I WorkShop del Tavolo Permanente di Sanità Elettronica

Transcript

1 I WorkShop del Tavolo Permanente di Sanità Elettronica Infrastruttura nazionale del Fascicolo Sanitario Elettronico (InFSE) L infrastruttura regionale del progetto MEDIR Gianmaria Mancosu gimancosu@regione.sardegna.it

2 Sanità Elettronica in Sardegna Le principali iniziative della RAS Rete dei MMG/PLS e Fascicolo Sanitario Elettronico (MEDIR) Anagrafe Regionale Assistibili (AnagS) Progetto Rete di Telepatologia Oncologica (RTP) Progetto Laboratorio Unico d Analisi (SILUS) Sistema Informativo Sanitario Integrato Regionale (SISaR) Progetti infrastrutturali Distribuzione Carta Nazionale dei Servizi (SAX-I) Sistema Pubblico di Cooperazione Applicativa (ICAR) Rete Telematica Regionale (RTR) 2

3 Il Centro Servizi Regionale - CRESSAN 3

4 Progetto MEDIR FSE Obiettivi Supportare l efficienza delle cure primarie attraverso l integrazione in rete dei Medici di Medicina Generale, Pediatri di Libera Scelta e gli altri Operatori Sanitari del sistema al fine di agevolare il processo di continuità dell assistenza, anche attraverso lo sviluppo di appropriate forme associative Supportare l integrazione dei servizi sanitari e sociali nell ambito del territorio al fine di agevolare i processi di integrazione tra presidi, professionisti, attività sociali degli Enti Locali nell ambito delle attività proprie del distretto definite dalla Programmazione Regionale Favorire la riorganizzazione e la razionalizzazione delle strutture e dei presidi sul territorio Consentire a ciascun Assistito, ovunque si trovi, di poter consultare tutta la sua storia sanitaria collegandosi al portale del sistema 4

5 Progetto MEDIR FSE Utenti del sistema coinvolti MMG: (solo il 60% di questi utilizzano alla data strumenti informatici) PLS: 230+ (solo il 60% di questi utilizzano alla data strumenti informatici) GM/GT: 230+ Medici Ospedalieri e Igiene Pubblica: Specialisti ambulatoriali: 680+ Farmacie: 520+ Cittadini: Stato di avanzamento Da settembre 2009 è iniziato il beta-test Aziende sanitarie coinvolte: 2/11 (Sassari e Sanluri) Operatori coinvolti: circa 20 MMG/PLS SW Cartella clinica integrato: 1/6 (Fimesan) 5

6 Sistema Informativo Sanitario RAS 6

7 Sistema Informativo Sanitario RAS 7

8 Sistema Informativo Sanitario RAS Integrazione: processo di prescrizione specialistica 8

9 Sistema Informativo Sanitario RAS Coinvolgimento degli stakeholders sui tavoli istituzionali Processi Sanitari Modelli dei dati, codifiche e vocabolari Regole di autorizzazione Gestione del consenso Livello Tecnologico Standard e protocolli di ultimissima generazione (spesso in corso di definizione/adozione) Disponibilità e Integrabilità Infrastrutture e servizi regionali (PDD, Anagrafi assistititi) Integrabilità dei sistemi terzi 9

10 Sistema Informativo Sanitario RAS Scelte per garantire la interoperabilità nazionale Coordinamento del DIT e coinvolgimento del Ministero della Salute Standard di riferimento per la realizzazione del sistema FSE Registry Repository: IHE-XDS Condivisione dei documenti CDA 2.0 HL7 V. 3.0 (referti, prescrizioni, PS, SSI, etc.) Utilizzo del sistema pubblico di cooperazione applicativa realizzato compliant con gli standard CNIPA (openspcoop realizzato nell ambito del progetto nazionale ICAR) Accesso degli OS al sistema attraverso la CNS Firma digitale sui documenti xml signature Politica di accesso al sistema nel rispetto della Privacy Sistema per la gestione dell identificazione federata: SAML 10

11 Attività di standardizzazione Rappresentazione Clinical Knowledge Definizione, Adozione e Implementazione delle specifiche tecniche HL7-CDA 2.0 per il set completo dei documenti clinici Prescrizioni (farmaceutiche, specialistiche, ricovero, ) Refertazioni e Report (laboratorio, dimissioni, pronto soccorso,.) Documenti di supporto (accettazione, SDO, prenotazione,..) Patient Summary e Scheda Sanitaria Individuale Consenso Generale e Revoca, Consenso puntuale (restrizioni di visibilità) e Assenso Puntuale (presenza del paziente) 11

