Seminario Alessandro Sulis, 25-10-2012

950 views
720 views

Published on

Si inquadrano lo stato dell'arte del settore ed il progressivo processo di informatizzazione. Si descrivono i più usati standard internazionali, le modalità di utilizzo e il loro ruolo fondamentale per l'interoperabilità e integrazione di sistemi informativi.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
950
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Seminario Alessandro Sulis, 25-10-2012

  1. 1. Standard internazionali e lineeguida per il software nel settore della salute Alessandro Sulis alessandro.sulis@crs4.it
  2. 2. Agenda• Introduzione: l’importanza delle informazioni• Parola chiave: interoperabilità• Standard Interazionali – HL7: Health Level Seven – IHE: Integrating the Healthcare Enterprise• Use case: il «problema degli spaghetti»• Mirth Connect• Conclusioni
  3. 3. L’importanza delle informazioni• Un ospedale moderno non può prescindere dall’utilizzo di strutture informatiche e tecnologiche all’avanguardia• La pratica clinica si basa sulla gestione e sul trattamento di informazioni indispensabili per prendere decisioni puntuali sulle terapie e cure da seguire• Informazioni non sempre disponibili in forma digitale e non sempre uniformi
  4. 4. Parola chiave: interoperabilità /1 Come trasmetto la Chi è il paziente? richiesta alla E’ registrato? radiologia?Come lo identifico? Paziente in contatto constessa Richiesta di prestazione Ho la Come associo le l’ospedale radiologica anagrafica di chi mi ha immagini alla richiesta PS/reparti richiesto la e al paziente corretto? prestazione? Come rendo fruibili le Sono sicuro di immagini al reparto? Come rendo fruibile ilEvento clinico immagini refertare referto al reparto? relative al paziente corretto? Esecuzione di una radiografia e Produzione e trasmissione produzione delle immagini del referto
  5. 5. Parola chiave: interoperabilità /2• Sistemi diversi -> tipologie di dati clinici diverse• Mancata interoperabilità: procedure «manuali» – Consegna manuale accettazione radiologia – Trasferimento cartaceo immagine per refertazione – Trasferimento cartaceo immagine e referto• Tempi non accettabili• Aumento della probabilità di errore• Necessità di un linguaggio comune
  6. 6. Soluzione: standardizzazione• Linguaggio e procedure comuni per la trasmissione delle informazioni cliniche• Linguaggio dedicato (non è il solo) – HL7 (Health Level 7)• Utilizzo coordinato di standard (come HL7), contestualizzato a precisi domini clinici : – IHE (Integrating the Healthcare Enterprise)
  7. 7. HL7: un po’ di storia• Organizzazione volontaria e no profit• Nome: ultimo livello pila ISO/OSI• Fondata nel 1987, accreditata poi nel 1995 dall’American Standard Institute• Autorità globale: HL7 international -> http://www.hl7.org• Organismi nazionali: HL7 Italia -> (http://www.hl7italia.it)
  8. 8. HL7: struttura dello standard• Possiamo identificare tre macroblocchi: – Messaggistica -> HL7v2.x , HL7v3 – Documentale: HL7 CDA (Clinical Document Architecture) – Concettuale: RIM (Reference Information Model)• Focus -> Messaggistica, in particolare su HL7 v2.x• HL7 V3 -> Prende un’altra strada, filosofia completamente differente dalla v2.x
  9. 9. HL7v2: background (1/2)● Livello applicazione: definizione di cosa si è scambiato (data), quando è avvenuto lo scambio (timing) e gli eventuali errori (error)● Obiettivo principale (cit. HL7 V2.5, Ch. 1,p.3): ● “Address the interfaces among various systems that send or receive patient admissions/registration,discharge or transfer (ADT) data, queries, resource and patient scheduling, orders, results, clinical observations, billing,master file update information,medical records, scheduling,patient referral and patient care ”
  10. 10. HL7 v2: background (2/2)● Contenuti ● Rules (Definizioni e regole sintattiche messaggi) ● Patient Administration (ADT and registration) ● Order Entry ● Query ● Observation Reporting
  11. 11. Messaggi: struttura gerarchica e delimitatori (1/2)MSH|^~&|LB|Modulo LB|LIP|Reparto A|201210251630||QBP^SLI^QBP_Q11|001|P|2.5|||||IT||ITQPD|SLI^Specimen Labeling Instructions^IHE_LABTF|0001|RCP|I||R ● Message – Segment ● Field ● Component ● Subcomponent ● [……….] – Segment – Field M1-S2-F1 ● Field M1-S2-F2 ● [……….]
  12. 12. Messaggi: struttura gerarchica e delimitatori (2/2) Delimiter Suggested Value Encoding Usage Character Position Segment Terminator <cr> - Terminates a segment record Field Separator | - Separates two adjacent data fields within a segment Component ^ 1 Separates adjacent Separator components of data fields where allowed Subcomponent & 4 Separates adjacent Separator subcomponents of data fields where allowed Repetition Separator ~ 2 Separates multiple occurrences of a field where allowed Escape Character 3 Escape character
  13. 13. Messaggi: segmentiMSH|^~&|LB|Modulo LB|LIP|Reparto A|201210251630||QBP^SLI^QBP_Q11|001|P|2.5|||||IT||ITQPD|SLI^Specimen Labeling Instructions^IHE_LABTF|0001|RCP|I||R • Segmento: gruppo logico di campi • E’ sempre identificato da una sequenza iniziale di tre lettere a inizio riga • Messaggio: deve iniziare col segmento MSH • Occorrenze: una, nessuna o più di una, a seconda del message type • Alcuni segmenti sono obbligatori, sempre a seconda del message type
  14. 14. Messaggi: campiMSH|^~&|LB|Modulo LB|LIP|Reparto A|201210251630||QBP^SLI^QBP_Q11|001|P|2.5|||||IT||ITQPD|SLI^Specimen Labeling Instructions^IHE_LABTF|0001|RCP|I||R ● Definiti come una sequenza di caratteri, rappresentano i dati effettivamente trasmessi e vengono identificati tramite gli attributi: ● Position: Posizione ordinale allinterno del segmento ● Maximum Length: Lunghezza massima ● Data type: tipo di dato contenuto ● Optionality (R=Required,C=Conditional,O=Optional) ● Repetition
  15. 15. Segmento MSHMSH|^~&|LB| LB_A|LIP|LIP_A|201210251630||QBP^SLI^QBP_Q11|001|P|2.5|||||IT||IT Codici delle ID Univoco del Timestamp del Tipo di messaggio applicazioni inviante Messaggio messaggio - Message Code (ID) e ricevente - Trigger Event (ID) - Message Structure(ID)
  16. 16. Tipologie di messaggiMessage Descrizione Trigger Event DescrizioneType ID IDQBP Query (Request) Q21 Get Person Demographics (Query)RSP Query (Response) K22 Get Person Demographics (Response)ADT Patient Administration A28 Add Person or Patient InformationORM Order Message O01 General Order Message
  17. 17. Esempio ADT_A28 (Request&ACK)MSH|^~&|GST||||20070117092534||ADT^A28^ADT_A28|1263483|T|2.5|||AL|AL|ITAPID|||1025^^^PK||PAOLINO^PAPERINO||19491129|M||||||||||PLNPRN49S29D335TPV1||N Segmento MSA: immediatamente dopoMSH|^~&|MIRTH||GST||20121024234404||ACK^A28^ACK|20121024234404|T|2.5 MSH nel messaggio diMSA|AA|1263483 Informazioni ACK (AA= Application paziente (Cognome,Accept) Nome, Data ID Nuova Anagrafica Nascita…..) MSA-2: Ripetuto l’identificativo univoco del messaggio di richiesta (MSH-10)
  18. 18. Scambio di messaggi HL7 : transactions QBP_Q11 RSP_K11 (ACK) INITIATOR RECEIVERMSH|^~&|LB|Modulo LB|LIP|Reparto A|201210251630||QBP^SLI^QBP_Q11|001|P|2.5|||||IT||ITQPD|SLI^Specimen Labeling Instructions^IHE_LABTF|0001|100001|RCP|I||RMSH|^~&|LIP|Reparto A|LB|Modulo LB|201210251630||RSP^SLI^RSP_K11|002|P|2.5|||||IT||ITMSA|AA|001||||QAK||0001|OK|Q22^Specimen Labeling Instructions^IHE_LABTF|1QPD|SLI^Specimen Labeling Instructions^IHE_LABTF|0001|100001|PID|1||123456^^^Ospedale A^PI||Rossi^Mario^^^^^L|19810101|MPV1|1|O|||||||||||||||||3333444SPM|1|1234560001||001^Venous blood|||||||P||||||20070112|||||||||1|021^ChimicaORC|NW|1234561|||||||201210251630|14789^Rossi^Mario||14789^Rossi^Mario|||||051^GastroTQ1|||||||||ROBR||1234561||17432^liver function^local|||||6.0|||||||14789^Rossi^Mario
  19. 19. HL7v2: riepilogo• Linguaggio ben definito per la comunicazione fra sistemi ospedalieri• Ciascun messaggio ha un tipo e una sintassi ben definiti• Comunicazione bidirezionale fra i sistemi (message/ACK)• Problema fondamentale: applicazione in un contesto reale• Quali messaggi utilizzare?
  20. 20. IHE: Integrating the Healthcare Enterprise• Consorzio fondato e gestito da professionisti della sanità e dell’industria con l’obiettivo di migliorare metodologie e condivisione dell’informazione fra sistemi• Sollecita fortemente l’utilizzo degli standard esistenti, ma focalizzandone l’attenzione su aspetti procedurali e domini applicativi• Pubblica, per ciascun domninio applicativo, i relativi Technical Frameworks
  21. 21. IHE: Domini Applicativi● Anathomic Pathology● Cardiology● Eye Care● IT Infrastructure● Laboratory● Patient Care Coordination/Devices● Radation Oncology● Radiology
  22. 22. IHE: Organizzazione dei processi IHE supporta lutilizzo delle tecnologie (HL7,DICOM,ecc.), contestualizzandole ai fari domini e producendo i relativi Technical Frameworks (TF) Il risultato di questa certificazione è la produzione da parte del I vendors fanno vendor degli IHE riferimento ai TF e sulla Integration Statements base di questi sviluppano e la registrazione le loro soluzioni di dellapplicativo come integrazione IHE e ne IHE conforme certificano la conformità partecipando agli eventi Connectathon
  23. 23. IHE: Technical Frameworks • TF diversi per ciascun dominio (Laboatorio, Radiologia, Ecc.) • Profili di integrazione: worklow specifici per ciascun dominio (Es. Laboratory Barcode Labeling) • Attori/Transazioni: scambio di informazioni tra i sistemi (messaggi)
  24. 24. …..dal Connectathon 2012 a Pisa….
  25. 25. …ma nella realtà??• Sistemi periferici obsoleti e che non parlano HL7, informaticamente isolati dagli altri• Tipologie di dati non uniformi• Semantica dei dati (codici prestazioni)• Mancanza di una anagrafica centralizzata• Costi di raggiungimento dell’interoperabilità elevati (costruzione di interfacce ad-hoc per ciascun sistema)
  26. 26. Integrazione «a spaghetti>> Laboratorio Oracle View Hl7 Radiologia V2.3Farmacia TXT HL7 TXT V2.5 Anatomia SIO Sistema Informativo Patologica Ospedaliero
  27. 27. Integrazione <<a stella>> Laboratorio Oracle View Hl7 V2.3 RadiologiaFarmacia TXT HL7 TXT V2.5 Anatomia SIO Patologica Sistema Informativo Ospedaliero
  28. 28. Mirth Connect: Powering Healthcare Transformation• Nasce come strumento per la semplificazione, trasformazione e routing dei messaggi HL7• Molto potente, grazie alla capacità di agganciarsi a qualunque sorgente dati• Scritto in Java, sfrutta la libreria HL7Api per la trasformazione dei messaggi• Basato su piattaforma di integrazione, che dà la possibilità di scrivere blocchi di codice ad- hoc (Javascript-Rhino)
  29. 29. Mirth Connect: Overview (1/3)• Connessioni verso qualunque sistema e con qualunque protocollo – TCP/MLLP, Database, XML…… – FTP, PDF, Email…..• Trasformazione, selezione e routing dati – HL7 v2-v3, CDA, DICOM, X12 – Progettazione di canali «black-box»
  30. 30. Mirth Connect: Overview (2/3)
  31. 31. Mirth Connect: Overview (3/3)
  32. 32. Grazie per l’attenzione!!!!!

×