FHIR Profile

The foundational profile for representing a patient in the United States, mandated by the ONC Cures Act for certified EHR systems. It constrains the base Patient resource to ensure consistent demographic data exchange.

• Must Support: Requires support for specific race, ethnicity, and birth sex extensions.
• Identifier: Mandates the use of standard identifier systems like Medical Record Number (MRN) and Social Security Number (SSN).
• Communication: Profiles the Patient.communication element to include a language code and a proficiency level, enabling language-appropriate care.

A profile on the Claim resource designed to automate the prior authorization workflow between providers and payers. It standardizes the clinical data submitted to support a medical necessity review.

• Clinical Evidence: Adds extensions to attach structured clinical data, such as QuestionnaireResponse resources, directly to the claim.
• Service Line Detail: Profiles Claim.item to require specific procedure codes (CPT/HCPCS) and diagnosis pointers.
• Supporting Info: Constrains Claim.supportingInfo to categorize submitted documents (e.g., clinical notes, lab results) using a defined value set, enabling automated parsing.

A globally harmonized profile on the Observation resource for representing laboratory results in a cross-border patient summary. It ensures a clinician in any country can interpret a result's semantics.

• Universal Coding: Mandates the use of LOINC for the Observation.code to identify the analyte being measured.
• UCUM Units: Constrains Observation.valueQuantity.unit to use the Unified Code for Units of Measure (UCUM) syntax, eliminating unit ambiguity.
• Result Status: Tightly binds Observation.status to a small, definitive value set (final, amended, corrected) to clearly communicate the result's lifecycle state.

A profile on the PractitionerRole resource used across multiple Da Vinci guides to standardize the representation of a clinician's role and contact information for care coordination.

• Role Codification: Mandates a binding to the NUCC Health Care Provider Taxonomy value set for the PractitionerRole.code to precisely define a provider's specialty.
• Digital Contact: Profiles the PractitionerRole.telecom element to require standard extensions for Direct Secure Messaging addresses and FHIR server endpoint URLs.
• Network Participation: Adds an extension to reference the specific health plan network or contract a provider is operating under for a given encounter.

A profile on the Patient resource used by payers in the Payer Data Exchange (PDex) guide for member identification and matching. It adapts the patient resource for payer-specific administrative contexts.

• Coverage Linkage: Mandates the inclusion of a Patient.identifier for the Member ID to link the administrative record to a specific health plan coverage.
• Administrative Gender: Constrains Patient.gender to the administrative gender codes required by payer systems, distinct from clinical gender identity extensions.
• Matching Constraints: Defines invariants that require a combination of identifier, name, and birth date to be present, ensuring sufficient data for probabilistic member matching algorithms.

A profile on the AdverseEvent resource from the Quality Improvement Core (QICore) Implementation Guide, designed to support electronic clinical quality measure (eCQM) calculation.

• Causality Assessment: Adds an extension to capture the clinician's assessment of whether a suspected agent caused the event, a critical element for quality reporting.
• Seriousness Criteria: Profiles AdverseEvent.seriousness to use a defined value set aligning with regulatory reporting standards for serious adverse events.
• Contextual Linking: Mandates references to the associated Encounter and MedicationAdministration or Immunization resources, providing the full clinical context needed for measure logic.

The primary mechanism for adding custom attributes to a profile when the base resource definition is insufficient. Extensions allow implementers to model data elements not covered by the core specification without breaking conformance. A profile formally slices and constrains which extensions are required or permitted.

• Must Support: Profiles flag critical extensions that systems must be capable of processing.
• Modifier Extensions: A special class of extensions that change the fundamental meaning of an element and must be understood by receivers.
• URL Identity: Every extension is uniquely identified by a canonical URL, ensuring unambiguous definition across disparate systems.

A published document that bundles a coherent set of profiles, extensions, value sets, and narrative rules to solve a specific interoperability problem. An IG is the vehicle for distributing profiles and their supporting artifacts.

• Canonical Home: Profiles are defined and published within an IG, which provides the authoritative context for their use.
• CapabilityStatements: IGs include statements that define which profiles a server or client must support for a given role.
• Examples: Every IG contains instance examples that demonstrate valid data conforming to the defined profiles.

A software tool that programmatically checks whether a resource instance conforms to the constraints defined in one or more profiles. Validation is the enforcement mechanism that turns a profile from a passive document into an active contract.

• Constraint Checking: Validates cardinality, invariants, slicing rules, and terminology bindings.
• StructureDefinition Engine: The validator parses the StructureDefinition resource that formally represents a profile.
• Outcome Reporting: Returns an OperationOutcome resource detailing each error and warning location with a line and column.

The mechanism within a profile that links a coded element to a specific ValueSet, defining the exact set of allowed codes. The binding strength dictates how strictly a system must adhere to the defined code set.

• Required: Only codes from the bound ValueSet are allowed; any other code is an error.
• Extensible: Codes from the ValueSet are preferred, but other codes may be used if no suitable concept exists.
• Example: The ValueSet is merely a suggestion with no formal enforcement.
• Preferred: Systems should use the bound codes but are not strictly required to do so.

A concise, text-based authoring language designed to make defining profiles faster and less error-prone than editing raw XML or JSON StructureDefinitions. FSH is compiled into the formal FHIR definitions that validators consume.

• Human-Authorable: Uses a clean syntax with keywords like Profile, Parent, Title, and * for element rules.
• SUSHI Compiler: The reference compiler that translates .fsh files into the standard FHIR IG publication format.
• Differential Focus: Authors describe only the constraints and changes relative to the base resource, not the entire definition.

The mandatory FHIR Implementation Guide for the United States, defining the minimum conformance requirements for accessing patient data. It is a concrete, real-world example of a set of profiles that constrain base FHIR resources for a national jurisdiction.

• ONC Mandate: Certified EHR systems must support the US Core profiles for interoperability.
• Foundational Profiles: Defines profiles for Patient, Observation, Condition, MedicationRequest, and other common resources.
• Profile Inheritance: Many domain-specific US IGs, like USCDI-aligned guides, derive their profiles by further constraining US Core profiles.