IBSE Infrastruttura di Base della Sanità Elettronica

Transcript

1 IBSE Infrastruttura di Base della Sanità Elettronica PATIENT SUMMARY Definizione dei contenuti del Patient Summary e relazioni con la Scheda Sanitaria Individuale dell'assistito Documento di lavoro: materiale confidenziale ad esclusivo uso interno. Non distribuire né citare senza assenso esplicito della struttura responsabile. Pagina 1 di 64

2 Indice 1 Status del documento Note di lettura Guida alla lettura Documentazione di Riferimento Obiettivi e contesto di riferimento del documento...8 SEZIONE I. DEFINIZIONE CONCETTUALE DI PATIENT SUMMARY E RELAZIONI CON LA SCHEDA SANITARIA INDIVIDUALE Ricognizione dei concetti di PS in ambito internazionale Standard tecnici di riferimento Concetti di PS nelle buone pratiche internazionali Contesto normativo nazionale Definizione Patient Summary Obiettivi del PS Principali casi d uso Ciclo di vita dei documenti Matrice delle classi informative per casi d uso del PS...16 SEZIONE II. STRUTTURAZIONE DEL DOCUMENTO PATIENT SUMMARY IN CCD Obiettivi Header Patient Summary Root del documento:<clinical Document> Dominio: <realmcode> Identificativo CDA2: <typeid> Identificativo CDA2: <templateid> Identificativo documento: <id> Versione del documento: <setid> e <versionnumber> Codice Documento:<code> Riservatezza del documento:<confidentialitycode> Data di creazione documento:<effectivetime> Lingua e Dominio: <languagecode>...28 Pagina 2 di 64

3 Destinatario: <recordtarget> Custode: <custodian> Autore e autenticatore: <author> e <legalauthenticator> EventoClinico: <documentationof> e <serviceevent> Destinatario del documento: <informationrecipient> Contatti: <guardian> e <participant> Body documento Patient Summary Allergie e reazioni avverse Terapie farmacologiche croniche o attuali rilevanti Lista problemi rilevanti e diagnosi codificate Accertamenti diagnostici rilevanti ai fini delle patologie riportate Controlli pianificati a percorsi concordati per patologie croniche o particolari Vaccinazioni Partecipazione a trials clinici Visite Parametri di monitoraggio (pressione, dati antropometrici, ecc.) Assenso/dissenso donazione d organi Consenso/diniego accanimento terapeutico Stato corrente del paziente Potenziali rischi del paziente in relazione alla storia dei membri familiari Vita sociale (es. fumatore, etc.) BIBLIOGRAFIA...57 Appendice A Elenco OID...58 Appendice B - Composizione dello IUD...59 Appendice C Cenni sui meccanismi di Firma Digitale XML-Signature...61 Appendice D - Esempio di documento Patient Summary...63 Appendice E - Prescrizione casi d uso...64 Pagina 3 di 64

4 Status del documento Questa versione: Titolo: Patient Summary Versione: Stato: BOZZA Autore/i: Daniela Berardi, Lorenzo Cerulli, Katia Colantonio Ente/Società: Innovazione Italia Responsabile: Katia Colantonio Ente/Società: Innovazione Italia Contributore/i: Giuseppe Frieri, Mariano Paolizzi, Valter De Giorgi, Francesco Caccavo, Leandro Pesca,Italo Paolini, Gruppo CNR Regione Basilicata Ente/Società: Regione Abruzzo, Regione Sardegna, Regione Puglia, FIMMG Gruppo informatico, Regione Basilicata Emesso: Ente/Società: Storia delle revisioni: Versione Status Data Descrizione Modifica 1.0 BOZZA 07/ 06/2007 Prima versione BOZZA rilasciata in discussione 2.0 BOZZA Release interna 3.0 BOZZA 06/07/2007 Prima ipotesi di concetti e contenuti PS BOZZA 24/07/ BOZZA 03/08/2007 Prime ipotesi di mapping classi informative per casi d uso e prime ipotesi di strutturazione in CCD di alcune classi informative Strutturazione dell header in CCD, e inizio definizione body (sezione Allergie e reazioni avverse ) Pagina 4 di 64

5 Note di lettura Nella definizione dei requisiti, delle specifiche e delle regole descritte nei documenti sono utilizzate le parole chiave DEVE, NON DEVE, OBBLIGATORIO, VIETATO, DOVREBBE, CONSIGLIATO, NON DOVREBBE, SCONSIGLIATO, POTREBBE, OPZIONALE che devono essere interpretate in conformità con RFC In particolare: DEVE, OBBLIGATORIO, NECESSARIO (MUST, REQUIRED, SHALL) significano che la definizione è un requisito assoluto, la specifica deve essere implementata, la consegna è inderogabile. NON DEVE, VIETATO (MUST NOT, SHALL NOT) significano che c è proibizione assoluta di implementazione di un determinato elemento di specifica. DOVREBBE, CONSIGLIATO (SHOULD, RECOMMENDED) significano che in particolari circostanze possono esistere validi motivi per ignorare un requisito, non implementare una specifica, derogare alla consegna, ma che occorre esaminare e valutare con attenzione le implicazioni correlate alla scelta. NON DOVREBBE, SCONSIGLIATO (SHOULD NOT, NOT RECOMMENDED) significano che in particolari circostanze possono esistere validi di motivi per cui un elemento di specifica è accettabile o persino utile, ma, prima di implementarlo, le implicazioni correlate dovrebbero essere esaminate e valutate con attenzione. PUÒ, OPZIONALE (MAY, OPTIONAL) significano che un elemento della specifica è a implementazione facoltativa Le parole chiave nel testo sono segnalate in maiuscolo e neretto (es. DEVE ). 1 Vedi: Pagina 5 di 64

