PROGETTO DI APPLICAZIONI SOFTWARE CHE SI APPOGGIANO ALLO STANDARD INTERNAZIONALE "HEALTH LEVEL 7"

1. PROGETTO DI APPLICAZIONI SOFTWARE CHE SI APPOGGIANO ALLO STANDARD INTERNAZIONALE "HEALTH LEVEL 7"

2. Gli ospedali ed altre strutture sanitarie tipicamente utilizzano diversi sistemi computerizzati per le varie mansioni alle quali sono chiamate; ognuno di questi sistemi dovrebbe comunicare con gli altri per ricevere o trasmettere nuove informazioni, ma non sempre questo è possibile Spesso software forniti da produttori diversi non consentono la benché minima interoperabilità Gli standard di messaggistica definiscono come l'informazione deve essere ordinata e comunicata tra una entità e l'altra questi standard consistono in un'insieme di regole che permettono di condividere e processare le informazioni in maniera uniforme e coerente tra i vari applicativi conformi

3. L’Health Level Seven • Lo scopo dell'organizzazione Health Level Seven (HL7) è quello di progettare standard per l'interoperabilità che permettano di migliorare l'assistenza sanitaria, ottimizzare il flusso lavorativo, ridurre gli errori e migliorare il trasferimento delle informazioni tra tutte le entità interessate • HL7 è probabilmente lo standard per la comunicazione di messaggi più diffuso al mondo nel settore dell'ICT in sanità • Lo standard è stato sviluppato inizialmente per il sistema sanitario degli Stati Uniti anche se attualmente coinvolge l'intera comunità internazionale

4. "Level Seven" (Livello 7) si riferisce al più alto livello del modello di comunicazione ISO/OSI (Open Systems Interconnection / International Organization for Standardization), il livello applicazione • Questo livello si occupa unicamente dell'aspetto semantico della comunicazione, quindi della definizione di quali informazioni devono essere scambiate, il tempismo dello scambio e la comunicazione di errori semantici all'applicazione

5. HL7 V2 • L'HL7 v2 è stato pubblicato e standardizzato dall'ANSI nel 1988; • da allora sono susseguite diverse versioni fino alla Versione 2.5.1 del 2007 • Il processo di sviluppo HL7 v2.x è interamente ad hoc, non è stata definita una metodologia esplicita: i membri che si occupano della definizione dello standard ricevono solamente delle guide informali per la costruzione dei messaggi

6. BREVE DESCRIZIONE V2 • Ogni scambio di informazioni è inizializzato da un evento scatenante e consiste in uno o più messaggi • Ogni messaggio è una sequenza di segmenti in un ordine definito; i segmenti possono essere obbligatori o opzionali e possono essere ammesse ripetizioni • Ogni segmento è una sequenza di campi dato, separati da uno speciale separatore di campo; ogni segmento ha un nome codificato univoco di 3 caratteri; ogni segmento termina con un carattere "carriagereturn” • Ogni campo dati ha un tipo di dati, che potrebbe essere composto da più componenti che sono separati da un separatore di componenti

7. ESEMPIO MESSAGGIO HL7 MSH|^~\&|GHH LAB|ELAB-3|GHH OE|BLDG4|200202150930||ORU^R01|CNTRL- 3456|P|2.4 PID|||555-44-4444||EVERYWOMAN^EVE^E^^^^L|JONES|196203520|F|||153 FERNWOOD DR.^^STATESVILLE^OH^35292||(206)3345232|(206)752- 121||||AC555444444||67-A4335^OH^20030520 OBR|1|845439^GHH OE|1045813^GHH LAB|1554-5^GLUCOSE|||200202150 730||| ||||||555-55-5555^PRIMARY^PATRICIA P^^^^MD^^LEVEL SEVEN HEALTHCARE, INC.|||||||||F||||||444-44-4444^HIPPOCRATES^HOWARD H^^^^MD OBX|1|SN|1554-5^GLUCOSE^POST 12H CFST:MCNC:PT:SER/PLAS:QN||^182|mg/dl|70_105|H|||F<cr>

