Gli ospedali ed altre strutture sanitarie tipicamente utilizzano diversi sistemi computerizzati per le varie mansioni alle quali sono chiamate; ognuno.

Presentazione sul tema: "Gli ospedali ed altre strutture sanitarie tipicamente utilizzano diversi sistemi computerizzati per le varie mansioni alle quali sono chiamate; ognuno."— Transcript della presentazione:

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 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à, costringendo gli operatori ad un lavoro supplementare, solitamente manuale, teoricamente evitabile; lo stesso problema può inoltre essere riscontrato all'interno dei medesimi applicativi se questi non sono compatibili con versioni precedenti degli stessi. 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; essi normalmente precisano il linguaggio, la struttura e le tipologie di dato richieste per l'integrazione di sistemi eterogenei

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 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; in questi anni l'HL7 ha accumulato una notevole esperienza grazie al suo utilizzo quotidiano nella maggior parte degli ospedali e nelle richieste di rimborso delle prestazioni.

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 "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 della definizione di quali informazioni devono essere scambiate, il tempismo dello scambio e la comunicazione di errori semantici all'applicazione; il protocollo HL7 si occupa di conseguenza solo dell'aspetto semantico della comunicazione lasciando in secondo piano gli aspetti implementativi necessari affinché la comunicazione abbia fisicamente luogo.

5 HL7 V2 L'HL7 v2 è stato pubblicato e standardizzato dall'ANSI nel 1988; da allora sono susseguite diverse versioni fino alla Versione 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 L'HL7 V2 è attualmente lo standard de facto per quanto riguarda la messaggistica tra sistemi informativi sanitari; la sua diffusione è capillare negli USA, mentre si sta sempre più diffondendo in altri paesi quali il Canada, l'Australia, la Germania, l'Olanda, il Giappone e l'Inghilterra. Il processo di sviluppo L'HL7 V2 ha avuto sin dall'inizio un'importante successo, ma questo ha portato ad uno sviluppo dello standard non supportato da un adeguato rigore logico. 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. Inoltre gli eventi scatenanti e i campi dati sono descritti unicamente nel linguaggio naturale, ne segue che  le relazioni strutturali tra i campi dati non sono chiare o comunque non sempre ben definite. Con le versioni 2.x i comitati tecnici creano messaggi editando direttamente documenti di elaborazione testi; i meta-dati non sono disponibili in una forma strutturata fin quando gli impiegati ed i volontari non li estraggono tediosamente dai documenti di elaborazione testi dopo la pubblicazione, con conseguenti ritardi, possibili errori e non standardizzazione degli stessi. L'HL7 si è evoluto notevolmente negli anni, sia a causa della sua maturità che delle continue evoluzioni nel settore dell'assistenza sanitaria; se da un lato l'ampliamento dello standard HL7 ha portato notevoli vantaggi nella intercomunicazione tra i vari sistemi informativi sanitari, dall'altro ha messo in evidenza le stringenti limitatezze del suo modello di sviluppo, sicuramente non adeguato a supportare una così vasta quantità di informazioni. Per porre in parte rimedio ai problemi di modellamento dei messaggi si è cercato di riutilizzare in maniera cospicua i vari concetti introdotti nello standard, al fine di non introdurne di nuovi e più specifici; in particolare i segmenti sono riutilizzati in molti messaggi e le definizioni degli stessi sono riusate per molti eventi scatenanti con lo scopo di ridurre la complessità e la dimensione dello standard; al fine di favorire questo esteso riutilizzo la maggior parte dei campi dati sono stati resi opzionali. A causa della metodologia di sviluppo non rigorosa si possono riscontrare numerose deficienze semantiche; per esempio i capitoli sono inconsistenti nel loro utilizzo degli eventi scatenanti rispetto ai codici di stato; inoltre non ci sono specifiche su quando un particolare tipo di sistema informativo di assistenza sanitaria dovrebbe rispettare un evento scatenante o accettare un messaggio. Riassumendo, c'è un sostanziale bisogno di migliorare questo vecchio processo al fine di gestire la vastità e complessità delle sfide che l'HL7 attualmente affronta. L'industria dell'assistenza sanitaria ne trarrà sicuramente benefici perché questo nuovo processo porta ad una maggiormente rigorosa definizione delle specifiche che potranno essere elaborate più facilmente dai moderni sistemi informativi.

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 "carriage return” Ogni campo dati ha un tipo di dati, che potrebbe essere composto da più componenti che sono separati da un separatore di componenti L'HL7 V2 è attualmente lo standard de facto per quanto riguarda la messaggistica tra sistemi informativi sanitari; la sua diffusione è capillare negli USA, mentre si sta sempre più diffondendo in altri paesi quali il Canada, l'Australia, la Germania, l'Olanda, il Giappone e l'Inghilterra. Il protocollo di interfacciamento HL7 V2 ha la seguente struttura generale: 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; il primo segmento di ogni messaggio definisce il tipo di messaggio ed il tipo di evento scatenante che ha causato la spedizione del messaggio. 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 "carriage return". Ogni campo dati ha un tipo di dati, che potrebbe essere composto da più componenti che sono separati da un separatore di componenti (di solito il carattere "^")