6 146 3 Guida alla lettura La tabella seguente descrive i contenuti delle sezioni che compongono il documento: Sezion e Titolo 1. Status del documento 2. Note di lettura Tabella 1 Guida alla lettura Descrizione Descrizione dei principali metadati del documento (titolo, autori, responsabili), lo stato del documento, e la storia delle revisioni. Richiami sull uso delle parole chiave secondo RFC Guida alla lettura Questa sezione Documentazione di Riferimento Obiettivi e contesto di riferimento del documento Elenco della documentazione ritenuta prerequisito per la comprensione del documento. Obiettivi del documento Le sezioni più complesse del documento riportano al loro inizio, in corsivo, una descrizione sintetica dei contenuti. Pagina 6 di 64

7 Documentazione di Riferimento Di seguito è riportato un elenco della documentazione ritenuta prerequisito per la comprensione del presente documento. Sono inoltre un ulteriore prerequisito CONSIGLIATO 2 i capitolati regionali del Progetto Medicina Generale Emesso da TSE TSE DIT DIT DIT FIMMG HL7 DIT ASTM7HL 7 Tabella 2 Documentazione di riferimento Documento Nome File Data Riferimento Una Politica per La Sanità Elettronica. Strategia architetturale per la Sanità Elettronica Linee guida per gli standard tecnologici IBIS a livello regionale Tutti i documenti di progettazione condivisa Allegato C Data Set Rete MMG Accordo Collettivo Nazionale per la disciplina dei rapporti con i medici di siglato 2005 Implementation guide CDA2 - CCD GLOSSARIO HL7 Implementation Guide: CDA Release 2 Continuity of Care Document (CCD) TSE-Politica Condivisa per la Sanità Elettronica.pdf TSE-IBSE- Strategia_architett urale-v DEF.pdf TSE-IBSE-Linee_ guida_per_gli_stan dard_tecnologici_ib IS_a_livello_region ale-v01 00-BOZZA- 01.pdf vari Allegato C dataste di riferimento v.1.0.doc Accordo collettivo nazionale.pdf - CCD.06Dec2006_In fo_ballot2.doc - IBSE Glossario BOZZA 03 - CCD.06Dec2006_In fo_ballot_2.doc 31/03/ /03/ /11/2006 Alla data corrente 07/06/ ronica.gov.it ronica.gov.it DIT del 07/11/ ronica.gov.it Prot. DIT/1884/05/III Livelli di requisito (RFC2119) CONSIGLIATO OBBLIGATORIO OBBLIGATORIO OBBLIGATORIO OBBLIGATORIO CONSIGLIATO ronica.gov.it ronica.gov.it ronica.gov.it/egr oupware CONSIGLIATI OBBLIGATORIO OBBLIGATORIO 2 Questi, ovviamente, sono prerequisito OBBLIGATORIO per il fornitore direttamente coinvolto. Pagina 7 di 64

8 Obiettivi e contesto di riferimento del documento Questo documento segue il documento Strategia architetturale per la Sanità Elettronica approvato dal Tavolo di lavoro permanente per la Sanità Elettronica (TSE), i capitolati Rete MMG emessi dal DIT e recepiti dalle Amministrazioni Regionali e il documento Linee guida per gli standard tecnologici IBIS a livello regionale e contribuisce, insieme a documenti successivi, a definire il documento di Patient Summary. Esso ha due obiettivi principali: 1. proporre una definizione del concetto di Patient Summary (PS) in riferimento al Fascicolo Sanitario Elettronico e ai documenti clinici che esso contiene. 2. definire i dati e le classi di informazioni che il Patient Summary deve contenere, al fine di garantire al meglio efficienza, efficacia e continuità della cura nei diversi casi d uso che le Regioni decideranno di implementare. 3. definire la struttura del documento del Patient Summary a partire dalle specifiche CCD La definizione che viene formulata nel presente documento deriva dall insieme dei contributi ricevuti dalle Amministrazioni Regionali che si sono candidate alla definizione del Patient Summary 3 e tiene conto dei seguenti presupposti: - contributi ricevuti dalle Amministrazioni Regionali medesime - il contesto normativo di riferimento per la collocazione del documento - le buone pratiche internazionali - gli standard tecnici di strutturazione documentale E implicito che documento di PS che verrà definito sarà un documento creato e mantenuto dal MMG / PLS principale destinatario dell intervento progettuale Rete dei Medici di. Il Patient Summary generico conterrà un sottoinsieme informativo derivante dalla Scheda Sanitaria Individuale del paziente prevista negli Accordi Collettivi Nazionali della medicina di base, già prevista nei capitolati emessi dalle Regioni per il progetto in oggetto. A tal fine il gruppo di lavoro che ha redatto il presente documento ha definito un insieme abbastanza ampio di classi informative che in linea di massima corrisponde all insieme strutturato di informazioni potenzialmente contenute in una Scheda Sanitaria Individuale (e dunque nei software correnti di c.d. Cartella Clinica presenti presso gli studi medici). 3 Abruzzo, Basilicata, Puglia e Sardegna Pagina 8 di 64

9 La scelta su eventuali classi informative da omettere o ridurre sarà in carico al gruppo di lavoro allargato in funzione dei diversi casi d uso previsti ed in funzione della concertazione che avverrà in ambito regionale con le associazioni di categoria. Come tutti i documenti prodotti nell ambito della progettazione condivisa, rientra nelle attività di ambito condiviso previste nelle schede tecniche definite negli Accordi di Programma Quadro e costituiscono linee guida per l implementazione del progetto finalizzate alla costruzione dell Infrastruttura di Base della Sanità Elettronica a livello regionale e alla predisposizione delle basi di interoperabilità del Fascicolo Sanitario Elettronico e dei relativi documenti informatici a livello interregionale. Tale documento DEVE costituire la base della proposta nazionale nell ambito della Call for proposal CIP ehealth Large Scale Pilot di tipo A relativamente al Patient s Summary. Questo documento è strutturato in due principali sezioni: 1. la prima sezione è di definizione contettuale del documento Patient Summary, contiene i principali i casi d uso e le principali classi informative, mappate sul CCD/CCR, che si intendono utilizzare; 2. la seconda sezione è invece relativa alla strutturazione del documento informatico in CCD 212 Pagina 9 di 64

