Wer den Artikel zum Verhältnis von CDA und FHIR mochte, wird IHE MHD (Mobile access to Health Documents) lieben: MHD ist die pragmatische Antwort auf die Frage, die in Projekten immer wieder kommt:
MHD ist keine „Dokumenten-Ablösung“, sondern eine Brücke: Es nimmt die dokumentenbasierte Realität (Befunde, Arztbriefe, PDF, CDA, Images) ernst – und bringt sie in eine FHIR-kompatible Zugriffswelt.
- Dokumente bleiben (Befundcharakter, Signatur, Narrative, Medienvielfalt) – auch wenn FHIR überall ist.
- IHE MHD modernisiert nicht das Dokumentformat, sondern Zugriff & Metadaten über FHIR.
- DocumentReference macht Dokumente findbar (Typ, Zeitraum, Autor, Status) – nicht nur „downloadbar“.
- Bestes Zielbild: Dokument (PDF/CDA) + FHIR-Extrakte – MHD hält den Dokumentteil interoperabel.
Was ist IHE MHD (Mobile access to Health Documents)?
IHE MHD standardisiert den Zugriff auf Dokumente und Dokumentmetadaten über HL7 FHIR. Entscheidend ist: MHD ist kein neues Dokumentformat, sondern ein Profil und ein Vorgehensmodell, um Dokumente (z. B. PDF, CDA, Bilder) über FHIR interoperabel auffindbar und abrufbar zu machen.
MHD ist kein Dokumentformat, sondern ein FHIR-Zugriffsprofil
MHD schreibt nicht vor, wie ein Dokument intern aufgebaut sein muss. Es definiert vielmehr, wie Dokumente beschrieben (Metadaten), gesucht (Search) und abgerufen (Retrieve) werden – und wie Versionierung/Beziehungen sauber abgebildet werden.
Welche Rolle spielt IHE XDS im Hintergrund?
Viele Landschaften sind historisch durch IHE XDS geprägt (Registry/Repository, Provide & Register, Query, Retrieve). MHD übernimmt die bewährte Dokumentenlogik – und bringt sie in eine moderne, API-basierte FHIR-Welt.
Warum Dokumente trotz FHIR wichtig bleiben (PDF, CDA, Befunde)
FHIR steht für strukturierte Daten, Services und Ressourcen. Im Alltag der Versorgung bleiben Dokumente trotzdem zentral – und zwar nicht aus Nostalgie, sondern aus fachlichen und organisatorischen Gründen:
- Befundcharakter & rechtliche Erwartungen: Ein signierter Arztbrief ist ein abgeschlossenes Dokument.
- Provenance & Nachvollziehbarkeit: Dokumente transportieren Kontext, Narrative, Layout, ggf. Signaturen.
- Medienvielfalt: PDF, CDA-XML, Bilddaten, gescannte Unterlagen – das ist Realität.
- Kommunikationslogik: Viele Prozesse funktionieren als „Übermittlung eines Dokuments“.
Befundcharakter, Signatur, Nachvollziehbarkeit
Ein Dokument ist häufig die Einheit, die medizinisch, organisatorisch und juristisch als „abgeschlossen“ gilt. Genau deshalb ist Versionierung (korrigiert/ersetzt) und Herkunft (Autor/Organisation) so wichtig.
Warum „Dokument übertragen“ weiterhin ein Kernprozess ist
In vielen Workflows ist das Dokument das Kommunikationsobjekt: „Hier ist der Befund/Brief“ – und nicht „Hier sind 20 einzelne Felder, bitte interpretieren“.
Grafik 1: Dokumentenfluss vs. Datenfluss
Links: dokumentenbasierte Kommunikation (Befund/Brief). Rechts: servicebasierte Datenwelt (FHIR-Ressourcen & Queries).
DocumentReference in FHIR: Dokumentmetadaten richtig modellieren
In der FHIR-Welt ist die zentrale Ressource für Dokumente die DocumentReference. Sie ist – vereinfacht – das, was in der XDS-Welt die Dokumentmetadaten waren. MHD setzt genau hier an: DocumentReference wird zum Metadatenanker, der Dokumente interoperabel auffindbar macht.
Welche Metadaten entscheidend sind (Typ, Kategorie, Autor, Zeitraum, Status)
Interoperabilität entsteht nicht durch einen Download-Link, sondern durch belastbare Metadaten: Dokumenttyp und Kategorie, Erstellungszeitraum, Autor/Organisation sowie Status und Versionbeziehungen. Ohne diese Felder ist Suche (und damit Nutzbarkeit) reines Glücksspiel.
Binary vs. Attachment.url: Wo liegt der Dokumentinhalt?
Der Inhalt selbst kann im FHIR-Server als Binary liegen oder extern in einem DMS/Repository – dann verweist die DocumentReference über Attachment.url. Beide Varianten sind valide; entscheidend ist, dass Abruf, Authentifizierung/Autorisierung und Audit sauber zusammenpassen.
Versionierung in FHIR: relatesTo, current vs. superseded
Korrigierte Befunde sind Normalfall. Daher muss klar abbildbar sein, ob ein Dokument ein anderes ersetzt oder ergänzt (relatesTo) – und was „aktuell“ (current) vs. „überholt“ (superseded) ist.
Grafik 2: DocumentReference als Metadatenanker
DocumentReference verbindet Patient, Metadaten und den eigentlichen Inhalt (Binary oder URL) – inklusive Versionbeziehungen.
Dokumente über FHIR finden: Suche statt Download-Link
Ein „Download-Endpoint“ ist noch keine Interoperabilität. Interoperabel wird es, wenn standardisierte Suche möglich ist. Genau das liefert MHD: Dokumente werden nicht nur abrufbar, sondern gezielt auffindbar.
Typische Suchfälle (Entlassbrief, Radiologie, Zeitraum, Organisation)
- Patient = X
- Typ = „Entlassbrief“ oder „Radiologischer Befund“
- Zeitraum = letzte 12 Monate
- Autor/Organisation = Krankenhaus Y
- Status = current/superseded
Metadatenqualität als Voraussetzung für Interoperabilität
Wenn Typ/Kategorie nicht konsequent gepflegt werden, wird Suche unzuverlässig. Daher ist Metadaten-Governance nicht „nice to have“, sondern Kern des Designs.
MHD und CDA: So passt die Dokumentenwelt zur FHIR-API-Welt
Hier schließt sich der Kreis zu „CDA vs. FHIR“: CDA ist ein strukturiertes Dokumentformat (inkl. Narrativ) für „abgeschlossene“ Befunde/Briefe. FHIR ist stark bei granularen Daten und APIs. MHD verbindet beides, indem es den Dokumentzugriff über FHIR standardisiert.
Best Practice: Dokument (PDF/CDA) + strukturierte FHIR-Extrakte
- Primärdokument bleibt PDF/CDA (signiert, vollständig, „rechtssicher“).
- FHIR-Ressourcen ergänzend als Extrakte (z. B. Probleme, Medikation, Allergien).
- MHD sorgt für Metadaten, Auffindbarkeit, Abruf und Versionierung.
Verlinkung & Provenance: Kontext sauber herstellen
Dokument und Extrakte sollten sich gegenseitig referenzieren (z. B. über Provenance/Composition), damit Herkunft, Kontext und Nachvollziehbarkeit erhalten bleiben.
MHD Architekturpattern in der Praxis (Repository, DMS, Hybrid)
Pattern A: Dokument als Binary im FHIR-Server
- FHIR-Server speichert Dokumentinhalt als Binary
- DocumentReference verweist intern darauf
- Pro: Security/Logging zentral · Contra: Speicher/Archivanforderungen
Pattern B: DMS/Repository mit URL-Referenz
- DocumentReference enthält Attachment.url zum DMS/Repository
- FHIR-Server verwaltet Metadaten & Suche
- Pro: nutzt bestehende Archive · Contra: Security/Consent systemübergreifend
Pattern C: Hybrid mit Extrakten (FHIR-Plattform)
- Dokumente im Repository/DMS, Extrakte in einer FHIR-Plattform
- Beidseitige Referenzen (z. B. Provenance/Composition)
- Pro: maximale Nutzbarkeit · Contra: Governance/Synchronisation
Grafik 3: Hybrid-Zielbild – Dokument + FHIR-Extrakte
Dokumente bleiben im Repository/DMS, während FHIR-Extrakte in einer FHIR-Plattform abfragbar werden. MHD verbindet beides.
Häufige Fehler bei IHE MHD Implementierungen (und wie man sie vermeidet)
IDs & Identitätsmanagement
Patienten-IDs, Dokument-IDs, Organisations-IDs: Hier entscheidet sich, ob Systeme zusammenfinden oder nicht. Klare Strategie für systemübergreifende Identitäten (UUID/URI-Schema, Mapping) ist Pflicht.
Versionierung & Ersetzungen
Beziehungen („ersetzt“, „ergänzt“) müssen konsequent abgebildet werden – inklusive Status „current“ vs. „superseded“. Sonst entstehen Dubletten, falsche Trefferlisten und Misstrauen in die Suche.
MimeType/Hash/Integrity
Wer Integrität und Nachvollziehbarkeit ernst nimmt, pflegt mimeType, size und ggf. Hash von Anfang an – nicht „später, wenn Zeit ist“.
Security, Consent, Audit
Dokumente sind häufig sensibler als einzelne Datenpunkte. Zugriffsmatrix nach Kategorien, Audit-Konzept und klare Policy-Enforcement-Punkte (PEP) gehören ins Design.
MHD-Checkliste: So starten Hersteller und Kliniken pragmatisch
- Use Cases festnageln (Dokumenttypen, Suchen, Rollen/Consent)
- Metadaten-Governance definieren (Typ/Kategorie, Autor, Zeitraum, Status/Version)
- Profilkonformität erzwingen (Validator in CI/CD, Testdaten, Negativtests)
- Search-Design testen (Qualität & Performance der Suchen)
- End-to-End Abruf inkl. Security/Audit (auch über Systemgrenzen)
Fazit: IHE MHD macht Dokumente in FHIR-Projekten interoperabel nutzbar
Wer aus der CDA-/Dokumentenwelt kommt, muss Dokumente nicht „wegmodernisieren“, um FHIR ernst zu nehmen. IHE MHD bietet einen sauberen Pfad, Dokumente standardisiert zu beschreiben, auffindbar zu machen, abzurufen und versioniert zu verwalten – und gleichzeitig dort, wo sinnvoll, strukturierte FHIR-Daten ergänzend aufzubauen.