8. HL7 V2: VANTAGGI E SVANTAGGI VANTAGGI SVANTAGGI Pensato per la sanità americana Ambiguo Interoperabilità limitata Troppo flessibile Destinato a non essere più supportato Standard antiquato Difficoltà sulle certificazioni • Standard de facto • Stabile • Retro compatibile • Diverse implementazioni • Relativamente semplice • Flessibile • Costo relativamente basso

9. HL7 V3 Dal 1996 l'HL7 ha cercato di porre rimedio ai problemi concettuali e strutturali della V2 attraverso lo studio di un nuovo modello di sviluppo, che potesse guidare in una maniera più strutturata la creazione del nuovo standard V3. Lo scopo era quello di realizzare uno standard più rigoroso e definito, che potesse ridurre le incertezze riguardo la sua implementazione e di conseguenza i suoi costi. • Orientato agli oggetti • Conformità testabile • Non solo livello 7

10. PRINCIPI DI SVILUPPO • Internazionalizzazione • Opzionalità ridotta • Sistemi lascamente accoppiati • Compatibilità funzionale V2 • Retro-compatibilità • Sicurezza • Privacy

11. I MODELLI INFORMATIVI Come risultato del processo di modellamento della versione 3 sono stati realizzati tre modelli informativi basati sugli oggetti, i quali rispecchiano diversi livelli di approfondimento dell'analisi del dominio informativo delle aziende sanitarie: • Il RIM (Reference Information Model) che è ora uno standard ANSI è evoluto in un semplice framework astratto che si interessa della selvaggiamente eterogenea ed interconnessa natura delle informazioni cliniche attraverso solo sei importanti classi; nello stesso modo vengono rappresentate in maniera semplificata le informazioni amministrative. • Nel D-MIM (Domain Message Information Model) il RIM astratto viene reso specifico per definire gli elementi informativi per un'area di dominio o specialità. • Nel R-MIM (RefinedMessage Information Model) il D-MIM viene raffinato per definire gli elementi informativi di una famiglia di messaggi

12. RIM 2.18

13. E GLI ALTRI ARTEFATTI Oltre ai modelli informativi è stato definito un vocabolario, che è principalmente lo strumento con il quale sono stati risolti i problemi precedentemente intrattabili di multipli vocabolari riguardanti limiti organizzativi e nazionali. Viene inoltre prodotta una descrizione gerarchica per ogni messaggio definito all'interno dell'HL7 V3, la quale permette di organizzare un vasto insieme di dettagli riguardo ai contenuti degli specifici messaggi, provvedendo una più perentoria lista di tutti i vincoli e definizioni semantiche dettagliate, non appropriate nelle più astratte rappresentazioni.

14. LE INTERAZIONI • Le interazioni sono il cuore dello scambio di messaggi; la definizione formale di interazione è: • Una associazione univoca tra tipi di messaggi (trasferimento di informazioni), un particolare evento scatenante che inizia o è la causa del trasferimento e le responsabilità del ricevente (in termini di interazioni di risposta) associate al ricevimento della Interazione.  • Vengono inoltre in esse definiti i tipi di "TrasmissionWrapper" e "ControlActWrapper" che possono essere usati per la gestione dell'interazione.

16. ImplementationTechnologySpecifications • Le specifiche sull'implementazione tecnologica (ITS) definiscono come rappresentare gli oggetti del RIM per la trasmissione nei messaggi; esse coprono i livelli ISO 6 e 5 • L'HL7 ha adottato l'XML per le sue iniziali ITS, ma ora si è aggiunto anche una ITS sull'UML • Il modello di trasmissione astratto dell'HL7 v3 si basa sul RIM; i messaggi definiti dal protocollo possono essere pensati come una comunicazione di grafi di oggetti del RIM dal trasmettitore al ricevente • le ITS possono meglio trattare la rappresentazione di questi messaggi avendo appropriate rappresentazioni per gli oggetti, gli attributi ed i tipi di dati

