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
conformi
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
• "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
HL7 V2
• L'HL7 v2 è stato pubblicato e standardizzato
dall'ANSI nel 1988;
• da allora sono susseguite diverse versioni fino alla
Versione 2.5.1 del 2007
• Il processo di sviluppo HL7 v2.x è interamente ad
hoc, non è stata definita una metodologia
esplicita: i membri che si occupano della
definizione dello standard ricevono solamente
delle guide informali per la costruzione dei
messaggi
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
ESEMPIO MESSAGGIO HL7
MSH|^~\&|GHH LAB|ELAB-3|GHH OE|BLDG4|200202150930||ORU^R01|CNTRL3456|P|2.4
PID|||555-44-4444||EVERYWOMAN^EVE^E^^^^L|JONES|196203520|F|||153
FERNWOOD DR.^^STATESVILLE^OH^35292||(206)3345232|(206)752121||||AC555444444||67-A4335^OH^20030520
OBR|1|845439^GHH OE|1045813^GHH LAB|1554-5^GLUCOSE|||200202150 730|||
||||||555-55-5555^PRIMARY^PATRICIA P^^^^MD^^LEVEL SEVEN
HEALTHCARE, INC.|||||||||F||||||444-44-4444^HIPPOCRATES^HOWARD
H^^^^MD
OBX|1|SN|1554-5^GLUCOSE^POST 12H CFST:MCNC:PT:SER/PLAS:QN|
|^182|mg/dl|70_105|H|||F<cr>
HL7 V2: VANTAGGI E SVANTAGGI
VANTAGGI
• Standard de facto
• Stabile
• Retro compatibile
• Diverse implementazioni
• Relativamente semplice
• Flessibile
• Costo relativamente basso
SVANTAGGI
• Pensato per la sanità
americana
• Ambiguo
• Interoperabilità limitata
• Troppo flessibile
• Destinato a non essere più
supportato
• Standard antiquato
• Difficoltà sulle certificazioni
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
PRINCIPI DI SVILUPPO
•
•
•
•
•
•
•
Internazionalizzazione
Opzionalità ridotta
Sistemi lascamente accoppiati
Compatibilità funzionale V2
Retro-compatibilità
Sicurezza
Privacy
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
RIM 2.18
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.
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.
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
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.
1.
2.
3.
4.
5.
L'applicazione trasmittente
("mittente") memorizza le sue
informazioni nel formato del
proprio database
Il mittente rappresenta
logicamente queste
informazioni come un grafo di
oggetti del RIM
Usando la forma dei messaggi
definita nell'HMD e
l'algoritmo definito dalle ITS il
mittente rappresenta gli
oggetti RIM come un
documento XML
Il mittente serializza il
documento creando un file
XML
Il mittente trasmette il file
XML alla applicazione
ricevente ("destinatario")
usando il TCP/IP, l'EMAIL o
altri livelli di trasporto
messaggi
6.
7.
8.
9.
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
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.
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.
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
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.
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.
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.
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
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.
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.
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.
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.
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.
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.