Profile (FHIR Profile)

fhir technical technical fhirinteroperabilityhealthcare
Source: HL7 System: http://hl7.org/fhir Code: Profile Reviewed: 08/01/2026 License: CC-BY-4.0

Profile (FHIR Profile)

One-sentence definition: A FHIR Profile is a StructureDefinition that constrains or extends a base FHIR resource to define how it must be used in a specific context — mandating required elements, restricting value sets, and declaring extensions — so that conforming implementations exchange data consistently.

Full Definition

FHIR base resources are intentionally permissive. Most elements are optional, value set bindings are loose, and the spec accommodates the widest possible range of implementations. This flexibility is necessary for global adoption, but it creates a problem: two FHIR-compliant systems can exchange Patient resources that are technically valid FHIR but structurally incompatible — different identifier systems, different name representations, missing data fields required for reporting.

A Profile solves this by tightening the flexibility for a specific context. It declares: in this situation, these elements are required, these value sets must be used, and this extension must be present. A resource “claims” conformance to a profile by listing the profile’s canonical URL in meta.profile.

Technically, a Profile is a FHIR StructureDefinition resource with derivation: constraint. It is identified by a canonical URL — a globally unique, stable identifier like http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient. That URL is both the identifier and the documentation pointer: navigate to it and you find the full profile definition.

Implementation details: This entry covers the definition and purpose of profiles. For how profiles work (cardinality, Must Support, value set binding, extensions), StructureDefinition authoring, validation tools, and practical examples, see the canonical reference → FHIR Profiling.

Context and Usage

Where This Term Appears

Profiles appear wherever FHIR conformance is specified or enforced:

  • Implementation Guide (IG) documentation — every IG defines the profiles it requires
  • CapabilityStatement — servers declare which profiles they support for each resource type
  • Validation error messages: “Resource does not conform to profile http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient”
  • meta.profile in resource payloads — the resource self-identifies which profiles it claims to satisfy
  • ONC certification criteria and CMS rule text — regulatory programs name profiles by canonical URL
  • API documentation and integration contracts

Common Usage Examples

In conversation: “We validate against the US Core Patient profile before storing — if it doesn’t pass, we reject it at the gateway.”

In documentation: “Resources returned by this endpoint conform to the US Core Observation Vital Signs profile.”

In technical contexts — a Patient resource claiming US Core conformance:

{
  "resourceType": "Patient",
  "id": "example",
  "meta": {
    "profile": [
      "http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"
    ]
  },
  "identifier": [
    {
      "system": "http://hospital.example.org/mrn",
      "value": "MRN-00456"
    }
  ],
  "name": [
    {
      "family": "Jones",
      "given": ["Marcus"]
    }
  ],
  "gender": "male",
  "birthDate": "1972-09-30"
}

Why FHIR Profiles Exist

Without profiles, “FHIR-compliant” is almost meaningless for interoperability. A Patient resource is technically valid FHIR if it has resourceType: Patient and nothing else — the base spec requires almost nothing. Two systems can both pass base FHIR validation and still fail to exchange usable data because one sends race/ethnicity data and the other doesn’t, or one uses SNOMED CT for conditions while the other uses ICD-10, or one includes a birth date and the other treats it as optional.

Profiles are the mechanism that transforms “FHIR-compliant” into “US Core-compliant” or “mCODE-compliant.” They encode the shared agreement — the precise structural and vocabulary requirements — that makes actual interoperability possible between specific systems in a specific context.

Profile Types

National Profiles (US Core, UK Core, AU Base)

National profiles define the baseline for health data exchange within a jurisdiction. Examples:

  • US Core — the US national profile set, required by ONC certification; defines profiles for Patient, Observation (lab, vital signs, clinical notes), Condition, MedicationRequest, and many others
  • UK Core — NHS England’s national FHIR profile set for England
  • AU Base — Australian national baseline profiles maintained by HL7 Australia
  • CA Core — Canadian national baseline profiles