10 SEZIONE I. DEFINIZIONE CONCETTUALE DI PATIENT SUMMARY E RELAZIONI CON LA SCHEDA SANITARIA INDIVIDUALE Ricognizione dei concetti di PS in ambito internazionale Standard tecnici di riferimento Nel panorama internazionale le organizzazioni di maggior riferimento, HL7 e IHE, sui diversi concetti di patient summary orientati alla continuità della cura stanno convergendo nella strutturazione di un formato di CDA2 rivisitato denominato CCD - Continuity of Care Document. La strutturazione del CCD è il risultato di una collaborazione tra HL7 e ASTM (American Society for Testing and Materials) Committee E31 on Healthcare Informatics. Esso deriva dallo standard CCR - Continuity of Care Record 4, promosso dalla ASTM, secondo HL7-CDA2. In sintesi il CCR è un insieme di dati rilevanti che descrivono lo stato di salute presente e passato di un paziente e le cure e i trattamenti cui si è sottoposto. Tali dati coprono informazioni di tipo amministrativo, demografico e clinico. Il CCR costituisce un modo per un professionista sanitario di aggregare tutti i dati di un paziente, che ritiene rilevanti e di inviarli ad un altro professionista sanitario al fine di garantire la continuità della cura. Pertanto, scopo primario del CCR è fornire un istantanea sul quadro clinico, demografico e amministrativo di uno specifico paziente. 4 ASTM E Standard Specification for Continuity of Care Record (CCR) Pagina 10 di 64

11 Concetti di PS nelle buone pratiche internazionali Al fine di verificare i concetti di PS presenti in ambito internazionale, i principali autori, le classi informative e le modalità tecniche di strutturazione dei documenti è stata effettuata un analisi sulle principali buone pratiche internazionali. Di seguito, nelle tabelle 1 e 2, vengono illustrati i diversi approcci alla strutturazione del Patient Summary che rappresentano lo stato dell arte a livello internazionale Tabella 1 Patient Summary (informazioni di base) Tabella 2 Patient Summary (storia clinica ed altri dati) In sintesi è possibile affermare che i Patient Summary in fase di sperimentazione a Pagina 11 di 64

12 livello internazionale condividono alcuni campi: Informazioni di base ed attuali: o o o Dati anagrafici del paziente, del medico che ha redatto il Patient Summary e di un ulteriore contatto del paziente in casi di emergenza Allergie a farmaci o ad altre sostanze, rischi immunitari, intolleranze. Negli USA per ciascuna reazione allergica viene indicata la causa e la data dell ultima reazione. Medicinali prescritti e in fase di somministrazione al paziente. In particolare, in Svezia si concentra l attenzione su: nome farmaco, dose, data di prescrizione, medico prescrittore; in aggiunta, negli USA vengono indicati, tra gli altri, il nome della marca del farmaco, il codice del farmaco e il sistema di codifica usato, data inizio e modalità somministrazione, modalità di riassunzione (refill) e campo commenti Problemi attuali che il paziente presenta ed eventuali diagnosi. In Svezia la diagnosi è codificata in ICD-10CM. In Finlandia in questo campo vengono indicate anche le disabilità psichiche/fisiche. In British Columbia sono anche riportate le osservazioni. Storia Clinica: o o o Medication record, cioè l insieme dei farmaci rilevanti somministrati in passato al paziente. In Inghilterra tale campo contiene le prescrizioni ripetitive degli ultimi 18 mesi e quelle acute degli ultimi 6 mesi. In Svezia si concentra l attenzione su nome farmaco, dose, data di prescrizione, medico prescrittore. Elenco delle vaccinazioni. In Scozia si distingue tra vaccinazioni da effettuare e quelle effettuate. Negli USA per ciascuna malattia per cui è stato erogato il vaccino, si indica la data di vaccino, e opzionalmente la dose, la modalità di somministrazione, il lotto e il produttore del vaccino Diagnosi e documenti clinici. I vari Paesi inseriscono tipologie diverse di documenti clinici (o riferimenti ad essi, o dati riassuntivi) in questo campo: si va dalle prescrizioni specialistiche e di ricovero della British Columbia, agli esami clinici e procedure della Finlandia, alle lettere di dimissione e referti (lab analisi, radiologia) della Svezia, ai referti di laboratorio e diagnostica e prescrizioni specialistiche degli USA. Ciascun Patient Summary è inoltre, caratterizzato da campi specifici al Paese (o stato componente). Quelli che appaiono più interessanti e utili, stanti le finalità del Patient Summary sono i seguenti: Svezia: o log degli accessi (accessibile solo dal paziente): in questo modo viene Pagina 12 di 64

13 offerta al paziente una maggiore garanzia di verificare chi ha acceduto a quali dati, eseguendo quali operazioni. Tale facoltà è in accordo con le linee guida del Gruppo di Lavoro dei Garanti privacy UE (Article 29 working party) Finlandia: o scelta di donazione degli organi e testamento biologico British Columbia, Belgio: o storia clinica del paziente USA: o o o o o o o sezione a cura del cittadino, in cui può riportare i suoi dati, problemi, ecc. storia sociale del paziente storia clinica del paziente (inclusi i contatti con strutture sanitarie) e della sua famiglia segni vitali: altezza, peso, pressione sanguigna, temperatura, ritmo cardiaco, data registrazione segni vitali, pulsiossimetria ecc. percorsi di cura, perizie mediche piano di cura raccomandato (testo libero) protesi, ausili, ecc. rilevanti per il paziente Si noti che solo in Inghilterra e Scozia l MMG/PLS è l unico autore del Patient Summary. Negli USA esso è compilato da ogni professionista sanitario coinvolto nella continuità della cura (medici, infermieri, ecc.) esiste un campo per il medico "mittente" e uno per il medico "destinatario". In British Columbia è compilato da ciascun operatore di cura primaria. Per quanto riguarda Svezia, Finlandia e Belgio non è indicato esplicitamente chi è l autore del Patient Summary, ma dai documenti sembra che ci possano essere più autori, incluso l MMG/PLS Per quanto riguarda gli standard utilizzati, Svezia e Belgio utilizzano un linguaggio proprietario basato su XML, mentre gli altri utilizzano CDA2. Della Scozia non si sa nulla. Si noti che gli USA utilizzano il CCD (Continuity of Care Document) appositamente orientato a gestire documenti per la continuità della cura. 318 Pagina 13 di 64

