FHIR non ha risolto l'interoperabilità sanitaria

Un nuovo fondatore di health-tech legge di FHIR per la prima volta e si fa brevemente ottimista. Esiste uno standard. Lo standard è moderno. Lo standard è basato su REST, strutturato in JSON e autenticato con OAuth. Sicuramente questo significa che l'integrazione con i sistemi EHR è un problema risolto.

Poi integra davvero con il primo EHR, e nel giro di una settimana l'ottimismo è svanito. Lo standard esiste. Le implementazioni non concordano su di esso. Il divario tra "FHIR-compatible" sulla pagina marketing e "parla con questo specifico deployment di Epic" nella pratica è enorme, ed è lì che vive il vero lavoro di integrazione.

A cosa serve FHIR

Lo standard in sé è un vero risultato. Definisce la forma delle risorse per le entità che contano in ambito sanitario — pazienti, osservazioni, condizioni, farmaci, incontri — in un modo ragionevolmente moderno, ragionevolmente estensibile e molto più lavorabile delle alternative precedenti.

Se si costruisce da zero, FHIR è la scelta giusta. Il proprio modello di dati interno finirà per assomigliare a FHIR anche se non si parte da lì, quindi partire da lì risparmia la riscrittura inevitabile.

Se si costruisce uno strumento generico che consuma "dati FHIR" senza curarsi di quale sistema li produce, lo standard porta forse all'80% del percorso. Per demo, prototipi e lavoro accademico è sufficiente.

Dove iniziano i problemi

I problemi iniziano quando si deve parlare con un vero EHR in una vera rete ospedaliera. Ci sono tre divari distinti.

Il divario specifico del fornitore. Epic, Cerner, Meditech e Athena espongono tutti endpoint FHIR. Non espongono tutti lo stesso FHIR. Ognuno ha le proprie peculiarità — campi richiesti dallo standard ma assenti nei loro dati, estensioni che esistono nella loro versione ma da nessun'altra parte, campi popolati con significati diversi in deployment diversi. Il cliché del settore è "se hai visto un Epic, hai visto un Epic." È un cliché perché è vero.

Il divario specifico del deployment. Anche all'interno dello stesso fornitore, ogni ospedale configura il sistema in modo diverso. Due deployment di Epic in due sistemi sanitari diversi restituiranno dati conformi allo standard ma con significati sottilmente diversi. Il modo in cui un sito usa un particolare codice di osservazione potrebbe sovrapporsi a come un altro sito usa uno completamente diverso. Senza conoscenza clinica locale, i dati sono corretti e incomprensibili allo stesso tempo.

Il divario dei dati storici. FHIR è moderno. I dati non lo sono. La maggior parte dei dati clinici in qualsiasi EHR di produzione precede l'era FHIR ed era originariamente codificata in HL7 v2, ICD-9, dizionari personalizzati o testo libero. L'endpoint FHIR si trova sopra un livello di traduzione, e quel livello è incompleto, con perdite di informazione e pieno di casi limite. Chiedere "quali farmaci ha mai preso questo paziente?" tramite FHIR restituirà una lista. Se la lista sia completa è una domanda separata, e la risposta è quasi sempre no.

Cosa funziona davvero

Abbiamo rilasciato molte integrazioni EHR. Alcune cose che hanno retto nel tempo.

Trattare FHIR come punto di partenza, non come contratto. Costruire il proprio modello di dominio nel modo in cui dovrebbe apparire. Poi costruire un livello di traduzione tra FHIR e il proprio modello, e trattare quel livello come la parte più fragile e più testata della codebase. Lo è.

Testare con dati reali (de-identificati), non con la sandbox. Le sandbox dei fornitori contengono dati idealizzati di cui il team marketing del fornitore non si vergognerebbe. I dati di produzione non sono così. Ottenere accesso a dati reali rappresentativi — anonimizzati, con i giusti BAA in atto — ed eseguire il proprio codice contro di essi prima di andare live. I bug che si trovano in questo modo sono quelli che i clienti avrebbero trovato nella prima settimana.

Costruire per la degradazione elegante, non per la completezza. Alcuni pazienti avranno dati. Altri no. Alcuni campi saranno popolati. Altri no. La maggior parte del software sanitario fallisce in produzione non perché i dati sono sbagliati, ma perché il software assume che ci siano dati che non ci sono. Scrivere codice in modo difensivo, comunicare onestamente le lacune agli utenti, e non fare mai silenziosamente default su "nessun valore" quando la risposta potrebbe essere "non lo sappiamo."

Avere qualcuno con competenza clinica nel team. I dati sono medici. Le decisioni su cosa fare quando i dati sono ambigui sono decisioni mediche. Se il team non riesce a distinguere tra una lacuna clinicamente significativa e una insignificante, il prodotto prenderà silenziosamente decisioni che nessun clinico approverebbe.

Il riassunto onesto

FHIR non ha risolto l'interoperabilità sanitaria. Ha reso possibile il prossimo decennio di lavoro, che è una cosa diversa e più accurata da dire. Il vero lavoro di integrazione — quello che richiede tempo, quello che tiene insieme la produzione — si trova sopra FHIR, non dentro di esso. Chiunque dica il contrario o non ha mai rilasciato una vera integrazione, o ne sta vendendo una.