Kurze Antwort: ImagingStudy ist eine FHIR-Ressource, die besagt: Dieser Patient hatte eine CT an diesem Datum, mit diesen Serien und diesen Instanz-UIDs, und die Bilder sind dort. DICOMweb ist das dort: die REST-Schnittstelle des Archivs, das die Pixel speichert. FHIR trägt die Beschreibung und den Bericht; DICOM trägt die Bilder. Eine ImagingStudy verweist auf eine Endpoint-Ressource, deren connectionType dicom-wado-rs ist, und ein Viewer kombiniert die beiden.
Was ImagingStudy enthält
Eine FHIR ImagingStudy-Ressource enthält die Metadaten einer einzelnen Bildgebungsstudie: die DICOM Study Instance UID als Identifikator, einen Status, den untersuchten Patienten, die Begegnung, die Startzeit und die anfordernde ServiceRequest, Modalitätscodes aus dem DICOM DCM-Vokabular, die Anzahl der Serien und Instanzen, den Endpunkt, an dem sich die Bilder befinden, und jede Serie mit ihren Instanzen und UIDs. Sie enthält keine Pixel.
identifier: die DICOM Study Instance UID, alsurn:oid:1.2.840…mit dem Systemurn:dicom:uid;status: registered, available, cancelled, entered-in-error, unknown;subject: der Patient;encounter,started,referrer,basedOn(die ServiceRequest, die sie bestellt hat);modality: Codes aus dem eigenen Vokabular von DICOM (CT, MR, US, CR, DX…), Systemhttp://dicom.nema.org/resources/ontology/DCM;numberOfSeries,numberOfInstances;endpoint: wo die Bilder abgerufen werden können;series[]: jede mit ihrer Series Instance UID, Modalität, Körperstelle,instance[]mit SOP Instance UID und SOP Class UID.
Was es nicht enthält: Pixeldaten, Fenstereinstellungen, den vollständigen DICOM-Header oder den Berichtstext. Der Bericht ist ein DiagnosticReport mit einem zurückweisenden imagingStudy.
Ein gültiges FHIR R4 Beispiel
Ein gültiges FHIR R4 ImagingStudy-Beispiel enthält die Study Instance UID als Identifikator mit dem System urn:dicom:uid, den Status 'available', eine CT-Modalität aus dem DICOM DCM-Codesystem, den Patienten, die Startzeit, die Anzahl der Serien und Instanzen, einen Verweis auf einen Endpunkt mit connectionType dicom-wado-rs und Serieneinträge mit ihren UIDs, dem Körperteil und der SOP Class UID.
{
"resourceType": "ImagingStudy",
"id": "ct-chest-2026-03",
"identifier": [{"system": "urn:dicom:uid", "value": "urn:oid:1.2.840.113619.2.55.3.2831164356.781.1710415000.1"}],
"status": "available",
"modality": [{"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "CT"}],
"subject": {"reference": "Patient/example"},
"started": "2026-03-14T09:12:00+01:00",
"numberOfSeries": 2,
"numberOfInstances": 412,
"endpoint": [{"reference": "Endpoint/pacs-dicomweb"}],
"series": [{
"uid": "1.2.840.113619.2.55.3.2831164356.781.1710415000.2",
"number": 1,
"modality": {"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "CT"},
"bodySite": {"system": "http://snomed.info/sct", "code": "51185008", "display": "Thoracic structure"},
"numberOfInstances": 410,
"instance": [{
"uid": "1.2.840.113619.2.55.3.2831164356.781.1710415000.3",
"sopClass": {"system": "urn:ietf:rfc:3986", "code": "urn:oid:1.2.840.10008.5.1.4.1.1.2"},
"number": 1
}]
}]
}
Die SOP Class UID 1.2.840.10008.5.1.4.1.1.2 ist CT Image Storage. Der Endpoint sieht so aus:
{
"resourceType": "Endpoint",
"id": "pacs-dicomweb",
"status": "active",
"connectionType": {"system": "http://terminology.hl7.org/CodeSystem/endpoint-connection-type", "code": "dicom-wado-rs"},
"payloadType": [{"text": "DICOM WADO-RS"}],
"address": "https://pacs.example-hospital.org/dicomweb"
}
Ein Viewer erstellt die Abruf-URL aus den beiden: {Endpoint.address}/studies/{StudyInstanceUID}, ruft dann WADO-RS für Metadaten und Frames auf.
Wer erstellt ImagingStudy-Ressourcen
ImagingStudy-Ressourcen werden normalerweise von einer FHIR-Fassade vor einem PACS oder VNA oder von einer Integrations-Engine erstellt, wenn eine Studie abgeschlossen ist, oft ausgelöst durch die HL7 v2 ORU- oder die DICOM MPPS-Nachricht. Einige Archive generieren sie 'on the fly' aus einer QIDO-RS-Abfrage. Der Scanner selbst erstellt keine ImagingStudy-Ressourcen.
Normalerweise nicht der Scanner. Eine FHIR-Fassade vor dem PACS oder VNA oder eine Integrations-Engine erstellt die ImagingStudy, wenn die Studie abgeschlossen ist (oft ausgelöst durch die HL7 v2 ORU- oder die DICOM MPPS-Nachricht) und hält numberOfInstances synchron. Einige Archive generieren ImagingStudy "on the fly" aus einer QIDO-RS-Abfrage. Wenn Ihr Projekt sie von Hand schreibt, müssen die UIDs exakt mit dem Archiv übereinstimmen, Zeichen für Zeichen, sonst zeigt der Viewer eine leere Studie an.
Fehler, die Viewer zum Absturz bringen
Die Fehler, die Viewer beim Lesen einer FHIR ImagingStudy zum Absturz bringen, sind: die Study UID in 'id' statt in 'identifier' zu setzen, einen Nicht-DICOM-Modalitätscode zu verwenden, einen Endpunkt mit dem falschen connectionType auf einen DICOMweb-Server zu richten, die Zählungen von Serien und Instanzen veraltet zu lassen, nachdem sich Bilder geändert haben, und Pixeldaten in einem FHIR Binary anstelle eines DICOM-Archivs zu erwarten.
- Die Study UID in
idstatt inidentifierzu setzen; FHIR-IDs werden vom Server zugewiesen und dürfen keine OIDs sein. - Eine Modalität aus SNOMED oder einer lokalen Liste statt des DICOM DCM-Codesystems.
- Ein Endpoint mit
connectionTypehl7-fhir-rest, der auf einen DICOMweb-Server zeigt, oder umgekehrt. - Zählen von Serien und Instanzen einmal und nie aktualisieren, wenn Bilder hinzugefügt oder gelöscht werden.
- Erwartung der Pixeldaten in FHIR Binary. Die FHIR-Spezifikation selbst besagt, dass Bilder zu DICOM gehören, nicht zu Binary.
In einem Anpheros-Datensatz
Die Anpheros Platform hostet keine ImagingStudy- oder DICOM-Daten. Radiologische Befunde kommen als DiagnosticReport oder DocumentReference (der Bericht mit seinen Codes und Texten); wo das Krankenhaus einen Viewer-Link bereitstellt, kann die DocumentReference ihn als Anhangs-URL tragen. Die Bilder verbleiben im Archiv des Krankenhauses unter dessen Zugangsregeln.
Verwandte Seiten
- DICOMweb erklärt
- DICOM-Tags erklärt
- DocumentReference vs DiagnosticReport vs Binary
- PACS vs RIS vs VNA
- CT-Scan-Bericht erklärt
- DICOM vs FHIR für Entwickler
Quellen
- HL7 FHIR R4: ImagingStudy
- HL7 FHIR R4: Endpoint
- HL7 FHIR R4: endpoint-connection-type code system
- DICOM PS3.16: DCM controlled terminology (CID 29 Acquisition Modality)
- DICOM PS3.18: Web Services
Häufige Fragen
Kann ein FHIR-Server die Bilder selbst speichern?
Technisch kann ein Binary beliebige Bytes enthalten, aber die FHIR-Spezifikation empfiehlt dies für Bilder nicht, und kein Viewer funktioniert so. Bilder bleiben in einem DICOM-Archiv; FHIR verweist darauf.
Was hat sich in FHIR R5 für ImagingStudy geändert?
R5 behält die gleiche Struktur bei, bereinigt die Benennung (z. B. ersetzt procedure procedureReference und procedureCode) und gleicht die Behandlung von Körperstellen an. R4 bleibt die Version, die die meisten Archive und nationalen Profile verwenden.
Wie verknüpft sich der Bericht mit den Bildern?
DiagnosticReport.imagingStudy verweist auf die ImagingStudy; DiagnosticReport.media kann Schlüsselbilder als Media-Ressourcen enthalten. Die ImagingStudy verweist auf den Endpoint für die vollständige Studie.
Benötige ich ImagingStudy, wenn ich bereits DICOMweb habe?
Nur wenn andere FHIR-Konsumenten wissen müssen, dass die Studie existiert, z. B. eine Patienten-App, ein Behandlungsplan oder ein Forschungs-Export. Ein Radiologie-Viewer allein kann mit QIDO-RS und WADO-RS auskommen.
Anpheros Daily ausprobieren
Bewahren Sie Ihre Befunde von Scans und Tests an einem Ort in Anpheros Daily auf, bereit für Ihren nächsten Arztbesuch.
So funktioniert es in der App →
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 →