Modulo MED/50 Gestione della risorsa digitale nei percorsi diagnostici Master di I° livello in Scienze Tecniche applicate alla Gestione dei sistemi Informatici in Diagnostica per Immagini Modulo MED/50 Gestione della risorsa digitale nei percorsi diagnostici Empoli, 07 IX 2010 Ing. Flavio Flamini

Agenda Sistemi ed INTEGRAZIONI tra sistemi EVOLUZIONI dei sistemi in Sanità

Agenda INTEGRAZIONI tra sistemi EVOLUZIONI dei sistemi in Sanità Standards Iniziative Lavoro EVOLUZIONI dei sistemi in Sanità

I sistemi in sanità CR - Computed Radiography PACS - Picture Archival & Communication System RIS – Radiology Information Service Sistemi di trasmissione WEB-based Sistemi HIS Sistemi di Gestione delle Prenotazioni (CUP) Sistemi di Gestione delle Degenze (ADT) Sistemi per il trattamento clinico (EPR, …) Sistemi di produzione di altra documentazione ECG, EEG, tracciati, esami di laboratorio etc.

Gli Standard La qualità nella cura di un paziente dipende dalla possibilità di aggregare informazioni. Condividere informazioni della storia clinica di un paziente è un fattore fondamentale per un miglioramento nei costi, nella produttività e qualità del settore sanitario. In tale contesto emerge l’importanza degli standard.

Gli standard in Medicina

Digital Imaging and Communication In Medicine DICOM: cos’è - 1 Digital Imaging and Communication In Medicine standard globale promosso dagli sforzi congiunti di ACR (American College of Radiology) e NEMA (National Electrical Manufacturers Association) storia: 1983 inizio collaborazione ACR-NEMA 1985 ACR-NEMA 1.0 1988 ACR-NEMA 2.0 1993 ACR-NEMA 3.0

DICOM: cos’è - 2 Definisce i criteri per la comunicazione, la visualizzazione, l'archiviazione e la stampa di informazioni di tipo biomedico E’ pubblico, nel senso che la sua definizione è accessibile a tutti. E’ uno standard industriale,e non uno standard ISO, quindi universale: ciò comporta una certa tolleranza nell'implementazione delle specifiche. La conformità DICOM può riguardare determinate proprietà e non altre. Occorre notare che il DICOM è uno standard industriale, e non uno standard ISO, quindi universale: ciò comporta una certa tolleranza nell'implementazione delle specifiche, al punto che attualmente forse non esistono apparecchiature che possano definirsi pienamente DICOM compliant, nel senso rigoroso che la definizione di uno standard imporrebbe. Nella maggior parte dei casi, infatti, un'apparecchiatura risulta conforme ad una parte dello standard (ad esempio la modalità di archiviazione delle immagini), mentre adotta tecnologie proprietarie per altre funzionalità (ad esempio la gestione delle liste pazienti). La compatibilità DICOM ed in generare di qualsiasi dispositivo DICOM compatibile deve essere certificata dal costruttore attraverso un documento autocertificativo, denominato Conformance Statement, che ne elenchi le funzionalità. La trattazione dettagliata del conformance statement che un costruttore deve emettere, per poter dichiarare una sua applicazione conforme allo standard DICOM, è contenuta nel volume 2 delle specifiche DICOM. Il buon esito di una connessione tra due apparecchiature DICOM è in prima istanza legato al confronto tra i due conformance statement, a meno di errori sui documenti od omissioni nell'implementazione, eventualità purtroppo tutt'altro che remote

DICOM: cos’è - 3 NON è un formato di compressione. Lo standard DICOM applicato alla codifica dei file è un metodo per incapsulare i dati e per definire come questi debbano essere codificati o interpretati. L'immagine viene archiviata in forma non compressa, secondo la codifica con la quale viene prodotta, anche se esistono molti software che sono in grado di produrre o interpretare file DICOM contenenti dati compressi secondo vari algoritmi (JPEG, JPEG Lossless, JPEG Lossy, vari algoritmi dello standard JPEG2000, etc.

