FHIR Resource

Each FHIR resource represents a single, coherent clinical or administrative concept—such as a Patient, Observation, or MedicationRequest—with a strict scope that prevents ambiguity. Resources contain only the data elements relevant to that concept, ensuring modularity. For example, a patient's demographic details live in the Patient resource, while their lab results reside in separate Observation resources linked by references. This separation of concerns allows systems to exchange only the data they need without parsing monolithic documents.

Every FHIR resource carries a standardized set of metadata fields that enable consistent management across disparate systems:

• id: A server-assigned logical identifier unique within that server
• meta: Contains version tracking, last updated timestamp, and profile claims
• implicitRules: References the rules that govern how the resource was constructed
• language: Specifies the language of the human-readable text portions This uniform header ensures that any FHIR-aware system can immediately understand the provenance and versioning of a resource without domain-specific logic.

Every resource must include an XHTML text element that provides a human-readable summary of the resource's clinical content. This narrative serves as a safety net: if a receiving system cannot fully parse the structured data, it can still display the narrative to a clinician. The narrative can be generated by the server, extensions where the client provides it, or additional where the client supplements a generated narrative. This requirement bridges the gap between machine-processable data and human clinical decision-making.

FHIR resources are designed to be extended without breaking conformance to the base specification. The extension mechanism allows implementers to add custom data elements anywhere in a resource structure. Extensions are identified by a canonical URL and can be simple (a single value) or complex (nested structures). When a particular extension pattern proves broadly useful, it may be promoted to a modifierExtension—which changes the meaning of the resource itself—or eventually incorporated into the base resource definition in a future FHIR version.

Resources connect to one another through Reference elements, which contain a URL-like pointer to another resource. A MedicationRequest references a Patient for the subject and a Practitioner for the prescriber. References can be:

• Literal: A direct URL to a specific resource on a server
• Logical: An identifier-based reference resolved through a registry
• Contained: The referenced resource is embedded inline within the parent This graph of references enables rich clinical context without duplicating data across resources.

Coded elements within a resource are bound to a ValueSet that defines the allowed codes for that element. The binding strength specifies how strictly the code must match:

• required: Only codes from the specified ValueSet are valid
• extensible: Codes from the ValueSet are preferred, but others may be used
• example: The ValueSet is merely a suggestion
• preferred: The ValueSet is recommended but not enforced This mechanism ensures semantic consistency while allowing flexibility for local use cases.