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

DICOM vs FHIR: dati di imaging e dati clinici

DICOM trasporta immagini mediche, FHIR i dati clinici correlati: cosa copre ciascuno, come ImagingStudy e DiagnosticReport si collegano e cosa archiviare dove.

DICOM e FHIR non sono concorrenti: DICOM è lo standard per le immagini mediche — i pixel e i metadati tecnici di un Raggi X, TC o RM — mentre HL7 FHIR è lo standard per i dati clinici ad essi correlati, come l'ordine, il referto del radiologo, i reperti e il paziente a cui appartengono. Un tipico flusso di lavoro di imaging utilizza entrambi: lo scanner e il PACS parlano DICOM, l'ospedale e le app per pazienti parlano FHIR, e le risorse FHIR puntano allo studio DICOM anziché copiarlo. Questa pagina spiega dove inizia e finisce ciascuno standard, come si connettono e cosa un backend FHIR come Anpheros dovrebbe e non dovrebbe memorizzare.

La risposta breve

	DICOM	HL7 FHIR R4
Cosa trasporta	Immagini e i loro metadati (modalità, parte del corpo, spaziatura delle fette, dispositivo, UID)	Dati clinici: pazienti, ordini, referti, osservazioni, farmaci…
Dimensione tipica	Megabyte o gigabyte per studio	Kilobyte per risorsa
Unità di dati	Studio → Serie → Istanza, identificati da UID univoci globali	Risorse (Patient, ServiceRequest, ImagingStudy, DiagnosticReport…) con riferimenti
Trasporto	Servizi di rete DIMSE (C-STORE, C-FIND, C-MOVE) e REST DICOMweb (QIDO-RS, WADO-RS, STOW-RS)	REST su HTTPS con JSON o XML
Archiviati in	PACS o archivio neutrale rispetto al fornitore (VNA)	EHR, server FHIR, piattaforma dati sanitari
Letti da	Visualizzatori radiologici, modelli di immagini AI, modalità	Applicazioni cliniche, applicazioni per pazienti, analisi, AI che lavora su testo e valori

A cosa serve DICOM

DICOM (Digital Imaging and Communications in Medicine) definisce come un'immagine viene codificata e come le apparecchiature di imaging la scambiano. Ogni file immagine contiene un header con centinaia di attributi — identificatori del paziente e dello studio, modalità (CT, MR, DX, US…), parametri di acquisizione, spaziatura dei pixel — accanto ai dati dei pixel. Le immagini sono raggruppate come istanze all'interno di serie all'interno di uno studio, ognuna con un UID come 2.25.181945…, in modo che lo stesso studio possa essere ritrovato in qualsiasi archivio.

DICOMweb ha portato DICOM su HTTP: QIDO-RS per cercare studi, WADO-RS per recuperarli, STOW-RS per memorizzarli. Questo rende le immagini raggiungibili da visualizzatori web e servizi cloud, ma il payload è ancora DICOM.

Ciò che DICOM non fa bene è la storia clinica: perché è stato richiesto lo studio, cosa ha concluso il radiologo, a quale problema si riferisce e come si inserisce nei risultati di laboratorio e nelle terapie. Questo è il compito di FHIR.

Cosa fa FHIR per l'imaging

FHIR R4 dispone di risorse per ogni fase di un flusso di lavoro di imaging:

ServiceRequest — l'ordine: "radiografia del torace, due proiezioni, sospetta polmonite".
ImagingStudy — un riepilogo di uno studio DICOM (UID, modalità, numero di serie e istanze, sito corporeo) e un endpoint che indica dove le immagini possono essere recuperate, ad esempio un indirizzo DICOMweb WADO-RS. Non contiene pixel.
DiagnosticReport — il referto del radiologo: codice, stato, conclusione, data di emissione e, facoltativamente, il referto originale in PDF in presentedForm; imagingStudy lo collega allo studio.
Observation — singoli riscontri o misurazioni che devono essere interrogabili, come le dimensioni di un nodulo.
DocumentReference — un documento come un referto PDF o un'immagine chiave esportata come JPEG.

Un ImagingStudy che punta a uno studio in un PACS (struttura FHIR R4 valida):

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

Il referto sullo stesso studio, come DiagnosticReport (supera il validator 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"}]
}