17. ITS XML • Lo standard XML definisce come rappresentare documenti XML come flussi di byte da 8bit e come devono accoppiarsi l'apertura e la chiusura dei tag; questo corrisponde al livello 5 ISO/OSI; • Il modello ad oggetti di un documento (DOM, DocumentObjectModel) dell'XML definisce l'albero sintattico astratto dei documenti XML e corrisponde al livello 6 ISO/OSI L'ITS deve provvedere alla codifica di tutti i tipi di componenti che sono definiti nel messaggio HL7; la raccomandazione XML Schema è stata selezionata all'interno della famiglia degli standard XML come migliore metodo per raggiungere questo scopo. Gli schemi specificano cosa è accettabile in un documento XML attraverso la definizione di vincoli; il risultante schema per un messaggio XML può essere usato dai normali strumenti XML per determinare se un particolare messaggio HL7 sia valido per quel determinato schema. La parte più estesa delle ITS è dedicata ai tipi di dati dove specifici frammenti di schema sono stati definiti per tutti i 42 tipi di dati supportati dall'HL7.

18. L'applicazione trasmittente ("mittente") memorizza le sue informazioni nel formato del proprio database • Il mittente rappresenta logicamente queste informazioni come un grafo di oggetti del RIM • Usando la forma dei messaggi definita nell'HMD e l'algoritmo definito dalle ITS il mittente rappresenta gli oggetti RIM come un documento XML • Il mittente serializza il documento creando un file XML • Il mittente trasmette il file XML alla applicazione ricevente ("destinatario") usando il TCP/IP, l'EMAIL o altri livelli di trasporto messaggi Il destinatario quindi recupera il file XML dal livello di trasporto Il destinatario rimuove i wrapper del messaggio HL7 v3 ed analizza il contenuto codificato usando un parser standard per creare un albero DOM Il destinatario quindi interpreta l'albero DOM invertendo il mappaggio operato dall'ITS e ricreando di conseguenza il grafo degli oggetti RIM trasmessi In fine il destinatario memorizza le informazioni utilizzando il formato del suo database

