HL7 e IHE
Standard e
linee guida per il
loro utilizzo
L’architettura di interoperabilità
Azienda
Telemedicina
Sistema Informativo Ospedaliero
Glicemia da diabetico
Per monitoring
Diabetologia
Neurochirurgia
…..
Ortopedia
•Lab Analisi
•Radiologia
•Microbiologia
•Anatomia Patologica
•Med. Nucleare
•Ambulatori
Cardiologia
Immagini
Neuroradiologiche
Per teleconsulto
Servizi diagnostici
Repository dei dati clinici
Progetto e-gov “Telemed-Escape”
verso Medici Med. Gen.
Altri utilizzatori
esterni
Il sistema informativo di servizio
Richiesta
+ campioni
Laboratorio
Referto
Il punto di vista del reparto
Richiesta
+ campioni
Richiesta
+ campioni
Richiesta
+ campioni
Richiesta
Richiesta
Microbiologia
e virologia
Laboratorio
Anatomia
patologica
Radiologia
Visita
specialistica
Referto
Referto
Referto
Referto
Referto
Modello del sistema informativo
Sistema unificato di reparto
Richiesta
+ campioni
Richiesta
+ campioni
Richiesta
+ campioni
Richiesta
Richiesta
Sistemi clinici
Microbiologia
e virologia
Laboratorio
Anatomia
patologica
Radiologia
Visita
specialistica
Referto
Referto
Referto
Referto
Referto
Sistema unificato dei contenuti (=Repository)
La buona integrazione deve
• essere event driven – pilotata da un evento
• essere real time - tempo reale
• essere asincrona – senza aspettare la risposta di nessuno
• utilizzare uno standard
HL7
HEALTH LEVEL SEVEN
Esempio: HL7 richiesta di esami radiologici
MSH|^~\&|SI|SII|Eso|Istituto di Radiologia|||ORM^O01|SI030000000000000500|P|2.3.1|||||||
PID|||46644078^^^^ASSIPCA^~CNTSRA78L61D325O^^^^CODFISC||CONTIN^SARA||19780530|M||
|Via Vattelapesca 14^^Padova^PD^35128|||||||20981701|||||Udine|||||||
PV1||I|001300^Terapia intensiva^7|||||5101^Mario^Rossi
|||||||||||2070197100|||||||||||||||||||||||||200004210950|||||||V|
ORC|NW|20701971001^050901^001400^L|||CM||1^once^^20030730^^R|||124^Giulio^Verdi||5101^Mario^Rossi||2175|||
001300
OBR|1|2070197100-1^050901^001400^L||87^TC ADDOME INFERIORE||||||||N|TC di controllo in
paziente traumatizzato|||5101^Mario^Rossi|||||||||||1^once^^20030730^^R|||WHLC|||||||||||A
ORC|NW|20701971001^050901^001400^L|||CM||1^once^^20030730^^R|||124^Giulio^Verdi||5101^Mario^Rossi||2175|||
001300
OBR|2|2070197100-1^050901^001400^L||8^TC COLLO ||||||||N|TC di controllo in paziente
traumatizzato|||5101^Mario^Rossi|||||||||||1^once^^20030730^^R|||WHLC|||||||||||A
Health Level 7 – HL7
Messaggio
Segmento 1
Campo 1
Campo 2
Campo ...
Segmento 2
Segmento …
Esempio: HL7 richiesta di esami radiologici
MSH|^~\&|SI|SII|Eso|Istituto di Radiologia|||ORM^O01|SI030000000000000500|P|2.3.1|||||||
PID|||46644078^^^^ASSIPCA^~CNTSRA78L61D325O^^^^CODFISC||CONTIN^SARA||1978053
0|M|||Via Vattelapesca 14^^Padova^PD^35128|||||||20981701|||||Udine|||||||
PV1||I|001300^Terapia intensiva^7|||||5101^Mario^Rossi
|||||||||||2070197100|||||||||||||||||||||||||200004210950|||||||V|
ORC|NW|20701971001^050901^001400^L|||CM||1^once^^20030730^^R|||124^Giulio^Verdi||5101^Mario^Rossi||21
75|||001300
OBR|1|2070197100-1^050901^001400^L||87^TC ADDOME INFERIORE||||||||N|TC di controllo in
paziente traumatizzato|||5101^Mario^Rossi|||||||||||1^once^^20030730^^R|||WHLC|||||||||||A
ORC|NW|20701971001^050901^001400^L|||CM||1^once^^20030730^^R|||124^Giulio^Verdi||5101^Mario^Rossi||21
75|||001300
OBR|2|2070197100-1^050901^001400^L||8^TC COLLO ||||||||N|TC di controllo in paziente
traumatizzato|||5101^Mario^Rossi|||||||||||1^once^^20030730^^R|||WHLC|||||||||||A
Health Level 7 – HL7
Messaggi
• ADT
•A01 – Accettazione Ricovero
•A02 – Trasferimento
•A03 - Dimissione
• ORM – richieste di esami / Visite
• ORU – ritorno risultati strutturati
• MDM – comunicazione documento medico
•…
•…
•…
Modello del sistema informativo
Sistema unificato di reparto (ADT – ORM)
Richiesta
+ campioni
Richiesta
+ campioni
Richiesta
+ campioni
Richiesta
Richiesta
Sistemi clinici – erogazione della richiesta
Microbiologia
e virologia
Laboratorio
Anatomia
patologica
Radiologia
Visita
specialistica
Referto
Referto
Referto
Referto
Referto
Sitema unificato dei contenuti (=Repository)
ORU - MDM
Health Level 7 – HL7
Messaggio
Segmento 1
Campo 1
Campo 2
Campo ...
Segmento 2
Segmento …
Health Level 7 – HL7
MSH|^~\&|SSI|SI|?|?|200603091622||ADT^A01|SI060000000173484800|P|2.3
EVN|A01|20060309162211|||ER144^TOFFANIN^MARICA|20060309162211
PID||483051819^^^050116|46690891^^^L^ASSIPCA^~CNTSRA78L61D325O^
^^N^CODFISC^~483051819^^^050116^CODSAN^~^^^050116^STP||CONTIN
^SARA^^^^^L~^^^^^^C||196201010000|M|||VIA DUE
PALAZZI,35/A^^PADOVA^PD^35100^^L^028060^^^^^^C^||||||||483051819
PV1|1|I|013100^^^050901&013100&L^^^^^Clinica
medica|L||||~^^^^^^^^^^^^^050901&013100&L||RIC|||||||~^^^^^^^^^^^^^050901&
013100&L||200623543^^^^RIC_AO|SSN||||||||||||||||||||||||20060109162211||||||200
617415||^&
DG1|1||||20060309162211|A
Health Level 7 – HL7
MSH|^~\&|SSI|SI|?|?|200603091750||ADT^A02|SI060000000173499800|P|2.3
EVN|A02|20060309175018|||M60570^LERON^VANESSA|20060309110000
PID||483051819^^^050116|46690891^^^L^ASSIPCA^~CNTSRA78L61D325O^
^^N^CODFISC^~483051819^^^050116^CODSAN^~^^^050116^STP||CONTI
N^SARA^^^^^L~^^^^^^C||196201010000|M|||VIA DUE
PALAZZI,35/A^^PADOVA^PD^35100^^L^028060^^^^^^C^||||||||483051819
PV1|1|I| 015810^2^7^050901&015810&L^^^^^ISTAR 2 |||
013100^^^050901&013100&L^^^^^Clinica
medica||~^^^^^^^^^^^^^050901&018201&L|~^^^^^^^^^^^^^050901&015810&
L|RIC|||||||1962^ZANINOTTO&GIOVANNI^^^^^^^^^^^^050901&018201&L||
200623543 ^^^^RIC_AO|SSN|||||||||||||||||||||||| 20060109162211||||||||^&
Health Level 7 – HL7
MSH|^~\&|SSI|SI|?|?|200603091756||ADT^A03|SI060000000173500500|P|2.3
EVN|A03|20060309175614|||C000900^FREO^LUISA|20060309175458
PID||483051819^^^050116|46690891^^^L^ASSIPCA^~CNTSRA78L61D325O^
^^N^CODFISC^~483051819^^^050116^CODSAN^~^^^050116^STP||CONTI
N^SARA^^^^^L~^^^^^^C||196201010000|M|||VIA DUE
PALAZZI,35/A^^PADOVA^PD^35100^^L^028060^^^^^^C^||||||||483051819
PV1|1|I| 015810^2^7^050901&015810&L^^^^^ISTAR
2|||||~^^^^^^^^^^^^^050901&015810&L|~^^^^^^^^^^^^^050901&015810&L|RI
C|||||||~^^^^^^^^^^^^^050901&011807&L|| 200623543 ^^^^RIC_AO
|SSN|||||||||||||||||||||||| 20060109162211|20060309175458|||||20064710|V||
DG1|1||PREGRESSO DOLORE ADDOMINALE||20060309145138|F
Health Level 7 – HL7
I messaggi sono uguali
APPARENTEMENTE
Li distinguano la valorizzazione dei campi
Data di ricovero + reparto di ammissione
Data di trasferimento + reparto di destinazione del trasferimento
Data di dimissione + reparto di dimissione
…..
Health Level 7 – HL7
Tipologie di campi
• Testo (es. motivo dell’esame)
• Numerici (es. risultati dell’esame di laboratorio)
• Codificati (es. il campo dove indico che l’ordine è nuovo o
cancellato)
• Composti (es. identificativo della struttura che richiede
l’esame)
Esempio: HL7 richiesta di esami radiologici
MSH|^~\&|SI|SII|Eso|Istituto di Radiologia|||ORM^O01|SI030000000000000500|P|2.3.1|||||||
PID|||46644078^^^^ASSIPCA^~CNTSRA78L61D325O^^^^CODFISC||CONTIN^SARA||197805
30|M|||Via Vattelapesca 14^^Padova^PD^35128|||||||20981701|||||Udine|||||||
PV1||I|001300^Terapia intensiva^7|||||5101^Mario^Rossi
|||||||||||2070197100|||||||||||||||||||||||||200004210950|||||||V|
ORC|NW|20701971001^050901^001400^L|||CM||1^once^^20030730^^R|||124^Giulio^Verdi||5101^Mario^Rossi||
2175|||001300
OBR|1|2070197100-1^050901^001400^L||87^TC ADDOME INFERIORE^L||||||||N|TC di
controllo in paziente
traumatizzato|||5101^Mario^Rossi|||||||||||1^once^^20030730^^R|||WHLC|||||||||||A
ORC|NW|20701971001^050901^001400^L|||CM||1^once^^20030730^^R|||124^Giulio^Verdi||5101^Mario^Rossi||2
175|||001300
OBR|2|2070197100-1^050901^001400^L||8^TC COLLO^L||||||||N|TC di controllo in paziente
traumatizzato|||5101^Mario^Rossi|||||||||||1^once^^20030730^^R|||WHLC|||||||||||A
Health Level 7 – HL7
Tipologie di campi
• Singoli (es. data di nascita)
• Multipli (es. identificativo del paziente: codice aziendale,
codice fiscale, tessera sanitaria…)
Esempio: HL7 richiesta di esami radiologici
MSH|^~\&|SI|SII|Eso|Istituto di Radiologia|||ORM^O01|SI030000000000000500|P|2.3.1|||||||
PID|||46644078^^^^ASSIPCA^~CNTSRA78L61D325O^^^^CODFISC||CONTIN^SARA||1978
0530|M|||Via Vattelapesca 14^^Padova^PD^35128|||||||20981701|||||Udine|||||||
PV1||I|001300^Terapia intensiva^7|||||5101^Mario^Rossi
|||||||||||2070197100|||||||||||||||||||||||||200004210950|||||||V|
ORC|NW|20701971001^050901^001400^L|||CM||1^once^^20030730^^R|||124^Giulio^Verdi||5101^Mario^Rossi||2
175|||001300
OBR|1|2070197100-1^050901^001400^L||87^TC ADDOME INFERIORE^L||||||||N|TC di
controllo in paziente
traumatizzato|||5101^Mario^Rossi|||||||||||1^once^^20030730^^R|||WHLC|||||||||||A
ORC|NW|20701971001^050901^001400^L|||CM||1^once^^20030730^^R|||124^Giulio^Verdi||5101^Mario^Rossi||2
175|||001300
OBR|2|2070197100-1^050901^001400^L||8^TC COLLO^L||||||||N|TC di controllo in paziente
traumatizzato|||5101^Mario^Rossi|||||||||||1^once^^20030730^^R|||WHLC|||||||||||A
Health Level 7 – HL7
Versioni
• 2.3.1 – esempi visti fin’ora
• 2.5 – introduzione ad esempio di messaggi di laboratorio,
e di query
• 3.0 – abbandono della struttura in ‘|’, introduzione del xml
e di una struttura di base dati coerente con la
messaggistica (reference data model)
Health Level 7 – HL7
<ADT_A01>
<MSH>
<MSH_1_FieldSeparator>|</MSH_1_FieldSeparator>
<MSH_2_EncodingCharacters>^~\&amp;</MSH_2_EncodingCharacters>
<MSH_3_SendingApplication>
<EI>
<EI_1_EntityIdentifier>REGADT</EI_1_EntityIdentifier>
</EI>
</MSH_3_SendingApplication>
<MSH_4_SendingFacility>
<EI>
<EI_1_EntityIdentifier>MCM</EI_1_EntityIdentifier>
</EI>
</MSH_4_SendingFacility>
<MSH_5_ReceivingApplication>
<EI>
<EI_1_EntityIdentifier>RSP1P8</EI_1_EntityIdentifier>
</EI>
…
</MSH>
Health Level 7 – HL7
<PID>
<PID_3_PatientIDInternalID>
<CX>
<CX_1_ID>MR2</CX_1_ID>
<CX_4_AssigningAuthority>XYZ</CX_4_AssigningAuthority>
</CX>
</PID_3_PatientIDInternalID>
<PID_5_PatientName>
<XPN>
<XPN_1_FamilyName>JONES</XPN_1_FamilyName>
<XPN_2_GivenName>WILLIAM</XPN_2_GivenName>
<XPN_3_MiddleInitialorName>A</XPN_3_MiddleInitialorName>
<XPN_4_Suffix>JR</XPN_4_Suffix>
</XPN>
</PID_5_PatientName>
<PID_7_DateTimeofBirth>19501010</PID_7_DateTimeofBirth>
<PID_8_Sex>M</PID_8_Sex>
<PID_11_PatientAddress>
<XAD>
<XAD_1_StreetAddress>123 EAST STREET</XAD_1_StreetAddress>
<XAD_3_City>NY</XAD_3_City>
<XAD_4_StateorProvince>NY</XAD_4_StateorProvince>
<XAD_5_Ziporpostalcode>10021</XAD_5_Ziporpostalcode>
</XAD>
</PID_11_PatientAddress>
…
Come gestire correttamente oltre 16000
messaggi al giorno?
• Inviare i messaggi ai destinatari corretti (uno o più)
• Gestire le code di messaggi (un sistema non risponde e gli altri,
che non sono bloccati, continuano a generare messaggi che non si devono
perdere)
• Avere un punto unico di controllo sul flusso dei
messaggi
STRUTTURA
HUB & SPOKE
Come gestire correttamente oltre 16000
messaggi al giorno?
SI UTILIZZA UN
E.A.I.
Enterprise Application Integrator
E.A.I.
Enterprise Application Integrator
Ogni sistema ha i suoi ‘canali’ per la comunicazione dei messaggi
E.A.I.
Enterprise Application Integrator
Enterprise Application Integrator
Come applicare l’HL7
IHE
Integrating the
Healthcare Enterprise
Integrating the Healthcare Enterprise
(IHE)
 e’ un progetto
 ha lo scopo di semplificare l’integrazione in ambiente