Come i due si collegano

 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 regola che mantiene i sistemi semplici: le immagini rimangono nell'archivio di imaging; il fascicolo clinico conserva il referto, i risultati che contano e un puntatore alle immagini. Copiare studi DICOM in un database clinico moltiplica lo spazio di archiviazione e il rischio per la privacy senza rendere il fascicolo più utile alla maggior parte dei suoi lettori.

Altri standard colmano le lacune tra gli ospedali: profili IHE come XDS-I per la condivisione di documenti di imaging tra organizzazioni e FHIRcast per mantenere un visualizzatore di radiologia e un'applicazione di refertazione sullo stesso paziente e studio.

Imaging, interoperabilità e AI

L'AI sulle immagini mediche (rilevamento, segmentazione, triage) opera sui dati pixel DICOM, solitamente all'interno del dipartimento di imaging o di una piattaforma specializzata. L'AI che aiuta un paziente o un medico a ragionare sull'intero record — "cosa ha mostrato l'ultima radiografia del torace e come si relaziona alla tosse e agli antibiotici?" — opera sul report, sui risultati e sul resto dei dati clinici, che è ciò che FHIR trasporta. Entrambi i tipi di AI necessitano della stessa cosa dall'infrastruttura: dati con codici, tempi e un'origine registrata.

Dove si posiziona Anpheros

Anpheros memorizza il record di ogni paziente come HL7 FHIR R4. Per l'imaging, ciò significa:

Memorizzati: il referto radiologico come DiagnosticReport, il referto originale o un'immagine chiave come DocumentReference (fino a 25 MiB per documento), i reperti come Observation e l'ordine come ServiceRequest. Ogni scrittura porta la provenienza e il paziente decide quali applicazioni possono leggerla.
Non memorizzati: studi DICOM. Anpheros non è un PACS, non ha un'interfaccia DICOMweb e non supporta la risorsa ImagingStudy oggi, quindi non può indicizzare o servire immagini. Non legge né interpreta immagini.

Nell'app Anpheros Daily, un paziente può fotografare o caricare un referto di imaging e conservarlo nei propri documenti accanto al resto del proprio record. Per uno sviluppatore che crea un'app o un'integrazione clinica, la divisione pratica è: conservare le immagini nel proprio sistema di imaging, scrivere il referto e i reperti nel record FHIR del paziente. Come integrare i sistemi clinici con un backend FHIR mostra come scrivere una visita e i suoi documenti in un'unica transazione, e l'esempio di DiagnosticReport mostra la struttura di un referto.

Domande frequenti

Qual è la differenza tra DICOM e FHIR?

DICOM codifica e scambia immagini mediche e i loro metadati tecnici; FHIR scambia dati clinici come ordini, referti, osservazioni e farmaci. In pratica, le risorse FHIR descrivono e fanno riferimento agli studi di imaging, mentre le immagini stesse rimangono in DICOM.

FHIR può archiviare immagini mediche?

FHIR può trasportare piccole immagini come allegati (un'immagine chiave in un DocumentReference o Media), ma non è progettato per studi diagnostici completi. La risorsa ImagingStudy descrive uno studio DICOM e indica dove può essere recuperato; i pixel rimangono in un PACS o archivio.

Cos'è DICOMweb?

La parte RESTful dello standard DICOM: QIDO-RS per la ricerca, WADO-RS per il recupero e STOW-RS per l'archiviazione di studi tramite HTTP. Un ImagingStudy FHIR può puntare a un endpoint DICOMweb.

Quale risorsa FHIR contiene un referto radiologico?

DiagnosticReport, con una categoria radiologica, un codice LOINC per l'esame, una conclusione e, se necessario, il referto originale come PDF in presentedForm. Le misurazioni che devono essere ricercabili diventano Observations separate.

Anpheros supporta DICOM?

No. Anpheros archivia il lato clinico dell'imaging — referti, risultati, documenti e ordini — nel record FHIR R4 del paziente. Non archivia, serve o interpreta immagini DICOM e non supporta ImagingStudy oggi.

Correlati

Interoperabilità dei dati sanitari: gli standard intorno a FHIR
Piattaforma FHIR: i 26 tipi di risorse archiviati da Anpheros
FHIR vs. un database medico personalizzato
API per i risultati di laboratorio: lo stesso pattern per i referti di laboratorio
Come integrare i sistemi clinici con un backend FHIR

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