Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
DICOM vs FHIR: Bilddaten und klinische Daten
DICOM transportiert medizinische Bilder, FHIR die klinischen Daten darum: was jede abdeckt, wie ImagingStudy und DiagnosticReport verbunden sind und was wo gespeichert werden sollte.
DICOM und FHIR sind keine Konkurrenten: DICOM ist der Standard für medizinische Bilder – die Pixel und die technischen Metadaten eines Röntgenbilds, CTs oder MRTs – während HL7 FHIR der Standard für die klinischen Daten darum herum ist, wie z. B. die Bestellung, der Bericht des Radiologen, die Befunde und der Patient, zu dem sie gehören. Ein typischer Workflow für Bildgebung nutzt beide: der Scanner und das PACS sprechen DICOM, die Krankenhaus- und Patientenanwendungen sprechen FHIR, und FHIR-Ressourcen verweisen auf die DICOM-Studie, anstatt sie zu kopieren. Diese Seite erklärt, wo jeder Standard beginnt und endet, wie sie verbunden sind und was ein FHIR-Backend wie Anpheros speichern sollte und nicht speichern sollte.
Die Kurzfassung
| DICOM | HL7 FHIR R4 | |
|---|---|---|
| Was es transportiert | Bilder und deren Metadaten (Modalität, Körperteil, Schichtabstand, Gerät, UIDs) | Klinische Daten: Patienten, Bestellungen, Berichte, Beobachtungen, Medikamente… |
| Typische Größe | Megabyte bis Gigabyte pro Studie | Kilobyte pro Ressource |
| Dateneinheit | Studie → Serie → Instanz, identifiziert durch global eindeutige UIDs | Ressourcen (Patient, ServiceRequest, ImagingStudy, DiagnosticReport…) mit Referenzen |
| Transport | DIMSE-Netzwerkdienste (C-STORE, C-FIND, C-MOVE) und DICOMweb REST (QIDO-RS, WADO-RS, STOW-RS) | REST über HTTPS mit JSON oder XML |
| Gespeichert in | PACS oder herstellerneutrales Archiv (VNA) | EHR, FHIR-Server, Gesundheitsdatenplattform |
| Gelesen von | Radiologie-Viewer, KI-Bildmodelle, Modalitäten | Klinische Apps, Patienten-Apps, Analysen, KI, die mit Text und Werten arbeitet |
Wofür DICOM dient
DICOM (Digital Imaging and Communications in Medicine) definiert, wie ein Bild kodiert wird und wie Bildgebungsgeräte es austauschen. Jede Bilddatei enthält neben den Pixeldaten einen Header mit Hunderten von Attributen – Patienten- und Studienidentifikatoren, Modalität (CT, MR, DX, US…), Akquisitionsparameter, Pixelabstand. Bilder werden als Instanzen innerhalb von Serien innerhalb einer Studie gruppiert, jede mit einer UID wie 2.25.181945…, damit dieselbe Studie in jedem Archiv wiedergefunden werden kann.
DICOMweb brachte DICOM zu HTTP: QIDO-RS zum Suchen von Studien, WADO-RS zum Abrufen, STOW-RS zum Speichern. Das macht Bilder von Web-Viewern und Cloud-Diensten erreichbar, aber die Nutzlast ist immer noch DICOM.
Was DICOM nicht gut kann, ist die klinische Geschichte: warum die Studie angeordnet wurde, was der Radiologe schlussfolgerte, zu welchem Problem sie gehört und wie sie mit Laborergebnissen und Medikamenten zusammenhängt. Das ist die Aufgabe von FHIR.
Was FHIR im Bereich Imaging leistet
FHIR R4 verfügt über Ressourcen für jeden Schritt eines Imaging-Workflows:
- ServiceRequest – die Anforderung: „Röntgen-Thorax, zwei Ansichten, Verdacht auf Pneumonie“.
- ImagingStudy – eine Zusammenfassung einer DICOM-Studie (UIDs, Modalität, Anzahl der Serien und Instanzen, Körperstelle) und eine
endpoint, die angibt, wo die Bilder abgerufen werden können, z. B. eine DICOMweb WADO-RS-Adresse. Sie enthält keine Pixel. - DiagnosticReport – der Bericht des Radiologen: Code, Status, Schlussfolgerung, Ausstellungsdatum und optional der Originalbericht als PDF in
presentedForm;imagingStudyverknüpft ihn mit der Studie. - Observation – einzelne Befunde oder Messungen, die abfragbar sein müssen, wie z. B. die Größe eines Knotens.
- DocumentReference – ein Dokument wie ein PDF-Bericht oder ein Schlüsselbild, das als JPEG exportiert wurde.
Eine ImagingStudy, die auf eine Studie in einem PACS verweist (gültige FHIR R4-Struktur):
{
"resourceType": "ImagingStudy",
"status": "available",
"subject": {"reference": "Patient/example"},
"identifier": [{"system": "urn:dicom:uid", "value": "urn:oid:2.25.181945102383749012843512396725468820"}],
"started": "2026-10-03T10:20:00-05:00",
"modality": [{"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "DX"}],
"numberOfSeries": 1,
"numberOfInstances": 2,
"endpoint": [{"reference": "Endpoint/pacs-wado"}],
"series": [{
"uid": "2.25.30584718293846127394857102938475",
"modality": {"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "DX"},
"bodySite": {"system": "http://snomed.info/sct", "code": "51185008", "display": "Thoracic structure"},
"numberOfInstances": 2,
"instance": [{"uid": "2.25.11223344556677889900112233445566",
"sopClass": {"system": "urn:ietf:rfc:3986", "code": "urn:oid:1.2.840.10008.5.1.4.1.1.1.1"}}]
}]
}
Der Bericht zur selben Studie als DiagnosticReport (er besteht den FHIR R4 Validator):
{
"resourceType": "DiagnosticReport",
"status": "final",
"category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v2-0074", "code": "RAD", "display": "Radiology"}]}],
"code": {"coding": [{"system": "http://loinc.org", "code": "36643-5", "display": "XR Chest 2 Views"}], "text": "Chest X-ray, 2 views"},
"subject": {"reference": "Patient/example"},
"effectiveDateTime": "2026-10-03T10:20:00-05:00",
"issued": "2026-10-03T15:05:00-05:00",
"performer": [{"display": "Springfield Imaging Center"}],
"conclusion": "No acute cardiopulmonary abnormality.",
"presentedForm": [{"contentType": "application/pdf", "url": "https://imaging.springfield-hospital.test/reports/RPT-8812.pdf", "title": "Radiology report"}]
}
Wie die beiden verbunden werden
modality (X-ray, CT, MR) ──DICOM──► PACS / VNA ◄──DICOMweb (WADO-RS)── image viewer, AI image model
▲
ImagingStudy.endpoint│ (where the images are)
│
order (ServiceRequest) ──► study ──► report (DiagnosticReport) ──► patient record (FHIR)
│
patient app, clinic system, AI assistant (text and values)
Die Regel, die Systeme einfach hält: Bilder bleiben im Bildarchiv; der klinische Datensatz enthält den Bericht, die relevanten Befunde und einen Verweis auf die Bilder. Das Kopieren von DICOM-Studien in eine klinische Datenbank vervielfacht Speicher- und Datenschutzrisiken, ohne den Datensatz für die meisten Leser nützlicher zu machen.
Andere Standards füllen die Lücken zwischen Krankenhäusern: IHE-Profile wie XDS-I für den Austausch von Bilddokumenten zwischen Organisationen und FHIRcast, um einen Radiologie-Viewer und eine Berichts-App für denselben Patienten und dieselbe Studie synchron zu halten.
Bildgebung, Interoperabilität und KI
KI auf medizinischen Bildern (Erkennung, Segmentierung, Triage) arbeitet mit DICOM-Pixeldaten, normalerweise innerhalb der radiologischen Abteilung oder einer spezialisierten Plattform. KI, die einem Patienten oder Arzt hilft, den gesamten Datensatz zu interpretieren – „was zeigte das letzte Röntgenbild der Brust und wie steht es im Zusammenhang mit dem Husten und den Antibiotika?“ – arbeitet mit dem Befund, den Ergebnissen und den übrigen klinischen Daten, die FHIR transportiert. Beide Arten von KI benötigen dasselbe von der Infrastruktur: Daten mit Codes, Zeiten und einem aufgezeichneten Ursprung.
Wo Anpheros passt
Anpheros speichert die Akte jedes Patienten als HL7 FHIR R4. Für die Bildgebung bedeutet dies:
- Gespeichert: der Radiologiebericht als
DiagnosticReport, der Originalbericht oder ein Schlüsselbild alsDocumentReference(bis zu 25 MiB pro Dokument), Befunde alsObservationund die Anforderung alsServiceRequest. Jeder Schreibvorgang trägt die Herkunft, und der Patient entscheidet, welche Anwendungen ihn lesen dürfen. - Nicht gespeichert: DICOM-Studien. Anpheros ist kein PACS, hat keine DICOMweb-Schnittstelle und unterstützt derzeit nicht die
ImagingStudy-Ressource, sodass es keine Bilder indizieren oder bereitstellen kann. Es liest oder interpretiert keine Bilder.
In der Anpheros Daily App kann ein Patient einen Bildgebungsbericht fotografieren oder hochladen und ihn in seinen Dokumenten neben dem Rest seiner Akte aufbewahren. Für einen Entwickler, der eine App oder eine Klinikintegration erstellt, ist die praktische Aufteilung: Bewahren Sie Bilder in Ihrem Bildgebungssystem auf, schreiben Sie den Bericht und die Befunde in die FHIR-Akte des Patienten. How to integrate clinic systems with a FHIR backend zeigt, wie ein Besuch und seine Dokumente in einer Transaktion geschrieben werden, und das DiagnosticReport example zeigt die Struktur eines Berichts.
Häufig gestellte Fragen
Was ist der Unterschied zwischen DICOM und FHIR?
DICOM kodiert und tauscht medizinische Bilder und deren technische Metadaten aus; FHIR tauscht klinische Daten wie Anordnungen, Berichte, Beobachtungen und Medikamente aus. In der Praxis beschreiben FHIR-Ressourcen Bildgebungsstudien und verweisen auf diese, während die Bilder selbst in DICOM verbleiben.
Kann FHIR medizinische Bilder speichern?
FHIR kann kleine Bilder als Anhänge (ein Schlüsselbild in einem DocumentReference oder Media) übertragen, ist aber nicht für vollständige diagnostische Studien ausgelegt. Die ImagingStudy-Ressource beschreibt eine DICOM-Studie und gibt an, wo sie abgerufen werden kann; die Pixel verbleiben in einem PACS oder Archiv.
Was ist DICOMweb?
Der RESTful-Teil des DICOM-Standards: QIDO-RS zum Suchen, WADO-RS zum Abrufen und STOW-RS zum Speichern von Studien über HTTP. Eine FHIR ImagingStudy kann auf einen DICOMweb-Endpunkt verweisen.
Welche FHIR-Ressource enthält einen radiologischen Bericht?
DiagnosticReport, mit einer Kategorie Radiologie, einem LOINC-Code für die Untersuchung, einem Schlussfolgerung und, falls erforderlich, dem Originalbericht als PDF in presentedForm. Messungen, die durchsuchbar sein müssen, werden zu separaten Observations.
Unterstützt Anpheros DICOM?
Nein. Anpheros speichert die klinische Seite der Bildgebung – Berichte, Befunde, Dokumente und Anordnungen – im FHIR R4-Datensatz des Patienten. Es speichert, liefert oder interpretiert keine DICOM-Bilder und unterstützt ImagingStudy derzeit nicht.
Verwandte Themen
- Interoperabilität von Gesundheitsdaten: die Standards rund um FHIR
- FHIR-Plattform: die 26 Ressourcentypen, die Anpheros speichert
- FHIR im Vergleich zu einer benutzerdefinierten medizinischen Datenbank
- API für Laborergebnisse: das gleiche Muster für Laborberichte
- Integration von Kliniksystemen mit einem FHIR-Backend
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card