Margherita-4: sviluppo e diffusione di una cartella clinica elettronica condivisa per la Rianimazione

Transcript

1 Ricerca Finalizzata 2006 Margherita-4: sviluppo e diffusione di una cartella clinica elettronica condivisa per la Rianimazione rapporto sullo stato di avanzamento del progetto al 3/12/2008 preparato da: Mario Tavola 1, Abramo Anghileri 2 e Guido Bertolini 2 1 U.O. Anestesia e Rianimazione 1 - Ospedale A. Manzoni, Lecco 2 Laboratorio di Epidemiologia Clinica - Centro di Coordinamento GiViTI Istituto di Ricerche Farmacologiche Mario Negri Ranica, Bergamo Centro di Coordinamento GiViTI - Laboratorio di Epidemiologia Clinica Centro di Ricerca per le Malattie Rare Aldo e Cele Daccò Villa Camozzi Ranica (Bergamo) tel ; fax: ; giviti@marionegri.it;

2 Introduzione Obiettivo generale della ricerca è quello di completare lo sviluppo della cartella clinica informatizzata e di realizzare le condizioni affinché si raggiunga la più ampia diffusione possibile fra le Terapie Intensive Italiane. In particolare i principali obiettivi specifici del progetto consistono in: 1. Perfezionare i contenuti medico-infermieristici della cartella, a partire da quanto emerso nella fase di sviluppo e di validazione dello strumento Unità operative 1 e Perfezionare il modulo della segnalazione dei donatori d organo in modo che risulti automaticamente compilato dalla cartella clinica Unità operativa Progettare e sviluppare un modulo di acquisizione dati dalle apparecchiature di reparto (monitor, ventilatori, pompe infusionali) Unità operativa Progettare un modulo di interfaccia con i servizi dell ospedale (Servizi informativi ospedalieri comprendenti l anagrafica regionale, la farmacia, il laboratorio, la diagnostica per immagini, i reparti di degenza, la trasmissione della lettera di dimissioni ai medici di medicina generale) Unità operativa Organizzare un servizio di assistenza tecnica che garantisca interventi tempestivi ed efficaci ad un numero elevato di reparti Unità operativa Progettare e realizzare un sistema di restituzione dei dati ai centri che valorizzi al massimo la logica di promozione della qualità dell assistenza attraverso il confronto dei processi di cura e degli esiti ottenuti Unità operativa 6. Di seguito si presenta il documento metodologico-operativo sulle caratteristiche della nuova versione della cartella clinica elettronica Margherita-4 per i reparti di terapia intensiva, attualmente installata in 10 rianimazioni italiane. Anagrafica del paziente Attualmente viene effettuato l inserimento manuale dei dati anagrafici e sanitari del paziente. E in fase di elaborazione e successivamente di test l acquisizione dell anagrafica stessa dall interfaccia con i sistemi informativi ospedalieri e regionali (si veda l apposita sezione di questo rapporto per i dettagli).

3 Accettazione del paziente in reparto Si inseriscono le informazioni relative al ricovero del paziente: data, ora di ricovero; provenienza del paziente, esplicitando se proveniente dallo stesso ospedale o da altro ospedale, reparto di degenza ordinaria o reparto di accettazione/emergenza; diagnosi clinica relativa ai motivi di ricovero e alle insufficienze d organo presenti, secondo classificazioni validate, con la possibilità di un esplicitazione delle patologie secondo la codifica ICD9-CM; notizie anamnestiche del paziente. In particolare il programma consente e in qualche modo facilità la raccolta di tutte le informazioni inerenti le patologie croniche del paziente, i motivi che hanno portato al ricovero in rianimazione, le terapie in atto prima del ricovero. In questo ambito vengono raccolte anche le reazioni allergiche del paziente, in particolare quelle legate a farmaci. L attuale versione del programma consente di avere costantemente in linea le informazioni sulle allergie su tutti i moduli di cartella, in particolare quelli che riguardano la prescrizione e la somministrazione della terapia. Un apposito indicatore mantiene l attenzione dell operatore, medico e infermiere, sulle sostanze e sui principi attivi potenzialmente rischiosi per il paziente qualora venissero somministrati. Inoltre, qualora i medico prescriva o l infermiere somministri un principio attivo o un prodotto farmaceutico a cui il paziente risulta allergico vengono attivati opportuni messaggi e richieste di conferma, sia della prescrizione che della somministrazione, di tali prodotti, sottolineando ulteriormente il potenziale rischio per il paziente stesso. Il sistema è ora interconnesso con il prontuario terapeutico nazionale. Diario clinico giornaliero Sviluppato ed articolato per tutte le informazioni inerenti il decorso clinico del paziente relativamente alle problematiche sia mediche sia assistenziali e infermieristiche. Il diario è strutturato in due parti. La prima è codificata e suddivisa per organi ed apparati. In tal modo si ottiene una codifica comune a tutti gli utilizzatori della cartella clinica, che consente il confronto fra reparti, le analisi epidemiologiche e di processo clinico. La seconda parte consente l inserimento di testo libero, al fine di meglio chiarire l andamento del paziente, effettuare epicrisi sulla situazione clinica e sviluppare un programma diagnostico-terapeutico.

