STANDARD DI INTEGRAZIONE IN SANITA’ DICOM E HL7 · Lezione del 03/12/08. NECESSITA’ DELL’ICT...

STANDARD DI INTEGRAZIONE IN SANITA’

DICOM E HL7

Corso di TELEMEDICINALezione del 03/12/08

NECESSITA’ DELL’ICT

Nel mondo dell’ICT ci sono alcuneimportanti necessità:

CONDIVISIONE DELLE INFORMAZIONIINTEGRAZIONE DELLE DIVERSE APPLICAZIONI E SISTEMI INFORMATIVIINTEGRAZIONE DELLE DIVERSE TECNOLOGIE E PIATTAFORME

IMPORTANZA DEGLI STANDARD

La risposta alle richieste dell’ICT è data da:Standard ApertiArchitetture AperteInteroperabilità

Solo in questo modo si rende possibile il riuso e lo scambio di informazioni tra società diverse al fine di dare servizi on line e on time adeguati alla richiesta del pubblico.

Standard, norma e percorso di certificazione

Direttiva Europea 98/34/CE del 22 giugno 1998

La Norma è la specifica tecnica approvata da un organismo riconosciuto a svolgere attività normativa e che appartenga a una delle seguenti categorie:

norma internazionale (ISO)norma europea (EN)norma nazionale (UNI)

SIGNIFICATI: UNI – EN - ISOUNI Contraddistingue tutte le norme nazionali italiane e significa che la norma è stata elaborata direttamente dalle Commissioni UNI o dagli Enti FederatiEN Identifica le norme elaborate dal CEN (ComitéEuropéen de Normalisation). Le norme EN devono essere obbligatoriamente recepite dai paesi membri C.E., divenendo quindi norme UNI EN. Servono come riferimento per tutte le norme europee e non si ammettono norme nazionali discordanti.ISO Individua le norme elaborate dall’ISO (International Organization for Standardization). Queste norme sono un riferimento applicabile in tutto il mondo, a livello nazionale (UNI ISO) oppure a livello europeo (UNI EN ISO)

DEFINIZIONE DI NORMA

Le NORME sono documenti che definiscono le caratteristiche (dimensionali, prestazionali, ambientali, di sicurezza, di organizzazione ecc.) di un prodotto, processo o servizio, secondo lo stato dell'arte.

DEFINIZIONE DI STANDARD

Lo STANDARD è un modello di riferimento che utilizza un insieme di elementi per uniformare le caratteristiche di un prodotto o servizio con l'obiettivo di semplificare processi operativi, ottimizzare le risorse, ridurre i costi.

CERTIFICAZIONE

La certificazione di un prodotto o servizio può avvenire solo dopo la predisposizione di uno standard e tendenzialmente solo dopo che uno standard è stato reso oggetto di una norma.

Vantaggi di standard e norme

Riduzione dei costi: razionalizzazione delle attività di impresa e dei processi produttivi.Sviluppo di un economia del settore di riferimento, garantendo la conformità dei prodotti alle norme nazionali dei paesi di destinazione (norme EN e ISO).Supportare il legislatore e l'interazione cliente-fornitore, poiché viene demandata alle norme la definizione di requisiti tecnici di riferimento.

Standard di comunicazioneInterconnessione: si intende la possibilità

tecnica di trasferire dati da un sistema a un altro.

Interoperabilità: si intende la possibilitàche i dati, prodotti e archiviati in un sistema, siano comunicati e riutilizzati in un altro sistema/applicativo all'interno di una data azienda o tra quest'ultima e altre aziende.Alla facilità di interconnessione si contrappone la necessità di accordi precisi per ottenere l’interoperabilità.

Sistemi di scambio dei dati

Codice ASCII (American Standard Code for Information Interexchange)

Codice a 8 bit256 combinazioni disponibiliServe a codificare lettere, numeri e simboli

API

Application Program InterfaceHanno rappresentato e rappresentano una modalità più elaborata per lo scambio di dati tra applicazioni.L’inconveniente è che questa soluzione obbliga a fare sviluppi specifici per ciascun caso applicativo.Conveniente quando gli applicativi coinvolti nel sistema sono pochi. In un HIS si stima che intervengano 20/30 applicativi diversi con centinaia di interfacce.