14 Contesto normativo nazionale Nel panorama normativo nazionale relativo alla categoria dei medici di base esiste un unico strumento denominato Scheda Sanitaria Individuale definito all interno dell Accordo Collettivo Nazionale per la Disciplina dei Rapporti con i Medici di Medicina Generale ai sensi dell art. 8 del D.Lgs. n. 502 del 1992 e successive modificazioni ed integrazioni. In particolare l articolo 45 Compiti del medico al comma 2 punto b) si precisa che l espletamento dei compiti di cui al comma 1 avviene anche attraverso la tenuta e l'aggiornamento di una scheda sanitaria individuale, su supporto informatico e tenuto conto di quanto previsto dall art. 59, lettera B, ad uso del medico e ad utilità dell assistito e del SSN, secondo standard nazionali e regionali e modalità definite nell ambito degli Accordi regionali, nonché l utilizzazione della Carta nazionale dei Servizi, prevista dal comma 9 art. 52 della Legge 27 Dicembre 2002, n. 289 e della tessera del cittadino secondo quando previsto dall art. 50 della Legge 24 novembre 2003 n Essa, nelle accezioni definite all interno dell ACN viene utilizzata nei seguenti casi d uso: - dal medico che ha in cura l assistito dal momento della scelta al momento della revoca / morte (art. 45, comma 2, lettera b); - dai medici nelle forme associative e per la continuità assistenziale.(art. 54 e 56); - dai MMG nelle prescrizioni di ricovero ordinario (art. 51 comma 9 e allegato E). Il modello e la struttura dei dati che devono essere contenuti all interno della Scheda Sanitaria Individuale non sono normati. All interno dell ACN si fa riferimento esclusivamente ad una compatibilità generica del software nel caso della medicina di gruppo (art. 54 comma 9 lettera f). Il data set allegato ai capitolati Rete MMG 5 aveva l obiettivo di avviare un processo anche di interoperabilità semantica a livello progettuale. La Scheda Sanitaria Individuale è quindi l unico documento sanitario al quale si può fare riferimento per avviare un processo di costruzione del Patient Summary. In virtù di questo deve essere verificata la potenziale succedanea valenza probatoria in caso di giudizio di un Patient Summary. 5 Allegato C Data Set di riferimento v.1.0 Prot. DIT/1884/05/III Pagina 14 di 64

15 Definizione Patient Summary Nell ambito UE viene data la seguente definizione 6 A patient summary is defined as a clinical document that is digitally stored in repositories with cumulative indexing systems and secure access by authorised people. It is based on full electronic health record. In order to achieve maximum benefit from this instrument, the structured content of patient summaries should be agreed at an international level, starting from a few generic summaries and gradually developing a series of summaries specific for each clinical context. Il gruppo di lavoro di progettazione condivisa del progetto Rete MMG ha definito il Patient Summary come: un documento informatico sanitario, firmato digitalmente e contenuto nel FSE 7, che riassume la storia del paziente e la situazione corrente. Esso è creato ed aggiornato dal MMG ogni qualvolta intervengono cambiamenti da lui ritenuti rilevanti 8 ai fini della storia del paziente. Contiene un set predefinito di dati clinici significativi per l emergenza (emergency data set). 3.1 Obiettivi del PS Nell ambito del progetto rete MMG gli obiettivi del PS possono essere: 1. rendere le informazioni disponibili per i contatti inattesi (emergenza/pronto soccorso); 2. cura cronica prevista, controllo clinico; 3. continuità di cura nelle vie cliniche comuni; 4. uso medico legale 5. medicina di gruppo (SSI) 3.2 Principali casi d uso I principali casi d uso possono essere sintetizzati in: - situazioni di emergenza nelle quali il paziente non può presentare esaustivamente la propria storia (problemi, allergie e farmaci correnti...) 6 Tale definizione è stata formulata da DG INFSO sulla base della letteratura e condivisa nell ambito del gruppo di lavoro ehealth ad hoc group. 7 Il Fascicolo Sanitario Elettronico (FSE) è l insieme dei documenti sanitari informatici del cittadino, firmati digitalmente, creati nella storia dei suoi contatti con i diversi attori del SSN. Tali documenti sono memorizzati, distribuiti ed indicizzati all interno dell infrastruttura nazionale federata della Sanità Elettronica (IBSE). Il FSE è accessibile dal cittadino e dagli operatori sanitari giuridicamente autorizzati in qualunque luogo ed in qualunque momento nel rispetto della regolamentazione nazionale e della tutela della privacy. L FSE rende disponibili le informazioni sanitarie dal momento in cui vengono referenziate nell infrastruttura sia per gli usi primari (emergenza, assistenza) che per gli usi secondari (amministrativi e di governo) - Fonte IBSE Glossario BOZZA03 8 Accezione suggerita da FIMMG Pagina 15 di 64

