Analisi ad alto livello

Transcript

1 I.T.B. Istituto di Tecnologie Biomediche Unità di Sanità Elettronica - Roma Mariangela Contenti, Gregorio Mercurio, Gianfranco Misuriello, Fabrizio L. Ricci, Angelo Rossi Mori, Luca D. Serbanati Analisi ad alto livello Sommario Il Progetto LUMIR, coerentemente con gli obiettivi del Piano Sanitario Nazionale persegue due obiettivi strategici: Supportare l efficienza delle cure primarie attraverso l integrazione in rete dei professionisti medici e pediatri in forma singola o associata al fine di agevolare i processi di continuità della cura; Supportare l integrazione dei servizi sanitari e sociali nell ambito del territorio al fine di agevolare i processi di integrazione tra presidi, distretti e professionisti. A tal fine, le soluzioni adottate nel Progetto LUMIR si ispirano ai risultati ottenuti nell ambito del progetto MobiDis. Tale progetto MobiDis mette al centro delle sue ricerche lo studio di una nuova architettura di sistemi informativi per ambienti sanitari ed adotta una prospettiva mirata al paziente (patient-centric paradigm); in particolare, è stata studiata la gestione dei Fascicoli Sanitari Personali (FaSP) e dei relativi Libretti Sanitari Personali (LSP) dei cittadini in maniera integrata e consistente. Questo documento è così strutturato: Il Capitolo Introduzione ed i successivi paragrafi 1, 2, 3 illustrano il tema trattato, lo scopo ed il campo di applicazione, indicano la bibliografia di riferimento e gli acronomi e le definizioni utilizzate. Il Capitolo 2 riporta lo stato dell arte ed dell informatizzazione della Regione Basilicata, ponendo il focus sui progetti da coinvolgere nell ambito di LUMIR. Il Capitolo 3 espone una valutazione del Capitolato Tecnico del Progetto LUMIR alla luce dell indagine svolta in Regione e delle evoluzioni avvenute dall atto di redazione del programma. Il Capitolo 4, infine, descrive il disegno architetturale ad alto livello di un sistema informatico in grado di supportare l integrazione dei servizi sanitari e sociali nell ambito del territorio e in parallelo con una maggiore integrazione dei professionisti nello svolgimento delle cure primarie. Analisi ad alto livello Pagina 1 di 38

2 Indice dei Contenuti 1. Introduzione Scopo e vincoli Riferimenti bibliografici Acronimi e definizioni 4 2. Il sistema informativo sanitario attuale della Regione Basilicata Sintesi dello stato attuale del sistema informativo sanitario regionale (SISR) Progetti realizzati nell ambito dell assistenza sanitaria di base Progetti realizzati nell ambito dell assistenza ospedaliera Progetti di informatizzazione del SISR Progetto RUPAR della Regione Basilicata Progetto BAS-REFER Progetto ICAR Progetto TELEMEDBAS Progetto BASMED Progetto MARNO Rivisitazione del Capitolato Tecnico LUMIR Obiettivi di macro-livello Potenziamento degli attuali sistemi tecnologici (OR1) Adeguamento delle componenti software del SISR (OR2) Avvio sperimentale software per i Punti Salute (OR3) Vincoli applicativi: LUMIR, altri progetti e le applicazioni legacy Applicazioni sanitarie La situazione delle applicazioni sanitarie in Basilicata Componenti software legacy da prendere in considerazione per LUMIR Funzioni applicative legacy da prendere in considerazione per LUMIR Eredità MobiDis Principi MobiDis Livelli di approfondimento in MobDis Architettura MobiDis Il nuovo sistema informativo sanitario della Regione Basilicata Fascicolo Sanitario Elettronico per la Regione Basilicata Cos è FSE in LUMIR Infrastruttura FSE Requisiti per l infrastruttura di comunicazione che supporta FSE Componenti dell infrastruttura del FSE Analisi dei requisiti utente per il FSE Contesto del FSE Requisiti per il FSE Principi di progettazione del FSE per LUMIR Separazione ontologica Obiettivi ontologici di LUMIR Documenti CDA Separazione secondo i punti di vista (viewpoints) Architettura LUMIR Diagramma dei componenti del sistema LUMIR 37 Analisi ad alto livello Pagina 2 di 38

3 1. Introduzione 1.1 Scopo e vincoli Il presente documento descrive i risultati dell analisi di alto livello del sistema informativo riguardante il Progetto LUMIR fornendo in finale una proposta di architettura del sistema informatico in accordo con gli standard di cooperazione applicativa e con le direttive del Tavolo della Sanità Elettronica (TSE). Di conseguenza, il sistema LUMIR sarà facilmente integrabile con il futuro sistema nazionale che prevede l interoperabilità di tutti gli operatori sanitari, appunto su scala nazionale. La progettazione esecutiva verrà presentata in dettaglio in un apposito documento, successivo a questo. 1.2 Riferimenti bibliografici 1) [LUMIR] Convenzione CNR Basilicata - LUMIR Lucania - Medici in Rete - Allegato tecnico; 2) [MOBIDIS] Progetto MOBIDIS ( 3) [TSE] Il Tavolo di lavoro permanente per la Sanità Elettronica ( 4) [BASREFER] Progetto BAS-REFER Invio delle refertazioni di laboratorio ai medici di base per via informatica protetta, P.O.R. Basilicata 2000/2006, Misura VI.2 Reti immateriali, ALLEGATO 1 (allegato_1_-_scheda_progetto_bas-refer.doc); 5) [BASREFERWEB] Portale BAS-REFER ( 6) [ICAR] Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni <Task AP-1> Piano di progetto Versione 1.4 (ICAR_Task_AP1_piano_progetto_V1 4.doc); 7) [ICARWEB] Portale ICAR ( 8) [ICARC] Convegno L avvio del progetto ICAR. Interoperabilità e cooperazione applicativa fra le Regioni e le Province autonome Trento, Maggio 2006; 9) [TELEMEDBAS] Progetto TeleMedBas Servizi di Teleformazione e di telemedicina Specializzata su rete a larga banda PROGETTAZIONE ESECUTIVA (progetto esecutivo TeleMedBas.doc); 10) [ERA] ehealth ERA Towards the Establishment of a European Research AREA D2.3 Report on Priority Topic Cluster One and recommendations ; 11) [Allegati W1ANR1AA] W1ANRALL; 12) [TSE] TSE-IBSE-Strategia_architetturale-v01.00-DEF.pdf ( 39). Analisi ad alto livello Pagina 3 di 38

4 1.3 Acronimi e definizioni ADI ADP AO ASL CA CCV CDA CEA CNS CTR CUP EA EBM EHR FaSP FSE Assistenza Domiciliare Integrata Assistenza Domiciliare Protetta Azienda Ospedaliera Azienda Sanitaria Locale Medico di Continuità Assistenziale Cartella Clinica Virtuale HL7 Clinical Document Architecture Centri Esterni Accreditati Carta Nazionale Servizi Centro Tecnico Regionale Centro Unificato di Prenotazione Enterprise Architecture Evidence Based Medicine Electronic Health Record Fascicolo Sanitario Personale HL7 Health Level 7 IBIS IBSE Fascicolo Sanitario Elettronico InfoBroker Individuale Sanitario Infrastruttura di Base per la Sanità Elettronica ICAR Infrastruttura per la Cooperazione Applicativa Regionale ICT IP ISDN IBSE LSP LUMIR MdS MMG MobiDis Information Communication and Technology Internet Protocol Integrated Services Digital Network Infrastruttura di Base per la Sanità Elettronica Libretto Sanitario Personale LUcania Medici In Rete Ministero della Salute Medici di Medicina Generale Telemedicina tramite telefonia mobile Analisi ad alto livello Pagina 4 di 38

5 OMS PLS Programma Progetto PS PSN P2P RIM RMMG RS RSA RP RQ RT Organizzazione Mondiale per la Sanità Pediatri di Libera Scelta Progetto LUMIR Progetto LUMIR Punto Salute Piano Nazionale Sanitario Peer to Peer HL7 Reference Information Model Rete dei Medici di Medicina Generale Responsabile Scientifico Residenza Sanitaria per Anziani Responsabile del Programma Responsabile dell Assicurazione di Qualità Responsabile Tecnico del WorkPackage RUPAR Rete Unitaria della Pubblica Amministrazione Regionale SOA SPCoop SSN SSR SISR UTAP Service Oriented Architecture Sistema Pubblico di Cooperazione applicativa Sistema Sanitario Nazionale Sistema Sanitario Regionale Sistema Informativo Sanitario Regionale Unità Territoriale di Assistenza Primaria Analisi ad alto livello Pagina 5 di 38