PATIENT FILE (1)Data base degli eventi socio sanitari significativi relativi al paziente.Tale database può essere consultato, con i dovuti accorgimenti tecnologici in materia di autenticazione, autorizzazione e privacy, dagli attori sociosanitari del sistema, che possono risalire ai dati sanitari di un dato paziente.Si privilegia l'invio di dati anche in formati grezzi (per esempio .pdf) più che fornire dati in formati standard in modo che tali informazioni possano essere riutilizzati in ambiti diversi e in applicativi diversi.

PATIENT FILE (2)Best Practice basata sulla tendenza di creare diversi data repository clinici (EMR – Electronic Medical Record) che vengono popolati dalle diverse strutture sanitarie.Creazione di una rete di dati che assicura l’interconnessione e l’interoperabilità dei dati.E’ indispensabile uno standard per i dati e i protocolli di comunicazioni per rendere disponibile l’informazione on demand dalle e alle diverse strutture.

Progetto TETA (BN)

Aree delle inforamazioni cliniche

Area A : CUP e Scheda di accettazioneArea B : Anamnesi del pazienteArea C : Diario Clinico, terapie,

prestazione specialistiche, esamidignostici …..L’area B è difficilmente standardizzabilepoichè dipende dal reparto a cui siriferisce.

Costruzione di un EMR standardizzato