These are typically mandated by regulation or certification programs. They form the floor that all implementations in a jurisdiction must meet.

Domain-Specific Profiles

Domain-specific Implementation Guides layer profiles on top of national profiles for a clinical use case:

  • mCODE — minimal Common Oncology Data Elements; profiles for cancer diagnosis, treatment, and outcomes
  • Da Vinci PDex — payer data exchange; profiles for payer-to-payer and provider-to-payer data sharing
  • US VRDR — vital records and death reporting; profiles for mortality data
  • QI-Core — Quality Improvement core profiles used for CMS quality measure reporting

A system implementing mCODE must also meet US Core requirements, since mCODE profiles build on US Core.

Organizational Profiles

Individual hospitals, payer organizations, or health systems may define internal profiles for their own FHIR server implementation. These express local data requirements beyond what a national IG mandates — for instance, requiring an internal patient identifier type, or restricting a medication coding system to the organization’s formulary. Organizational profiles are opaque to external systems but valid FHIR.

Profiles and FHIR Versions

Profiles are version-specific. A US Core R4 profile is a different StructureDefinition than a US Core R5 profile, even if they constrain the same logical concept. The canonical URLs differ between versions, and the underlying resource structures may differ too.

Mixing FHIR versions in a pipeline is a common source of validation failures. An R4 server validating against an R5 profile, or an R5 client sending resources to an R4 server, will encounter errors. Most production deployments today run FHIR R4; R5 adoption is growing but not yet dominant.

Relationship to Other Terms

  • FHIR — The standard that defines profiling as a mechanism
  • HL7 — The organization that maintains FHIR and publishes key profiles like US Core
  • Resource — The base resource type that a profile constrains
  • Extension — Profiles declare which extensions are allowed or required

Common Misconceptions

Misconception 1: Profiles are Optional

  • Incorrect belief: Profiles are nice-to-have documentation; real interoperability just needs FHIR compliance.
  • Reality: For regulated use cases, profiles are legally required. ONC certification requires US Core profile conformance — a system that passes base FHIR validation but fails US Core profiles is not ONC-certifiable. CMS quality programs require QI-Core. A system claiming US Core compliance that ignores its profiles is not compliant, regardless of base FHIR validity.
  • Why it matters: Integration contracts and procurement requirements should reference specific profiles and versions, not just “FHIR support.” Base FHIR compliance alone provides no structural guarantee that data will be usable.

Misconception 2: Profiles Guarantee Interoperability

  • Incorrect belief: If both systems claim conformance to the same profile, data will flow correctly between them.
  • Reality: Profiles ensure structural conformance — the right elements are present with the right cardinalities and value sets. They don’t guarantee semantic agreement on edge cases, extension interpretation, search parameter support, or operational behavior. Two systems can both be “US Core conformant” and still fail to exchange certain data correctly due to different interpretations of Must Support, different extension handling, or different search parameter implementations.
  • Why it matters: Profile conformance is a necessary but not sufficient condition for interoperability. End-to-end testing between specific implementations is still required. Connectathons and Inferno test runs expose real-world gaps that profile validation alone won’t catch.

Why Profiles Matter

Profiles are how the FHIR community transforms a flexible international standard into the specific, actionable agreements that real-world interoperability requires. Without profiles, every integration is a negotiation. With profiles, there is a shared, documented, testable specification that both sides can validate against independently.

For anyone building or consuming FHIR APIs in a regulated context, the relevant profiles are non-negotiable requirements — not implementation preferences. Knowing which profiles apply, what they require, and how to validate against them is core competency for FHIR implementation work.

Cross-References

  • FHIR — The standard that defines profiling
  • HL7 — The organization that maintains FHIR and publishes US Core
  • Resource — The base resource type that profiles constrain
  • Extension — How profiles add data beyond base resource definitions

Last reviewed: February 15, 2026 Definition authority: HL7 International Content status: Canonical reference