HL7 FHIR DSTU 1: un modello a risorse e API REST per l'interoperabilità sanitaria

AIHealth

Piattaforma clinica on-premise con LLM locali, RAG su dati FHIR/DICOM, supporto alla diagnosi, follow-up remoto. Architettura progettata per il percorso MDR.

Scopri AIHealth →

Digital Health

Sviluppo di software medicale conforme agli standard normativi CE e MDR. Sistemi di supporto alle decisioni cliniche, integrazione AI nei flussi di lavoro clinici.

Scopri →

Perché un nuovo standard

Nel 2014 HL7 ha pubblicato la Draft Standard for Trial Use 1 di FHIR — Fast Healthcare Interoperability Resources. Il lavoro è partito intorno al 2011 su iniziativa di Grahame Grieve e di un gruppo di esperti HL7, in risposta a un malessere che percorreva da anni la comunità dell’interoperabilità sanitaria: i due standard dominanti erano HL7 v2 — pragmatico e capillare ma non auto-descrittivo, povero di semantica, altamente customizzato — e l’insieme HL7 v3 + CDA R2, rigoroso ma largamente considerato troppo complesso, con costi di implementazione elevati e una penetrazione effettiva inferiore alle aspettative.

Allo stesso tempo il resto dell’industria informatica si era spostato su API HTTP RESTful, JSON come formato di scambio preferito, OAuth per l’autorizzazione. L’ecosistema sanitario — in particolare i vendor EHR americani e gli strumenti di patient-facing sviluppati fuori dagli ospedali — domandava un punto di accesso tecnico alla pari con il resto del web.

FHIR è la risposta di HL7 a questa domanda: un modello informativo riconoscibile per chi viene dal mondo v2/CDA, esposto con le convenzioni tecniche del web moderno.

DSTU 1: una prima pietra

La DSTU 1 di FHIR è stata approvata in ballot ANSI il 17 febbraio 2014 e pubblicata come standard HL7 con qualifica Draft — cioè esplicitamente soggetta a revisione nei rilasci successivi, sulla base dell’esperienza dei primi implementatori. Da subito è stata accompagnata da Connectathon semestrali in cui fornitori, ricercatori e servizi pubblici implementavano e testavano le risorse fianco a fianco.

DSTU 1 definisce 49 Resource fondamentali, tra cui Patient, Practitioner, Encounter, Observation, Condition, Procedure, MedicationOrder, MedicationDispense, MedicationAdministration, DiagnosticReport, Immunization, AllergyIntolerance, Organization, Location, Substance, Device, DocumentReference.

I sei principi di progetto

FHIR è stato progettato con obiettivi espliciti, che si possono leggere in controluce rispetto ai limiti degli standard precedenti:

1. Risorsa come unità atomica — ogni entità clinica o organizzativa è una Resource autoconclusa, con un suo URL, una sua identità, un suo ciclo di vita
2. Composizionalità — le risorse si riferiscono tra loro attraverso reference e possono essere aggregate in Bundle per documenti, ricerche, messaggi, transazioni
3. API REST — ogni risorsa è esposta con le convenzioni HTTP: GET, POST, PUT, DELETE su pattern [base]/[Resource]/[id], con _search, _history, _include
4. Due serializzazioni equivalenti — XML e JSON, con schema di riferimento pubblicato e mapping tra le due forme
5. Leggibilità umana — ogni risorsa contiene una sezione text con narrativa XHTML, eredità diretta del principio di leggibilità di CDA R2
6. 80/20 — il core standard copre l’80% dei casi d’uso comuni; il restante 20% è gestito via Extension, con un meccanismo uniforme per aggiungere attributi senza rompere la specifica

Sopra i sei principi si innesta un meccanismo di conformance-driven design: per ogni contesto d’uso si definisce un Profile (serializzato come risorsa StructureDefinition) che restringe, estende e vincola le risorse di base. La conformità a un profilo è verificabile automaticamente — la machine-readable conformance è cittadina di prima classe nello standard.

