IBSE Infrastruttura di Base della Sanità...
-
Upload
trinhduong -
Category
Documents
-
view
214 -
download
0
Transcript of IBSE Infrastruttura di Base della Sanità...
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 1 di 64
1 2
3
4
5
6
7
IBSE 8
Infrastruttura di Base della Sanità 9
Elettronica 10
11
PATIENT SUMMARY 12
Definizione dei contenuti del Patient Summary e relazioni con la Scheda 13 Sanitaria Individuale dell'Assistito 14
15 16 17 18 19 20 21 22 23 24 25 26
27 28 29 30 31 32
Documento di lavoro: materiale confidenziale ad esclusivo uso interno. Non distribuire né 33 citare senza assenso esplicito della struttura responsabile. 34
35
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 2 di 64
36
Indice 37
1 Status del documento ............................................................................................................................4 38
2 Note di lettura..........................................................................................................................................5 39
3 Guida alla lettura.....................................................................................................................................6 40
4 Documentazione di Riferimento ...........................................................................................................7 41
5 Obiettivi e contesto di riferimento del documento .............................................................................8 42
SEZIONE I.– DEFINIZIONE CONCETTUALE DI PATIENT SUMMARY E RELAZIONI CON LA SCHEDA SANITARIA 43 INDIVIDUALE.....................................................................................................................................................10 44
1 Ricognizione dei concetti di PS in ambito internazionale...............................................................10 45
1.1 Standard tecnici di riferimento ...................................................................................................10 46
1.2 Concetti di PS nelle buone pratiche internazionali .................................................................11 47
2 Contesto normativo nazionale ............................................................................................................14 48
3 Definizione Patient Summary .............................................................................................................15 49
3.1 Obiettivi del PS.............................................................................................................................15 50
3.2 Principali casi d’uso.....................................................................................................................15 51
3.3 Ciclo di vita dei documenti..........................................................................................................16 52
3.4 Matrice delle classi informative per casi d’uso del PS ...........................................................16 53
SEZIONE II. – STRUTTURAZIONE DEL DOCUMENTO PATIENT SUMMARY IN CCD........................................18 54
1 Obiettivi ..................................................................................................................................................18 55
2 Header Patient Summary ....................................................................................................................18 56
2.1.1 Root del documento:<Clinical Document> ..........................................................................19 57
2.1.2 Dominio: <realmCode>...........................................................................................................19 58
2.1.3 Identificativo CDA2: <typeId> ................................................................................................19 59
2.1.4 Identificativo CDA2: <templateId> ........................................................................................20 60
2.1.5 Identificativo documento: <id>...............................................................................................22 61
2.1.6 Versione del documento: <setId> e <versionNumber> .....................................................23 62
2.1.7 Codice Documento:<code> ...................................................................................................25 63
2.1.8 Riservatezza del documento:<confidentialityCode>..........................................................27 64
2.1.9 Data di creazione documento:<effectiveTime> ..................................................................28 65
2.1.10 Lingua e Dominio: <languageCode>................................................................................28 66
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 3 di 64
2.1.11 Destinatario: <recordTarget> ............................................................................................29 67
2.1.12 Custode: <custodian>.........................................................................................................32 68
2.1.13 Autore e autenticatore: <author> e <legalAuthenticator>.............................................33 69
2.1.14 EventoClinico: <documentationOf> e <serviceEvent>..................................................37 70
2.1.15 Destinatario del documento: <informationRecipient>....................................................39 71
2.1.16 Contatti: <guardian> e <participant>................................................................................39 72
2.2 Body documento Patient Summary .........................................................................................44 73
2.2.1 Allergie e reazioni avverse.....................................................................................................46 74
2.2.2 Terapie farmacologiche croniche o attuali rilevanti ............................................................54 75
2.2.3 Lista problemi rilevanti e diagnosi codificate.......................................................................54 76
2.2.4 Accertamenti diagnostici rilevanti ai fini delle patologie riportate.....................................54 77
2.2.5 Controlli pianificati a percorsi concordati per patologie croniche o particolari ...............55 78
2.2.6 Vaccinazioni .............................................................................................................................55 79
2.2.7 Partecipazione a trials clinici..................................................................................................55 80
2.2.8 Visite ..........................................................................................................................................55 81
2.2.9 Parametri di monitoraggio (pressione, dati antropometrici, ecc.) ....................................55 82
2.2.10 Assenso/dissenso donazione d’organi ............................................................................55 83
2.2.11 Consenso/diniego accanimento terapeutico...................................................................55 84
2.2.12 Stato corrente del paziente................................................................................................55 85
2.2.13 Potenziali rischi del paziente in relazione alla storia dei membri familiari..................56 86
2.2.14 Vita sociale (es. fumatore, etc.) ........................................................................................56 87
3 BIBLIOGRAFIA .....................................................................................................................................57 88
Appendice A –Elenco OID ...........................................................................................................................58 89
Appendice B - Composizione dello IUD.....................................................................................................59 90
Appendice C – Cenni sui meccanismi di Firma Digitale XML-Signature..............................................61 91
Appendice D - Esempio di documento Patient Summary.......................................................................63 92
Appendice E - Prescrizione casi d’uso ......................................................................................................64 93
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 4 di 64
1 Status del documento 94
Questa versione: 95
96 Titolo: Patient Summary 97 98 Versione: 05.00 99 Stato: BOZZA 100 Data: 03/08/2007 13.26 101 102 Autore/i: Daniela Berardi, Lorenzo Cerulli, Katia Colantonio 103 Ente/Società: Innovazione Italia 104 105 Responsabile: Katia Colantonio 106 Ente/Società: Innovazione Italia 107 108 Contributore/i: Giuseppe Frieri, Mariano Paolizzi, Valter De Giorgi, 109
Francesco Caccavo, Leandro Pesca,Italo Paolini, Gruppo CNR 110 – Regione Basilicata 111
Ente/Società: Regione Abruzzo, Regione Sardegna, Regione Puglia, FIMMG – 112 Gruppo informatico, Regione Basilicata 113
114 Emesso: 115 Ente/Società: Dipartimento per l’Innovazione e le Tecnologie 116 117
118 Storia delle revisioni: 119
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
4.0 BOZZA 24/07/2007 Prime ipotesi di mapping classi informative per casi d’uso e prime ipotesi di strutturazione in CCD di alcune classi informative
5.0 BOZZA 03/08/2007 Strutturazione dell’header in CCD, e inizio definizione body (sezione “Allergie e reazioni avverse”)
120
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 5 di 64
2 Note di lettura 121
Nella definizione dei requisiti, delle specifiche e delle regole descritte nei documenti 122 sono utilizzate le parole chiave DEVE, NON DEVE, OBBLIGATORIO, VIETATO, 123
DOVREBBE, CONSIGLIATO, NON DOVREBBE, SCONSIGLIATO, POTREBBE, OPZIONALE 124 che devono essere interpretate in conformità con RFC21191. 125
In particolare: 126
• DEVE, OBBLIGATORIO, NECESSARIO (MUST, REQUIRED, SHALL) significano 127
che la definizione è un requisito assoluto, la specifica deve essere 128 implementata, la consegna è inderogabile. 129
• NON DEVE, VIETATO (MUST NOT, SHALL NOT) significano che c’è proibizione 130
assoluta di implementazione di un determinato elemento di specifica. 131
• DOVREBBE, CONSIGLIATO (SHOULD, RECOMMENDED) significano che in 132 particolari circostanze possono esistere validi motivi per ignorare un 133
requisito, non implementare una specifica, derogare alla consegna, ma che 134 occorre esaminare e valutare con attenzione le implicazioni correlate alla 135
scelta. 136
• NON DOVREBBE, SCONSIGLIATO (SHOULD NOT, NOT RECOMMENDED) 137 significano che in particolari circostanze possono esistere validi di motivi per 138
cui un elemento di specifica è accettabile o persino utile, ma, prima di 139 implementarlo, le implicazioni correlate dovrebbero essere esaminate e 140
valutate con attenzione. 141
• PUÒ, OPZIONALE (MAY, OPTIONAL) significano che un elemento della 142 specifica è a implementazione facoltativa. 143
144
Le parole chiave nel testo sono segnalate in maiuscolo e neretto (es. “DEVE”). 145
1 Vedi: http://www.ietf.org/rfc/rfc2119.txt
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 6 di 64
3 Guida alla lettura 146
147
La tabella seguente descrive i contenuti delle sezioni che compongono il documento: 148
Tabella 1 – Guida alla lettura 149
Sezione
Titolo Descrizione
1. Status del documento
Descrizione dei principali metadati del documento (titolo, autori, responsabili), lo stato del documento, e la storia delle revisioni.
2. Note di lettura Richiami sull’uso delle parole chiave secondo RFC2119
3. Guida alla lettura Questa sezione
4. Documentazione di Riferimento
Elenco della documentazione ritenuta prerequisito per la comprensione del documento.
5. Obiettivi e contesto di riferimento del documento
Obiettivi del documento
6. … …
7.
8.
9.
150
Le sezioni più complesse del documento riportano al loro inizio, in corsivo, una 151
descrizione sintetica dei contenuti. 152
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 7 di 64
4 Documentazione di Riferimento 153
Di seguito è riportato un elenco della documentazione ritenuta prerequisito per la 154
comprensione del presente documento. Sono inoltre un ulteriore prerequisito 155 CONSIGLIATO2 i capitolati regionali del “Progetto Rete dei Medici di Medicina 156
Generale” 157
Tabella 2 – Documentazione di riferimento 158
Emesso da Documento Nome File Data Riferimento
Livelli di requisito
(RFC2119)
TSE Una Politica per La Sanità Elettronica.
• TSE-Politica Condivisa per la Sanità Elettronica.pdf
31/03/2005 www.sanitaelettronica.gov.it CONSIGLIATO
TSE Strategia architetturale per la Sanità Elettronica
• TSE-IBSE-Strategia_architetturale-v01.00-DEF.pdf
31/03/2006 www.sanitaelettronica.gov.it OBBLIGATORIO
DIT
Linee guida per gli standard tecnologici IBIS a livello regionale
• TSE-IBSE-Linee_ guida_per_gli_standard_tecnologici_IBIS_a_livello_regionale-v01 00-BOZZA-01.pdf
07/11/2006 e-mail DIT del 07/11/2006 OBBLIGATORIO
DIT Tutti i documenti di progettazione condivisa
• vari Alla data corrente
www.sanitaelettronica.gov.it OBBLIGATORIO
DIT Allegato C – Data Set Rete MMG
• Allegato C – dataste di riferimento v.1.0.doc
07/06/2005 Prot. DIT/1884/05/III
OBBLIGATORIO
FIMMG
Accordo Collettivo Nazionale per la disciplina dei rapporti con i medici di Medicina Generale siglato 2005
• Accordo collettivo nazionale.pdf
2005 www.sisac.info CONSIGLIATO
HL7 Implementation guide CDA2 - CCD
- CCD.06Dec2006_Info_Ballot2.doc
2006 www.sanitaelettronica.gov.it
CONSIGLIATI
DIT GLOSSARIO - IBSE – Glossario BOZZA 03
2007 www.sanitaelettronica.gov.it
OBBLIGATORIO
ASTM7HL7
HL7 Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD)
- CCD.06Dec2006_Info_Ballot_2.doc 2006
www.sanitaelettronica.gov.it/egr
oupware OBBLIGATORIO
159
2 Questi, ovviamente, sono prerequisito OBBLIGATORIO per il fornitore direttamente coinvolto.
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 8 di 64
5 Obiettivi e contesto di riferimento del 160
documento 161
Questo documento segue il documento “Strategia architetturale per la Sanità 162
Elettronica” approvato dal Tavolo di lavoro permanente per la Sanità Elettronica (TSE), 163 i capitolati Rete MMG emessi dal DIT e recepiti dalle Amministrazioni Regionali e il 164
documento “Linee guida per gli standard tecnologici IBIS a livello regionale” e 165 contribuisce, insieme a documenti successivi, a definire il documento di Patient 166
Summary. Esso ha due obiettivi principali: 167
1. proporre una definizione del concetto di Patient Summary (PS) in riferimento al 168 Fascicolo Sanitario Elettronico e ai documenti clinici che esso contiene. 169
2. definire i dati e le classi di informazioni che il Patient Summary deve contenere, 170 al fine di garantire al meglio efficienza, efficacia e continuità della cura nei 171
diversi casi d’uso che le Regioni decideranno di implementare. 172
3. definire la struttura del documento del Patient Summary a partire dalle 173 specifiche CCD 174
La definizione che viene formulata nel presente documento deriva dall’insieme dei 175
contributi ricevuti dalle Amministrazioni Regionali che si sono candidate alla 176 definizione del Patient Summary3 e tiene conto dei seguenti presupposti: 177
- contributi ricevuti dalle Amministrazioni Regionali medesime 178
- il contesto normativo di riferimento per la collocazione del documento 179
- le buone pratiche internazionali 180
- gli standard tecnici di strutturazione documentale 181
E’ implicito che documento di PS che verrà definito sarà un documento creato e 182 mantenuto dal MMG / PLS principale destinatario dell’intervento progettuale Rete dei 183
Medici di Medicina Generale. 184
Il Patient Summary generico conterrà un sottoinsieme informativo derivante dalla 185 Scheda Sanitaria Individuale del paziente prevista negli Accordi Collettivi Nazionali 186
della medicina di base, già prevista nei capitolati emessi dalle Regioni per il progetto in 187 oggetto. 188
A tal fine il gruppo di lavoro che ha redatto il presente documento ha definito un 189
insieme abbastanza ampio di classi informative che in linea di massima corrisponde 190 all’insieme strutturato di informazioni potenzialmente contenute in una Scheda 191
Sanitaria Individuale (e dunque nei software correnti di c.d. Cartella Clinica presenti 192 presso gli studi medici) . 193
3 Abruzzo, Basilicata, Puglia e Sardegna
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 9 di 64
La scelta su eventuali classi informative da omettere o ridurre sarà in carico al gruppo 194
di lavoro allargato in funzione dei diversi casi d’uso previsti ed in funzione della 195 concertazione che avverrà in ambito regionale con le associazioni di categoria. 196
Come tutti i documenti prodotti nell’ambito della progettazione condivisa, rientra nelle 197
attività di ambito condiviso previste nelle schede tecniche definite negli Accordi di 198 Programma Quadro e costituiscono linee guida per l’implementazione del progetto 199
finalizzate alla costruzione dell’Infrastruttura di Base della Sanità Elettronica a livello 200 regionale e alla predisposizione delle basi di interoperabilità del Fascicolo Sanitario 201
Elettronico e dei relativi documenti informatici a livello interregionale. 202
Tale documento DEVE costituire la base della proposta nazionale nell’ambito 203
della Call for proposal CIP eHealth Large Scale Pilot di tipo A relativamente al 204 Patient’s Summary. 205
Questo documento è strutturato in due principali sezioni: 206
1. la prima sezione è di definizione contettuale del documento Patient Summary, 207
contiene i principali i casi d’uso e le principali classi informative, mappate sul 208 CCD/CCR, che si intendono utilizzare; 209
2. la seconda sezione è invece relativa alla strutturazione del documento 210
informatico in CCD 211
212
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 10 di 64
SEZIONE I.– DEFINIZIONE CONCETTUALE DI PATIENT 213
SUMMARY E RELAZIONI CON LA SCHEDA SANITARIA 214
INDIVIDUALE 215
216
1 Ricognizione dei concetti di PS in ambito 217
internazionale 218
219
1.1 Standard tecnici di riferimento 220
Nel panorama internazionale le organizzazioni di maggior riferimento, HL7 e IHE, sui 221
diversi concetti di patient summary orientati alla continuità della cura stanno 222 convergendo nella strutturazione di un formato di CDA2 rivisitato denominato CCD - 223
Continuity of Care Document. 224
La strutturazione del CCD è il risultato di una collaborazione tra HL7 e ASTM 225
(American Society for Testing and Materials) Committee E31 on Healthcare 226 Informatics. Esso deriva dallo standard CCR - Continuity of Care Record4, promosso 227
dalla ASTM, secondo HL7-CDA2. 228
In sintesi il CCR è un insieme di dati rilevanti che descrivono lo stato di salute 229 presente e passato di un paziente e le cure e i trattamenti cui si è sottoposto. Tali dati 230
coprono informazioni di tipo amministrativo, demografico e clinico. Il CCR costituisce 231 un modo per un professionista sanitario di aggregare tutti i dati di un paziente, che 232
ritiene rilevanti e di inviarli ad un altro professionista sanitario al fine di garantire la 233 continuità della cura. Pertanto, scopo primario del CCR è fornire un’istantanea sul 234
quadro clinico, demografico e amministrativo di uno specifico paziente. 235
4 ASTM E2369-05 Standard Specification for Continuity of Care Record (CCR)
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 11 di 64
1.2 Concetti di PS nelle buone pratiche internazionali 236
Al fine di verificare i concetti di PS presenti in ambito internazionale, i principali autori, 237 le classi informative e le modalità tecniche di strutturazione dei documenti è stata 238
effettuata un’analisi sulle principali buone pratiche internazionali. Di seguito, nelle 239 tabelle 1 e 2, vengono illustrati i diversi approcci alla strutturazione del Patient 240
Summary che rappresentano lo stato dell’arte a livello internazionale. 241
242
243
Tabella 1 – Patient Summary (informazioni di base) 244
245
246
Tabella 2 – Patient Summary (storia clinica ed altri dati) 247
In sintesi è possibile affermare che i Patient Summary in fase di sperimentazione a 248
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 12 di 64
livello internazionale condividono alcuni campi: 249
• Informazioni di base ed attuali: 250
o Dati anagrafici del paziente, del medico che ha redatto il Patient 251 Summary e di un ulteriore contatto del paziente in casi di emergenza 252
o Allergie a farmaci o ad altre sostanze, rischi immunitari, intolleranze. 253
Negli USA per ciascuna reazione allergica viene indicata la causa e la data 254 dell’ultima reazione. 255
o Medicinali prescritti e in fase di somministrazione al paziente. In 256
particolare, in Svezia si concentra l’attenzione su: nome farmaco, dose, 257 data di prescrizione, medico prescrittore; in aggiunta, negli USA vengono 258
indicati, tra gli altri, il nome della marca del farmaco, il codice del 259 farmaco e il sistema di codifica usato, data inizio e modalità 260
somministrazione, modalità di riassunzione (refill) e campo commenti 261
• Problemi attuali che il paziente presenta ed eventuali diagnosi. In Svezia la 262 diagnosi è codificata in ICD-10CM. In Finlandia in questo campo vengono 263
indicate anche le disabilità psichiche/fisiche. In British Columbia sono anche 264 riportate le osservazioni. 265
• Storia Clinica: 266
o Medication record, cioè l’insieme dei farmaci rilevanti somministrati in 267
passato al paziente. In Inghilterra tale campo contiene le prescrizioni 268 ripetitive degli ultimi 18 mesi e quelle acute degli ultimi 6 mesi. In Svezia 269
si concentra l’attenzione su nome farmaco, dose, data di prescrizione, 270 medico prescrittore. 271
o Elenco delle vaccinazioni. In Scozia si distingue tra vaccinazioni da 272
effettuare e quelle effettuate. Negli USA per ciascuna malattia per cui è 273 stato erogato il vaccino, si indica la data di vaccino, e opzionalmente la 274
dose, la modalità di somministrazione, il lotto e il produttore del vaccino 275
o Diagnosi e documenti clinici. I vari Paesi inseriscono tipologie diverse di 276 documenti clinici (o riferimenti ad essi, o dati riassuntivi) in questo 277
campo: si va dalle prescrizioni specialistiche e di ricovero della British 278
Columbia, agli esami clinici e procedure della Finlandia, alle lettere di 279 dimissione e referti (lab analisi, radiologia) della Svezia, ai referti di 280
laboratorio e diagnostica e prescrizioni specialistiche degli USA. 281
Ciascun Patient Summary è inoltre, caratterizzato da campi specifici al Paese (o stato 282 componente). Quelli che appaiono più interessanti e utili, stanti le finalità del Patient 283
Summary sono i seguenti: 284
• Svezia: 285
o log degli accessi (accessibile solo dal paziente): in questo modo viene 286
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 13 di 64
offerta al paziente una maggiore garanzia di verificare chi ha acceduto 287
a quali dati, eseguendo quali operazioni. Tale facoltà è in accordo con 288
le linee guida del Gruppo di Lavoro dei Garanti privacy UE (Article 29 289 working party) 290
• Finlandia: 291
o scelta di donazione degli organi e testamento biologico 292
• British Columbia, Belgio: 293
o storia clinica del paziente 294
• USA: 295
o sezione a cura del cittadino, in cui può riportare i suoi dati, problemi, 296
ecc. 297
o storia sociale del paziente 298
o storia clinica del paziente (inclusi i contatti con strutture sanitarie) e 299 della sua famiglia 300
o segni vitali: altezza, peso, pressione sanguigna, temperatura, ritmo 301
cardiaco, data registrazione segni vitali, pulsiossimetria ecc. 302
o percorsi di cura, perizie mediche 303
o piano di cura raccomandato (testo libero) 304
o protesi, ausili, ecc. rilevanti per il paziente 305
Si noti che solo in Inghilterra e Scozia l’MMG/PLS è l’unico autore del Patient 306
Summary. Negli USA esso è compilato da ogni professionista sanitario coinvolto nella 307 continuità della cura (medici, infermieri, ecc.) esiste un campo per il medico "mittente" 308
e uno per il medico "destinatario". In British Columbia è compilato da ciascun 309 operatore di cura primaria. Per quanto riguarda Svezia, Finlandia e Belgio non è 310
indicato esplicitamente chi è l’autore del Patient Summary, ma dai documenti sembra 311 che ci possano essere più autori, incluso l’MMG/PLS 312
313
Per quanto riguarda gli standard utilizzati, Svezia e Belgio utilizzano un linguaggio 314
“proprietario” basato su XML, mentre gli altri utilizzano CDA2. Della Scozia non si sa 315 nulla. Si noti che gli USA utilizzano il CCD (Continuity of Care Document) 316
appositamente orientato a gestire documenti per la continuità della cura. 317
318
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 14 di 64
2 Contesto normativo nazionale 319
Nel panorama normativo nazionale relativo alla categoria dei medici di base esiste un 320
unico strumento denominato “Scheda Sanitaria Individuale” definito all’interno dell’ 321 Accordo Collettivo Nazionale per la Disciplina dei Rapporti con i Medici di Medicina 322
Generale ai sensi dell’art. 8 del D.Lgs. n. 502 del 1992 e successive modificazioni ed 323 integrazioni. 324
In particolare l’articolo 45 – Compiti del medico al comma 2 punto b) si precisa che 325
l’espletamento dei compiti di cui al comma 1 avviene anche attraverso “la tenuta e 326 l'aggiornamento di una scheda sanitaria individuale, su supporto informatico e tenuto 327
conto di quanto previsto dall’art. 59, lettera B, ad uso del medico e ad utilità 328 dell’assistito e del SSN, secondo standard nazionali e regionali e modalità definite 329
nell’ambito degli Accordi regionali, nonché l’utilizzazione della Carta nazionale dei 330 Servizi, prevista dal comma 9 art. 52 della Legge 27 Dicembre 2002, n. 289 e della 331
tessera del cittadino secondo quando previsto dall’art. 50 della Legge 24 novembre 332 2003 n. 326”. 333
Essa, nelle accezioni definite all’interno dell’ACN viene utilizzata nei seguenti casi 334
d’uso: 335
- dal medico che ha in cura l’assistito dal momento della scelta al momento della 336 revoca / morte (art. 45, comma 2, lettera b); 337
- dai medici nelle forme associative e per la continuità assistenziale.(art. 54 e 56); 338
- dai MMG nelle prescrizioni di ricovero ordinario (art. 51 comma 9 e allegato E). 339
Il modello e la struttura dei dati che devono essere contenuti all’interno della Scheda 340 Sanitaria Individuale non sono normati. All’interno dell’ACN si fa riferimento 341
esclusivamente ad una compatibilità generica del software nel caso della medicina di 342 gruppo (art. 54 comma 9 lettera f). 343
Il data set allegato ai capitolati Rete MMG5 aveva l’obiettivo di avviare un processo 344
anche di interoperabilità semantica a livello progettuale. 345
La Scheda Sanitaria Individuale è quindi l’unico documento sanitario al quale si può 346
fare riferimento per avviare un processo di costruzione del Patient Summary. In virtù 347 di questo deve essere verificata la potenziale succedanea valenza probatoria in caso di 348
giudizio di un Patient Summary. 349
5 Allegato C – Data Set di riferimento v.1.0 Prot. DIT/1884/05/III
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 15 di 64
3 Definizione Patient Summary 350
Nell’ambito UE viene data la seguente definizione6 351
A patient summary is defined as a clinical document that is digitally stored in repositories with 352 cumulative indexing systems and secure access by authorised people. It is based on full electronic 353 health record. In order to achieve maximum benefit from this instrument, the structured content of 354 patient summaries should be agreed at an international level, starting from a few generic summaries 355 and gradually developing a series of summaries specific for each clinical context. 356
357 Il gruppo di lavoro di progettazione condivisa del progetto Rete MMG ha definito il 358
Patient Summary come: 359
“un documento informatico sanitario, firmato digitalmente e contenuto nel FSE7, 360 che riassume la storia del paziente e la situazione corrente. Esso è creato ed 361 aggiornato dal MMG ogni qualvolta intervengono cambiamenti da lui ritenuti 362
rilevanti8 ai fini della storia del paziente. Contiene un set predefinito di dati clinici 363 significativi per l’emergenza (emergency data set)”. 364
3.1 Obiettivi del PS 365
Nell’ambito del progetto rete MMG gli obiettivi del PS possono essere: 366
1. rendere le informazioni disponibili per i contatti inattesi (emergenza/pronto 367 soccorso); 368
2. cura cronica prevista, controllo clinico; 369
3. continuità di cura nelle vie cliniche comuni; 370
4. uso medico legale 371
5. medicina di gruppo (SSI) 372
3.2 Principali casi d’uso 373
I principali casi d’uso possono essere sintetizzati in: 374
- situazioni di emergenza nelle quali il paziente non può presentare esaustivamente 375 la propria storia (problemi, allergie e farmaci correnti...) 376
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
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 16 di 64
- situazioni di necessità di continuità informativa, all'interno di gruppi di MMG, in 377
orari in cui il proprio medico non è disponibile 378
- pazienti gestiti da più professionisti nell'ambito di patologie croniche o anziani i 379
regime di assistenza domiciliare o residenziale 380
- supporto al processo diagnostico in corso di consulenza specialistica, teleconsulto 381
- continuità informativa tra MMG ed ospedale in situazione di ricovero (la 382 maggioranza dei ricoveri non viene decisa dal MMG) 383
La mappatura effettuata con il Gruppo informatico FIMMG delle classi informative 384
necessarie e correlate ai diversi casi d’uso ha tuttavia evidenziato la necessità di 385 strutturare i seguenti tre principali casi d’uso: 386
1. situazioni di emergenza e di pronto soccorso 387
2. situazione di continuità della cura per accessi programmati alle strutture 388 sanitarie (richieste di ricovero o di consulenze specialistiche) 389
3. continuità informativa all’interno dei gruppo di MMG ovvero in caso di revoca 390
della scelta del medico 391
3.3 Ciclo di vita dei documenti 392
Sia il documento Scheda Sanitaria Individuale che il documento Patient Summary 393
vengono creati al momento del primo contatto dell’assistito con il medico e viene 394 aggiornato e mantenuto dal medico stesso fino a quando ha in cura l’assistito. 395
Come tutti gli altri documenti strutturati, firmati digitalmente e referenziati 396
nell’infrastruttura di Fascicolo Sanitario Elettronico seguono le modalità di C-R-U-D 397 previste dall’infrastruttura. 398
3.4 Matrice delle classi informative per casi d’uso del PS 399
Al fine di procedere ad una prima ipotesi esaustiva per la strutturazione del 400
documento PS vengono riportate, nella tabella seguente, le classi di dati ritenute 401 rilevanti dal gruppo di lavoro Regioni e FIMMG. Esse vengono di seguito associate alle 402
macro aree della struttura del CCD/CCR e rappresentate nella successiva tabella di 403
sintesi. 404
Di seguito viene definita una prima ipotesi di relazione tra le classi informative ed i 405 casi d’uso selezionati che costituisce base di discussione a livello nazionale e regionale. 406
I campi contrassegnati con il simbolo X potrebbero essere considerati come 407
potenzialmente “obbligatori”. I campi contrassegnati con il simbolo ♦ potrebbero 408
essere considerati come potenzialmente opzionali9. 409
9 Le ipotesi presenti in qusta versione del documento sono state effettuate in collaborazione con il Gruppo Informatico
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 17 di 64
Nelle sezioni successive vengono inserite delle ipotesi di strutturazione delle sezioni e 410
dei campi da inserire nel CCD. Esse derivano da un processo di armonizzazione dei 411
contributi delle regioni, il data set dei capitolati rete mmg, le normativa di riferimento 412 e le necessità dello standard CCD. 413
Tabella 3 –Ipotesi selezione classi informative per casi d’uso 414
CLASSI INFORMATIVE PRINCIPALI SCENARI D’USO
ID Classi definite da GdL Patient Summary CCR/CCD
Emergenza / Pronto Soccorso
Continuità della
Cura10
Medicina di gruppo o di
rete11
1. 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
4. Allergie (farmacologiche) e reazioni avverse
Alerts x x x
5. Allergie (farmacologiche) e reazioni avverse
Alerts x x x
6. Lista problemi rilevanti e diagnosi codificate
Problems x x x
7. Accertamenti diagnostici rilevanti ai fini delle patologie riportate
Results x x x
8. Controlli pianificati a percorsi concordati per patologie croniche o particolari
Plan of Care ♦ x x12
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.) Vital signs ♦ ♦ x
13. Assenso/dissenso donazione d’organi parte del campo "Advanced Directives" x13 x x
14. Consenso/diniego accanimento terapeutico
parte del campo "Advanced Directives" x14 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
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
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 18 di 64
SEZIONE II. – STRUTTURAZIONE DEL DOCUMENTO 416
PATIENT SUMMARY IN CCD 417
418
1 Obiettivi 419
Di seguito viene presentato il modello di Patient Summary strutturato secondo lo 420
standard CCD. 421
Sulla base delle considerazioni effettuate nei paragrafi precedenti e in virtù del fatto 422 che il documento è realizzato nell’ambito del progetto rete MMG, ci si concentra sul 423
documento di Patient Summary redatto dal MMG/PLS per le emergenze. 424
Il documento di Patient Summary in formato CCD viene predisposto dal SW del 425 MMG/PLS, firmato secondo le modalità di firma elettronica/digitale previste dalla 426
normativa, e reso disponibile nel Fascicolo Sanitario Elettronico tramite le apposite 427 interfacce di servizio. 428
Il medico di emergenza tramite il SW da lui utilizzato recupera, in presenza 429 dell’assistito/assitibile e da lui autorizzato, il documento di Patient Summary CCD dal 430
FSE al fine di avere un chiaro quadro clinico del paziente per poter erogare la 431 prestazione necessaria. 432
Si noti che il presente documento non si sostituisce né al documento di 433
specifiche CCD, né al documento di specifiche HL7/CDA Rel2, che 434
rappresentano prerequisiti imprescindibili dalla corretta struttruazione del 435
Patient Summary. Pertanto, per tutto ciò che riguarda gli elementi non 436
indicati nel presente documento, si rimanda ai documenti di specifica degli 437
standard. 438
439
2 Header Patient Summary 440
Di seguito nella definizione della struttura del documento CDA sono omessi alcuni 441
attributi dei tag ed i relativi valori nel caso siano invariati rispetto ai valori di default 442
previsti da HL7 e a meno che la loro specificazione non sia assolutamente necessaria. 443 Pertanto dove l’attributo non è indicato non vuol dire che non esiste o non sia 444
necessario riportarlo ma semplicemente che l’attributo va valorizzato ( o considerato 445 da punto di vista applicativo) con il valore di default assegnato dallo standard HL7 –446
CDA Rel.2. 447
Si noti che poiché il CCD è derivato dal CDA, per quanto riguarda la struttura 448 dell’header valgono le stesse regole del CDA. 449
Commento [katiaC1]: check
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 19 di 64
Gli OID utilizzati per alcuni codici nel documento non sono ancora assegnati 450
o non hanno in alcuni casi la struttura corretta. La corretta assegnazione 451
sarà valutata in seguito anche in base alle modalità di articolazione di alcuni 452
rami della gerarchia degli OID HL7 al livello italiano. L’attuale ipotesi di 453
gerarchia è consultabile sul sito di HL7Italia all’indirizzo: 454
http://www.HL7italia.it/../MACROFUNZIONI/PUB/PUB_ELENCODOCUMENTI455
.ASP?RUBCERCAHIDE=HL7%20OID 456
457
2.1.1 Root del documento:<Clinical Document> 458
459
Elemento root per la struttura xml che rappresenta il documento CDA. 460 461
<ClinicalDocument xsi:schemaLocation="urn:hl7-org:v3 CDA.xsd" xmlns="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 462
2.1.2 Dominio: <realmCode> 463
Elemento OBBLIGATORIO che indica il dominio di appartenenza del documento. 464 465
Più precisamente indica l’esistenza di una serie di restrizioni applicate per il dominio 466 ITALIANO al profilo CCD. 467
468 469
Attributo Tipo Valore Dettagli
root CE IT Definisce l’id di contesto per l’Italia. 470 471
Uso: 472 <realmCode code=”IT” />
473
2.1.3 Identificativo CDA2: <typeId> 474
Elemento OBBLIGATORIO che indica che il documento è strutturato secondo le 475 specifiche HL7-CDA Rel 2.0 e più precisamente secondo lo schema della “CDA, Release 476
Two Hierarchical Description” 477
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 20 di 64
478
Il tag <typeId> è un valore del tipo HL7 “Instance Identifier” ed è composto da una 479
attributo root che riporta un codice OID, un attributo extension che riporta un codice 480
specifico. 481 482
Attributo Tipo Valore Dettagli
root OID 2.16.840.1.113883.1.3 Object Identifier di HL7 per i modelli registrati
extension ST POCD_HD000040
Codifica identificativa del “CDA Release Two Hierarchical Description” che è lo schema che contiene la gerarchia delle classi di un documento CDA
483 484
Uso: 485 <typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
486
2.1.4 Identificativo CDA2: <templateId> 487
Elemento OBBLIGATORIO che indica il template di riferimento per il documento 488
corrente. 489 490
Il tag <templateId> è un valore del tipo HL7 “Instance Identifier” ed è composto da 491
un attributo root che riporta un codice OID ed eventualmente un attributo extension 492
che riporta un codice specifico. 493 494
I template possono essere utilizzati per individuare, in relazione alla tipologia di 495 documento espresso dal tag <code> (vedi seguito), un insieme di restrizioni/linee 496
guida da applicare all’intero documento o ad una specifica sezione dello stesso. 497 498
499 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
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 21 di 64
question. 500 501
Nel caso specifico, essendo indicato dall’attributo <code> il codice relativo al 502
documento di “PATIENT SUMMARY”, l’attributo <templateID> identificherà la specifica 503
versione del template (schema-schematron) che deve essere utilizzata dal document 504
CONSUMER per la validazione del documento corrente. 505 506
L’attributo <templateId> può, nel nostro contesto, permettere la progressiva 507
evoluzione dei modelli di documento CDA utilizzati dalla sanità elettronica. Tramite la 508
combinazione dell’attributo <code>, che rimane costante per la medesima tipologia di 509
documento (ex: “PATIENT SUMMARY”), e l’attributo <templateID> che potrebbe 510
variare in relazione alla versione dello schema utilizzato per validare il documento, 511 (ex: versione 1.0 , 1.1 etc) è possibile da parte del document CONSUMER individuare 512
sempre lo specifico template di validazione della versione corrente di documento. 513 514
In ciascun documento CDA ci possono essere uno o più elementi <templateID>. In 515
particolare, è prevista dallo standard la possibilità di utilizzare template con diversi 516 livelli di granularità, potendo anche specificare template differenti in punti diversi del 517
documento. 518 519
Il document CONSUMER non deve identificare il documento tramite il 520 <templateID> ma esclusivamente tramite l’attributo <code>. 521
522
Il Patient Summary è caratterizzato da due elementi <templateID>: 523
524 Il primo elemento <template> è valorizzato secondo le regole di conformance 525
previste dall’implementation guide del CCD, ed è pertanto costituito dal solo elemento 526 <root> valorizzato come segue: 527
528 Attributo Tipo Valore Dettagli
Root OID 2.16.840.1.113883.10.20.1
OID del catalogo degli schemi dei template di documento per i documenti di Patient Summary (Rif: CCD –CONF-??)
extension15 ST - 529
15 Ipotesi – Codice composto PREFISSO: ITPRF CODICE: PSUM _GEN per il Patient Summary (generico) VERSIONE: “001” progressivo per il versioning dei template
Commento [dberardi2]: da inserire
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 22 di 64
530
il secondo definisce il documento di Patient Summary in ambito Italiano, in termini di 531
imposizione di una serie di costraint sul modello previsto dal CCD, ed è valorizzato 532 come segue: 533
534 Attributo Tipo Valore Dettagli
Root OID 2.16.840.1.113883.2.9.10.2.4 OID del catalogo degli schemi dei template di documento per i documenti di Patient Summary
extension16 ST “ITPRF_PSUM_GEN-001” Identificativo del template di documento PATIENT SUMMARY
535
Uso: 536 537
<templateId root= “<2.16.840.1.113883.10.20.1>”/> <templateId root="2.16.840.1.113883.2.9.10.2.4" extension=" ITPRF_PSUM_GEN-001"/>
538
2.1.5 Identificativo documento: <id> 539
Elemento OBBLIGATORIO che identifica univocamente l’istanza di ogni documento 540
CDA. 541 Il tag <id> è un valore del tipo HL7 “Instance Identifier” ed è composto da un 542
attributo root che riporta un codice OID, un attributo extension che riporta un codice 543 specifico e un attributo con il nome dell’authority che è responsabile della codifica 544
posta nel campo extension. 545 546
Come richiesto da HL7 ogni singola istanza di documento CDA (singolo patient 547 summary, singola prescrizione, singolo referto …) DEVE essere dotata di un 548
IDENTIFICATIVO UNIVOCO che andrà collocato nell’attributo <id> del documento. 549
550
Pertanto è necessario concordare un meccanismo di creazione di ID univoci a livello 551 nazionale necessari all’identificazione dei documenti sanitari presenti nell’FSE. Tale 552
meccanismo è riportato, insieme ad una ricognizione delle ipotesi al livello regionale, 553 nell’Appendice D del presente documento. 554
555 556
<id>: 557
Attributo Tipo Valore Dettagli
Commento [dberardi3]: check
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 23 di 64
root OID [OID identificativo della struttura di competenza]
OID della struttura cui appartiene l’autore del documento (vedi appendice A)
extension ST [IUD]
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)
assigningAuthorityName ST [NOME STRUTTURA DI COMPETENZA]
Nome struttura cui appartiene l’autore del documento
558 559 Uso: 560 <id root="2.16.840.1.113883.2.9.4.1.1.120111" extension="204.1234.20070327120000" assigningAuthorityName=”AUSL LATINA 1” />
561
562
563
2.1.6 Versione del documento: <setId> e <versionNumber> 564
Elemento OBBLIGATORIO che rappresenta un identificatore comune di tutte le 565
revisioni del documento. Il <setID> resta quindi costante tra le diverse versioni del 566 medesimo documento. 567
568 Se, per esempio, viene prodotto un documento di Patient Summary pubblicato nel FSE 569
e successivamente il document SOURCE, a causa di un errore o per altro motivo, 570 decide di modificarlo/sostituirlo, il nuovo documento di prescrizione avrà un <id> 571
univoco e diverso dal primo ed un <setID> uguale al primo documento pubblicato. 572 573 Lo standard prevede inoltre che il nuovo documento abbia una relazione di tipo 574 <relatedDocument> che punta al documento sostituito. 575
576 Anche il <setID> come l’<id> deve essere unico in uno spazio di dominio; pertanto è 577
OBBLIGATORIO che alla prima creazione del documento i campi <setID> ed <id> 578
siano valorizzati allo stesso modo con lo IUD generato. Successivamente nelle diverse 579
revisioni del documento si modificherà solo l’<id> con un nuovo IUD, mantenendo il 580
<setID> costante. 581
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 24 di 64
582 583 <setID>: 584
Attributo Tipo Valore Dettagli
root OID [OID identificativo della struttura di competenza]
OID della struttura cui appartiene l’autore del documento (vedi Appendice A)
extension ST [IUD] Identificativo univoco delle revisioni del documento
assigningAuthorityName ST [NOME STRUTTURA DI COMPETENZA]
Nome struttura cui appartiene l’autore del documento
585 586 <versionNumber>: 587
Attributo Tipo Valore Dettagli
value INT [progressivo versione documento]
Ad ogni successiva versione del documento (RPLC), tale numero incrementa di una unità (partendo da 1)
588
Uso: 589
<setId root="2.16.840.1.113883.2.9.4.1.1.120111" extension="204.1234.20070327120000.DW322" assigningAuthorityName=”AUSL LATINA 1” /> <versionNumber value=”1” />
590
591
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 25 di 64
592
Figura 4: versionamento del documento - Replace (estratto documentazione HL7) 593
594
2.1.7 Codice Documento:<code> 595
Elemento OBBLIGATORIO che indica la tipologia di documento. 596 L’attributo <code> riporta un codice che identifica la tipologia di documento a cui il CDA 597
si riferisce (Prescrizione, Referto di …., lettera di dimissione, patient summary) 598
599 Il valore DEVE fare riferimento al sistema di codifica LOINC 600
601 Nel caso del Patient Summary, le specifiche CCD impongono che il tag deve essere 602
così valorizzato : 603 604
605 606
607 608 609
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 26 di 64
<code>: 610
Attributo Tipo Valore Dettagli
codeSystem OID 2.16.840.1.113883.6.1 Codifica LOINC
code CS “34133-9” Codice relativo alla tipologia del documento. (“Summarization of episode note”)
codeSystemName ST LOINC codeSystemVersion ST 2.19 Versione codifica LOINC displayName ST “PATIENT SUMMARY” 611 612
Per individuare nel realm Italiano le successive tipologie di patient summary il codice 613 espresso nell’elemento <code> PUO’ essere tradotto in un codesystem definito in 614
ambito italiano e condiviso all’interno del dominio FSE. In tale contesto è quindi 615 ammesso l’utilizzo all’interno dell’elemento code di un <translation> che DEVE essere 616
così valorizzato: 617 618 <code><translation>: 619
Attributo Tipo Valore Dettagli
codeSystem OID 2.16.840.1.113883.2.9.4.4 Codifica LOINC
code CS “X-3400-4” or “X-3400-5”
Codice relativo alla specifica tipologia di documento.
codeSystemName ST ITCDADOC_TYPECODE codeSystemVersion ST 1 Versione codifica LOINC displayName ST “PATIENT SUMMARY” 620 Nota: Tale codice NON PUO’ mai confliggere con il codice LOINC “34133-9” 621
“Summarization of episode “note 622 623 Uso: 624 625 <id root="2.16.840.1.113883.2.9.2.150106" extension="150106.1001.000000005.2007032118.DW009" assigningAuthorityName="ASL Napoli 1"/> <code code="34133-9" codeSystem="2.16.840.1.113883.6.1" displayName="Summarization of episode note"> <translation code="X-3400-4" codeSystem="2.16.840.1.113883.2.9.4.4" codeSystemName="ITCDADOC_TYPECODE" codeSystemVersion="1"/>
Commento [dberardi4]: verificare
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.
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 27 di 64
</code> 626 627
628
2.1.8 Riservatezza del documento:<confidentialityCode> 629
Elemento OBBLIGATORIO che indica la riservatezza del documento. 630
631 Il tag <confidentialityCode> riporta un codice che identifica il livello di confidenzialità del 632
documento CDA secondo la codifica di “Confidentiality” di HL7 633
634
Code * Definition
N (normal) (codeSystem 2.16.840.1.113883.5.25)
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 2.16.840.1.113883.5.25)
Restricted access, e.g. only to providers having a current care relationship to the patient.
V (very restricted) (codeSystem 2.16.840.1.113883.5.25)
Very restricted access as declared by the Privacy Officer of the record holder.
635 636
Nel caso della prescrizione il tag deve essere così valorizzato : 637 638
Attributo Tipo Valore Dettagli codeSystem OID 2.16.840.1.113883.5.25 OID codifica
code ST “N” Normali regole di riservatezza
codeSystemName ST “Confidentiality” Nome della codifica 639
Uso: 640 641 <confidentialityCode code="N" codeSystem=”2.16.840.1.113883.5.25” codeSystemName =”
Confidentiality“ />
642 643 644
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 28 di 64
645
2.1.9 Data di creazione documento:<effectiveTime> 646
Elemento OBBLIGATORIO che indica la data di creazione del documento Patient 647 Summary in CDA. L’attributo <effectiveTime> rappresenta un codice temporale che 648
può essere strutturato secondo diverse modalità di codifica previste da HL7. 649 650
Tale valore deve essere quello del client utilizzato dal document SOURCE, 651 opportunamente certificato. 652
653 Nel caso della prescrizione l’attributo deve essere valorizzato tramite un tipo Time 654
Stamp (TS) come presentato di seguito: 655 656
657 Attributo Tipo Valore Dettagli
value TS [YYYYMMddhhmmss+|-ZZzz]
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 +0100. Ad esempio le 22.30.00 si indicano 21.30.00+0100
658
Uso: 659 660 <effectiveTime value="20000407130000+0100"/>
661 662
L’esempio indica le 14:00 00:(ora Italiana) del 07 Aprile 2000. 663 664
665 666
2.1.10 Lingua e Dominio: <languageCode> 667
Elemento FACOLTATIVO che indica la lingua in cui è redatto il documento. 668
L’attributo <languageCode> rappresenta un codice conforme alle specifiche dell’IETF 669
(Internet Engineering Task Force) RFC 3066 (OID: 2.16.840.1.113883.6.121) 670 671
Nel caso del Patient Summary il tag deve essere così valorizzato: 672
Attributo Tipo Valore Dettagli
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 29 di 64
code ST it-IT oppure it
L’attributo deve essere nella forma nn o nn-CC, dove nn è la codifica ISO-639-1 della lingua in minuscolo e CC è la codifica ISO-3166 dello Stato in maiuscolo
673
Uso: 674 <languageCode code="it-IT"/>
675 676
677 678
2.1.11 Destinatario: <recordTarget> 679
Elemento OBBLIGATORIO che identifica il soggetto cui si riferisce il Patient Summary. 680 681
Il <recordTarget> è un elemento composto da un ruolo <patientRole> verso 682
un’entità <patient>. 683
684
Per il Patient Summary l’elemento deve pertanto essere strutturato come segue: 685
<recordTarget> <patientRole> <patient>...</patient> <patientRole> <recordtarget> 686 687
2.1.11.1 <patientRole> 688
Il ruolo <patientRole> deve prevedere genericamente al suo interno almeno un 689
elemento di tipo <id> destinato ad accogliere la chiave identificativa del paziente, 690
secondo gli schemi assegnati da ogni singola regione ed un elemento di tipo <id> 691 destinato ad accogliere le informazioni relative al codice fiscale. 692
693
Diverse sono tuttavia le casistiche possibili e le relative eccezioni, in dipendenza dalla 694
tipologia di soggetto in esame; tali casistiche possono essere così sintetizzate: 695
696 1. Soggetti assicurati da istituzioni estere: 697
698
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 30 di 64
<patientRole> DEVE riportare un elemento di tipo <id> contenente: 699
1. Numero di identificazione personale ed il codice dell’istituzione competente 700 2. Numero di identificazione della Tessera Sanitaria 701
702 <id>: 703
Attributo Tipo Valore Dettagli
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
704 Uso: 705
<id root=”2.16.380” extension=”CRLLNZ99M99F999T-80380001207300055794” assigningAuthorityName=”SSN-MIN SALUTE#500001”> 706
707 2. Cittadino italiano o straniero residente (iscritto SSN): 708
709 Due elementi di tipo <id> contenenti: 710
1. Il codice assegnato dall’anagrafica regionale (FACOLTATIVO) 711 2. Il codice fiscale del paziente (OBBLIGATORIO) 712
713 Primo <id>: 714
Attributo Tipo Valore Dettagli
root OID 2.16.840.1.113883.2.9.[REGIONE].4.1
OID schema di identificazione regionale
extension ST [CODICE IDENTIFICATIVO] Codice anagrafica regionale
715 716 Secondo <id>: 717
Attributo Tipo Valore Dettagli
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 31 di 64
root OID 2.16.840.1.113883.2.9.4.3.2 OID Ministero economia e finanze – CF
extension ST [CODICE FISCALE] CF del paziente
assigningAuthorityName ST “MEF” Ministero dell’Economia e delle Finanze
718 Uso: 719
<recordTarget> <patientRole> <id root="2.16.840.1.113883.2.9.90.4.1" extension="83741345" azssigningAuthorityName="Regione Toscana" /> id root="2.16.840.1.113883.2.9.4.3.2" extension="CRLLNZ99M22G999T" assigningAuthorityName="MEF"/> <patient>…………</patient> </patientRole> </recordTarget> 720 721
2.1.11.2 <patient> 722
L’entità <patient> contiene i dettagli anagrafici relativi al paziente. 723
Riporta alcuni attributi OBBLIGATORI con l’indicazione dei dati anagrafici, quali in 724
particolare <name> (con i componenti <family> e <given>), 725
<administrativeGenderCode>. E’ inoltre FACOLTATIVO inserire il luogo di nascita 726
nell’attributo <birthplace>. 727
728 Uso: 729
<recordTarget> <patientRole> <id ../> <id ../> <patient> <name> <family>Guido</family> <given>Rossi</given> </name> <birthPlace> <place> <addr>....</addr> </place>
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 32 di 64
</birthPlace> <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/> </patient> </patientRole> </recordTarget>
730 Nel caso di documenti per le quali sia prevista la possibilità di anonimato in 731
ottemperanza a quanto previsto dal dall’art. 87 nella nuova disciplina sulla Privacy 732 (D.Lgs. 30 giugno 2003 n. 196) gli attributi anagrafici <name> e <birthplace>, 733
qualora presente, vanno riportati sprovvisti di valori ma ambedue decorati con 734
l’attributo nullFavour=”MSK” per permetterne la comprensione al document consumer. 735 736 Nessu ulteriore utilizzo/valore dell’attributo NULLFLAVOR è ammesso. 737 738
Uso: 739 740 <recordTarget> <patientRole> <id ../> <id ../> <id…/> <patient> <id root="2.16.840.1.113883.2.9.4.3.2" extension="CRLLNZ99M22G999T" assigningAuthorityName="MEF"/> <name nullFlavor=”MSK”> <birthplace nullFlavor=”MSK”> </patient> </patientRole> </recordTarget>
741
2.1.12 Custode: <custodian> 742
Elemento OBBLIGATORIO che identifica l’organizzazione incaricata della custodia del 743 documento originale. Tale organizzazione è la struttura di cui fa parte colui che ha 744
creato il documento (MMG -ASL, Altro Medico redattore del Patient Summary–AO,..). 745 746
Il <custodian> è un elemento composto da un ruolo di tipo <assignedCustodian> 747
verso un’entità <representedCustodianOrganization>. 748
749
L’elemento viene pertanto ad essere strutturato come segue: 750
<custodian> <assignedCustodian>
Commento [dberardi7]: Verificare se ha senso l’anonimato anche per il Patient Summary
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 33 di 64
<representedCustodianOrganization> </representedCustodianOrganization> </assignedCustodian> </custodian> 751 752
2.1.12.1.1 <representedCustodianOrganization> 753
La classe <representedCustodianOrganization> deve pertanto contenere al suo 754
interno un <id> che riporta l’identificativo della struttura a cui fa capo il documento. 755 756
Attributo Tipo Valore Dettagli
root OID 2.16.840.1.113883.2.9. [ASL/AO] OID ASL/AO
extension ST [ID STRUTTURA] Struttura che ha prodotto il documento - Da definire
757 Per le strutture che ricadono sotto la competenza delle ASL/AO è pertanto previsto che 758
sia asegnato da parte di queste, dove non già esistente, un identificativo univoco. 759 760 Uso: 761 <custodian> <assignedCustodian> <representedCustodianOrganization> <id root="2.16.840.1.113883.2.9.4.1.1.120111” extension="123456789"/> <name>AUSL Latina</name> </representedCustodianOrganization> </assignedCustodian> </custodian> 762 763 764 765
2.1.13 Autore e autenticatore: <author> e 766
<legalAuthenticator> 767
2.1.13.1 Autore: <author> 768
769
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 34 di 64
Elemento OBBLIGATORIO che identifica il soggetto che ha creato il documento. Esso 770
può essere una persona o una macchina. 771
L’autore può essere identificato da uno o più <id>. 772
La classe DEVE contenere un attributo <time> OBBLIGATORIO con l’indicazione 773
dell’ora di produzione del documento: la valorizzazione viene effettuata come nel caso 774
dell’attributo <effectiveTime>. 775
776 <time>: 777
Attributo Tipo Valore Dettagli
value TS [YYYYMMddhhmmss+|-ZZzz]
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 +0100. Ad esempio le 22.30.00 si indicano 21.30.00+0100
778
779 Primo <id>: 780
Attributo Tipo Valore Dettagli
root OID 2.16.840.1.113883.2.9.4.3.2 OID Ministero economia e finanze – CF
extension ST [CODICE FISCALE]
Codice Fiscale dell’autore del documento
781 782 Secondo <id>: 783
Attributo Tipo Valore Dettagli
root OID 2.16.840.1.113883.2.9.[REGIONE].4.2
OID schema di identificazione regionale operatori
extension ST [CODICE IDENTIFICATIVO] Codice anagrafica regionale operatori 784 Uso: 785
<author> <time value="20000407130000+0100"/> <assignedAuthor> <id root="2.16.840.1.113883.2.9.4.3.2" extension="CRLLNZ99M22G999T"/> <id root="2.16.840.1.113883.2.9.90.4.2" extension="87245"/>
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 35 di 64
</assignedAuthor> </author>
786 787 788
2.1.13.2 Firmatario del documento: <legalAuthenticator> 789
Elemento OBBLIGATORIO che riporta il firmatario del documento. Se il documento è 790
generato da una macchina, il responsabile del documento è l’organizzazione 791
responsabile per la generazione del documento. 792 793
La classe DEVE contenere un tag <time> OBBLIGATORIO con l’indicazione dell’ora di 794
produzione del documento (la valorizzazione viene effettuata come nel caso 795 dell’attributo <effectiveTime>), un’attributo <signatureCode>, ed un’ 796
<assignedEntity> destinato ad accogliere l’<id> del prescrittore. 797
798 Per le modalità di firma del documento (XML-Signature Enveloped), si vedano le 799
indicazioni riportate nell’appendice C. 800 801 <time>: 802
Attributo Tipo Valore Dettagli
value TS [YYYYMMddhhmmss+|-ZZzz]
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 +0100. Ad esempio le 22.30.00 si indicano 21.30.00+0100
803 <signatureCode>: 804
Attributo Tipo Valore Dettagli
code ST “S” Codice che indica che il documento è firmato digitalmente
805 <assignedEntity><id>: 806
Attributo Tipo Valore Dettagli
root OID 2.16.840.1.113883.2.9.4.3.2 OID Ministero economia e finanze - CF
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 36 di 64
extension ST [CODICE FISCALE]
807
808
809
Uso: 810
811
Uso nel caso in cui l’autore del documento sia una macchina: 812
<legalAuthenticator> <time value="20000407130000+0100"/> <signatureCode code="S" /> <assignedEntity classCode="ASSIGNED "> <id root="2.16.840.1.113883.2.9.4.3.2” extension="CRLLNZ99M22G999T" /> <assignedPerson> <name> <given>Guido</given> <family>Rossi</family> <suffix>Dott.</suffix> </name> </assignedPerson> </assignedEntity> </legalAuthenticator>
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 37 di 64
813 814
2.1.14 EventoClinico: <documentationOf> e <serviceEvent> 815
Il documento di Patient Summary costituisce una vista delle cure cui si è sottoposto un 816 paziente durante un determinato periodo di tempo, che per il contesto in esame, 817
potrebbe anche coincidere con l’intero arco di vita. In conformità con quanto previsto 818 dalla guida di implementazione di CCD, la durata dell’arco temporale cui il Patient 819
Summary si riferisce viene veicolata all’interno degli elementi (OBBLIGATORI) 820 <documentationOf> e <serviceEvent>. 821
822 L’elemento <documentationOf> deve essere strutturato come segue: 823
<documentationOf> <serviceEvent> … </serviceEvent> </documentationOf> 824 825
<author> <time value="20000407130000+0100"/> <assignedAuthor> <id root="2.16.840.1.113883.2.9.4.3.2” extension="CRLLNZ99M22G999T" /> <assignedAuthoringDevice> <softwareName>Sistema di Patient Summary v1.0</softwareName> </assignedAuthoringDevice> <representedOrganization> <id root="2.16.840.1.113883.2.9.4.1.1.120111” extension="123456789"/> <name>AUSL Latina</name> </representedOrganization> </assignedAuthor> </author> <legalAuthenticator> <time value="20000407130000+0100"/> <signatureCode code="S"/> <assignedEntity> <id nullFlavor="NI"/> <representedOrganization> <id root="2.16.840.1.113883.2.9.4.1.1.120111” extension="123456789"/> <name>AUSL Latina</name> </representedOrganization> </assignedEntity> </legalAuthenticator>
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 38 di 64
826 827
2.1.14.1 <serviceEvent> 828
Nel caso di Patient Summary rappresenta semplicemente l’arco temporale a cui si 829
riferisce il Patient Summary unitamente all’insieme dei principali operatori sanitari 830 (caregivers) nel medesimo periodo di riferimento 831
832 <ServiceEvent>: 833
834
Attributo Tipo Valore Dettagli
classCode CS “PCPR”
Codice che identifica l’evento da cui ha origine il PS
835
L’intervallo di durata dell’evento in seguito al quale è stato redatto il Patient Summary 836 è rappresentato mediante un elemento <effectiveTime>. 837
838 <effectiveTime xsi:type=’IVL_TS’>: 839 840 Attributo Tipo Valore Dettagli
low TS [YYYYMMddhhmmss]
inizio intervallo. Per Patient Summary generici può essere la data di nascita del paziente. Per Patient Summary specifici può essere l’inizio dell’evento di cura o della patologia.
high TS [YYYYMMddhhmmss]
fine intervallo. Per Patient Summary generici può essere la data in cui è stato redatto il Patient Summary. Per Patient Summary specifici può essere la fine dell’evento di cura o della patologia, o la data di redazione del Patient Summary.
841
E’ possibile aggiungere ulteriori dati anche al di fuori di questo intervallo di tempo se 842 rilevanti rispettal alla cura fornita in quell’intervallo di tempo. 843
844
845
846 Uso: 847 848
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 39 di 64
<documentationOf> <serviceEvent classCode="PCPR"> <effectiveTime> <low value="19320924"/><high value="20000407"/> </effectiveTime> </serviceEvent> </documentationOf>
849 850
2.1.15 Destinatario del documento: <informationRecipient> 851
Elemento OPZIONALE che rappresenta il destinatario del documento. 852 853
E’ rappresentato mediante uno o più elementi ClinicalDocument / 854 informationRecipient. 855 856 857
2.1.16 Contatti: <guardian> e <participant> 858
Elemento OBBLIGATORIO che rappresenta le persone da contattare ad esempio nel 859 caso in cui il paziente sia minore oppure nel caso in cui non sia in grado di intendere o 860
volere. Nel primo caso il contatto è il tutore legale, nel secondo il contatto può essere 861 un familiare, un parente, assistenti sociali, organizzazioni di volontariato/religiose, ecc. 862
Se conosciuto, DEVE essere indicato almeno un contatto. 863
2.1.16.1 Tutore legale: <recordTarget>…..<guardian> 864
Elemento OPZIONALE che rappresenta il tutore legale. 865 866
Il tutore legale può essere una persona (istanza della classe Person) o 867 un’organizzazione (istanza della classe Organization) aventi il ruolo di Tutore 868
rappresentato dalla classe Guardian, classCode=”GUAR”, per un determinato paziente 869 (istanza della classe Patient). 870 871 Un <guardian> PUO’ essere caratterizzato un <id> costruito come segue: 872 873 <id>: 874
Attributo Tipo Valore Dettagli
root OID 2.16.840.1.113883.2.9.4.3.2 OID Ministero economia e finanze – CF
extension ST [CODICE FISCALE] CF del paziente
Commento [dberardi8]: Analizzare il caso di assenza di contatti da indicare: si forniscono I contatti delle organizzazioni socio-sanitarie?
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 40 di 64
assigningAuthorityName ST “MEF” Ministero dell’Economia e delle Finanze
875
In assenza di un codice identificativo utilizzabile o conosciuto, l’<id> di <guardian> 876
deve riportare un nullFlavor con valore ”UNK” 877
E’ comunque OBBLIGATORIO che siano riportati i dettagli del Tutore Legale 878
valorizzando nella classe <guardian>, <guardianPerson>, nel caso di PERSONE, 879 <guardianOrganzation> in caso di ORGANIZZAZIONI e gli elementi <addr> e 880
<telecom>. 881
882
Uso: 883 <recordTarget> <patientRole> <patient> <guardian> <id root="2.16.840.1.113883.2.9.4.3.2" assigningAuthorityName=" MEF" extension="CRLLNZ73M22F839T"/> <addr use="H"> <streetAddressLine>via</streetAddressLine> <streetAddressLine>roma</streetAddressLine> <streetAddressLine>23</streetAddressLine> <postalCode>00100</postalCode> <city> ROMA</city> <county>RM</county> <country>ITALIA</country> <state>IT</state> </addr> <telecom use="H" value="tel:(+39)-349-3071-281"/> <guardianPerson> <name> <family>Lorenzi</family> <given>Lorenzo</given> </name> </guardianPerson> </guardian> ….. 884 885
2.1.16.2 Altri Contatti: …. <participant> 886
887
Elemento OBBLIGATORIO che identifica il contatto di un paziente (un familiare, un 888 parente, assistenti sociali, organizzazioni di volontariato/religiose, ecc.), diverso dal 889
tutore legale. 890 891
Commento [dberardi9]: Vedi commento precedente
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 41 di 64
Un paziente può essere caratterizzato da uno o più contatti. La tipologia di contatto 892
viene determinata in prima istanza attrverso il classCode dell’ <associatedEntity> 893
894 895
Un <participant> PUO’ essere classificato come parente, contatto di emergenza, o, 896 genericamente, chi fornisce assistenza ad anziani/malati (infermiere, badante, ecc.). 897
898 L’attributo <typecode> dell’elemento <participant> DEVE essere sempre valorizzato 899
con “IND” ad indicare una partecipazione “INDIRETTA” all’atto. 900 901
Per tutti gli i contatti è OBBLIGATORIO riportare sempre valorizzati gli elmenti 902 <addr> e <telecom>, nonché i dettgli anagrafici 903
<associatedPerson><name><family> e <associatedPerson><name><given> relativi 904 al contatto Parenti. 905
906
2.1.16.2.1 Parenti 907
908
I contatti di tipo “Parente” sono i familiari, i parenti più o meno stretti, ecc. Sono 909 caratterizzati dai seguenti valori: 910 911 912 <associatedEntity >: 913
Attributo Tipo Valore Dettagli
classCode CS “NOK” Codice che identifica il contatto “Parente ” (Next Of Kin)
914
<code> DOVREBBE essere valorizzato come indicato in tabella: 915
Attributo Tipo Valore Dettagli
code CS [codice Tipo Parente] Codice che identifica il tipo di relazione col paziente
codeSystem OID 2.16.840.1.113883.1.11.19579 oppure 2.16.840.1.113883.1.11.20.21
OID – che identifica la codifica
codeSystemVersion ST 1 Versione codifica
codeSystemName ST [Tipo Parente] -
Commento [lcerulli10]: OID non assegnati Individuare dizionario codifica
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 42 di 64
916
917
PUO’ essere caratterizzata da un <id> che se presente DEVE essere valorizzato come 918 segue: 919
920
<id>: 921 Attributo Tipo Valore Dettagli
Root OID 2.16.840.1.113883.2.9.4.3.2 OID Ministero economia e finanze – CF
Extension ST [CODICE FISCALE] CF del paziente
assigningAuthorityName ST “MEF” Ministero dell’Economia e delle Finanze
922
Nel caso l’<id> non sia conosciuto questo va riportato con l’attributo nullFlavor 923 valorizzato con “UNK”. 924
925
2.1.16.2.2 Emergenza 926
927
I contatti di tipo “contatto di emergenza” sono i contatti da chiamare nel caso di 928 emergenza. 929
930 < associatedEntity >: 931
932
Attributo Tipo Valore Dettagli
classCode CS “ECON” Codice che identifica il “Contatto di Emergenza“ (Emergency CONtact)
933
934 PUO’ essere caratterizzata da un <id> che se presente DEVE essere valorizzato come 935
segue: 936 937
<id>: 938 Attributo Tipo Valore Dettagli
Root OID 2.16.840.1.113883.2.9.4.3.2 OID Ministero economia e finanze – CF
Extension ST [CODICE FISCALE] CF del paziente
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 43 di 64
assigningAuthorityName ST “MEF” Ministero dell’Economia e delle Finanze
939 Nel caso l’<id> non sia conosciuto questo va riportato con l’attributo nullFlavor 940
valorizzato con “UNK”. 941 942
943
2.1.16.2.3 Assistenza Malati ed Anziani 944
945
I contatti di tipo “assistenza ad anziani e malati” sono tutti coloro che prestano 946 assistenza (infermiere, badante, ecc.) 947 948 949 < associatedEntity >: 950
Attributo Tipo Valore Dettagli
classCode CS “CAREGIVER” Codice che identifica il contatto “Assistenza ad Anziani e Malati” (Caregiver)
951 PUO’ essere caratterizzata da un <id> che se presente DEVE essere valorizzato come 952
segue: 953 954
<id>: 955 Attributo Tipo Valore Dettagli
Root OID 2.16.840.1.113883.2.9.4.3.2 OID Ministero economia e finanze – CF
Extension ST [CODICE FISCALE] CF del paziente
assigningAuthorityName ST “MEF” Ministero dell’Economia e delle Finanze
956 Nel caso l’<id> non sia conosciuto questo va riportato con l’attributo nullFlavor 957
valorizzato con “UNK”. 958 959
Uso: 960 <participant typeCode="IND"> <associatedEntity classCode="CAREGIVER"> <id root="2.16.840.1.113883.2.9.4.3.2” extension="RSSMRA56L20F839C" /> <addr> <streetAddressLine>via Salaria, 23</streetAddressLine>
Commento [dberardi11]: Valutare se è opportuno restringere ai soli medici, In tal caso l’<id> DEVE essere presente e coincidere con il codice operatore
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 44 di 64
<city>Roma</city> <postalCode>00168</postalCode> </addr> <telecom value="tel:0635367898"/> <associatedPerson> <name> <given>Mario</given> <family>Rossi</family> </name> </associatedPerson> </associatedEntity> </participant> <participant typeCode="IND"> <associatedEntity classCode="NOK"> <id root="2.16.840.1.113883.2.9.4.3.2” extension="TRSBLM71E57A662F" /> <code code="65656005" codeSystem="2.16.840.1.113883.6.96" displayName="Madre Naturale"/> <telecom value="tel: 0654981932"/> <associatedPerson> <name> <given>Teresa</given> <family>Bellomo</family> </name> </associatedPerson> </associatedEntity> </participant> 961 962 963 964 965
966
2.2 Body documento Patient Summary 967
In questa sezione si definisce il BODY del documento Patient Summary, in formato 968 strutturato, composto dalla classe <structuredBody> che tramite una relazione di 969
<component> contiene una o più sezioni di tipo <section> che riportano il contenuto 970
effettivo del patient summary. 971
972
Nota: Per il dominio italiano si prevede che il livello minimo di strutturazione 973
del CDA sia HL7 – LIVELLO 2. 974 975
976
Commento [dberardi12]: Vengono inserite delle ipotesi di strutturazione delle sezioni e dei campi da inserire nel body. Le regioni sono invitate a redigere e compilare le tabelle laddove mancanti o incomplete.
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 45 di 64
977 978
979 Uso: 980
981
<component> <structuredBody moodCode="EVN" classCode="DOCBODY"> <component> <section ID=” ALLERGIE/REAZIONI AVVERSE”> ………. </section> </component> <component> <section ID=“ LISTA PROBLEMI/DIAGNOSI”> ………. </section> </component> <component> <section ID…”> ………. </section> </component> </structuredBody> </component>
982
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 46 di 64
La classe <section> è una classe composta che prevede un’attributo <text> (livello 1) 983
OBBLIGATORIO ed utilizzato per la descrizione narrativa del contenuto della sezione ( 984 che può a sua volta essere organizzato attraverso dei delimitatori di lista <list> ed 985
<item>) , un’attributo <code> (livello 2) OBBLIGATORIO che specifica il codice della 986
tipologia di sezione e uno o più elementi <entry> FACOLTATIVE che ne definiscono il 987
contenuto (livello 3). 988
989 990
991
2.2.1 Allergie e reazioni avverse 992
Sezione OBBLIGATORIA che individua una sezione del documento contenente 993
informazioni relative alle eventuali allergie e reazioni avverse ai farmaci, ai mezzi di 994 contrasto, o ad altre sostanze. Le intolleranze alimentari NON DEVONO essere inserite 995
in questa sezione, ma nella sezione Problemi. E’ NECESSARIO indicare esplicitamente 996 l’assenza di allergie o reazioni allergiche conosciute. 997
La sezione è individuata da un elemento <templateId root="2.16.840.1.113883.10.20.1.2"/> . 998
InoltRe, contiene un elemento <text> OBBLIGATORIO. L’elemento <text> DEVE 999
contenere al suo interno la descrizione narrativa dell’allergia o reazione allergica 1000
(livello 1): si dovrebbe indicare la sostanza scatenante (es. Penicillina), il tipo di 1001
reazione (es. vomito) ed eventualmente lo stato (Attivo, Non più attivo, ecc.) dello 1002 scopo del documento (Livello 1). PUO’ essere strutturato come tabella, come di 1003
seguito indicato: 1004 Uso: 1005
<text> <table border="1" width="100%"> <thead> <tr><th>Sostanza scatenante </th><th>Reazione </th><th>Stato</th></tr> </thead> <tbody> <tr><td>Penicillina</td><td>Orticaria</td><td>Active</td></tr> <tr><td>Acido Acetilsalicilico</td> <td>Respiro Affannoso</td> <td>Attivo</td></tr> <tr><td>Bario</td><td>Nausea</td><td>Attivo</td></tr> </tbody> </table> </text>
1006
1007 La sezione è individuata da un elemento <code> (livello 2) che ne specifica il contenuto 1008
che è così strutturato: 1009
1010
<section><code>: 1011
Commento [katiaC13]: verificare la codifica. Nel presente paragrafo si considerano solo allergie e reazioni avverse a sostanze farmacologiche
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 47 di 64
1012
Attributo Tipo Valore Dettagli
code CS “ALLERGIE/REAZIONI AVVERSE”
Codice che identifica il contenuto della sezione
codeSystem OID 2.16.840.1.113883.6.1 Codifica LOINC
codeSystemName ST LOINC -
codeSystemVersion ST 2.19 Versione codifica
1013 1014 1015
Per il livello machine readable (livello 3), ciascuna allergia/reazioni allergica viene 1016 rappresentata tramite un’<entry> che ripota un <act> generico che racchiude al suo 1017
interno un’ <observation>, che descrive il tipo di problema (reazione allergica), la 1018
sostanza scatenante (racchiusa all’interno di un elemento <participant>), il tipo di 1019 reazione (rappresentata mediante un’observation che ha una relazione con la prima 1020
observation di tipo manifest), e lo stato (anch’essa rappresentata mediante 1021 un’observation). Ciascuna allergia/reazione DEVE essere rappresentata mediante la 1022
struttura e i valori riportati nel riquadro seguente 1023
1024 Uso: 1025
<entry typeCode="DRIV"> <act classCode="ACT" moodCode="EVN"> <templateId root='2.16.840.1.113883.10.20.1.27'/> <!—- Allergia--> <id root="36e3e930-7b14-11db-9fe1-0800200c9a66"/> <code nullFlavor="NA"/> <entryRelationship typeCode="SUBJ"> <observation classCode="OBS" moodCode="EVN"> ..................<!—- Tipo di reazione es reazione allergica a sostanza --> <participant typeCode="CSM"> ..................<!—- Sostanza scatenante --> </participant> <entryRelationship typeCode="MFST" > <observation classCode="OBS" moodCode="EVN"> ..................<!—- reazione allergica --> </observation> </entryRelationship> <entryRelationship typeCode="REFR"> <observation classCode="OBS" moodCode="EVN"> ..................<!—- Stato dell’allergia -->
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 48 di 64
</observation> </entryRelationship> </observation> </entryRelationship> </act> </entry>
1026
Si noti in particolare che <act><code> DEVE essere valorizzato con “NA” (Not 1027
Applicable). 1028 1029
Il tipo di reazione DEVE essere contenuto all’interno di una section <observation> che 1030
DEVE avere il tag templateID valorizzato con ‘2.16.840.1.113883.10.20.1.18’. Inoltre 1031
DEVE contenere i tag 1032
<observation> <code>: 1033
Attributo Tipo Valore Dettagli
Code CS “ASSERTION” Codice
codeSystem OID 2.16.840.1.113883.5. 14 OID ActCode
codeSystemName ST ActCode
1034
<observation> <statusCode> 1035
Attributo Tipo Valore Dettagli
Code CS “Completed” Codice
codeSystem OID 2.16.840.1.113883.5. 4 OID StatusCode
codeSystemName ST StatusCode
1036
Il valore dell’observation può essere codificato con SNOMED o con una codifica 1037 equivalente da individuare: 1038
<value> 1039
Attributo Tipo Valore Dettagli
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 49 di 64
Code CS [TIPO DI REAZIONE ALLERGICA] Codice da individuare
codeSystem OID 2.16.840.1.113883.6.96 o code system equivalente da individuare
OID-SNOMED o di un code system equivalente da individuare
codeSystemName ST “SNOMED” o equivalente -
SystemVersion ST [VERSIONE DEL SISTEMA DI CODIFICA]
1040
Si noti che nel caso in cui non vi siano allergie, E’ NECESSARIO indicare esplicitamente 1041
che “Non vi sono reazioni allergiche conosciute. 1042
L’observation che descrive la reazione allergica PUO’ contenere un elemento di tipo 1043 <effectiveTime> che indica il tempo associate alla reazione, ad esempio la data in cui si 1044
è presentata la durata dei sintomi, ecc. 1045
1046
Uso: 1047
<entry typeCode="DRIV"> <act classCode="ACT" moodCode="EVN"> <templateId root='2.16.840.1.113883.10.20.1.27'/> <!—- Allergia--> <id root="36e3e930-7b14-11db-9fe1-0800200c9a66"/> <code nullFlavor="NA"/> <entryRelationship typeCode="SUBJ"> <observation classCode="OBS" moodCode="EVN"> <templateId root='2.16.840.1.113883.10.20.1.18'/><!—- Tipo di reazione es reazione allergica a sostanza --> <id root="4adc1020-7b14-11db-9fe1-0800200c9a66"/> <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/> <statusCode code="completed"/> <value xsi:type="CD" code="282100009" codeSystem="2.16.840.1.113883.6.96" displayName="Reazione a sostanza avversa "/> ............................................ </observation> </entryRelationship> </act> </entry>
1048 1049
1050
1051
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 50 di 64
Una observation che descrive un’allergia DOVREBBE contenere almeno una sezione di 1052
tipo <participant>, che DEVE contenere la sostanza scatenante all’interno di una 1053
sezione <playingEntity>. I campi DEVONO essere valorizzati come segue: 1054
1055
<participant> 1056
Attributo Tipo Valore Dettagli
typeCode CS “CSM” Rappresenta il fatto che che il farmaco/i mezzo di contrasto DEVE essere “Consumable”
1057 1058
<participantRole> 1059
Attributo Tipo Valore Dettagli
classCode CS “MANU” Rappresenta il fatto che il farmaco/il mezzo di contrasto dovrebbe essere “Manufactured”
1060 <playingEntity>: 1061
Attributo Tipo Valore Dettagli
Code CS ““MMAT””
Indica il fatto che la sostanza scatenante (contenuta nel farmaco/ o nel mezzo di contrasto) è un materiale manufatto (“Manufactured Material”)
1062
La sostanza scatenante DEVE essere codificata come segue: 1063
1064
<code>: 1065
Attributo Tipo Valore Dettagli
code CS [AGENTE SCATENANTE] “Agente Scatenante”
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 51 di 64
codeSystem OID 2.16.840.1.113883.6.73 oppure 2.16.840.1.113883.2.9.6.1.5
OID codice - ATC (da preferire) oppure AIC
codeSystemName ST “ATC” oppure “AIC”
codeSystemVersion ST 1
1066
Uso: 1067
<participant typeCode="CSM"> <participantRole classCode="MANU"> <playingEntity classCode="MMAT"> <code code="12345" codeSystem="2.16.840.1.113883.6.73" displayName="Acido Acetilsalicilico"/> </playingEntity>
1068 1069
Una observation che descrive un’allergia PUO’ contenere una o più osservazioni di 1070 reazioni allergiche observations (templateId 2.16.840.1.113883.10.20.1.54), ciascuna 1071
delle quail PUO’ contenere esattamente una observation di criticità (templateId 1072 2.16.840.1.113883.10.20.1.55). 1073
L’observation che rappresenta la (modalità di) reazione è associata all’observation che 1074
rappresenta l’allergia, mediante una relazione di tipo manifest (<entryRelationship 1075 typeCode="MFST" >) 1076 1077 <observation>: 1078
Attributo Tipo Valore Dettagli
classCode x_ActClassDocumentEntryAct “OBS” Tiplogia di osservazione di tipo generico
moodCode x_DocumentActMood “EVN” -
1079
La reazione DEVE avere il tag templateID valorizzato con ‘2.16.840.1.113883.10.20.1.54. 1080
Inoltre DEVE contenere il tag 1081
<observation> <code>: 1082
Attributo Tipo Valore Dettagli
Commento [dberardi14]: OID non ancora assegnato
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 52 di 64
Code CS “ASSERTION” Codice
codeSystem OID 2.16.840.1.113883.5. 14 OID ActCode
codeSystemName ST ActCode
1083
<observation> <statusCode> 1084
Attributo Tipo Valore Dettagli
Code CS “Completed” Codice
codeSystem OID 2.16.840.1.113883.5. 4 OID StatusCode
codeSystemName ST StatusCode
1085
Il valore dell’observation può essere codificato con SNOMED o con una codifica 1086
equivalente da individuare: 1087
<value> 1088
Attributo Tipo Valore Dettagli
Code CS [REAZIONE ALLERGICA] Codice da individuare
codeSystem OID 2.16.840.1.113883.6.96 o code system equivalente da individuare
OID-SNOMED o di un code system equivalente da individuare
codeSystemName ST “SNOMED” o equivalente -
SystemVersion ST [VERSIONE DEL SISTEMA DI CODIFICA]
1089
Uso: 1090
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 53 di 64
<entryRelationship typeCode="MFST" > <observation classCode="OBS" moodCode="EVN"> <templateId root='2.16.840.1.113883.10.20.1.54'/> <!— Reazione --> <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/> <statusCode code="completed"/> <value xsi:type="CD" code="247472004" codeSystem="2.16.840.1.113883.6.96" displayName="Orticaria"/> </observation> </entryRelationship>
1091
L’observation che rappresenta la criticità della reazione è associata all’observation che 1092 rappresenta l’allergia, mediante una relazione di tipo manifest (<entryRelationship 1093
typeCode=" SUBJ " >) 1094 1095 <observation>: 1096
Attributo Tipo Valore Dettagli
classCode x_ActClassDocumentEntryAct “OBS” Tiplogia di osservazione di tipo generico
moodCode x_DocumentActMood “EVN” -
1097
La reazione DEVE avere il tag templateID valorizzato con ‘2.16.840.1.113883.10.20.1.54. 1098
Inoltre DEVE contenere il tag 1099
<observation> <code>: 1100
Attributo Tipo Valore Dettagli
Code CS “SEV” Codice
codeSystem OID 2.16.840.1.113883.5. 14 OID ActCode
codeSystemName ST ActCode
1101
<observation> <statusCode> 1102
Attributo Tipo Valore Dettagli
Code CS “Completed” Codice
Commento [dberardi15]: OID non ancora assegnato
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 54 di 64
codeSystem OID 2.16.840.1.113883.5. 4 OID StatusCode
codeSystemName ST StatusCode
1103
1104
1105
2.2.2 Terapie farmacologiche croniche o attuali rilevanti 1106
Questa sezione contiene informazioni relative alle terapie farmacologiche rilevanti cui il 1107
paziente è attualmente sottoposto e alle cure ripetitive. 1108
TO DO 1109
2.2.3 Lista problemi rilevanti e diagnosi codificate 1110
Questa sezione contiene dati sui problemi clinici, condizioni, sospetti diagnostici e 1111
diagnosi certe, sintomi, attuali e passati, del paziente. Essi possono essere elencati in 1112 ordine cronologico inverso o in ordine di importanza, a seconda delle finalità del 1113
patient summary. Le diagnosi sono codificate in ICD9-CM. Tale classe include, tra le 1114 altri gli screening oncologici, Lista malattie pregresse, Interventi chirurgici, Organi 1115
mancanti, le dipendenze e le intolleranze alimentari. Inoltre, i problemi possono 1116 essere caratterizzati da uno “stato”, ad esempio: attivo, non attivo, cronico, 1117
intermittente, risolto, ricorrente, ecc. 1118
TO DO 1119
2.2.4 Accertamenti diagnostici rilevanti ai fini delle patologie 1120
riportate 1121
Questa sezione comprendei i referti o gli accertamenti diagnostici rilevanti ai fini delle 1122 patologie di cui il medico sia venuto a conoscenza per i seguenti motivi 1123
1) notifica sulla sua pubblicazione sull’FSE (questo aspetto verrà dettagliato nelle 1124
successive release) , oppure 1125
2) copia cartacea da parte del paziente e il medico ne trascrive i risultati.(di questo 1126 aspetto va valutata l’applicabilità a livello regionale) 1127
1128
TO DO 1129
1130
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 55 di 64
2.2.5 Controlli pianificati a percorsi concordati per patologie 1131
croniche o particolari 1132
Comprende l’insieme delle informazioni su prescrizioni di prestazioni, interventi, 1133
appuntamenti, procedure attive e non terminate. 1134
TO DO 1135
2.2.6 Vaccinazioni 1136
Definisce lo stato attuale delle vaccinazioni del paziente e le vaccinazioni effettuate dal 1137 MMG/PLS cui il paziente si è sottoposto in passato. TO DO 1138
2.2.7 Partecipazione a trials clinici 1139
Comprende l’insieme delle informazioni relative ai trattamenti e alle procedure 1140
terapeutiche, chirurgiche, diagnostiche pertinenti riguardo alla storia clinica del 1141
paziente. TO DO 1142
2.2.8 Visite 1143
Comprende le visite rilevanti effettuate dal paziente presso l’MMG/PLS. TO DO 1144
1145
2.2.9 Parametri di monitoraggio (pressione, dati 1146
antropometrici, ecc.) 1147
Definisce i segni vitali del paziente attuali e quelli passati, rilevanti ai fini della 1148 definizione del quadro clinico di un paziente, ad esempio, pressione, BMI, peso 1149
altezza, ecc. Dovrebbero essere elencati almeno quelli più rilevanti, ad esempio, i 1150 segni vitali più recenti, i valori massimi, minimi o borderline. TO DO 1151
2.2.10 Assenso/dissenso donazione d’organi 1152
Se la dichiarazione del donatore prevista dall’art.23 comma 3 L.91/99 è fornita 1153 all’MMG. Si ricorda che la medesima legge prevede che la dichiarazione possa essere 1154
anche rilasciata all’ASL. TO DO 1155
2.2.11 Consenso/diniego accanimento terapeutico 1156
Se rilevato dall’MMG. TO DO 1157
1158
2.2.12 Stato corrente del paziente 1159
Contiene lista e descrizione dello stato corrente del paziente: possono essere 1160
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 56 di 64
comprese le seguenti sotto sezioni: 1161
A. Capacità motoria 1162
B. stato mentale del paziente 1163
C. attività della vita quotidiana 1164
D. autosufficienza 1165
E. … 1166
1167
Include eventuali informazioni su ADI/ADP (Assistenza Domiciliare 1168 Programmata)/struttura residenziale TO DO 1169
1170
2.2.13 Potenziali rischi del paziente in relazione alla storia dei 1171
membri familiari 1172
Contiene i potenziali rischi del paziente in relazione alla storia dei membri familiari TO 1173
DO 1174
1175
2.2.14 Vita sociale (es. fumatore, etc.) 1176
In questa sezione vengono incluse informazioni relative allo stile di vita come ad 1177
esempio 1178
A. Fumatore 1179
B. Tossicodipendente 1180
C. Esposizioni tossiche 1181
D. Alcolizzato 1182
E. … 1183
TO DO 1184
Commento [katiaC16]: da verificare
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 57 di 64
3 BIBLIOGRAFIA 1185
Codice Titolo
[HL7CDA2] Clinical Document Architecture Release 2.0 (ANSI/HL7 CDA R2-2005) www.HL7.org, www.HL7italia.it
[HL7v2] HL7 Version 2.5 www.HL7.org, www.HL7italia.it
[HL7v3] HL7 Version 3.0 www.HL7.org, www.HL7italia.it
[CCD] HL7 Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD) April 01, 2007
[IBSE]
Strategia architetturale per la Sanità Elettronica - Tavolo di lavoro permanente Sanità Elettronica delle Regioni e delle Province Autonome (TSE) GdLT: IBSE Marzo 2006 http://www.sanitaelettronica.gov.it/xoops/modules/docmanager/view_file.php?curent_file=361&curent_dir=39
[UML]
OMG, Unified Modeling Language http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML , ed in particolare: OMG, Unified Modeling Language: Superstructure. Version 2.1
1186
1187
1188
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 58 di 64
Appendice A –Elenco OID 1189
Le codifiche ufficiali e loro modifiche DEVONO essere richieste direttamente a HL7 1190 Italia [http://www.HL7italia.it/./MACROFUNZIONI/HTML/OID4.ASP] 1191
1192
1193
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 59 di 64
Appendice B - Composizione dello IUD 1194
1195
Ricognizione delle modalità di crezione degli Identificativi Unici di Documento (IUD) da 1196
parte dei progetti Regionali: 1197
1198
Regione Campi Formato Univocità Ulteriori Commenti
Codice regionale AUSL emissione prescrizione numerico a livello
regionale
Codice identificativo del medico prescrittore
Ultima cifra dell’anno in corso Emilia Romagna (SOLE)
Numero progressivo della prescrizione interna
generata dall’applicativo di cartella clinica del medico prescrittore
Codice AUSL emissione prescrizione; numerico
forse a livello nazionale (perché il codice del medico -
di base - è preceduto dal codice della regione).
Codice identificativo del medico prescrittore
Ultime due cifre dell’anno in corso;
Veneto (IESS) e Friuli Venezia Giulia
Numero progressivo della prescrizione interna
generata dall’applicativo di cartella clinica del medico prescrittore.
numero progressivo della prescrizione alfanumerico a livello
regionale
gestito mediante smartcard
dell'operatore codice prescrittore
Lombardia (CRS-SISS)
check digit
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 60 di 64
Puglia (SIST) numero progressivo della
prescrizione, codice prescrittore
numerico a livello regionale
lo IUP è gestito lato server ed è scaricato sul PC
del medico a lotti
Sardegna (MEDIR) in fase di decisione in fase di decisione
in fase di decisione
proposta di inserirlo sulla
smart card dell'operatore
1199
1200
Definizione ipotesi di normalizzazione dello IUD: 1201
Il requisito fondamentale dell’id del documento è che esso sia univoco sull’intero 1202
dominio nazionale dell’FSE in vista della futura federazione degli FSE regionali. 1203
Si precisa che l’ID non viene costituito per essere un codice PARLANTE ma 1204 solo per essere UNIVOCO nel dominio di riferimento. Pertanto le applicazioni 1205
NON DEVONO utilizzare l’ID per risalire alle caratteristiche del documento. 1206
La codifica proposta suggerisce l’utilizzo, per il campo root dell’OID assegnato da HL7 1207
Italia ad ogni ASL/AO distribuita sul territorio nazionale. 1208
Il campo extension, invece, riporta una codifica univoca per quel particolare sotto-1209 dominio così composta: 1210
1211 <ID STRUTTURA>.<ID OPERATORE>.<TIMESTAMP>.<RANDOM SEED> 1212
1213 Nel dettaglio: 1214
o <ID STRUTTURA> è il campo (o una serie di campi separati dal carattere 1215
“.”) che identifica la struttura finale che assegna l’<ID OPERATORE> 1216
o <ID OPERATORE> è l’ID univoco assegnato dalla struttura competente ad 1217
ogni attore in grado di interagire col sistema 1218
o <TIMESTAMP> è la data alla quale viene creato il documento, nella forma 1219
YYYYMMDDHHmmSS 1220
o <RANDOM_SEED> è un codice casuale generato al momento della creazione 1221
del’ID (5 caratteri alfanumerici) 1222
1223
1224
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 61 di 64
Appendice C – Cenni sui meccanismi di Firma 1225
Digitale XML-Signature 1226
L’attributo <Signature> contiene i dati necessari per la verifica della firma apportata 1227
al documento. Questo include le direttive indirizzate dallo standard XML Signature 1228 come riscontrabile al sito web: http://www.w3.org/TR/xmldsig-core. 1229
Si utilizza il namespace http://www.w3.org/2000/09/xmldsig#. 1230 1231
La struttura di base di una sezione di firma del documento è la seguente, con 1232 l’indicazione della cardinalità degli elementi opzionali: 1233
1234
<Signature ID [0…1]> <SignedInfo> <CanonicalizationMethod/> <SignatureMethod/> (<Reference URI [0…1] > (<Transforms>) [0…1] <DigestMethod> <DigestValue> </Reference>) [1…*] </SignedInfo> <SignatureValue> (<KeyInfo>)[0…1] (<Object ID [0…1]>) [0…*]
</Signature>
1235
Nel nostro caso, il formato si customizza nel modo seguente. 1236 1237
Campo Cardinalità Scelta Descrizione Signature ID 0…1 0 Non utilizzato Reference 1…* 1 Specificare un unico algoritmo e
valori di digest Reference URI 0…1 0 Non utilizzato
Transforms 0…1 0 Nessuna trasformazione dei dati richiesta
KeyInfo 0…1 1 Codifica BASE64 del certificato digitale X.509 da utilizzare per il
riscontro della firma Object 0…* 0 Nessun Object definito
Object ID 0…1 0 (vedi “Object”, riga precedente) 1238
Il valore della firma digitale, codificata BASE64, viene memorizzato nel campo XML 1239 denominato <SignatureValue>. 1240
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 62 di 64
L’algoritmo da utilizzare per il calcolo della firma digitale, così come i meccanismi di 1241
canonicalizzazione vengono memorizzati nel campo XML denominato <SignatureInfo>. 1242
Nel dettaglio, all’interno di questo campo vanno specificati gli attributi riportati di 1243
seguito 1244 1245
Procedura di firma del documento 1246
Il document SOURCE deve elaborare il flusso XML da firmare per calcolarne l’impronta. 1247 Quindi viene creato un elemento di tipo <Reference>, includendo l’algoritmo utilizzato 1248
e il valore del digest ottenuto. 1249
A questo punto viene creato un elemento <SignedInfo> con il <SignatureMethod>, il 1250
<CanonicalizationMethod> e la <Reference> appena calcolata. 1251
Si applica la procedura di canonicalizzazione, nel caso di documenti con più 1252
namespace (es:erogazione prescrizione) TUTTI E DUE I NAMESPACE DEVONO 1253 ESSERE CANONICALIZZATI E FIRMATI, viene calcolato il <SignatureValue> 1254
dell’elemento <SignedInfo> tramite l’algoritmo specificato in <SignedInfo> stesso. In 1255
questo modo anche gli algoritmi utilizzati risultano firmati, prevenendo la possibilità di 1256
attacchi sostenuti sostituendo gli algoritmi utilizzati con altri notoriamente più 1257 vulnerabili. 1258
Si costruisce l’elemento <Signature> sulla base degli elementi appena costruiti 1259
(<SignedInfo> e <SignatureValue>) aggiungendo anche l’elemento <KeyInfo>. 1260
L’elemento <KeyInfo> contiene la codifica BASE64 del certificato X.509 da utilizzare 1261
per la verifica della firma stessa. 1262
Si inserisce la sezione <Signature> all’interno del documento stesso. 1263
1264
Procedura di controllo della firma 1265
Il document CONSUMER applica l’algoritmo di canonicalizzazione specificato nella 1266 sezione <CanonicalizationMethod> alla sezione <SignedInfo> ed estrae la sezione 1267
<Reference> memorizzata. 1268
Sulla base dell’algoritmo in essa specificato, viene calcolato il digest del documento. 1269 Si verifica che il digest calcolato sia uguale a quello memorizzato. Se così non è, la 1270
procedura fallisce. 1271
Se la procedura precedente termina con successo, occorre estrarre dalla sezione 1272
<KeyInfo> le informazioni sulla chiave di firma. 1273
Si applica l’algoritmo di canonicalizzazione all’elemento <SignatureMethod> e si 1274 utilizza il risultato per confermare il valore che è memorizzato nell’elemento 1275
<SignatureValue>. 1276
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 63 di 64
Appendice D - Esempio di documento Patient 1277
Summary 1278
TO DO 1279
1280
Presidenza del Consiglio dei Ministri
Dipartimento per l’Innovazione e le Tecnologie
Rete dei Medici di Medicina Generale
Titolo: Patient Summary
Data: 03/08/2007 Stato: BOZZA 05
Nomefile: IBSE-RMMG-Definizione Patient Summary-BOZZA-05
Pagina 64 di 64
Appendice E - Prescrizione casi d’uso 1281
Si descrivono di seguito brevemente i sequence diagram di alcuni casi d’uso 1282 esemplificativi di utilizzo dei documento di PatientSummary TO DO 1283
1284
1285
PsummaryGEnerico [Paziente->MMG->Specialista] 1286
Il caso d’uso esemplifica la sequenza degli eventi dal momento in cui il paziente 1287 presenta la necessità di cura al momento dell’……………. TO DO 1288
1289
1290