6 2. Il sistema informativo sanitario attuale della Regione Basilicata 2.1 Sintesi dello stato attuale del sistema informativo sanitario regionale (SISR) La Regione Basilicata si estende su una superficie di Kmq, è costituita da due province e da 131 comuni. La popolazione residente è concentrata soprattutto nei centri urbani (90%), il resto si distribuisce tra nuclei rurali e case sparse. Il 66% della popolazione risiede nella provincia di Potenza (Fonti ISTAT, Censimento della popolazione 2001). Nei servizi territoriali operano 510 Medici di Medicina Generale, 90 Pediatri di Libera Scelta, 453 Medici di Continuità Assistenziale. Si ha un carico medio di 100 assistiti per MMG, di 582 assistiti per PLS e vi sono in media 3 CA per comune. Vi sono 27 distretti sanitari di I livello ed 11 distretti sanitari di II livello. Nella regione Basilicata tutte le strutture sanitarie sono interconnesse alla RUPAR ed il posizionamento dei nodi primari e secondari è stato fatto nell ottica di privilegiare la rete sanitaria regionale. La RUPAR nasce nel 1999, è costituita da 16 nodi di cui 11 posizionati in strutture sanitarie regionali, garantendo in tal modo la connessione a larga banda delle stesse. La gestione della rete è effettuata direttamente dalla Regione Basilicata per il tramite del Centro Tecnico Regionale che ha la responsabilità del dominio della Rete. Relativamente al Sistema Informativo Sanitario Regionale si può affermare che gli obiettivi raggiunti sono correlati: Alla realizzazione del Sistema Informativo Sanitario Regionale come insieme degli applicativi, connessi in rete tra loro, che gestiscono le principali aree sanitarie (prestazioni specialistiche e farmaceutiche, medicina di base, anagrafe assistiti e medici, ricoveri ospedalieri,specialistica ambulatoriale, etc.); Al collegamento telematico di tutte le strutture operanti nell ambito del Servizio Sanitario Regionale (ospedali, servizi specialistici, medici di base, etc.); Alla realizzazione di un sistema di supporto alle decisioni per il governo della spesa sanitaria, destinato ai dirigenti delle aziende sanitarie ed alla amministrazione regionale; Alla creazione di alcuni servizi reali all utenza delle Aziende Sanitarie e Ospedaliere fruibili sul portale Basilicatanet. Si considerano di seguito gli interventi effettuati nell area dell assistenza sanitaria di base e nell area dell assistenza ospedaliera. Tali interventi hanno prodotto un miglioramento dei servizi offerti dalle strutture sanitarie pubbliche adeguando il sistema esistente alle nuove tecnologie informatiche (basate sulla costituzione di Intranet aziendali) e costruendo nelle ASL le infrastrutture necessarie per lo sviluppo di servizi telematici per la sanità su scala Regionale Progetti realizzati nell ambito dell assistenza sanitaria di base Attivazione dei Centri Unificati di Prenotazione delle aziende sanitarie locali ed ospedaliere (CUP Aziendali) per rendere prenotabili, presso le diverse sedi delle aziende sanitarie dislocate sul territorio regionale, tutte le prestazioni; Analisi ad alto livello Pagina 6 di 38

7 Attivazione del Centro Unificato Regionale (CUP Regionale), per l integrazione dei CUP Aziendali. Tale attivazione è finalizzata a garantire l interoperabilità dei centri di prenotazione delle ASL e delle aziende ospedaliere ed ancora l interscambio informativo tra le aziende sanitarie ed i centri esterni accreditati (CEA) relativamente alle prestazioni ambulatoriali eseguite presso i medesimi centri e la gestione dell esenzione dei ticket da parte degli assistiti. Attivazione di un Call Center CUP unico a livello regionale per la prenotazione telefonica delle prestazioni specialistiche, in qualsiasi struttura sanitaria della Regione erogante le prestazioni richieste dall assistito. Sviluppo di un prodotto per la gestione dello Studio Medico di base in grado di fornire al medico di famiglia il necessario supporto informatico atto a consentirgli da un lato la completa automazione dello studio e dall altro l interazione con le strutture delle aziende sanitarie regionali in modo da offrire ai propri assistiti alcuni servizi fondamentali (vedi prenotazioni di visite specialistiche, indagini strumentali, esami di laboratorio). Sistema di Controllo di Gestione in grado di supportare i funzionari del Dipartimento Sicurezza Sociale della Regione e gli amministratori delle aziende sanitarie nelle decisioni per il governo della spesa sanitaria, sia a livello aziendale che a livello regionale, con particolare riferimento alla compensazione sanitaria interregionale. Controllo e monitoraggio della Spesa Farmaceutica convenzionata che, partendo dalla lettura ottica delle ricette, elabora alcuni indicatori quali-quantitativi a livello territoriale con comunicazioni periodiche (semestrali) al MMG. Adeguamento tecnologico e funzionale dei prodotti di gestione dell Anagrafe Unica della Popolazione Assistita. Gestione dei Pagamenti delle Convenzioni di Medicina Generica e Pediatrica. Gestione della assegnazione e collocazione della Guardia Medica Progetti realizzati nell ambito dell assistenza ospedaliera Per l assistenza ospedaliera nella regione Basilicata sono realizzati i seguenti sistemi: Sviluppo di un prodotto di controllo della produttività ospedaliera (AIRO) finalizzato a supportare il management delle aziende ospedaliere nelle attività di programmazione e controllo degli interventi volti migliorare l efficienza dell intera struttura ospedaliera. Tale sistema, partendo dalla gestione completa del ricovero, delle attività di reparto e delle attività ambulatoriali, consente di stabilire, misurare controllare, l efficienza e l efficacia complessiva di ciascuna unità operativa ospedaliera e, di conseguenza, dell intero presidio ospedaliero. Attivazione di un sistema di storicizzazione ottica dei dati clinici dell assistito (memorizzazione ottica delle cartelle cliniche). Sviluppo di un prodotto per la gestione delle Sale Chirurgiche (pianificazione degli interventi, gestione delle attività della sala operatoria, gestione dei farmaci e dei materiali utilizzati). Analisi ad alto livello Pagina 7 di 38

8 Adeguamento funzionale e avvio in esercizio del prodotto di gestione delle Attività di Reparto (prerequisito essenziale per l avvio in esercizio del Controllo di Produttività Ospedaliera). Sviluppo di un prodotto per la gestione dei Pazienti Dializzati (GEPADIAL). Sviluppo di un prodotto per la gestione dei Pazienti Cardiopatici (GEPACARD). In particolare, gli applicativi GEPADIAL (Cartella clinica elettronica per la Divisione di Nefrologia e Dialisi) e GEPACARD (Cartella clinica elettronica per la Divisione di Cardiologia) sono stati realizzati utilizzando la tecnologia Microsoft COM e sono strutturati in componenti ACTIVEX. I dati trattati dalle singole procedure sono memorizzati su database relazionale Microsoft SQL Server. GEPADIAL e GEPACARD possono scambiare dati e/o integrarsi con i seguenti software del Sistema informativo ospedaliero: Anagrafica unica assistiti; CUP; Laboratorio di analisi; Radiologia; Altri reparti. Le integrazioni possono essere realizzate attraverso i seguenti standard e/o metodi: Tracciato record; Viste logiche; HL7; XML; Web services. Analisi ad alto livello Pagina 8 di 38

9 2.2 Progetti di informatizzazione del SISR Progetto RUPAR della Regione Basilicata Dal punto di vista dell infrastruttura hardware, software e di rete, preposta all erogazione dei servizi informatici a livello regionale, il progetto RUPAR varato dalla Regione Basilicata, assicura attualmente l interconnessione a larga banda di tutte le ASL e di tutte le strutture ospedaliere. Queste, infatti, rappresentano i nodi primari o secondari del sistema. Associato al sistema di rete, il sistema hardware gode di caratteristiche analoghe, in quanto ciascun nodo regionale presenta dotazioni Server parzialmente adeguate a supportare le funzionalità applicative, ma comunque esistenti e in evoluzione Progetto BAS-REFER Il Progetto BAS-REFER gestisce i principali flussi operativi che permettono la creazione dei referti firmati e i loro invio al sistema centrale, per essere messi a disposizione dei MMG/PLS, dei cittadini e degli operatori autorizzati. Il medico potrà visualizzare la lista degli eventi clinici riconducibili alla produzione di referti di un proprio assistito solo ed esclusivamente previa autorizzazione dello stesso tramite delega da esplicitare in un apposita sezione del portale Basilicata.Net (rif. [BASREFERWEB]) Progetto ICAR ICAR è un progetto interregionale a cui hanno aderito 16 Regioni e la Provincia Autonoma di Trento. L importo complessivo del progetto interregionale è di circa 30 milioni di euro (fondi UMTS - DPCM ) e la durata è di 36 mesi. L obiettivo del progetto è quello di definire e realizzare un infrastruttura di base e alcuni relativi servizi infrastrutturali al fine di permettere la cooperazione applicativa a livello interregionale. Il progetto ICAR si articola in un insieme di interventi progettuali paralleli, tra loro coordinati ed integrati che le Regioni intendono cooperativamente attuare. Vi sono due tipologie di interventi: interventi infrastrutturali di base (INF) e interventi per lo sviluppo di casi studio applicativi (AP) (rif. [ICARC]) Progetto TELEMEDBAS Il progetto ha l obiettivo di potenziare la comunicazione tra i presidi sanitari regionali e collegarli ai Centri di Eccellenza Clinica (IRCCS), realizzando una rete formativa e informativa permanente di alto livello in medicina e sanità, basata sul teleconsulto specialistico, che utilizzi servizi di e-learning e videoconferenza, e che sfrutti l accesso ai dati clinico-amministrativi del paziente (rif. [TELEMEDBAS]). Dal punto di vista del trasferimento dei dati, l intervento sfrutta il potenziamento dell infrastruttura di rete regionale, che verrà ottenuto dall aggiudicazione dell appalto concorso per la continuazione, l ampliamento e l innovazione dei servizi di connettività della RUPAR e dei relativi servizi di base. Per la realizzazione dell intervento progettuale si prevede, in accordo con quanto previsto nella scheda di cui al primo integrativo all APQ-SI Basilicata (Accordo Programma Quadro Società dell Informazione), la progettazione, l acquisizione, l implementazione e Analisi ad alto livello Pagina 9 di 38

