Two-phase FHIR terminology

Terminology in Health IT is a very important and complicated aspect. A lot of interoperability depends on how accurately do you encode your data.

FHIR Terminology Service specification does a great job to provide developers with simple and straight-forward API for terminology service.

Terminology management is a complicated domain — you have to keep up-to-date external code systems, understand their internal structure, provide authoring, versioning and publishing tools.

We can imagine an architecture with separated FHIR server & Terminology service. But “good” FHIR server has a quite strong dependency on Terminology — for validation, lookups and subsumption queries. Implementing full terminology service specification in FHIR server is a big deal. Using external terminology service make your FHIR server non-autonomous. So we have a trade-off :(

Authoring vs Usage

If you look closer into FHIR terminology you might notice that terminology can be decomposed into two parts — authoring/manage and usage. For authoring cases, you need up-to-date CodeSystems, ValueSets design tools with expansion engine, versions management etc. For usage, you mostly will work with immutable ValueSets and have to provide efficient filtering and lookup for validation.

To reduce coupling between Terminology and FHIR server, we can separate responsibilities in the following way:

Here are the technical details of how we can do this.

Concept Resource

In Aidbox we split CodeSystem into header info and set of Concept (Non-FHIR-yet :) resources, which have a similar structure as CodeSystem.conceptelement and Coding datatype. This allows us to translate part of Terminology Service API into unified FHIR crud/search API over Concept Resources.

We convert popular terminologies into a set of Concept resources, which can be distributed as ndjson files for efficient bulk export/import. Here is an example for LOINC:

---
- code: 10000-8
  display: R wave duration in lead AVR
  names:
 - R wave dur L-AVR
 - Cardiac
 - "Durat"
 - "ECG"
 ....
  property:
      loinc:
          relatednames2: Cardiac; Durat; ECG; EKG.MEASUREMENTS; ...
          method_typ: EKG
          classtype: '2'
          system: Heart
          time_aspct: Pt
          common_order_rank: '0'
          property: Time
          order_obs: Observation
          unitsrequired: Y
         ....

Expansion denormalization

If we add to Concept Resource multiple links to Value Sets we can denormalize all sophisticated Value Set expansions like this:

code: 10000-8
system: http://loinc.org
display: R wave duration in lead AVR
valueSet:
-
reference: ValueSet/LL1162-8
-
reference: ValueSet/another-vs

Set of Concepts with denormalized ValueSets can be dumped into ndjson with kinda bulk export API and uploaded into FHIR server.

FHIR server runtime

Concept resource with links to ValueSets can be used in FHIR server to implement basic usage operations — $expand with filter, $validate-code and $lookup — by simple search API over Concept:

GET /ValueSet/v1/$expand?_filter=x
=> GET /Concept?vs=v1&display=???/ValueSet/v1/$validate-code?system=???&code=???
=> /Concept?vs=v1&system=???&code=???

Conclusion

To simplify usage of terminology and decouple FHIR servers from terminology, we can introduce new Concept resource type, do all ValueSet authoring on terminology service and bulk export/import denormalized (expanded) Concepts into FHIR servers with much more simple implementation of basic operations.

Your feedback is welcome!

Two-phase FHIR terminology

Terminology in Health IT is a very important and complicated aspect. A lot of interoperability depends on how accurately do you encode your data.

FHIR Terminology Service specification does a great job to provide developers with simple and straight-forward API for terminology service.

Terminology management is a complicated domain — you have to keep up-to-date external code systems, understand their internal structure, provide authoring, versioning and publishing tools.

We can imagine an architecture with separated FHIR server & Terminology service. But “good” FHIR server has a quite strong dependency on Terminology — for validation, lookups and subsumption queries. Implementing full terminology service specification in FHIR server is a big deal. Using external terminology service make your FHIR server non-autonomous. So we have a trade-off :(

Authoring vs Usage

If you look closer into FHIR terminology you might notice that terminology can be decomposed into two parts — authoring/manage and usage. For authoring cases, you need up-to-date CodeSystems, ValueSets design tools with expansion engine, versions management etc. For usage, you mostly will work with immutable ValueSets and have to provide efficient filtering and lookup for validation.

To reduce coupling between Terminology and FHIR server, we can separate responsibilities in the following way:

  • Design ValueSets on Terminology Service and publish in expanded form by some kind of bulk export API/format
  • Load and use ValueSets in an optimized form into FHIR servers

Here are the technical details of how we can do this.

Concept Resource

In Aidbox we split CodeSystem into header info and set of Concept (Non-FHIR-yet :) resources, which have a similar structure as CodeSystem.conceptelement and Coding datatype. This allows us to translate part of Terminology Service API into unified FHIR crud/search API over Concept Resources.

We convert popular terminologies into a set of Concept resources, which can be distributed as ndjson files for efficient bulk export/import. Here is an example for LOINC:

---
- code: 10000-8
  display: R wave duration in lead AVR
  names:
 - R wave dur L-AVR
 - Cardiac
 - "Durat"
 - "ECG"
 ....
  property:
      loinc:
          relatednames2: Cardiac; Durat; ECG; EKG.MEASUREMENTS; ...
          method_typ: EKG
          classtype: '2'
          system: Heart
          time_aspct: Pt
          common_order_rank: '0'
          property: Time
          order_obs: Observation
          unitsrequired: Y
         ....

Expansion denormalization

If we add to Concept Resource multiple links to Value Sets we can denormalize all sophisticated Value Set expansions like this:

code: 10000-8
system: http://loinc.org
display: R wave duration in lead AVR
valueSet:
-
reference: ValueSet/LL1162-8
-
reference: ValueSet/another-vs

Set of Concepts with denormalized ValueSets can be dumped into ndjson with kinda bulk export API and uploaded into FHIR server.

FHIR server runtime

Concept resource with links to ValueSets can be used in FHIR server to implement basic usage operations — $expand with filter, $validate-code and $lookup — by simple search API over Concept:

GET /ValueSet/v1/$expand?_filter=x
=> GET /Concept?vs=v1&display=???/ValueSet/v1/$validate-code?system=???&code=???
=> /Concept?vs=v1&system=???&code=???

Conclusion

To simplify usage of terminology and decouple FHIR servers from terminology, we can introduce new Concept resource type, do all ValueSet authoring on terminology service and bulk export/import denormalized (expanded) Concepts into FHIR servers with much more simple implementation of basic operations.

Your feedback is welcome!

About FHIR facades (part I) - two approaches

ReAD MORE

Two-phase FHIR terminology

ReAD MORE

First Fhirbase Release

ReAD MORE

FHIR Storage and Analytics in Baltimore

ReAD MORE

SQL on FHIR

ReAD MORE

Should you use FHIR resources as your data storage format?

ReAD MORE

The FHIR Guide for CTOs and technical leaders

ReAD MORE

FHIR and Machine Learning (ML)

ReAD MORE

Announcing the FHIRbase Dojo!

ReAD MORE

FHIR Starter 2018: Recap of the first FHIR conference in Eastern Europe

ReAD MORE

Using FHIR to Simplify Healthcare Application Development

ReAD MORE

FHIR: What's great, what isn't so good, and what it's not built to do

ReAD MORE

Moving Cardiovascular Disease Detection to the Cloud

ReAD MORE

FHIR Success Story: Narus Health Connects Patients, Families and Providers

ReAD MORE

Thoughts on the Duke University FHIR Applications Roundtable

ReAD MORE

Choosing Access Control Model for a Generic FHIR Server

ReAD MORE

Implementing FHIR in Dynamic Languages

ReAD MORE

Choosing FHIR for Laboratory Integration

ReAD MORE

Thoughts About Microservices

ReAD MORE

Meaningful Use Stage 3: ONC-certified API for your health care application

ReAD MORE

Transforming Healthcare IT

ReAD MORE

Starting a Health IT project with the FHIR standard at your healthcare organization

ReAD MORE

How do we build the best Convenient Healthcare Clinics?

ReAD MORE

Accelerating Healthcare Innovation with HL7 FHIR

ReAD MORE
415 S Sepulveda Blvd Ste 1000 Los Angeles, CA 90034
+1 (818) 731-1279
hello@health-samurai.io