Fascicolo Sanitario Elettronico BIOINGEGNERIA ED INFORMATICA MEDICA

Transcript

1 Fascicolo Sanitario Elettronico BIOINGEGNERIA ED INFORMATICA MEDICA 1

2 Definizione linee guida nazionali 2011 Il Fascicolo Sanitario Elettronico è l insieme dei dati e documenti digitali di tipo sanitario e socio-sanitario generati da eventi clinici presenti e trascorsi, riguardanti l assistito. Ha un orizzonte temporale che copre l intera vita del paziente, è alimentato in maniera continuativa dai soggetti che prendono in cura l assistito nell ambito del Servizio sanitario nazionale e dei servizi sociosanitari regionali. 2

3 Ricovero ospedaliero Farmaci Specialistica ambulatoriale Prevenzione Assistenza Domiciliare Assistenza Residenziale Area socio-sanitaria Finalità del FSE FSE è finalizzato a raccogliere e trasmettere informazioni socio-sanitarie e dati clinici del cittadino, in modo da garantire la continuità di cura attraverso i diversi servizi assistenziali Utilizzo del FSE da parte del Medico RICOVERO OSPEDALIERO Accesso al referto di un cardiologo per un paziente che sta visitando; SPECIALISTICA AMBULATORIALE PRESTAZIONI FSE Controllo dell andamento del diabete per un paziente che ha fornito elettronicamente i dati sanguigni del glucosio; FARMACEUTICHE ASSISTENZA RESIDENZIALE Prescrizione farmaceutica elettronica per un proprio assistito, integrata con informazioni sull erogazione da parte del farmacista. ASSISTENZA DOMICILIARE ACCESSI AL PS. Per la sua realizzazione è tuttavia necessaria una infrastruttura che assicuri l integrazione tra i diversi sistemi di generazione degli eventi sanitari e ne garantisca l accesso sicuro in rete agli operatori autorizzati e al cittadino, nel pieno rispetto della normativa vigente in materia di privacy 3

4 Contenuti del FSE Dati Identificativi dell anagrafica dell assistito: il fulcro intorno al quale ruotano tutti i processi legati all assistenza sanitaria. La correttezza e l aggiornamento dei dati anagrafici e assistenziali relativi ai cittadini per i quali sono erogate prestazioni sanitarie è un prerequisito alla costituzione e alla gestione del Fascicolo Sanitario Elettronico. I dati anagrafici non fanno parte del FSE ma sono gestiti in archivi separati alimentati dalle anagrafi degli assistiti. Tra i dati anagrafici è fondamentale il Codice Fiscale che rappresenta la chiave univoca di identificazione del cittadino e viene attribuito esclusivamente dall Agenzia delle Entrate, che, in caso di necessità, provvede a risolvere i casi di omocodia. 4

5 Dati Identificativi 5

6 Dati amministrativi relativi all assistenza 6

7 Documenti sanitari e socio-sanitari (1) FSE viene automaticamente aggiornato, tenendo conto anche dei contenuti informativi già disponibili, con i documenti sanitari e socio-sanitari certificati, cioè rilasciati dai soggetti del Servizio Sanitario Nazionale (ad es. referti di laboratorio, radiologia e specialistica ambulatoriale) archiviati elettronicamente presso repository dedicati. FSE è costituito da: 1. Un nucleo minimo di documenti indispensabili disponibili a livello regionale 2. Altri documenti dipendono grado di informatizzazione della regione di riferimento 7

8 Documenti sanitari e socio-sanitari (2) 8

9 Profilo Sanitario Sintetico (1) Profilo Sanitario Sintetico (Patient Summary) è il documento informatico sanitario che riassume la storia clinica del paziente e la sua situazione corrente. Creato ed aggiornato dal MMG/PLS ogni qualvolta intervengono cambiamenti da lui ritenuti rilevanti ai fini della storia clinica del paziente e contiene un set predefinito di dati clinici significativi utili in caso di emergenza Caratteristiche 1. Sintetico (informazioni essenziali) 2. Unico autore (creato dal MMG/PLS, non dedotto da FSE) 3. Non clinicamente specializzato (serve per la continuità di cura) 4. Non ha un destinatario predefinito 5. Unico (all interno FSE non per paziente) 9