10 configurazione, nonché la messa a regime dei seguenti servizi e sistemi di trasferimento in relazione con gli obiettivi prefissati: Estensione e potenziamento della larga banda per le strutture Ospedaliere e collegamento alla rete GARR; Realizzazione di formazione permanente di alto livello in medicina e sanità e di un network per il teleconsulto specialistico Progetto BASMED Il progetto ha l obiettivo di supportare la cooperazione tra MMG e per la gestione dello Studio Medico di base, ed è in grado di fornire al medico di famiglia il necessario supporto informatico atto a consentirgli da un lato la completa automazione dello studio e dall altro l interazione con gli altri MMG in base a determinati percorsi/protocolli clinici Progetto MARNO Attraverso il sistema software MARNO, la Regione Basilicata svolge le attività di informatizzazione delle ricette farmaceutiche per la gestione del servizio di raccolta dei dati delle ricette a fini statistici e di controllo della spesa farmaceutica. Il servizio di rilevazione e trattamento dei dati dalle ricette farmaceutiche ha due finalità fondamentali: Verificare la congruità di quanto corrisposto alle farmacie convenzionate e se queste hanno rispettato le norme vigenti nella spedizione di ricette contenenti prescrizioni di medicinali la cui spesa è a carico del Servizio Sanitario; Elaborare statistiche sui consumi e sulla spesa farmaceutica, in riferimento alla tipologia dei farmaci, agli ambiti territoriali, alle caratteristiche degli assistiti, ai comportamenti prescrittivi dei medici, anche in relazione a livelli di spesa prefissati, ad indici prescrittivi standardizzati, all appropriatezza delle prescrizioni, alle interazioni, alle possibili correlazioni epidemiologiche dei consumi farmaceutici. Alla rilevazione e trattamento dei dati dalle ricette farmaceutiche sono connesse altre funzioni, come il trasporto delle ricette, la loro obliterazione, il loro inscatolamento, la loro archiviazione ottica (immagini digitali delle ricette), la loro custodia per cinque anni e lo smaltimento finale. Analisi ad alto livello Pagina 10 di 38

11 3. Rivisitazione del Capitolato Tecnico LUMIR 3.1 Obiettivi di macro-livello Il Progetto LUMIR si innesta nel contesto del progetto nazionale RMMG Rete dei Medici di Medicina Generale e persegue lo scopo del completamento e del potenziamento dell interconnessione logica esistente per consentire: A. Un effettiva comunicazione e condivisione delle informazioni tra vari utenti; B. L accesso ai dati trattati dal proprio sistema informativo, anche attraverso LUMIR; C. L integrazione dello stesso nell ambito del Sistema Informativo Sanitario Regionale, tra tutti i soggetti e le strutture sanitarie che operano nell ambito dell assistenza sanitaria primaria della Regione; D. L avvio sperimentale dei modelli organizzativi Punti di Salute, sul territorio regionale. Dal punto di vista prettamente implementativo, LUMIR prevede i seguenti interventi, con componenti software preferibilmente open source, a supporto del nuovo modello organizzativo in sperimentazione (i.e. Punto Salute), coerentemente alle politiche e linee guida del Tavolo permanente per la Sanità Elettronica: Ob. Descrizione OR1 Potenziamento degli attuali sistemi tecnologici ed informativi dei MMG e degli altri operatori, per consentire l effettiva comunicazione e condivisione delle informazioni OR2 Adeguamento delle componenti software del Sistema Informativo Sanitario Regionale afferenti ai livelli di assistenza territoriale ed ospedaliera, ai sistemi di monitoraggio delle prescrizioni ed al sistema di EHR Regionale, per consentire la loro integrazione con i sistemi informativi del MMG OR3 Avvio sperimentale di software progettato per i Punti Salute in almeno 5 punti sul territorio regionale Componenti software IBIS Regione Basilicata Rete di Repository FSE (Componente CCV-Mobidis) Libretto Sanitario Personale (LSP) Componenti di Integrazione (wrapper) allineati ai Template HL7 CDA LSP per Pediatria e/o 1-2 malattie croniche (e.g. Diabetologia e Cardiologia) Potenziamento degli attuali sistemi tecnologici (OR1) Questo intervento da parte della Regione Basilicata ha lo scopo di effettuare di perfezionare gli attuali sistemi tecnologici ed informativi dei MMG/PLS per consentire l interoperabilità tra vari attori coinvolti, con l effettiva comunicazione e condivisione delle informazioni e con l integrazione dei servizi applicativi della rete MMG/PLS nel contesto di un Sistema Informativo Sanitario Regionale integrato. In questo senso l intervento prevede: La connessione dei MMG/PLS al sistema di videoconferenza ed al network per il teleconsulto specialistico, al servizio degli operatori sanitari del territorio regionale Analisi ad alto livello Pagina 11 di 38

12 previsto dal progetto di telemedicina TeleMedBas (già in corso su altri progetti, e quindi non previsto in LUMIR); L accesso ai servizi di formazione specifica per MMG/PLS, per il tramite del portale di e-learning regionale (già in corso su altri progetti, e quindi non previsto in LUMIR); Il potenziamento dei servizi dedicati ai MMG/PLS sul portale Basilicata.Net, con accesso tramite certificato digitale (già in corso su altri progetti, e quindi non previsto in LUMIR); L automazione completa dei flussi informativi tra Regione, ASL, Ospedali e MMG/PLS con utilizzo diffuso della firma digitale (già in corso su altri progetti, e quindi non previsto in LUMIR); La definizione di regole standard per la produzione dei dati a partire dagli sistemi applicativi dei MMG/PLS (applicativi ad hoc o interoperabilità degli esistenti), al fine di consentire la condivisione delle informazioni tra MMG/PLS rendendo sostituibili tra loro i MMG/PLS nei confronti del cittadino assistito nello scopo di avere una copertura maggiore di assistenza sanitaria (attività prevista in LUMIR); La definizione ed implementazione delle componenti chiave della infrastruttura FSE, ovvero l IBIS regionale costituita da registri (i.e. Indice degli Eventi), repository, AccesGateway per il routing dei messaggi, e il middleware dei servizi comuni (attività prevista in LUMIR); La definizione ed implementazione della componente FSE (ovvero CCV in accezione Mobidis) (attività prevista in LUMIR); La definizione ed implementazione del front-end del FSE cioè delle componenti che forniscono varie viste sul FSE (attività prevista in LUMIR) Adeguamento delle componenti software del SISR (OR2) Questo intervento prevede l adeguamento dei sistemi applicativi attuali o in corso di realizzazione del SISR per renderli interoperabili nel sistema integrato. A partire dai progetti in corso di realizzazione nella Regione relativamente ai sistemi di cooperazione applicativa ed all integrazione della RUPAR Basilicata in linea con le regole tecniche condivise a livello nazionale, vengono adeguati gli attuali componenti software dei SISR per consentire l integrazione con i sistemi informativi dei MMG/PLS. Ciò consentirà l integrazione dei MMG/PLS e dei Punti Salute con il territorio e con l ospedale/asl consentendo la condivisione delle informazioni tra tutti i soggetti coinvolti a vario titolo nell erogazione dei servizi sanitari al cittadino assistito. L intervento prevede: Implementazione delle funzioni applicative di CUP, Refertazione, ADI, etc. (già in corso su altri progetti, e quindi non previsto in LUMIR); Integrazione al livello applicativo di alcuni sistemi applicativi esistenti utilizzati dai vari attori nel ambito del SISR con particolare riferimento all applicativo per la continuità assistenziale; l attività verrà realizzato attraverso apposite componenti software (wrapper) che da un lato integrano le funzionalità già disponibili di tipo RMMG (e.g. prenotazione online, prescrizione, etc.) e ne fornisce altre specifiche per Analisi ad alto livello Pagina 12 di 38

13 la nuova forma di assistenza (e.g. gestione integrata ADI, etc.) e dall altro lato utilizza come collante il middleware e FSE previste da OR1 (attività prevista in LUMIR); La definizione di regole standard per la produzione dei dati, a partire dagli applicativi SISR, al fine di consentire la condivisione delle informazioni tra operatori (attività prevista in LUMIR) Avvio sperimentale software per i Punti Salute (OR3) L intervento per il Punto Salute prevede: Con riferimento alla sperimentazione del Punto Salute di S. Gervaso avviata nella ASL N 1 di Venosa, l avvio, da parte della Regione, con gradualità di altri PS nelle ASL del proprio territorio (attività non prevista in LUMIR); La definizione del modello organizzativo funzionale del PS e l eventuale attivazione di uno specifico sistema informativo atto alle esigenze di tali strutture così progettate, completamente integrato nella rete sanitaria regionale (attività prevista in LUMIR); Gli aspetti sanitari riguarderanno in prima battuta il completamento del follow-up della prima infanzia, e si analizzerà la possibilità di estendere i risultati ad altre patologie come, ad esempio, lo scompenso cardiaco (attività prevista in LUMIR); In particolare, si prevede la realizzazione del Libretto Sanitario Elettronico per la gestione sanitaria condivisa (scegliendo tra Libretto Pediatrico, Libretto Geriatrico, etc.), ossia l estensione open source del progetto MOBIDIS (attività prevista in LUMIR). Analisi ad alto livello Pagina 13 di 38

