FHIR Implementation Guide

The core building block of any IG. A Profile constrains a base FHIR resource by tightening cardinalities, restricting terminology bindings, and applying invariants. For example, the US Core Patient Profile mandates that Patient.identifier must include a specific identifier system and that Patient.name is required, whereas the base FHIR spec leaves both optional. Profiles define the precise data structure a system must support to claim conformance.

When a standard FHIR resource lacks a needed data element, an IG defines an Extension. Extensions are custom, non-modifier elements appended to existing resources without breaking base conformance. An IG for oncology might define an extension on Observation to capture a tumor grade or genomic variant allele frequency, data points not present in the core specification. Each extension has a canonical URL for global identification.

An IG binds coded elements to specific ValueSets and CodeSystems to enforce semantic consistency. A ValueSet is a curated list of allowed codes for a field. For instance, a blood pressure IG would bind Observation.code to a ValueSet containing only LOINC codes 8480-6 (Systolic) and 8462-4 (Diastolic). The binding strength—required, extensible, or example—dictates how strictly systems must adhere.

A mandatory resource that declares the functional expectations for systems implementing the IG. A CapabilityStatement specifies which profiles a server must support, which RESTful interactions (e.g., create, search) are required, and which search parameters must be honored. It serves as a contract: a client can read a server's CapabilityStatement to discover exactly what data and operations are available.

IGs define custom SearchParameters to enable querying on elements that are not searchable in the base specification. If a profile defines a critical extension for patient risk score, the IG would include a SearchParameter definition allowing clients to execute GET /Patient?risk-score=gt5. This makes the profiled data operationally accessible via the standard FHIR RESTful API.

A robust IG includes Example instances—concrete, valid JSON or XML resources that demonstrate correct usage. These are not just illustrative; they are tested by the FHIR Validator to guarantee they conform to the profiles. Accompanying narrative documentation explains the clinical workflow context, actor responsibilities, and transaction sequences, bridging the gap between technical specification and real-world implementation.

The atomic building block of an IG. A profile constrains a base FHIR Resource by tightening cardinalities, restricting terminology bindings, and defining extensions. For example, the US Core Patient Profile mandates specific identifier systems and requires a race and ethnicity extension that the base Patient resource does not. Profiles are authored in StructureDefinition resources and are the primary mechanism for enforcing IG-specific data requirements.

The mechanism that links a coded element in a profile to a specific ValueSet, defining the universe of allowed codes. Bindings have a strength that determines enforcement:

• required: only codes from the ValueSet are valid
• extensible: ValueSet codes preferred, others allowed with a warning
• example: ValueSet is illustrative only An IG for a specific domain, like oncology, will bind elements to disease-specific code systems such as SNOMED CT or ICD-O-3.

A FHIR resource that declares the specific capabilities a server or client must support to claim conformance to an IG. It defines:

• RESTful interactions: which operations are mandatory (e.g., read, search-type)
• Search parameters: which query parameters must be supported
• Supported profiles: which resource profiles the system can process A CapabilityStatement is the contract that enables automated conformance testing and client-server negotiation.