Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

DICOM vs FHIR : données d'imagerie et données cliniques

DICOM transporte les images médicales, FHIR les données cliniques qui les entourent : ce que chacun couvre, comment ImagingStudy et DiagnosticReport se connectent, et ce qu'il faut stocker où.

DICOM et FHIR ne sont pas des concurrents : DICOM est la norme pour les images médicales — les pixels et les métadonnées techniques d'une radiographie, d'un scanner ou d'une IRM — tandis que HL7 FHIR est la norme pour les données cliniques qui les entourent, telles que la demande, le rapport du radiologue, les conclusions et le patient auquel elles appartiennent. Un flux de travail d'imagerie typique utilise les deux : le scanner et le PACS communiquent en DICOM, l'hôpital et les applications patient communiquent en FHIR, et les ressources FHIR pointent vers l'étude DICOM plutôt que de la copier. Cette page explique où chaque norme commence et s'arrête, comment elles se connectent, et ce qu'un backend FHIR tel qu'Anpheros doit et ne doit pas stocker.

La réponse courte

	DICOM	HL7 FHIR R4
Ce qu'il transporte	Images et leurs métadonnées (modalité, partie du corps, espacement des coupes, appareil, UIDs)	Données cliniques : patients, commandes, rapports, observations, médicaments…
Taille typique	Mégaoctets à gigaoctets par étude	Kilooctets par ressource
Unité de données	Étude → Série → Instance, identifiée par des UIDs globalement uniques	Ressources (Patient, ServiceRequest, ImagingStudy, DiagnosticReport…) avec des références
Transport	Services réseau DIMSE (C-STORE, C-FIND, C-MOVE) et DICOMweb REST (QIDO-RS, WADO-RS, STOW-RS)	REST sur HTTPS avec JSON ou XML
Stocké dans	PACS ou archive neutre du fournisseur (VNA)	Dossiers médicaux électroniques (DME), serveur FHIR, plateforme de données de santé
Lu par	Visionneuses de radiologie, modèles d'IA d'images, modalités	Applications cliniques, applications patient, analytique, IA travaillant sur du texte et des valeurs

À quoi sert le DICOM

DICOM (Digital Imaging and Communications in Medicine) définit comment une image est encodée et comment les équipements d'imagerie l'échangent. Chaque fichier image contient un en-tête avec des centaines d'attributs — identifiants du patient et de l'étude, modalité (CT, MR, DX, US…), paramètres d'acquisition, espacement des pixels — à côté des données pixel. Les images sont regroupées en instances au sein de séries au sein d'une étude, chacune avec un UID tel que 2.25.181945…, afin que la même étude puisse être retrouvée dans n'importe quelle archive.

DICOMweb a apporté le DICOM sur HTTP : QIDO-RS pour rechercher des études, WADO-RS pour les récupérer, STOW-RS pour les stocker. Cela rend les images accessibles depuis des visualiseurs web et des services cloud, mais la charge utile reste du DICOM.

Ce que le DICOM ne fait pas bien, c'est l'histoire clinique : pourquoi l'étude a été demandée, quelle a été la conclusion du radiologue, à quel problème elle se rapporte, et comment elle s'intègre avec les résultats de laboratoire et les médicaments. C'est le rôle de FHIR.

Ce que FHIR fait autour de l'imagerie

FHIR R4 dispose de ressources pour chaque étape d'un flux de travail d'imagerie :

ServiceRequest — la commande : "radiographie thoracique, deux vues, suspicion de pneumonie".
ImagingStudy — un résumé d'une étude DICOM (UIDs, modalité, nombre de séries et d'instances, site corporel) et une endpoint qui indique où les images peuvent être récupérées, par exemple une adresse DICOMweb WADO-RS. Elle ne contient pas de pixels.
DiagnosticReport — le rapport du radiologue : code, statut, conclusion, date d'émission et, facultativement, le rapport original au format PDF dans presentedForm ; imagingStudy le lie à l'étude.
Observation — des constatations ou des mesures individuelles qui doivent être interrogeables, comme la taille d'un nodule.
DocumentReference — un document tel qu'un rapport PDF ou une image clé exportée en JPEG.

Un ImagingStudy qui pointe vers une étude dans un PACS (structure FHIR R4 valide) :

{
  "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"}}]
  }]
}

Le rapport sur la même étude, en tant que DiagnosticReport (il passe le valideur FHIR R4) :

{
  "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"}]
}

Comment les deux se connectent

 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)