OBJECTS = I.O.(Information Objects) DICOM: cosa fa -1 descrive il mondo reale rappresentandolo tramite una struttura Object-Oriented  oggetti e relazioni OBJECT (=I.O.) (es. immagine CT) Attributes: KV, mAs, position.. SERVICE (=DIMSE) (es. send, store..) Dicom Services Message Elements: L'approccio a sviluppare strutture di dati basate su modelli e analisi di versioni astratte di entita` reali e` la cosidetta "struttura orientata per oggetti" la quale offre il grande vantaggio di mostrare chiaramente, sia i dati richiesti in un determinato scenario modellato, sia le modalita` di interazione e correlazione tra di essi. Un entita` del mondo reale come un paziente, un ricovero, un immagine... viene modellata come un oggetto; ogni oggetto ha in se` una serie di attributi, per sempio l'oggetto paziente conterra` gli attributi dati anagrafici, data di ricovero ecc.. Definiti gli oggetti di interesse e tutte le loro caratteristiche, DICOM definisce quali operazioni possono essere eseguite e su quali oggetti. Tali operazioni sono chiamate DIMSE service (Dicom Message Service). La combinazione di un oggetto ed i corrispondenti servizi prende il nome di SOP (Service Object Pair). L'insieme delle SOP relative ad un unico oggetto formano una SOP Class. OBJECTS = I.O.(Information Objects) ex : CT Image, MR Image, RT Plan... each Object includes a set of attributs (known as IOD=IO Definition) ex: for a CT Image object, attributs= kV, mAs, position,.. SERVICES = DIMSE (Dicom Services Message Elements) ex : send, store, query, retrieve... Service Object Pair (SOP) (es. store a CT image)

SERVICES = DIMSE (Dicom Services Message Elements) DICOM: cosa fa -2 descrive il mondo reale rappresentandolo tramite una approccio client-server  user e provider SCU = Service Class User SCP = Service Class Provider OBJECTS = I.O.(Information Objects) ex : CT Image, MR Image, RT Plan... each Object includes a set of attributs (known as IOD=IO Definition) ex: for a CT Image object, attributs= kV, mAs, position,.. SERVICES = DIMSE (Dicom Services Message Elements) ex : send, store, query, retrieve... Store this image pls Image has been stored CT Storage SCP CT Storage SCU

DICOM: Struttura -1 Le specifiche di DICOM sono suddivise in parti; questo e` stato fatto al fine di poter aggiornare la singola parte senza dover ripubblicare l'intero standard. La corrente versione consiste in 9 parti (figura 1) piu` due capitoli aggiuntivi che fissano i criteri secondo cui i files di DICOM possono essere scambiati attraverso supporti di memoria removibili come dischi e nastri.                                                                                                         Parte 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" (entita`). Parte 2: E' nella seconda parte che viene fornita la definizione di conformita` verso DICOM, cioe` si richiede ai costruttori di descrivere chiaramente come i loro apparecchi siano conformi a DICOM. Le precedenti versioni 1.0 e 2.0 di ACR NEMA non avevano queste caratteristiche, cosi` che era possibile per due apparecchi essere dichiarati conformi pur utilizzando strutture e software diversi che non avrebbero permesso loro la comunicazione. Parte 3: La terza parte formula la definizione degli oggetti di informazione (IOD), alcuni dei quali potrebbero contenere gruppi di attributi simili, raccolti insieme in una serie di moduli comuni. Tali oggetti composti sono per esempio un immagine TC, RM, NM, US, ecc e contengono attributi inerenti alla stessa entita` del mondo reale ed altri non inerenti. L'utilizzo di oggetti composti e` dovuto al fatto che la recente letteratura informatica ha mostrato che usando tale struttura, i relativi attributi possono essere richiamati con un minor numero di accessi. Parte 4: Il contenuto della quarta parte mostra le specifiche delle classi di servizi (SOP Class) che sono basate su di una serie di operazioni base, operanti su IOD. Tali classi di servizi sono: certificazione, memorizzazione, richiamo/consultazione di immagini ed informazioni, contenuto dello studio, gestione del paziente, gestione dell'esame, gestione del referto, gestione della documentazione. Quando un'applicazione DICOM genera una serie di dati, questa deve essere decodificata per poter essere inserita in un messaggio per la comunicazione. Parte 5: Le specifiche della codifica dati ed i relativi processi formano la quinta parte di DICOM. La principale funzione di questa parte puo` essere definita il "linguaggio" che due apparecchi devono usare per comunicare (es formato JPEG per la compressione delle immagini). Parte 6: La parte 6 e` l'elenco completo di tutti gli elementi dei dati, insieme ai loro valori numerici o alfanumerici. Parte 7: La settima parte definisce cio` che e` necessario al software applicativo per interagire con i protocolli di comunicazione DICOM. Il formato base di un messaggio e` costituito da una stringa di comando ed una stringa di dati. Parte 8: Il supporto di rete per il trasferimento dei messaggi e` descritto nella ottava parte: In ambiente DICOM il protocollo di comunicazione utilizzato e` il TCP/IP che rappresenta uno standard ormai molto diffuso che consente il trasferimento di immagini e dati a prescindere dal mezzo fisico di trasmissione in modo efficente e coordinato. Data l'esistenza di molte reti di comunicazione, realizzate secondo strategie differenti, la scelta di questo standard rappresenta una soluzione ideale al trasferimento delle immagini diagnostiche, sia a livello locale, che su rete metropolitana (MAN) o geografica (WAN). Parte 9: Infine nella nona ed ultima parte sono raggruppate tutte le modalita` relative ai vecchi protocolli punto-punto ancora in uso presso vecchi sistemi.