14 3.2 Vincoli applicativi: LUMIR, altri progetti e le applicazioni legacy Applicazioni sanitarie Nella Figura 1 è rappresentato il quadro riepilogativo dei processi di interazione tra vari sistemi applicativi che hanno un impatto diretto sul circuito di assistenza sanitaria Assistito, Medico di Base, Struttura Sanitaria e Regione, e quindi che risultano d interesse per il Progetto LUMIR. Accesso Servizi Refertazione Pronto Soccorso Laboratorio Gestore Repository Amministrativo Repository Amministrativo CUP Utente Reparto Sistema di reporting Cassa ADT (Accettazione) Fascicolo clinico ADT (Dimissione / Trasferimento) Gestore Repository Clinico Repository Clinico Figura 1: Quadro riepilogativo dei processi di interazione Il circuito informativo dovrebbe essere completato con l integrazione al sistema dei Centri Esterni Accreditati, al sistema di gestione dell Assistenza Domiciliare, al sistema Vaccinale, al sistema di Gestione della Protesica e a quello di rilevazione delle Prescrizioni Farmaceutiche (circuito MARNO). Si sottolinea che il repository di raccolta dei dati clinico-amministrativi è l elemento centrale che raccoglie le informazioni provenienti dai sistemi verticali e le offre secondo logiche differenziate in base al profilo d uso e di accesso (controllo di gestione e contabilità analitica/generale, epidemiologia e verifica dei livelli di cura e appropriatezza, indagine epidemiologica, etc.) La situazione delle applicazioni sanitarie in Basilicata Oltre al Progetto LUMIR (RMMG in Basilicata), in Regione Basilicata sono attive e previste altre iniziative nel settore dell informatica medica (BAS-REFER, CUP, Analisi ad alto livello Pagina 14 di 38

15 BASITEL, etc.). Con tali iniziative il Progetto LUMIR si confronterà per creare un unico ambiente favorevole alla sanità elettronica in Basilicata. Dal punto di vista dell infrastruttura hardware, software e di rete, preposta all erogazione dei servizi informatici a livello regionale, il sistema RUPAR assicura attualmente l interconnessione a larga banda di tutte le ASL e le strutture ospedaliere. Associato al sistema di rete, il sistema hardware è caratterizzato da nodi principali dislocati presso ciascuna struttura sanitaria, inoltre ciascun nodo regionale presenta dotazioni Server adeguate a supportare le funzionalità applicative verticali. Sono in corso inoltre attività di ricognizione e di verifica dello stato di adeguatezza delle strutture che verranno potenziate, in virtù di un piano di omogeneizzazione e di uniforme riorganizzazione dei Server sia dal punto di vista architetturale che da quello dell efficienza e delle risorse. Le applicazioni che vengono utilizzate a livello centrale dipartimentale e periferico (cioè presso le AO ed ASL) seguono anch esse una logica territoriale e di rete. Ciò è reso possibile grazie all impianto contrattuale adottato nella maggior parte dei contesti di fornitura, che prevede un rapporto convenzionato tra società produttrici e il dipartimento, il quale a sua volta si fa carico di coprire le esigenze informative delle strutture sanitarie. Ciò offre diversi vantaggi, tra cui principalmente una uniformità sinergica tra le funzioni applicative ed un maggiore controllo della spesa (sia perché direttamente scalata su economie pluri-ente, sia perchè gestita da una entità univoca). Si elencano, di seguito, i principali sistemi applicativi (associati all ambito funzionale coperto) che rispondono attualmente a tale situazione contrattuale: CUP (Centro Unico di Prenotazione delle prestazioni specialistiche); AIRO (sistema di gestione dell Accettazione e Dimissione Ospedaliera, Pronto Soccorso, Ricoveri e Refertazione); Anagrafe Sanitaria; CEA (sistema di gestione dei Centri Esterni Accreditati); Controllo di Gestione e di Produttività Ospedaliera; Gestione degli Invalidi Civili; Protesica; BASMED (sistema per la gestione degli studi medici di MMG). Altre applicazioni rientrano in una analoga gestione territoriale (per ragioni che le hanno viste nascere contrattualmente in modo omogeneo rispetto alle varie aziende sanitarie), come ad esempio l ADI (sistema per la gestione dell assistenza domiciliare in corso di sperimentazione presso 3 ASL regionali), le applicazioni ospedaliere di Contabilità e Magazzino Farmacia, ed altre. Analisi ad alto livello Pagina 15 di 38

16 3.2.3 Componenti software legacy da prendere in considerazione per LUMIR Grazie ai progetti in corso di seguito descritti, sono presenti i seguenti elementi fondamentali per la progettazione del programma LUMIR: Componente Collocazione Descrizione C01 Anagrafica Unica degli Assistiti C02 Anagrafica MMG/PLS dei C03 Repository dei Referti firmati CTR Allineata giornalmente con le anagrafiche dipartimentali; tale base dati anagrafica centralizzata, è carente per quanto riguarda la correttezza e completezza del dato; per questo motivo, la Regione è impegnata a creare sul portale Basilicata.Net una seziona di registrazione per utenti BASREFER, nella quale presentare i dati in possesso della Regione, ed eventualmente dare la possibilità all utente di inviare comunicazione di variazioni o di completamento dei propri dati CTR CTR Per la corretta identificazione ed autenticazione del medico Memorizza i referti firmati, ottenuti principalmente dai Laboratori e il Pronto Soccorso C04 Indice Centrale CTR Contiene i metadata e i riferimenti ai referti laddove sono memorizzati. C05 CUP Regionale Regione Basilicata Il Centro Unico di Prenotazione fornisce all Indice Centrale BASREFER i dati di sintesi relativi ad una prenotazione, senza la necessità di firmare digitalmente alcun documento C06 Basedati Deleghe CTR Il cittadino/medico può richiedere di ricevere via una notifica di referto pronto, presso la propria casella di posta elettronica; i cittadini eventualmente desiderano dare ai propri medici tale opzione C07 FirmaDocumentX C08 InvioDocumentoX C09 Repository di raccolta dei Dati Clinico- Amministrativi Laboratori, Pronto Soccorso Laboratori, Pronto Soccorso CTR Permette l apposizione della firma digitale su un qualsiasi documento elettronico Permette l inoltro del documento precedentemente firmato con FirmaDocumentoX al sistema centrale Elemento centrale che raccoglie le informazioni provenienti dai sistemi verticali SISR e le offre secondo logiche differenziate in base al profilo d uso e di accesso Analisi ad alto livello Pagina 16 di 38

17 Componente Collocazione Descrizione C10 ICAR Identificazione Assistito C11 ICAR Mobilità Sanitaria C12 ICAR Informativa per i Medici di Base C13 ICAR Accesso ai dati Clinico- Amministrativi CTR CTR Utilizzo in rete di funzioni di cooperazione applicativa per effettuare il riconoscimento anagrafico degli utenti iscritti in una qualsiasi Azienda Sanitaria del territorio nazionale Comunicazione, a livello interregionale, degli eventi riguardanti prestazioni e ricoveri per gli assistiti delle aziende sanitarie al fine di consentire il monitoraggio costante dei livelli di mobilità sanitaria ed effettuare tempestivamente le compensazioni sanitarie interregionali di carattere finanziario CTR Comunicazione, a livello interregionale, per MMG/PLS, delle informazioni riguardanti i Ricoveri e le Dimissioni dei propri assistiti CTR Possibilità di accesso, a livello interregionale, da parte di personale medico autorizzato, ai dati Clinico-Amministrativi di un utente ricoverato appartenente ad altra azienda sanitaria Nell ambito della sperimentazione dei sistemi software sviluppati nel progetto LUMIR alcuni componenti legacy descritti saranno coinvolti. La scelta dei sistemi da coinvolgere sarà presa durante lo svolgimento del progetto in accordo con la Regione e secondo gli interessi emersi. Analisi ad alto livello Pagina 17 di 38

18 3.2.4 Funzioni applicative legacy da prendere in considerazione per LUMIR Funzione Collocazione Descrizione F01 CUP Centrale CTR Centro Unico di Prenotazione delle prestazioni specialistiche F02 CUP Periferico ASL, AO Centro Unico di Prenotazione delle prestazioni specialistiche F03 AIRO CTR Sistema di gestione dell Accettazione e Dimissione Ospedaliera F04 AIRO CTR Sistema di gestione del Pronto Soccorso F05 AIRO CTR Sistema di gestione dei Ricoveri F06 AIRO CTR Sistema di gestione della Refertazione F07 Anagrafiche CTR Anagrafe sanitaria F08 CEA CTR Sistema di gestione dei Centri Esterni Accreditati F09 IC CTR Gestione degli Invalidi Civili F10 Protesica CTR Protesica F11 BASMED CTR Sistema per la gestione degli studi medici di MMG Nell ambito della sperimentazione dei sistemi software sviluppati nel progetto LUMIR alcune funzioni applicative legacy descritte saranno coinvolte. La scelta dei sistemi da coinvolgere sarà presa durante lo svolgimento del progetto in accordo con la Regione e secondo gli interessi emersi. Analisi ad alto livello Pagina 18 di 38

