Il folder clinico del paziente

Corsia Virtuale:
ipotesi di sistema informativo come federazione d’informazioni cliniche relative al paziente
Angelo Rossi Mori & Fabrizio L. Ricci
15 dicembre 2001
Il processo di cura che si basa sulla corsia virtuale enfatizza le funzioni dell'insieme delle strutture sanitarie (di medicina
generale, ospedaliera, ecc.) che collaborano per portare avanti il protocollo clinico scelto per il paziente, ognuna con le
proprie competenze e specializzazioni. E' importante definire bene i ruoli che ciascuna di esse svolge nell'erogazione
della cura ed è quindi fondamentale definire il modello d'interazione tra di esse, tenendo anche conto che il paziente è
"fisicamente" distante dagli operatori sanitari presenti in tali strutture. L'erogazione della cura eseguita durante il
ricovero virtuale coinvolge i seguenti attori:
 il paziente (oggetto della cura);
 il responsabile della cura (un medico, un team di medici) che segue l'intero processo di cura del paziente;
 il fornitore della cura (il responsabile della cura, un medico specialista, un infermiere, il paziente stesso, un
familiare del paziente, il centro di ascolto) che esegue le attività diagnostiche, terapeutiche e riabilitative.
Lo scambio d'informazione tra i diversi attori, oltre che avvenire direttamente, si realizza tramite l'accesso alle
informazioni rese disponibili nel server del folder clinico del paziente. Tale folder clinico deve permettere al
responsabile di avere un’immagine aggiornata del paziente (nella propria cartella clinica) ed assicurare la coerenza
degli obiettivi tra gli attori. Pertanto im folder clinico del paziente deve contenere sia le nuove informazioni cliniche
relative al paziente che la lista degli eventi relativi alle attività cliniche suggerite, programmate ed eseguite
(protocollo clinico) ed anche lo stato di esecuzione della singola attività (procedure gestionali) e dei flussi informativi
tra le strutture coinvolte nell'attività. In tal modo si realizza la gestione federata delle informazioni crucialiche
cosituiscono le varie cartelle clinice; il vantaggio di una tale gestione federata è rappresentato dalla immediata
disponibilità delle informazioni cruciali presenti nelle varie cartelle cliniche del paziente presenti in tutto il territorio.
La federazione di dati clinici
Il linguaggio XML (Extensible Mark-up Language) è stato adottato come W3C standard nel settore dell’informatica
medica.
La Task Force su XML del CEN TC2511 ha individuato differenti prospettive nell’uso di XML come strumento per
federare dati clinici provenienti da differenti sistemi informativi.
Nel caso del progetto “Corsia virtuale” si è in presenza di differenti sistemi legacy, ciaascuno contenente informazioni
sullo stesso paziente. Le informazioni necessarie ad un utente, nascono dalla fusione di quelle presenti in alcuni di tali
sistemi. Pertanto l’utente dovrebbe interrogare tutti i sistemi. Per evitare ciò, le informazioni del singolo paziente sono
estratte dai singoli sistemi ed inserite in un unico archivio, sotto forma di documenti XML (od un insieme di documenti
opportunamente “collegati”). Questa estrazione è effettuata direttamente dal software che gestisce il singolo sistema
legacy secondo formati predefiniti, descritti con il linguaggio XML (fig. 1).
“Categories of use of XML in healthcare”, XML Task Force, CEN TC251/XML/DM02, Giessen,
July 1998
1
1
User
Interface
User
Interface
User
Interface
XML Document
Application
T
T
AC
RA C
EXT
T
CT
AC
TR
TR
EX
EXTRA
Data
store
WRITE
READ
WRITE
READ
Multi source XML publisher
EX
ENTER
API
API
Application
Data store
Brow ser
VIEW
VIEW
ENTER
Brow ser
Brow ser
Data store
Data
store
Fig. 1: XML publishing for browsing merged information
Questo approccio, definito come “XML publishing for browsing merged information”, permette di presentare le
informazioni provenienti dai vari sistemi in maniera uniforme, in quanto la federazione dei dati clinici è ottenuta tramite
un sistema di documenti (server del folder clinico del paziente, nella fig. 1 indicato come “multisource XML
publisher”) navigabile in rete in modo coerente.
Se all’inizio quando i sistemi legacy sono in numero di 2/3 non è necessario definire i documenti XML secondo uno
standard, al crescere del numero di sistemi occorrerà definire l’XML schema, e quindi i relativi tag, in modo che per i
singoli sistemi siano definiti messaggi di scambio, cioè la struttura dei documeni che costituiscono il folder clinico del
paziente.
Ciò diviene fondamentale quando si vorrà processare automaticamente i documenti XML (ad esempio data analysis,
supporto alle decisioni, ecc.); in tal caso occorrerà non solo standardizzare la struttura dei singoli documenti ma anche il
contenuto: è necessario un dizionario dei metadati.
Oltre a visualizzare le informazioni cliniche e a processarle, questa soluzione permette l’integrazione dei dati, nel senso
che un dato presente nel server del folder clinico del paziente può essere inserito nella cartella clinica del singolo
sistema legacy, nel quale un medico archivia i dati che lui ritiene importanti da gestire per controllare il processo di cura
del paziente. Si crea così un modo per lo scambio elettronico di dati tra sistemi legacy.
Pertanto quando un documento è inserito nel server del folder clinico del paziente, può essere inviato automaticamente
un avviso ai vari sistemi legacy ed addirittura tali sistemi possono essere regolarmente aggiornati.
Il difetto della soluzione proposta risiede nel fatto che il medico naviga in un sistema integrato formato dal sistema di
gestione della sua cartella clinica e del server del folder clinico del paziente: possono essere presenti due modalità
diverse d’interazione. Ma questo difetto può divenire un punto di forza della proposta in quanto due diversi sistemi
implicano:
 un ben definito confine nella responsabilità e qualità delle informazioni;
 un maggior controllo delle informazioni inserite nel singolo sistema legacy.
