HL7 ha promosso FHIR a Draft Standard for Trial Use 1 con la ballot ANSI del 17 febbraio 2014, e la specifica circola come versione v0.0.82. È il primo standard HL7 a modellare le entità cliniche come risorse interrogabili via HTTP in XML o JSON, anziché come segmenti separati da pipe o documenti firmati. Dopo qualche anno passato a scrivere parser per messaggi v2 e a leggere documenti CDA, mi sono preso il tempo di annotare dove il modello cambia davvero.

Contesto

Chi integra sistemi sanitari in Italia lavora quasi sempre con due famiglie di standard. La prima è HL7 v2, il formato dei messaggi ADT, ORM, ORU che attraversano l’ospedale: segmenti separati da |, capillare ma non auto-descrittivo, e dipendente da accordi locali su quali campi e quali Z-segment usare. La seconda è CDA R2 — Clinical Document Architecture, costruita sopra il Reference Information Model di HL7 v3 — che fa da base tecnica ai documenti del Fascicolo Sanitario Elettronico regionale: rigorosa, espressiva, ma con una curva di implementazione ripida e un’adozione reale sotto le aspettative dichiarate a inizio anni Duemila.

Nel frattempo il resto dell’integrazione applicativa si è spostato su API HTTP, JSON come formato di scambio e OAuth per l’autorizzazione. Gli strumenti rivolti al paziente e i prodotti EHR, soprattutto negli Stati Uniti, chiedevano un punto di accesso ai dati clinici con le stesse convenzioni del resto del web. FHIR — Fast Healthcare Interoperability Resources, avviato intorno al 2011 da Grahame Grieve dentro HL7 — nasce per rispondere a questa richiesta.

Architettura

L’unità di base è la Resource: un’entità clinica o organizzativa con un tipo, un’identità e un URL. DSTU 1 ne definisce un insieme ristretto di tipi fondamentali, tra cui Patient, Practitioner, Encounter, Observation, Condition, Procedure, DiagnosticReport, Immunization, AllergyIntolerance, MedicationPrescription, MedicationDispense, MedicationAdministration, Organization, Location, Device, DocumentReference. Segnalo il nome MedicationPrescription: in questa versione l’ordine di terapia si chiama così, non con il nome che prenderà nelle revisioni successive.

Ogni risorsa è esposta secondo le convenzioni HTTP, sullo schema [base]/[Tipo]/[id]:

GET    [base]/Patient/example
POST   [base]/Patient
PUT    [base]/Patient/example
DELETE [base]/Patient/example
GET    [base]/Patient/example/_history

Le risorse si referenziano a vicenda tramite reference e si aggregano in Bundle, il contenitore usato per i risultati di ricerca, i documenti, i messaggi e le transazioni. Ci sono due serializzazioni equivalenti, XML e JSON, con schemi pubblicati e un mapping reciproco. Una Patient in JSON resta sull’ordine delle poche decine di righe:

{
  "resourceType": "Patient",
  "identifier": [{
    "system": "urn:oid:2.16.840.1.113883.2.9.4.3.2",
    "value": "RSSMRA50T25H501U"
  }],
  "name": [{ "use": "official", "family": ["Rossi"], "given": ["Mario"] }],
  "gender": { "coding": [{ "system": "http://hl7.org/fhir/v3/AdministrativeGender", "code": "M" }] },
  "birthDate": "1950-12-25"
}

Ogni risorsa porta anche una sezione text con una narrativa in XHTML: l’informazione strutturata resa in forma leggibile da una persona, eredità diretta del principio di leggibilità di CDA R2. Così un sistema ricevente può mostrare il contenuto anche quando non sa interpretare tutti i campi strutturati.

La ricerca passa per i parametri HTTP. La richiesta

GET [base]/Observation?subject=Patient/example&name=http://loinc.org|1558-6

restituisce un Bundle con le osservazioni che soddisfano i criteri. I parametri ammettono modificatori (:exact, :missing), prefissi per i confronti numerici e di data, e ricerca concatenata sui riferimenti; con _include il bundle si porta dietro anche le risorse referenziate, e si risolvono in una sola chiamata.