19 3.3 Eredità MobiDis Principi MobiDis Il sistema MobiDis (rif. [MOBIDIS]) segue i seguenti principi derivati dalle particolarità del settore che si vuole informatizzare e dai requisiti dei sistemi business in genere. Questi principi sono pienamente condivisibili per il progetto LUMIR: 1. Centralità del paziente: il sistema viene sviluppato intorno al concetto di cartella clinica virtuale associata a ciascun cittadino/paziente registrato nel sistema. Altri sistemi informativi per la sanità enfatizzano altri aspetti come: l organizzazione, l area territoriale o le malattie. 2. Molteplicità di viste sui dati memorizzati nel sistema: consumatori e fornitori di servizi sanitarie possono accedere ai dati in modo personalizzato secondo il contesto di cura in cui si trovano. Per ciascun utente, secondo le sue necessità e il suo scopo di accesso, il sistema permette un accesso limitato ai dati offrendo all utente: a. i dati da lui richiesti, b. in un formato da lui sollecitato, c. secondo le possibilità di visualizzazione del suo display, d. quando lui li vuole. 3. Valore aggiunto per i fornitori di cura: il sistema deve fornire ai fornitori di cura informazioni aggiuntive e quanto possibile complete, conoscenze necessarie per tutte le attività critiche svolte dal fornitore. 4. Informazioni accurate e appropriate: tutti gli agenti coinvolti in attività di cura debbono avere dal sistema solo informazioni accurate, aggiornate e fornite al momento giusto. 5. Interoperabilità e integrazione: il sistema coesisterà con sistemi legacy con cui deve cooperare per sempre o magari per un periodo limitato di tempo; l architettura del sistema deve permettere facile integrazione con tali sistema. 6. Standardizzazione: il sistema MobiDis deve essere allineato con tutti gli standard riconosciuti nei campi sanitario e informatico; questi standard sono importanti per gli scambi di informazione tra i vari componenti del sistema, ma soprattutto per gli scambi tra il sistema ed altri sistemi. 7. Riutilizzabilità: l architettura del sistema MobiDis deve contenere componenti facilmente riutilizzabili a tutti i livelli: dai pattern di supporto alla cura fino ai pattern nella tecnologia informatica. 8. Adattabilità: il sistema deve permettere l adattamento a vari situazioni e a vari contesti. La variabilità delle situazioni riguarda strategie di pianificazione, prestazioni obbligatori e quelle opzionali, risorse, obiettivi del business etc.; la variabilità dei contesti riguarda contesti in cui opererà il sistema (locali, regionali etc.), numero di nodi nell infrastruttura informatica, numero di utenti, numero di transazioni concorrenti etc.. 9. Estendibilità per sviluppi futuri: il sistema MobiDis deve essere progettato per affrontare le esigenze esistente oggi nel mondo della sanità, ma dovrebbe essere aperto per integrare esigenze future in un dominio cosi dinamico come è la sanità. Analisi ad alto livello Pagina 19 di 38

20 10. Sicurezza e privacy: un sistema come MobiDis crea per individui comuni un nuovo tipo di accesso alla sanità; questo accesso impone un approccio speciale per le politiche di sicurezza e privacy delle informazioni. L operatività del sistema è basata sul consento dei consumatori e dei fornitori di cura. 11. Apertura a nuove tecnologie: una caratteristica importante nel progetto MobiDis è la varietà dei dispositivi di accesso al sistema. Questi dispositivi sono sottoposti ad un continuo rinnovamento tecnologico, potendo diventare realtà nuovi paradigmi; il sistema deve affrontare questa sfida ed essere pronto al connettersi con nuovi dispositivi sempre più sofisticati e miniaturizzati Livelli di approfondimento in MobDis Il progetto MOBIDIS ha analizzato, progettato e sperimentato un sistema per garantire agli attori di una cosiddetta Struttura Sanitaria Virtuale (gli operatori sanitari autorizzati e il paziente) l accesso ad una quantità appropriata di dati clinici sul paziente, tenuti costantemente aggiornati. L utente, una volta autorizzato, ha difatti a disposizione tre livelli di approfondimento: A) una sintesi dello stato clinico del paziente, costantemente aggiornata, sotto il controllo del medico di fiducia del paziente Questo livello è estremamente utile ed efficace, e copre la maggior parte dei bisogni ordinari di accesso all informazione clinica. Si ritiene, infatti, che un operatore sanitario remoto, sia alla prima visita che in caso di cooperazione con altri operatori, debba poter disporre di una sintesi controllata dello stato del paziente, facilmente e rapidamente consultabile, anche tramite terminale mobile, in modo da poter affrontare le emergenze (si pensi al Pronto Soccorso) e comunque avere immediatamente un quadro complessivo del paziente stesso. In tale ambito, dovrebbero essere forniti anche tutti i dati relativi ai trattamenti farmacologici seguiti e tutte le informazioni riguardanti le incompatibilità e le allergie del paziente rispetto ai principi attivi. B) un insieme di pagine riassuntive di tutti gli ultimi incontri del paziente con le strutture sanitarie Quando lo ritiene necessario, l operatore può successivamente accedere in modo mirato ad informazioni più dettagliate, guidato sia dal quadro generale ricevuto che dalla visita in corso. C) i dati originali esportati dalle cartelle cliniche delle varie strutture sanitarie coinvolte A questo scopo viene prevista una cartella clinica virtuale, che mette in linea tutte le informazioni cliniche fornite dalle cartelle cliniche disponibili in formato elettronico in diversi sistemi locali, con opportune trasformazioni per ovviare alla diversità di formati e contenuti che non permettono una facile integrazione. La configurazione del sistema permette alla Struttura Sanitaria Virtuale di evolvere verso forme più complesse, ad esempio con l uso di messaggistica standard tra sistemi informativi clinici strutturati, basate su un ampio dizionario dati condiviso. La semplicità d uso e il basso grado di accoppiamento tra i sistemi locali esistenti sono un fattore che faciliterà la penetrazione di questo sistema e la sua evoluzione graduale. Analisi ad alto livello Pagina 20 di 38

21 Nella Figura 2 sono evidenziati i tre modi suddetti con cui l utente accede alle informazioni cliniche personali dell assistibile: Cartelle cliniche ospedaliere Cartelle cliniche specialistiche Maschere ad hoc tramite web Esami diagnostici e altri documenti DATI ORIGINALI Estrazione Estratto sull incontro in XML Catalogazione, notifica Data sets essenziali secondo problema e contesto SERVER DI APPOGGIO Contesto della richiesta Stili XSL parametrici Profilo utente importa dati legge pagina MMG Pagine XML stand-by marca pagina con ignora Adattamento allega pagina ACCESSO DIRETTO Cartella clinica MMG Estrazione Data sets per MMG Esporta in XML Dizionario dati esteso Sintesi stato corrente paziente in XML Catalogazione Pagine XML Adattamento Profilo utente Contesto della richiesta Stili XSL parametrici SERVER PRIMARIO Profilo utente Contesto della richiesta Pagine XML attive Adattamento Pagine web Pagine web Stili XSL parametrici Figura 2: Accesso alle informazioni cliniche personali Tramite le pagine Web residenti nel Server Primario, passate attraverso il vaglio del MMG (informazioni approvate, importate e amalgamate nella propria cartella, e quindi estratte secondo criteri uniformi); Tramite pagine Web estratte in modo uniforme dalle cartelle cliniche originali, e predisposte in un Server di Appoggio; Tramite accesso diretto alle pagine Web ottenute per trasformazione delle cartella cliniche originali, attraverso la Cartella Clinica Virtuale, residenti nei sistemi informativi locali Architettura MobiDis Il sistema MobiDis è inserito nel suo ambiente costituito dal Sistema Sanitario Nazionale o una parte del SSN, cosi come viene presentato nella Figura 3. Questo diagramma introduce il modello architetturale del sistema da realizzare. Il modello descrive il sistema MobiDis con una vista del più alto livello, identificando le componenti principali che partecipano alla creazione e gestione della cartella clinica virtuale (CCV). Analisi ad alto livello Pagina 21 di 38

22 Registri Repository di dominio Servizi di registri Cartella Clinica Virtuale Servizi della CCV Servizi di repository Servizi comuni Bus di comunicazione MobiDis Servizi di integrazione Applicazioni legacy Applicazioni ad hoc Figura 3: Architettura MobiDis Il modello è organizzato in strati di componenti. La localizzazione geografica e il criterio funzionale hanno contribuito alle decisioni di collocare i componenti in uno o l altro degli strati. In questo modello di integrazione del sistema MobiDis con sistemi già esistenti, tutte le applicazioni accedono al sistema utilizzando il bus di comunicazione e attraverso messaggi HL7. Il bus di comunicazione diventa l unico punto di accesso nel sistema. Con i suoi servizi comuni, il sistema MobiDis intercetta i messaggi scambiati con le applicazioni e provvede l inserimento di tutti i servizi necessari (conversioni di formato, verifica di autorizzazioni, normalizzazione etc.). I registri e i repository di dominio utilizzano lo stesso canale di comunicazione e gli stessi servizi, cioè la stessa infrastruttura software. Analisi ad alto livello Pagina 22 di 38