16 situazioni di necessità di continuità informativa, all'interno di gruppi di MMG, in orari in cui il proprio medico non è disponibile - pazienti gestiti da più professionisti nell'ambito di patologie croniche o anziani i regime di assistenza domiciliare o residenziale - supporto al processo diagnostico in corso di consulenza specialistica, teleconsulto - continuità informativa tra MMG ed ospedale in situazione di ricovero (la maggioranza dei ricoveri non viene decisa dal MMG) La mappatura effettuata con il Gruppo informatico FIMMG delle classi informative necessarie e correlate ai diversi casi d uso ha tuttavia evidenziato la necessità di strutturare i seguenti tre principali casi d uso: 1. situazioni di emergenza e di pronto soccorso 2. situazione di continuità della cura per accessi programmati alle strutture sanitarie (richieste di ricovero o di consulenze specialistiche) 3. continuità informativa all interno dei gruppo di MMG ovvero in caso di revoca della scelta del medico 3.3 Ciclo di vita dei documenti Sia il documento Scheda Sanitaria Individuale che il documento Patient Summary vengono creati al momento del primo contatto dell assistito con il medico e viene aggiornato e mantenuto dal medico stesso fino a quando ha in cura l assistito. Come tutti gli altri documenti strutturati, firmati digitalmente e referenziati nell infrastruttura di Fascicolo Sanitario Elettronico seguono le modalità di C-R-U-D previste dall infrastruttura. 3.4 Matrice delle classi informative per casi d uso del PS Al fine di procedere ad una prima ipotesi esaustiva per la strutturazione del documento PS vengono riportate, nella tabella seguente, le classi di dati ritenute rilevanti dal gruppo di lavoro Regioni e FIMMG. Esse vengono di seguito associate alle macro aree della struttura del CCD/CCR e rappresentate nella successiva tabella di sintesi. Di seguito viene definita una prima ipotesi di relazione tra le classi informative ed i casi d uso selezionati che costituisce base di discussione a livello nazionale e regionale. I campi contrassegnati con il simbolo X potrebbero essere considerati come potenzialmente obbligatori. I campi contrassegnati con il simbolo potrebbero essere considerati come potenzialmente opzionali 9. 9 Le ipotesi presenti in qusta versione del documento sono state effettuate in collaborazione con il Gruppo Informatico Pagina 16 di 64

17 Nelle sezioni successive vengono inserite delle ipotesi di strutturazione delle sezioni e dei campi da inserire nel CCD. Esse derivano da un processo di armonizzazione dei contributi delle regioni, il data set dei capitolati rete mmg, le normativa di riferimento e le necessità dello standard CCD. Tabella 3 Ipotesi selezione classi informative per casi d uso ID Classi definite da GdL Patient Summary CLASSI INFORMATIVE CCR/CCD Emergenza / Pronto Soccorso PRINCIPALI SCENARI D USO Continuità della Cura 10 Medicina di gruppo o di rete Anagrafica paziente Patient (dati identificativi paziente) x x x 2. Anagrafica MMG From (dati identificativi medico autore e medico destinatario) x x x 3. Contatti (familiari ed assistenziali) Support x x x Allergie (farmacologiche) e reazioni avverse Allergie (farmacologiche) e reazioni avverse Lista problemi rilevanti e diagnosi codificate Accertamenti diagnostici rilevanti ai fini delle patologie riportate Controlli pianificati a percorsi concordati per patologie croniche o particolari Alerts x x x Alerts x x x Problems x x x Results x x x Plan of Care x 9. Vaccinazioni Immunizations 10. Partecipazione a trials clinici Procedures x x x 11. Visite parte del campo "Encounters" 12. Parametri di monitoraggio (pressione, dati antropometrici, ecc.) 13. Assenso/dissenso donazione d organi 14. Consenso/diniego accanimento terapeutico Vital signs x parte del campo "Advanced Directives" x 13 x x parte del campo "Advanced Directives" x 14 x x 15. Stato corrente del paziente Functional status x x x 16. Potenziali rischi del paziente in relazione alla storia dei membri familiari Family History x x 17. Vita sociale (es. fumatore, etc.) Social History x x 415 x 12 FIMMG 10 Include richieste di ricovero e di consulenze specialistiche 11 La potenziale obbligatorietà corrisponde a quanto previsto al citato art. 45 dell ACN 12 E potenzialmente obbligatorio SOLO nel caso sia stato il MMG/PLS a somministrare la vaccinazione 13 E potenzialmente obbligatorio SOLO nel caso in cui la Dichiarazione del paziente si stata acquisita da MMG e non dall ASL 14 E potenzialmente obbligatorio SOLO nel caso in cui la Dichiarazione del paziente si stata acquisita da MMG e non dall ASL Pagina 17 di 64

18 SEZIONE II. STRUTTURAZIONE DEL DOCUMENTO PATIENT SUMMARY IN CCD Obiettivi Di seguito viene presentato il modello di Patient Summary strutturato secondo lo standard CCD. Sulla base delle considerazioni effettuate nei paragrafi precedenti e in virtù del fatto che il documento è realizzato nell ambito del progetto rete MMG, ci si concentra sul documento di Patient Summary redatto dal MMG/PLS per le emergenze. Il documento di Patient Summary in formato CCD viene predisposto dal SW del MMG/PLS, firmato secondo le modalità di firma elettronica/digitale previste dalla normativa, e reso disponibile nel Fascicolo Sanitario Elettronico tramite le apposite interfacce di servizio. Il medico di emergenza tramite il SW da lui utilizzato recupera, in presenza dell assistito/assitibile e da lui autorizzato, il documento di Patient Summary CCD dal FSE al fine di avere un chiaro quadro clinico del paziente per poter erogare la prestazione necessaria. Si noti che il presente documento non si sostituisce né al documento di specifiche CCD, né al documento di specifiche HL7/CDA Rel2, che rappresentano prerequisiti imprescindibili dalla corretta struttruazione del Patient Summary. Pertanto, per tutto ciò che riguarda gli elementi non indicati nel presente documento, si rimanda ai documenti di specifica degli standard Header Patient Summary Di seguito nella definizione della struttura del documento CDA sono omessi alcuni attributi dei tag ed i relativi valori nel caso siano invariati rispetto ai valori di default previsti da HL7 e a meno che la loro specificazione non sia assolutamente necessaria. Pertanto dove l attributo non è indicato non vuol dire che non esiste o non sia necessario riportarlo ma semplicemente che l attributo va valorizzato ( o considerato da punto di vista applicativo) con il valore di default assegnato dallo standard HL7 CDA Rel.2. Si noti che poiché il CCD è derivato dal CDA, per quanto riguarda la struttura dell header valgono le stesse regole del CDA. Commento [katiac1]: check Pagina 18 di 64

