Kurze Antwort: Gesundheitsdaten bewegen sich durch vier Ebenen von Standards. Austauschstandards übertragen die Daten zwischen Systemen: HL7 v2-Nachrichten, CDA-Dokumente, FHIR-Ressourcen und DICOM für Bilder. Modellierungs- und Speicherstandards legen fest, wie ein Datensatz innerhalb eines Systems strukturiert ist: openEHR für klinische Datensätze, OMOP für Forschungsdatenbanken. Terminologien geben jedem Konzept einen Code, den beide Seiten verstehen: SNOMED CT, LOINC, ICD, ATC, UCUM, RxNorm. Identitäts- und Sicherheitsstandards legen fest, wer was lesen darf: OAuth 2.0 und SMART on FHIR, plus IHE-Profile, die all das zu getesteten Rezepten kombinieren. Niemand verwendet nur einen; ein Krankenhaus betreibt typischerweise alle vier Ebenen gleichzeitig.
Die Karte
Standards für die Gesundheitsinteroperabilität bilden vier Ebenen. Austauschstandards (HL7 v2, CDA, FHIR, DICOM und DICOMweb) bewegen Daten zwischen Systemen, und IHE-Profile kombinieren sie zu getesteten Rezepten. openEHR strukturiert die gespeicherte Akte und OMOP strukturiert Forschungsdatenbanken. Terminologien wie SNOMED CT und LOINC sowie Identitätsstandards wie SMART on FHIR werden in all diesen verwendet.
| Ebene | Standard | Was es ist | Wo man es 2026 trifft |
|---|---|---|---|
| Austausch | HL7 v2 | Pipe-getrennte Nachrichten (ADT, ORU, ORM, SIU) über MLLP | Innerhalb von Krankenhäusern: Aufnahmen, Laborergebnisse, Bestellungen, Terminplanung. Immer noch die häufigste Schnittstelle |
| Austausch | CDA / C-CDA | XML-klinische Dokumente mit einem menschenlesbaren Teil und kodierten Einträgen | Entlassungszusammenfassungen, Überweisungsschreiben, der US C-CDA, grenzüberschreitende Zusammenfassungen in MyHealth@EU |
| Austausch | FHIR (R4, R4B, R5) | Web-Ressourcen (Patient, Observation, Condition…) über REST und JSON | Patienten-Apps, nationale APIs, EHR-APIs, US Core, das EHDS-Austauschformat |
| Austausch | DICOM und DICOMweb | Bildobjekte mit eingebetteten Metadaten; DICOMweb ist seine REST-Schnittstelle | Jeder Scanner, PACS und Radiologie-Viewer; Web-Viewer verwenden DICOMweb |
| Rezepte | IHE-Profile | Getestete Kombinationen der oben genannten für einen Anwendungsfall (XDS, PIX/PDQ, XCA, SWF) | Dokumentenaustausch zwischen Krankenhäusern und Regionen, Patientenidentität, Radiologie-Workflow |
| Speicherung | openEHR | Archetypen-basierter klinischer Datenmodell für den Datensatz selbst | Krankenhaus- und nationale EHR-Plattformen in Teilen Europas, Skandinaviens, Brasiliens |
| Forschung | OMOP CDM | Ein gemeinsames relationales Modell für Beobachtungsforschung | Forschungsnetzwerke, Real-World-Evidenz, EHDS-Sekundärnutzung |
| Terminologie | SNOMED CT, LOINC, ICD-10/11, ATC, RxNorm, UCUM | Codes für Befunde, Tests, Diagnosen, Medikamente, Einheiten | Innerhalb jedes der oben genannten Standards |
| Identität | OAuth 2.0, OpenID Connect, SMART on FHIR, IHE XUA | Wer der Benutzer ist und worauf die App zugreifen darf | Jede patientenorientierte App und jede EHR-App-Plattform |
Wie die Ebenen zusammenpassen
Die Ebenen der Standards für die Gesundheitsinteroperabilität passen zusammen, indem jede eine Aufgabe im selben Workflow erfüllt: Eine HL7 v2-Nachricht transportiert eine Laboranforderung, LOINC und UCUM kodieren das Ergebnis, eine openEHR-Plattform speichert es, eine FHIR-API stellt es nach einem SMART on FHIR-Login einer Patienten-App zur Verfügung, und ein CDA-Dokument teilt es mit einem anderen Krankenhaus.
Ein Bluttest zeigt an einem Nachmittag alle vier Ebenen. Die Bestellung verlässt die Station als HL7 v2 ORM-Nachricht (Austausch). Das Ergebnis des Analysators kommt als HL7 v2 ORU zurück, wobei der Test in LOINC und die Einheit in UCUM kodiert ist (Terminologie). Das Krankenhaus speichert es in seiner eigenen Datenbank, vielleicht einer openEHR-Plattform (Speicherung). Die Patienten-App liest es über eine FHIR-API als Observation, nachdem sich der Patient mit SMART on FHIR (Identität) angemeldet hat. Wenn das Krankenhaus den vollständigen Bericht mit einem anderen Krankenhaus teilt, kann es dies als CDA-Dokument über ein IHE XDS-Register tun. Wenn das Ergebnis später in eine Forschungskohorte aufgenommen wird, wird es in OMOP umgewandelt.
Die Standards sind keine Konkurrenten. Jeder wurde für eine andere Aufgabe entwickelt, und der Ersatz eines durch einen anderen bedeutet normalerweise den Wiederaufbau von etwas, das bereits funktioniert.
Welchen brauchen Sie?
Welchen Standard für die Gesundheitsinteroperabilität Sie benötigen, hängt von der Aufgabe ab: FHIR R4 mit SMART on FHIR für Patienten- oder Kliniker-Apps, HL7 v2 für die Anbindung an bestehende Krankenhaussysteme, DICOM und DICOMweb für Bilder, CDA- oder FHIR-Dokumente für ganze Dokumente, openEHR für die langfristige Speicherung von Akten, OMOP für die Forschung und IHE-Profile, wenn zwei Systeme sich identisch verhalten müssen.
- Sie entwickeln eine App für Patienten oder Kliniker: FHIR R4, mit den Profilen Ihres Marktes (Implementierungsleitfäden), SMART on FHIR für die Anmeldung.
- Sie verbinden sich mit den bestehenden Systemen eines Krankenhauses: Erwarten Sie zuerst HL7 v2; FHIR, wo der Anbieter es anbietet. Siehe HL7 v2-Nachrichten erklärt.
- Sie verarbeiten Bilder: DICOM für Speicherung und Übertragung, DICOMweb für alles im Browser, FHIR ImagingStudy nur für die Metadaten. Siehe DICOMweb erklärt und ImagingStudy vs DICOMweb.
- Sie tauschen ganze Dokumente aus (Zusammenfassungen, Briefe): CDA, wo es vorgeschrieben ist, FHIR-Dokumente (ein Bundle vom Typ
document), wo Sie wählen können. Siehe CDA und C-CDA erklärt. - Sie entwerfen, wie ein Datensatz über Jahrzehnte gespeichert wird: openEHR, mit FHIR als Austauschschicht. Siehe openEHR vs FHIR.
- Sie führen Forschung an vielen Datensätzen durch: OMOP, mit FHIR als Quelle. Siehe Sekundärnutzung von Gesundheitsdaten.
- Sie benötigen, dass zwei Systeme gleich funktionieren: Wählen Sie das IHE-Profil für Ihren Anwendungsfall und testen Sie dagegen.
Wo Anpheros sitzt
Die Anpheros-Plattform sitzt in der Austauschschicht der Standards-Map als FHIR R4-Server mit OAuth 2.0-Zugang und Webhooks für Änderungsbenachrichtigungen. Sie empfängt Laborergebnisse über einen Konnektor von HL7 v2 ORU, CSV oder JSON. Sie speichert keine DICOM-Bilder und bietet keinen CDS Hooks-Dienst an; diese verbleiben in den Krankenhaussystemen.
Anpheros Platform ist ein FHIR R4-Server mit den Ressourcen, die ein patientenzentrierter Datensatz benötigt (Patient, Observation, Condition, MedicationStatement, DocumentReference, DiagnosticReport, Immunization, Consent, Provenance und andere), OAuth 2.0 für den Zugriff und Webhooks für Änderungsbenachrichtigungen. Laborergebnisse kommen über den Labor-Konnektor von HL7 v2 ORU, CSV oder JSON. Es speichert keine DICOM-Bilder und bietet keinen CDS Hooks-Dienst an; diese bleiben in den Systemen des Krankenhauses, und der Datensatz verweist auf sie.
Lesereihenfolge
Eine gute Lesereihenfolge für Standards der Gesundheitsinteroperabilität beginnt damit, was FHIR ist und wie es sich von HL7 v2 unterscheidet, dann die FHIR Observation-Ressource, dann die darin verwendeten Terminologien LOINC und SNOMED CT, dann DICOMweb für Bilder, CDA für Dokumente und schließlich openEHR im Vergleich zu FHIR, wie Akten gespeichert werden.
Wenn Sie neu in diesem Bereich sind: Was FHIR ist → HL7 vs FHIR → FHIR Observation → LOINC und SNOMED CT → DICOMweb → CDA → openEHR vs FHIR.
Verwandte Seiten
- HL7 vs FHIR
- HL7 v2-Nachrichten erklärt
- CDA und C-CDA erklärt
- DICOMweb erklärt
- openEHR vs FHIR
- FHIR Implementierungsleitfäden
- FHIR R4 vs R5
- Was ist ein LOINC-Code?
- Was ist SNOMED CT?
- DICOM vs FHIR für Entwickler
- FHIR-Profile und Erweiterungen erklärt
- FHIR-Terminologieserver erklärt
- Gesundheitsdaten-Regulierungsübersicht
- Nationale elektronische Gesundheitsakten in Europa und den USA
- Integration von Krankenhaussystemen erklärt
- KI auf medizinischen Daten
- Sekundärnutzung von Gesundheitsdaten
- Sicherheit und Identität in Gesundheits-Apps
Quellen
- HL7 International: Standards
- HL7 FHIR R4 Spezifikation
- DICOM-Standard, aktuelle Ausgabe
- IHE Technische Frameworks
- openEHR Spezifikationen
- OHDSI OMOP Common Data Model
- SMART App Launch
Häufige Fragen
Ersetzt FHIR alle anderen Standards?
Nein. FHIR ersetzt benutzerdefinierte APIs und langsam auch einige CDA-Dokumentenaustausche. HL7 v2 bleibt das Arbeitspferd innerhalb von Krankenhäusern, DICOM bleibt der einzige Standard für Bilder, und openEHR und OMOP beantworten Fragen (Speicherung, Forschung), für die FHIR nicht konzipiert wurde.
Was ist der Unterschied zwischen einem Standard und einem IHE-Profil?
Ein Standard wie FHIR oder DICOM definiert Bausteine. Ein IHE-Profil wählt spezifische Bausteine aus, legt deren Optionen fest und gibt genau an, wie Systeme sie für eine Aufgabe verwenden müssen, damit zwei Anbieter, die beide die IHE-Tests bestehen, ohne ein Projekt zusammenarbeiten können.
Welche Standards verwenden nationale Gesundheitssysteme?
Die meisten europäischen Systeme begannen mit CDA-Dokumenten und HL7 v2 und fügen FHIR-APIs hinzu; das EHDS-Austauschformat basiert auf FHIR und dem IPS. Die USA schreiben FHIR US Core für den Patientenzugriff und C-CDA für den Dokumentenaustausch vor.
Wo passen SNOMED CT und LOINC hinein?
Sie sind keine Austauschstandards; sie sind Vokabulare, die in allen von ihnen verwendet werden. Ein LOINC-Code identifiziert den Test in einem HL7 v2 OBX-Segment, einem CDA-Eintrag und einer FHIR Observation gleichermaßen.
Kostenlos in der Sandbox testen
Ihr erster FHIR-Aufruf in 5 Minuten. Eine HL7 FHIR R4 API mit der Zustimmung des Patienten: probieren Sie sie in der Sandbox aus und verbinden Sie dann Ihre eigene App oder Ihr Kliniksystem.
Kostenlos · 30 synthetische Patienten · keine Karte
Anpheros entwickelt eine Patientenakte, die der Patient kontrolliert und mit jeder Klinik teilen kann, auf einer HL7 FHIR R4-Plattform mit Sitz in der EU. Diese Anleitungen helfen Ihnen, Ihre Gesundheit zu verstehen und zu organisieren; sie ersetzen nicht Ihren Arzt.
Über Anpheros →