What is a FHIR Implementation Guide (IG)

HL7 FHIR has many versions of its own called "Implementation Guides" (IGs). These variations exist for applying it to more focused domains like prior authorization, country-specific requirements, HEDIS-specific requirements, and others. In this blog we will cover the reasons why these variations exist and how to adhere to them.

Explanation of FHIR Implementation Guides:

• FHIR is the most secure, high velocity, detailed medical data format that exists today, having superseded both HL7v2 and HL7v3 - implementation guides (IG's) describe it's field structure and constraints using structured data.

• Just how there were many variations of HL7v3 CDA, there are also many narrow versions of FHIR that require data be stored in a specific way. For example, the USCDI FHIR IG (federal IG of the United States) requires that blood pressure be specified in a narrow way, whereas technically there are multiple ways to structure it in the base IG it is tied to - R4. By this method the federal government does not need to look in multiple places in multiple ways for blood pressures.

• Varying IGs primarily specify:

  • Unique FHIR Resource structures

  • codes permitted in specified fields

  • field validations with regular expressions

  • extensions permitted on specific resources

  • what fields are required, and whether none, one, or multiple entries are permitted

  • dependencies associated with the IG (other IGs / dependencies)

• FHIR IGs may be found on simplifier.net as packaged, structured formatting files and are used to drive the documentation that appears on the main HL7 FHIR website, as well as used to validate FHIR API payloads in systems such as Tenasol's validation engine and HAPI FHIR.

• FHIR IGs will list dependencies - definitions to be used that are not listed in that specific IG. Most commonly this includes:

  • R4 - the standard base IG that includes loose, unconstrained definitions of all resources

  • FHIR Extensions Pack - A set of definitions of what extensions are commonly permitted.

  • Others - other smaller definitions, or IG's that are dependencies of the dependencies.

• IG's are constructed as *.tgz files and made compatible with Node Package Manager (NPM) for html-renderable documentation and validation output. They also may be integrated with python for pydantic validation during resource construction.

Most Common Implementation Guides

1. R4 (Revision 4 Implementation Guide)

R4 is the most heavily used implementation guide to date. It is the 4th revision of FHIR and contains all resources in the loosest sense with the least number of restrictions. Most adopted IG's that are not R4 are based on R4, meaning that if an implementation guide does not specify a resource structure, it simply defaults to using those available in R4.

2. USCDI (United States Core Data for Interoperability)

USCDI is the federal formatting. Organizations such as the CDC, HHS, CMS, and the SSA rely on this standard for interoperability when FHIR is utilized. The above image shows some variations on the main Patient Resource, which include custom extensions, changes in count, and top level information in fields rather than deferment to an R4 child resource (e.g. HumanName is unused for patient name).

3. Da Vinci (HREX/ Health Record Exchange)

Da Vinci exists primarily for Prior Authorization. It is based on USCDI with some additional modifications.

4. Gravity (SDOH Clinical Care)

Gravity is based on the Da Vinci IG (in turn based on USCDI, in turn based on R4). It is used specifically to record social determinants of health and was created to accommodate information that is not inherently specified in any previous IG - information such as income and food availability which are useful to research institutions. This is an important concept, as new data formats such as FHIR may otherwise restrict the availability of such information if it is not able to be included at least in some formalized methodology.

How to Use a FHIR Implementation Guide

There is no one way to use an IG - they exist as a standardized way for the rules to be documented. There are however a large number of systems - including at Tenasol that can make use of these IG's to thoroughly test a FHIR servers incoming and outgoing FHIR data to make sure that it complies with required standards - this makes sure that the client receiving it gets correctly structured data they expect, or similarly allows you to validate that a partner is sending correctly structured data.

Modern systems in interoperability, such as Tenasol, are increasingly using metrics to score partners based on data completeness and structure - a FHIR implementation guide is one such way to do this.

An example of visual validation may be seen on our tool used to view FHIR data. Errors generated from a FHIR IG are classified as:

• Errors (strictly disagree with the IG)

• Warnings (general guidance), and

• Information (notes on where things might be able to be clearer)

Conclusion

FHIR Implementation Guides ultimately exist because healthcare interoperability cannot function reliably with unconstrained flexibility alone. While base FHIR provides a powerful and highly adaptable framework for exchanging medical data, organizations, governments, and research institutions often require much stricter definitions in order to ensure consistency, automation, and large-scale interoperability. Without these constraints, two systems could both produce technically valid FHIR while storing the same clinical information in entirely different ways.

Implementation Guides have become one of the most important components of healthcare data exchange. They allow institutions to standardize terminology, validation rules, required fields, and resource structures for highly specialized use cases such as prior authorization, quality measurement, social determinants of health, and nationwide interoperability initiatives.

Understanding how IGs are layered, validated, and inherited is therefore critical for any organization building modern healthcare technology. A system that supports only “base FHIR” is often insufficient for production interoperability. Instead, successful implementations must understand dependencies, terminology validation, profile constraints, and the operational requirements of the specific IG ecosystem they intend to support.

If you are interested in learning more, contact us.

You can also see our interactive FHIR viewer here.