19 Gli OID utilizzati per alcuni codici nel documento non sono ancora assegnati o non hanno in alcuni casi la struttura corretta. La corretta assegnazione sarà valutata in seguito anche in base alle modalità di articolazione di alcuni rami della gerarchia degli OID HL7 al livello italiano. L attuale ipotesi di gerarchia è consultabile sul sito di HL7Italia all indirizzo: Root del documento:<clinical Document> Elemento root per la struttura xml che rappresenta il documento CDA. <ClinicalDocument xsi:schemalocation="urn:hl7-org:v3 CDA.xsd" xmlns="urn:hl7-org:v3" xmlns:xsi=" Dominio: <realmcode> Elemento OBBLIGATORIO che indica il dominio di appartenenza del documento. Più precisamente indica l esistenza di una serie di restrizioni applicate per il dominio ITALIANO al profilo CCD. root CE IT Definisce l id di contesto per l Italia. Uso: <realmcode code= IT /> Identificativo CDA2: <typeid> Elemento OBBLIGATORIO che indica che il documento è strutturato secondo le specifiche HL7-CDA Rel 2.0 e più precisamente secondo lo schema della CDA, Release Two Hierarchical Description Pagina 19 di 64

20 Il tag <typeid> è un valore del tipo HL7 Instance Identifier ed è composto da una attributo root che riporta un codice OID, un attributo extension che riporta un codice specifico. root OID extension ST POCD_HD Uso: Object Identifier di HL7 per i modelli registrati Codifica identificativa del CDA Release Two Hierarchical Description che è lo schema che contiene la gerarchia delle classi di un documento CDA <typeid root=" " extension="pocd_hd000040"/> Identificativo CDA2: <templateid> Elemento OBBLIGATORIO che indica il template di riferimento per il documento corrente. Il tag <templateid> è un valore del tipo HL7 Instance Identifier ed è composto da un attributo root che riporta un codice OID ed eventualmente un attributo extension che riporta un codice specifico. I template possono essere utilizzati per individuare, in relazione alla tipologia di documento espresso dal tag <code> (vedi seguito), un insieme di restrizioni/linee guida da applicare all intero documento o ad una specifica sezione dello stesso. CDA provides a mechanism to reference a template or implementation guide that has been assigned a unique identifier. Until there is a formal HL7 Template specification, there is no standardized process to test conformance against referenced templates. [..] When ClinicalDocument.templateId is valued in an instance, it signals the imposition of a set of template-defined constraints. In addition, the templateid attribute is available in all other CDA classes, thus enabling the imposition of a set of template-defined constraints at any level of granularity. The value of this attribute provides a unique identifier for the template(s) in Pagina 20 di 64

21 question. Nel caso specifico, essendo indicato dall attributo <code> il codice relativo al documento di PATIENT SUMMARY, l attributo <templateid> identificherà la specifica versione del template (schema-schematron) che deve essere utilizzata dal document CONSUMER per la validazione del documento corrente. L attributo <templateid> può, nel nostro contesto, permettere la progressiva evoluzione dei modelli di documento CDA utilizzati dalla sanità elettronica. Tramite la combinazione dell attributo <code>, che rimane costante per la medesima tipologia di documento (ex: PATIENT SUMMARY ), e l attributo <templateid> che potrebbe variare in relazione alla versione dello schema utilizzato per validare il documento, (ex: versione 1.0, 1.1 etc) è possibile da parte del document CONSUMER individuare sempre lo specifico template di validazione della versione corrente di documento. In ciascun documento CDA ci possono essere uno o più elementi <templateid>. In particolare, è prevista dallo standard la possibilità di utilizzare template con diversi livelli di granularità, potendo anche specificare template differenti in punti diversi del documento. Il document CONSUMER non deve identificare il documento tramite il <templateid> ma esclusivamente tramite l attributo <code>. Il Patient Summary è caratterizzato da due elementi <templateid>: Il primo elemento <template> è valorizzato secondo le regole di conformance previste dall implementation guide del CCD, ed è pertanto costituito dal solo elemento <root> valorizzato come segue: Root OID OID del catalogo degli schemi dei template di documento per i documenti di Patient Summary 529 extension 15 ST - (Rif: CCD CONF-??) Commento [dberardi2]: da inserire 15 Ipotesi Codice composto PREFISSO: ITPRF CODICE: PSUM _GEN per il Patient Summary (generico) VERSIONE: 001 progressivo per il versioning dei template Pagina 21 di 64

22 il secondo definisce il documento di Patient Summary in ambito Italiano, in termini di imposizione di una serie di costraint sul modello previsto dal CCD, ed è valorizzato come segue: Root OID OID del catalogo degli schemi dei template di documento per i documenti di Patient Summary extension 16 ST ITPRF_PSUM_GEN-001 Identificativo del template di documento PATIENT SUMMARY Uso: <templateid root= < > /> <templateid root=" " extension=" ITPRF_PSUM_GEN-001"/> Identificativo documento: <id> Elemento OBBLIGATORIO che identifica univocamente l istanza di ogni documento CDA. Il tag <id> è un valore del tipo HL7 Instance Identifier ed è composto da un attributo root che riporta un codice OID, un attributo extension che riporta un codice specifico e un attributo con il nome dell authority che è responsabile della codifica posta nel campo extension. Come richiesto da HL7 ogni singola istanza di documento CDA (singolo patient summary, singola prescrizione, singolo referto ) DEVE essere dotata di un IDENTIFICATIVO UNIVOCO che andrà collocato nell attributo <id> del documento. Pertanto è necessario concordare un meccanismo di creazione di ID univoci a livello nazionale necessari all identificazione dei documenti sanitari presenti nell FSE. Tale meccanismo è riportato, insieme ad una ricognizione delle ipotesi al livello regionale, nell Appendice D del presente documento. <id>: Commento [dberardi3]: che ck Pagina 22 di 64

