5 Sfide dell’integrazione HL7 (e come risolverle)

Comprensione delle interfacce HL7

Le specifiche delle interfacce HL7 includono specifiche di dati per vari tipi di messaggistica, come ADT, ORM o ORU (tra gli altri). Un’interfaccia HL7 consiste di alcuni componenti chiave:

• Un endpoint di esportazione (per l’applicazione che invia il messaggio)
• Un endpoint di importazione (per l’applicazione che riceve il messaggio)
• Un metodo di trasferimento dati (per spostare i dati tra i due endpoint)

Ci sono alcuni problemi con le interfacce HL7 che rendono questa configurazione molto più problematica di quanto sembri in superficie. In primo luogo, i moduli di invio e ricezione sono creati dai fornitori di software durante il processo di sviluppo dell’applicazione. Poiché HL7 permette un’ampia personalizzazione, le applicazioni spesso usano diversi formati HL7. In effetti, ci sono molte varianti e adattamenti degli standard di interfaccia HL7, quindi non c’è un unico standard per come questi sistemi sono implementati o come i dati sono gestiti. E questo significa che per permettere alle applicazioni di inviare e ricevere dati che possono capire, è necessaria la traduzione e la mappatura dei dati.

Ci sono alcune opzioni per affrontare queste preoccupazioni:

• Modificare i moduli di invio e ricezione
• Utilizzare un motore di interfaccia per tradurre i messaggi
• Implementare una soluzione API

Diamo uno sguardo più da vicino alle sfide di integrazione HL7 e come superarle.

Le sfide di integrazione HL7

1. I medici non lasceranno la piattaforma EHR, accederanno a un sistema non correlato e duplicheranno i dati che sono già nell’EHR. Semplicemente non è pratico o efficiente, e i medici sono già sotto pressione per fare di più in meno tempo. Non importa quanto possa essere utile l’applicazione, se richiede loro di duplicare i loro sforzi, semplicemente non la useranno se non si adatta al loro flusso di lavoro. Quindi, le applicazioni devono essere facilmente accessibili ai medici ed eliminare la necessità di duplicazione dei dati. Dovrebbero anche avere un’integrazione a circuito chiuso, con i dati che vengono estratti e inseriti nell’EHR. I team IT hanno tipicamente degli arretrati significativi, il che significa che le organizzazioni potrebbero aspettare mesi (o anni) per costruire le interfacce necessarie per queste integrazioni.

2. C’è una variazione significativa nel modo in cui i fornitori implementano gli standard HL7.

La varianza sostanziale nell’implementazione HL7 rallenta i cicli e rende l’integrazione sia lunga che costosa. Essenzialmente, richiede il mantenimento di una base di codice diversa e punti di integrazione per ogni EHR. Inoltre, richiede risorse significative dedicate allo sviluppo dell’integrazione, il che significa meno risorse disponibili per altre esigenze, come il miglioramento delle caratteristiche e delle funzionalità. Inoltre, la sostituzione o l’aggiunta di interfacce ha un impatto su ogni applicazione che si interfaccia con l’app aggiornata – potenzialmente con un impatto sull’intero sistema. Ogni endpoint per l’app aggiornata deve essere creato o cambiato per facilitare la comunicazione, e ogni fornitore di software con interfacce collegate all’app deve sostituire o modificare i propri endpoint, pure.

3. Una migliore integrazione è necessaria per creare app migliori.

La mancanza di un monitoraggio centralizzato significa che più tempo e denaro devono essere dedicati al monitoraggio. I problemi possono passare inosservati fino a quando non sono diventati una vera e propria crisi, e anche allora, è difficile individuare la fonte del problema. C’è una mancanza di informazioni significative a livello di sistema disponibili in modo tempestivo, quindi non c’è un modo efficace per valutare lo stress complessivo di un sistema. A sua volta, questo rende difficile stimare le esigenze di risorse come la dimensione del server, le comunicazioni di rete e il personale di supporto. Più dati in tempo reale e capacità di lettura-scrittura sono disperatamente necessari.

4. La scarsa semantica dei dati HL7 lascia la porta aperta a interpretazioni errate.

