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

PROGETTO DI APPLICAZIONI SOFTWARE CHE SI APPOGGIANO ALLO STANDARD INTERNAZIONALE "HEALTH LEVEL 7"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 conformiGli 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 eterogenei2LHealth Level SevenLo 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 interessateHL7 probabilmente lo standard per la comunicazione di messaggi pi diffuso al mondo nel settore dell'ICT in sanitLo standard stato sviluppato inizialmente per il sistema sanitario degli Stati Uniti anche se attualmente coinvolge l'intera comunit internazionaleLo 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.

3"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 applicazioneQuesto 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.

4HL7 V2L'HL7 v2 stato pubblicato e standardizzato dall'ANSI nel 1988;da allora sono susseguite diverse versioni fino alla Versione 2.5.1 del 2007Il 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 sviluppoL'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.5BREVE DESCRIZIONE V2Ogni scambio di informazioni inizializzato da un evento scatenante e consiste in uno o pi messaggiOgni messaggio una sequenza di segmenti in un ordine definito; i segmenti possono essere obbligatori o opzionali e possono essere ammesse ripetizioniOgni 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 returnOgni campo dati ha un tipo di dati, che potrebbe essere composto da pi componenti che sono separati da un separatore di componentiL'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 messaggiOgni 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 ripetizioniOgni 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 "^")

6ESEMPIO MESSAGGIO HL7MSH|^~\&|GHH LAB|ELAB-3|GHH OE|BLDG4|200202150930||ORU^R01|CNTRL-3456|P|2.4PID|||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^20030520OBR|1|845439^GHH OE|1045813^GHH LAB|1554-5^GLUCOSE|||200202150730|||||||||555-55-5555^PRIMARY^PATRICIA P^^^^MD^^LEVEL SEVEN HEALTHCARE, INC.|||||||||F||||||444-44-4444^HIPPOCRATES^HOWARD H^^^^MDOBX|1|SN|1554-5^GLUCOSE^POST 12H CFST:MCNC:PT:SER/PLAS:QN||^182|mg/dl|70_105|H|||Fil 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 "^")

7HL7 V2: VANTAGGI E SVANTAGGIVANTAGGIStandard de factoStabileRetro compatibileDiverse implementazioniRelativamente sempliceFlessibileCosto relativamente bassoSVANTAGGIPensato per la sanit americanaAmbiguoInteroperabilit limitataTroppo flessibileDestinato a non essere pi supportatoStandard antiquatoDifficolt sulle certificazioni[VANTAGGI HL7 V2]Standard de facto: L'HL7 V2 uno standard diffuso a livello internazionale e largamente utilizzato; attualmente di fatto lunico standard aperto utilizzato per linterfacciamento nellambito dellassistenza sanitaria; di conseguenza non pu che essere la prima scelta da prendere in considerazione nel caso si debba realizzare unintegrazione 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 evolutivaRetro compatibile: Le versioni 2.x sono sempre compatibili con le precedenti, anche se naturalmente queste ultime saranno limitate nellutilizzo delle nuove funzionalit introdotte dalle versioni successiveDiverse 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 linteroperabilit del proprio sistema informativo grazie allHL7 V2Relativamente semplice: Basandosi su pochi elementi normativi, lintero protocollo relativamente semplice da studiare ed implementareFlessibile: I messaggi contengono molti elementi opzionali che permettono di adattarsi alle necessit e disponibilit delle entit che li utilizzano, semplicemente concordando quali informazioni condividereCosto 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 dellHL7 nel vecchio continenteAmbiguo: 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 sanitarioInteroperabilit 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 allintero universo degli enti che si interfacciano attraverso lo standard HL7 V2 e questo limita lutilit ed il vantaggio della sua utilizzazioneTroppo 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 necessitDestinato a non essere pi supportato: Anche se da poco uscita la versione 2.5.1 e potrebbe essere rilasciata una 2.6, lo sviluppo dello standard destinato a bloccarsi, in quanto sar rimpiazzato dalla nuova V3Standard 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 conseguonoDifficolt 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 efficaci8HL7 V3Dal 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 oggettiConformit testabileNon solo livello 7Dal 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 SVILUPPOOrientato 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

9PRINCIPI DI SVILUPPOInternazionalizzazioneOpzionalit ridottaSistemi lascamente accoppiatiCompatibilit funzionale V2Retro-compatibilitSicurezzaPrivacy

