HL7 FHIR R4: la prima release Normative e la corsa all'interoperabilità

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 →

Dal “Trial Use” al “Normative”

A quasi cinque anni dalla pubblicazione della DSTU 1, HL7 ha rilasciato il 30 dicembre 2018 la Release 4 di FHIR — versione 4.0.0 dello standard. Quattro passaggi intermedi — DSTU 1, DSTU 2, STU 3 — hanno permesso di raccogliere feedback, rompere la retrocompatibilità dove necessario, e consolidare le parti più stabili.

R4 è la prima release che introduce il concetto di contenuto Normative: per un insieme di risorse e di componenti infrastrutturali, HL7 assume un impegno esplicito di retrocompatibilità all’interno della stessa famiglia R4 e nelle release future. Questa è una differenza qualitativa rispetto alle precedenti DSTU/STU: chi costruisce su un componente Normative ha una base tecnica stabile che non verrà rotta in modo unilaterale.

Cosa è Normative in R4

Il set Normative al debutto di R4 comprende l’infrastruttura di base — Resource, Extension, i tipi di dato primitivi, le convenzioni di rappresentazione XML e JSON — e l’API REST completa (read, vread, update, patch, delete, history, create, search, capabilities, transaction, batch).

Tra le risorse cliniche, entrano in stato Normative in R4 alcune delle più centrali:

• Patient — anagrafica del paziente
• Observation — osservazioni cliniche (misurazioni, rilevazioni, referti di laboratorio, vital signs)
• Encounter — contatti clinici (visite, ricoveri, teleconsulti)
• Condition — diagnosi e problemi
• Practitioner, Organization, Location
• AllergyIntolerance
• DiagnosticReport
• Medication, MedicationRequest, MedicationStatement

Il resto del contenuto — circa il 60% delle risorse — rimane in stato Trial Use (STU), con segnalazione esplicita del livello di maturità per ogni risorsa (Maturity Level 0-5, FMM).

SMART on FHIR

Parallelamente alla stabilizzazione di R4, lo stack FHIR si è arricchito di specifiche che standardizzano scenari applicativi tipici. La più rilevante è SMART on FHIR — Substitutable Medical Applications, Reusable Technologies — iniziativa del gruppo di Boston Children’s Hospital e Harvard Medical School guidata da Josh Mandel e Ken Mandl.

SMART definisce un profilo di autenticazione e autorizzazione basato su OAuth 2.0 e OpenID Connect, per permettere a un’applicazione di terze parti (“SMART app”) di accedere ai dati FHIR di un paziente o di un professionista in modo controllato:

