Monthly Archives: January 2013

Question: HL7 v2 Query Semantics

Question:

My question relates to HL7 v2 Query / Query response. In chapter 5 of the specification, it talks about a query and its response should be thought of as a message pair. Does that mean when a server responds to a query it should only respond with information pertaining to the query?

I ask because we are interacting with a service that can respond to a query with information from a previously timed out query in addition to the current query.

Would you consider that a breach of HL7?

Answer:

It’s certainly true that the expectation is that the query and response are a pair. Well, at least, that they are tied together. A single query may lead to multiple responses. Concerning the use of these messages, the specification says:

The variety of potential queries is almost unlimited

These transactions provide a format, or a set of tools to support queries to the extent desired by the institution. The resources available and local policies will influence the type of queries that are implemented

(Both quotes from section 5.2)

I wonder about the wisdom of responding to a new query with information from a previous query, but it’s certainly not a “breach of HL7” (i.e. not conformant).

Standards have no sense of humor

FHIR is a draft standard that is early in it’s ballot cycle. It’s a reasonable anticipation that it will end up as a ISO standard in the fullness of time. But for now, it’s just a draft standard. Writing a standard is a huge piece of work, and you have find entertainment where you can…. with that in mind, I added a couple of jokes to the specification.

In the roadmap, after describing the general nature of FHIR, I add this line:

Compared to the all the other approaches, FHIR… [– Obligatory: insert your FHIR FIRE related joke here –].

It’s not as if I won’t have heard the joke before – sometimes my life seems to consist of a continuous stream of people telling me FHIR related puns and jokes. There’s several different pronounciations, each with their own stream of jokes.

The other point is in the RESTful specification, where I added a new HTTP status code. The existing status codes describe the server rejecting an HTTP request for a variety of transport/negotiation/parsing/security failures, but there is no code to say that the request as submitted would violate server business rules – all there is is a general server error. But the case that a client makes a request that would violate business rules on the server is both common and important in FHIR, so it was proposed that we should add an HTTP status code to indicate this status. Since adding a new HTTP status code is a rather involved process, I added a custom code on a temporary basis:

  • 490 Talk to the Hand – the proposed resource violated server business rules.

Well, it turns out that HL7 balloters don’t have a sense of humor – both of these two attracted several negative ballot comments.

Guess I’ll have to find my entertainment somewhere else….

Question: UnitID and UnitType in CDA

Question:

What is the purpose of unitID and unitType in the address type in HL7 CDA? Do they come from a closed termset? I assume they are related, but I can’t really tell as I haven’t found documentation about it

Answer:

Well, this is some thing that’s a little unclear in the data types definitions. The data types spec says that these two names map to two particular part type codes:

unitID UNID
unitType UNIT

Then it gives these definitions for these two codes:

  UNID unit identifier The number or name of a specific unit contained within a building or complex, as assigned by that building or complex.
  UNIT unit designator Indicates the type of specific unit contained within a building or complex. E.g. Appartment, Floor

Separating out these kind of fields in an address is very unusual – most systems simply have lines + town/suburb + post code + state/country, depending on where you are in the world.

But some systems parse the address more aggressively, or demand more careful entry on the part of the person filling out the field. In Australia, this level of data entry is something I’ve occasionally seen on that part of large public-facing entities, such as telstra, or medical insurers (as much as anything else, it’s about cheaper postal delivery).

By the way, if you receive an address part UnitId and UnitType, and you don’t cater for these kind of address parts, the intention is that you collapse these to a plain line of text, or something simpler that you do support.

FHIR Extensions, the 80/20 rule, DICOM and the LONG tail

As part of FHIR, we have said that resources will only contain the “core” elements, and those not widely used will be delegated to a robust extension mechanism.

As a rule of thumb, we’ve talked about using an 80/20 rule – elements should be included in a resource if they are catered for / used by 80% of the implementing systems. This rule of thumb has been quite controversial, even just as a rule of thumb, just used as a guide to help decide what is and isn’t out. One of the big question is 80% of what? And that’s not a simple question, with a simple answer, and it’s not meant to, though it’s one reason why FHIR resources need to have a well defined scope, so that it’s less opaque regarding 80% of what. And even then it’s hard, because it’s extremely difficult to get examples of real world exchanges, let alone a good representative collection, by which you can get even rough statistics.