4 Procedure diagnostiche e terapeutiche Nell attuale versione sono state inserite, in un apposito modulo, tutte le procedure diagnostico-terapeutiche ed interventi chirurgici con relative codifiche strutturate secondo ICD9-CM così da consentire la classificazione delle stesse in tempo reale durante la degenza del paziente. Per ogni procedure segnalata è prevista l introduzione della data e ora di esecuzione e vi è la possibilità di specificare, mediante testo libero, eventuali dettagli ritenuti utili per la documentazione sanitaria. Di seguito si riporta a titolo esemplificativo la schermata per l inserimento di una nuova procedura chirurgica. Figura 1 Inserimento nuova procedura chirurgica

5 Presidi e manovre assistenziali effettuate sul paziente Si tratta di un altro nuovo modulo che consente di descrivere tutti i principali presidi medicochirurgici utilizzati sul paziente, le principali manovre assistenziali e di porle in relazione con l andamento clinico del paziente stesso. Figura 2 Modulo dei presidi assistenziali Registrazione dei parametri vitali con inserimento manuale e acquisizione dati dalle apparecchiature elettromedicali È stata completamente ridisegnata l interfaccia utente della parte inerente la raccolta dei parametri vitali del paziente, per quanto riguarda l inserimento manuale degli stessi.

6 Sono state inoltre sviluppate le procedure di acquisizione automatica dei parametri direttamente dalle apparecchiature elettromedicali secondo standard HL7 senza vincoli a specifiche tipologie di apparecchiature. In particolare si stanno già testando le acquisizioni da apparecchiature Drager-Siemens e Philips. In particolare, tutti i parametri relativi a misurazioni del sistema cardiocircolatorio (rilevati sia in modo invasivo che non invasivo), respiratorio, alle procedure di ventilazione artificiale meccanica, i parametri di temperatura corporea, i parametri relativi alla funzione cerebrale, vengono inviati ogni 2 minuti dalle relative centrali di monitoraggio (di cui sono dotati tutti i reparti) al server dove è installato il programma Margherita. Il passaggio finale di acquisizione nella cartella clinica dei parametri così campionati viene effettuato sempre dal medico o dall infermiere, a garanzia di acquisizione di parametri non alterati dalla presenza di artefatti. Figura 3 Nuovo foglio dei parametri vitali

