STANDARD DI INTEGRAZIONE IN SANITA DICOM E HL7. Corso di TELEMEDICINA Lezione del 03/12/08

Transcript

1 STANDARD DI INTEGRAZIONE IN SANITA DICOM E HL7 Corso di TELEMEDICINA Lezione del 03/12/08

2 NECESSITA DELL ICT Nel mondo dell ICT ci sono alcune importanti necessità: CONDIVISIONE DELLE INFORMAZIONI INTEGRAZIONE DELLE DIVERSE APPLICAZIONI E SISTEMI INFORMATIVI INTEGRAZIONE DELLE DIVERSE TECNOLOGIE E PIATTAFORME

3 IMPORTANZA DEGLI STANDARD La risposta alle richieste dell ICT è data da: Standard Aperti Architetture Aperte Interoperabilità 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.

4 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)

5 SIGNIFICATI: UNI EN - ISO UNI Contraddistingue tutte le norme nazionali italiane e significa che la norma è stata elaborata direttamente dalle Commissioni UNI o dagli Enti Federati EN 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)

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

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

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

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

10 Standard di comunicazione Interconnessione: 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à.

11 Sistemi di scambio dei dati Codice ASCII (American Standard Code for Information Interexchange) Codice a 8 bit 256 combinazioni disponibili Serve a codificare lettere, numeri e simboli

12

13 API Application Program Interface Hanno 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.

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

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

16 Progetto TETA (BN)

17 Aree delle inforamazioni cliniche Area A : CUP e Scheda di accettazione Area B : Anamnesi del paziente Area C : Diario Clinico, terapie, prestazione specialistiche, esami dignostici.. L area B è difficilmente standardizzabile poichè dipende dal reparto a cui si riferisce.

18 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 informazioni Tracciabilità del patient work-flow tra le diverse strutture

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

20 Standard nell area ICT SANITA I due principali standard utilizzati in sanità sono: DICOM HL7 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!

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

22 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

23 2 problema: non tutto poteva essere digitale CT = Computed Tomography US = Ultra Sound MR = Magnetic Resonance NM = Nuclear Medicine Distribuzione media del carico di lavoro (esami) sulle varie modalità Fonte: Fuji 2003

24 Soluzione: Il protocollo DICOM 3 DICOM 3 ACR NEMA DICOM 3.0 ACR: American College of Radiology NEMA National Electrical Manufacturers' Association DICOM Digital Imaging and Communications in Medicine PS 3.1: Introduction and Overview (this document) PS 3.2: Conformance PS 3.3: Information Object Definitions PS 3.4: Service Class Specifications PS 3.5: Data Structure and Encoding PS 3.6: Data Dictionary PS 3.7: Message Exchange PS 3.8: Network Communication Support for Message Exchange PS 3.9: Point to Point Communication Support for Message Exchange," PS 3.10: Media Storage and File Format for Data Interchange PS 3.11: Media Storage Application Profiles PS 3.12: Media Formats and Physical Media for Data Interchange PS 3.13: Print management point-to-point communication support PS 3.14 Grayscale Standard Display Function PS 3.15: Security Profiles PS 3.16: Content Mapping Resource

25 DICOM: UN PO DI STORIA Nel 1983 ACR (American College of Radiology) e la NEMA (National Electrical Manifactures 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 In seguito nel 1988 venne pubblicata la nuova versione 2.0 ACR-NEMA (non prevedeva specifiche di comunicazione in rete)

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

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

28

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

30

31 Scambio di informazioni Alla base del protocollo in esame esiste un approccio Client/Server, nel senso che, ogni volta che due applicazioni decidono di connettersi per scambiarsi informazioni, una delle due deve svolgere il ruolo di fornitore del servizio (SCP: Service Class Provider) mentre l'altra quello di utente (SCU: Service Class User).

32

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

34

35

36 Stratificazione dello standard Gli standard per la "comunicazione elettronica" sono sempre composti da più strati, ognuno dei quali ha dei compiti e delle funzioni specifiche (ISO-OSI) Il vantaggio della stratificazione è che uno strato può essere modificato, aggiornato ecc., senza interferire con gli altri.

37 Modello Entità Relazioni Lo standard Dicom si basa sul principio dell' "entity-ralationship (E-R) modeling", ossia in 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 degli attributi

38 ENTITA Attributi Relazioni

39 Dicom Message Service Elements-DIMSEs In Dicom3 è prevista una serie di "servizi" standardizzati che assicurano lo svolgimento di operazioni quali archiviazione dei dati, stampa delle immagini, ricerca dei dati, ecc. A causa della struttura orientata agli oggetti di Dicom3, i servizi sono organizzati in classi di servizi.

40 SOP Class Gli oggetti d'informazione e le classi di servizi sono 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.).

41 Parti dello standard Dicom (1-3) 1) La prima parte contiene una panoramica dello standard stesso, con descrizione dei principi basilari; quando abbiamo presentato 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 potrebbero contenere gruppi di attributi simili, raccolti insieme in una serie di moduli comuni.

42 Parti dello standard Dicom (4) 4) specifiche delle classi di servizi (SOP Class) che sono basate su di una serie di operazioni base, operanti su IOD. ESEMPI : certificazione, memorizzazione, richiamo/consultazione di immagini ed informazioni, contenuto dello studio, gestione del paziente, gestione dell'esame, gestione del referto, gestione della documentazione.

