3. Architetture informatiche e gestione dei dati sanitari
3.2 Definizione di Electronic Health Record
Come avremo modo di ribadire, il Garante Privacy italiano non ha fatto una chiara scelta di campo da un punto di vista tecnico- architetturale. Questi, infatti, prima di addentrarsi nella definizione par- ticolareggiata delle sub-categorie individuate all’interno della classifi- cazione degli strumenti atti a gestire i dati sanitari dei pazienti (FSE e
dossier), tratta in apertura delle «Linee guida in tema di Fascicolo Sani-
tario Elettronico (Fse) e di dossier sanitario – 16 luglio 2009» (d’ora in avanti: LG FSE) de
l’insieme dei diversi eventi clinici occorsi ad un individuo, messo in condivisione logica dai professionisti o organismi sanitari che assisto- no l’interessato, al fine di offrirgli un migliore processo di cura44.
43 Cfr. R. C
USHMAN, Primer: Data Protection and the Personal Health Record,
Project Health Design ELSI Team, University of Miami, in Rete: <http://www.projecthealthdesign.org/media/file/primer_data_protection.pdf>;
ID., Primer: Authentication of identity (with application to PHRs/PHAs), in Rete:
<http://www.projecthealthdesign.org/media/file/primer_authentication.pdf>; ID., PHRs
and the Next HIPAA, 2008, in Rete: <http://www.projecthealthdesign.org/
media/file/PHR_HIPAA2.pdf>; A.M. FROOMKIN, Forced Sharing of Patient-
Controlled Health Records, Working Paper, 2008, in Rete: <http://www.project
healthdesign.org/media/file/Forced-sharing.pdf>; ID., The New Health Information
Architecture: Coping with the Privacy Implications of the Personal Health Records Revolution, UM ELSI Group for Project HealthDesign, 2008, in Rete:
<http://www.projecthealthdesign.org/media/file/social-life-info-15.pdf>; N.P. TERRY,
Personal Health Records: Directing More Costs and Risks to Consumers, Working
Paper, August 2008, in Rete: <http://ssrn.com/abstract=1248768>.
Non vi è qui una scelta tecnologica, bensì un’indicazione di ca- rattere concettuale, utile nella prospettiva regolativa scandita dal baga- glio di nozioni giuridicamente rilevanti offerte dal Codice Privacy. È la condivisione logica dei dati tra organismi e professionisti sanitari in vi- sta di un miglioramento del processo curativo che permette di dare l’imprimatur di FSE ad un’architettura informatica, quale che sia la modellizzazione informatica attraverso cui essa sia concepita e diventi operativa.
Il ruolo del cittadino, sebbene non richiamato nelle definizioni a carattere generale, viene ribadito a livello di inciso:
il titolare del trattamento può, inoltre, prevedere che l’interessato pos- sa inserire o ottenere l’inserimento – anche in appositi moduli e se- condo degli standard, anche di sicurezza, definiti dal titolare – talune informazioni sanitarie (es. autovalutazioni, referti emessi da strutture sanitarie di altre regioni o Stati) o amministrativo sanitarie (es. appun- tamenti medici, periodicità dei controlli prescritti) che riterrà più op- portune45.
Il sistema di FSE italiano è, pertanto, orientato verso un model- lo di EHR e pone in secondo piano, ma come obiettivo da raggiungere, la scelta di un’infrastruttura basata anche su un modello di PHR.
Non tralasciando il ruolo primario che, in prospettiva, il cittadi- no rivestirà all’interno di queste architetture, verranno di seguito ana- lizzate ulteriori peculiarità dei sistemi di EHR, utili a meglio compren- dere le modalità secondo le quali tali servizi possono essere offerti46. Il tutto risulterà cruciale allorquando si cercherà di conformare le architet-
45 Ibidem, p. 5.9.
46 Si prenda a riferimento A
MATAYAKUL, Electronic Health Records, cit., 2 ss.;
CARTER, Electronic Health Records, cit., 5 ss.; R.GARTEE, Electronic Health Records.
Understanding and Using Computerized Medical Records, Upper Saddle River, New
ture digitali ai principi ed alle regole giuridiche che connotano, in parti- colare, il nostro ordinamento giuridico.
Un sistema di EHR si caratterizza per tre principali funzionali- tà: l’integrazione di dati provenienti da diverse fonti (ospedali, profes- sionisti sanitari, ecc.), l’acquisizione di dati presso i punti di assistenza ed il supporto all’attività clinico decisionale. Quando queste componen- ti sono incorporate all’interno di una singola infrastruttura ed interagi- scono tra di loro in maniera armonica, possiamo considerare il risultato un EHR, appunto.
Questo fa dell’EHR un sistema, ovvero una serie di elementi in- terconnessi che funzionano assieme per conseguire uno scopo determi- nato: la cura del paziente. L’aspetto problematico dei sistemi in ambito sanitario è determinato dal fatto che i dati vengono prodotti autonoma- mente da parte di soggetti diversi e spesso non coordinati tra loro. L’interoperabilità gioca, quindi, un ruolo cruciale.
All’interno del sistema acquista valore l’integrazione tra infor- mazioni di varia natura (dati clinici, dati finanziari, dati amministrativi, ecc.) che, assieme, concorrono a migliorare sensibilmente in termini di qualità, costi ed efficienza il servizio sanitario. Inoltre, il EHR non è limitato ad una singola posizione spaziale e deve invece collegare di- versi e distanti punti di accesso a disposizione dei diversi utenti (pa- zienti) e fornitori del servizio (aziende ospedaliere, professionisti sani- tari, ecc.). Esso deve essere in grado di integrare dati provenienti dagli operatori sanitari per garantire la continuità nelle cure e da sistemi PHR, al fine di porre in essere una struttura di visualizzazione longitu- dinale dello stato clinico e di salute di un singolo soggetto.
Da un punto di vista tecnico, le componenti di un modello di EHR sono le seguenti47.
47 Per un’introduzione alle caratteristiche fondamentali ed alle componenti tecniche
Anzitutto, esso deve avere sistemi di approvvigionamento dei dati (source system) in grado di raccogliere le informazioni necessarie a supportare l’infrastruttura. Sono i sistemi amministrativi, finanziari e dipartimentali che interagiscono secondo diverse modalità con il fasci- colo sanitario, all’interno dei quali si può definire la categoria degli
specialized source system per individuare i dati provenienti da sorgenti
di specialità clinica (quali cardiologia, servizi di emergenza, ecc.). Occorre, poi, prevedere una serie di sistemi informativi clinici (clinical information system (CIS)), i quali si occupano della raccolta e dell’elaborazione dei dati per supportare specifiche funzionalità. Ad e- sempio, all’interno di un ospedale i sistemi clinici possono essere sud- divisi in moduli separati con riferimento a diversi tipi di funzioni.
Abbiamo, inoltre, un’infrastruttura di supporto (supporting in-
frastructure) che riunisce i dati, integrandoli tra di loro. Sebbene ognu-
no dei sistemi informativi clinici possa tranquillamente funzionare co- me isola a sé stante di dati, la maggior parte delle strutture sanitarie considera un obiettivo da raggiungere quello dell’integrazione di tutte le informazioni provenienti dai diversi sistemi di approvvigionamento. Un repository clinico di dati (clinical data repository (CDR)) risponde a tale esigenza: esso consiste in un database concepito per gestire i tra- sferimenti di dati all’interno del sistema. Un «motore di regole» (rules
engine), ossia un sistema in grado di fungere da fonte di istruzioni ope-
rative, fornisce al CDR una logica di programmazione per il supporto alle decisioni cliniche da applicare ai diversi dati all’interno del reposi-
tory. Un sources knowledge garantisce, poi, che le informazioni conte-
nute siano rese disponibili e possano così essere utilizzate assieme ai dati raccolti attraverso il EHR (quale, ad esempio, un database sui vari tipi di farmaci che descrive i principi attivi e come questi influenzino o possano essere condizionati dai diversi stati fisiologici).
Un’altra struttura di integrazione è rappresentata dal data wa-
fine di generare nuove conoscenze. Le componenti volte ad integrare i dati generano a loro volta dei report. Infine, i sistemi di archiviazione (storage system) sono deputati alla raccolta ed alla conservazione dei dati così ottenuti.
Considerato che la facilità nell’utilizzo di questo tipo di stru- menti, unita alla necessaria fiducia che gli utenti devono poter riporre sul sistema stesso, sono i fattori chiave che ne determineranno, o non, il successo, risultano di fondamentale importanza altri due elementi: lo «strato» relativo alla presentazione grafica (presentation layer) e l’in- terfaccia uomo-computer (human-computer interfaces). Il primo è quel- la parte che garantisce l’immissione dei dati e le funzioni di ricerca; questo software consente l’utilizzo di template, icone ed altre caratteri- stiche grafiche per la visualizzazione dei dati. La seconda consiste nel dispositivo di input con cui gli utenti inseriscono e ricercano i dati (ad esempio, computer workstation, personal computer, computer portatili,
tablet, ecc.).
Le funzionalità legate alla connettività del sistema supportano la raccolta e l’integrazione dei dati. Un utilizzo crescente di EHR nel processo curativo dei pazienti, anche in una prospettiva aggregata, ri- chiede una struttura informatica, hardware e software, che permetta la comunicazione di dati tra reti informatiche locali (local area network – LAN48) e reti geografiche (wide area network – WAN49) in modo sicu- ro e privacy-oriented. Il risultato consiste nella creazione di varie forme di scambio di informazioni sanitarie – health information exchange (HIE) – tra diverse organizzazioni.
Rimane, in chiusura, da registrare l’importanza che via via stanno acquisendo le fonti di dati che derivano direttamente dai pazien- ti. Le PHR rappresentano sicuramente il futuro della sanità elettronica
48 Rete informatica caratterizzata da un’estensione territoriale non superiore a qual-
che chilometro.
e, dunque, sempre più sarà necessario integrare all’interno dei sistemi già esistenti (EHR) funzionalità ed applicazioni che consentano al pa- ziente-utente di fruire appieno delle potenzialità schiuse dal nuovo ruo- lo di protagonista della gestione dei percorsi curativi che lo riguardano, a quest’ultimo concesso dalla evoluzione tecnologica.