19. HL7 JAVA SIG API l modello dei dati RIM, i tipi di dati HL7 ed i meta-file delle definizioni permettono all'API realizzata dal Java Special Interest Group di analizzare e costruire messaggi conformi allo standard HL7 V3 senza richiedere la conoscenza della struttura dei messaggi all'interno del codice. Dato un meta-file valido ed il relativo messaggio V3 in formato XML l'API può processare il file a prescindere dal tipo di messaggio e del suo contenuto. Come risultato del processo di elaborazione del messaggio, l'API genera a run-time un grafo di oggetti RIM (definiti dall'API stessa) che rappresenterà il contenuto del messaggio XML V3. Lo sviluppatore può di conseguenza utilizzare gli oggetti RIM come necessario per estrarre i valori del messaggio. Viceversa per costruire un messaggio XML V3, le API richiedono un grafo di oggetti RIM per guidare il processo di trasformazione; quindi una volta instanziati i vari oggetti RIM e assegnati i desiderati valori agli attributi (tra i quali anche quelli relativi alle relazioni tra i vari oggetti) le API permetteranno di creare un file XML che rispecchi il messaggio V3 definito dal grafo degli oggetti.

20. CONSIDERAZIONI HL7 JAVA SIG API • Le API definite dal Java SIG attualmente risentono dell'instabilità dello sviluppo dello standard; nonostante una architettura all'avanguardia che permette di farla adattare automaticamente al modificarsi dello standard, l'API si basa su i file "mif" contenenti metadati spesso non coerenti e di conseguenza il suo utilizzo ne risulta a volte pregiudicato. •  Inoltre mentre il processo di analisi dei messaggi è agevole ed intuitivo, la creazione degli stessi non è ancora ben supportata; in particolar modo la creazione di valori appartenenti ai tipi di dati predefiniti HL7 V3 è particolarmente macchinosa ed a volte non implementata. • La principale mancanza delle Java SIG API è però l’assenza di un decente supporto ai wrapper ed agli eventi scatenanti: attualmente l’API è completamente incentrata sulla realizzazione dei messaggi HL7 V3 dal punto di vista unicamente semantico, ovvero relativa solamente all’albero degli oggetti RIM da trasferire; la gestione delle interazioni non è di conseguenza attualmente supportata, mancando la possibilità di gestire le responsabilità dei ruoli applicativi ed il rilevamento automatico dei messaggi da spedire. • Nonostante alcune lacune la realizzazione da parte dell’HL7 di una API Java ufficiale sarà sicuramente fondamentale per una veloce implementazione del protocollo tramite il linguaggio Java.

21. HL7 Message Editor Il HL7 Message Editor un editor visuale di messaggi HL7 V3 scritto in Java e che si basa sulle API prodotte dall'HL7 Java Special Interest Group. Fondamentalmente l'HL7 Message Editor realizza un'interfaccia grafica che permette di strutturare appieno le principali funzioni della Java SIG API, ovvero quelle riguardanti la creazione e l'analisi dei messaggi HL7; nello specifico il tool permette di: • Caricare tipi di messaggi codificati nel formato mif ed altri meta-file prodotti dalle specifiche HL7 V3 • Creare ed editare messaggi HL7 V3 • Caricare messaggi HL7 V3 xml • Visualizzare e scrivere messaggi HL7 V3 xml

22. La filosofia con la quale è stato progettato l'editor rispecchia fedelmente quella dell'API sulle quali si poggia: l'applicazione è il più possibile indipendente dalle future modifiche allo standard HL7, questo al fine di massimizzare l'utilità e la ri-utilizzabilità del codice prodotto, in vista della grande variabilità dello standard HL7 in questa sua fase di sviluppo. Proprio come le API l'editor è e sarà in grado di gestire qualsiasi tipo di messaggio le cui meta-informazioni siano state codificate in un file MIF (Model Interchange Format), salvo il fatto che questi utilizzino gli oggetti definiti nel RIM e gli attributi specificati nel protocollo HL7 V3. Inoltre, grazie all'utilizzo della Java Reflection, per poter supportare ulteriori tipi di dati è sufficiente creare la relativa classe ed essa sarà prontamente utilizzabile dall'applicazione; per quanto riguarda invece la gestione di nuovi oggetti RIM, sarà sufficiente che questi siano gestiti dall'API e l'editor si adatterà di conseguenza.

24. L’applicazione HL7 MessageEditor è stata realizzata con lo scopo di sfruttare appieno le potenzialità della HL7 Java SIG API; ne segue che l’editor risulta particolarmente generico e facilmente adattabile alle eventuali, ed attualmente frequenti, modifiche dello standard. Oltre ai vantaggi derivati dall’API l’editor attualmente condivide anche le lacune della stessa: tramite l’interfaccia grafica è possibile editare tutti i tipi di messaggi definiti dalle varie versioni dello standard HL7 V3, ma non è stato implementato il supporto alle interazioni. Questa limitazione implica una ridotta funzionalità dell’HL7 MessageEditor: l’applicazione facilita la creazione di un determinato messaggio, ma non guida in alcun modo l’utente alla creazione dello stesso, né chiarisce in alcun modo la semantica dei messaggi; ne segue che attualmente l’editor sia efficacemente utilizzabile unicamente da utenti che conoscano in maniera adeguata lo standard HL7 V3 e sappiano quale messaggio e quali informazioni debbano essere inviate. Si può quindi affermare che l’utilizzo dell’editor sicuramente facilita sia la scrittura che la lettura del messaggio, ma non gestisce in alcun modo l’automatizzazione dello scambio delle interazioni, probabilmente uno dei vantaggi dell’HL7 V3 maggiormente importanti.

25. In Italia, così come nella maggior parte del resto del mondo, non è attualmente presente una struttura centralizzata per quanto riguarda i sistemi informativi sanitari; l’intero settore è dominato da soluzioni proprietarie e personalizzate distinte tra loro; spesso questi sistemi sono particolarmente specializzati il che può rendere difficoltosa una loro integrazione a causa della diversità di definizione di alcune informazioni. Ne risulta un ambiente fortemente eterogeneo e scarsamente interconnesso, in forte antitesi con la filosofia generale degli altri ambienti informatici, ormai completamente orientata all’interconnessione e l’interoperabilità; i vantaggi di una più spinta automazione nel trattamento delle informazioni nel settore dell’assistenza sanitaria vanno ben oltre l’aspetto economico, di per se particolarmente importante visto le somme in gioco. Grazie ad una più efficiente ed efficace gestione automatizzata delle informazioni è sicuramente possibile migliorare di molto l’assistenza sanitaria, in particolar modo in quelle situazioni in cui il reperimento immediato e corretto delle informazioni è di primaria importanza per la sopravvivenza del paziente, come per esempio nel caso di interventi d’urgenza ed incidenti. Naturalmente i vantaggi che le attuali soluzioni informatiche potrebbero apportare all’intero sistema sanitario non sono state ignorate dalla dirigenza del settore; nonostante tutto la situazione italiana risulta comunque sostanzialmente invariata.

27. SISTEMA INFORMATIVO SANITARIO • Nuovo Sistema Informativo Sanitario (NSIS) • Progetto Mattoni • Agenzia per i Servizi Sanitari Regionali (Assr)

28. Sicuramente la miglior soluzione per operare l’integrazione auspicata dal settore ed allo stesso tempo proteggere gli investimenti fino ad ora fatti sui sistemi informativi sanitari consiste nell’utilizzo di un protocollo di interfacciamento come quelli sviluppati dall’HL7. Grazie al protocollo HL7 è possibile mantenere a livello locale il sistema informativo proprietario ed allo stesso tempo assicurare una totale interconnessione con gli altri sistemi informativi; una volta realizzata una interfaccia HL7 per il proprio sistema informativo è teoricamente possibile comunicare in maniera intellegibile con qualsiasi altro sistema avente un’interfaccia compatibile con il protocollo. Il linguaggio HL7 permette quindi di rendere comprensibili a due sistemi informativi sanitari eterogenei le stesse informazioni; in altre parole grazie all’HL7 è possibile collegare in maniera semantica i due sistemi interconnessi.

29. L’HL7 però non gestisce in alcun modo il collegamento fisico vero e proprio e le problematiche ad esso associate; di conseguenza affinché si possa effettivamente instaurare una comunicazione intellegibile tra i due sistemi è necessario realizzare una sottostruttura di messaggistica alla quale poter appoggiare il trasporto dei messaggi HL7. In questo è sicuramente utile l’utilizzo di frame work specializzati per l’interoperabilità quali Mirth, che permette di realizzare una rete di sistemi informativi perfettamente gestita e connessa, capace di comunicare tramite una vasta serie di protocolli e di tipi di messaggi, tra cui naturalmente l’HL7, nelle due versioni V2 e V3.

31. CONCLUSIONI HL7 V2 Attualmente l’HL7 V2 è lo standard più diffuso tra i sistemi informativi sanitari internazionali, quindi risulta il principale candidato per l’implementazione di una interfaccia di connessione tra tali sistemi. D’altra parte però l’HL7 V2 non è attualmente molto diffuso nel territorio italiano, tantomeno in quello europeo, quindi a meno di necessità di comunicazione con aziende sanitarie d’oltreoceano, la sua diffusione internazionale ha poco valore per la situazione italiana. Inoltre lo standard V2 soffre di particolari carenze a livello semantico che ne pregiudicano l’utilità: a causa dell’elevato numero di opzioni e dell’approssimativa definizione dei tipi di dato lo standard V2 costringe le due entità che vogliono comunicare ad accordarsi sui vario concetti condivisi, rendendo di fatto lo standard utile per una interconnessione bipolare e non diffusa; in aiuto a questa problematica potrebbe arrivare il progetto mattoni che tra i vari scopi include l’indicazione delle scelte implementative relative alla semantica non definita all’interno dell’ HL7 V2, quindi in un certo senso la definizione di uno standard nello standard.

32. Nonostante queste problematiche la diffusa presenza di applicazioni software che supportano lo standard HL7 sono un notevole incentivo al suo utilizzo, in quanto permettono di diminuire i tempi di sviluppo e le spese; inoltre grazie alla stabilità ed alla indiscussa maturità del protocollo, oltre comunque alla possibilità di poter comunicare con le molte aziende sanitarie internazionali, l’HL7 V2 rimane comunque lo standard che assicura con maggior sicurezza la stabilità dell’investimento nel breve e medio periodo. In definitiva se il progetto relativo al NSIS dovesse avere un improvviso sviluppo (eventualità alquanto improbabile … ) l’HL7 V2 sarebbe sicuramente il miglio candidato per la soluzione del problema dell’interoperabilità a livello locale e regionale.

33. CONCLUSIONI HL7 V3 L’HL7 V3 è nato con lo scopo di risolvere tutti i problemi riscontrati durante lo sviluppo e l’utilizzazione della precedente versione; partendo da una definizione univoca e strutturata dei concetti interni ai messaggi ha cercato di risolvere in maniera definitiva i problemi sintattici propri della V2; l’obbiettivo sembra sostanzialmente raggiunto anche se la complessità del settore non rende agevole una sua trattazione. In sostanza nonostante siano passati oltre 10 anni dall’inizio dei lavori non tutti problemi sono stati risolti e molti altri probabilmente ancora si ripresenteranno, ma la strada tracciata sembra comunque quella giusta; le difficoltà riscontrate riguardano soprattutto il nuovo modello di sviluppo, forse troppo macchinoso per poter trattare una materia così vasta come quella dell’assistenza sanitaria, soprattutto a causa delle diverse competenze a cui si deve andare incontro. L’HL7 infatti non tratta unicamente degli aspetti medici (di per se a loro volta molto complessi), ma anche amministrativi, economi e giuridici; ne risulta quindi nel complesso uno standard di enormi dimensioni che sicuramente deve essere considerato con la dovuta cautela, visti i forti investimenti monetari e di tempo che una sua eventuale implementazione comporterebbe. D’altro canto l’HL7 V3 si presenta come una soluzione definitiva per l’interfacciamento e non solo dei sistemi informativi sanitari; fondandosi sulle interazioni il nuovo protocollo HL7 implicitamente cerca di imporre non solo la semantica dei dati da scambiare ma anche le modalità che comportano l’invio di questi dati. Questo approccio assomiglia all’utilizzo che attualmente viene fatto del “best practice” da parte dei software ERP; affinché l’utilizzo dell’HL7 V3 come protocollo di interfaccia sia efficiente è necessario che tutto il sistema informativo condivida la gestione delle interazioni e di conseguenza dei processi, così come definiti dal protocollo. Ciò non è sempre possibile, soprattutto in una realtà come quella italiana in cui i protocolli amministrativi sono definiti a livello nazionale e di conseguenza non adattabili localmente. Quindi anche nel caso dell’HL7 V3 l’utilizzo del protocollo sarebbe sicuramente poco efficiente senza il contemporaneo intervento normativo applicato da parte di un ente centralizzato superiore che imponga in questo caso le stesse interazioni definite dallo standard; senza la condivisione degli eventi scatenati e dei ruoli applicativi il processo di interfacciamento risulterebbe limitato ed a volte inconcludente, andando di fatto a sminuire l’utilità dell’utilizzo della nuova versione V3.

34. Il grande problema dell’HL7 V3 è però il suo interminabile processo di sviluppo: dopo 12 anni di lavori sul nuovo standard non è ancora previsto il termine ultimo dei lavori; nonostante l’enorme mole di concetti e la vastità del settore tutto questo tempo per la definizione di uno standard informatico non solo non è ammissibile, ma denuncia un problema di fondo insormontabile: la lentezza di sviluppo. Una delle caratteristiche principali dell’informatica è sicuramente la sua continua e tumultuosa evoluzione ed anche se questa porta inevitabilmente ad alcuni problemi di compatibilità, dall’altra introduce spesso importanti novità che spesso migliorano la sua usabilità; uno standard troppo lento nel suo sviluppo e quindi nel suo adattamento probabilmente rischia di non sapersi adeguare alle evoluzioni informatiche e non solo. Cosa accadrebbe nel caso di modifiche normative dei processi amministrativi del settore sanitario? Probabilmente lo sviluppo del protocollo non sarebbe adeguatamente pronto a riflettere tali modifiche, costringendo di conseguenza il sistema informativo ad adattassi in maniera asincrona alle modifiche prima normative e poi di protocollo, con le spese ed i ritardi conseguenti. Nonostante le buone intenzioni, inoltre la V3 ha ancora difetti comuni alla V2, quali la grande quantità di opzioni (anche se in parte ridotte rispetto al precedente protocollo) e le difficoltà nella certificazione allo standard (che probabilmente verranno risolte unicamente a partire dalla prima revisione, con l’introduzione a livello normativo dei ruoli applicativi). Comunque, nel caso in cui si dovesse sviluppare un sistema informativo sanitario da zero potrebbe essere consigliabile utilizzare come modello informativo il RIM, al fine di sfruttare il lavoro di modellamento fin qui svolto dall'HL7, con uno sguardo alla futura V3.