Il folder clinico del paziente
Il folder clinico del paziente è costituto dai vari documenti (in formato XML) generati dalle varie cartelle cliniche. Tali
informazioni descrivono sia lo stato di salute del paziente che lo stato di avanzamento del protocollo clinico ed anche in
delle singole attività gestionali componenti.
E’ chairo che non tutte quesi documenti interessano il medico: l’utente navigherà nelle informazioni presenti nel server,
leggerà quelle che gli interessano e, se vuole, potrà inserirle nella sua cartella clinica.
Questa soluzione implica:
2

la realizzazione di procedure di “import” ed “export” per ogni sistema di gestione di cartella clinica (sistema
legacy) secondo un ben preciso formato XML;
 l’individuazione dei documenti che si scambiano gli attori del ricovero vituale e la definizione del relativo
messaggio, visto come input al server del folder clinico del paziente;
 la definizione di una sintesi della cartella clinica del paziente come documento di apertura del folder clinico del
paziente.
Pertanto il contenuto del folder clinico del paziente è composto, ad esempio, da:
o la sintesi del paziente, che è estratta dalla cartella clinica;
o le notifiche di eventi (altri ricoveri, problemi, etc),
o la variazione di stato di un’attività (la necessità e la prenotazione di un esame, ecc.);
o il monitoraggio da home care;
o notifiche interventi da centro di ascolto;
o i risultati dei vari esami diagnostici;
o i referti degli interventi speciaistici.
La presenza del server del folder clinico del paziente può permettere la segnalazione automatica dell’arrivo di nuovi
documenti al personale sanitario interessato, ad esempio al medico generico l’ingresso dei risultati dell’ultima analisi
clinica del paziente che lui sta seguendo. Questo implica la costruzione di un archivio (database degli operatori sanitari)
che conosca lo staff sanitario che opera sul paziente; tale archivio servirà anche a garantire la privacy dell’intero
sistema.
Qualora nel tempo si aumenterà il numero degli attori partecipano al ricovero virtuale (e dei relativi sistemi di gestione
delle cartelle cliniche – sistemi legacy) e delle patologie trattate sarà necessario la costruzione di un dizionario dei
metadati e quindi una ontologia dei documenti scambiati.
La presenza del server del folder clinico del paziente implica una figura di gestore del server di dati clinici che
garantisce la manutenzione dei dati in esso presenti. Ad esempio egli avrà il compito di cancellare i documenti. Vanno
chiarite però alcune questioni:
o chi è questa figura (un medcio, uno staff, ecc.);
o quando e perché effettuare l’operazione di cancelllazione.
Probabimente non si tratta di una cancellazione fisica, ma solo dell’inserimento di un flag associato alla singola
informazione, in modo da renderlo obsoleta: tale procedura è adotta nelle cartelle cliniche elettroniche per motivi
legali.
Nel definire questa figura e i suoi ruoli occorre tener conto degli scopi che ha il server del folder clinico del paziente: si
tratta di un server che facilita la comunicazione tra i vari attori che operano sul paziente, per cui i i dati transitano dal
server (e ci rimangono) e quelli utili vengono copiati nella cartella locale della singola struttura sanitaria (sistema
legacy).
I messaggi
Durante il ricovero virtuale vengono scambiati documenti tra gli attori. In formato elettronico questi documenti
divengono il contenuto dei messaggi che circolano ne sistema informativo della corsia virtuale e che vanno a costituire
il folder clinico del paziente.
Un messaggio con il relativo documento associato (e quindi il set di dati impacchettato nel messaggio) è così composto:
o BUSTA – occorre una lista dei data elements per formato dell’header dei messaggi (chi spedisce, a chi,
quando, …).
o DIRECTORY ENTRY – occorre una lista dei data elements per entry nella directory per i documenti
(nome medico, nome paziente, data registrazione, tipo documento, tipo evento, data evento, …).
o PAYLOAD (cioè il contenuto utile) – occorre una descrizione del payload. Il server contiene e gestisce
due tipologie di dati (che devono/possono essere prodotte e utilizzate dai vari sistemi legacy:
 data set (minimo) strutturato – su cui fa ricerche strutturate, tabelle e calcoli. Le liste dei data
elements strutturati contenuti nei diversi tipi di documenti (una lista per ogni tipo di evento e di
patologia);
 documenti allegati – solo per display ed eventualmente ricerche a testo libero. Sarebbe bene
mettere nella voce della directory il nome standard del documento (resoconto visita, risultato di
laboratorio, rapporto operatorio, …) e l’evento che viene descritto (visita dermatologica,
inserimento di pacemaker, …).
L’architetura del sistema informativo
Oltre al server del folder clinico del paziente e al database degli operatori sanitari, esistono altri sistemi relativi alle
varie strutture che operano sul paziente.
3
I sistemi legacy
Ogni sistema di gestione di cartella clinica presenta le funzioni di import ed export che lo collegano al server del folder
clinico.
Ciò implica alcune scelte su queste nuove funzionalità:
o In una cartella clinica è ammesso un dato generato da un autore che non fa parte della struttura sanitaria
ove risiede il sistema legacy? – Verrà memorizzato insieme al dato anche le informazioni sulla sua
sorgente, ma ciò vuol dire che nella cartella clinica del medico di medicina generale è presente un dato
misurato dal paziente o la diagnosi che è stata effettuata da un medico ospedaliero.
o Come sono generati i messaggi? – Si ricorre ad una corrispondenza tra schema di cartella clinica e XML
del documento, memorizzato in database opportuno?
o come sono accettati i messaggi? - I dati strutturati presenti nel messaggio vengono interpretati dal sistema
legacy e memorizzati in modo opportuno. Invece per i documenti allegati, viene interpretata solo l’entry
strutturata della directory (cioè, il nome paziente, il nome medico, il nome del documento, la data
registrazione, il tipo di file, …). Il documento vero e proprio viene collocato sull’hard disc del sistema
locale (o viene puntato tramite URL presso un server h24) e viene passato al programma opportuno (a
seconda del tipo di file). Pertanto il sistema gestisce la directory entry ma non cerca di entrarci e né di
estrarre informazioni: esiste solo la possibilità di una sua visualizzazione.
Il servizio comune – centro di ascolto h24
Il centro di ascolto nazionale/regionale interviene, generalmente per un’emergenza, durante la non disponibilità
dell’ospedale (h6, h12). A tal fine deve poter leggere dal server una sintesi del paziente e gli eventi recenti e quindi
inserire nel folder clinico del paziente una sintesi del proprio intervento.
Le emergenze possono essere di due tipi:
 le emergenze da complicanze o da nuovi problemi acuti, per le quali è il paziente che chiama il medico;
 complicanze prevedibili, sulla base di dati di laboratorio, segni e sintomi iniziali o cambi di scenari, delle quali se
ne accorge solo il medico.
Per quelle del primo tipo, il paziente od un suo familiare può chiamare il centro (non ha altre possibilità in alcune
situazioni); in tal caso l’azione di risposta:
 si risolve per telefono (complicanze od eventi attese o probabili, di lieve entità, verificate, e per le quali, ad
esempio, è già stato fornito o prescritto il supporto farmacologico);
 si invia personale paramedico a domicilio per rilevazione di parametri fisiologici non telemonitorizzabilii
(strumenti non disponibili), o anche per necessità di terapie infusionali;
 in casi di gravità media si invia il medico;
 in casi di notevole gravità o di mancata disponibilità del medico per gravità media, in caso di necessità di procedure
diagnostiche di laboratorio o strumentali, si procede al ricovero in Day-Hospital o in regime di degenza ordinaria.
Per espletare il primo tipo di azione il centro di ascolto non necessità di alcun supporto oltre quello della dipsonibilità
delle informazioni cliniche sul paziente. Per la seconda e la terza deve conoscere le disponibilità degli operatori sanitari
(con apposito database delle disponibilità del personale sanitario); per la quarta deve interagire con il 118.
La valigetta
La valigetta ha due tipi di uscite:
o dati e testi, che vanno direttamente al server del folder clinico;
o segnali (ECG, spiro, ecc.) che vanno al centro specialistico, quindi refertati e da questo al server del folder
clinico secondo un messaggio così composto:
 il payload = segnale è accompagnato da dati strutturati di intestazione (nome paziente, nome
medico, data, ecc.);
 il centro specialistico aggiunge l’interpretazione e le conclusioni, e mette il tutto in un documento
in formato pdf;
 sarebbe opportuno memorizzare nella nuova intestazione del documento in formato pdf anche
una copia dell’interpretazione e delle conclusioni, più date e autori;
 si potrebbe strutturare la coppia referto + segnale (in modo ipertestuale).
Sarebbe utile che il messaggio di uscita dal centro di ascolto contenesse anche dei dati clinici strutturati ed il segnale in
quanto tale (non come semplice immagine), oltre al documento (segnale e referto) in formato pdf, a partire dai dati
strutturati di entrata. Infatti il documento in formato pdf è utile per la stampa del risultato dell’ECG, mentre la parte
strutturata potrebbe essere memorizzzata nella cartella clinica con la possibilità di un’eventuale successiva elaborazione
del segnale.
4
Gli standard
Al fine di garantire l’espansione del sistema in termini di nuovi sistemi legacy, di sistemi di telemedicina, ecc, è
importante il rispetto degli standard e dei risultati di alcuni progetti (candidati a divenire prossimamente nuovi
standard).
A tal fine occorre tener condo:
o CEN/TC251
 continuità delle cure – ENV 13940
 comunicazione cartella clinica – ENV 13606,
 trasmissione ECG – ENV 1064
 richiesta di ricovero e dimissione – ENV 12538
 richiesta e referto diagnostico – ENV 12539
 segni vitali (gestione apparechiature) – ENV 13734
o HL7
 CDA – clinical document architecture
o DICOM
 Immagini e segnali diagnostici
o LOINC
 nomi delle variabili misurate
 nomi delle misure effettuate sui segnali
 nomi dei documenti e delle sezioni (progetto DOTF)
o ASTM, PROREC Belgio, C-CARE, XDT, Medicalogic
 lista dei data elements contenuti in una cartella clinica
o inoltre esistono, come esempi da studiare e a cui eventualemente ispirarsi,
 i data set inglesi per diverse patologie in oncologia
 le estensioni ai sistemi di codifica della Regione Lazio, per diverse branche
 DO-IT data set europeo per il diabete
 CD sulla refertazione in cardiologia della Veterans Administration
La metodologia di progetto del sistema informativo-organizzativo
La realizzazione del sistema informativo ed organizzativo parte dalla descrizione concettuale del protocollo clinico
tramite un linguaggio di descrizione di workflow basato su un modello attività-evento. In tal modo verranno
individuati:
 le risorse cliniche (ruoli medici e parametrici, strumentazione diagnostica e terapeutica anche di tipo telecontrollo,
ecc.),
 le risorse informatiche (dati, parametri clinici e conoscenze),
 le relazioni temporali tra le varie attività cliniche e gestionali necessarie alla realizzazione del processo di cura,
Si giunge così non solo a definire l’interoperabilità tra le cartelle cliniche presenti nelle differenti strutture sanitarie, ma
anche il flusso informativo.
La progettazione della corsia virtuale si basa sul modello del processo di cura relativo alle patologie in oggetto, basato
sul modello d’interazione presentato precedentemente. Il metodo di progetto si basa sull’analisi e modellizzazione di:
i.
protocolli clinici e in particolare in un’ottica di decentramento;
ii.
scenario evolutivo della malattia in questione e il ruolo dei paramtri epidemiologici nell'evoluzione della
stessa;
iii.
dati clinici-gestionali e il ruolo degli esami (che possano anche essere effetuati dal paziente) e le emergenze;
iv.
modello funzionale organizzaione-informazione e il ruolo di Centro di Ascolto;
v.
sistemi e tecnologie della Telemedicina e la questione di integrazione di essi nel progetto.
Pertanto sono punti di partenza di questo studio:
o La cartella clinica;
o Linee guida cliniche e comportamentali relative a 2 patologie (una chirurgica ed una cronica).
o Lo scenario per definire il quadro di riferimento organizzativo della corsia virtale, tenedo conto che
esistono due situazioni ben precise e abbastanza diverse:
 Il caso del paziente ospedalizzato in modo precoce;
 Il caso del paziente cronico domiciliare
Scenario A – paziente ospedalizzato dimesso in modo precoce
Le caratteristiche di questo scenario sono:
 il paziente viene dimesso e rimane sotto la supervisione dell’ospedale
o mandato al medico di medicina generale (MMG) di seguire un “piano di follow-up consigliato”
o il MMG riceve piano di cura consigliato e sintesi della cartella ospedaliera, più aggiornamento ad ogni
incontro in ospedale
o il MMG riferisce all’ospedale eventi inattesi e decisioni sue (variazioni)
5




cartella clinica principale presso l’ospedale
o deve includere monitoraggio da home care
o deve includere segnalazioni dal MMG
inizio e fine del processo sono a carico dell’ospedale:
o la gestione del server del folder clinico
o la registrazione nuovo paziente e chiusura del folder clinico
Ruolo e compiti della cartella clinica di Colianni – raccogliere documentazione (strutture dati, formati, …)
problemi aperti
o responsabilità
 di chi è la responsabilità legale del paziente ? che forma di collaborazione si instaura tra ospedale
e MMG ? (il MMG viene arruolato e rimborsato dall’ospedale ?)
 libertà del MMG rispetto al piano consigliato dall’ospedale
 chi prescrive ? il MMG prescrive sulla base dei consigli ? può adattare – modificare le
prescrizioni ?
o ruolo del paziente (e familiari, volontari)
 acquisisce dati con sensori e test diagnostici (affidabilità ?)
 come vanno i dati nella caretella clinica ? chi ne è responsabile ?
 può inserire le proprie annotazioni ?
 valutazioni del proprio stato, sintomi
 valori misurati
 assunzione di farmaci, procedure effettuate
o fattori economici
 perché il MMG dovrebbe accettare un sovraccarico di lavoro in quanto gli viene affidato un
paziente complesso – non guarito – che altrimenti sarebbe a carico dell’ospedale
 l’ospedale fattura un DRG normale per una prestazione ridotta e passata in carico al MMG ?
o fattori organizzativi e clinici
 l’ospedale manda personale proprio a casa del paziente ? fa controlli in ambulatorio outpatient o
day hospital ?
 chi interpreta i dati dei monitoraggi da casa ? l’ospedale manda aggiornamenti di
diagnosi/interpretazioni e piani di cura al MMG ? i dati vanno in doppia copia a ospedale e MMG
?
 prima dell’ospedalizzazione, si può prevedere la stessa procedura per preparazione e filtro al
ricovero (sempre iniziata dall’ospedale) ?
Scenario B – paziente cronico domiciliare
Le caratteristiche di questo scenario sono:
 il mandato principale di assistenza è affidato al MMG
 devices e interfaccia internet dal paziente al MMG per aggiornamenti
 ospedale come supervisione riceve copie dei dati (parametri sentinella concordati), è un watchdog che decide
quando intervenire con interrupt e warning proattivo
 visita iniziale nell’ospedale, transfer di mandato con istruzioni al MMG
 notifiche strutturate (con dati predefiniti e livello di importanza/urgenza) messe su server o spedite ai destinatari
opportuni secondo un profilo
 Ruolo e compiti della cartella clinica di Colianni – raccogliere documentazione (strutture dati, formati, …)
 problemi aperti
o responsabilità
 di chi è la responsabilità legale del paziente ? che forma di collaborazione si instaura tra ospedale
e MMG
 libertà del MMG rispetto al piano consigliato dall’ospedale
 chi prescrive ? il MMG prescrive sulla base dei consigli ? può adattare – modificare le
prescrizioni ?
o ruolo del paziente (e familiari, volontari)
 acquisisce dati con sensori e test diagnostici (affidabilità ?)
 come vanno i dati nella caretella clinica ? chi ne è responsabile ?
 può inserire le proprie annotazioni ?
 valutazioni del proprio stato, sintomi
 valori misurati
 assunzione di farmaci, procedure effettuate
o fattori economici
 perché l’ospedale dovrebbe accettare un sovraccarico di lavoro
o fattori organizzativi e clinici
6

l’ospedale manda personale proprio a casa del paziente ? fa controlli in ambulatorio outpatient o
day hospital ?
 chi interpreta i dati dei monitoraggi da casa ? l’ospedale manda aggiornamenti di
diagnosi/interpretazioni e piani di cura al MMG ? i dati vanno in doppia copia a ospedale e MMG
?
Compiti dei due gruppi di lavoro
Cosa fa il gruppo clinico
o scrive due casi verosimili dettagliati (uno per ogni sperimentazione), come fosse un libro di testo,
focalizzando su una precisa patologia e su un corrispondente intervento
 descrizione di un paziente realistico in ospedale, intervento a cui viene sottoposto, stato alla
dimissione e necessità di follow-up, corso degli eventi attesi e piano di cura previsto (clinicodiagnostico) con l’evoluzione della malattia e con i parametri sentinella
 il paziente viene dimesso, messaggio al MMG (cosa contiene ?)
 parametri misurati a casa, a chi vengono spediti e cosa ci fanno (modulazione del piano di cura
…)
 descrivere una interazione MMG-ospedale e le attività del MMG
 chi prescrive e cosa prescrive
 accade un evento inatteso (quale ? – fare un esempio realistico) e vengono prese nuove decisioni
(quali ? - esempio). Immaginare chi ne parla e con chi (se ne accorge il paziente, chiama il MMG
e cosa gli dice, MMG manda un e-mail all’ospedale che dice …, ospedale risponde …)
o descrive le conoscenze cliniche che verranno fornite
 quali documenti vengono scambiati e in quali occasioni
 quali dati vengono memorizzati e scambiati, per ogni tipo di patologia e per ogni evento
 quali tabelle di codifica vengono utilizzate, per ogni data element (non solo diagnosi e tariffario
…) – terminologie di infermieri e assistenti domiciliari ??
o descrive le sedi sperimentali
 reparti e servizi coinvolti (quale sw ?), MMG coinvolti, reti regionali e registri attesi, tipi di
pazienti previsti nella sperimentazione, …
Cosa fa il gruppo tecnico
 perfeziona e commenta il diagramma prodotto durante l’incontro
 lo verifica con i 2 casi descritti dal gruppo clinico
o verifica quali infrastrutture sono disponibili nelle sedi sperimentali, sia ospedaliere che MMG (hw, sw,
reti, …)
o espande la descrizione del centro servizi nazionale/regionale
o produce una descrizione dettagliata del server e delle interfacce necessarie presso i sw locali esistenti
 ambedue i gruppi esaminano gli standard disponibili e vedono quanto possono essere utili come sono o possono
essere utili come ispirazione.
7