As part of my preparation for the HL7 Phoenix meeting, I’m giving some thought to what a FHIR resource for RESTful access to DICOM images would look like (this is possible future joint work with NEMA). It’s early days – we don’t know what the scope of RESTful resources would be – study, series, image, plane? But as part of my preparative work, I prepared a scatter plot for the frequency of DICOM elements in my set of sample DICOM images (mostly derived from http://support.dcmtk.org/wiki/dicom/images, but also stuff I’ve collected through commercial use in Australia). Note that it’s easier to collect this for DICOM than for HL7 v2 and CDA documents, since it’s easy to pack messages into files and vice versa  (something that I’d like to be true of FHIR, because it really is good for the ecosystem). So we could take this sample set as somewhat illustrative of the situation in health care exchange generally (Note: I have only included data elements in the root of the file, not nested sequences, and the distribution includes manufacturer defined tags as well):

dicom-distribution

It’s really intriguing to see just how long the tail is – only 30 of 900 different DICOM elements I encountered appeared in >80% of the DICOM images, and about 700 of the 900 appeared in <1% of the images. This tail is longer here than it really is for several reasons:

  • it’s a set of DICOM images that cross modalities. One DICOM standard for all modalities, like if you had one HL7 message for all message types (though this set doesn’t include non-image related dicom content such as MPP or structured reports)
  • it’s based on the instances, not the systems. The tail will always be longer for instances, since some things only appear a few times, but are always important when they do (i.e. LMP in an image), so they are supported in all/most systems
  • it’s based on examples not production images (mostly) – though that might cut both ways

Nevertheless, a few of us that looked at this distribution were surprised by how long the tail is even given these caveats.

Note that the modality is an interesting one: a modality such as MRI is <20% of usage, but obviously important. It needs a whole set of custom data elements to properly describe the image. Perhaps, in a FHIR context, that implies that there might be modality specific resources for further image details? These details lie in front of us. Note that this is a common pattern that crops up in other areas too – such as medications, where 99% of medications are off the shelf retail formulations, but a few specific areas of medicine have highly specific and detailed formulation requirements (i.e. chemotherapy).

I present this primarily to demonstrate the length of the tail. These elements and features often occupy a significant portion of the standard – but a casual reader often can’t judge what to ignore or not until after they’ve read and understood the whole thing. So they add to the cost of implementation, even when they aren’t used. We’re trying to keep the long tail down in FHIR, without denying the functionality that they represent.

As for the FHIR Image resource – the table that underlies this graph will be useful for prioritising what to represent in the resource, but is hardly going to be a final determiner.

Top 30

Since people will no doubt be interested, here’s the top 30 root element list (the 100% are the mandatory elements, so that’s not really surprising):

 

0008,0016 100 (Image Properties/SOP Class UID)
0008,0018 100 (Image Properties/SOP Instance UID)
0008,0020 100 (Image Properties/Study Date)
0008,0030 100 (Image Properties/Study Time)
0008,0050 100 (Image Properties/Accession Number)
0008,0060 100 (Image Properties/Modality)
0008,0070 100 (Image Properties/Manufacturer)
0008,0090 100 (Image Properties/Referring Physician’s Name)
0010,0020 100 (Patient Details/Patient ID)
0020,000D 100 (Study Instance Properties/Study Instance UID)
0020,000E 100 (Study Instance Properties/Series Instance UID)
0020,0010 100 (Study Instance Properties/Study ID)
0020,0011 100 (Study Instance Properties/Series Number)
0020,0013 100 (Study Instance Properties/Instance Number)
0010,0010 99 (Patient Details/Patient’s Name)
0010,0030 99 (Patient Details/Patient’s Birth Date)
0010,0040 99 (Patient Details/Patient’s Sex)
0028,0010 85 (Sampling Property/Rows)
0028,0011 85 (Sampling Property/Columns)
0028,0002 84 (Sampling Property/Samples per Pixel)
0028,0004 84 (Sampling Property/Photometric Interpretation)
0028,0100 84 (Sampling Property/Bits Allocated)
0028,0101 84 (Sampling Property/Bits Stored)
0028,0102 84 (Sampling Property/High Bit)
0028,0103 84 (Sampling Property/Pixel Representation)
7FE0,0010 84 (Pixel Data/Pixel Data)
0008,1030 70 (Image Properties/Study Description)
0008,103E 62 (Image Properties/Series Description)
0008,0008 59 (Image Properties/Image Type)
0020,0020 56 (Study Instance Properties/Patient Orientation)

Implementing XDS on a FHIR Server

This is a follow up to an earlier post, Implementing ATNA on a FHIR server, and a preparative post for the XDS-focused FHIR Connectathon to be held this weekend.

For the connectathon, I am providing an XDS.b interface to a FHIR Resource Repository. The server accepts and XDS.b “ProvideAndRegisterDocumentSet” operation, and converts it a set of FHIR resources, and then submits them to the FHIR Repository. It would be possible to support other XDS.b operations, but I don’t have time for this prior to the connectathon.

There’s some conceptual differences between a XDS.b approach, and the FHIR RESTful approach to XDS:

  • The XDS.b interface is very transactional – a focus on “submission sets”, things that are submitted together. On the other hand, the FHIR definitions for XDS are very focused on stable resources – documents, folders, authors, patients. The notion of a submission set is absent in FHIR (though you can submit groups of these resources as a “batch” to a FHIR Repository
  • Security: the FHIR definitions that support XDS functionality do not get involved with security – it is assumed that this comes from elsewhere, using standard functionality such as OAuth.
  • The classic XDS architecture has a document source submitting to a document repository, which notifies a patient registry of the existence of the document, so that document consumers can find it. FHIR handles this differently: registries, which are aggregators of content, subscribe to multiple repositories by using their atom feeds.

To explain the third point further, an XDS eco-system consists of a series of clients and servers that use the following resource types:

  • Patient/Person – patient demographics
  • Agent/Organization – author & provider information etc
  • XdsEntry – the actual index entry for a document
  • XdsFolder – when the document is allocated to a folder
  • SecurityEvent – equivalent of an ATNA record (see Implementing ATNA on a FHIR server)
  • Binary – the resource that actually stores the document itself

In FHIR, the difference between a registry and a Repository is that the repository supports the binary resource, and references from the XdsEntry to the Binary refer to local references on the server, whereas a registry has XdsEntry resources that refer to the content found elsewhere – either Binary Resources on another server, or some other kind of server that serves resources. A registry subscribes to XdsEntry updates, and converts (if necessary) relative references to Binary resources to absolute references. It would also subscribe to the other resource types (Patient, Person, Agent, Organization, XdsFolder)

This means that a server that provides “ProvideAndRegisterDocumentSet” has to take the submission, convert it to a set of resources, and store those resources in a FHIR repository. Documents submitted through the XDS.b interface become visible by watching the XdsEntry atom feed, or by searching the XdsEntry resources on the server. Done carefully, a ProvideAndRegisterDocumentSet can be converted to a FHIR batch in a single operation, which can then be submitted to a FHIR repository as a separate operation – this is called an “XDS 2 FHIR Bridge”.

A test implementation of an XDS 2 FHIR bridge can be found at http://hl7connect.healthintersections.com.au:3098/svc/xds. This accepts XDS ProvideAndRegisterDocumentSet operations. Submitted documents can be seen at http://hl7connect.healthintersections.com.au/svc/fhir/xdsentry. This is based on an IHE certified XDR implementation, though this version hasn’t been IHE certified. (No security, btw, since the outputs are public anyway, so don’t submit real clinical documents!) (And note that due to a technical limitation in the XDS side of the implementation, this interface only accepts CDA documents, not any other kind of document).

Note that this test implementation also builds an XdsEntry2 as well as an XdsEntry – the FHIR project team is evaluating two different granularity approaches to XDS, to see which provides the best balance of usability and re-useability.

Note also that this implementation makes extensive use of inline resources, as discussed previously, as a way of evaluating their use.

Implementation Details

The implementation of the bridge is done in javascript. The script is commented extensively to explain what is happening. As an overview, the script has to build the following kinds of resources:

  • XdsEntry (no XdsFolder support – I haven’t seen real world usage of that yet)
  • Patient/Person
  • XdsEntry2 / Agent

In addition to building their raw contents by extracting information from the XDS ExtrinsicObject, the script also has to figure out how the resources are identified, and link them up correctly in in the batch so that server will identify them properly. Much of the hard work is involved in this step (see previous post on this subject).

The script is called and provided with a handle to 3 parameters of interest: the ExtrinsicObject element in the submission set, the associated binary content as base64, and an empty batch to be filled out form the information provided in the ExtrinsicObject. The script makes use of some fairly obvious utility functions, and a FHIR factory object that is used to construct the objects that build out the batch.

I keep the current version of the script at http://www.healthintersections.com.au/xds2fhir.js – read the script for further information.

Question: FHIR date formats in JSON

Question:

I’m reading a bit about FHIR … and I was wondering why you choose to specify date/time as strings instead of the notation below that is commonly used in JSON and supported by e.g. MongoDB tools for queries on date values ?

e.g.
“birthDate”: {
“$date”: “1968-04-08T23:00:00.000Z”
},

Answer:

When we considered the JSON date representation, we searched for any evidence that one of these date formats, of which there are several, was gaining real traction in the community. We could find no evidence that any one of these date formats was a clear winner, particularly in terms of support in common JSON parsing libraries.

As a consequence, we elected to use the same wire representation as all the other properties, and the same as in the XML – which happens to be, for full date times, exactly the same format you use above, though without the $date part. Note that the “$” part also causes problems for many json libraries as well – we tried to use that for something, and had to change away from that because several important platforms couldn’t work with that (I forget which ones).

JSON is real convenient for the users, but it’s very hard to use in a standard.

We’d be happy to receive solid feedback that the current solution doesn’t work with MongoDB – but note that a number of the implementers in the project team itself use MongoDB. Perhaps one of them might comment.

Question: How to use FHIR for ABBI

Question:

How could you represent the ABBI text data using FHIR resources?

Background: We (the FHIR project team) have had some interaction with the ABBI development team in the past week or so. They are looking for a more formal representation for ABBI than text, and JSON has emerged as a possible / favored candidate. That lead them to looking at FHIR to see whether we had anything to offer in this space.

Answer:

Well, FHIR certainly has a lot to offer – something that is developing quickly, but is on the standards track, that offers both XML and JSON (interchangeably, which isn’t as easy as it sounds), works with REST and the web, and is easy to use. But there’s something missing: FHIR doesn’t have a relevant resource for the core of the ABBI data set. So we had a fruitful interchange with some of the ABBI team, and they sent us some definitions and sample (real) data (yay – sample data – that’s what we like, real data), and we knocked up a straw-man Claim resource that would be suitable for use with ABBI data, that includes our own experience with claims data, and that is consistent with the way things are done in FHIR.

Since this is (presently) out of band work done at the behest of some members of the ABBI team, it’s not going to be part of the FHIR spec published at http://hl7.org/fhir (for now, at least). Instead, it’s published here:

Claim Resource

Covers both initial claims (invoices) and adjudicated claims (EOBs – Explanations of Benefits). UML:

claim

Note: there’s a problem with the representation of subline – it should be a relationship back to Line (Something for me to investigate in the tooling).

The XML definition for this is:

<Claim xmlns="http://hl7.org/fhir">
 <identifier><!-- 0..1 Identifier Id for this claim instance --></identifier>
 <adjudicating><!-- 0..1 Resource(Claim) For adjudication, what invoice is it --></adjudicating>
 <type><!-- 0..1 CodeableConcept Type of claim --></type>
 <period><!-- 0..1 Period Timeframe covered by claim --></period>
 <patient><!-- 1..1 Resource(Patient) Covered party --></patient>
 <billingProvider><!-- 1..1 Resource(Person|Organization) Who is billing --></billingProvider>
 <coverage><!-- 1..1 Resource(Coverage) What coverage is claim against --></coverage>
 <precedingClaims><!-- 0..* Resource(Claim) Other coverages billed --></precedingClaims>
 <netAmount><!-- 1..1 Money Amount to be paid --></netAmount>
 <allowedAmount><!-- 0..1 Money Revised amount to be paid --></allowedAmount>
 <coveredAmount><!-- 0..1 Money Amount paid by coverage --></coveredAmount>
 <nonCoveredAmount><!-- 0..1 Money Left to pay by patient and/or subsequent coverage --></nonCoveredAmount>
 <line>  <!-- 0..* Breakdown of claim -->
  <code><!-- 1..1 CodeableConcept Billing code --></code>
  <modifier><!-- 0..* CodeableConcept Qualifiers for billing code --></modifier>
  <unitAmount><!-- 0..1 Money Amount paid/unit --></unitAmount>
  <unitQuantity><!-- 0..1 Quantity Number of units --></unitQuantity>
  <netAmount><!-- 1..1 Money unitAmount * quantity + sublines --></netAmount>
  <allowedAmount><!-- 0..1 Money Cap on amount allowed to be billed --></allowedAmount>
  <coveredAmount><!-- 0..1 Money Allowed net amount with adjustments --></coveredAmount>
  <service>  <!-- 0..* Healthcare service item is for -->
   <type><!-- 0..1 CodeableConcept Service code --></type>
   <bodySite><!-- 0..* CodeableConcept Where on body was service done? --></bodySite>
   <period><!-- 0..1 Period Start and end date --></period>
   <performer><!-- 0..1 Resource(Agent|Organization) Who delivered service --></performer>
   <location><!-- 0..1 Resource(Location) Where performed --></location>
   <indication><!-- 0..* CodeableConcept Diagnosis or clinical reason --></indication>
   <details><!-- 0..1 Resource(ANY) Details of service --></details>
  </service>
  <adjustment>  <!-- 0..* What's not covered & why -->
   <reason><!-- 0..1 CodeableConcept Reason for adjustment --></reason>
   <amount><!-- 1..1 Money Amount of adjustment (usually negative) --></amount>
  </adjustment>
  <subLine><!-- 0..* Content as for Claim.line Sub-elements of line item --></subLine>
 </line>
 <extension><!-- 0..* Extension  See Extensions  --></extension>
 <text><!-- 1..1 Narrative Text summary of resource (for human interpretation) --></text>
</Claim>

 

Note that this is just a strawman for illustration purposes, to see what this would look like in json. So let’s see a couple of examples. First of all, let’s get the patient details out of the way. (and also, the formatting of this sucks compared to the standard FHIR representation, but the WordPress editor has defeated me in that regard this time around).

What the ABBI team provided:

Name: JACYLN BOURNE
Date of Birth: 4/15/1941
Address Line 1: 415 EAST 71ST ST
Address Line 2:
City: NEW YORK
State: NY
Zip: 10021
Phone Number:
Email: sample@bluebuttontrust.org
Part A Effective Date: 11/1/2008
Part B Effective Date: 2/1/2009

Other than the Effective dates, which are really coverage information, this goes in the Person resource, and is represented in JSON like this:

{ 
  "Person" : {
    "name" : [{
      "family" : "BOURNE",
      "given" : "JACYLN"
    }],
    "telecom" : [{
      "system" : "email",
      "value" : "sample@bluebuttontrust.org"
    }],
    "birthDate" : "1941-04-15",
    "address" : [{
      "line" : "415 EAST 71ST ST",
      "city" : "NEW YORK",
      "state" : "NY",
      "zip" : "10021"
    }],
    "text" : {
      "status" : "generated",
      "div" : "..." 
    }
  }
}

Note that I was going to fill out the narrative in the div properly, but trying to represent html elements in the preformatted text throws the WordPress editor out, so you’ll just have to imagine something proper there.

Moving on, to the core of the data, here’s sample data provided by the ABBI team:

Claim Number: 9427984358334
Provider: MANHATTAN ENDOSCOPY CENTER L
Provider Billing Address: CL #4685  PO BOX 95000 PHILADELPHIA PA 191954685
Service Start Date: 9/21/2012
Service End Date: 
Amount Charged: $386.60
Medicare Approved: $386.59
Provider Paid: $386.59
You May be Billed: $0.00
Claim Type: PartB
Diagnosis Code 1: V1272
Diagnosis Code 2: 56210

Line number:  1
Date of Service From:  9/21/2012
Date of Service To:  9/21/2012
Procedure Code/Description:  G0105 - Colorectal Cancer Screening; Colonoscopy On Individual At High Risk
Modifier 1/Description:  
Modifier 2/Description:  
Modifier 3/Description:  
Modifier 4/Description:  
Quantity Billed/Units:  1
Submitted Amount/Charges:  $386.59
Allowed Amount:  $386.59
Non-Covered:  $0.00
Place of Service/Description:  24 - Ambulatory  Surgical Center
Type of Service/Description:  F - Ambulatory Surgical Center
Rendering Provider No:  A300070363
Rendering Provider NPI:  1124324181

Line number:  2
Date of Service From:  10/22/2012
Date of Service To:  10/22/2012
Procedure Code/Description:  G8907
Modifier 1/Description:  
Modifier 2/Description:  
Modifier 3/Description:  
Modifier 4/Description:  
Quantity Billed/Units:  1
Submitted Amount/Charges:  $0.01
Allowed Amount:  $0.00
Non-Covered:  $0.01
Place of Service/Description:  24 - Ambulatory  Surgical Center
Type of Service/Description:  F - Ambulatory Surgical Center
Rendering Provider No:  A300070363
Rendering Provider NPI:  1124324181

Represented in JSON following the definitions in the Claim resource above, this looks like this:

{ 
 "Claim" : {
    "identifier": {
        "id" : { "value" : "9427984358334" } 
    },
    "type" : {
        "coding" : {
            "code" : "PartB"
        }
    },
    "period" : {
        "start" : { "value" : "2012-09-21" }
    }, 
    "patient" : {
        "type" : "Patient", 
        "id" : "example-abbi"
    },
    "billingProvider" : {
      "Organization" : {
        "identifier" : [ {
           "label" : "Provider No",
           "identifier" : {
             "id" : "A300070363"
           }
        }, {
           "use" : "official",
           "label" : "Provider NPI",
           "identifier" : {
             "system" : "http://us.gov/NPI",
             "id" : "1124324181"
           }        
        } ]
        "name" : { value : "MANHATTAN ENDOSCOPY CENTER L" },
        "address" : {
          "line" : "CL #4685  PO BOX 95000",
          "city" : "PHILADELPHIA",
          "state" : "PA",
          "dpid" : "191954685"
        } 
      }
    },
    "netAmount" : {
        "value" : "386.60".
        "units" : "$"
    }
    "allowedAmount" : {
        "value" : "386.59",
        "units" : "$"
    }
    "coveredAmount" : {
        "value" : "386.59",
        "units" : "$"
    }

    "line" : [ {
      "code" : {
        "coding" : {
          "system" : "http://cms.gov/Medicare/Coding/type-of-service-codes",
          "code" : "1",
          "display" : "Medical Care"
        }
      }
      "unitAmount" : {
        "value" : "386.59",
        "units" : "$"
      }
      "unitQuantity" : {
        "value" : "1"
      }
      "netAmount" : {
        "value" : "386.59",
        "units" : "$"
      }
      "allowedAmount" : {
        "value" : "386.59",
        "units" : "$"
      }
      "service" : [ {
        "type" : {
          "coding" : {
            "code" : "G0105",
            "display" : "Colorectal Cancer Screening; Colonoscopy On Individual At High Risk"
          }
        }
        "period" : {
          "start" : "2012-09-21",
          "end" : "2012-09-21"
        }
        "location" : {
          "Location" : {
             "code" : {
               "coding" : {
                 "code" : "24",
                 "display" : "Ambulatory  Surgical Center"
               }
             }
          }
        }
      } ]
    },
    {
      "code" : {
        "coding" : {
          "system" : "http://cms.gov/Medicare/Coding/type-of-service-codes",
          "code" : "2",
          "display" : "Administrivia"
        }
      }
      "unitAmount" : {
        "value" : "0.01",
        "units" : "$"
      }
      "unitQuantity" : {
        "value" : "1"
      }
      "netAmount" : {
        "value" : "0.01",
        "units" : "$"
      }
      "allowedAmount" : {
        "value" : "0.00",
        "units" : "$"
      }
      "service" : {
        "type" : {
          "coding" : {
            "code" : "G8907"
          }
        }
        "period" : {
          "start" : "2012-10-22",
          "end" : "2012-10-22"
        }
        "location" : {
          "Location" : {
             "code" : {
               "coding" : {
                 "code" : "24",
                 "display" : "Ambulatory  Surgical Center"
               }
             }
          }
        }
      }
    }],
    "text" : {
      "status" : "generated",
      "div" : "..."
    }
  } 
}

Though there’s plenty of discussion to have around the exact design of the resource, and what elements there should be, etc, this is enough to show roughly what the output would look like using JSON resources as defined by FHIR. Coming cold at this, most readers would probably comment about a couple of apparently spurious levels of nesting, which equate to places for redirection or abstraction – such as code…coding…code, or location…Location. There’s good reasons for these nesting, though we’re still looking at cleaning this up so it looks better in the final instance.

p.s. Lloyd McKenzie did much of the preparative work for this post, including the original claim resource design – thanks.