7 Terapia E stata ulteriormente sviluppato il modulo della terapia, in tutte le sue parti di prescrizione, somministrazione, calcolo degli apporti nutrizionali, calcolo degli apporti idrici e di sali minerali. Il sistema guida alla prescrizione per principio attivo, ma consente di effettuare anche prescrizioni per prodotti commerciali nonché la prescrizione di farmaci extraprontuario. Nel caso di prescrizione per principio attivo, nella fase di somministrazione si possono visionare tutti i prodotti commerciali corrispondenti al principio attivo. Ciò al fine di minimizzare i possibili errori sia in prescrizione che in somministrazione. A seconda della via di somministrazione impiegata, cambia l interfaccia utente, in modo da mantenere a video solo le informazioni essenziali all attività che si sta svolgendo e ridurre così la possibilità di errori da ridondanza. E stata infine aggiunta la possibilità di configurare in modo personalizzato le principali e più comuni diluizioni di farmaci utilizzati in ogni singolo reparto. Tutte le parti inerenti l idratazione e la nutrizione del paziente prevedono il confronto in tempo reale tra i fabbisogni e gli apporti prescritti al paziente, ciò al fine di ottimizzare la terapia nutrizionale artificiale e ridurre le imprecisioni. Già descritta precedentemente tutta la parte di software che prevede il controllo e gli avvisi automatici relativamente alle allergie del paziente e la prescrizione e la somministrazione della terapia. Dimissione / trasferimento paziente Si stanno predisponendo i protocolli informatici perchè, oltre alla classica lettera di dimissione o di trasferimento cartacea già in uso, vi sia la possibilità, attraverso la rete informatica ospedaliera (ove esistente), di inoltrare i dati clinici rilevanti del paziente al reparto di trasferimento oppure al medico di medicina generale nel caso di dimissione del paziente stesso presso altra struttura o a domicilio Stampe Di tutte le parti di cartella clinica sopra descritte sono previste le stampe su carta. Ogni singolo reparto può organizzare e personalizzare sia le modalità che le tempistiche di stampa. Tutta la documentazione così prodotta, oltre agli indiscutibili vantaggi in termini di leggibilità, consente di risalire in modo chiaro a trasparente a tutte le diverse fasi del ricovero del

8 paziente in rianimazione sia per le componenti cliniche che per quelle organizzative e gestionali. Inoltre su tutte le parti di cartella compaiono in modo assolutamente chiaro le identificazioni dei singoli operatori correlate a tutti i passaggi di cui ciascun operatore risulta direttamente responsabile. Compilazione a posteriori Lo strumento informatico non deve costringere gli operatori ad operare sul paziente con la preoccupazione di dover documentare simultaneamente tutto quanto fatto e rilevato. Lo strumento è stato per questo realizzato in modo tale da poter inserire dati, rilevazioni e decisioni anche in un tempo successivo al loro effettivo svolgimento, con la possibilità di riferirle al tempo di reale rilevazione o effettuazione delle procedure. Tutto ciò corrisponde esattamente a quanto succede quotidianamente nella pratica clinica. Il software registra, tiene traccia e puntualmente riporta sia a monitor che sui moduli di stampa tutti questi passaggi rendendo molto più esplicita e trasparente la documentazione presente nella cartella clinica del paziente. Estrazione dati Tutti i moduli sopra descritti, attualmente installati e in uso della cartella informatizzata, sono stati realizzati sotto forma di database al fine di garantire raccolte dati a scopi sia epidemiologici che organizzativo-gestionali. In particolare possono essere fatte correlazioni in merito all andamento clinico del paziente e le decisioni diagnostico-terapeutiche intraprese sul paziente. Si stanno a questo proposito sviluppato gli strumenti di estrazione e di analisi dei dati inseriti. Dalla parte codificata delle procedure chirurgiche e diagnostiche, oltre alle correlazioni precedentemente descritte, sarà possibile effettuare un analisi dettagliata di quantità, qualità e coerenza delle procedure effettuate sul paziente stesso, con inferenze e confronti anche in termini di costi. Dai moduli relativi alla terapia si potranno ricostruire ed analizzare per singoli trattamenti o per gruppi di farmaci informazioni relative all appropriatezza in termini di scelte terapeutiche, durata delle terapie e modalità di somministrazione. Si pensi, a titolo di esempio, a possibili approfondimenti e confronti in alcuni settori di rilievo dei trattamenti in rianimazione quali quelli della terapia antibiotica, della sedazione/analgesia, della nutrizione artificiale, del buon uso del sangue e degli altri emocomponenti, dei principali farmaci vasoattivi ecc. Dalla parte inerente i presidi e le procedure assistenziali effettuate sul paziente potranno essere raccolte informazioni di rilievo in merito ai carichi di lavoro e l intensità di assistenza correlata alla gravità della condizione clinica del paziente stesso.