10 Profilo sanitario sintetico (2) Intestazione Dati del paziente Cognome, nome, codice fiscale, sesso, età in anni, data di nascita, comune di nascita, indirizzo di domicilio, telefono (sono importanti eventuali esenzioni e l appartenenza ad una rete di patologia) Dati del medico Cognome, nome, codice fiscale, indirizzo e- mail, telefono Eventuali nominativi Persona da contattare (nel caso in cui il da contattare paziente sia minore, o nelcaso in cui non sia in grado di intendere o volere) 10

11 Profilo sanitario sintetico (3) Dati essenziali (se valorizzati in cartella) Allergie, reazioni avverse ai farmaci o ai Sostanza scatenante, tipo di reazione. L assenza di allergie o di reazioni allergiche mezzi di contrasto o ad altre sostanze, conosciute va dichiarata così come se non rilevate perché non a conoscenza. intolleranze, rischi immunitari Problemi di salute rilevanti e diagnosi Terapie in corso Stato del paziente Trattamenti e procedure terapeutiche, chirurgiche e diagnostiche Fattori di rischio Attuale situazione clinica (patologie croniche e/o rilevanti) del paziente: sintomi, attuali e passati, del paziente; condizioni, sospetti diagnostici e diagnosi certe, screening oncologici; lista malattie pregresse se rilevanti, dipendenze, etc. Farmaci somministrati in maniera continuativa oltre a quelli riferitialle prescrizioni effettuate nell ultimo mese integrate eventualmenteda altre riconosciute come rilevanti dal medico Indicazioni socio-assistenziali utili, in particolare, in fase di dimissione del paziente dalla struttura al fine di attivare adeguati percorsi assistenziali necessari (ad es. capacità motoria, stato mentale, autosufficienza Interventi chirurgici rilevanti ed eventuali riferimenti a referti di laboratorio, di radiologia, di visite specialistiche, etc., inclusa l eventuale partecipazione a trials clinici; riportare i risultati di accertamenti registrati nell ultimo anno con l aggiunta delle informazioni ritenute rilevanti dal MMG/PLS. rischio eredo-familiare, Dipendenze, esposizione a sostanze tossiche,etc. Vaccinazioni Organi mancanti/trapianti/espianti Protesi, impianti, ausili Somministrazioni di cui è a conoscenza il MMG/PLS (tipo di vaccino, data e modalità di somministrazione). Se portatore di dispositivi permanenti e impiantabili 11

12 Profilo sanitario sintetico (4) Altre informazioni sul paziente Parametri di monitoraggio Piano di cura attivo Gruppo sanguigno Altre patologie di recente insorgenza Gravidanza e parto Assenso/dissenso alla donazione d organi Ultima rilevazione di pressione arteriosa, peso, altezza, funzionalitàpolmonari L insieme delle informazioni su prescrizioni di prestazioni, interventi, appuntamenti, procedure attive e non terminate Contiene la dichiarazione del donatore prevista dall art.23 comma 3L.91/99 se dichiarata al MMG/PLS 12

13 Requisiti di liceità per il trattamento dei dati personali contenuti nel FSE Verso il cittadino: Informativa Deve essere evidenziata l intenzione di costituire un FSE che documenti la storia sanitaria dell assistito ai fini del miglioramento del processo di cura (mediante la raccolta di una maggiore quantità di informazioni possibili), chiarendo che i dati che confluiscono nel fascicolo sono relativi al suo stato di salute pregresso e/o attuale. Consenso informato al trattamento dei dati La creazione del FSE ha in se l elaborazione del dato del singolo paziente. Necessaria forma esplicita di consenso al trattamento dei dati. 13

14 Soluzione architetturale idonea La soluzione architetturale, quindi, deve essere tale da garantire che l accesso alle informazioni del FSE sia consentito solo se si verificano le seguenti condizioni: l assistito ha espresso esplicito consenso alla costituzione del proprio FSE; le informazioni da trattare sono indispensabili per la specifica cura dell assistito; le informazioni da far confluire nel FSE non siano state oggetto di oscuramento da parte dell assistito; l assistito ha espresso esplicito consenso all accesso alle informazioni autorizzate; l assistito ha indicato le categorie di operatori sanitari abilitati alla consultazione delle informazioni autorizzate, fermo restando che il personale sanitario abilitato, coinvolto nella cura di un paziente, può consultare solo i dati clinici dell assistito correlati con la patologia in cura. 14

15 Definizione di ruoli, profili, e modalità di accesso (1) Considerata la differente natura delle informazioni, appare necessario determinare il livello di visibilità più appropriato per ciascuna categoria sanitaria. Ricorso a un sistema di gestione dei privilegi di natura modulare che, basandosi su una preventiva classificazione dei dati, attribuisca diritti di accesso ed autorizzazioni limitate soltanto ad un sottoinsieme di essi. Ricorso a politiche di accesso per consentire a un utente di identificarsi e autenticarsi, mediante meccanismi di autenticazione debole e/o forte. Al fine di garantire la tracciabilità delle operazioni svolte sul sistema e di chi le ha eseguite in modo da abilitare funzionalità di auditing e di certificazione sulle attività svolte per le diverse finalità previste, dovranno essere registrate tutte le operazioni, sia quelle andate a buon fine che quelle annullate. 15

16 Definizione di ruoli, profili, e modalità di accesso (2) Fonti abilitate ad alimentare i dati del FSE: Strutture accreditate per la diagnosi e cura del cittadino in cui operano i professionisti della Sanità Soggetti destinatari e relativi profili di accesso: Vengono definite le macro categorie per definire i profili di accesso dati Anagrafici riguardano le informazioni personali identificative del cittadino; dati Amministrativi riguardano le esenzioni e il medico di base; dati Prescrittivi riguardano le prescrizioni; dati Clinici- riguardano tutti i documenti clinici; dati di Consenso riguarda la possibilità di trattare i dati all interno del FSE. 16

17 Definizione di ruoli, profili, e modalità di accesso (3) RUOLO FUNZIONI TIPOLOGIE DI DATI. Medico di Medicina Generale/Pediatra di Libera Scelta Medico convenzionato con la ASL per svolgere attività di MMG/PLS. 17 Lettura Scrittura Anagrafici Amministrativi Prescrizioni Clinici Consenso Prescrizioni Clinici (solo se previsti come tipi di documento) Consenso Nella definizione dei soggetti abilitati si dovrà tenere conto di quanto specificato dalle Linee guida in tema di fascicolo sanitario elettronico (FSE) e dossier sanitario dell Autorità Garante per la protezione dei dati personali del 16 luglio 2009 in tema di individuazione dei soggetti che possono trattare i dati (punto 4 del citato Provvedimento del Garante) e accesso ai dati personali contenuti nel Fascicolo sanitario elettronico e nel dossier sanitario (punto 5 del citato Provvedimento del Garante).

18 Valore legale del fascicolo Il decreto legislativo del 7 marzo 2005, n. 82 recante Codice dell'amministrazione digitale (CAD), come modificato dal decreto legislativo 30 dicembre 2010, n. 235, definisce il documento informatico come la rappresentazione informatica di atti, fatti o dati giuridicamente rilevanti (art. 1, comma 1, lettera p). Tale decreto presuppone la Firma Digitale Elettronica e la marcatura temporale. FSE non assume valore legale qualora ogni singolo componete non è stato firmato elettronicamente (Firma elettronica) 18

19 La sicurezza dei SI sanitari: normative di riferimento I componente del FSE devono comunque far riferimento all allegato B (art. da 33 a 36 D.Lgs 196/2003) (Disciplinare Tecnico in materia di misure minime di sicurezza) che prende in considerazione un sottoinsieme dello standard «ISO/IEC 17799:2005, Information Technology Security Techniques» sulle tecniche di sicurezza dei sistemi informativi Tale sottoinsieme tratta: Autenticazione, codici identificativi e password Profili di autorizzazione Disposizioni varie Adozione di sistemi di cifratura Backup Interventi formativi. Le ISO/IEC 17799:2005 sono state aggiornate nello standard ISO/IES (Information security management systems) 19

20 Standard di interoperabilità BIOINGEGNERIA ED INFORMATICA MEDICA 20

21 Interoperabilità I modelli architetturali attualmente maggiormente diffusi non scambiano informazioni tra di loro. Per poter far parlare tra loro i SI sanitari è possibile aggiungere uno strato software di intermezzo (detto middleware ) che deve assicurare l interoperabilità. Interoperabilità: possibilità di scambiare informazioni e utilizzare procedure mediante stazioni di lavoro con caratteristiche hardware e software diverse

22 Interoperabilità - problemi attuali Fino ad oggi la difficoltà di pervenire ad una condivisione di informazione clinica attraverso basi di dati eterogenee è stata grande, a causa della diversità di piattaforme software, di struttura dei database e di connessione fra i vari luoghi di deposito dei dati. Molti software proprietari Non uniformità dei dati raccolti Difficoltà nello scambiare i dati con altri centri Tuttavia... è pressoché impossibile pensare a sistemi informativi completamente integrati

23 Approcci al problema Gli approcci a questo problema sono sostanzialmente due: 1. Primo approccio tende a perseguire la codifica e la traduzione dei documenti clinici in un vocabolario controllato. Difficoltà di ottenere una codifica realmente universale enorme, ed il sistema di codifica decurta il documento clinico della ricchezza informativa del linguaggio naturale. Inoltre sono sempre necessarie soluzioni locali di condivisione fra piattaforme e software differenti 2. L'altro approccio è quello cosiddetto documentcentered, che renda il documento indipendente da software e da piattaforma e consenta uno scambio di informazione completo, semplice ed immediato. 23

24 Record medico universale L utilizzo di Internet con HTML non è sufficiente perchè HTML è incentrato sulla presentazione dei dati e non sul loro contenuto Non è possibile fare drag&drop delle informazioni sul proprio database La soluzione è data da XML (XML - extensible Markup Language) e dalla standardizzazione del formato di scambio Ogni ambiente medico può creare il proprio vocabolario attraverso un set DTD (Document Type Definition) Viene specificata struttura e formato di ciascun tipo di dato Il contenuto del database è automaticamente convertito in un documento XML valido

25 Record medico universale Sarà possibile recuperare i documenti attraverso browser standard e motori di ricerca per recuperare i record Un browser Internet può essere interrogato da molti utenti contemporaneamente I dottori possono i rivedere i dati dall ospedale, da casa, in viaggio Possono essere generati automaticamente reports e lettere di dimissione

26 UN ESEMPIO Un agenzia di home care necessita di tutti i dati clinici del paziente Il materiale va prelevato dai vari presidi in cui si è recato Non è possibile pensare di trovare software standard o di standardizzare hw/sw nel futuro L unica soluzione è attualmente accedere ai presidi via browser, stampare la documentazione del paziente e ricopiarla sul proprio DB La soluzione ideale è invece raggiugere il sito dell ospedale, farsi autorizzare l accesso, accedere alla sua documentazione, fare drag&drop sul proprio database. Appena rilasciata la prima versione stabile di XML l organizzazione delle aziende di homecare ha sviluppato lo Health Care Markup Language

27 ALTRI ESEMPI Il Royal Brompton Hospital (UK) ha sviluppato un sistema XML che produce lettere di dimissione automatiche, report di broncoscopia, links ai dati dei pazienti a scopo di ricerca Le informazioni sono inserite come testo libero Esiste possibilità di ricerca con criteri complessi Non è mai necessario inserire i dati due volte E semplice generare reports con formato flessibile Il sistema alimenta continuamente un EPR generale Il sistema è stato sviluppato in 8 settimane e I vecchi records sono stati convertiti in XML al 98%

28 ALTRI ESEMPI Lo Hunt Orthopaedic Hospital (UK) utilizza XML per migliorare la qualità dell assistenza Opera un attenta analisi dell EPR secondo un dettagliato markup E possibile trovare l occorrenza delle operazioni in cui è stata utilizzata una speciale procedura o calcolare l incidenza di farmaci costosi Basta cercare la parola chiave accanto al tag desiderato

29 HL7 Patient Record Architecture E stato creato un insieme di specifiche per documenti clinici fino all approvazione dello Health Level 7 (HL7) come standard ANSI nel 1997 HL7 è iniziato come movimento bottom-up da parte dei medici ed è divenuto standard di fatto. Il documento HL7 è l unità base dei un EPR orientato al documento. Ogni tipo di record è derivabile dai documenti base per estrazione, copia, link

30 HL7 Patient Record Architecture Lo HL7 PRA (Patient Record Architecture) definisce la semantica e i vincoli strutturali L architettura è indipendente dalla piattaforma e da software proprietario L architettura è specificata in XML Ogni documento HL7 consiste in uno header e un body. Lo header fornisce metadati che identificano e classificano il documento Il body supporta la visualizzazione dei dati

31 HL7 Patient Record Architecture L architettura è scalabile e multilivello per consentire la granularità dei livelli di markup Consiste di 3 livelli che vanno di pari passo con la profondità dell informazione clinica: LIVELLO 1 (Coded Header) Specifica il markup della struttura del documento in modo che ogni documento sia visualizzabile secondo un foglio di stile comune

32 HL7 Patient Record Architecture LIVELLO 2 (Coded Structure) E possibile condividere anche la semantica dei documenti, identificando sezioni e sottosezioni con titolo codificato (es. Anamnesi con sottosezione Storia della patologia attuale) Il livello 2 specifica i markup per queste sottostrutture E possibile compilare ed emettere schede di dimissione (anche create per dettatura) Il livello 2 deve avere la sua DTD che specifichi le sottosezioni LIVELLO 3 (Coded Content): Articolazione semantica completa Il ricevente può utilizzare su questo livello qualsiasi strumento di analisi pur di conoscerne I markup

33 HL7 Patient Record Architecture HL7 definisce anche eventi Trigger cioè eventi che scatenano un flusso di informazioni all'interno della struttura sanitaria (ad es. la accettazione di un paziente implica l'aggiornamento della anagrafica pazienti ma anche del sistema di gestione dei posti letto). A tali eventi corrispondono pertanto dei messaggi che i vari sottosistemi informativi si scambiano per tenersi aggiornati l'uno con l'altro (ad es. il sistema di prenotazione esami e quello amministrativo devono essere sempre sincronizzati tra loro per consentire di calcolare efficientemente il DRG all'atto della dimissione). Molte case di software sanitario stanno incorporando il PRA nei loro sistemi di sviluppo

34 HL7 Patient Record Architecture The Open HealthCare Group fornisce un sistema chiamato X- Chart che utilizza un codice sorgente open. Il codice OHG risulta effettivamente trasferibile da/verso ogni centro di cura Ogni istituzione è incoraggiato ad usarlo e modificarlo Scopo del gruppo è creare una comunità che intenda migliorare l assistenza medica grazie al miglior uso dell informazione Sono presenti nel sito vari tipi di record chirurgici e codice DTD, XML e XSL. La National Library of Medicine incoraggia a mandare citazioni ed abstracts da inserire in Medline in formato XML già con opportuni tag, per assicurare un inserimento utile dei riferimenti bibliografici da parte degli utenti remoti

35 RIS standard DICOM RIS (Sistema Informativo di Radiologia) fornisce supporto alla attività di prenotazione esami, refertazione, archiviazione e interrogazione della base dati delle immagini radiologiche. Lo scambio di immagini avviene grazie allo standard DICOM (Digital Imaging and Communication in Medicine), Inizialmente la pluralità di produttori di hardware in campo medico ha ostacolato la standardizzazione La NEMA, organismo che rappresenta i costruttori Americani, ha promosso la definizione di DICOM. 35

36 DICOM DICOM può essere considerato una evoluzione del PACS (Picture Archiving and Communications System), in quanto prevede l'interconnessione sia meccanica che elettrica delle apparecchiature con costi e difficoltà minori ed una manutenzione semplificata. Consente sia l'utilizzo di un unico sistema di documentazione (stampante laser) e di memorizzazione, sia il collegamento diretto bidirezionale ai sistemi informativi di reparto (RIS) ed ospedaleri (HIS), oltre che la comunicazione all'esterno con altri ospedali o con Internet. 36

37 DICOM 37