IBSE Infrastruttura di Base della Sanità Elettronica

Transcript

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

IBSE Infrastruttura di Base della Sanità Elettronica

Transcript

Documenti analoghi

collecting sputum samples for culture and mycobacterium/koch

patient engagement scale - Ospedale Fatebenefratelli di Erba

COLLECTING FAECES FOR A FAECAL OCCULT BLOOD TEST

piano di sussidi per l`assistenza dentaria dei bambini dichiarazione

La Scabbia Scabies

Roberto Alesse - Commissione di Garanzia e Sciopero

piano di sussidi per l`assistenza dentaria dei bambini dichiarazione

Si prega di far compilare questo certificato dal proprio

DECRETO DEL PRESIDENTE DELLA REPUBBLICA 12

Diapositiva 1 - Università Cattolica del Sacro Cuore