9 Da questi esempi si evince come tale strumento così strutturato ed articolato, non sia solamente uno strumento clinico relativo alla documentazione sanitaria di cartella clinica, ma consenta di mettere in relazione la clinica in senso stretto con altre problematiche relative all attività dei reparti di rianimazione. In particolare con le problematiche organizzative, strutturali e gestionali dei reparti stessi. Raccogliere informazioni su questi aspetti e soprattutto poter fare un confronto dei dati rilevati consente approfondimenti uniformi, chiari e trasparenti non solo nel merito dell appropriatezza clinica del trattamento dei pazienti ma anche dell appropriatezza dell uso delle risorse a disposizione dei singoli reparti. Interfacciamento con i sistemi informativi ospedalieri Architettura di integrazione La Figura 4 descrive l architettura di integrazione della cartella clinica Margherita all interno del sistema informativo dell Ospedale Manzoni di Lecco, ospedale pilota per quanto riguarda la sperimentazione. Lo scenario descritto in Figura 4 è stato pensato in modo da conciliare le due esigenze di: a) rendere operativa l integrazione nel sito pilota del progetto (Ospedale Manzoni di Lecco); b) mantenere l interfaccia da e verso la cartella clinica Margherita il più possibile slegata e indipendente dal particolare contesto. Figura 4 - Architettura di integrazione della cartella clinica "Margherita" nel S.I.O.

10 La cartella clinica Margherita si interfaccia con il sistema informativo ospedaliero attraverso un componente Gateway HL7, che dal lato cartella si integra direttamente con gli archivi della cartella clinica, mentre verso il sistema informativo ospedaliero colloquia attraverso messaggi standard HL7. L Azienda Ospedaliera Ospedale di Lecco dispone della piattaforma regionale di integrazione, per cui i messaggi provenienti dalla BAC transitano attraverso il middleware di integrazione JCAPS, e da questo vengono recapitati alla cartella clinica attraverso il componente Gateway HL7. I messaggi previsti per l integrazione sono riassunti nella tabella seguente: La struttura dei messaggi HL7 utilizzati nell integrazione sarà al 100% compatibile con le specifiche della Regione Lombardia, e contenute nel documento: AS-PS_R-SEHL7#01-v06 (20/10/2008), disponibile sul sito sezione documentazione SISS, al paragrafo Scenari e Linee Guida per le integrazioni interne.

11 Messaggi di classe ANAG (anagrafica) Sulla BAC risiedono i dati anagrafici dei cittadini che hanno avuto un contatto con l Azienda Ospedaliera. La BAC è alimentata dal Front-Office aziendale, ed è integrata con l Anagrafe Regionale tramite i servizi SISS di identificazione del cittadino; pertanto costituisce il riferimento anagrafico aziendale per quanto riguarda i dati anagrafici dei pazienti. Quando la BAC riceve una variazione anagrafica certificata (in funzione delle policy aziendali), la BAC invia a tutti i sistemi interessati una notifica attraverso i messaggi HL7 descritti in tabella. Nello scenario descritto, le notifiche sono relative a: inserimento di un nuovo paziente in anagrafe, la BAC invia un messaggio ADT^A28; modifica di un anagrafica esistente, la BAC invia un messaggio ADT^A31; unificazione di due anagrafiche (i dati anagrafici del paziente B vanno sostituiti con i dati anagrafici del paziente A, a seguito della notifica ogni riferimento a B viene sostituito da A ), la BAC invia un messaggio ADT^A40. Messaggi di classe ADT (admission/dimission/transfer) L architettura di integrazione di Figura 4 evidenzia il fatto che, fatta eccezione per il messaggio ADT^A01 uscente (ricovero diretto), la cartella clinica Margherita è passiva per quanto riguarda i messaggi di trasferimento e di dimissione. Alla base di questa scelta ci sono due considerazioni: la prima è che di norma si vuole concentrare nell ADT aziendale le funzioni prettamente amministrative, con la sola esclusione della Lettera di Dimissione; la seconda è che l architettura del progetto SISS della Regione Lombardia prevede la notifica certificata (con smartcard operatore) di ogni movimentazione di ricovero, trasferimento e dimissione: se questa attività venisse concentrata sui reparti, avremmo una moltiplicazione poco controllabile delle integrazioni al SISS all interno dell Azienda. Fatta questa dovuta precisazione, il messaggio di notifica di un nuovo ricovero ADT^A01, ed il relativo messaggio di annullamento ADT^A11 possono essere inviati indifferentemente dal sistema ADT di gestione ricoveri, oppure dal Pronto Soccorso nel caso di ricovero in urgenza. Nel messaggio di ricovero ovviamente è obbligatorio specificare il numero di ricovero, che nello scenario descritto si ipotizza ottenuto tramite un integrazione diretta fra il Pronto Soccorso ed il sistema di gestione dei Ricoveri. Il solo messaggio ADT^A01 può essere originato anche dalla cartella clinica Margherita per gestire il caso di ricovero diretto in reparto. Il messaggio di trasferimento ADT^A02 e relativo annullamento ADT^A12 possono essere originati solamente dal sistema di gestione dei ricoveri.