23 4. Il nuovo sistema informativo sanitario della Regione Basilicata 4.1 Fascicolo Sanitario Elettronico per la Regione Basilicata Cos è FSE in LUMIR Il cuore dell architettura della Rete di Medici di Medicina Generale della Regione Basilicata è il Fascicolo Sanitario Elettronico (FSE) dove vengono raccolti informazioni sugli eventi sanitari del cittadino/paziente dalla sua nascita, mano a mano che vengono generati. Il FSE non è un semplice raccoglitore di dati ma è un entità virtuale fornitrice di un insieme di servizi accessibili a tutti quelli interessati e che hanno diritti di accesso a questi servizi. I servizi servono non solo per visualizzare i dati gestiti dall entità virtuale, ma anche di alimentare la stessa entità con informazioni aggiornate attraverso flussi di dati provenienti dalle applicazioni locali o regionali abilitate per comunicare con FSE. In questa accezione FSE si allinea ad un concetto largamente utilizzato, quello di Electronic Health Record (EHR). Nell accezione LUMIR, FSE non è la memoria dei dati operativi e non sarà mai una fonte di nuovi dati. FSE fornisce ad ogni cittadino una registrazione storica dei principali eventi sanitari verificati nell ambito del sistema sanitario. La registrazione è disponibile in formato elettronico ovunque ed in qualsiasi momento a tutti coloro che hanno diritto di accesso al fine di garantire un integrazione socio-sanitaria nell assistenza del cittadino. Il FSE di un cittadino sarà acceduto in vari contesti di cura da vari attori. FSE deve essere in grado di fornire viste personalizzate sui dati del cittadino secondo le necessità e gli obiettivi di ciascun utente. In una vista, la personalizzazione deve fornire i dati desiderati, nel formato desiderato, al momento desiderato, con informazioni sul contesto dello scenario di cura corrente e informazioni riguardanti le eventuale scelte da prendere da parte dell utente. Alcune volte la vista personalizzata può essere incarnata in un libretto sanitario specializzato per i pazienti stessi. In questi casi il libretto può usufruire dall appoggio di una base di conoscenze specifiche per la tipologia del libretto Infrastruttura FSE Nella rete RMMG, FSE non è l unica applicazione, ma deve convivere con altre applicazioni che sono produttori o consumatori di informazioni interscambiate con FSE. In una tale rete FSE deve essere indipendente da altre applicazioni per lasciarle evolvere liberamente una da altra e dall architettura stessa. La soluzione del problema è il disaccoppiamento tra le applicazioni, FSE incluso. Questo disaccoppiamento può essere realizzato attraverso una infrastruttura di comunicazioni tra vari applicazioni che implementa un meccanismo di routing tra produttori e consumatori di informazioni, entità paritetiche in una architettura orientata ai servizi. Il Tavolo per la Sanità Elettronica ha chiamato questa infrastruttura IBSE (Infrastruttura di Base della Sanità Elettronica). L infrastruttura del FSE contiene componenti altamente riutilizzabili che fungono da supporto alle applicazioni di gestione dei dati sanitari. Essa consiste da soluzioni software, definizioni di dati e standard di messaggistica necessarie al FSE Requisiti per l infrastruttura di comunicazione che supporta FSE I principali requisiti adottati per l infrastruttura IBSE in vista della progettazione del FSE sono i seguenti (rif. [TSE]): Analisi ad alto livello Pagina 23 di 38

24 L infrastruttura deve rendere disponibili le informazioni cliniche dell assistito (la sua storia clinica) dove e quando queste informazioni sono clinicamente utili; L architettura complessiva dell infrastruttura deve essere federata e in linea con le moderne architetture tecnologiche e con la cooperazione applicativa prevista dal Sistema Pubblico di Connettività e Cooperazione (SPCoop) e recentemente dal protocollo ICAR (Interoperabilità e Cooperazione Applicativa tra le Regioni); L infrastruttura deve avere un grado di prestazioni elevato in termini di sicurezza e rispetto della privacy e basarsi su un profilo condiviso di sicurezza sia tecnologica che organizzativa; L infrastruttura deve essere intrinsecamente affidabile e deve avere una disponibilità 24x7 (ossia 24 ore al giorno, ogni giorno della settimana); L infrastruttura deve essere pensata in maniera modulare per evitare una rapida obsolescenza del sistema; L infrastruttura deve avere la minima invasività possibile rispetto ai sistemi esistenti e massima disponibilità di integrarli; L infrastruttura deve utilizzare degli standard aperti sia per i protocolli di trasporto che per gli aspetti sintattici e semantici (documenti e dati scambiati tra i sistemi) Componenti dell infrastruttura del FSE L infrastruttura del FSE contiene le seguenti tipologie di sistemi: 1. Sistemi registry (registri) che forniscono e gestiscono informazioni necessarie per l identificazione univoca degli attori nel sistema FSE; questi attori sono sia i pazienti/cittadini che gli operatori sanitari o le varie strutture di cura: ASL, ospedali etc. sono numerose tipologie di registri utili per il FSE 1. Nell infrastruttura del FSE, i registri della stessa tipologia possono essere molteplici secondo l area geografica coperta. Esempi di registri utili sono: a. Registri anagrafe cittadini, registri anagrafe operatori sanitari, registri di localizzazione, etc.. b. Registri contenenti consensi informati dei pazienti fanno parte anche loro dell infrastruttura FSE. c. Registri di metadati che rendono pubbliche informazioni sulla semantica e sui componenti di un dato per ottenere l interoperabilità semantica dei metadati in 1 Registry di elementi e tipi di dati: forniscono un dizionario comune di dati che contengono definizioni di tipi e elementi di dato. Registry di schemi XML: forniscono un repository di versioni di schemi XML che descrivono messaggi, formati di file, e componenti di dato. Registry di XML Stylesheet: forniscono un repository di versioni di XML stylesheet per conversioni tra schemi di dati. Registry di namespace o dominio: forniscono un registry che controlla un domnio o namespace gerarchico. Registry di servizi: fornisce un registry dinamico per servizi web. Registri di modelli: forniscono un repository di modelli di informazioni, relazioni tra dati, e altri informazioni di tipo ontologico. Analisi ad alto livello Pagina 24 di 38

25 vari domini e in vari contesti culturali. Questi registri di solito memorizzano la semantica degli elementi di metadati e mantengono informazioni su qualsiasi estensione locale di essi, fornendo anche mappings ad altri schemi di metadati. d. Registri che forniscono servizi che permettano ad applicazioni fornitrici di servizi di incontrare i consumatori degli stessi servizi. 2. Repository di dominio che gestiscono insiemi di dati clinici appartenenti al dominio del FSE (repository per farmaci, immagini di diagnostico e di analisi di laboratorio). 3. Servizi comuni in particolare di comunicazione per sostenere l interoperabilità tra i vari componenti nell infrastruttura, tra altre infrastrutture e tra l infrastruttura stessa e le applicazioni legaci. 4. Strutture standardizzate di dati e messaggi in grado di abilitare transazioni necessarie alla memorizzazione e allo scambio di informazioni tra FSE e il suo ambiente. Questa infrastruttura permette l implementazione del sistema FSE, un altra componente software che gestisce e memorizza informazioni cliniche mirate al cittadino. Il progetto LUMIR deve identificare i requisiti, l architettura e le soluzioni tecnologiche per l implementazione del Fascicolo Sanitario Personale regionale in conformità con le norme, le leggi e gli standard internazionali e con il progresso registrato nel campo dell ICT (Figura 4). Standard, norme, leggi vincoli vincoli vincoli Requisiti Architettura logica Modello del dominio Modello dei servizi Metamodelli Architettura tecnologica Figura 4. Progetto FSE per LUMIR In questo ambito è sbagliato concepire il FSE come una base di dati (virtuale o meno); invece esso deve essere visto e progettato come un sistema di routing sofisticato. L architettura FSE (architettura logica in Figura 4) viene specificata attraverso il modello di dominio (Reference Model in termini HL7), i servizi forniti e i meta-modelli utilizzati, così come evidenziato nella Figura 4. Questo documento si conclude con la prima bozza di architettura cosi come essa risulta dall analisi del ambiente in cui FSE verrà utilizzato. 4.2 Analisi dei requisiti utente per il FSE Contesto del FSE La Figura 5presenta il contesto applicativo del FSE, formato dagli attori (persone e altri sistemi applicativi) che interagiscono con FSE, dagli elementi base (Registry/Repository), dai Libretti Sanitari del Paziente. Registry/ repository Casa anziani Assistente sociale Libretto paziente/ Analisi ad alto livello Summary Pagina 25 di 38 ASL

26 Figura 5.Contesto del FSE L architettura FSE deve consentire l interazione con altri sistemi che utilizzano la stessa infrastruttura. I servizi FSE devono essere aggiunti ad un infrastruttura esistente che deve fornire la condivisione e la sicurezza degli accessi ai fascicoli sanitari dei diversi pazienti. Questi servizi devono essere accessibili per la comunità degli utenti che compongono il contesto del FSE (Figura 5) per essere utilizzati dalle applicazioni installate presso i fornitori di cura (la cartella elettronica del medico di famiglia, la cartella clinica del ospedale, etc.), presso i pazienti (accesso web ai vari libretti della salute) oppure presso altri enti interessate nell informarsi sulla salute dei cittadini (Ministero della Salute, Comuni, etc.). In questo senso il FSE è lui stesso un infrastruttura di tipo middleware che consente lo sviluppo di sistemi applicativi Requisiti per il FSE I requisiti rispettati dal FSE e dalle applicazioni supportate da esso includono: copertura per l intero ciclo di vita dei cittadini, facilitare l interazioni tra paziente e gli operatori sanitari, assicurare la tracciabilità delle decisioni, potenziare la responsabilità dei fornitori di cura, etc., indipendenza di qualsiasi formato o scelta tecnologica, condivisione dei dati e delle conoscenze attraverso l interoperabilità, utilizzo sia per cure primarie che per quelle acute, integrazione tra vari linguaggi o gerghi utilizzati nel ambito sanitario, Analisi ad alto livello Pagina 26 di 38