PRINCIPI DI SVILUPPOInternazionalizzazione: lo standard internazionale prevede al suo interno la realizzazioni di varianti regionali, che saranno perfettamente compatibili tra di loroOpzionalit ridotta: l'uso dell'opzionalit all'interno dei messaggi ridotta al minimo indispensabileSistemi 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 definiteSicurezza: la futura V3 preveder al suo interno diversi meccanismi di protezione delle informazioniPrivacy: 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.10I MODELLI INFORMATIVICome 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 messaggiCome 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 STATO11RIM 2.18

E GLI ALTRI ARTEFATTIOltre 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.13LE INTERAZIONILe 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.14

Implementation Technology SpecificationsLe specifiche sull'implementazione tecnologica (ITS) definiscono come rappresentare gli oggetti del RIM per la trasmissione nei messaggi; esse coprono i livelli ISO 6 e 5L'HL7 ha adottato l'XML per le sue iniziali ITS, ma ora si aggiunto anche una ITS sull'UMLIl 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 riceventele ITS possono meglio trattare la rappresentazione di questi messaggi avendo appropriate rappresentazioni per gli oggetti, gli attributi ed i tipi di datiLe 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.16ITS XMLLo 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/OSIL'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.

17L'applicazione trasmittente ("mittente") memorizza le sue informazioni nel formato del proprio databaseIl mittente rappresenta logicamente queste informazioni come un grafo di oggetti del RIMUsando la forma dei messaggi definita nell'HMD e l'algoritmo definito dalle ITS il mittente rappresenta gli oggetti RIM come un documento XMLIl mittente serializza il documento creando un file XMLIl 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 trasportoIl destinatario rimuove i wrapper del messaggio HL7 v3 ed analizza il contenuto codificato usando un parser standard per creare un albero DOMIl destinatario quindi interpreta l'albero DOM invertendo il mappaggio operato dall'ITS e ricreando di conseguenza il grafo degli oggetti RIM trasmessiIn fine il destinatario memorizza le informazioni utilizzando il formato del suo databaseSPEDIZIONEL'applicazione trasmittente ("mittente") memorizza le sue informazioni nel formato del proprio databaseIl mittente rappresenta logicamente queste informazioni come un grafo di oggetti del RIMUsando la forma dei messaggi definita nell'HMD e l'algoritmo definito dalle ITS il mittente rappresenta gli oggetti RIM come un documento XMLIl mittente serializza il documento creando un file XMLIl mittente trasmette il file XML alla applicazione ricevente ("destinatario") usando il TCP/IP, l'EMAIL o altri livelli di trasporto messaggiRICEZIONEIl destinatario quindi recupera il file XML dal livello di trasportoIl destinatario rimuove i wrapper del messaggio HL7 v3 ed analizza il contenuto codificato usando un parser standard per creare un albero DOMIl destinatario quindi interpreta l'albero DOM invertendo il mappaggio operato dall'ITS e ricreando di conseguenza il grafo degli oggetti RIM trasmessiIn fine il destinatario memorizza le informazioni utilizzando il formato del suo database

18HL7 JAVA SIG APIl modello dei dati RIM, i tipi di dati HL7 ed i meta-file delle definizionipermettono all'API realizzata dal Java Special Interest Groupdi analizzare e costruire messaggi conformi allo standardHL7 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 XMLl'API pu processare ilfile 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 percostruire 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 definizionipermettono all'API realizzata dal Java Special Interest Groupdi analizzare e costruire messaggi conformi allo standardHL7 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 XMLl'API pu processare ilfile 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 percostruire 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.

19CONSIDERAZIONI HL7 JAVA SIG APILe API definite dal Java SIG attualmente risentono dell'instabilit dello sviluppo dello standard; nonostanteuna architettura all'avanguardiache 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 lassenza di un decente supporto ai wrapper ed agli eventi scatenanti: attualmente lAPI completamente incentrata sulla realizzazione dei messaggi HL7 V3 dal punto di vista unicamente semantico, ovvero relativa solamente allalbero 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 dellHL7 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; nonostanteuna architettura all'avanguardiache 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 lassenza di un decente supporto ai wrapper ed agli eventi scatenanti: attualmente lAPI completamente incentrata sulla realizzazione dei messaggi HL7 V3 dal punto di vista unicamente semantico, ovvero relativa solamente allalbero 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 dellHL7 di una API Java ufficiale sar sicuramente fondamentale per una veloce implementazione del protocollo tramite il linguaggio Java.20HL7 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 V3Creare ed editare messaggi HL7 V3Caricare messaggi HL7 V3 xmlVisualizzare e scrivere messaggi HL7 V3 xmlIl 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 V3Creare ed editare messaggi HL7 V3Caricare messaggi HL7 V3 xmlVisualizzare e scrivere messaggi HL7 V3 xml21La 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.22