La règle qui maintient la simplicité des systèmes : les images restent dans l'archive d'imagerie ; le dossier clinique conserve le rapport, les conclusions importantes et un pointeur vers les images. Copier des études DICOM dans une base de données clinique multiplie les risques de stockage et de confidentialité sans rendre le dossier plus utile à la plupart de ses lecteurs.

D'autres normes comblent les lacunes entre les hôpitaux : les profils IHE tels que XDS-I pour le partage de documents d'imagerie entre organisations, et FHIRcast pour maintenir un visualiseur de radiologie et une application de reporting sur le même patient et la même étude.

Imagerie, interopérabilité et IA

L'IA sur les images médicales (détection, segmentation, triage) fonctionne sur les données pixel DICOM, généralement au sein du département d'imagerie ou d'une plateforme spécialisée. L'IA qui aide un patient ou un médecin à raisonner sur l'ensemble du dossier — « qu'a montré la dernière radiographie thoracique, et comment cela se rapporte-t-il à la toux et aux antibiotiques ? » — fonctionne sur le rapport, les constatations et le reste des données cliniques, ce qui est ce que FHIR transporte. Les deux types d'IA ont besoin de la même chose de l'infrastructure : des données avec des codes, des horodatages et une origine enregistrée.

Où Anpheros s'intègre

Anpheros stocke le dossier de chaque patient en HL7 FHIR R4. Pour l'imagerie, cela signifie :

Stocké : le compte-rendu de radiologie sous forme de DiagnosticReport, le compte-rendu original ou une image clé sous forme de DocumentReference (jusqu'à 25 MiB par document), les constatations sous forme de Observation, et la demande sous forme de ServiceRequest. Chaque écriture porte sa provenance, et le patient décide quelles applications peuvent la lire.
Non stocké : les études DICOM. Anpheros n'est pas un PACS, n'a pas d'interface DICOMweb et ne prend pas en charge la ressource ImagingStudy aujourd'hui, il ne peut donc pas indexer ni servir d'images. Il ne lit ni n'interprète les images.

Dans l'application Anpheros Daily, un patient peut photographier ou télécharger un compte-rendu d'imagerie et le conserver dans ses documents à côté du reste de son dossier. Pour un développeur créant une application ou une intégration de clinique, la séparation pratique est la suivante : conservez les images dans votre système d'imagerie, écrivez le compte-rendu et les constatations dans le dossier FHIR du patient. Comment intégrer les systèmes de clinique avec un backend FHIR montre comment écrire une visite et ses documents en une seule transaction, et l'exemple de DiagnosticReport montre la structure d'un compte-rendu.

Foire aux questions

Quelle est la différence entre DICOM et FHIR ?

DICOM encode et échange des images médicales et leurs métadonnées techniques ; FHIR échange des données cliniques telles que les commandes, les rapports, les observations et les médicaments. En pratique, les ressources FHIR décrivent et référencent les études d'imagerie, tandis que les images elles-mêmes restent en DICOM.

FHIR peut-il stocker des images médicales ?

FHIR peut transporter de petites images en tant que pièces jointes (une image clé dans un DocumentReference ou un Media), mais il n'est pas conçu pour des études diagnostiques complètes. La ressource ImagingStudy décrit une étude DICOM et indique où elle peut être récupérée ; les pixels restent dans un PACS ou une archive.

Qu'est-ce que DICOMweb ?

La partie RESTful de la norme DICOM : QIDO-RS pour rechercher, WADO-RS pour récupérer et STOW-RS pour stocker des études sur HTTP. Une ImagingStudy FHIR peut pointer vers un point de terminaison DICOMweb.

Quelle ressource FHIR contient un rapport de radiologie ?

DiagnosticReport, avec une catégorie de radiologie, un code LOINC pour l'examen, une conclusion et, si nécessaire, le rapport original en PDF dans presentedForm. Les mesures qui doivent être consultables deviennent des Observations distinctes.

Anpheros prend-il en charge DICOM ?

Non. Anpheros stocke le côté clinique de l'imagerie — rapports, constatations, documents et commandes — dans le dossier FHIR R4 du patient. Il ne stocke, ne sert ni n'interprète les images DICOM et ne prend pas en charge ImagingStudy aujourd'hui.

Liens pertinents

Interopérabilité des données de santé : les standards autour de FHIR
Plateforme FHIR : les 26 types de ressources stockés par Anpheros
FHIR vs. une base de données médicale personnalisée
API des résultats de laboratoire : le même schéma pour les rapports de laboratoire
Comment intégrer les systèmes de clinique avec un backend FHIR

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card