• SMART App Launch Framework — sequenza di handshake per il lancio dell’app dal contesto di una cartella clinica (EHR launch) o da un portale paziente (standalone launch)
• Scope granulari — patient/Observation.read, user/*.read, launch/patient, offline_access
• OpenID Connect per l’identità dell’utente
• Supporto per backend services con client credential grant (SMART Backend Services, rilevante per l’accesso a grandi volumi di dati)

SMART è oggi il meccanismo di autorizzazione di riferimento per le app cliniche che consumano FHIR; i principali vendor EHR americani (Epic, Cerner, Allscripts) espongono endpoint SMART on FHIR certificati.

CDS Hooks

Dove SMART on FHIR risolve il “come l’app accede ai dati”, CDS Hooks — specifica v1.0 pubblicata nel 2018 — risolve il “come la cartella clinica si interfaccia con servizi esterni di supporto alle decisioni”. Il modello:

• La cartella clinica espone dei hook (patient-view, medication-prescribe, order-sign, order-select) che si attivano in specifici punti del flusso clinico
• I CDS Services remoti (ospitati da vendor, payer, istituzioni di ricerca) ricevono un contesto FHIR e restituiscono Card (raccomandazioni testuali, suggerimenti, link ad app SMART)
• La cartella integra le Card nell’interfaccia, mantenendo il medico al centro della decisione

CDS Hooks completa così un ecosistema in cui i dati FHIR diventano il punto di ingresso per logiche di supporto clinico distribuite, senza che ogni cartella debba ospitare il proprio motore di regole.

Bulk Data Access

Un altro tassello in sviluppo al momento della R4 è FHIR Bulk Data Access (Flat FHIR): specifica per l’esportazione asincrona di grandi volumi di dati FHIR, tipicamente per analitica e ricerca. Il formato di output è NDJSON (newline-delimited JSON), con un endpoint $export asincrono e un meccanismo di polling per il recupero. La specifica è in stato STU al momento della R4, ma di fatto molte implementazioni server la supportano già.

Bulk Data è la risposta di FHIR al bisogno di data lake e pipeline analitiche: anziché interrogare milioni di risorse una per una via REST, si esporta un dump fotografato a una data e si processa offline.

US Core, Argonaut e la spinta regolatoria USA

L’adozione di FHIR R4 negli Stati Uniti è accelerata da un fattore regolatorio preciso. Negli Stati Uniti, il 21st Century Cures Act del 2016 ha affidato a ONC (Office of the National Coordinator for Health IT) il compito di definire requisiti di interoperabilità per le Certified Health IT. A febbraio 2019 ONC ha pubblicato un Notice of Proposed Rulemaking che propone FHIR R4 come standard obbligatorio per l’API delle cartelle cliniche certificate, con riferimento a USCDI (United States Core Data for Interoperability) come dataset clinico minimo.

La finalizzazione della regola è attesa nel corso del 2019/2020. Se confermata, renderà FHIR R4 de facto lo standard di scambio sanitario negli USA, con effetti di trascinamento anche sui mercati non americani. Il lavoro del Argonaut Project — consorzio avviato nel dicembre 2014 tra vendor EHR e organizzazioni sanitarie — ha preparato il terreno con profili d’uso concordati, confluiti in US Core Implementation Guide.

Le implementazioni open source

L’ecosistema implementativo è ormai ampio e maturo:

• HAPI FHIR (James Agnew, University Health Network) — continua ad essere la reference implementation in Java. Versione 4.x già disponibile con supporto completo R4, comprende server JPA, client, validator, terminology server
• Firely .NET SDK — libreria .NET mantenuta da Firely (ex Furore, Olanda), erede di fhir-net-api; Firely distribuisce anche Vonk Server (commerciale con componenti open)
• Microsoft FHIR Server for Azure — server open source basato su .NET Core, rilasciato nell’ottobre 2018 su GitHub con licenza MIT, supporto PostgreSQL e Cosmos DB come backend
• IBM FHIR Server — server open source rilasciato sempre nell’ottobre 2018, Java, licenza Apache 2.0
• Google Cloud Healthcare API — non open source, ma espone API FHIR R4 conformi come servizio gestito
• HL7 FHIR Validator a riga di comando — strumento ufficiale di validazione

La presenza contemporanea di Microsoft, IBM, Google con offerte FHIR è un indicatore della direzione del mercato cloud per la sanità.

Cosa significa in Europa

In Europa il quadro è più frammentato. A livello di Unione, non esiste al 2019 una norma equivalente al 21st Century Cures Act; le direttive eHealth lavorano su ambito cross-border con profili propri (eHDSI usa CDA R2 per il patient summary e l’e-prescription, evoluzione verso FHIR in discussione). I singoli Stati membri procedono a velocità diverse: UK con NHS Digital Care Connect basato su FHIR STU3, Germania con gematik e la specifica gemSpec, Paesi nordici con profili FHIR per interoperabilità nazionale.

In Italia l’adozione di FHIR al 2019 è esplorativa. HL7 Italia ha costituito gruppi di lavoro su profili FHIR italiani ma non ci sono ancora Implementation Guide nazionali pubblicate con lo stato di documenti ufficiali di riferimento. Il FSE resta ancorato a CDA R2; la riflessione sull’adozione di FHIR per il FSE di seconda generazione è in corso ma attende decisioni di indirizzo.

Cosa cambia

Con R4 FHIR esce dalla fase di sperimentazione e diventa una pila tecnica su cui costruire sistemi produttivi con orizzonti pluriennali. Il triplo meccanismo — risorse REST stabili + SMART on FHIR per autorizzazione + CDS Hooks per workflow esterni — compone un modello di interoperabilità non soltanto di scambio documentale, ma di integrazione applicativa: un’app esterna può leggere lo stato clinico del paziente, proporre azioni, registrare decisioni, tornare alla cartella senza che la cartella debba conoscere in anticipo quell’app.

È un cambiamento di paradigma che in medicina ha implicazioni ben oltre la tecnologia, sulle modalità con cui il software clinico viene costruito, certificato, aggiornato. Le prossime tappe riguarderanno la maturazione delle Implementation Guide nazionali in Europa, l’integrazione con i meccanismi di identità digitale degli Stati membri, e l’evoluzione del ruolo regolatorio — con MDR e l’imminente riflessione europea sull’AI in ambito sanitario che si intrecciano con le scelte tecniche di piattaforma.

Riferimenti: HL7 FHIR Release 4 (30 dicembre 2018). SMART App Launch Framework, Boston Children’s Hospital / Harvard Medical School. CDS Hooks 1.0. FHIR Bulk Data Access STU. US Core Implementation Guide. HAPI FHIR, Firely, Microsoft FHIR Server for Azure, IBM FHIR Server. ONC Notice of Proposed Rulemaking, febbraio 2019.