Nel complesso panorama sanitario di oggi, è imperativo che le applicazioni non solo comprendano i valori dei dati, ma ciò che quei valori effettivamente significano. Per evitare interpretazioni errate, le interfacce HL7 devono comunicare la loro interpretazione dello standard di interfaccia HL7 utilizzato. Per esempio, un valore di “NA” significa “Nessuna allergia” o “Non applicabile”? Un valore di “3” può indicare che un paziente è un fumatore attuale in un sistema, ma in un altro, quello stesso valore potrebbe significare che il paziente è un ex fumatore o non ha mai fumato. Queste interpretazioni errate, e la qualità generale dei dati, hanno serie implicazioni per la fornitura di cure ai pazienti. Poiché i sistemi sanitari di oggi sono sempre più regionali, con più punti di contatto con il paziente, la corretta interpretazione dei dati è ancora più critica.

5. La migrazione a un nuovo EHR può comportare una perdita di dati legacy.

La migrazione a un nuovo EHR rappresenta una sfida anche per le organizzazioni sanitarie. Alcune organizzazioni sanitarie scelgono semplicemente di mantenere più EHR, richiedendo ai medici di accedere a più piattaforme, o peggio, di richiedere record cartacei. Altri decidono di spostare i dati esistenti sul nuovo sistema. Tuttavia, devono dare priorità ai dati per la migrazione. (Quali dati sono più importanti? Quali dati dovrebbero essere spostati per primi?) L’essenziale di base, come i farmaci, le allergie e le diagnosi, sono in genere prioritari per il trasferimento, il che significa che altri dati, come i risultati di laboratorio più vecchi, le immagini e altri dati possono essere lasciati indietro. Inoltre, potrebbe non essere possibile convertire alcuni tipi di dati (come le immagini), o potrebbero esserci errori nei dati dopo la conversione. In generale, la migrazione comporta notevoli costi tecnologici e di risorse, e i tempi di migrazione sono spesso lunghi.

Come risolvere le sfide dell’integrazione HL7

I motori di interfaccia sono una comune soluzione di integrazione HL7, ma non sono in grado di superare queste sfide e di soddisfare gli obiettivi di interoperabilità. Con i motori d’interfaccia, PHI deve essere memorizzato in un secondo database, che introduce inutili rischi per la sicurezza – particolarmente importante nell’era moderna della privacy e della responsabilità dei dati. Il codice deve essere scritto ripetutamente, e l’implementazione in generale è lenta. Inoltre non sono EHR-agnostici, e non forniscono l’accesso ai dati in tempo reale che è così essenziale per i fornitori di assistenza sanitaria oggi.

Fortunatamente, i fornitori di software e i fornitori di assistenza sanitaria possono superare queste sfide con l’uso delle API. Integrate permette lo scambio di informazioni sanitarie attraverso qualsiasi piattaforma EHR senza compromettere la sicurezza di PHI. Supporta lo scambio di informazioni senza soluzione di continuità tra EHRs, applicazioni cliniche e amministrative e fornisce un accesso in tempo reale ai dati clinici e amministrativi. Questo significa accesso in tempo reale alle registrazioni dei pazienti tra i vari fornitori e fatturazione semplificata, che si traduce in una riduzione dei costi grazie alla minore richiesta di tempo da parte del personale.

Integrate dispone di un robusto set di API REST che leggono e scrivono su EHR attraverso moduli software supportati dal fornitore di EHR, standardizzando l’integrazione EHR attraverso API universali e in tempo reale e un modello di dati unificato, più strumenti per aiutare nel monitoraggio e nella gestione dell’ambiente. L’API gestisce l’interfaccia, quindi non c’è bisogno di aspettare nella coda del progetto di integrazione, riducendo il tempo di integrazione da mesi a poche ore. Naturalmente, tutti questi vantaggi non significano nulla se l’usabilità è scarsa. Con Integrate, otterrete un’esperienza utente superiore, quindi non dovrete mai preoccuparvi che gli utenti abbandonino la vostra piattaforma.

La strada verso l’integrazione HL7 ha molti ostacoli, ma le soluzioni API come Integrate mettono la vera interoperabilità alla portata dei fornitori di software e delle organizzazioni sanitarie.