The Location resource contains all the primitive details of a resource, such as its name, address, geographic co-ordinates, and/or geographic boundary.
The only relationship defined in the current Location definition is the basic part-of property, which is intended to indicate subsets and only permits a single hierarchy - which is typical of Organization locations rather than geographic regions.
The ability to support multiple hierarchies is what we are seeking to detail.
Terminologies are more than just codes. They can contain properties, and also relationships. It is the combination of these things that make it suitable for representing location hierarchies.
Also within the terminology space are mappings (via the ConceptMap resource) which can link concepts, which is particularly useful to map between different versions of terminologies.
This has been done in other verticals before in FHIR, specifically in the medications space. Here the relationships help link various medications to categories of medication, packaging of medications, and also relationships between drug classes and brand vs generic content.
The terminology service in FHIR is able to then provide ways to navigate those relationships to discover various things.
The Medication resource itself has a code
property that links to the appropriate codes/concepts.
There is also some history with locations being in terminologies, as in many systems the set of countries, states, counties, towns etc are all stored in lookup lists (a code system) and used in address finders too, binding the valueset to multiple address properties to provide a level of validation.
The relationships between these is not always available, but sometimes is.
Although the geometry data could be added to the CodeSystem as properties of the codes (and I've seen it done), I don't believe that we should be doing this, and leave that data in the Location resource itself.
Some examples of locations in terminologies (many not FHIR):
One suggestion has been to use stub Organization and OrganizationAffiliation resources.
Note: I'm not a fan of this approach as it pollutes the other resources with resources that are not useful for anything else, and could cause other issues while sharing the data.
If we leverage the relationships via the terminology, we will need to define the relationships between the locations (as codes) and then also link the concept for the location to the Location resource.
Properties on the concept (inside the code-system, or via code-system supplements) there are many pre-defined properties that we can use, specifically parent
, child
and part-of
which can be leveraged by the token search modifiers above
, below
, in
and not-in
.
This example shows a hypothetical codesystem concept for New York City that has
the relationships to New York State, An Eastern region, and a partOf the USA.
These other concepts would be in the same codesystem for this example, and shows
how multiple parents/children is possible.
These properties could also link to external code systems, though that doesn't directly link into the standard search functionalities, but can work with valuesets to select levels of a hierarchy, or even filter content directly via $expand.
The property would need to be pre-defined to be used.
ConceptMaps to link concepts externally (assuming same concepts as above)
Linking the concept to its equivalent location resource is then done using coded properties on the Location resource.
This could be one of:
As the content is now coded, sharing this should be much simpler and able to be defined by the appropriate custodian of the data.
Referencing the location "concepts" now has a code that can be attached to content to cross link everything, and the regular CodeSystem canonical resource versioning and management can help ensure that all is well managed.
The Location instances with that addition coded data included could then also be distributed via the CRMI approaches too.
(refer to the non-canonical-artifacts section)