Con la Release 4 di FHIR, pubblicata da HL7 a fine dicembre 2018, per la prima volta una parte dello standard supera un ballot Normative e va in sottomissione ad ANSI come standard normativo. La build 4.0.0 porta la data del 27 dicembre, l’annuncio sul blog HL7 è dei primi di gennaio 2019. Per chi scrive software clinico la notizia non sono le risorse nuove, ma il fatto che alcune parti dello standard arrivino con un impegno esplicito a non rompere la retrocompatibilità nelle release successive.

Contesto

FHIR — Fast Healthcare Interoperability Resources — nasce nel 2011 dal tentativo di HL7 di aggirare i limiti pratici di HL7 v2 e di CDA (Clinical Document Architecture), spostando il modello dati sanitario su un’API REST con rappresentazioni JSON e XML. Le release fino a qui — DSTU 1 (2014), DSTU 2 (2015), STU 3 (2017) — sono state tutte Trial Use: buone per implementare, ma con la libertà dichiarata di rompere la compatibilità a ogni salto. Chi aveva scritto un client contro STU 2 sapeva di dover mettere mano al codice per passare a STU 3, e ha dovuto farlo.

È qui che interviene R4. Una specifica che si riscrive a ogni release va benissimo per sperimentare, molto meno per sistemi che devono restare in produzione per anni in un dominio — quello clinico — dove il software si sostituisce di rado e certificare costa.

Cosa è Normative in R4

Il set Normative al debutto di R4 è ristretto di proposito. Riguarda l’infrastruttura di base e l’API, non il grosso delle risorse cliniche:

  • l’API REST nel suo insieme — read, vread, update, create, delete, history, search, capabilities, transaction, batch
  • le rappresentazioni XML e JSON
  • i tipi di dato primitivi e l’infrastruttura di base (Resource, le estensioni, le convenzioni di serializzazione)
  • il layer di terminologia e il conformance framework (StructureDefinition, CapabilityStatement, ValueSet, CodeSystem)

Sul lato delle risorse cliniche lo stato Normative tocca un nucleo piccolo: in particolare Patient e Observation. Tutto il resto resta Trial Use, ciascuna risorsa con un suo livello di maturità dichiarato — il FHIR Maturity Model (FMM), da 0 a 5 — che dice quanto quella risorsa è stata messa alla prova sul campo. Una risorsa centrale nei flussi reali come MedicationRequest o DiagnosticReport, per quanto diffusa nelle implementazioni, in R4 resta formalmente STU.

In pratica l’impegno di retrocompatibilità copre la meccanica dello scambio — come si parla al server, come si serializza una risorsa, come il server dichiara cosa offre — ma copre il contenuto clinico solo in parte. Un’applicazione che si appoggia alla struttura di Observation ha terreno stabile; una che si appoggia alla forma esatta di una risorsa STU sa che quella forma può ancora cambiare.

Il punto critico: una retrocompatibilità con un perimetro

«Normative» in FHIR vuol dire una cosa precisa e circoscritta: le modifiche future a un artefatto Normative non romperanno le implementazioni conformi esistenti. Non vuol dire che l’artefatto sia completo, né che copra ogni caso d’uso, né che le risorse correlate ancora STU siano stabili.

Questo perimetro va letto con calma, per due motivi.

Il primo: la stabilità dell’API non porta con sé la stabilità del dato. Posso scrivere un client contro l’API REST Normative e avere la garanzia che search e read continueranno a rispondere nelle release future; ma se quel client interpreta il payload di una risorsa STU, l’evoluzione di quella risorsa lo tocca comunque. La promessa Normative protegge il trasporto più del significato.

Il secondo: FHIR ammette estensioni dappertutto. La flessibilità che lo rende adottabile in contesti diversi — ogni elemento può portare estensioni, ogni risorsa può essere profilata — è anche ciò che lega l’interoperabilità reale ai profili concordati, non alla sola conformità al core. Due server entrambi conformi a R4 possono restare non interoperabili se riempiono gli stessi campi in modo diverso o si appoggiano a estensioni diverse. Lo stato Normative del core non scioglie questo nodo: lo sposta sui profili.

Implicazioni: dove si gioca l’interoperabilità reale

Per questo il lavoro che pesa non sta solo nel core della specifica, ma negli Implementation Guide che ne vincolano l’uso a un contesto. Negli Stati Uniti era già in moto: lo US Core Implementation Guide, erede dei profili concordati dal progetto Argonaut (un consorzio di vendor EHR e organizzazioni sanitarie partito nel 2014), fissa quali risorse, quali campi e quali vocabolari un sistema deve gestire per dirsi interoperabile su quel mercato.

Sopra al core FHIR si stanno assestando anche specifiche applicative, che non toccano il modello dati ma il modo in cui le applicazioni ci dialogano. SMART App Launch definisce, su OAuth 2.0 e OpenID Connect, come un’applicazione di terze parti ottiene un accesso controllato ai dati FHIR a partire dal contesto di una cartella clinica o di un portale paziente, con scope granulari (patient/Observation.read, launch/patient). CDS Hooks — la cui prima specifica stabile, la 1.0, è del 2018 — definisce come una cartella clinica chiama servizi esterni di supporto alle decisioni in punti precisi del flusso (patient-view, medication-prescribe) e ne riceve indicazioni testuali. Sono pezzi distinti dal core, con un loro ciclo di maturità, ma è la loro combinazione con R4 a fare di FHIR una base per l’integrazione applicativa e non solo per lo scambio documentale.

Sul fronte regolatorio statunitense, a febbraio 2019 ONC (Office of the National Coordinator for Health IT) ha emesso un Notice of Proposed Rulemaking — pubblicato nel Federal Register il 4 marzo 2019 — che propone di adottare FHIR R4 come standard per le API delle cartelle cliniche certificate, con USCDI (United States Core Data for Interoperability) come dataset clinico minimo. La regola non è ancora definitiva, ma la direzione è dichiarata: se confermata, lega la certificazione del software sanitario USA a R4.

L’ecosistema implementativo va nella stessa direzione. HAPI FHIR (in Java, Apache 2.0) gestisce R4; il Firely .NET SDK copre lo stack .NET; sia Microsoft sia IBM hanno rilasciato a fine 2018 server FHIR Open Source. Trovare insieme questi attori sullo stesso standard è già di per sé un segnale sull’adozione attesa.

Limiti

R4 è la prima release Normative, non una release interamente Normative: il grosso delle risorse cliniche resta STU, e nelle scelte di progetto va trattato come tale. In Europa il quadro è più frammentato — al 2019 non c’è un equivalente del 21st Century Cures Act, lo scambio cross-border (eHDSI) si regge ancora su CDA R2, e i singoli Stati vanno a velocità diverse; in Italia l’adozione di FHIR è esplorativa e il Fascicolo Sanitario Elettronico resta ancorato a CDA R2. Lo stato Normative di una parte dello standard è una condizione necessaria per costruire sistemi con orizzonti pluriennali, ma da sola non produce interoperabilità: quella continua a dipendere da profili concordati, terminologie condivise e vincoli regolatori che, fuori dagli Stati Uniti, restano in larga parte da scrivere.

Immagine di copertina: Diagramma concettuale dell’architettura FHIR: un medico e un paziente collegati attraverso una FHIR API REST e un FHIR Health Server… — diagramma di ClinDCast, CC0 — https://commons.wikimedia.org/wiki/File:FHIR_Academy_-_ClinDCast.webp