Using a FHIR Observation

These are some notes written by Lloyd, Grahame & Eric about using Observation in practice. I’ve copied this directly, here so I always know where to find it. You should refer to the source for the most recent version.

Observation.component, Observation.extension and Observation.related all provide ways of conveying “extra” information about an Observation.  This document provides some design principles to help in deciding which of these mechanisms should be used to solve a given problem.

1. Distinct Observation instances should be created whenever information can reasonably be interpreted and used independently or where the Observation characteristics of subject/performer/time/method are different.  I.e. don’t use components or extensions for anything that is reasonably used or exchanged by itself – regardless of how the data might be captured.  Components and extensions should only be used when information is tightly coupled to an observation and cannot usually be usefully interpreted apart from it.  For example, “body position” is not useful when separated from a Blood Pressure measurement.  However white blood cell count can be interpreted just fine if it is separated from hemoglobin – even though they may have both been measured at the same time and reported together.  (Note: This is already discussed in the Observation usage notes.)
2. Just because something was an OBX in v2, that doesn’t mean it should be an Observation or Observation.component in FHIR.  In v2, OBX was often used as a “grab bag” for additional information (particularly information that is tangentially related to observations) when there was a desire to avoid Z-segments.  In FHIR, Observation and Observation.component have specific purposes:
   1. Observation is about information that is being collected/observed
   2. Observation.components are qualifiers on what was observed or sub-aspects of what was observed.  If a requirement is dealing with something other than that, an extension may be needed.  For example, elements that qualify other Observation attributes – qualifiers on who performed the observation, when the observation happened, etc.  – should be considered as extensions on the associated Observation attribute.  This is especially if equivalent data in other resources would be handled this way.
3. If there’s a core property on a resource that’s semantically appropriate to convey information, it should be used in preference to extensions.  Extensions are only to be used when information cannot be appropriately conveyed in core structures and the requirement does not meet the 80% guideline for addition as core across the broad scope of the resource.  The reasons for this are as follows:
   1. A few systems will outright reject instances with extensions they don’t recognize.  This isn’t good practice, but some systems feel they may incur a liability if they accept data they can’t fully support and would rather not support it at all.
   2. Some systems will throw away unrecognized extensions because they do not have the ability to store them.  This will not be an issue for systems designed for FHIR, but most healthcare systems will not be for many years, if ever.
   3. More systems will be incapable of displaying extension data they don’t recognize, even if they do support FHIR internally
   4. Extensions will not be searchable in most systems including test servers.  While the component search capabilities may not meet all needs, they provide more functionality than none.  Defining additional search capabilities is no different whether the search is against extensions or components.
   5. For any extension to be supported or searchable, implementations must create and maintain customizations to their base implementation.  This has a cost and the cost is multiplied by all systems that must support the extension or at least convey/transport the extension
   6. FHIR specifications should be designed to accommodate the needs of legacy systems as much as possible.  While systems may make changes to accommodate new domains, the degree and speed of change will vary.  The more systems that can consume useful amounts of the data, the more useful a specification will be.  Core elements are those that have been deemed to be most likely to be supported by legacy systems.
   7. The machine processing effort to slice based on Observation.component.code vs. Observation.extension.url is not significantly different – both the code and the URL essentially function as “magic strings” that can be used to find the appropriate data element.  Where magic strings need to be used, HL7 prefers that they come from a formally maintained ontology – i.e. a code system – to help ensure consistency and coherence.  While extensions can be tied to external terminologies, it’s more direct to use the Observation.component mechanism.

Note: Extensions should not be used as a mechanism for avoiding FHIR’s expectation for usage of external code systems.  If external code systems can be shown to be insufficient or unreliable, HL7’s SNOMED partition or other options can be available.  Concerns about the use of external code systems such as LOINC or SNOMED should be discussed with HL7’s Terminology Authority.

1. Deep extension hierarchies should be minimized as they add additional complexity to data storage (meaning fewer systems will support them and more systems will throw them away).  That said, they will certainly be necessary for repeating collections of elements.  Grouping of optional or related data is less of a driver as resources are an organizational structure for exchange, not user interfaces.  Co-occurrence constraints can handle small groups of elements that must be omitted or appear as a group.