12 Infrastruttura di Base della Sanità Elettronica Il Tavolo di Sanità Elettronica ha approvato il documento TSE-IBSE-Strategia Architetturale per la Sanità Elettronica in cui si indica una strategia architetturale di riferimento per il sistema nazionale della Sanità Elettronica. La realizzazione di un infrastruttura di base che coinvolga gli attori primari è un prerequisito per ogni sistema di Sanità Elettronica Principali requisiti IBSE: Disponibilità delle informazioni cliniche Architettura federata Sicurezza e Privacy Affidabilità/Disponibilità dell infrastruttura Struttura modulare Integrazione con i sistemi esistenti Uso di standard aperti 12

13 IBSE: Architettura generale / 1 13

14 IBSE: Architettura generale / 2 14

15 FSE Organizzazione Topologica L FSE viene realizzato senza duplicazione di dati, che rimangono nella responsabilità degli enti che li producono ma che possono essere acceduti, di volta in volta, secondo le autorizzazioni previste. Nella figura sono rappresentate le ASL/Regioni ed all interno di queste l InfoBroker Individuale Sanitario (IBIS). Ogni ente, sia essa Regione, ASL, AO o altro, fornisce il punto d'ingresso alla rete del Sistema Sanitario Nazionale attraverso l'accessgateway (AG). 15

16 IBSE: Schemi di deployment 16

17 Document Registry Services La realizzazione del registro degli eventi clinici prevede l utilizzo delle specifiche ebxml seguendo le linee guida dettate del TSE, nonché le specifiche IHE-XDS. Un registro ebxml contiene istanze di metadati che descrivono i contenuti del repository o di altri metadati. Attraverso i metadati è possibile indicizzare e quindi recuperare i contenuti ad essi associati. Cross-Enterprise Document Sharing (IHE-XDS) è un profilo per ebxml che nasce dall esigenza di dover condividere documenti medico/clinici all interno dei vari domini sanitari. Definisce anche le transazioni che possono avvenire all interno di un dominio sanitario. Il Document Registry, raccoglie e indicizza XDS Document (metadati) che rappresentano documenti di tipo CDA. Ogni documento di tipo CDA è una struttura XML è possibile utilizzare un processo di trasformazione XSLT per creare tutte le informazioni dei metadati XDS estraendole o generandole dalle informazioni cliniche contenute nei documenti stessi Attraverso le interfacce esposte dal Document Registry è possibile aggiungere nuove entry nell indice, eliminarle, renderle obsolete, riattivarle (interfaccia di LifecycleManager) interrogare tali entry (interfaccia di QueryManager) 17

18 IHE-XDS: Attori e transazioni Il profilo IHE-XDS prevede inoltre diversi attori: Il Document source che crea i documenti e li invia al repository Il Document consumer che richiede documenti Il Patient Identity Source che assegna l identificatore univoco degli assistiti e mantiene le informazioni anagrafiche Patient Identity Source Patient Identity Feed Document Registry Query Documents Document Consumer Register Document Set Document Source Provide&Register Document Set Document Repository Retrieve Document 18

19 Progetto MEDIR FSE Il Fascicolo Sanitario Elettronico della RAS La Regione Autonoma della Sardegna ha implementato un FSE nel rispetto di quanto stabilito dal DIT: L architettura utilizzata implementa il profilo di integrazione IHE-XDS Viene utilizzato CDA HL7 v. 3.0 Il profilo di integrazione prevede due componenti principali: Registry: questo si occupa di mantenere le informazioni principali (metadati) sui documenti sanitari archiviati sui repository in modo tale che questi siano recuperabili dal cittadino e dagli Operatori Sanitari autorizzati Repository: si occupa di mantenere i documenti sanitari che vengono generati 19

20 Progetto MEDIR FSE Organizzazione topologica Domino Centrale Regionale (FSE metadata Registry) 11 Domini Aziendali Distribuzione di informazioni cliniche (affinity domains) Federazione di domini e informazioni 20

21 Progetto MEDIR FSE Schema di deployment custom Infrastruttura di base MEDIR Document Source Provide Document Transazioni Document Registry Register Document Document Repository Publ ish Notification Broker Query Registry Retrieve Document Get Notifications Document Consumer 21

22 Progetto MEDIR FSE Utilizzo del sistema pubblico di cooperazione applicativa 22

23 MEDIR FSE - rappresentazione clinical knowledge Il CDA Il CDA è composto al livello più alto dal Header: utile per dare informazioni al mittente del documento o a chi lo deve leggere una volta generato. Include informazioni come: Identificativo del documento Identificativo del paziente Tipologia del documento Data del documento Struttura che tiene in custodia il documento originale Operatore Sanitario che lo ha generato Operatore che lo ha firmato Body: contiene le informazioni clinico sanitarie del documento e questa sezione può essere struttura e non strutturata 23