Esempio: una Patient in JSON

Un paziente FHIR in JSON è lungo poche decine di righe:

{
  "resourceType": "Patient",
  "id": "example",
  "identifier": [{
    "system": "urn:oid:2.16.840.1.113883.2.9.4.3.2",
    "value": "RSSMRA50T25H501U"
  }],
  "name": [{
    "use": "official",
    "family": ["Rossi"],
    "given": ["Mario"]
  }],
  "gender": "male",
  "birthDate": "1950-12-25"
}

La stessa informazione in XML usa il namespace http://hl7.org/fhir. Le due forme sono interscambiabili — una delle differenze più visibili rispetto a CDA R2, che ammette solo XML.

Search, references, bundle

La ricerca è basata su parametri HTTP: GET [base]/Observation?patient=123&code=http://loinc.org|1558-6 restituisce un Bundle di tipo searchset. I parametri supportano modificatori (:exact, :missing, :contains), prefissi numerici (gt, lt, ge, le), e chained search (Observation?patient.name=Rossi). _include e _revinclude inseriscono nel bundle anche le risorse referenziate.

La transazione atomica è modellata come Bundle di tipo transaction: un singolo POST [base] esegue più creazioni/aggiornamenti in modo atomico.

La licenza CC0

Uno degli aspetti più rilevanti — e insolitamente aperti per HL7 — è la scelta della licenza: FHIR è rilasciato come Creative Commons CC0 (dominio pubblico) sia per la specifica che per gli schemi e gli esempi. La libera riutilizzabilità senza restrizioni è stata una scelta strategica per abbassare la soglia di adozione da parte di chiunque — vendor, ricercatori, startup, pubbliche amministrazioni — in contrasto con il regime più restrittivo storicamente adottato da HL7 International.

Prime implementazioni open source

La DSTU 1 è accompagnata fin dall’inizio da implementazioni di riferimento aperte:

• HAPI FHIR — libreria Java, sviluppata da James Agnew (University Health Network) come estensione dell’ecosistema HAPI nato per HL7 v2. Copre client, parser, server, con API di alto livello
• Spark — reference server open source in .NET sviluppato da Furore (Olanda) sotto la guida di Ewout Kramer, uno dei principali contributori dello standard
• fhir-net-api — libreria client/server .NET, ancora di origine Furore
• FHIR Test Server pubblico di University Health Network, usato per interoperability testing nei Connectathon

A questi si affiancano strumenti di modellazione come Forge per la costruzione di profili, e validator a linea di comando distribuiti da HL7.

Cosa significa per l’Italia e l’Europa

Al 2014 l’adozione di FHIR nel contesto italiano è ancora a livello esplorativo. I programmi FSE regionali si basano su CDA R2, e le regole tecniche nazionali — in arrivo con il DPCM attuativo dell’articolo 12 del DL 179/2012 — sono disegnate su documenti CDA. FHIR entra per ora come oggetto di interesse nei gruppi di lavoro HL7 Italia, con valutazioni su possibili profili italiani e casi d’uso dove l’API REST offrirebbe un valore aggiunto rispetto al documento firmato (patient summary consultabili, accesso dati paziente da app, interfaccia programmatica per trial clinici).

Il DSTU 1 è esplicitamente una base per raccogliere feedback: HL7 ha dichiarato che le revisioni successive porteranno modifiche non retrocompatibili in alcune aree. Nelle intenzioni della comunità, è l’inizio di un percorso pluriennale di stabilizzazione che attraverserà diversi passaggi DSTU prima di una versione Normative stabile.

Riferimenti: HL7 FHIR DSTU 1, approvato ANSI 17 febbraio 2014. HL7 International. HAPI FHIR (University Health Network). Spark / fhir-net-api (Furore). Licenza Creative Commons CC0.