FHIR ImagingStudy vs DICOMweb: cosa contiene cosa

Risposta breve: ImagingStudy è una risorsa FHIR che indica questo paziente ha fatto una TC in questa data, con queste serie e questi UID di istanza, e le immagini sono là. DICOMweb è il là: l'interfaccia REST dell'archivio che contiene i pixel. FHIR porta la descrizione e il referto; DICOM porta le immagini. Un ImagingStudy fa riferimento a una risorsa Endpoint il cui connectionType è dicom-wado-rs, e un visualizzatore combina le due cose.

Cosa contiene ImagingStudy

Una risorsa FHIR ImagingStudy contiene i metadati di uno studio di imaging: l'UID dello Studio Istanza DICOM come identificatore, uno stato, il Paziente soggetto, l'incontro, l'ora di inizio e la Richiesta di Servizio ordinante, codici di modalità dal vocabolario DICOM DCM, conteggi di serie e istanze, l'Endpoint dove si trovano le immagini, e ogni serie con le sue istanze e UID. Non contiene pixel.

identifier: l'UID dello Studio DICOM, come urn:oid:1.2.840… con sistema urn:dicom:uid;
status: registered, available, cancelled, entered-in-error, unknown;
subject: il Paziente; encounter, started, referrer, basedOn (il ServiceRequest che lo ha ordinato);
modality: codici dal vocabolario DICOM stesso (CT, MR, US, CR, DX…), sistema http://dicom.nema.org/resources/ontology/DCM;
numberOfSeries, numberOfInstances;
endpoint: dove recuperare le immagini;
series[]: ciascuna con il proprio UID della Serie, modalità, sito corporeo, instance[] con UID dell'Istanza SOP e UID della Classe SOP.

Cosa non contiene: dati pixel, impostazioni di finestra, l'intero header DICOM, o il testo del referto. Il referto è un DiagnosticReport con imagingStudy che punta indietro.

Un esempio valido di FHIR R4

Un esempio valido di FHIR R4 ImagingStudy riporta l'UID dello Studio Istanza come identificatore con sistema urn:dicom:uid, stato disponibile, una modalità CT dal sistema di codici DICOM DCM, il paziente, l'ora di inizio, conteggi di serie e istanze, un riferimento a un Endpoint di connectionType dicom-wado-rs, e voci di serie con i loro UID, sito corporeo e UID della 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'UID della Classe SOP 1.2.840.10008.5.1.4.1.1.2 è CT Image Storage. L'Endpoint si presenta così:

{
  "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 visualizzatore costruisce l'URL di recupero dalle due: {Endpoint.address}/studies/{StudyInstanceUID}, quindi chiama WADO-RS per metadati e frame.

Chi crea le risorse ImagingStudy

Le risorse ImagingStudy sono solitamente create da una facciata FHIR di fronte al PACS o VNA, o da un motore di integrazione, quando uno studio è completo, spesso innescato dal messaggio HL7 v2 ORU o dal messaggio DICOM MPPS. Alcuni archivi li generano al volo da una query QIDO-RS. Lo scanner stesso non crea risorse ImagingStudy.

Di solito non lo scanner. Una facciata FHIR davanti al PACS o VNA, o un motore di integrazione, crea l'ImagingStudy quando lo studio è completo (spesso innescato dal messaggio HL7 v2 ORU o dal DICOM MPPS) e mantiene numberOfInstances sincronizzato. Alcuni archivi generano ImagingStudy al volo da una query QIDO-RS. Se il tuo progetto li scrive a mano, gli UID devono corrispondere esattamente all'archivio, carattere per carattere, altrimenti il visualizzatore mostrerà uno studio vuoto.

Errori che rompono i visualizzatori

Gli errori che rompono i visualizzatori che leggono un FHIR ImagingStudy sono: inserire l'UID dello Studio in id invece che in identifier, usare un codice di modalità non DICOM, puntare un Endpoint con il connectionType errato a un server DICOMweb, lasciare i conteggi di serie e istanze obsoleti dopo che le immagini cambiano, e aspettarsi dati pixel in un FHIR Binary invece che in un archivio DICOM.

Mettere l'UID dello Studio in id invece che in identifier; gli id FHIR sono assegnati dal server e potrebbero non essere OID.
Una modalità da SNOMED o una lista locale invece del sistema di codici DICOM DCM.
Un Endpoint con connectionType hl7-fhir-rest che punta a un server DICOMweb, o viceversa.
Contare serie e istanze una volta e non aggiornare mai quando vengono aggiunte o eliminate immagini.
Aspettarsi i dati pixel in FHIR Binary. La specifica FHIR stessa dice che le immagini appartengono a DICOM, non a Binary.

In un record Anpheros

Anpheros Platform non ospita ImagingStudy o dati DICOM. I risultati radiologici arrivano come DiagnosticReport o DocumentReference (il referto, con i suoi codici e testo); dove l'ospedale espone un link al visualizzatore, il DocumentReference può portarlo come URL di allegato. Le immagini rimangono nell'archivio dell'ospedale secondo le sue regole di accesso.

Pagine correlate

Fonti

Domande frequenti

Un server FHIR può archiviare le immagini stesse?

Tecnicamente un Binary può contenere qualsiasi byte, ma la specifica FHIR lo sconsiglia per l'imaging e nessun visualizzatore funziona in quel modo. Le immagini rimangono in un archivio DICOM; FHIR vi punta.

Cosa è cambiato in FHIR R5 per ImagingStudy?

R5 mantiene la stessa forma, riordina la nomenclatura (ad esempio procedure sostituisce procedureReference e procedureCode) e allinea la gestione del sito corporeo. R4 rimane la versione utilizzata dalla maggior parte degli archivi e dei profili nazionali.

Come si collega il referto alle immagini?

DiagnosticReport.imagingStudy fa riferimento all'ImagingStudy; DiagnosticReport.media può contenere immagini chiave come risorse Media. L'ImagingStudy fa riferimento all'Endpoint per lo studio completo.

Ho bisogno di ImagingStudy se ho già DICOMweb?

Solo se altri consumatori FHIR hanno bisogno di sapere che lo studio esiste, ad esempio un'app per pazienti, un piano di cura o un'esportazione di ricerca. Un visualizzatore radiologico da solo può vivere su QIDO-RS e WADO-RS.

Anpheros Daily

Prova Anpheros Daily

Conserva i referti delle tue ecografie e analisi in un unico posto in Anpheros Daily, pronti da mostrare alla tua prossima visita.

Come funziona nell'app →

iPhone e Mac Android Apri nel tuo browser →

Questa guida è informativa e non sostituisce il consulto medico. Per le decisioni sulla tua salute parla con il tuo medico. In caso di emergenza, chiama il numero di emergenza locale (112 in Europa).

Scritto da

Il team Anpheros

Anpheros sviluppa una cartella clinica che il paziente controlla e può condividere con qualsiasi studio medico, su una piattaforma HL7 FHIR R4, con sede in UE. Queste guide ti aiutano a comprendere e organizzare la tua salute; non sostituiscono il tuo medico.

Chi siamo →