27 supporto per la privacy dei cittadini, supporto per dati medico-sanitari: liste tabelle, serie temporali, eventi sanitari, domini di valori, sistemi alternativi di misurazione, etc., supporto per workflow automatici o semi-automatici, supporto per usi secondari quali l educazione, la ricerca, la medicina popolare, compatibilità con sistemi di messaggistica esistenti Principi di progettazione del FSE per LUMIR La progettazione del FSE include la modellizzazione dell informazione, dei servizi e delle regole del business. La modelizzazione si basa sul principio cardine della progettazione, cioè la separazione delle competenze (separation of concerns) che permette la scomposizione di un sistema in parti, ognuna delle quali responsabile di una particolare area di interesse, chiamata concern. Questo principio permette di creare più modelli dello stesso sistema, ognuno di essi organizzato gerarchicamente. Un tale approccio fornisce mantenibilità, estendibilità e flessibilità al sistema Separazione ontologica La separazione ontologica si basa sulla dimensione semantica dell universo da rappresentare. Una separazione fondamentale è tra l Universo dell Informazione e quello Reale in cui il primo è uno specchio parziale, mediato del secondo. Nell Universo dell Informazione si deve distinguere tra i modelli informativi contenenti delle strutture di informazione e i modelli dei vincoli imposti ai primi. Tali vincoli sono derivati dalle regole del business al fine di poter mappare meglio i modelli informativi nel mondo reale. Concetti come Archetype e Templates nello strato dei modelli delle regole del business mappano i modelli informativi in terminologie, classifiche e linee guida. Tenere separati i due livelli permette di distinguere tra i modelli più stabili, quelli di riferimento, e quelli più volatili, delle regole del business. Di conseguenza, nello sviluppo del software di supporto per le attività business si possono separare le attività che progettano ed implementano i database e i meccanismi di supporto infrastrutturale delle attività automatizzate da quelle che sviluppano archetypes, patterns e impostano vincoli (cioè conoscenze). In seguito si presenta l ontologia dei concetti le cui istanze sono gestite dal FSE Obiettivi ontologici di LUMIR Un sistema informativo sanitario territoriale di ampie dimensioni, come uno di natura regionale, deve essere in grado di relazionare un unico sistema di metadati al fine di garantire l integrità semantica del contenuto di ciascuna informazione elementare. Nel caso del progetto LUMIR, i metadati individuati corrispondono in gran parte all HEADER dello standard HL7 CDA. Tale scelta potrebbe non essere analoga a quella fatta in altre regioni oppure in altre nazioni; in tale ambito, si possono immaginare ponti semantici tra questi sistemi eterogenei di metadati, attraverso ontologie condivise e sistemi di registri interoperabili tra i modelli più consolidati. Nasce quindi la necessità di associare una ontologia al sistema di metadati presente nei registri dell infrastruttura LUMIR. Tale necessità, peraltro, deriva nel Analisi ad alto livello Pagina 27 di 38

28 conferire una interpretazione semantica alle informazioni presenti nei registri, che non sia quella implicitamente sottesa dal sistema di metadati scelto. Ad esempio, HL7 ha categorizzato gli eventi del domino sanitario, così come evidenziati nella An Figura Example 7, considerando le Service principali funzionalità Functionality coinvolte; tale classificazione può essere impiegata per individuare una ontologia d alto livello per gli eventi di LUMIR. Ontology Ciò è stato fatto in parte considerando i metadati dell HEADER di HL7 CDA: HealthCareServices PatientAdministration PatientCare PatientReferral Scheduling ObservationReporting PatientReferralRequest PatientInfoRequest CancelPatientReferral InsuranceInformation ClinicalInformation DemographicData GetClinicalInformation servicequality location Properties of the Generic Service Class Figura 6. Eventi HL7 Allo stesso modo, il CEN, nello standard EN 13606, ha disegnato un modello, una parte sintetizzato nella Figura 7, per i concetti espressi negli statement (concetti); tale classificazione può essere impiegata per individuare una ontologia d alto livello per i servizi legati ai documenti sanitari. Analisi ad alto livello Pagina 28 di 38

29 An example Service Message Ontology DD02: Problem DTC12: CarePlan DF03: AllergyState DTH03: Ongoing Problems DTH08: Present Interpretations DD01: Diagnosis DTC08: Diagnostic Test Results DS00: Patient Concept Property Figura 7. Statement CEN Eventi HL7 In generale, quindi, nella visione LUMIR diversi sistemi FSE possono sviluppare i propri metadati, nomenclatori e ontologie. Talune di queste possono essere conformi a standard sviluppati dagli enti di normalizzazione (CEN TC251, ISO TC215, GEHR, HL7, etc.), altre possono essere proprietarie e rese aperte da descrizione semantiche (ISO , Dublin Core). Il mapping tra queste ontologie può avvenire attraverso delle mediazioni semantiche opportune Documenti CDA Per la rappresentazione elettronica delle Unità Documentali sarà utilizzato lo standard HL7 CDA. L iniziativa Clinical Document Architecture (CDA) è stata introdotta in HL7 versione 3 come un modello standard, derivato dal RIM HL7, di scambio di documenti elettronici in ambito clinico con vari livelli di complessità. Il CDA, quindi, rappresenta un file elettronico che specifica la struttura e la semantica di un documento clinico ed ha le seguenti caratteristiche: Persistenza: un documento clinico elettronico HL7 CDA continua ad esistere in uno stato inalterato, per un periodo di tempo definito. Amministrabilità: un documento clinico elettronico HL7 CDA è mantenuto da un organizzazione affidabile. Autenticazione: un documento clinico elettronico HL7 CDA è un insieme di informazioni che possono essere legalmente autenticate. Contesto: un documento elettronico HL7 CDA stabilisce il contesto del suo contenuto. Interezza: l autenticazione di un documento clinico elettronico HL7 CDA è applicata all intero documento e non a porzioni dello stesso. Leggibilità umana: un documento clinico elettronico HL7 CDA è leggibile da un essere umano. Come indicato, il modello CDA è derivato dal RIM HL7 mediante il processo classico di specializzazione della metodologia versione 3, che pone dei vincoli sulle classi del RIM. Analisi ad alto livello Pagina 29 di 38

30 Un documento CDA è codificato in XML, ed è costituito da due grosse componenti: l HEADER e il BODY. L HEADER è compreso fra i tag ClinicalDocument e il tag structuredbody, ed identifica e classifica il documento fornendo informazioni sull autenticazione, gli attori sanitari, il paziente e i fornitori di prestazioni sanitarie. Il BODY contiene le informazioni cliniche e può essere costruito sia in formato destrutturato che in formato strutturato mediante sezioni ricorsive. Il BODY del CDA in formato strutturato contiene le entry che si richiamano agli eventi sanitari che caratterizzano i dati clinici del documento. Tali eventi sono descritti mediante degli atti sanitari. I principali atti sono: Act: registra l informazione sanitaria relativa a cosa è stato fatto, cosa può essere fatto o è intenzione o richiesto che venga fatto. E derivata dalla classe Act del RIM e viene usata quando le altre classi più specifiche non sono appropriate. Observation: rappresenta l informazione sulla natura di una osservazione ed eventualmente il risultato o gli accertamenti correlati. E derivata dalla classe Observation del RIM. Encounter: è un interazione tra un paziente e una struttura sanitaria con il fine di fornire dei servizi sanitari fra i quali una valutazione diagnostica. L Encounter è usato per l ammissione, la dimissione e il trasferimento come per ogni singola visita presso un ufficio sanitario; inoltre, tratta il piano per visite regolari quali cure preventive durante la gravidanza o il controllo di pazienti con malattie croniche. L Encounter è derivato dalla classe PatientEncounter del RIM, usata per rappresentare incontri/contatti correlati o un effettivo singolo incontro. Supply: è usata per rappresentare la fornitura di un materiale da una entità ad un altra. E derivata dalla classe Supply del RIM. Procedure: è usata per rappresentare gli interventi; è derivata dalla classe Procedure del RIM. SubstanceAdministration: è usata per rappresentare eventi relativi a medicazioni, quali la storia delle medicazioni, la pianificazione di medicazioni. Include la richiesta, le istruzioni per il paziente, le raccomandazioni, le promesse, i divieti o i rifiuti di somministrazione di una sostanza e gli effettivi atti si somministrazione di una sostanza. E derivata dalla classe SubstanceAdministration del RIM. Organizer: è usata per creare un arbitrario raggruppamento di altre classi rappresentanti eventi clinici che condividono un contesto. Un Organizer può contenere un altro Organizer ed altre classi rappresentanti eventi clinici attraverso la relazione Component. E derivata dalla classe Act del RIM. L infrastruttura FSE evidenziata in precedenza per LUMIR assicura un meccanismo per conservare i documenti clinici elettronici, per avvertire un eventuale destinatario predefinito della disponibilità di una particolare Unità Documentale, per cercare nell elenco i documenti clinici elettronici relativi ad un paziente e per estrarli dall archivio. I dati clinici contenuti nelle Unità Documentali pervenuti al destinatario non sono necessariamente elaborabili; l infrastruttura FSE di LUMIR assicura, infatti, solo la distribuzione delle Unità Documentali, non la possibilità di interpretare il contenuto; per questo scopo, è necessario utilizzare degli ulteriori standard, come ad esempio HL7 CDA che sarà la specifica di riferimento per le Unità Documentali in LUMIR. Analisi ad alto livello Pagina 30 di 38