7 ESEMPIO MESSAGGIO HL7 MSH|^~\&|GHH LAB|ELAB-3|GHH OE|BLDG4| ||ORU^R01|CNTRL- 3456|P|2.4 PID||| ||EVERYWOMAN^EVE^E^^^^L|JONES| |F|||153 FERNWOOD DR.^^STATESVILLE^OH^35292||(206) |(206) ||||AC ||67-A4335^OH^ OBR|1|845439^GHH OE| ^GHH LAB|1554-5^GLUCOSE||| ||| |||||| ^PRIMARY^PATRICIA P^^^^MD^^LEVEL SEVEN HEALTHCARE, INC.|||||||||F|||||| ^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> il primo segmento di ogni messaggio definisce il tipo di messaggio ed il tipo di evento scatenante che ha causato la spedizione del messaggio. separatore di campo (di solito il caratere pipe "|"); Gli elementi dato alla destra dello stesso sono omessi dal messaggio. Dei campi vuoti sulla sinistra sono indicati tramite separatori di campi dati consecutivi ("||") separatore di componenti (di solito il carattere "^")

8 HL7 V2: VANTAGGI E SVANTAGGI
Standard de facto Stabile Retro compatibile Diverse implementazioni Relativamente semplice Flessibile Costo relativamente basso Pensato per la sanità americana Ambiguo Interoperabilità limitata Troppo flessibile Destinato a non essere più supportato Standard antiquato Difficoltà sulle certificazioni [VANTAGGI HL7 V2] Standard de facto: L'HL7 V2 è uno standard diffuso a livello internazionale e largamente utilizzato; attualmente è di fatto l’unico standard aperto utilizzato per l’interfacciamento nell’ambito dell’assistenza sanitaria; di conseguenza non può che essere la prima scelta da prendere in considerazione nel caso si debba realizzare un’integrazione con un altro sistema informativo. Stabile: Dopo circa 20 anni di sviluppo e diverse revisioni, nonché naturalmente il largo utilizzo quotidiano, lo standard ha raggiunto una piena maturità evolutiva Retro compatibile: Le versioni 2.x sono sempre compatibili con le precedenti, anche se naturalmente queste ultime saranno limitate nell’utilizzo delle nuove funzionalità introdotte dalle versioni successive Diverse implementazioni: Molte aziende hanno realizzato framework di sviluppo per il supporto all'HL7 V2; ne segue che il mercato creatosi è altamente concorrenziale e sostanzialmente affidabile, a tutto vantaggio dei clienti che devono espandere l’interoperabilità del proprio sistema informativo grazie all’HL7 V2 Relativamente semplice: Basandosi su pochi elementi normativi, l’intero protocollo è relativamente semplice da studiare ed implementare Flessibile: I messaggi contengono molti elementi opzionali che permettono di adattarsi alle necessità e disponibilità delle entità che li utilizzano, semplicemente concordando quali informazioni condividere Costo relativamente basso: Per tutte le ragioni precedentemente elencate il costo di utilizzo dello standard HL7 V2 per l'interfacciamento dei sistemi può essere realizzato attraverso una spesa limitata [SVANTAGGI HL7 V2] Pensato principalmente per la sanità americana: Sono di conseguenza poco curati tutti gli ambiti che negli USA rivestono un interesse secondario, come per esempio gli aspetti relativi all'assistenza sanitaria primaria e la pubblica sanità, che invece sono particolarmente importanti nel contesto europeo; questa naturalmente è una grave limitazione per il mercato europeo, che in parte spiega il minor utilizzo dell’HL7 nel vecchio continente Ambiguo: Non esistendo una definizione formale e condivisa dei concetti, questi ultimi possono risultare ambigui e non ben definiti; ne seguono difficoltà implementative e la presenza inaspettata di errori semantici, particolarmente critici nel settore sanitario Interoperabilità limitata: A causa della semantica non condivisa, l'HL7 V2 non offre una soluzione universale per l'interoperabilità, in quanto necessita di accordi bilaterali affinché i messaggi siano ben definiti; di conseguenza ogni implementazione è in generale legata a due uniche entità e non all’intero universo degli enti che si interfacciano attraverso lo standard HL7 V2 e questo limita l’utilità ed il vantaggio della sua utilizzazione Troppo flessibile: Il gran numero di elementi opzionali tende a rendere l'implementazione del protocollo ed in generale l'integrazione dei sistemi più complessa, in quanto costringe le due entità ad una prolungata e profonda analisi delle rispettive necessità Destinato a non essere più supportato: Anche se è da poco uscita la versione e potrebbe essere rilasciata una 2.6, lo sviluppo dello standard è destinato a bloccarsi, in quanto sarà rimpiazzato dalla nuova V3 Standard antiquato: Dopo circa 20 anni il mondo dell'informatica è cambiato, mentre l'HL7 V2 poggia sulle stesse basi; la sicurezza, la privacy e l'xml sono temi adattati successivamente nell'HL7 V2, con i problemi e le difficoltà che ne conseguono Difficoltà sulle certificazioni: Non esiste una procedura ufficiale per verificare la compatibilità di un sistema informativo allo standard HL7 V2; inoltre la presenza di molti elementi opzionali rende difficile la stipulazione di contratti efficaci

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 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. CARATTERISTICHE PROCESSO DI SVILUPPO Orientato agli oggetti: gli oggetti sono entrati prepotentemente nell'industria dell'informatica; grazie soprattutto all'UML e l'Unified Process il processo di analisi funzionale dei dati e la definizione dei relativi oggetti si può basare su tecniche assodate e strumenti diffusi. Conformità testabile: le specifiche includono diversi strumenti e concetti utili alla testabilità della conformità. Non solo livello 7: contemporaneamente allo sviluppo dello standard HL7 V3 vengono realizzate delle "Specifiche di implementazione tecnologica", in particolar modo riguardanti l'XML