43 Parti dello standard Dicom (5-7) 5) specifiche della codifica dati ed i relativi processi ESEMPIO: JPEG per le immagini 6) Elenco completo di tutti gli elementi dei dati, 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 è costituito da una stringa di comando ed una stringa di dati.

44 Parti dello standard Dicom (8-9) 8) Supporto di rete per il trasferimento dei messaggi (TCP-IP) 9) modalità relative ai vecchi protocolli punto-punto ancora in uso presso vecchi sistemi.

45

46 Ogni attributo è identificato da una coppia di numeri esadecimali detto tag Valori dell attributo 109 righe 91 colonne

47 Nome Attributo In genere viene riportato anche il tipo dell attributo con una sigla TM=Time oppure CS = Coded String etc.. I Pixel stanno alla fine del file messaggio e sono preceduti da una serie di informazioni aggiuntive

48 ESEMPIO DI IMMAGINE DICOM

49

50 Sicurezza DICOM ha limitato gli interventi in materia di sicurezza agli aspetti relativi al trasferimento e alla codifica dell informazione. Supporta meccanismi per consentire l autenticazione, la confidenzialità e l integrità a livello di connessione, mediante il protocollo SSL (Security Sockets Layer). Non supporta strumenti specifici per controllare gli accessi e per identificare chi accede ai dati.

51 HL7 Health Level Seven

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

53 Perché nasce HL7? 1 Struttura Sanitaria/Reparto 2 Struttura Sanitaria/Reparto documentazione storia clinica pregressa Lettera di dimissione referti anamnesi sistema informatico dimissione ricovero sistema informatico ammissione medico trasferimento medico

54 Perché nasce HL7? Sistema Informativo 1 Sistema Informativo 2

55 Perché nasce HL7? HL7 Messaggio Creazione Messaggio HL7 Parsing Messaggio HL7

56 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 modello corrisponde invece alla definizione concettuale di un'interfaccia di tipo paritario (applicazione-applicazione) posta al settimo livello del modello OSI

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

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

59 Temi dello scambio di dati ammissione/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.

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

61 Possibili interazioni aggiornamento 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.

62 Come funziona HL7? Descrive in maniera particolareggiata il layout dei Messaggi che vengono scambiati fra due o più applicazioni che si scambiano informazioni Divide i Messaggi in segmenti e li identifica con il nome del paziente Un Messaggio è costituito da una sequenza ordinata di Segmenti Un Segmento è una collezione ordinata di Data Elements Tipicamente i Data Elements all'interno di un Segmento riguardano un argomento comune Il Tipo del Messaggio è identificato da un codice di tre lettere, e l Evento che scatena l'inizio di una comunicazione è denominato evento trigger

63 Versione HL Gestisce 95 tipologie di messaggi Per ciascun messaggio vengono fornite delle indicazioni di processo relativamente ai possibili scambi di informazioni Il "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.

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

65 Messaggio di conferma di ricevimento

66 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

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

68 Messaggio ADT con i segmenti MSH message header EVN trigger event PID patient id PV1 patient visit information

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

70

71

72

73 Vantaggi dell HL7 2.xx Fra 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.

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

75 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)

76 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)

77

78 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

79 I 6 backbone Act - le azioni che vengono eseguite e che devono essere documentate in ciascun processo di cura Participation - 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.

80

81 Definizione del RIM Tale 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)

82 Vantaggi della procedura di definizione di un RIM definizione di precise specifiche funzionali definizione di un data model consistente definizione 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.

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

84 Clinical Document Architecture (CDA) Standard che specifica la struttura e la semantica dei documenti clinici Un 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.

85 Caratteristiche del CDA Utilizzo di extensible Markup Language (XML) Utilizzo del RIM HL7 versione 3 e dei tipi di dati/messaggi definiti in tale standard Utilizzo 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)

86 CDA livelli di architettura CDA 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 RIM CDA L2 dovrà rappresentare una specificazione del livello precedente e dovrà contenere l'insieme delle strutture e della semantica ammissibile per ciascun tipo di documento CDA L3 rappresenterà un'ulteriore specificazione del livello precedente e dovrà precisare il contenuto clinico espresso formalmente nel documento attraverso l'utilizzo del modello RIM

87 Un documento CDA è taggato dall elemento <ClinicalDocument> > e contiene un Header e un Body. <ClinicalDocument> CDA Header <StructuredBody> CDA Body </StructuredBody StructuredBody> </ClinicalDocument ClinicalDocument>

88 L Header è compreso tra <ClinicalDocument< ClinicalDocument> > e <StructuredBody< StructuredBody>, ed identifica e classifica il documento e fornisce informazioni sull autenticazione (document( information), cosa ha scatenato il dato (encounter( encounter), il paziente (service( targets) ) e gli operatori coinvolti (service( actors) Il Body contiene il report clinico e può essere sia un blob non strutturato, che dati compresi tra markup strutturati. In questo caso, è diviso in sezioni di documenti innestabili e ricorsive. Una sezione è compresa tra elementi <Section> > e può contenere un blocco narrativo singolo, un certo numero di entries,, ed external reference

89 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 CDA e, l'utilizzo di XML come linguaggio di comunicazione.