23 root OID [OID identificativo della struttura di competenza] OID della struttura cui appartiene l autore del documento (vedi appendice A) extension ST [IUD] assigningauthorityname Uso: ST [NOME STRUTTURA DI COMPETENZA] Identificativo Unico Documento Generato dal client dell autore secondo regole condivise, in modo da evitare collisioni all interno del medesimo dominio di competenza documento (vedi appendice B) Nome struttura cui appartiene l autore del documento <id root=" " extension=" " assigningauthorityname= AUSL LATINA 1 /> Versione del documento: <setid> e <versionnumber> Elemento OBBLIGATORIO che rappresenta un identificatore comune di tutte le revisioni del documento. Il <setid> resta quindi costante tra le diverse versioni del medesimo documento. Se, per esempio, viene prodotto un documento di Patient Summary pubblicato nel FSE e successivamente il document SOURCE, a causa di un errore o per altro motivo, decide di modificarlo/sostituirlo, il nuovo documento di prescrizione avrà un <id> univoco e diverso dal primo ed un <setid> uguale al primo documento pubblicato. Lo standard prevede inoltre che il nuovo documento abbia una relazione di tipo <relateddocument> che punta al documento sostituito. Anche il <setid> come l <id> deve essere unico in uno spazio di dominio; pertanto è OBBLIGATORIO che alla prima creazione del documento i campi <setid> ed <id> siano valorizzati allo stesso modo con lo IUD generato. Successivamente nelle diverse revisioni del documento si modificherà solo l <id> con un nuovo IUD, mantenendo il <setid> costante. Pagina 23 di 64

24 <setid>: root OID extension ST [IUD] assigningauthorityname ST [OID identificativo della struttura di competenza] [NOME STRUTTURA DI COMPETENZA] OID della struttura cui appartiene l autore del documento (vedi Appendice A) Identificativo univoco delle revisioni del documento Nome struttura cui appartiene l autore del documento <versionnumber>: value Uso: INT [progressivo versione documento] Ad ogni successiva versione del documento (RPLC), tale numero incrementa di una unità (partendo da 1) <setid root=" " extension=" dw322" assigningauthorityname= AUSL LATINA 1 /> <versionnumber value= 1 /> Pagina 24 di 64

25 Figura 4: versionamento del documento - Replace (estratto documentazione HL7) Codice Documento:<code> Elemento OBBLIGATORIO che indica la tipologia di documento. L attributo <code> riporta un codice che identifica la tipologia di documento a cui il CDA si riferisce (Prescrizione, Referto di., lettera di dimissione, patient summary) Il valore DEVE fare riferimento al sistema di codifica LOINC Nel caso del Patient Summary, le specifiche CCD impongono che il tag deve essere così valorizzato : Pagina 25 di 64

26 <code>: codesystem OID Codifica LOINC code CS Codice relativo alla tipologia del documento. ( Summarization of episode note ) codesystemname ST LOINC codesystemversion ST 2.19 Versione codifica LOINC displayname ST PATIENT SUMMARY Per individuare nel realm Italiano le successive tipologie di patient summary il codice espresso nell elemento <code> PUO essere tradotto in un codesystem definito in ambito italiano e condiviso all interno del dominio FSE. In tale contesto è quindi ammesso l utilizzo all interno dell elemento code di un <translation> che DEVE essere così valorizzato: <code><translation>: codesystem OID Codifica LOINC code CS X or X Codice relativo alla specifica tipologia di documento. codesystemname ST ITCDADOC_TYPECODE codesystemversion ST 1 Versione codifica LOINC displayname ST PATIENT SUMMARY Nota: Tale codice NON PUO mai confliggere con il codice LOINC Summarization of episode note Uso: Commento [dberardi4]: verif icare Commento [dberardi5]: Nel documento degli OID lo si chiama (anche) Patient Summary generico. Commento [dberardi6]: Nel documento degli OID lo si chiama (anche) Patient Summary generico. <id root=" " extension=" dw009" assigningauthorityname="asl Napoli 1"/> <code code=" " codesystem=" " displayname="summarization of episode note"> <translation code="x " codesystem=" " codesystemname="itcdadoc_typecode" codesystemversion="1"/> Pagina 26 di 64

27 </code> Riservatezza del documento:<confidentialitycode> Elemento OBBLIGATORIO che indica la riservatezza del documento. Il tag <confidentialitycode> riporta un codice che identifica il livello di confidenzialità del documento CDA secondo la codifica di Confidentiality di HL7 Code * Definition N (normal) (codesystem ) Normal confidentiality rules (according to good health care practice) apply. That is, only authorized individuals with a legitimate medical or business need may access this item. R (restricted) (codesystem ) Restricted access, e.g. only to providers having a current care relationship to the patient. V (very restricted) (codesystem ) Very restricted access as declared by the Privacy Officer of the record holder Nel caso della prescrizione il tag deve essere così valorizzato : codesystem OID OID codifica code ST N Normali regole di riservatezza codesystemname ST Confidentiality Nome della codifica Uso: <confidentialitycode code="n" codesystem= codesystemname = Confidentiality /> Pagina 27 di 64