Per costruzione di un EMR si intende sostanzialmente la costruzione di un data repository che consenta prevalentemente il mix del contenuto informativo dell'area A e dell'area C (e solo parzialmente dell'area B)Riutilizzo e interoperabilità delle informazioniTracciabilità del patient work-flow tra le diverse strutture

Electronic Patient Record

La costruzione di Electronic PatientRecord significa rendere possibile la condivisione in rete di varie strutture di EMR attraverso l'utilizzo di particolari meccanismi di ricerca.

Standard nell’area ICT SANITA’I due principali standard utilizzati in sanitàsono:

DICOMHL7

Il DICOM è stato approvato dall’ISO mentre l’HL7 è ancora uno standard de facto in fase di approvazione.La maggior parte dei paesi europei ha adottato versioni nazionali di HL7.L’Italia ovviamente è in grave ritardo !

L’avvento del digitale: nuove potenzialità diagnostiche…

Raggi X = la pellicola svolge contemporaneamente il ruolo di detettore della radiazione, visualizzazione delle immagini e conservazione dei dati

Anni ’70-’80: l’introduzione degli ultrasuoni e della Tomografia assiale computerizzata la catena di formazione dell’immagine cambia e l’immagine diventa disponibile immediatamente sui monitor.Sta per iniziare il digitale….

…e nuovi problemi.1° problema: la compatibilità

Ogni modalità digitale era un’isola tecnologica proprietaria, con il suo monitor, la sua stampante il suo software di gestione…

2° problema: non tutto poteva essere digitale

Fonte: Fuji 2003

Distribuzione media del carico di lavoro (esami) sulle varie modalità

CT = Computed TomographyUS = Ultra SoundMR = Magnetic ResonanceNM = Nuclear Medicine

Soluzione: Il protocollo DICOM 3

ACR: American College of RadiologyNEMA National Electrical Manufacturers' AssociationDICOM Digital Imaging and Communications in Medicine

DICOM 3ACR NEMA DICOM 3.0

PS 3.1: Introduction and Overview (this document)PS 3.2: ConformancePS 3.3: Information Object DefinitionsPS 3.4: Service Class SpecificationsPS 3.5: Data Structure and EncodingPS 3.6: Data DictionaryPS 3.7: Message ExchangePS 3.8: Network Communication Support for

Message ExchangePS 3.9: Point to Point Communication Support

for Message Exchange,"

PS 3.10: Media Storage and File Format forData Interchange

PS 3.11: Media Storage Application ProfilesPS 3.12: Media Formats and Physical Media

for Data InterchangePS 3.13: Print management point-to-point

communication supportPS 3.14 Grayscale Standard Display FunctionPS 3.15: Security ProfilesPS 3.16: Content Mapping Resource

DICOM: UN PO’ DI STORIANel 1983 ACR (American College of Radiology) e la NEMA (National ElectricalManifactures Association) cominciano a lavorare allo standard.Dopo due anni fu presentato alla RSNA (Radiological Society of North America) la prima versione dello standard ACR-NEMA 300-1985 1.0In seguito nel 1988 venne pubblicata la nuova versione 2.0 ACR-NEMA 300-1988 (non prevedeva specifiche di comunicazione in rete)

DICOM: UN PO’ DI STORIA (2)Con l'adozione di una particolare architettura dei dati chiamata "struttura orientata per oggetti" si arrivò allo sviluppo della nuova versione definita DICOM/3, che superava le difficoltà di interconnessione in rete con l'adozione di due protocolli il TCP/IP e l'ISO-OSI. Quindi DICOM/3 da' la possibilità ai suoi utilizzatori di verificare se due apparecchi dichiarati conformi sono in grado di scambiare informazioni. Il completamento delle specifiche dello standard avviene nel 1993 e viene presentato dal RSNA.

Definizione

Il DICOM consente ai vari dispositivi medici (TAC, risonanza ecc,) l'archiviazione e lo scambio delle immagini e delle informazioni associate in un formato digitale.Il DICOM è uno standard di comunicazione che permette la comunicazione digitale tra diagnostiche e apparecchiature di diversi produttori.

Il protocollo DICOM 3

Lo standard definisce come deve essere redatta la dichiarazione di conformità.

Non esiste un ente certificatore. E’ un onere totalmente a carico della ditta costruttrice dell'apparecchiatura che si dichiara conforme allo Standard

Quindi nonostante ufficialmente i dispositivi abbiano”le carte in regola” per una effettiva aderenza allo Standard, in pratica molte connessioni risultano difficoltose se non addirittura impossibili.

Scambio di informazioni

Alla base del protocollo in esameesiste un approccio Client/Server, nelsenso che, ogni volta che due applicazioni decidono di connettersiper scambiarsi informazioni, una delledue deve svolgere il ruolo di fornitoredel servizio (SCP: Service Class Provider) mentre l'altra quello di utente (SCU: Service Class User).

Il protocollo DICOM 3

Le più importanti classi di servizi DICOM:

Print: gestisce le comunicazioni tra una applicazione DICOM e una stampante

Storage: gestisce il trasferimento e l’archiviazione di immagini tra applicazioni DICOM

Query/Retrieve: gestisce le operazioni di accesso e trasferimento di immagini in base a un criterio di ricerca

Verification: verifica le comunicazioni tra applicazioni DICOM

Working list: Gestisce la connessione tra i dati del paziente (all’interno del RIS) e le immagini prodotte dalle diverse modalità diagnostiche. In questo modo si ha una relazione univoca tra dati personali e dati dell’immagine.

Stratificazione dello standard

Gli standard per la "comunicazioneelettronica" sono sempre composti dapiù strati, ognuno dei quali ha deicompiti e delle funzioni specifiche(ISO-OSI)Il vantaggio della stratificazione è cheuno strato può essere modificato, aggiornato ecc., senza interferire con gli altri.

Modello Entità RelazioniLo standard Dicom si basa sul principio dell' "entity-ralationship (E-R) modeling", ossiain esso vengono definite una serie di entità, per esempio il paziente o delle immagini, più tutta una serie di relazioni tra tali entitàstesse.Le entità vengono definite anche oggetti. Il modello a oggetti è un principio fondamentale del Dicom. La definizione di un oggetto in Dicom3 avviene mediante la definizione degliattributi

ENTITA’

Attributi

Relazioni

Dicom Message Service Elements-DIMSEs

In Dicom3 è prevista una serie di "servizi" standardizzati che assicuranolo svolgimento di operazioni qualiarchiviazione dei dati, stampa delleimmagini, ricerca dei dati, ecc.A causa della struttura orientata aglioggetti di Dicom3, i servizi sonoorganizzati in classi di servizi.

SOP ClassGli oggetti d'informazione e le classi di servizisono i due componenti fondamentali di Dicom3, i primi contengono i dati da trattare, le seconde si occupano della manipolazione di tali dati.La combinazione degli oggetti d'informazione e delle classi di servizi forma la SOP Class (Service Object Pair), l'unità funzionale di Dicom3.Per esempio Dicom3 definisce una serie di classi SOP per l'immagazzinamento dei dati (CT storage SOP Class, MR storage SOP Class, ecc.).

Parti dello standard Dicom (1-3)

1) La prima parte contiene una panoramicadello standard stesso, con descrizione deiprincipi basilari; quando abbiamopresentato la filosofia di questo standard sono stati introdotti i concetti di "oggetti" e "SOP Class" (entità).2) Definizione di conformità verso DICOM (non presente nelle prime due versioni)3) Definizione degli oggetti di informazione(IOD), alcuni dei quali potrebberocontenere gruppi di attributi simili, raccoltiinsieme in una serie di moduli comuni.

Parti dello standard Dicom (4)

4) specifiche delle classi di servizi(SOP Class) che sono basate su di una serie di operazioni base, operantisu IOD.