sanitario
 ha lo scopo di permette l’interoperabilità, ossia la
possibilità di operare reciprocamente tra diversi sistemi
Integrating the Healthcare Enterprise
(IHE)
Non è uno standard
E’ la grammatica
per poter parlare tramite
STANDARD
(HL7 – DICOM)
Integrating the Healthcare Enterprise
(IHE)
Gli sponsor di IHE
•Radiological Society of North America
(RSNA)
• Healthcare Information and Management
System Society (HIMSS)
Integrating the Healthcare Enterprise
(IHE)
Organizzazione IHE
International IHE Committee
US IHE Committee
France IHE Committee
Europe IHE Committee
German IHE Committee
UK IHE Committee
Japan IHE Committee
Italy IHE Committee
Integrating the Healthcare Enterprise
(IHE)
I comitati europei
• Redicono i tecnical Framework nazionale
• Supportano i partecipanti al Connect-a-thon
• Organizzano Demo nazionali
• Gestiscono attività di educational
Integrating the Healthcare Enterprise
(IHE)
Parte da un sostanziale problema nella sanità:
“Come rendere interoperabili tutte le diverse
procedure che gestiscono il workflow dei dati
anagrafici del paziente dalla accettazione del
ricovero all’esecuzione di un esame radiologico,
cardiologico, di laboratorio”
Integrating the Healthcare Enterprise
(IHE)
Si propone cioè di definire in maniera chiara come
gli standard esistenti (in particolare DICOM e
HL7) dovrebbero essere utilizzati dai diversi
sistemi informativi per realizzare un'integrazione
tra loro
Integrating the Healthcare Enterprise
(IHE)
Le parole chiavi di IHE sono:
PR O FI LI
ATT O R I
TRAN SAZI O NI
Integrating the Healthcare Enterprise
(IHE)
I PROFILI
“Danno indicazione sull’organizzazione di attori
e transazioni nei specifici indirizzi di cura di cui
un paziente ha bisogno”
Integrating the Healthcare Enterprise
(IHE)
QUALI SONO I PROFILI
IHE è nato in “ambiente radiologico”
I primi 7 profili creati riguardavano infatti
prettamente la radiologia
Scheduled Workflow
Ammissione, ordine, schedulazione, immagini, notifica
del completamento del WF
Patient
Information
Reconciliation
Consistent
Presentation
of images
Access to
Radiology
Information
Pazienti
sconosciuti
e ordini
non schedulati
Presentazione
delle immagini
Coerente
Accesso a
Immagini e
documenti
Presentation of
Grouped Procedures
Key Image
Notes
Modifica delle
Immagini
significative
Simple Image and
Numric Reports
Modifica di semplici
documenti con
immagini link
e misurazioni
Integrating the Healthcare Enterprise
(IHE)
successivamente è stato implementato
introducendo i flussi di laboratorio, di
cardiologia, di gestione anagrafica, di
gestione dei referti….
Integrating the Healthcare Enterprise
(IHE)
GLI ATTORI
“Sono le applicazioni che producono e/o
gestiscono determinate informazioni”
Integrating the Healthcare Enterprise
(IHE)
Esempi di Attori
ADT
Patient Registration
Il sistema informativo responsabile dell’aggiunta o modifica
delle informazioni relative all’anagrafica del paziente e del suo
accesso alla struttura ospedaliera
ORDER
PLACER
Il sistema informativo responsabile della gestione “ordini”, che li
genera e li distribuisce nei dipartimentali di riferimento
ORDER FILLER
Dpt System Scheduler
Il sistema informativo dipartimentale responsabile della
gestione degli ordini ricevuti dall’Order Placer
Integrating the Healthcare Enterprise
(IHE)
LE
TRANSAZIONI
Order
Placer
Order
Filler
New order
Order accepted
“Sono scambi di informazioni
Battery replaced
tra attori”
Acknowledgement
Status change
Acknowledgement
Integrating the Healthcare Enterprise
(IHE)
Le transazioni sono l’insieme di:
• Trigger Events: eventi che scaturiscono l’invio dei messaggi
Es. inserimento nuova anagrafica, richiesta esame
• Message semantics: I messaggi che devono essere generati
Es. ADT^A01
•Expected Actions: Le azioni che devono scaturire a fronte
della ricezione di un messaggio
Integrating the Healthcare Enterprise
(IHE)
le TECNOLOGIE per le
transazioni
L’unico standard tecnologico che IHE indica e’
TCP/IP, e tutti i messaggi delle transizioni
avvengono sfruttando i socket
Integrating the Healthcare Enterprise
(IHE)
Tutte le linee guida di IHE sono
contenute nei
TECHNICAL
FRAMEWORK
IHE – Technical framework
Possiamo distingure i Technical framework
1. “verticali”: trattano singole realtà
(radiologia, laboratorio, cardiologia)
2. “orizzontali”: trattano le infrastrutture dello
strato sovrastante le singole realtà
(anagrafica, ADT)
IHE – Technical framework
Ogni TF è diviso in 2 volumi: 1. Integration profiles (scenari)
IHE – Technical framework
2. Transaction
IHE – Technical framework
di radiologia
Il workflow radiologico
Reg.
Paziente e
ins. richiesta
Invio worklist
Archiviazione
immagini
schedulazione
richiesta
Archiviazione
definitiva
Procedure di cambio stato
IHE – TF di radiologia
IHE Standards Based Transactions
• HL7:
- ADT Messages (A01-08, A11-13, A38, A40)
- ORM Messages
•DICOM:
- Modality Worklist Management (MWL)
- Modality Performed Procedure Step (MPPS)
- Storage, Storage Commitment
- Query/Retrieve
IHE – TF di radiologia
Normale flusso amministrativo
IHE – TF di radiologia
Aggiornamento paziente prima della richiesta
IHE – TF di radiologia
Aggiornamento paziente dopo della richiesta
IHE – TF di radiologia
Aggiornamento paziente dopo che la richiesta è
stata schedulata
IHE – TF di radiologia
Ordine modificato dall’Order Placer
IHE – TF di radiologia
Ordine modificato dal DSS
Integrating the Healthcare Enterprise
(IHE)
Technical Framework
• Laboratorio: definisce un nuovo profilo in ambiente
laboratorista e non più radiologico. Nel TF del laboratorio
sono indicati gli attori e le transazioni, ossia i messaggi
stantard da utilizzare e le loro implementazioni (Use case).
Use Case del workflow
del laboratorio (LSWF)
• Ordine scaturito dalla procedura di richiesta ordine con
campione identificato
• Ordine scaturito dalla procedura di richiesta ordine con
campione non identificato
• Ordine scaturito dalla procedura di laboratorio con
campione identificato
Schema di workflow di laboratorio
(LSWF)
Clinical
validation
Technical
validation
GLI ATTORI
del workflow di laboratorio (LSWF)
• ADT – Gestisce le informazioni relative al paziente
(demografiche,visite…). Feeds other actors.
• Order Placer – Genera e distribuisce gli ordini delle analisi
verso gli Order Filler. In alcune organizzazioni raccoglie e
identifica i campioni
• Order Filler – Riceve gli ordini delle analisi, schedula il
lavoro, valida i risultati e li spedisce al Result Tracker. Gestisce
gli stati degli ordini. In alcune organizzazioni crea gli ordini e
identifica i campioni.
GLI ATTORI
del workflow di laboratorio (LSWF)
• Automation Manager – Gestisce le informazioni nel
laboratorio. Riceve gli ordini dall’Order Filler, processa gli ordini
e restituisce i risultati
• Order Result Tracker – Archivia i risultati delle analisi
Schema di workflow di laboratorio
(LSWF)
Clinical
validation
Technical
validation
LE TRANSAZIONI
del workflow di laboratorio (LSWF)
• RAD1 – Registrazione dei pazienti
• RAD12 – Aggiornamento dei pazienti
• LAB1 – Comunicazione tra OP e OF dell’ordine
• LAB2 – Notifica di un nuovo ordine dall’OF all’OP
LE TRANSAZIONI
del workflow di laboratorio (LSWF)
• LAB3 – Comunicazione dei risultati e del cambio stato
ordine (correzione, cancellazione, cambio stato).
•LAB4 – Ditribuzione del lavoro al Automation Manager
(PUSH). Inoltro l’ordine e i dati del paziente
• LAB5 – Invio dei risultati dei all’OF
Integrazione del profilo di laboratorio
Laboratory Scheduled
Workflow (LSWF)
Laboratory Point Of
Care Testing (LPOCT)
Completed in 2003
Nov 2004
Esami eseguiti da un
laboratorio per un paziente
identificato
Esami eseguiti
in point of care
Laboratory Patient Information
Reconciliation (LPIR) In Process
Esami eseguiti per pazienti
sconosciuti o mal identificati
Laboratory Code Set Distribution
(LCSD) In Process
Sharing the batteries and tests code sets
throughout the enterprise
Laboratory Device
Automation (LDA)
In Process –TI Nov 2004
Processi pre-analitici, analisi e
trattamenti post-analitici
Integrating the Healthcare Enterprise
(IHE)
Technical Framework
• Cardiologia: definisce un nuovo profilo in ambiente
cardiologico con i suoi attori e con le sue transazioni, ossia i
messaggi stantard da utilizzare e le loro implementazioni
(Use case).
Integrating the Healthcare Enterprise
(IHE)
Technical Framework
• IT Infrastructure: definisce le implementazioni degli
standard per l’integrazione di archivi medici da condividere
per un supporto ottimale alle cure del paziente. ITI
identifica un subset di componenti funzionali della struttura
sanitaria, gli attori, e specifica le loro transazioni
Integrazione del profilo di
IT Infrastructure
Cross-Enterprise
Document Sharing
Registration, distribution
and access across health
enterprises of clinical
documents forming a
patient electronic health
record
Retrieve Information
for Display
Access a patient’s clinical
information and documents
in a format ready to be
presented
to the requesting user
Map patient identifiers
Map patient
identifiers
across
independent
across
independent
identification domains
identification domains
Access to workforce
contact information
Patient Demographics
Query
Patient Synchronized
Applications
Audit Trail & Node
Authentication
Patient Identifier Crossreferencing for MPI
Personnel White Page
Centralized privacy audit trail
and node to node
authentication to create a
secured domain.
Consistent Time
Coordinate time across
networked systems
Synchronize multiple
applications on a desktop to
the same patient
Enterprise User
Authentication
Provide users a single name
and centralized authentication
process
across all systems
Patient Identifier Cross – Referencing
for MPI
Scopi
• Permette a tutte le strutture integrate di registrare le
informazioni per loro utili che riguardano i pazienti
• Fornisce un sistema di query per richiedere informazioni
dei propri pazienti identificati da altri sistemi
• Notifica ai sistemi della struttura quando altri sistemi
aggiornano le informazioni dei i loro pazienti (opzionale)