Standard di interoperabilità e schema
Le attività di sviluppo degli standard intraprese dai primi anni 1980 miravano a fornire soluzioni a queste sfide di interoperabilità., Digital Imaging and Communications in Medicine (DICOM®), comitato per gli standard del National Electrical Manufacturers Association (NEMA), è stato uno dei primi a sviluppare uno standard per la comunicazione di imaging medicale informazioni , ora pubblicato dall’Organizzazione Internazionale per la Standardizzazione (ISO12052:2017). Tutti gli standard Health Level Seven (HL7) sono pubblicati da un’organizzazione ufficiale di standard nazionali, l’American National Standards Institute (ANSI)., È importante notare che gli standard HL7 (Health Level Seven) si concentrano sull’interoperabilità tecnica (scambio di dati sanitari) con conseguente interoperabilità operativa (semantica) limitata .
L’ormai molto popolare standard FHIR® (Fast Healthcare Interoperability Resources) ha notevolmente migliorato i flussi di informazioni operative . Il modello di riferimento HL7 FHIR® è definito da una raccolta di modelli di informazioni (risorse). Questi possono essere profilati (o meno) per generare un modello di informazione clinica., Le risorse FHIR® sono prodotte da un superset di dati presenti nei sistemi legacy per essere utilizzate direttamente dagli sviluppatori. A rigor di termini questi non sono “modelli” poiché non viene utilizzata nessuna delle solite ereditarietà, incapsulamento di elementi comuni o pratiche di digitazione. L’uso efficace dello standard FHIR ® dipende dal grado di accordo raggiunto tra le parti. Raggiungere un accordo in questo modo è più facile da raggiungere all’interno delle organizzazioni da un piccolo numero di parti interessate, compresi i medici, che accordi per soddisfare reti più estese. Ciò limita le opportunità di riutilizzo del software .,
Una revisione di sei US Medicare Accountable Care Organisations ha nuovamente evidenziato la necessità di adottare un approccio standard. Si è constatato che coloro che hanno utilizzato un unico sistema di cartelle cliniche elettroniche attraverso le loro reti di fornitori, sono stati in grado di condividere i dati in tempo reale, migliorando la capacità dei fornitori di coordinare le cure. Altri hanno avuto accesso a solidi scambi di informazioni sanitarie che consentono l’accesso ai dati dei pazienti da fornitori esterni. Nonostante questo è stato notato che il pieno potenziale di salute non è stato realizzato.,e il risultato di scarsa interoperabilità compromettere la capacità di cura, con conseguente:
•
Affidamento su altri mezzi di condividere i dati tra telefonate e fax,
•
pesante e frustrante l’uso di EHRs,
•
il Medico di burnout a causa del carico di lavoro associato con EHR gestione,
•
l’Accesso alle informazioni sanitarie scambi con poco o dati incompleti creando difficoltà per quanto riguarda il coordinamento dell’assistenza,
•
Incapacità di offerta di salute per i pazienti di altri di portali online per la loro Ehr,
•
Impossibilità di utilizzare google analytics per personalizzare la cura per adattarsi alle singole esigenze del paziente.,
Un’iniziativa del settore privato sta attualmente intraprendendo un progetto volto a far progredire l’adozione da parte dell’industria di standard di interoperabilità moderni e aperti noti come progetto Argonaut . Lo scopo di questo progetto è quello di sviluppare una API di prima generazione basata su FHIR®e le specifiche dei servizi di dati di base per consentire la condivisione di informazioni espanse per cartelle cliniche elettroniche e altre tecnologie dell’informazione sanitaria basate su standard Internet e modelli e stili architettonici. Questo lavoro è sponsorizzato da numerosi fornitori tra cui Cerner, Epic e Accenture., Lo scopo di questo lavoro è di accelerare lo sviluppo del modello FHIR ® concentrandosi su profili e documentazione FHIR® più specifici, tra cui un focus sulle specifiche di sicurezza e sulla documentazione di accompagnamento per consentire l’interoperabilità tra sistemi proprietari legacy, in cui i loro fornitori controllano contrattualmente l’accesso ai dati. L’uso di queste API crea rischi intrinseci per gli errori e la sicurezza del paziente a causa della mappatura dei dati.
Le organizzazioni sanitarie stanno ora gestendo il rapido assorbimento di FHIR® e il maggiore uso delle API., Dal punto di vista delle infrastrutture nazionali devono esserci i mezzi per facilitare il riutilizzo di alcuni modelli chiave FHIR® utilizzati di frequente. Questi possono essere scelti per diventare standard HL7 approvati. Senza l’adozione di modelli standard concordati ci sarà una proliferazione di modelli FHIR ® sviluppati per soddisfare le esigenze locali, molte ripetizioni e incongruenze che limitano i progressi nazionali complessivi verso il raggiungimento di un ecosistema sanitario digitale ben connesso., I modelli FHIR® non sono conformi alle convenzioni di modellazione ben note come dimostrato da Beale che ha concluso che:
le risorse FHIR sembrano essere il risultato di comitati separati che lavorano con quasi nessun riferimento incrociato, metodologia o base di progettazione comune. Il risultato è che ogni Risorsa è qualcosa di simile a un “sacco di attributi”, presumibilmente a causa dell’applicazione della cosiddetta regola 80/20 nel contesto del comitato.
I modelli FHIR® devono considerare un numero molto grande e ingestibile di punti dati., Questa limitazione è superata con l’adozione di modelli generici che sono perfettamente adatti per la messaggistica ma non per l’archiviazione semanticamente coerente dei dati clinici. Il contesto è parte integrante del modo in cui i medici elaborano le informazioni. Il contesto deve essere considerato quando si sviluppano sistemi di supporto alle decisioni o di intelligenza artificiale, quando si adottano varie strategie di analisi dei dati e per qualsiasi numero di standard pertinenti, inclusi quelli utilizzati per la mappatura dei dati.,
Si dice che le risorse FHIR® contengano un continuum di livelli ontologici, hanno due caratteristiche indesiderabili in un modello di informazione stabile:
volatilità — le risorse clinicamente specifiche dovranno chiaramente cambiare nel tempo. Come questo influenza i profili dipendenti è una domanda interessante;
apertura-si deve presumere che l’insieme delle risorse continuerà semplicemente a crescere per accogliere nuove importanti categorie di informazioni cliniche.,
Le conseguenze di questi fattori sono che il modello non è “mai finito” e che qualsiasi database o software basato su di esso avrà anche bisogno di una manutenzione continua. C’è un altro problema associato alle informazioni a valle: l’elaborazione per l’uso secondario dei dati. Questa è un’incapacità di sapere se le strutture di dati che sembrano essere quasi le stesse possono essere trattate allo stesso modo; l’impostazione predefinita con FHIR è che ogni Risorsa è la sua cosa ., Un esperto di standard internazionali ha osservato che:
FHIR® è stato progettato e inteso come standard API / interchange, la maggior parte delle principali organizzazioni ITC (Google, Microsoft, IBM, ecc.) e almeno un importante fornitore EHR (Cerner) hanno abbracciato FHIR® come schema di oggetti di persistenza e schema di datastore. FHIR ® rimane sottospecificato a livello internazionale, poiché l’associazione dei set di valori è relegata alle guide di implementazione (ad esempio la guida all’implementazione FHIR® Core degli Stati Uniti)., Date le attuali predisposizioni nazionali verso i codici HIT (National Health Information Technology) (praticamente ogni paese ha la propria maledetta pubblicazione di codici di procedura, e stranamente il mondo intero non sta ancora usando ICD11) questa separazione è altamente pragmatica. Gli ostacoli all’interoperabilità internazionale hanno meno a che fare con le specifiche tecniche di sintassi e molto più a che fare con la tendenza quasi intrattabile dei paesi a specificare i propri sistemi di codifica, a volte proprietari.,
L’adozione del framework architettonico openEHR richiede l’uso di un approccio di modellazione più completo . Questi modelli sono in grado di collegarsi con i modelli FHIR® dove richiesto, ad esempio l’archetipo del rischio di reazione avversa openEHR e la risorsa Allergyintollerance FHIR® sono stati pubblicati congiuntamente e allineati alla fine del 2015., Gli archetipi incorporano il lavoro collaborativo intrapreso da una grande comunità internazionale virtuale di professionisti multidisciplinari che trasformano i dati sanitari in una forma elettronica (computabile) basata sull’evidenza per garantire l’interoperabilità universale all’interno di qualsiasi ecosistema sanitario digitale. Questo approccio consiste nella modellazione multi-livello e single source all’interno di un’architettura software orientata ai servizi delineata da una serie di specifiche pubblicate dalla openEHR Foundation e liberamente disponibili a chiunque.,
openEHR è una specifica standard aperta governata da una fondazione senza scopo di lucro, è liberamente disponibile per essere implementata da qualsiasi sviluppatore. Le specifiche OpenEHR, frutto di 25 anni di ricerca e sviluppo, rappresentano l’unica seria istanziazione del Modello di riferimento ISO 13606 per la comunicazione di cartelle cliniche elettroniche che dettaglia una struttura gerarchica per l’informazione clinica . Questo standard viene sempre più utilizzato in grandi progetti in Regno Unito, Norvegia, Finlandia, Slovenia e Germania., Anche Cina, Cile, Brasile, Italia e Caraibi hanno adottato questo approccio. Infatti ISO 13606 è stato derivato dall’esperienza di openEHR, e più recentemente è stato influenzato attraverso l’esperienza con altri standard tra cui FHIR®. Il lavoro di modellazione clinica è più ampio di quello intrapreso in qualsiasi altro luogo in precedenza con una comunità di volontari di oltre 2000 persone provenienti da 93 paesi.
I modelli clinici di dominio ISO13606 noti come “archetipi” sono esterni al software., Ogni archetipo definisce un numero massimo di possibili datapoint e gruppi di dati che si applicano al concetto modellato. Ciò prevede un numero massimo di contesti diversi per soddisfare tutte le specialità cliniche e i potenziali usi dei dati. I modelli, costituiti da un livello di” ricombinazione “di modelli per definire insiemi di dati, utilizzano solo i datapoint di un insieme (qualsiasi numero o selezione) di archetipi necessari per qualsiasi” caso d’uso” o applicazione specifica, come qualsiasi tipo di valutazione clinica., I modelli possono essere utilizzati come definizioni dei messaggi per i sistemi legacy, nonché set di dati per le nuove applicazioni, inclusi i moduli. Ciò significa che qualsiasi insieme di archetipi può essere riutilizzato per più casi d’uso. Consente a parti significative del software di essere derivate dalla macchina dagli archetipi. Gli archetipi rappresentano i dati atomici in uno standard aperto; un fattore critico di successo in grado di resistere ai cambiamenti nella tecnologia, in particolare lo scambio e la persistenza.,
Questi “archetipi” (modelli) sono in uso da varie applicazioni, tra cui nel Servizio sanitario nazionale del Regno Unito, dove vengono utilizzati per la conversione di sistemi shadow che consentono l’uso di archivi di dati neutri rispetto ai fornitori. Altri utenti sono: Queensland Health e alcuni ospedali privati per i loro sistemi di controllo delle infezioni, un certo numero di strutture sanitarie primarie di Sydney occidentale e EHR condivisa del Northern Territory Health, e partner industriali openEHR i cui sistemi sono ampiamente implementati nei paesi scandinavi., I componenti e i sistemi conformi sono “aperti” in termini di modelli di dati e API. Strategicamente, l’approccio openEHR ha un focus sulla salute ben adattato alla cura centrata sul paziente. Questo approccio consente un mercato del software basato su piattaforma o “open back-end” in cui i fornitori del settore sanitario e gli sviluppatori di soluzioni si interfacciano tra loro attraverso modelli di informazioni standardizzati, modelli di contenuti, terminologie e interfacce di servizio.,
Una collaborazione aperta di individui, industria, organizzazioni di standardizzazione e fornitori di servizi sanitari hanno accettato di lavorare insieme per accelerare lo sviluppo di standard aperti per l’interoperabilità nel settore sanitario e sociale. Hanno fornito un forum collaborativo per condividere esperienze e fornire soluzioni volte a superare questo paesaggio confuso. A luglio 2018 hanno pubblicato una panoramica di ciò che è stato descritto qui . È stato notato che questi molti standard sono in fase di convergenza. Gli standard FHIR® e openEHR non affrontano lo stesso problema., Entrambi creano modelli di informazioni cliniche, ma i modelli openEHR (archetipi) sono indipendenti dal fornitore incentrato sui dati su piattaforme openEHR. FHIR® è incentrato sull’applicazione in quanto crea un modello comune da utilizzare in qualsiasi applicazione per poi costituire la base per definire l’interoperabilità tra le applicazioni, indipendentemente dai modelli aperti o proprietari su cui sono stati costruiti. Coloro che fanno uso di soluzioni di interoperabilità incentrate sull’applicazione lo fanno per consentire l’uso continuo di costosi sistemi legacy.,
openEHR e FHIR ® forniscono approcci complementari ma diversi per collegare un complesso mosaico di applicazioni in un unico sistema coerente . L’approccio openEHR incentrato sui dati si concentra sulla normalizzazione dei dati sanitari in primo luogo, e la costruzione di nuovi sistemi in cima a sistemi legacy per evitare i problemi di interoperabilità tutti insieme. Si tratta di definire un livello di dati all’interno di un’architettura di sistema aperta. Questo è il livello più importante in quanto facilita l’uso ottimale dei dati per migliorare i risultati, gestire meglio le malattie croniche e consentire una migliore gestione della salute della popolazione., Ciò richiede che i dati siano archiviati in formati neutri rispetto ai formati proprietari della maggior parte dei sistemi legacy. L’approccio data centric consente l’archiviazione e l’utilizzo dei dati sanitari digitali per tutta la vita di qualsiasi paziente.
Quasi tutti i sistemi basati su openEHR stanno attualmente sviluppando interfacce FHIR® per garantire che possano supportare il percorso del paziente tra sistemi openEHR e non openEHR . Lo schema di connettività openEHR può essere creato una volta e condiviso tra tutti i fornitori openEHR poiché si basano su archetipi openEHR comuni., Le applicazioni raggruppate su una piattaforma basata su openEHR non hanno bisogno di soluzioni di scambio come FHIR® perché sono in grado di comunicare direttamente tra loro attraverso repository di dati clinici condivisi. Ciò consente ai nuovi operatori del mercato di concentrarsi sullo sviluppo di applicazioni veramente innovative e di soddisfare funzionalmente i requisiti clinici di nicchia. La capacità di FHIR® è necessaria solo per consentire loro di comunicare con applicazioni proprietarie di fornitori di ecosistemi più ampi .
Leave a Reply