24 MEDIR FSE - Architettura Avanzata Prescrizioni Erogazioni Refertazioni Repository Identity Security e-health Services Bus PdD SPCC PdD PdD PdD IPSE,MEF, 24

25 MEDIR FSE - Tecnologie SOA Framework SOAP 1.1 IHE XDS HL7-CDA2 Prescrizione Refertazione Security Component.NET WCF - WSIT Business Process.NET Framework Biztalk 2006 Event Notification P&S FSE Query FSE Insert SOAP Message Security - XML Encryption - XML Signature - WS-Addressing - X.509 Certificate Token Profile SAML Token Profile Secure-Conversation e-health Services Bus WS-* ebxml Reg/Rep 3.0 Database Business Component.NET WCF Registry Repository Identity Mgm Data Access Logic Component SQL Server Message Box 25

26 MEDIR FSE Servizi di integrazione Integration Services Punto di ingresso al sistema, da applicativi client interni ad un dominio di servizi, o attraverso porta di dominio da servizi deployati in altri domini. Lo strato di Integration Services (Gateway, Orchestration, Messaging, Message Transformation, Service Locator, Service Agent), realizza l infrastruttura per servire le richieste di servizio provenienti dai sistemi terzi e dal portale web. Funzioni di Access Gateway dell architettura IBIS/IBSE, esponendo i servizi di integrazione di MEDIR tramite web service. Operazioni che consentono ai sistemi chiamanti di realizzare le transazioni previste dai requisiti funzionali. manipola le richieste per veicolarle verso i servizi di business effettua, se necessario, un routing verso gli altri domini realizza un sistema d integrazione basato sullo scambio di messaggi (Messaging System) La logica applicativa dei servizi di gateway viene realizzata integrando le funzionalità della componente di orchestrazione, che realizza la logica di composizione attivando i servizi applicativi secondo le regole di business definite Alcune funzionalità (orchestration, message tranformation, routing, etc.) di questo strato sono realizzate attraverso i servizi offerti dal middleware di integrazione Biztalk Server 2006 di Microsoft. 26

27 MEDIR FSE Servizi di integrazione Gateway Services Disaccoppia le dinamiche di chiamata dei servizi dalla loro locazione e implementazione. Interfacce web service ben definite e standardizzate. Alto grado di interoperabilità e garanzia di minimo impatto per i sistemi terzi. Le classi di servizi di gateway si specializzano solo quando è necessario introdurre uno specifico contratto di servizio, estendendo un'unica classe base astratta, che implementa la logica e il flusso di controllo comune. I.E., nel framework di sicurezza la logica e il flusso di controllo per l'autenticazione della richiesta di servizio sono centralizzati (funzionalità di intercept e factory centralizzata.net con Windows Comunication Foundation) Interfacce permettono l autenticazione degli operatori sanitari mediante l utilizzo di smart card CNS/CIE X.509 Token Profile 1.1, invocazione servizi di Security Token Service (STS), rilascio token SAML 1.1 validi all interno del dominio federato MEDIR. Servizi applicativi Medir secondo WS-Security 1.1 e SAML Token Profile 1.1 Servizi applicativi possono usufruire del token SAML rilasciato per condividere il contesto di sicurezza tra i differenti servizi o layers applicativi. In una fase transitoria, Token SAML anche attraverso l utilizzo di autenticazione debole (username), nel rispetto della specifica WS-Security UsernameToken Profile 1.1. La richiesta sul ServiceGateway, è costituita, dove applicabile, da un messaggio basato sugli standard definiti dal profilo IHE-XDS e HL7v3. 27

28 MEDIR FSE Esempio di erogazione Centro Servizi Sanitari Regionale MMG Medico Prescrittore Indice Fascicolo Sanitario Elettronico Assistito Medico Specialista Dominio Federato servizi MEDIR ASL Cagliari ASL Sanluri Repository Documenti Clinici Repository Documenti Clinici 28

29 MEDIR FSE Esempio di interrogazione Centro Servizi Sanitari Regionale MMG Medico Prescrittore Indice Fascicolo Sanitario Elettronico Interroga FSE Assistito Medico Specialista Dominio Federato servizi MEDIR ASL Cagliari ASL Sanluri Interroga FSE Repository Documenti Clinici Repository Documenti Clinici 29

30 Grazie per l attenzione Riferimenti: Gianmaria Mancosu gimancosu@regione.sardegna.it 30