Punto critico

Quel che merita più attenzione non è il trasporto REST, ma il modo in cui lo standard gestisce ciò che non copre. FHIR dichiara di modellare nel core l’insieme di elementi comuni alla maggior parte delle implementazioni, e di lasciare il resto a un sistema uniforme di Extension: ogni risorsa può portare attributi aggiuntivi identificati da un URL, senza che questo rompa la lettura da parte di un sistema che non li conosce. È la differenza concreta rispetto agli Z-segment di v2, dove l’estensione locale è opaca e priva di una definizione recuperabile.

Sopra a questo sta il Profile, serializzato come risorsa Profile: la definizione formale di come le risorse di base vanno ristrette, estese e vincolate per un dato contesto d’uso. Un profilo lo legge una macchina, quindi la conformità di un’istanza a un profilo si verifica in automatico. È la parte su cui DSTU 1 è apertamente acerba: il meccanismo c’è, ma è poco esercitato, e gli stessi profili di esempio cambieranno.

La qualifica Draft va presa alla lettera. La pagina sullo status DSTU della specifica avverte che durante la fase DSTU non c’è alcun impegno di compatibilità all’indietro o in avanti, e che le modifiche potranno essere anche strutturali — risorse rifattorizzate, regole di serializzazione cambiate, tipi di dato aggiunti o rimossi. HL7 mette in conto almeno due rilasci DSTU, a circa un anno di distanza, prima che una parte della specifica diventi Normative.

Implicazioni

Per chi integra in Italia, oggi, la ricaduta pratica è limitata. I programmi FSE regionali poggiano su CDA R2, e le regole tecniche in arrivo con il decreto attuativo dell’articolo 12 del DL 179/2012 sono disegnate sui documenti, non su API a risorse. FHIR entra come oggetto di valutazione nei gruppi HL7, in particolare dove un’interfaccia programmatica dà qualcosa che il documento firmato non dà: consultare un patient summary da un’applicazione, accedere ai dati di un paziente da strumenti esterni, raccogliere dati negli studi clinici.

La licenza abbassa la soglia di sperimentazione: specifica, schemi ed esempi escono come Creative Commons CC0, dominio pubblico, senza le restrizioni storicamente legate ai prodotti HL7 International. Esistono già implementazioni di riferimento aperte su cui provare il modello: HAPI FHIR, libreria Java scritta da James Agnew alla University Health Network come estensione dell’ecosistema HAPI nato per v2, e Spark, server di riferimento in .NET scritto da Furore con il contributo di Ewout Kramer, anche lui tra gli autori dello standard.

Limiti

DSTU 1 va presa per quello che dichiara di essere: una base per raccogliere feedback dai primi implementatori, non un bersaglio stabile. Chi costruisce qualcosa sopra v0.0.82 deve mettere in conto che alcune risorse e alcune regole cambieranno in modo non retrocompatibile, a partire da nomi come MedicationPrescription. La copertura clinica è parziale, e i terminology binding ai vocabolari (LOINC, SNOMED CT) sono indicati ma non ovunque vincolanti. Esporre una risorsa via REST non risolve, da solo, identità del paziente, consenso e tracciamento degli accessi: restano da progettare fuori dal modello dei dati.

https://www.hl7.org/fhir/DSTU1/ https://www.hl7.org/fhir/DSTU1/dstu.html https://www.hl7.org/fhir/DSTU1/patient.html https://www.hl7.org/fhir/DSTU1/medicationprescription.html https://www.hl7.org/fhir/DSTU1/http.html https://www.hl7.org/fhir/DSTU1/search.html https://hapifhir.io/ https://www.noze.it/insights/hl7-fhir-dstu1-nascita/

Immagine di copertina: Diagramma di risorse FHIR collegate tra loro da riferimenti, ciascuna composta da elementi dati che descrivono un concetto clinico — diagramma di Tertius3, CC BY-SA 4.0 — https://commons.wikimedia.org/wiki/File:FHIR_resource_graph.png