Reading FHIR Implementation Guides

min. reading time 

Last updated: March 21, 2026

Roles: Investigator Informaticist Software Engineer Clinician Scientist/Trainee

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.

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?
• Are the constraints defined in the IG appropriate for the relevant research use cases?
  • Are necessary data elements marked as required or as MustSupport? (MustSupport 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?¹
  • 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.²

Reading Particular IGs

Below are overviews for reading several IGs which serve as examples for the broad range of content in FHIR IGs.

• US Core: Primarily defines profiles for data, and the necessary FHIR REST API interactions for accessing that data. The API interactions in this guide are simple queries in line with the base FHIR API.
• Bulk Data Access: Primarily defines a workflow for accessing data in bulk. The majority of the system interactions are not part of the base FHIR REST API.
• Electronic Case Reporting (eCR): Defines profiles for data and several reporting workflows. These workflows can involve interactions beyond the FHIR REST API such as FHIR Messaging and Subscriptions.

Details on these IGs appear below. Readers are encouraged to click through the links to IG pages and explore the contents of these IGs.

US Core

The main US Core page has a helpful “How To Read This Guide” section, which describes the different parts of the IG. The “Conformance” and “Guidance” sections are of particular importance because they contain requirements which can not be expressed in the FHIR artifacts themselves.

Two parts of the “FHIR Artifacts” section are of particular interest. The “US Core Server Capability Statement” defines which FHIR interactions servers must support, which will determine how you can use the FHIR API to retrieve data. The “Profiles and Extensions” section contains links for all of the profiles and extensions defined in US Core, which will determine what the data looks like. When reading a page for a particular profile or extension, be sure to pay attention to the written narrative in addition to the actual definition, as the narrative may contain additional conformance rules which are not able to be expressed in the profile or extension itself.

Bulk Data Access

The Bulk Data Access IG is primarily concerned with defining a workflow for accessing large amounts of FHIR data, whatever that data may be. For this reason, the portions of the IG defining this workflow are much more important than the portions which contain actual FHIR artifacts. The “Export” page is the most important part of the guide, as it defines the actors involved as well as the workflows for initiating, cancelling, and checking the status of a bulk export. The “Authorization” page is also important, although that page’s content has been migrated out of the Bulk Data Access IG and is now part of the SMART App Launch IG. Finally, the “Groups” page describes how to define the Groups which determine which resources are included in bulk data export.

Electronic Case Reporting (eCR)

The eCR IG defines data and workflows to support data submission for public health surveillance. The “Design Considerations” page provides a general overview of the IG’s goals and workflows, and the “eICR Data Elements” page provides a list of the data elements used in the electronic initial case reports (eICRs). The workflows defined in the IG, as well as the FHIR profiles used by each workflow, are described on their own pages:

• Electronic Initial Case Report (eICR) Transaction and Profiles
• Reportability Response (RR) Transaction and Profiles
• Electronic Reporting and Surveillance Distribution (eRSD) Transaction and Profiles

The Artifacts Summary page contains a list of the large number of FHIR artifacts defined by the IG.

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).