28 Data di creazione documento:<effectivetime> Elemento OBBLIGATORIO che indica la data di creazione del documento Patient Summary in CDA. L attributo <effectivetime> rappresenta un codice temporale che può essere strutturato secondo diverse modalità di codifica previste da HL7. Tale valore deve essere quello del client utilizzato dal document SOURCE, opportunamente certificato. Nel caso della prescrizione l attributo deve essere valorizzato tramite un tipo Time Stamp (TS) come presentato di seguito: value Uso: TS [YYYYMMddhhmmss+ - ZZzz] <effectivetime value=" "/> L esempio indica le 14:00 00:(ora Italiana) del 07 Aprile Lingua e Dominio: <languagecode> Anno, mese, giorno, ora, minuti, secondi Le ore devono essere riportate nell intervallo 00:00:00-23:59:59. ZZzz rappresenta l offset rispetto al tempo di Greenwich (GMT Greenwich Mean Time). L Italia si trova a GMT+1, quindi ZZzz va valorizzato con Ad esempio le si indicano Elemento FACOLTATIVO che indica la lingua in cui è redatto il documento. L attributo <languagecode> rappresenta un codice conforme alle specifiche dell IETF (Internet Engineering Task Force) RFC 3066 (OID: ) Nel caso del Patient Summary il tag deve essere così valorizzato: Pagina 28 di 64

29 code ST it-it oppure it Uso: <languagecode code="it-it"/> L attributo deve essere nella forma nn o nn-cc, dove nn è la codifica ISO della lingua in minuscolo e CC è la codifica ISO-3166 dello Stato in maiuscolo Destinatario: <recordtarget> Elemento OBBLIGATORIO che identifica il soggetto cui si riferisce il Patient Summary. Il <recordtarget> è un elemento composto da un ruolo <patientrole> verso un entità <patient>. Per il Patient Summary l elemento deve pertanto essere strutturato come segue: <recordtarget> <patientrole> <patient>...</patient> <patientrole> <recordtarget> <patientrole> Il ruolo <patientrole> deve prevedere genericamente al suo interno almeno un elemento di tipo <id> destinato ad accogliere la chiave identificativa del paziente, secondo gli schemi assegnati da ogni singola regione ed un elemento di tipo <id> destinato ad accogliere le informazioni relative al codice fiscale Diverse sono tuttavia le casistiche possibili e le relative eccezioni, in dipendenza dalla tipologia di soggetto in esame; tali casistiche possono essere così sintetizzate: 1. Soggetti assicurati da istituzioni estere: Pagina 29 di 64

30 <patientrole> DEVE riportare un elemento di tipo <id> contenente: 1. Numero di identificazione personale ed il codice dell istituzione competente 2. Numero di identificazione della Tessera Sanitaria <id>: root OID [OID PAESE] Codice Paese soggetto estero extension ST [NUMERO IDENTIFICAZIONE PERSONALE ] + - +[NUMERO SERIALE] Numero id personale Numero seriale carta assigningauthorityname ST [ISTITUZIONE COMPETENTE] - [CODICE NUMERICO] Istiuzione competente + # + codice numerico Uso: <id root= extension= CRLLNZ99M99F999T assigningauthorityname= SSN-MIN SALUTE# > Cittadino italiano o straniero residente (iscritto SSN): Due elementi di tipo <id> contenenti: 1. Il codice assegnato dall anagrafica regionale (FACOLTATIVO) 2. Il codice fiscale del paziente (OBBLIGATORIO) Primo <id>: root OID OID schema di [REGIONE].4. identificazione 1 regionale extension ST [CODICE IDENTIFICATIVO] Codice anagrafica regionale Secondo <id>: Pagina 30 di 64

31 root OID extension ST [CODICE FISCALE] assigningauthorityname ST MEF Uso: OID Ministero economia e finanze CF CF del paziente Ministero dell Economia e delle Finanze <recordtarget> <patientrole> <id root=" " extension=" " azssigningauthorityname="regione Toscana" /> id root=" " extension="crllnz99m22g999t" assigningauthorityname="mef"/> <patient> </patient> </patientrole> </recordtarget> <patient> L entità <patient> contiene i dettagli anagrafici relativi al paziente. Riporta alcuni attributi OBBLIGATORI con l indicazione dei dati anagrafici, quali in particolare <name> (con i componenti <family> e <given>), <administrativegendercode>. E inoltre FACOLTATIVO inserire il luogo di nascita nell attributo <birthplace>. Uso: <recordtarget> <patientrole> <id../> <id../> <patient> <name> <family>guido</family> <given>rossi</given> </name> <birthplace> <place> <addr>...</addr> </place> Pagina 31 di 64

32 </birthplace> <administrativegendercode code="m" codesystem=" "/> </patient> </patientrole> </recordtarget> Nel caso di documenti per le quali sia prevista la possibilità di anonimato in ottemperanza a quanto previsto dal dall art. 87 nella nuova disciplina sulla Privacy (D.Lgs. 30 giugno 2003 n. 196) gli attributi anagrafici <name> e <birthplace>, qualora presente, vanno riportati sprovvisti di valori ma ambedue decorati con l attributo nullfavour= MSK per permetterne la comprensione al document consumer. Nessu ulteriore utilizzo/valore dell attributo NULLFLAVOR è ammesso. Uso: <recordtarget> <patientrole> <id../> <id../> <id /> <patient> <id root=" " extension="crllnz99m22g999t" assigningauthorityname="mef"/> <name nullflavor= MSK > <birthplace nullflavor= MSK > </patient> </patientrole> </recordtarget> Commento [dberardi7]: Veri ficare se ha senso l anonimato anche per il Patient Summary Custode: <custodian> Elemento OBBLIGATORIO che identifica l organizzazione incaricata della custodia del documento originale. Tale organizzazione è la struttura di cui fa parte colui che ha creato il documento (MMG -ASL, Altro Medico redattore del Patient Summary AO,..). Il <custodian> è un elemento composto da un ruolo di tipo <assignedcustodian> verso un entità <representedcustodianorganization>. L elemento viene pertanto ad essere strutturato come segue: <custodian> <assignedcustodian> Pagina 32 di 64