12 Trattamento dei messaggi di notifica nella cartella clinica Margherita Al fine di evitare interferenze con le attività operative della cartella, i messaggi di classe ADT opereranno su una coppia di tabelle di transito (tracciato da concordare), denominate a titolo esemplificativo: QUEUE_IN e QUEUE_OUT ( coda di ingresso, coda di uscita ). L utilizzo di tali tabelle è descritto nel seguito, in relazione al trattamento dei singoli messaggi. Messaggio ADT^A28 Il messaggio di inserimento di una nuova anagrafica paziente non dovrebbe essere gestito in modo incondizionato perché i nuovi pazienti che hanno un qualche contatto con l Azienda hanno poche probabilità di transitare dal reparto di rianimazione, e d altra parte inserire tutti i pazienti nell anagrafe pazienti locale della cartella clinica porterebbe ad una crescita incontrollata della stessa. Perciò si propone di realizzare una delle seguenti due strategie (comportamento definito da un parametro): sulla ricezione del messaggio ADT^A28, registrare l evento su log e scartare il messaggio sulla ricezione del messaggio ADT^A28, verificare se il paziente già esiste in anagrafe (per la strategia di verifica dell esistenza, si veda il messaggio ADT^A31); se esiste, aggiornare l anagrafica in base ai dati comunicati Messaggio ADT^A31 Sulla ricezione del messaggio di modifica dei dati anagrafici, occorre verificare innanzitutto se il paziente esiste in anagrafe locale. Se il paziente esiste l anagrafica viene aggiornata, altrimenti non viene fatto nulla. La strategia di verifica dell esistenza del paziente deve essere fatta in base ad un identificativo certo e riconosciuto in azienda, tipicamente il codice univoco aziendale o il codice fiscale. Messaggio ADT^A40 Sul messaggio di unificazione ( merge ) di due anagrafiche, il comportamento sarà il seguente: se entrambe le anagrafiche sono presenti in archivio, verranno unificate, altrimenti non verrà fatto nulla. Questo messaggio presuppone l esistenza e l utilizzo di un identificativo certo e riconosciuto in azienda, tipicamente il codice univoco aziendale o il codice fiscale.

13 Messaggio ADT^A01 (in ingresso alla cartella) Sul messaggio di nuovo ricovero, i dati contenuti nel messaggio (dati anagrafici del paziente e dati di ricovero) verranno posteggiati nella tabella QUEUE_IN. L interfaccia utente della cartella clinica verrà adattata in modo che vi sia evidenza dei pazienti in ingresso e non ancora allettati. L operazione di allettamento, con conseguente rimozione dalla tabella QUEUE_IN, sarà a carico di una funzione della cartella clinica. Una volta rimosso dalla tabella QUEUE_IN, un ricovero non potrà più essere annullato tramite messaggio ADT^A11. Messaggio ADT^A01 (in uscita dalla cartella) Il caso di ricovero diretto in reparto è l unico scenario in cui è previsto che la cartella clinica Margherita dia origine ad una notifica ADT^A01 verso il sistema di gestione dei ricoveri. Questo scenario è complicato dal fatto che all atto del ricovero in reparto non è disponibile il numero di ricovero, gestito in maniera centralizzata dall ADT, quindi si propone lo scenario seguente: Il paziente viene accettato in reparto, utilizzando i metodi della cartella. Nella tabella di uscita viene contestualmente creata una richiesta, che deve essere necessariamente distinta da tutte le altre tipologia, a significare esiste un nuovo ricovero creato localmente. La richiesta viene elaborata dal gateway, che invia all ADT un messaggio ADT^A01 sprovvisto di numero di ricovero; l ADT assegnato un numero di ricovero e memorizza il ricovero come nuovo ricovero incompleto ; una volta elaborata, la richiesta viene cancellata dalla tabella di uscita di Margherita. In un tempo successivo (es. la mattina dopo se il ricovero è avvenuto di sera) gli impiegati amministrativi dell ADT completano il ricovero e lo spediscono alla cartella Margherita. La cartella si ritrova un nuovo ricovero nella tabella di input. Nel momento in cui lo processa per inserirlo nel database, deve accorgersi che in realtà si tratta di un paziente già presente e deve aggiornare i dati di ricovero, compreso ovviamente il numero, al posto di inserirne uno nuovo. Messaggio ADT^A02 Si devono distinguere i due casi di trasferimento dal reparto e verso il reparto. In caso di trasferimento dal reparto, sarà cura del medico o del personale infermieristico spostare

