FHIR Limitations and Possible Solutions

Recognizing that FHIR's Terminology resources were not designed to enable collaboration between terminology authoring entities, there are several limitations implementers should be aware of when using FHIR for Terminology Change Set Exchange. Many of these limitations can be addressed through FHIR's inherent extensibility, but others are more difficult to address.

Limitations addressed via Extensions

Concept description attributes

These are secondary attributes adding context to concept designations, utilized at the CodeSystem.concept.designation element level.

• Concept designation dialect - to distinguish between multiple designations used in different langauges or dialects. For example, the SNOMED CT term 271737000 | Anemia (disorder) has a designation "Anemia" in the United States English dialect, but "Anaemia" in the Great Britain English dialect.
• Concept designation case sensitivity - to identify the case sensitivity applicable to the designation to retain its meaning. For example, "HIV" (for Human Immunodeficiency Virus) must remain uppercase and therefore is "Case Sensitive", whereas "diabetes mellitus" can be shown as "Diabetes Mellitus," "DIABETES MELLITUS," etc. and therefore is "Case Insensitive".
• Concept designation acceptability - to identify the relative suitability across several designations for a given concept. For example, for the SNOMED CT concept 22298006 |Myocardial infarction (disorder), a "Preferred" designation for use is "Myocardial infarction", but "Heart attack" is an "Acceptable" designation.

Concept property attributes

These are secondary attributes adding context to properties for concepts, utilized at the CodeSystem.concept.property element level.

• Concept property defining relationship type - to clarify if the property was explicitly "stated" by a terminologist, or "inferred" through some deductive process, such as a description logic classifier. For example in SNOMED CT, 205237003 |Pneumonitis (disorder) is Stated to be a 64572001 |Disease (disorder), but can be inferred to be a 19829001 |Disorder of lung (disorder).
• Concept property EL++ profile set (Necessary vs. Sufficient) - to clarify if the property is "necessary" or "sufficient" in defining the concept. For an example of how SNOMED CT applies these concepts, see here: https://confluence.ihtsdotools.org/display/DOCRELFMT/D.2+Necessary+and+Sufficient+-+Examples
• Concept SNOMED CT Role Group - to identify which role group to which a given property belongs in defining the concept. Role groups are constructs used to group related attributes together within a clinical concept, ensuring that the relationships between those attributes are accurately represented and unambiguously interpreted.

Other Limitations

Standardization of CodeSystem.property codes

HL7 has published some guidance on codes to use to represent properties from several terminologies (see: SNOMED CT Properties and LOINC Properties), but widespread implementations appear inconsistent. Additionally, any terminology exchange that lacks this standardization will likely struggle to convey semantic detail for concepts.

Change Sets with granularity below the concept level

As currently modelled, the smallest change that can be represented in a CodeSystem resource is a full "snapshot" representation of a Concept from that CodeSystem. If for example, the only change made to a Concept was a change to one of it's designation values, implementations would need to include the full semantic detail for that Concept in a Change Set. The specific change made would only be apparent via a comparison to the prior representation of the Concept.

Provenance to small changes

In the situation where multiple small changes were authored by several individuals, there are limits to how those changes can be referenced via a Provenance resource. Recognizing that with FHIR R5 a common extension was published allowing Provenances to reference elements within a resource (https://hl7.org/fhir/extensions/StructureDefinition-targetElement.html), even this approach is limited to those elements that have id attributes. In a CodeSystem change set instance, the most granular structure a Provenance could refer to using this approach would be an individual CodeSystem.concept, and changes specifically to sub-elements such as a Concept designation can not be indicated in this way.