ESEMPI : certificazione, memorizzazione, richiamo/consultazione di immagini ed informazioni, contenuto dello studio, gestione del paziente, gestionedell'esame, gestione del referto, gestionedella documentazione.

Parti dello standard Dicom (5-7)

5) specifiche della codifica dati ed i relativiprocessi

ESEMPIO: JPEG per le immagini6) Elenco completo di tutti gli elementi deidati, insieme ai loro valori numerici o alfanumerici.7) Definisce ciò che è necessario al software applicativo per interagire con i protocolli di comunicazione DICOM. Il formato base di un messaggio è costituitoda una stringa di comando ed una stringadi dati.

Parti dello standard Dicom (8-9)

8) Supporto di rete per iltrasferimento dei messaggi (TCP-IP)9) modalità relative ai vecchiprotocolli punto-punto ancora in usopresso vecchi sistemi.

Ogni attributo èidentificato dauna coppia di numeriesadecimalidetto “tag”

Valoridell’attributo

109 righe91 colonne

Nome AttributoIn genere vieneriportato anche il tipodell’attributo con unasigla – TM=Time oppure CS = Coded String etc..

I Pixel stanno allafine del file messaggio e sonopreceduti da unaserie di informazioniaggiuntive

ESEMPIO DI IMMAGINE DICOM

SicurezzaDICOM ha limitato gli interventi in materiadi sicurezza agli aspetti relativi al trasferimento e alla codificadell’informazione.Supporta meccanismi per consentirel’autenticazione, la confidenzialità e l’integrità a livello di connessione, medianteil protocollo SSL (Security Sockets Layer).Non supporta strumenti specifici per controllare gli accessi e per identificare chi accede ai dati.

HL7Health Level Seven

Health Level Seven - HL7

Il progetto HL7 prende il via nel marzo 1987 l'obiettivo è semplificare le interfacce fra i diversi applicativi sanitari si incentra sulla standardizzazione dei formati per lo scambio di alcuni gruppi di dati considerati comuni a ogni sistema di tipo sanitario.

ricoveroricovero

1° Struttura Sanitaria/Reparto

sistema

informatico

medico

anamnesi

amm

issioneam

missione

sistema

informatico

medicotrasferimentotrasferimento

Perché nasce HL7?

documentazione

Lettera di dimissionereferti

dimissione

dimissione

2° Struttura Sanitaria/Reparto

storia clinicapregressa

Sistema Informativo 1 Sistema Informativo 2

Perché nasce HL7?

010010010011101010010010011101

Creazione Messaggio HL7 Parsing Messaggio HL7

HL7

Messaggio

Perché nasce HL7?

Level 7 La dizione Level 7 fa riferimento al livello più alto del modello ISO/OSI (livello applicazione)non significa che HL7 sia conforme agli elementi definiti dal livello 7 dell'OSI, néche lo standard specifichi oggetti per i livelli dall'uno al sei del modellocorrisponde invece alla definizione concettuale di un'interfaccia di tipo paritario (applicazione-applicazione) posta al settimo livello del modello OSI

Modalità broadcast

Tale standard prevede che le informazioni vengano impacchettate in messaggi strutturati e trasmessi opportunamente con modalitàproattive, ovvero non on demand, ma bensì anticipando l'esigenza del sistema destinatario (modalitàbroadcast).

Socket e XML

La tecnologia utilizzata a oggi (HL7 versione 2.3.1) prevede scambio di messaggi via socket, ma ben presto sarà approvato lo standard HL7 versione 3, che utilizzeràmessaggistica basata completamente su tecnologia XML.

Temi dello scambio di datiammissione/dimissione/trasferimento dei pazienti;interrogazioni della banca dati sanitaria;pianificazione delle attività sanitarie e dell'impiego delle risorse:effettuazione di ordini;comunicazione di dati sanitari;gestione economica del ricovero;aggiornamento dei master file;gestione dei referti;assistenza al paziente e richiesta di consulenze.

Tecnologia di trasferimento

HL7 supporta gli scambi informativi fra sistemi implementati con una qualsiasi tecnologia (dal sistema di rete più evoluto a un sistema che scambia dati attraverso file e floppy disk); supporta lo scambio dei dati di singole transazioni o di un insieme di transazioni raggruppate in file;È pensato come una interfaccia plug and play fra diversi sistemi.

