# DICOM vs FHIR: dati di imaging e dati clinici

> DICOM trasporta le immagini mediche, FHIR i dati clinici ad esse correlati: cosa copre ciascuno, come ImagingStudy e DiagnosticReport si connettono e cosa memorizzare dove.

Source: https://developers.anpheros.com/it/guides/dicom-vs-fhir

**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):

```json
{
  "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](https://developers.anpheros.com/tools/fhir-validator)):

```json
{
  "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](https://developers.anpheros.com/it/guides/integrate-clinic-systems-fhir) mostra come scrivere una visita e i suoi documenti in un'unica transazione, e l'[esempio di DiagnosticReport](https://developers.anpheros.com/tools/fhir-examples/diagnostic-report) 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](https://developers.anpheros.com/it/guides/interoperability): gli standard intorno a FHIR
- [Piattaforma FHIR](https://developers.anpheros.com/it/guides/fhir): i 26 tipi di risorse archiviati da Anpheros
- [FHIR vs. un database medico personalizzato](https://developers.anpheros.com/it/guides/fhir-vs-custom-database)
- [API per i risultati di laboratorio](https://developers.anpheros.com/it/guides/lab-results-api): lo stesso pattern per i referti di laboratorio
- [Come integrare i sistemi clinici con un backend FHIR](https://developers.anpheros.com/it/guides/integrate-clinic-systems-fhir)