PACS e DICOM Storage Query/Retrieve Print Modality Worklist (1997/1999) Perfomed Procedure Step (2000) Storage Commitment (1999) MODALITA’ modality worklist RIS HIS Date indicano il primo prodotto commerciale che le supporta store images storage commitment HL7 PPS PACS query/retrieve print

DICOM: Conformance Statement descrive le funzionalità DICOM (oggetti e classi di servizio) supportate (per una data versione di una specifica apparecchiatura) CT Storage SCU Query/Retrieve SCP Modality Worklist SCU CT Storage SCP Query/Retrieve SCU Print SCU OBJECTS = I.O.(Information Objects) ex : CT Image, MR Image, RT Plan... each Object includes a set of attributs (known as IOD=IO Definition) ex: for a CT Image object, attributs= kV, mAs, position,.. SERVICES = DIMSE (Dicom Services Message Elements) ex : send, store, query, retrieve...

HL7 -1 Health Level 7 Scopo: "To provide standards for the exchange, management and integration of data that support clinical patient care and the management, delivery and evaluation of healthcare services." Storia: v2.0 v2.3 v2.3.1 v3.0 Health Level Seven (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 ed ha accumulato una notevole esperienza nell'utilizzo quotidiano nella maggior parte degli ospedali e nelle richieste di rimborso delle prestazioni. Lo sviluppo di HL7 ormai coinvolge l'intera comunità internazionale. HL7 sta coordinando gli sforzi con altri organismi internazionali di standardizzazione (es. CEN/TC 251, DICOM, ISO/TC 215, W3C). In parallelo con queste collaborazioni formali, HL7 sta incoraggiando la formazione di sezioni nazionali ("affiliates") in tutto il mondo. Sono state attivate le sezioni in: Argentina, Australia, Brasile, Cina, Croazia, Repubblica Ceca, Danimarca, Finlandia, Germania, India, Giappone, Corea, Lituania, Nuova Zelanda, Sud Africa, Svizzera, Taiwan, Olanda, Regno Unito. Le sezioni nazionali sono circa 30, fra queste particolarmente attive sono le sezioni di Australia, Canada, UK, Germania, Olanda. Lo standard viene sviluppato con risorse offerte volontariamente da numerose organizzazioni (industrie, agenzie governative, organizzazioni che forniscono o rimborsano l'assistenza, etc). Circa 40 gruppi di lavoro (Technical Committees e Special Interest Groups) si riuniscono per una settimana tre volte l'anno, ma idee e materiali tecnici vengono elaborati con un lavoro continuo tramite e-mail, conferenze telefoniche settimanali o incontri ad hoc. Informazioni su attività, struttura organizzativa e materiali prodotti sono disponibili in www.hl7.org.

HL7 -2 Architettura message-oriented (o client-server) the application that issues the message will be called Sender or Sending Application, and the address of the message will be called Receiver or Receiving Application. Definisce formato dei messaggi scambiati (ASCII) ed eventi generanti tale scambio messagge HL7 messages are ASCII messages, (unlike protocols such as DICOM), and command that they be "human readable". Message (definition) Messages are a defined sequence of segments and/or segment groups. Each segment, group, or message set within a message can be optional and/or repeating. Each message consists of the segments that are delimited by "carriage return" characters ("\r" or 0x0D). That's why you see each segment as a different line. Segments Every line in a message is called a 'segment'. Each segment has its own semantic purpose. This means that it contains information of a specific type. For example: MSH segment contains information about the Sender and Receiver of the message, type of the message, time stamp etc. EVN contains information about type of message, for example, A04 (Register a patient). Information contained in EVN is duplicated in MSH, so starting from version 2.3 this segment is excluded from all message definitions. PID contains demographic information about the patient such as name, id codes, address, and so on. PV1 contains information regarding the patient stay in the hospital such as location assigned, referring doctor etc. Segments consist of fields that are composites. Composites are delimited by "|". Each field has its own unique purpose and is defined by HL7 standard for each segment. Composites Composites are the building blocks of segments. Composites may be either a primitive data type, (string, number etc), or in turn be made up of other composites. Composites cannot have a recursive reference to themselves. The components of each composite are separated by ^ characters, and the sub-components of these components themselves can be delimited using & characters. Sometimes this can cause problems in non-compliant systems where a & character is entered by a user into a field. This is when the HL7 escaping protocol should be used. segment field data type

IHE: definizione Integrating the Healthcare Enterprise , HIMMS+RSNA, dal 1999 Non è uno standard!!!…ma è un’iniziativa, volta alla promozione e al supporto dell’integrazione dei sistemi in ambito sanitario Obiettivo: migliorare l’efficienza e l’efficacia della pratica clinica Improve the efficiency and effectiveness of clinical practice: Improve Workflow Improve Information Accuracy Improve Information Availability Enable Cross-System Functionality

IHE e gli standard -1 “Standards, such as DICOM and HL7, do exist for exchange of image and text information among various information systems. However, these can potentially be used in an almost infinite number of ways, and this has required vendors to provide custom solutions for each individual customer facility,” said Dr. Eliot Siegel, radiology chief at the Baltimore VA Medical Center. “The solution to reach this goal of interoperability has been to get all of the vendors together in one room and essentially have them agree how they’ll use DICOM and HL7 and other standards.” gli standard (DICOM, HL7, ICD…) sono indispensabili: sono gli strumenti gli standard da soli sono però insufficienti: sono aperti ad interpretazioni lasciano spazio a modifiche opzionali non specificano come devono essere applicati a scenari reali

IHE e gli standard -2 IHE Integration profile

IHE e gli standard -2 IHE si riferisce a problematiche di integrazione nel mondo reale della Radiologia è come se: DICOM e HL7 = dizionari IHE = grammatica, che permette di “assemblare” i “vocaboli” DICOM e HL7 in maniera tale da risolvere i problemi reali

Esempio di relazione tra IHE e HL7 IHE e gli standard -3 Esempio di relazione tra IHE e HL7 HIS RIS Livello IHE Ordine di esame Il medico ordina una procedura radiologica L’ordine viene completato In Radiologia Livello HL7 Message type ORM Event General Order O01 Segments MSH | PID | PV1 | ORC | OBR Fields SEQ LEN DT NAME 4 SI Set ID 75 EI Placer Order No. 75 EI Filler Order No. etc

Executive Information System (Controlling) SDO Process Reporting HL7 intx Executive Information System (Controlling) SDO Process extr/API/rep extracts reports Aggregation Data Warehouse Clinical Administrative Cl Middleware/Intx Router ADT Pt Mgmt Rx Inv Orders OE/ Sched OE/ Fin ADT OE Sched Fin RES RES extracts Acute Care Ancillary Out-patient Integrated Admin System Financial EMR Orders Pathways Path Telepath EMR Scheduling Orders HR Pharm LAB CCU System Purchasing RIS PACS Inventory Mgmt Transplant Mgmt System

IHE e gli standard -5

Pt Mgmt Scheduling DW EMR RIS PACS ADT OE (inbound) RES (outbound) Rad Interface Events ADT Sched FIN EMR RIS Adt Orders Status results OE (inbound) PACS RES (outbound) ADT OE (inbound) RES (outbound) A01 Admit IP A02 Transfer A03 Discharge A04 Reg OP/outside opt A05 Preadmit A06 Transfer OP to IP A07 Transfer IP to OP A08 demoraphic Update A11 Cancel Admit A12 Cancel Transfer A13 Cancel Discharge A17 Swap patients A23 delete pt record A28 Add person info A29 Delete person info A31 Updt person info A34 Merge patient info A35 Merge acct info M02 Physician Maintenance M05 Location Maintenance Order message from HIS Resp to rad-initated orders Cancel Order, HIS Order status from rad Cancel Order, rad Rad-initiated order Results Acknowledgements PACS SCHED S01 New Appt S02 resched S03 Modify appt S04 Cancel appt. S05 Discontinue S06 Delete appt S07 Add services S08 Modify services S09 Cancel service S10 Discon. service S11 Delete service Note: one-way only, add. Events if 2-way needed ADT- Pt admit/reg/MRN change/ demographic updt Status- Exam sched/resched/canc/ compl/uncompl/rep dict/rep fianl Order nfo- incl in sched status RES- Prelim report/rep edits/final rep FIN Procedures

IHE e gli standard -7 HL7 Segments- From Rad to PACS Pt Registration ADT A04 Pt MRN Change ADT A18 Pt Merge ADT A18 Demog Change ADT A08 Exam Sched ORM Exam Resched ORM Exam Cancelled ORM Begin Exam ORU Complete Exam ORU Uncompl Exam ORM Rep Dictated ORU Rep Edited ORU Final Report ORU

Agenda INTEGRAZIONI tra sistemi EVOLUZIONI dei sistemi in Sanità Standards Iniziative Lavoro EVOLUZIONI dei sistemi in Sanità Delle configurazioni Delle architetture Delle procedure

Evoluzioni dei sistemi informatici in HE EVOLUZIONI dei sistemi in Sanità Delle configurazioni S. centralizzati S. localizzati S. misti Delle architetture ASP Data center Delle procedure Clinical Applications Cartella Clinica, EPR

Configurazioni L’architettura dei sistemi complessi dipende fortemente: Dalle esigenze del Cliente Dalla realtà in cui vive Dal livello tecnologico del Partner scelto Dalle risorse a disposizione

L’archivio centralizzato Definizione di un Presidio di riferimento Configurazione Archivi a Lungo termine e Server Centrali Database Altamente performante Configurazione server periferici Valutazione dettagliata reti geografiche

L’archivio distribuito Configurazione Archivi a Lungo termine e Server in ogni presidio Necessità di collegamento: telerefertazione per particolari modalità diagnostiche Database LINK

L’archivio Misto Configurazione Archivi a Lungo termine e Server in alcuni presidi Necessità di collegamento geografico efficiente e funzionale

Networking: LAN e WAN WAN Local Area Netwok World wild Area Network Componenti Attivi Componenti Passivi Servizi World wild Area Network Apparati di Rete Geografica Connettività Server Client Client Router Router WAN Switch Hospital A Hospital B

LAN Componenti Attivi: switch Componenti Passivi Servizi: Client Rame / Fibra ottica Armadi Patch Pannel Patch Cord,…. Switch Client Server Hospital Servizi: Intestazioni Dati lato presa e permutatore Certificazioni

WAN – CDN Line Schede seriali Syn/Async velocità 2 Mbit Sempre aperta Flusso dati non soggetto a tariffazione per unità di tempo. WAN ROUTER ROUTER MASTER LAN SWITCH SERVER CLIENT

WAN – ISDN Line Schede Isdn velocità 64 Kb per 2 canali. Numero di canali aggregabili è relativo al numero di schede utilizzate. Connessione soggetta a tariffazione per unità di tempo. WAN ROUTER WAN ISDN Cloud LAN SWITCH SERVER CLIENT

Architetture L’architettura dei sistemi complessi dipende fortemente: Dalle esigenze del Cliente Dalla realtà in cui vive Dal livello tecnologico del Partner scelto Dalle risorse a disposizione DALLA TIPOLOGIA DI PRESTAZIONE RICHIESTA

ASP – Definizione ?? Application Service Providing E’ una struttura per cui l’archiviazione e le procedure back-end vengono eseguite LONTANO dal luogo in cui le prestazioni sono eseguite ed usufruite.

ASP - 1 Archiviazione centralizzata in una Server Farm Solo la produzione degli esami e la loro refertazione rimangono in ospedale Vantaggi Economici HW, SW, Manutenzione Pagamento Personalizzato Di Flusso di lavoro Variazioni della configurazione Variazione del case-mix Svantaggi Indiretto controllo Costi per WAN

ASP - 2

Medical Image Archive for all Departments DATA CENTER - 1 Medical Image Archive for all Departments Sound PDF documents Video Waveforms Cath Lab Images ECG Waveforms & Reports Endoscopy Nuclear medicine Nuclear medicine Cardiology Data Center Pathology Lab Results & Reports Orthopaedics CR Internal medicine Radiology MRI/CT Post Processing Ultrasound Images & Measurements Radiology images

Foundation for archival of clinical data DATA CENTER - 2 Clinical Data Centre Foundation for archival of clinical data HIS/CIS Clinician Portal / EMR/EPR Viewer IMPAX Radiology Heartlab Cardiology Specialty Systems 21 May 2036 Registration Lab & Rx Nursing Reporting Modality publish retrieve presentation

Sistemi PACS verso la multiutenza Altri ambiti di produzione e/o elaborazione delle immagini Espandere la sfida digitale oltre le mura della radiologia: Per fornire all’intero ospedale una soluzione integrata interdipartimentale Per dotarsi (o cercare…) di un sistema centralizzato di archiviazione

In ORTOPEDIA Strumento per le misurazioni; Strumento per diagnosi; Strumento per pianificazione di interventi chirurgici Studio dell’Anca Studio del Ginocchio, Biometria Osteotomia Coxometria Template delle protesi Modulo Dror Paley Osteotomy Ottimizzazione per l’intero flusso lavorativo patient care reporting

Calibrate images to account for magnification and improve accuracy

Leg length correction improves surgical outcomes and reduces potential litigation

Studio di valori clinici

Osteotomy Planning

Osteotomy Templates

In CARDIOLOGIA 1 Strumento per uniformare differenti tipologie di informazioni Strumento per uniformare differenti tipologie di Immagini Strumento per diagnosi; Strumento per la pianificazione di interventi chirurgici Strumento per la pianificazione di cure e trattamenti Ottimizzazione per l’intero flusso lavorativo patient care reporting

In CARDIOLOGIA 2 Hemo- dynamics ECG Waveforms & Reports Cath Lab Images Online Review Hemo- dynamics History Physical Findings ECG Waveforms & Reports Consults and Notes Echo Images & Measurements Digital Integrated Cardiovascular Record!

La Cartella Clinica non esiste specifica definizione normativa (eccez. case di cura private); esistono norme per la sua gestione (compilazione, custodia..) “la cartella clinica é il diario del decorso della malattia e di altri fatti clinici rilevanti (Cass. sente. 9423 11.11.83) e di essa fanno parte, tra l’altro, gli esami obiettivi e i referti dei trattamenti diagnostici.” cartella clinica = atto pubblico che fa fede fino a querela di falso generalm. x cdc non convenzionate, è solo promemoria privato (!!! no giurisprudenza a sostegno)

Cartella clinica: normativa deve essere conservata illimitatamente (prima Caposala, poi DS) obbligo di indicazione di data e ora obbligo di sottoscrizione   deve risultare leggibile anche l’errore corretto;  per errore o omissione rilevati in epoca successiva é necessario porre un’annotazione con data e firma; la conservazione spetta al primario fino al momento del rilascio, poi al Direttore Sanitario che é responsabile della custodia; l’archiviazione deve riguardare cartelle chiuse e come tali non suscettibili di modifiche; i fatti devono essere annotati contestualmente al loro verificarsi; la cartella clinica acquista carattere di definitività in relazione ad ogni singola annotazione ed esce dalla sfera di disponibilità del suo autore nel momento stesso in cui la singola annotazione viene registrata.

Cartella clinica: normativa Codice di Deontologia Medica (art. 23): “la cartella clinica deve essere redatta chiaramente, con puntualita’ e diligenza, nel rispetto delle regole della buona pratica clinica e contenere, oltre a ogni dato obiettivo relativo alla condizione patologica e al suo corso, le attivita’ diagnostico-terapeutiche praticate.”

Cartella clinica: altre definizioni Convegno ‘La cartella clinica: una illustre sconosciuta’ – A.O. Fatebenefratelli Oftalmico Milano 2001 “la cartella clinica e’ un insieme di documenti nei quali viene registrato dai medici e dagli infermieri un complesso di informazioni (anagrafiche, sanitarie, sociali, ambientali, giuridiche) concernenti un determinato paziente allo scopo di poterne rilevare cio’ che lo riguarda in senso diagnostico-terapeutico anche in tempi successivi al fine di predisporre gli opportuni interventi medici e poterne anche usufruire per le varie indagini di natura scientifica, statistica, medico-legale e per l’insegnamento.”

Cartella clinica: altre definizioni Altre fonti (siti Ordini Provinciali/Organismi Medici; “manuale di informatica medica” di Maceratini-Ricci) “La cartella clinica è lo strumento utilizzato per la raccolta dei dati della storia clinica di un assistito, dati che vengono raccolti durante gli incontri con gli operatori sanitari, per la prevenzione o in occasione di episodi di malattia”.

Cartella clinica: obiettivi supporto alla cura del paziente informazioni per valutazioni e decisioni informazioni per condivisione con i diversi operatori supporto alla ricerca clinica, epidemiologica, analisi dei farmaci, analisi della qualità di cura supporto alla formazione dei clinici documentazione per gestione sanitaria fatturazione, rimborsi, gestione dei costi documentazione legale delle azioni mediche

Cartella clinica cartacea: limiti e svantaggi “fisicità” leggibilità assenza di dati ambiguità “passività” nel processo decisionale

Cartella clinica elettronica: i principali vantaggi immediata disponibilità delle info comunicazione facilitata maggiore interazione tra gli operatori

EPR: definizioni EMR = Electronic Medical Record = Cartella Clinica Informatizzata creata sul pc (tastiera, riconoscimento vocale…) specifica del servizio che la eroga EPR = Electronic Patient Record= CPR = Computer-Based Patient Record = Cartella Clinica Elettronica del Paziente informazioni relative ad un paziente documentate da diversi servizi in diverse strutture multidisciplinare e multistruttura ID univoco per il paziente EHR = Electronic Health Record = Fascicolo Sanitario Personale informazioni relative ad un paziente (ID univoco) anche informazioni sanitarie e sullo stato di salute da altre fonti (genitori, allenatori, terapisti…)

Organizzazioni e progetti -1 PROREC PROmotion strategy for european electronic healthcare RECords URL http://www.prorec.it/ Chi sono Scopo dei centri PROREC è la discussione sui problemi legati all'introduzione della cartella clinica elettronica e la collaborazione tra i vari tipi di attori coinvolti per aumentare la consapevolezza su tali problemi e facilitare la loro soluzione, per diffondere sistemi di elevata qualità. I centri nazionali PROREC fanno parte di una rete europea di collaborazione, nell’ambito della Misura di Accompagnamento promossa dall’Unione Europea : “WIDENET Offering World-Wide Services through an International Network on Health Products European Union, 5th Framework Program, Applications relating to health, IST-1999-1420” I membri di ogni centro nazionale collaborano tra loro e con i colleghi europei per la messa a punto di materiale tecnico, educativo e divulgativo utile agli scopi descritti.  

Organizzazioni e progetti -1 FIASO Federazione Italiana Aziende Sanitarie e Ospedaliere. URL http://www.fiaso.it/ Chi sono Insieme a Federsanità – ANCI rappresentano la quasi totalità delle Aziende Sanitarie ed Aziende Ospedaliere. La FIASO associa oggi circa 150 tra aziende sanitarie locali e ospedaliere. Progetti di interesse La FIASO ha organizzato l’attività della Federazione per Aree Tematiche. Ogni Area Tematica è affidata alla responsabilità politica e operativa di un Vice Presidente.   Area tematica relativa all’Innovazione organizzativa e tecnologica (GdL ITC e sanità)  

Domande

Grazie per l’attenzione ARRIVEDERCI a DOMANI