10 PRINCIPI DI SVILUPPO Internazionalizzazione Opzionalità ridotta
Sistemi lascamente accoppiati Compatibilità funzionale V2 Retro-compatibilità Sicurezza  Privacy PRINCIPI DI SVILUPPO Internazionalizzazione: lo standard internazionale prevede al suo interno la realizzazioni di varianti regionali, che saranno perfettamente compatibili tra di loro Opzionalità ridotta: l'uso dell'opzionalità all'interno dei messaggi è ridotta al minimo indispensabile Sistemi lascamente accoppiati: l'HL7 prevede l'utilizzo di messaggi di conferma e l'invio di messaggi batch. Compatibilità funzionale V2: l'HL7 V3 dovrà essere concettualmente capace di comunicare con un sistema V2. Retro-compatibilità: le regole relative alla retro-compatibilità dei sistemi V3 sono già state definite Sicurezza: la futura V3 prevederà al suo interno diversi meccanismi di protezione delle informazioni Privacy: grazie alla riduzione delle opzionalità e ad un più attento utilizzo delle informazioni l'HL7 V3 sarà capace di proteggere maggiormente la privacy dei soggetti delle informazioni.

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 (Refined Message Information Model) il D-MIM viene raffinato per definire gli elementi informativi di una famiglia di messaggi 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 (Refined Message Information Model) il D-MIM viene raffinato per definire gli elementi informativi di una famiglia di messaggi DIAGRAMMI UML DELLE CLASSI E DI STATO

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. 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 inotre 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 "Trasmission Wrapper" e "Control Act Wrapper" che possono essere usati per la gestione dell'interazione. 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 "Trasmission Wrapper" e "Control Act Wrapper" che possono essere usati per la gestione dell'interazione.

15

16 Implementation Technology Specifications
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 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, Document Object Model) 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. Lo standard pubblico XML specifica il formato in cui vengono effettivamente trasmessi i messaggi HL7; 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; (SESSIONE) il modello ad oggetti di un documento (DOM, Document Object Model) dell'XML definisce l'albero sintattico astratto dei documenti XML e corrisponde al livello 6. (PRESENTAZIONE) 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 Il destinatario quindi recupera il file XML dal livello di trasporto
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' 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 SPEDIZIONE 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' o altri livelli di trasporto messaggi RICEZIONE 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. 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. Nel momento in cui nuovi tipi di messaggi ed i relativi meta-file verranno aggiunti al dominio dell'HL7 V3, l'API sarà capace di elaborare e costruire questi messaggi senza alcun cambiamento della stessa. 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. 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 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. 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.

23

24 L’applicazione HL7 Message Editor è 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 Message Editor: 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. L’applicazione HL7 Message Editor è 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 Message Editor: 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. 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.

26

27 SISTEMA INFORMATIVO SANITARIO
Nuovo Sistema Informativo Sanitario (NSIS) Progetto Mattoni Agenzia per i Servizi Sanitari Regionali (Assr) Nuovo Sistema Informativo Sanitario Nazionale Sistemi Informativi Sanitari regionali Sistemi Informativi aziendali territoriali Dai primi anni del 2000 è stata prevista l’istituzione di un “Nuovo Sistema Informativo Sanitario nazionale” che supervisionasse l’intero settore dell’assistenza sanitaria. Oltre al NSIS è stata instituita la “Agenzia Nazionale per i Servizi Sanitari Regionali” con lo scopo di facilitare l’integrazione a livello regionale delle varie aziende sanitarie locali; la principale occupazione dell’ ANSSR è attualmente lo sviluppo del progetto “Mattoni del Sistema Sanitario Nazionale ”, un insieme di 15 sotto-progetti distinti aventi lo scopo di supportare la realizzazione del NSIS.

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.

30

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. 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. 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. 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. 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.