Imagerie

FHIR ImagingStudy vs DICOMweb : métadonnées en FHIR, pixels en DICOM, avec un exemple

ImagingStudy est la ressource FHIR qui décrit une étude d'imagerie (modalité, série, instances, UIDs) et indique où se trouvent les images. DICOMweb est la manière dont les images sont réellement récupérées. Comment les deux se connectent via un Endpoint, un exemple R4 valide, et les erreurs qui bloquent les visualiseurs.

par Publié 5 min de lecture

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 forme urn:oid:1.2.840… avec le système urn: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ème http://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 id au lieu de identifier ; 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 connectionType hl7-fhir-rest pointant 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

Sources

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.

Anpheros Daily

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 →
Ce guide est informatif et ne remplace pas une consultation médicale. Pour toute décision concernant votre santé, parlez-en à votre médecin. En cas d’urgence, appelez le numéro d’urgence local (112 en Europe).
Rédigé par
L'équipe Anpheros

Anpheros développe un dossier médical que le patient contrôle et peut partager avec n'importe quelle clinique, sur une plateforme HL7 FHIR R4, basée en UE. Ces guides vous aident à comprendre et organiser votre santé ; ils ne remplacent pas votre médecin.

À propos d'Anpheros →