Lapplicazione HL7 Message Editor stata realizzata con lo scopo di sfruttare appieno le potenzialit della HL7 Java SIG API; ne segue che leditor risulta particolarmente generico e facilmente adattabile alle eventuali, ed attualmente frequenti, modifiche dello standard.Oltre ai vantaggi derivati dallAPI leditor attualmente condivide anche le lacune della stessa: tramite linterfaccia 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 dellHL7 Message Editor: lapplicazione facilita la creazione di un determinato messaggio, ma non guida in alcun modo lutente alla creazione dello stesso, n chiarisce in alcun modo la semantica dei messaggi; ne segue che attualmente leditor 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 lutilizzo delleditor sicuramente facilita sia la scrittura che la lettura del messaggio, ma non gestisce in alcun modo lautomatizzazione dello scambio delle interazioni, probabilmente uno dei vantaggi dellHL7 V3 maggiormente importanti.Lapplicazione HL7 Message Editor stata realizzata con lo scopo di sfruttare appieno le potenzialit della HL7 Java SIG API; ne segue che leditor risulta particolarmente generico e facilmente adattabile alle eventuali, ed attualmente frequenti, modifiche dello standard.Oltre ai vantaggi derivati dallAPI leditor attualmente condivide anche le lacune della stessa: tramite linterfaccia 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 dellHL7 Message Editor: lapplicazione facilita la creazione di un determinato messaggio, ma non guida in alcun modo lutente alla creazione dello stesso, n chiarisce in alcun modo la semantica dei messaggi; ne segue che attualmente leditor 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 lutilizzo delleditor sicuramente facilita sia la scrittura che la lettura del messaggio, ma non gestisce in alcun modo lautomatizzazione dello scambio delle interazioni, probabilmente uno dei vantaggi dellHL7 V3 maggiormente importanti.24In Italia, cos come nella maggior parte del resto del mondo, non attualmente presente una struttura centralizzata per quanto riguarda i sistemi informativi sanitari; lintero 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 allinterconnessione e linteroperabilit; i vantaggi di una pi spinta automazione nel trattamento delle informazioni nel settore dellassistenza sanitaria vanno ben oltre laspetto 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 lassistenza 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 durgenza ed incidenti.Naturalmente i vantaggi che le attuali soluzioni informatiche potrebbero apportare allintero 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; lintero 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 allinterconnessione e linteroperabilit; i vantaggi di una pi spinta automazione nel trattamento delle informazioni nel settore dellassistenza sanitaria vanno ben oltre laspetto 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 lassistenza 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 durgenza ed incidenti.Naturalmente i vantaggi che le attuali soluzioni informatiche potrebbero apportare allintero sistema sanitario non sono state ignorate dalla dirigenza del settore; nonostante tutto la situazione italiana risulta comunque sostanzialmente invariata.25

SISTEMA INFORMATIVO SANITARIONuovo Sistema Informativo Sanitario (NSIS)Progetto MattoniAgenzia per i Servizi Sanitari Regionali (Assr)Dai primi anni del 2000 stata prevista listituzione di un Nuovo Sistema Informativo Sanitario nazionale che supervisionasse lintero settore dellassistenza sanitaria.Oltre al NSIS stata instituita la Agenzia Nazionale per i Servizi Sanitari Regionali con lo scopo di facilitare lintegrazione 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.27Sicuramente la miglior soluzione per operare lintegrazione auspicata dal settore ed allo stesso tempo proteggere gli investimenti fino ad ora fatti sui sistemi informativi sanitari consiste nellutilizzo di un protocollo di interfacciamento come quelli sviluppati dallHL7.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 uninterfaccia 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 allHL7 possibile collegare in maniera semantica i due sistemi interconnessi.LHL7 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 lutilizzo di frame work specializzati per linteroperabilit 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 lHL7, nelle due versioni V2 e V3.

