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







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







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







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







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







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







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.







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







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







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)







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







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







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







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







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







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







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







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







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







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


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







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







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


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


Commento [dberardi3]: check







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







Pagina 24 di 64

582 583 <setID>: 584


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


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







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







Pagina 26 di 64

<code>: 610


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


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.







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







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


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








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







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


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


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








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>







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







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


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







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




778

779 Primo <id>: 780



extension ST [CODICE FISCALE]

Codice Fiscale dell’autore del documento

781 782 Secondo <id>: 783


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"/>







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




803 <signatureCode>: 804


code ST “S” Codice che indica che il documento è firmato digitalmente

805 <assignedEntity><id>: 806


root OID 2.16.840.1.113883.2.9.4.3.2 OID Ministero economia e finanze - CF







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>







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>







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


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







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



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?







Pagina 40 di 64


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







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


classCode CS “NOK” Codice che identifica il contatto “Parente ” (Next Of Kin)

914

<code> DOVREBBE essere valorizzato come indicato in tabella: 915


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







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


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


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










Pagina 43 di 64


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


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





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







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.







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







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







Pagina 47 di 64

1012


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 -->







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


Code CS “ASSERTION” Codice

codeSystem OID 2.16.840.1.113883.5. 14 OID ActCode

codeSystemName ST ActCode

1034

<observation> <statusCode> 1035


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








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







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


typeCode CS “CSM” Rappresenta il fatto che che il farmaco/i mezzo di contrasto DEVE essere “Consumable”

1057 1058

<participantRole> 1059


classCode CS “MANU” Rappresenta il fatto che il farmaco/il mezzo di contrasto dovrebbe essere “Manufactured”

1060 <playingEntity>: 1061


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


code CS [AGENTE SCATENANTE] “Agente Scatenante”







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


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



Commento [dberardi14]: OID non ancora assegnato







Pagina 52 di 64

Code CS “ASSERTION” Codice



1083






1085

Il valore dell’observation può essere codificato con SNOMED o con una codifica 1086

equivalente da individuare: 1087

<value> 1088


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







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


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



Code CS “SEV” Codice



1101




Commento [dberardi15]: OID non ancora assegnato







Pagina 54 di 64



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







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







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







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







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







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







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







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







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







Pagina 63 di 64

Appendice D - Esempio di documento Patient 1277

Summary 1278

TO DO 1279

1280







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

IBSE Infrastruttura di Base della Sanità...

Documents

Transcript of IBSE Infrastruttura di Base della Sanità...