31 Con ciò si realizzano le diverse finalità previste, fra cui quelle di utilizzo a fini comunicativi, utilizzo statistico-epidemiologico, utilizzo clinico, realizzazione di un sistema evoluto di Fascicolo Sanitario Elettronico. L infrastruttura FSE di LUMIR prevede l introduzione nella rete enterprise (Internet/intranet) di un Repository logico per l archivio delle Unità Documentali, ed un Registro degli indici dei documenti. Il sistema LUMIR incapsulerà ogni Unità Documentale che si scatena a valle di un evento clinico in un formato coerente allo standard HL7 CDA. Pertanto i dati trattati dal sistema LUMIR (dati di supporto, quali dati inerenti medicinali, prestazioni erogabili, fornitori di prestazioni, e dati clinici, relativi al percorso sanitario delle persone e all assistenza fornita alle persone stesse), verranno quindi incapsulati in file XML conformi allo standard HL7 CDA (dai Proxy Applicativi) e in tale formato verranno dati in pasto all infrastruttura FSE di LUMIR. Esempi di dati del sistema LUMIR sono: referti di laboratorio, visite specialistiche ambulatoriali, dati della diagnostica, dati delle cartelle sanitarie disponibili presso i MMG e i PLS, dati dei ricoveri, lettere di dimissione, SDO, prescrizioni farmaceutiche, specialistiche e di ricovero, vaccinazioni e certificati di malattia, Il vantaggio notevole è l adeguamento semantico dei dati degli eventi clinici, perché questi ultimi avranno sempre l HEADER codificato: ad esempio, se l evento di refertazione produce un PDF firmato destrutturato, questo sarà inserito, così com è (codifica base64) nel documento XML HL7 CDA (nella sezione BODY) ma comunque erediterà un serie di metadati (la sezione HEADER) che, in qualche maniera, lo strutturano (e.g. si riporta il tipo di documento, l autore, il soggetto, etc.); se l evento di refertazione, viceversa, produce già una qualche forma di strutturazione (e.g. un file XML) sarà più semplice il passaggio nel formato HL7 CDA, e quindi l estrazione dei dati componenti il documento. Il risultato è avere due Unità Documentali perfettamente confrontabili sotto l aspetto semantico, anche se originariamente completamente diversi (un PDF narrativo e destrutturato, ed un file XML strutturato), grazie ai metadati dell HEADER. Analisi ad alto livello Pagina 31 di 38

32 4.3 Separazione secondo i punti di vista (viewpoints) Quando le responsabilità nel sistema si dividono tra più componenti è necessario separare tra le informazioni che i processi elaborano e come questi processi comunicano tra loro. Più precisamente questa separazione si può dettagliare in più punti di vista: Funzionale: riguarda le attività business, obiettivi, politiche, contesto del sistema da specificare; Strutturale: riguarda la semantica dell informazione che deve essere memorizzata ed elaborata nel sistema; Comportamentale: riguarda la interazione tra oggetti che comunicano al livello delle loro interfacce; Infrastrutturale: riguarda i meccanismi che supportano la distribuzione geografica del sistema; Tecnologica: riguarda gli aspetti tecnologici dei componenti che compongono il sistema distribuito. Tale suddivisione sarà ripresa nel documento della progettazione di dettaglio del Progetto LUMIR. Di seguito, si riporta il punto di vista d alto livello funzionale, strutturale e comportamentale. Analisi ad alto livello Pagina 32 di 38

33 4.4 Architettura LUMIR La progettazione esecutiva del sistema LUMIR verrà presentata in un apposito documento. Gli aspetti fondamentali di questa architettura sono: orientamento ai servizi federazione dei dati federazione degli aspetti di sicurezza robustezza e tolleranza ai difetti. L architettura riutilizza il pattern dei sistemi business basati sui servizi adattandolo agli aspetti specifici della sanità elettronica, in particolare ai processi di creazione, gestione e utilizzo dei fascicoli sanitari dei cittadini. In seguito la stessa architettura potrà essere utilizzata per implementare applicazioni verticali come i vari libretti sanitari o i processi di cura per le varie malattie. L architettura del sistema business prevede in linee di massima la definizione/adattamento delle seguenti componenti logiche strutturate in più strati di servizi (Figura 8): A. Strato dell infrastruttura di comunicazione 1. Servizio di comunicazione in una rete composta da nodi corrispondenti a tutti gli operatori sanitari (i MMG/PLS, gli specialisti, i Laboratori, le Aziende Ospedaliere, etc.) basato su vari servizi di basso livello necessari nella comunicazione: servizi di integrazione dati, scambio di documenti (file), messaggistica sincrona ed asincrona (gestione code), orchestrazione di servizi etc. La comunicazione avviene utilizzando un protocollo standard: 2. Servizio di protocollo nazionale per l interoperabilità (ICAR sopra SPCoop). B. Strato dell infrastruttura di servizi condivisi: 3. Servizi per l indicizzazione, routing e persistenza delle informazioni, relative agli eventi sanitari individuali su scala regionale, composto da: 3.1. Un gruppo di Repository (quelli del Centro Tecnico Regionale e delle sedi periferiche) per la conservazione e l accesso alle informazioni relative agli eventi sanitari conformemente agli standard sintattici/semantici internazionali (es. lo standard HL7 CDA release 2.x); 3.2. Un gruppo di Registri (quello del Centro Tecnico Regionale e delle sedi periferiche) per la pubblicazione e l indicizzazione delle informazioni relative agli eventi sanitari Un Broker di oggetti business per la localizzazione/routing e trasporto di entità business del sistema informativo. 4. Servizi di sicurezza, privacy e di policy di accesso sicuro attraverso firma digitale ed autenticazione forte (standard CNS). 5. Servizi di notifica per la realizzazione di pattern diversificati di comunicazione compresa quella asincrona. 6. Servizi di dati per la realizzazione delle conversioni tra vari data-set e per la strutturazione/destrutturazione dei dati compositi. Analisi ad alto livello Pagina 33 di 38

34 7. Servizi di transazioni e auditing per la gestione delle transazioni (commit/rollback) distribuite. C. Strato dei servizi business (applicativi) 8. Servizi normalizzati e integrati, quali la prescrizione, refertazione, etc., provenienti da applicazioni legacy o non legacy. Questi servizi sono possibili componenti di complessi processi sanitari online. Processi utente Servizi di collaborazione Servizi di sicurezza e privacy Strato applicativo LIVELLI Modelli/ Ontologie Repository / Registry InfoBroker Integratore di servizi Processo business Servizi di pubblicazione e localizzazione Servizi di supporto per l interoperabilità sintattica e semantica Hub di servizi medico - sanitari Infrastruttura di comunicazione (ICAR/SPCoop) Integratore di servizi Strato del business Strato d interconnetività (SOA) Strato di normalizzazione dei servizi Strato dei servizi del business Basi dati Applic.. legacy Applic.. Applic.. Applic.. legacy legacy legacy Componenti Business Applic.. legacy Strato dei componenti software (sistemi legacy ) Figura 8: Architettura business del sistema LUMIR La Figura 9 mostra schematicamente gli strati di servizi che compongono il Sistema di Sanità della Regione Basilicata derivati dall architettura di riferimento. L accesso degli utenti al FSE si realizza utilizzando applicazioni web eseguite dal browser oppure applicazioni web realizzate ad hoc per il sistema sanitario regionale integrato. Nel caso del browser l accesso avviene tramite un portale della regione Basilicata. Il sistema FSE può comunicare con applicazioni legacy in quale caso tra il sistema e le applicazioni si interpongono dei componenti software (integratore legacy o wrapper) in grado di armonizzare i servizi dell applicazione con i servizi richiesti dal sistema. Il FSE è costituito da un software distribuito (Cartella clinica virtuale) che realizza i suoi compiti utilizzando un infrastruttura di servizi. Questi servizi sono servizi condivisi che assicurano prestazioni specifiche come: notifiche, rispetto della privacy, sicurezza dei dati e delle operazioni, transazioni, auditing etc. Questi servizi si inseriscono automaticamente nello scambio di informazioni che avviene tra le varie applicazioni. Questo scambio si basa su dei servizi di messaggistica che sfruttano Analisi ad alto livello Pagina 34 di 38

35 protocolli standard per comunicare in rete. In fine, il contenuto di dati dei messaggi viene prelevato attraverso servizi specifici per l accesso ai repository e/o database. Browser web 5. presentazione Strato di presentazione Portal web 4. logica dell applicazione 3. clienti virtuali Integratore legacy Cartella clinica virtuale Motore di query Cartella clinica virtuale Logica dell applicazione Cartella clinica virtuale Applicazione sanità Cartella clinica virtuale Servizi di comunicazione sicura a larga scala 2. servizi di back-up Servizio di notifica Servizio di identità (privacy) Servizio demografico Servizio di sicurezza Servizi di auditing Servizi di comunicazione locale (servizi di messaggistica) 1. persistenza DB legacy Persistenza Figura 9. Architettura a servizi del sistema LUMIR Analisi ad alto livello Pagina 35 di 38

36 Figura 10: Mapping dell architettura a servizi nell architettura business La Figura 10 presenta come si mappa l architettura a servizi nell architettura di riferimento. La Figura 11 invece introduce un altra vista ancora sul sistema sanitario regionale, integrato fornendo una strutturazione geografica dei componenti del software. Sono stati individuati tre ambienti: locale, aziendale e regionale in cui vengono installati i componenti software del sistema. Analisi ad alto livello Pagina 36 di 38