Réponse courte : ImagingStudy est une ressource FHIR qui indique ce patient a eu un CT à cette date, avec ces séries et ces identifiants uniques d'instance, et les images sont là. DICOMweb est le là-bas : l'interface REST de l'archive qui contient les pixels. FHIR transporte la description et le compte rendu ; DICOM transporte les images. Un ImagingStudy référence une ressource Endpoint dont connectionType est dicom-wado-rs, et un visualiseur combine les deux.
Ce que contient ImagingStudy
Une ressource FHIR ImagingStudy contient les métadonnées d'une étude d'imagerie : l'UID de l'instance d'étude DICOM comme identifiant, un statut, le sujet Patient, la rencontre, l'heure de début et la demande de service commandée, les codes de modalité du vocabulaire DICOM DCM, les décomptes de séries et d'instances, le point de terminaison où résident les images, et chaque série avec ses instances et ses UID. Elle ne contient pas de pixels.
identifier: l'identifiant unique d'étude DICOM, sous la formeurn:oid:1.2.840…avec le systèmeurn:dicom:uid;status: registered, available, cancelled, entered-in-error, unknown ;subject: le Patient ;encounter,started,referrer,basedOn(la ServiceRequest qui l'a commandé) ;modality: codes du vocabulaire propre à DICOM (CT, MR, US, CR, DX…), systèmehttp://dicom.nema.org/resources/ontology/DCM;numberOfSeries,numberOfInstances;endpoint: où récupérer les images ;series[]: chacun avec son identifiant unique de série, modalité, site corporel,instance[]avec l'identifiant unique d'instance SOP et l'identifiant unique de classe SOP.
Ce qu'il ne contient pas : les données pixel, les réglages de fenêtre, l'en-tête DICOM complet, ou le texte du compte rendu. Le compte rendu est un DiagnosticReport avec un imagingStudy qui pointe en retour.
Un exemple valide FHIR R4
Un exemple valide de FHIR R4 ImagingStudy porte l'UID de l'instance d'étude comme identifiant avec le système urn:dicom:uid, le statut disponible, une modalité CT du système de codes DICOM DCM, le patient, l'heure de début, les décomptes de séries et d'instances, une référence à un point de terminaison de connectionType dicom-wado-rs, et des entrées de séries avec leurs UID, le site corporel et l'UID de la classe SOP.
{
"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
}]
}]
}
L'identifiant unique de classe SOP 1.2.840.10008.5.1.4.1.1.2 est CT Image Storage. L'Endpoint ressemble à ceci :
{
"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"
}
Un visualiseur construit l'URL de récupération à partir des deux : {Endpoint.address}/studies/{StudyInstanceUID}, puis appelle WADO-RS pour les métadonnées et les trames.
Qui crée les ressources ImagingStudy
Les ressources ImagingStudy sont généralement créées par une façade FHIR devant le PACS ou le VNA, ou par un moteur d'intégration, lorsqu'une étude est terminée, souvent déclenchée par le message HL7 v2 ORU ou le message DICOM MPPS. Certaines archives les génèrent à la volée à partir d'une requête QIDO-RS. Le scanner lui-même ne crée pas de ressources ImagingStudy.
Généralement pas le scanner. Une façade FHIR devant le PACS ou le VNA, ou un moteur d'intégration, crée l'ImagingStudy lorsque l'étude est terminée (souvent déclenchée par le message HL7 v2 ORU ou le message DICOM MPPS) et maintient numberOfInstances à jour. Certaines archives génèrent ImagingStudy à la volée à partir d'une requête QIDO-RS. Si votre projet les écrit manuellement, les identifiants uniques doivent correspondre exactement à l'archive, caractère par caractère, sinon le visualiseur affichera une étude vide.
Erreurs qui cassent les visualiseurs
Les erreurs qui cassent les visualiseurs lisant une FHIR ImagingStudy sont : placer l'UID de l'étude dans id au lieu d'identifier, utiliser un code de modalité non-DICOM, pointer un point de terminaison avec le mauvais connectionType vers un serveur DICOMweb, laisser les décomptes de séries et d'instances obsolètes après que les images aient changé, et s'attendre à des données de pixels dans un FHIR Binary au lieu d'une archive DICOM.
- Mettre l'identifiant unique d'étude dans
idau lieu deidentifier; les identifiants FHIR sont attribués par le serveur et ne peuvent pas être des OID. - Une modalité de SNOMED ou une liste locale au lieu du système de code DICOM DCM.
- Un Endpoint avec
connectionTypehl7-fhir-restpointant vers un serveur DICOMweb, ou l'inverse. - Compter les séries et les instances une seule fois et ne jamais mettre à jour lorsque des images sont ajoutées ou supprimées.
- S'attendre aux données pixel dans FHIR Binary. La spécification FHIR elle-même indique que les images appartiennent à DICOM, pas à Binary.
Dans un dossier Anpheros
Anpheros Platform n'héberge pas de données ImagingStudy ou DICOM. Les résultats radiologiques arrivent sous forme de DiagnosticReport ou de DocumentReference (le compte rendu, avec ses codes et son texte) ; lorsque l'hôpital expose un lien vers un visualiseur, le DocumentReference peut le transporter comme URL d'attachement. Les images restent dans l'archive de l'hôpital sous ses règles d'accès.
Pages associées
- Explication de DICOMweb
- Explication des tags DICOM
- DocumentReference vs DiagnosticReport vs Binary
- PACS vs RIS vs VNA
- Explication du compte rendu de scanner CT
- DICOM vs FHIR pour les développeurs
Sources
- HL7 FHIR R4 : ImagingStudy
- HL7 FHIR R4 : Endpoint
- HL7 FHIR R4 : système de codes endpoint-connection-type
- DICOM PS3.16 : terminologie contrôlée DCM (CID 29 Acquisition Modality)
- DICOM PS3.18 : services Web
Questions fréquentes
Un serveur FHIR peut-il stocker les images elles-mêmes ?
Techniquement, un Binary peut contenir n'importe quels octets, mais la spécification FHIR le déconseille pour l'imagerie et aucun visualiseur ne fonctionne ainsi. Les images restent dans une archive DICOM ; FHIR y pointe.
Qu'est-ce qui a changé dans FHIR R5 pour ImagingStudy ?
R5 conserve la même structure, nettoie la nomenclature (par exemple, procedure remplace procedureReference et procedureCode) et aligne la gestion des sites corporels. R4 reste la version utilisée par la plupart des archives et des profils nationaux.
Comment le compte rendu est-il lié aux images ?
DiagnosticReport.imagingStudy référence l'ImagingStudy ; DiagnosticReport.media peut transporter des images clés sous forme de ressources Media. L'ImagingStudy référence l'Endpoint pour l'étude complète.
Ai-je besoin d'ImagingStudy si j'ai déjà DICOMweb ?
Seulement si d'autres consommateurs FHIR ont besoin de savoir que l'étude existe, par exemple une application patient, un plan de soins ou une exportation de recherche. Un visualiseur de radiologie seul peut fonctionner avec QIDO-RS et WADO-RS.
Essayez Anpheros Daily
Conservez vos rapports d'examens et d'analyses en un seul endroit dans Anpheros Daily, prêts à être présentés lors de votre prochaine visite.
Comment ça marche dans l'appli →