Possibili interazioniaggiornamento dei dati non sollecitato (il sistema inviante fornisce un aggiornamento di dati al sistema ricevente che trasmette una conferma del ricevimento (acknoledgment)interrogazione (query), grazie alla quale un sistema può interrogare una controparte che fornisce la risposta o una condizione di errore;ogni messaggio inviato (notificato in modalitàbroadcast) non può essere ripudiato ed è quindi sempre confermato dalla controparte.

Descrive in maniera particolareggiata il “layout” deiMessaggi che vengono scambiati fra due o piùapplicazioni che si scambiano informazioniDivide i Messaggi in segmenti e li identifica con il nome del pazienteUn Messaggio è costituito da una sequenza ordinata diSegmentiUn Segmento è una collezione ordinata di Data ElementsTipicamente i Data Elements all'interno di un Segmentoriguardano un argomento comuneIl Tipo del Messaggio è identificato da un codice di trelettere, e l‘Evento che scatena l'inizio di unacomunicazione è denominato evento “trigger”

Come funziona HL7?

Versione HL7 2.3.1

Gestisce 95 tipologie di messaggiPer ciascun messaggio vengono fornite delle indicazioni di processo relativamente ai possibili scambi di informazioniIl "messaggio ADT" (che è uno dei 95 messaggi di HL7) regola, per esempio, la fase di accettazione e dimissione di un paziente. Tale messaggio è composto da 51 eventi.

Comunicazione dell’ EVENTO A1 di ADT (accettazione o dimissione di un paziente)

Messaggio di conferma di ricevimento

Messaggio

Un messaggio è la + piccola unità in HL7 ed è composto da SEGMENTI.Inizia con un Header (MSH) ed èidentificato dal tipo e dall’evento iniziale (trigger)Es. L’evento di accettazione di un paziente è identificato da tipo ADT e dall’evento A01

Segmenti

I segmenti sono una ordinata sequenza di campiEs. L’anagrafica è un segmento che contiene vari campiSono identificati da 3 lettere (segment identifier)Possono essere di tipo obbligatorio, opzionale o ripetibile

Messaggio ADT con i segmenti

MSH message headerEVN trigger eventPID patient idPV1 patient visitinformation

CAMPI

Le informazioni contenute nei segmenti sono organizzate in campi.I campi possono essere di lunghezza variabile e di tipo diverso

Vantaggi dell’ HL7 2.xxFra i punti di forza del progetto HL7 versione 2.xx vi èsicuramente quello di poter fungere da collante fra sistemi di tipo eterogeneo.La gestione degli elementi fondamentali (messaggi (ADT), eventi (A01.), segmenti (PID), attributi del segmento (campi e contenuto dei campi) consente nel contempo di predefinire un data model o, quanto meno, di costituire una check list per verificare quali campi sono contenuti nel database aziendale e quali sono da implementare al fine di consentire l’integrazione e interoperabilità tra sistemi informativi diversi anche al fine della costruzione di EMR/EPR.

Problemi della versione 2.xx

L’HL7 2.xx rimane un data base di messaggi e manca di una organizzazione e di un modello di utilizzo.Nella versione 3 si superano tali problemi.

Obiettivi della versione 3

Creare un modello formale di riferimento chiamato RIM (Reference Information Model), basato su un unico linguaggio UML(Unified Modeling Language);Utilizzare XML per la sintassi dei messaggi;Definire uno standard per i documenti clinici CDA (Clinical Document Architecture)

RIM (Reference Information Model)

Sono stati definiti due modelli paralleli:

Un modello per l'analisi di casi d'utilizzo reali - Use Case Model (UCM)Un modello di informazioni detto Domain Information Model (DIM)

Scenario per ogni caso

Differentemente dalla versione HL7 2.xx viene definito dapprima uno scenario per ogni "caso"Partendo da tale scenario gli sviluppatori seguono una specifica metodologia che consente di definire sei principali backbone

I 6 backboneAct - le azioni che vengono eseguite e che devono essere documentate in ciascun processo di curaParticipation - come definizione dello scenario di contesto per un'azione in termini di chi fa cosa, per chi è stato fatto, dove è stato fatto;Entity - rappresenta le entità che partecipano al processo di cura;Role - che stabilisce i ruoli che le varie entitàsvolgono e come le stesse partecipano al processo di cura;actRelationship - che definisce la relazione tra un atto e un altro;roleLink - che rappresenta le relazioni tra i diversi attori coinvolti.

Definizione del RIMTale metodologia consente di precisare uno scenario/modello d'utilizzo (UCM) in base al quale viene definito un modello di informazioni necessarie per supportare lo scenario operativo (DIM) e un conseguente scenario di interazioni tra le varie entità(Interaction Model - IM) in base al quale viene definita la messaggistica di integrazione e interoperabilità(HDM)

Vantaggi della procedura di definizione di un RIM

definizione di precise specifiche funzionali definizione di un data model consistentedefinizione rigorosa di ciascun messaggio dichiarazione di conformità da utilizzare da parte degli sviluppatori al fine di aumentare il grado di interoperabilità tra applicazione e sistemi che utilizzano HL7 versione 3.xx.

Conclusioni sui RIM

Il RIM non deve essere inteso come un modello logico o fisico di database né come disegno per un sistema informativo Il RIM rappresenta l'universo dei dati e delle relazioni dai quali può essere costruito qualsiasi rilevante messaggio HL7.

Clinical Document Architecture(CDA)

Standard che specifica la struttura e la semantica dei documenti cliniciUn documento clinico contiene osservazioni e servizi e deve possedere le seguenti caratteristiche:

persistenza: un documento clinico continua a esistere senza alcuna alterazione per un periodo di tempo definito da regole locali o regionali;responsabilità: un documento clinico è mantenuto da una persona o da un'organizzazione che è responsabile del suo contenuto;possibilità di autenticazione: un documento clinico è un insieme di informazioni per le quali deve essere possibile un'autenticazione legale integrità: l'autenticazione di un documento clinico si applica alla totalità delle informazioni contenute e non può essere applicata solo a parti del documento estrapolandole dal contesto in cui sono state prodotte;leggibilità umana: un documento clinico deve essere leggibile da un essere umano.

Caratteristiche del CDA

Utilizzo di eXtensible Markup Language(XML)Utilizzo del RIM HL7 versione 3 e dei tipi di dati/messaggi definiti in tale standardUtilizzo di una gerarchia di specifiche per la produzione e lo scambio dei documenti (architettura):

Level One (CDA L1)Level two (CDA L2)Level Three (CDA L3)

CDA livelli di architetturaCDA L1 rappresenta la specifica più generale dei documenti che sono formalizzati da un header(intestazione) e da un body (corpo del documento). Nel corpo del documento devono essere utilizzate le classi di oggetti definiti dal RIMCDA L2 dovrà rappresentare una specificazione del livello precedente e dovrà contenere l'insieme delle strutture e della semantica ammissibile per ciascun tipo di documentoCDA L3 rappresenterà un'ulteriore specificazione del livello precedente e dovrà precisare il contenuto clinico espresso formalmente nel documento attraverso l'utilizzo del modello RIM

Un documento CDA Un documento CDA èè ““taggatotaggato”” dalldall’’elemento elemento <<ClinicalDocumentClinicalDocument> e contiene un > e contiene un HeaderHeader e un e un BodyBody..

<<ClinicalDocumentClinicalDocument>>

…… CDA CDA HeaderHeader ……

<<StructuredBodyStructuredBody>>

…… CDA Body CDA Body ……

</</StructuredBodyStructuredBody>>

</</ClinicalDocumentClinicalDocument>>

LL’’HeaderHeader èè compreso tra <compreso tra <ClinicalDocumentClinicalDocument> e <> e <StructuredBodyStructuredBody>, ed identifica e classifica il >, ed identifica e classifica il documento e fornisce informazioni sulldocumento e fornisce informazioni sull’’autenticazione (autenticazione (documentdocument informationinformation), cosa ha ), cosa ha scatenato il dato (scatenato il dato (encounterencounter), il paziente (), il paziente (service service targetstargets) e gli operatori coinvolti () e gli operatori coinvolti (service service actorsactors))

Il Body contiene il Il Body contiene il report clinicoreport clinico e può e può essere sia un blob non strutturato, che essere sia un blob non strutturato, che dati compresi tra markup strutturati. In dati compresi tra markup strutturati. In questo caso, questo caso, èè diviso in sezioni di diviso in sezioni di documenti innestabili e ricorsive.documenti innestabili e ricorsive.

Una sezione Una sezione èè compresa tra elementi compresa tra elementi <<SectionSection> e può contenere un blocco > e può contenere un blocco narrativo singolo, un certo numero di narrativo singolo, un certo numero di ““entriesentries””, ed , ed ““externalexternal referencereference””

Conclusioni sulla ver. 3 dell’HL7

Rispetto alle versioni precedenti le grandi novità, come si è detto, sono la definizione di scenari di integrazione (RIM) e della relativa messaggistica, l'architettura del CDAe, l'utilizzo di XML come linguaggio di comunicazione.