CONCLUSIONI HL7 V2Attualmente lHL7 V2 lo standard pi diffuso tra i sistemi informativi sanitari internazionali, quindi risulta il principale candidato per limplementazione di una interfaccia di connessione tra tali sistemi.Daltra parte per lHL7 V2 non attualmente molto diffuso nel territorio italiano, tantomeno in quello europeo, quindi a meno di necessit di comunicazione con aziende sanitarie doltreoceano, 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 lutilit: a causa dellelevato numero di opzioni e dellapprossimativa 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 lindicazione delle scelte implementative relative alla semantica non definita allinterno dell HL7 V2, quindi in un certo senso la definizione di uno standard nello standard.Attualmente lHL7 V2 lo standard pi diffuso tra i sistemi informativi sanitari internazionali, quindi risulta il principale candidato per limplementazione di una interfaccia di connessione tra tali sistemi.Daltra parte per lHL7 V2 non attualmente molto diffuso nel territorio italiano, tantomeno in quello europeo, quindi a meno di necessit di comunicazione con aziende sanitarie doltreoceano, 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 lutilit: a causa dellelevato numero di opzioni e dellapprossimativa 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 lindicazione delle scelte implementative relative alla semantica non definita allinterno dell HL7 V2, quindi in un certo senso la definizione di uno standard nello standard.

31Nonostante 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, lHL7 V2 rimane comunque lo standard che assicura con maggior sicurezza la stabilit dellinvestimento nel breve e medio periodo.In definitiva se il progetto relativo al NSIS dovesse avere un improvviso sviluppo (eventualit alquanto improbabile ) lHL7 V2 sarebbe sicuramente il miglio candidato per la soluzione del problema dellinteroperabilit 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, lHL7 V2 rimane comunque lo standard che assicura con maggior sicurezza la stabilit dellinvestimento nel breve e medio periodo.In definitiva se il progetto relativo al NSIS dovesse avere un improvviso sviluppo (eventualit alquanto improbabile ) lHL7 V2 sarebbe sicuramente il miglio candidato per la soluzione del problema dellinteroperabilit a livello locale e regionale. 32CONCLUSIONI HL7 V3LHL7 V3 nato con lo scopo di risolvere tutti i problemi riscontrati durante lo sviluppo e lutilizzazione 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; lobbiettivo sembra sostanzialmente raggiunto anche se la complessit del settore non rende agevole una sua trattazione.In sostanza nonostante siano passati oltre 10 anni dallinizio 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 dellassistenza sanitaria, soprattutto a causa delle diverse competenze a cui si deve andare incontro.LHL7 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.Daltro canto lHL7 V3 si presenta come una soluzione definitiva per linterfacciamento 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 linvio di questi dati.Questo approccio assomiglia allutilizzo che attualmente viene fatto del best practice da parte dei software ERP; affinch lutilizzo dellHL7 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 dellHL7 V3 lutilizzo 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 lutilit dellutilizzo della nuova versione V3.LHL7 V3 nato con lo scopo di risolvere tutti i problemi riscontrati durante lo sviluppo e lutilizzazione 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; lobbiettivo sembra sostanzialmente raggiunto anche se la complessit del settore non rende agevole una sua trattazione.In sostanza nonostante siano passati oltre 10 anni dallinizio 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 dellassistenza sanitaria, soprattutto a causa delle diverse competenze a cui si deve andare incontro.LHL7 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.Daltro canto lHL7 V3 si presenta come una soluzione definitiva per linterfacciamento 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 linvio di questi dati.Questo approccio assomiglia allutilizzo che attualmente viene fatto del best practice da parte dei software ERP; affinch lutilizzo dellHL7 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 dellHL7 V3 lutilizzo 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 lutilit dellutilizzo della nuova versione V3.33Il grande problema dellHL7 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 lenorme 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 dellinformatica sicuramente la sua continua e tumultuosa evoluzione ed anche se questa porta inevitabilmente ad alcuni problemi di compatibilit, dallaltra 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 lintroduzione 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 ilRIM, al fine di sfruttare il lavoro di modellamento fin qui svolto dall'HL7, con uno sguardo alla futura V3.Il grande problema dellHL7 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 lenorme 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 dellinformatica sicuramente la sua continua e tumultuosa evoluzione ed anche se questa porta inevitabilmente ad alcuni problemi di compatibilit, dallaltra 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 lintroduzione 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 ilRIM, al fine di sfruttare il lavoro di modellamento fin qui svolto dall'HL7, con uno sguardo alla futura V3.34