Reading FHIR Implementation Guides

Learning objectives
  1. Understand the purpose and structure of FHIR Implementation Guides (IGs).

  2. Apply the approach described in “Reading an IG” to reading and evaluating IGs for research purposes.

Relevant roles:
  • Investigator
  • Informaticist
  • Software Engineer
  • Clinician Scientist/Trainee

FHIR Implementation Guides (IGs) define a “set of rules of how a particular interoperability or standards problem is solved.”

IGs are published as web pages (like the ones listed here) that include both human-readable and machine-readable versions of the rules. For example, the human-readable version of US Core’s Patient profile and the machine-readable version are published alongside each other in the US Core IG. Additionally, IGs typically include substantial narrative content describing the problem they are addressing and providing additional context for their rules.

Researchers who are working with FHIR will likely need to read FHIR IGs, including those that are not specifically designed for research purposes (like US Core).

FHIR IGs typically share a common structure and format (especially those published through HL7®). The CodeX FHIR Accelerator has published a set of comprehensive resources on IG authoring that includes a detailed explanation of how to read and understand these common elements across IGs. Please use the button below to open this resource in a new window:

Open FSH Seminar > Reading an IG materials →

Evaluating an IG for research

The approach described in the materials FSH Seminar materials linked above can be applied to reviewing an IG for research purposes. Some of the key considerations specifically for research include:

  • Are all the necessary data elements included in the resources profiled in the IG? Determining

  • Are the constraints defined in the IG appropriate for the relevant research use cases?

    • Are necessary data elements marked as required or marked as MustSupport? This means that conforming FHIR servers should provide the data elements if they are available.

    • Are there any required data elements that are problematic from a research perspective? (E.g., requiring a patient’s name for research on deidentified data.)

  • Are there terminology bindings, and are they sufficiently strong to ensure consistent output?

    • Note that unless a terminology binding is set at the “required” level, FHIR servers may still return concepts that are not in the bound ValueSet.

    • This is especially relevant for using FHIR across different systems or institutions, which may use different terminology. It may be necessary to map to a single set of concepts, either as part of the FHIR implementation or during data analysis.

  • Is the IG implemented on the relevant FHIR servers you wish to get data from? If not, how much effort would be required to implement it?1

    • In the US, many IGs are based on US Core. Because many FHIR-enabled systems already support US Core, it may be easier to implement IGs that are based on it compared to IGs that are not.2

Next steps

Researchers using FHIR may wish to extend an existing IG, or create their own from scratch to define how FHIR should be used for their use case. Please see Writing IGs for more information.

Footnotes

  1. One approach to assessing this is to access instances of FHIR resources profiled in the IG from the FHIR server, and then compare them to the IG to see how close they are to the desired output.

    Conformance to an IG can be assessed automatically using a tool like the FHIR validator, or the output of the FHIR server can be manually compared against the profiles in the IG.↩︎

  2. IGs that are published through HL7 in the US Realm are typically required to either be based on US Core, or get an explicit exemption (which should be described in the IG).↩︎