14 preliminarmente il paziente dalla sua locazione (letto) alla tabella QUEUE_OUT. A questo punto il trasferimento potrà essere reso effettivo da parte dell ADT: alla ricezione del messaggio di trasferimento, sempre che il paziente sia presente in tabella QUEUE_OUT, il messaggio verrà accettato ed il paziente rimosso dalla tabella di transito. In caso di trasferimento verso il reparto, a seguito del trasferimento il paziente comparirà nella tabella QUEUE_IN e potrà essere preso in carico dal reparto, a meno di successivo annullamento. Messaggio ADT^A03 Preliminarmente al dimissione di un paziente, sarà cura del medico o del personale infermieristico spostare il paziente dalla sua locazione (letto) alla tabella QUEUE_OUT. A questo punto la dimissione potrà essere resa effettiva da parte dell ADT: alla ricezione del messaggio di dimissione, premesso che il paziente sia presente in tabella QUEUE_OUT, il messaggio verrà accettato ed il paziente rimosso dalla tabella di transito. Messaggio ADT^A11 Il messaggio di annullamento del ricovero dovrà verificare se il paziente risulta ancora presente nella tabella temporanea QUEUE_IN, ad indicare che il paziente non è stato ancora preso in carico dal reparto. Se ancora presente nella tabella di transito, la riga corrispondente verrà rimossa e l annullamento accettato. In caso contrario l annullamento verrà rifiutato. Messaggio ADT^A12 Si gestirà soltanto il caso di annullamento di un trasferimento verso il reparto, dal momento che il trasferimento dal reparto comporta una sequenza di due operazioni, che poco verosimilmente possono essere sbagliate in sequenza. Il paziente verrà rimosso dalla tabella QUEUE_IN, sempre che il trasferimento non sia già stato preso in carico. In caso contrario l annullamento non verrà accettato. Architettura tecnica Il componente di integrazione Gateway HL7 verrà realizzato come servizio NT, quindi una volta installato su un sistema compatibile (Windows 2000/XP/Vista/Server2003), il servizio sarà disponibile senza alcun intervento dell utente ed in particolare verrà avviato

15 automaticamente alla partenza del sistema operativo. L installazione del servizio potrà essere ottenuta lanciando un apposito script; il componente può essere installato, ad esempio, sul server dove risiede anche la componente server della cartella clinica Margherita, anche se questo non deve essere inteso come un requisito. Poiché il Gateway è sviluppato in architettura.net, è necessario che sul sistema ospite sia presente il Framework.NET versione 2.0 o successiva. Trattandosi di un processo server, quindi non dotato di interfaccia utente, l interazione con tale servizio ai fini di diagnosticarne il comportamento avverrà sia tramite l Event Viewer di Windows, sia tramite un file di log, il cui livello di verbosità (livello di dettaglio dei messaggi) sarà configurabile tramite un apposito parametro di configurazione. Il servizio esporrà verso la rete aziendale una porta TCP, il cui valore è configurabile a parametri in modo da evitare conflitti con porte già utilizzate. Lo scambio di messaggi HL7 avverrà su tale porta TCP, utilizzando il protocollo HL7 denominato MLLP (Minimal Lower- Layer Protocol). Il servizio verrà realizzato in modalità multi-thread, in modo tale da poter gestire un numero virtualmente illimitato di connessioni concorrenti.