A FHIR Document is a curated, persistent snapshot of a patient's clinical state at a specific point in time, assembled by bundling a Composition resource—which acts as the document's index and narrative structure—with all referenced Patient, Practitioner, Observation, and other resources into a single, signed FHIR Bundle of type document. This architecture ensures the document remains a complete, self-authenticating unit that can be rendered exactly as the author intended, independent of any source system.
Glossary
FHIR Document
A persistent, signed, and human-readable clinical document composed of a Composition resource bundled with all the supporting resources it references.
CLINICAL DOCUMENT ARCHITECTURE
What is a FHIR Document?
A FHIR Document is a persistent, signed, and human-readable clinical document composed of a Composition resource bundled with all the supporting resources it references, forming a self-contained, immutable information package.
Unlike a dynamic FHIR Resource accessed via a RESTful API, a document is an immutable information object designed for long-term persistence, legal record-keeping, and cross-enterprise exchange. The Composition resource provides the clinical context, section headings, and attestation, while the enclosing Bundle guarantees referential integrity, and a digital signature ensures non-repudiation, making it the FHIR equivalent of a Clinical Document Architecture (CDA) document.
ANATOMY OF A PERSISTENT CLINICAL RECORD
Core Characteristics of a FHIR Document
A FHIR Document is a curated, signed bundle of resources that represents a coherent clinical statement with a fixed presentation form. It is designed for long-term persistence, legal attestation, and human readability while remaining fully computable.
01
Composition as the Indexing Root
The Composition resource is the mandatory entry point that organizes the document's narrative. It defines the document's type (e.g., Discharge Summary), author, attester, and subject, and structures the content into explicit sections. Each section references a Bundle entry containing the clinical data, such as an Observation or MedicationStatement, ensuring a single coherent clinical statement.
Composition
Required Root Resource
02
Cryptographic Digital Signature
A FHIR Document is immutable and non-repudiable because the entire Bundle is signed using JSON Web Signature (JWS) or XML Signature. The signature is applied by the document's author or verifier, ensuring that any subsequent modification to the content—including the narrative text or attached resources—invalidates the signature. This provides a legal attestation mechanism for clinical records.
JWS
Standard Signature Format
03
Fixed Presentation Form
Unlike a transactional API response, a FHIR Document has a persistent presentation context. The Composition resource contains XHTML narrative in each section, representing the exact human-readable rendering intended by the author. This narrative is not dynamically generated; it is a stored, fixed artifact that must be displayed as-is, ensuring consistent clinical interpretation across different systems and time.
04
Self-Contained Bundle Architecture
The document is packaged as a FHIR Bundle of type document. This bundle must be self-contained, meaning all resources referenced by the Composition—such as the Patient, Practitioner, and all clinical Observations—are included inline. This design ensures the document remains a complete, standalone record that can be validated and rendered without external server queries, critical for archival and legal discovery.
document
Required Bundle Type
05
Strict Conformance to a Document Profile
A FHIR Document must declare conformance to a specific Document Profile via the Composition's meta.profile element. This profile, often defined by an Implementation Guide like US Core or an IHE profile, constrains the required sections, coded terminologies, and resource types. Validators enforce these constraints to ensure the document meets the exact structural and semantic requirements for a specific clinical use case.
06
Human-Readable Narrative Requirement
Every resource within the document bundle must contain a human-readable narrative in its text element. This is not optional for documents. The narrative represents the clinical content as the author intended it to be viewed, bridging the gap between raw structured data and clinical communication. The text.status must be generated or extensions to confirm the narrative reflects the structured data.
text.div
Mandatory XHTML Element
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.
Enterprise searchRAGPermissions
Read more
Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.
AI agentsWorkflow automationGovernance
Read more
Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
AI integrationDecision supportModel routing
Read moreFHIR DOCUMENT DEEP DIVE
Frequently Asked Questions
Clarifying the structure, purpose, and technical mechanics of the FHIR Document, a cornerstone of persistent clinical information exchange.
A FHIR Document is a persistent, signed, and human-readable clinical document composed of a Composition resource bundled with all the supporting resources it references. It is designed to be a complete, contextually self-contained snapshot of a patient's health record at a specific point in time, similar to a PDF or CDA document. Unlike a transient FHIR message, which represents a real-time event trigger, a FHIR Document is immutable and intended for long-term persistence, legal record-keeping, and cross-enterprise exchange. The document's integrity is ensured through a digital signature, and its narrative is rendered via the Composition.text element, guaranteeing human readability even without full parsing of the structured data.
About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
LinkedIn
Limited slotsGet a Free AI Consultation
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us