Author: Friedhelm Matten · Topic: HL7 FHIR, IHE MHD, DocumentReference, document interoperability

If you liked the article on the relationship between CDA and FHIR, you will love IHE MHD (Mobile access to Health Documents): MHD is the pragmatic answer to the question that keeps coming up in projects:

MHD is not a “document replacement”, but a bridge: it takes the document-based reality (reports, physician letters, PDF, CDA, images) seriously – and brings it into a FHIR-compatible access world.

What is IHE MHD (Mobile access to Health Documents)?

IHE MHD standardizes access to documents and document metadata via HL7 FHIR. What is decisive: MHD is not a new document format, but a profile and a procedural model to make documents (e.g. PDF, CDA, images) interoperably findable and retrievable via FHIR.

MHD is not a document format, but a FHIR access profile

MHD does not prescribe how a document must be structured internally. Rather, it defines how documents are described (metadata), searched (search), and retrieved (retrieve) – and how versioning/relationships are mapped cleanly.

What role does IHE XDS play in the background?

Many landscapes have historically been shaped by IHE XDS (registry/repository, provide & register, query, retrieve). MHD adopts the proven document logic – and brings it into a modern, API-based FHIR world.

Why documents remain important despite FHIR (PDF, CDA, reports)

FHIR stands for structured data, services, and resources. In everyday care, documents nevertheless remain central – and not out of nostalgia, but for professional and organizational reasons:

• Report character & legal expectations: a signed physician letter is a finalized document.
• Provenance & traceability: documents carry context, narrative, layout, and possibly signatures.
• Media variety: PDF, CDA XML, image data, scanned records – that is reality.
• Communication logic: many processes work as “transmitting a document”.

Report character, signature, traceability

A document is often the unit considered “finalized” medically, organizationally, and legally. That is precisely why versioning (corrected/replaced) and origin (author/organization) are so important.

Why “transmitting a document” remains a core process

In many workflows the document is the communication object: “Here is the report/letter” – and not “Here are 20 individual fields, please interpret”.

DocumentReference in FHIR: modeling document metadata correctly

In the FHIR world, the central resource for documents is the DocumentReference. Simplified, it is what document metadata used to be in the XDS world. MHD starts exactly here: DocumentReference becomes the metadata anchor that makes documents interoperably findable.

Which metadata is decisive (type, category, author, period, status)

Interoperability does not arise from a download link, but from robust metadata: document type and category, creation period, author/organization, as well as status and version relationships. Without these fields, search (and thus usability) is pure gambling.

Binary vs. Attachment.url: where does the document content reside?

The content itself can reside in the FHIR server as a Binary or externally in a DMS/repository – in which case the DocumentReference points to it via Attachment.url. Both variants are valid; what is decisive is that retrieval, authentication/authorization, and audit fit together cleanly.

Versioning in FHIR: relatesTo, current vs. superseded

Corrected reports are the normal case. Therefore it must be clearly representable whether a document replaces or appends another (relatesTo) – and what is “current” vs. “superseded”.

Finding documents via FHIR: search instead of a download link

A “download endpoint” is not yet interoperability. It becomes interoperable when standardized search is possible. That is exactly what MHD provides: documents become not only retrievable, but specifically findable.

Typical search cases (discharge letter, radiology, period, organization)

• Patient = X
• Type = “discharge letter” or “radiology report”
• Period = last 12 months
• Author/organization = hospital Y
• Status = current/superseded

Metadata quality as a prerequisite for interoperability

If type/category are not maintained consistently, search becomes unreliable. Therefore metadata governance is not “nice to have”, but the core of the design.

MHD and CDA: how the document world fits the FHIR API world

Here the circle to “CDA vs. FHIR” closes: CDA is a structured document format (incl. narrative) for “finalized” reports/letters. FHIR is strong at granular data and APIs. MHD connects both by standardizing document access via FHIR.

Best practice: document (PDF/CDA) + structured FHIR extracts

1. The primary document stays PDF/CDA (signed, complete, “legally robust”).
2. FHIR resources complement it as extracts (e.g. problems, medication, allergies).
3. MHD provides metadata, findability, retrieval, and versioning.

Linking & provenance: establishing context cleanly

The document and the extracts should reference each other (e.g. via Provenance/Composition), so that origin, context, and traceability are preserved.

MHD architecture patterns in practice (repository, DMS, hybrid)

Pattern A: document as Binary in the FHIR server

• The FHIR server stores the document content as a Binary
• DocumentReference points to it internally
• Pro: security/logging centralized · Con: storage/archiving requirements

Pattern B: DMS/repository with a URL reference

• DocumentReference contains an Attachment.url to the DMS/repository
• The FHIR server manages metadata & search
• Pro: reuses existing archives · Con: security/consent across systems

Pattern C: hybrid with extracts (FHIR platform)

• Documents in the repository/DMS, extracts in a FHIR platform
• Mutual references (e.g. Provenance/Composition)
• Pro: maximum usability · Con: governance/synchronization

Common mistakes in IHE MHD implementations (and how to avoid them)

IDs & identity management

Patient IDs, document IDs, organization IDs: this is where it is decided whether systems find each other or not. A clear strategy for cross-system identities (UUID/URI scheme, mapping) is mandatory.

Versioning & replacements

Relationships (“replaces”, “appends”) must be mapped consistently – including status “current” vs. “superseded”. Otherwise duplicates, incorrect result lists, and distrust of the search arise.

MIME type/hash/integrity

Anyone who takes integrity and traceability seriously maintains mimeType, size, and possibly a hash from the start – not “later, when there is time”.

Security, consent, audit

Documents are often more sensitive than individual data points. An access matrix by category, an audit concept, and clear policy enforcement points (PEP) belong in the design.

MHD checklist: how vendors and hospitals start pragmatically

Conclusion: IHE MHD makes documents interoperably usable in FHIR projects

Anyone coming from the CDA/document world does not have to “modernize documents away” to take FHIR seriously. IHE MHD offers a clean path to describe documents in a standardized way, make them findable, retrieve them, and manage them with versioning – while, where it makes sense, building up structured FHIR data in addition.

If you would like to assess this topic in your project or set up an MHD architecture pragmatically: get in touch – we support with the target picture, profiling, test strategy, and implementation governance.