Specifiche tecniche per la produzione della Scheda Sanitaria Individuale in formato HL7 Versione 3 CDA Rel.2 secondo template CCD Progetto Esecutivo Definitivo Accordo di Programma Quadro Atto Integrativo II - SI-II-09

Specifiche tecniche per la produzione della Scheda Sanitaria Individuale in formato HL7 Versione 3 CDA Rel.2 secondo template CCD

Progetto Esecutivo Definitivo

Accordo di Programma Quadro

"Sviluppo della Società dell'Informazione nella Regione Abruzzo"

Atto Integrativo II - SI-II-09

stazione appaltante:

R.T.I. aggiudicatario:

DEDALUS S.p.A TELECOM ITALIA S.p.A.

INDICE

1 DEFINIZIONI, ACRONIMI ED ABBREVIAZIONI 9

1.1 Acronimi 11

1.2 Abbreviazioni 12

1.3 Convenzioni grafiche e sintattiche 13

2 RIFERIMENTI 14

2.1 Premessa 15

2.2 Organizzazione del documento 16

3 INTRODUZIONE 17

3.1 Stati del documento 18

4 HEADER DELLA SCHEDA SANITARIA INDIVIDUALE 19

4.1 Root del documento 20

4.2 Dominio del documento 21

4.3 Identificativo CDA-R2 22

4.4 Identificativo di template CDA-R2 in uso 23

4.5 Identificativo unico del singolo documento 26

4.6 Tipologia del Documento 28

4.7 Data di creazione documento 30

4.8 Riservatezza del documento 32

4.9 Lingua del documento e Dominio 34

4.10 Versione del documento 35

4.11 Dati Anagrafici del paziente 39

4.11.1 Dati anagrafici del paziente 42

4.11.1.1 Tutore legale 43

4.12 Autore e autenticatore 44

4.12.1 Autore 44

4.12.2 Firmatario del documento 49

4.13 Custode 52

4.14 Contatti del paziente 55

4.14.1 Parenti 56

4.14.2 Emergenza 58

4.14.3 Assistenza Malati ed Anziani 59

4.14.3.1 Note implementative 62

4.15 documentationOf 63

4.16 Altre Informazioni 64

5 BODY DELLA SCHEDA SANITARIA INDIVIDUALE 65

5.1 Allergie, Intolleranze ed Xxxxxxx (Alerts) 67

5.1.1 Specifiche di Sezione 68

5.1.2 Descrizione Allarme 70

5.1.2.1 Vincoli Aggiuntivi 72

5.1.3 Alert Observation 73

5.1.4 Dettagli Allarme Generico 73

5.1.5 Indicazione assenza Allergie Note 74

5.1.6 Xxxxxxxx intolleranza o allergia 75

5.1.6.1 Vincoli Aggiuntivi 78

5.1.7 Descrizione Agente 78

5.1.7.1 Descrizione Agente (Non Codificato) 79

5.1.7.2 Descrizione Agente (Codificato) 79

5.1.8 Descrizione Reazione 80

5.1.8.1 Descrizione Reazioni (Codificata) 80

5.1.8.1.1.1 Vincoli aggiuntivi 81

5.1.8.2 Descrizione Reazioni (Non Codificata) 81

5.1.9 Stato dell’allergia 82

5.1.10 Commenti 83

5.1.10.1 Vincoli Aggiuntivi 84

5.1.11 Esempio 84

5.2 Problemi (Problems) 88

5.2.1 Specifiche di sezione 91

5.2.2 Modalità di gestione dei problemi “strutturati” (folder) 92

5.2.3 Problema 94

5.2.4 Dettagli problema 96

5.2.4.1 Vincoli aggiuntivi 98

5.2.5 Stato clinico 98

5.2.6 Stato di Salute 99

5.2.7 Gestione episodicità 101

5.2.8 Riferimenti Interni 102

5.2.9 Organi Mancanti 103

5.2.10 Esempio 103

5.3 Piani di Cura 107

5.3.1 Specifiche Sezione 107

5.3.2 Dettaglio Attività Piano di Cura 108

5.3.3 Esempi 110

5.3.3.1 Prescrizione Prestazione Riabilitativa 110

5.3.3.2 Richiesta osservazione 111

5.4 Farmaci (Medications) 113

5.4.1 Specifiche di Sezione 114

5.4.2 Descrizione Terapia 116

5.4.3 Posologia 120

5.4.4 Dettagli Farmaco 121

5.4.5 Ragione 123

5.4.6 Esempio 123

5.5 Vaccinazioni (Immunization) 125

5.5.1 Specifiche di Sezione 126

5.5.2 Vaccinazione 128

5.5.2.1 Vincoli aggiuntivi 130

5.5.3 Esempio 130

5.5.3.1 Narrative Block 130

5.5.3.2 Coded Entry 131

5.6 Procedure (Procedures) 133

5.6.1 Specifiche di sezione 133

5.6.2 Dettagli Procedura 135

5.6.2.1 Vincoli aggiuntivi 137

5.6.3 Esempio 137

5.7 Visite e Ricoveri (Encounter) 139

5.7.1 Specifiche di sezione 140

5.7.2 Dettagli Incontro 141

5.7.2.1 Vincoli aggiuntivi 142

5.7.3 Performer 142

5.7.4 Luogo 143

5.7.5 Esempio 144

5.8 Risultati esami e visite (Results) 145

5.8.1 Specifiche di Sezione 145

5.8.2 Result Organizer 147

5.8.3 Dettaglio Osservazione 148

5.8.4 Esempio 150

5.9 Rilevazioni (Vital Signs) 152

5.9.1 Specifiche di sezione 152

5.9.2 Vital Sign Organizer 154

5.9.2.1 Vital Signs Observation 155

5.9.2.2 Vincoli aggiuntivi 156

5.9.3 NarrativeBlock 157

5.10 Stile di Vita (Social History) 160

5.10.1 Specifiche di Sezione 160

5.10.2 Esempio 161

5.10.2.1 Narrative Block 161

5.11 Costante Biologica 163

5.11.1 Gruppo Sanguigno 163

5.11.2 Protesi 163

5.11.3 Organi Mancanti 163

5.12 Protesi ed Ausilii (Medical Equipment) 164

5.12.1 Specifiche di sezione 164

5.12.2 Esempi 165

5.12.2.1 Narrative_Block 165

5.13 Anamnesi Familiare (Family History) 166

5.13.1 Specifiche di sezione 166

5.13.2 Familiarità 169

5.13.2.1 Vincoli aggiuntivi 170

5.13.3 Dettagli su familiarità 171

5.13.4 Vincoli aggiuntivi 173

5.13.5 Causa di morte 173

5.13.6 Informazioni sull’età 173

5.13.7 Esempio 174

5.13.7.1 Narrative Block 174

5.13.7.2 Familiarità (Family History Organizer) 175

6 TABELLE 180

6.1 Codifica Istat Regioni 181

6.2 Tabella A.8 – Codici Istat Province 182

6.3 Tabella A.9 – Codifica Comuni d’Italia 183

6.4 Tabella A.10 – Codifica ASL 184

6.5 Tabelle di servizio Errore. Il segnalibro non è definito.

6.5.1 Participation Function 192

6.6 Parentele (PersonalRelationshipRoleType) 194

6.7 Unità di misura 199

6.7.1 ActEncounterCode 207

Revisioni

Nella tabella che segue sono riportate le indicazioni sugli aggiornamenti applicati al documento

Versione	Data	Descrizione
1.0	17/07/2008	Prima stesura del documento

1 Oggetto del documento

Il presente documento costituisce il deliverable 22.1 (Documento dei casi d’uso relativi a Scheda Sanitaria Individuale) previsto dalla Scheda attività 22 “Scheda Sanitaria Individuale” definita nel contesto del progetto "Rete MMG" promosso dalla regione Abruzzo.

2 Definizioni, Acronimi ed Abbreviazioni

2.1 Acronimi:

Sigla	Esteso	Descrizione
CCD	Continuity of Care Document
CDA-R2	HL7 Versione 3, dominio Clinical Document Architecture Release 2
DEU	Dipartimento Emergenze ed Urgenze
FSE	Fascicolo Sanitario Elettronico
HL7	Health Level 7
IHE	Integrating the Healthcare Enterprise
PCC	Patient Care Coordination
OID	Object IDentifier	Struttura dati definita da ISO
PS	Patient Summary
SSI	Scheda Sanitaria Individuale
XDS-MS	Cross Enterprise Document Sharing – Medical Summary

2.2 Abbreviazioni:

Xxxxx	Xxxxxx
e.g.	Exempli gratia (per esempio)
i.e.	Id est (cioè)

2.3 Convenzioni grafiche e sintattiche

esempio XML

CCD Conformance Statement

CONF 1 statement

Tutti gli OID che contengono “.99” al loro interno sono da intendersi come OID non registrati, forniti solo a titolo di esempio, perciò da NON utilizzare nei messaggi reali.

3 Riferimenti

Per la redazione delle specifiche tecniche in oggetto si è tenuto conto di quanto prodotto dal gruppo di lavoro di progettazione condivisa del progetto Rete MMG, indipendentemente dallo stato dei documenti prodotti, considerando la documentazione allo stato attuale distribuita come unico possibile riferimento per le informazioni condivise e approvate dai vari interlocutori.

Tale scelta si rende necessaria affinché il mancato completamento del ciclo di vita della documentazione non diventi un impedimento all’evoluzione del progetto Rete MMG della Regione Abruzzo:

Per la strutturazione del CDA 2 basato sul template CCD – Continuity of Care Document - l’organizzazione di riferimento sarà HL7 nelle sue strutturazioni Nazionale e Internazionale.

In conformità con il suddetto template, laddove applicabile, è stato fatto riferimento diretto ai template definiti da IHE PCC per la parte Medical Summary. (XDS-MS).

3.1 Premessa

Il presente documento integra quanto discusso all’’interno del gruppo di progettazione condivisa c/o il DIT in termini di armonizzazione fra i documenti di specifica dei PS presentati dalle diverse regioni. In particolare accoglie i requisiti di armonizzazione concordati durante le riunioni dei gg 10 e del 17 luglio 2008 a livello di header e di strutturazione di massima dei

documenti, che si applicano anche al documento di Scheda Sanitaria Individuale.

Per quanto riguarda lo standard HL7 V3 e CDA2 ed i riferimenti ad essi presenti, considerati destinatari del presente documento di tipo specialistico, non verranno approfondite le tematiche di tipo metodologico annesse allo standard stesso.

Quindi i lettori di questo documento dovranno conoscere lo standard HL7 Versione 3, in particolare il dominio CDA Release 2, e dovranno conoscere anche i contenuti del documento “HL7 Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD)” di HL7 ed ASTM, nella sua versione finale di Aprile 2007. Risulta inoltre utile per una corretta valutazione di questo documento anche la conoscenza del Technical Framework IHE Patient Care Coordination, Revision 3.0, 2007-2008.

L’entità SSI trattata in questo documento, non deve essere confusa – sebbene da essa derivata - con l’omonima definita a livello giuridico, dall’Accordo Collettivo Nazionale per la disciplina dei rapporti con i medici di medicina generale, sottoscritto ai sensi dell'art. 8 del d.lgs. 502/1992 [1], il cui art. 45, rubricato “Compiti del medico”, precisa: “L'espletamento delle funzioni di cui al precedente comma 1 (cioè “funzioni e compiti individuali del medico di assistenza primaria”) si realizza con: (…) c) la tenuta e l'aggiornamento di una Scheda Sanitaria Individuale, su supporto informatico (…) 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 (…)”.

Per ovviare a tale inconveniente, durante l’incontro di progettazione condivisa del 17 aprile 2008 tenutosi presso il DIT, è stato proposto “di referenziare la SSI come “profilo sanitario”, con due versioni: quella estesa (SSIE), assimilabile all’attuale SSI, e quella sintetica (SSIS), assimilabile all’attuale Scheda Sanitaria Individuale.”

Tuttavia in assenza di una asserzione formale sull’identificazione di questa entità (SSI vs SSIE) da parte del tavolo di progettazione condivisa, e per facilitare il tracciamento con la documentazione di progetto fino ad ora consegnata, è stato scelto di mantenere l’attuale dizione (SSI), fatto salva la distinzione sopra indicata.

3.2 Organizzazione del documento

Per ciò che concerne l’organizzazione del documento:

Ł Il capitolo 5 "Header della Scheda Sanitaria Individuale“ riporta le specifiche dell’header del CDA, conforme al template CCD, usato per veicolare la Scheda Sanitaria Individuale. Include vincoli aggiuntivi imposti dalle presenti specifiche.

Ł Il capitolo 6 "Body della Scheda Sanitaria Individuale” fornisce una descrizione di dettaglio su come mappare gli elementi non di tipo anagrafico presenti nella struttura dati della Scheda Sanitaria Individuale all’interno del body del CDA.

Ł Il capitolo 7 “Tabelle” riporta il dettaglio di alcune codifiche usate per la Scheda Sanitaria Individuale

4 Introduzione

Le componenti dati che determineranno la Scheda Sanitaria Individuale e che lo caratterizzano, come concordato tra la FIMG e le Regioni partecipanti al tavolo nazionale “Rete di Medicina Generale”, hanno portato alla seguente definizione:

La Scheda Sanitaria Individuale è un documento informatico, firmato digitalmente e contenuto nell’FSE, composto dall’insieme delle informazioni cliniche che il MMG ritiene rilevanti per la storia clinica dell’assistito e da lui mantenuto aggiornato. Essa contiene l’insieme strutturato di tutte le informazioni sanitarie note a MMG/PLS, ai sostituti (diretto, medicina di gruppo e di rete ), relativamente ad un assistito.

Nota: a differenza del PS, il cui primario intento è la focalizzazione su “pochi” elementi

essenziali, la SSI includerà in generale “tutti” i dati clinici del paziente, di cui il medico è a conoscenza e che egli ritiene utile che debbano essere tracciate.

Per quanto detto, la SSI sarà la modalità elettiva per l’interscambio tra sistemi non omogenei di cartella ambulatoriale per MMG, facilitando la continuità assistenziale anche in presenza di “trasferimenti” dei mandati assistenziali da MMG a MMG

Ulteriori dettagli sugli scenari d’uso del SSI sono descritti nel deliverable 22.1 sui Casi d’Uso.

4.1 Stati del documento

In conformità con quanto definito per i documenti che dovranno essere pubblicati nel FSE, anche la SSI segue il seguente diagramma degli stati:

I. un documento può essere invito al FSE solo se legalmente autenticato e disponibile per la consultazione (stato “completed”)

II. un documento presente nel FSE può essere annullato perché inviato per errore (stato “nullified”)

III. un documento presente nel FSE può essere reso obsoleto (stato “obsolete”) in quanto superato da una versione del documento più aggiornata

Figura 1 - Ciclo di vita della Scheda Sanitaria Individuale nel FSE

5 Header della Scheda Sanitaria Individuale

Di seguito si riportano: il modello del CDA-R2 header, un esempio e le istruzioni, i costraint e i conformance statment necessari alla creazione passo passo del Header della Scheda Sanitaria Individuale in formato CCD.

5.1 Root del documento

L’elemento radice per la struttura xml che rappresenta il documento CDA è rappresentato dal tag <Clinial Document>, come riporato nella struttura della figura seguente:

Esempio di elemento radice:

<ClinicalDocument xmlns:xsi="xxxx://xxx.x0.xxx/0000/XXXXxxxxx-xxxxxxxx" xsi:schemaLocation="urn:hl7-org:v3 CDA.xsd"

xmlns:voc="urn:hl7-org:v3/voc" xmlns="urn:hl7-org:v3">

5.2 Dominio del documento

L’ elemento obbligatorio che indica il dominio di appartenenza del documento, ovvero l’Italia, è rappresentato dalla proprietà <realmCode>

Questo valore è fisso e non modificabile. Esempio:

5.3 Identificativo CDA-R2

L’ elemento OBBLIGATORIO che indica che il documento è strutturato secondo le specifiche HL7 Versione 3- Dominio CDA Rel 2.0, e più precisamente secondo lo schema della “CDA, Release Two Hierarchical Description”, è rappresentato dal tag <typeId>

Il tag <typeId> è un valore del tipo HL7 “Instance Identifier” ed è composto da una attributo root che garantisce l’univocità dell’istanza dell’identificativo a livello globale attraverso codice OID, un attributo extension che riporta un codice specifico, usato per identificare univocare all’interno dello scope del root.

Questo valore è fisso e non modificabile.

Attributo

Tipo

Valore

Dettagli

root

OID

2.16.840.1.113883.1.3

Object Identifier di HL7 per i modelli registrati

extension

POCD_HD000040

Codifica identificativa del “CDA Release Two Hierarchical Description” che è lo schema

che contiene la gerarchia delle classi di un documento CDA

Esempio :

5.4 Identificativo di template CDA-R2 in uso

L’elemento obbligatorio utilizzato per indicare il template di riferimento per il documento corrente è <templateId>. La struttura di questa proprietà è riportata nella figura seguente:

I template a cui si fa riferimento nel documento CCD identificano attraverso il tag <code> un insieme di restrizioni e/o linee guida da applicare all’intero documento o ad una specifica sezione dello stesso, come richiesto dalle linee guida relative al "HL7 Implementation Guide: CDA Release 2 - Continuity of Care Document (CCD)", per facilitare il processo di verifica della conformance.

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

Il primo elemento <templateId> è valorizzato secondo le regole di conformance previste dall’implementation guide del CCD, ed è pertanto costituito dal solo elemento <root> valorizzato come segue:

Attributo

Tipo

Valore

Dettagli

Root

OID

2.16.840.1.113883.10.20.1

OID del catalogo degli schemi dei template di documento per i documenti di Scheda Sanitaria Individuale

(Rif: cap 1.4 CCD)

extension

[CONF-8]

[CONF-7] CCD SHALL contain one or more ClinicalDocument / templateId.

[CONF-8] At least one ClinicalDocument / templateId SHALL value ClinicalDocument / templateId / @root with “2.16.840.1.113883.10.20.1”, and SHALL NOT contain ClinicalDocument / templateId / @extension

Il secondo ed il terzo si riferiscono a documenti di tipo Medical Summary come previsti da IHE PCC (root='1.3.6.1.4.1.19376.1.5.3.1.1.1', '1.3.6.1.4.1.19376.1.5.3.1.1.2' )

Il quarto indica il documento di Scheda Sanitaria Individuale in termini di imposizione di una serie di costraint stabilito in ambito Italiano da HL7Italia, ed è valorizzato come segue:

Attributo

Tipo

Valore

Dettagli

Root

OID

2.16.840.1.113883.2.9.10.2.4

OID del catalogo degli schemi dei template di documento per i documenti di Scheda Sanitaria

Individuale

extension

Ipotesi – Codice composto PREFISSO: ITPRF

CODICE: SSI per la Scheda Sanitaria Individuale (generico)

VERSIONE: “001”

progressivo per il versioning dei template

Identificativo del template di documento SCHEDA SANITARIA INDIVIDUALE

Esempio:

<!- Medical Summary -->

5.5 Identificativo unico del singolo documento

L’elemento obbligatorio che identifica univocamente l’istanza di ogni documento CDA è rappresentato dal tag <id>.

Il tag <id> è un valore del tipo HL7 “Instance Identifier” ed è composto da un attributo root che riporta un codice OID, un attributo extension che riporta un codice specifico e un attributo con il nome dell’authority che è responsabile della codifica posta nel campo extension.

Come richiesto da HL7 ogni singola istanza di documento CDA (singolo Scheda Sanitaria Individuale, singola prescrizione, singolo referto …) è dotata di un identificativo univoco collocato nell’attributo <id> del documento.

L’univocità dell’<id>, nella sua composizione root + extension, DEVE essere assicurata a livello universale.

TSE suggerisce un meccanismo di creazione di ID univoci per l’identificazione dei documenti sanitari presenti nell’FSE. .

<id>:

Attributo

Tipo

Valore

Dettagli

root

OID

[OID del dominio di identificazione dei documenti]

Identificativo univoco del dominio di indentificazione dei documenti.

Tale identificativo – riconosciuto pubblicamente - garantisce l’univocità dell’istanza dell’identificativo a livello globale.

Tale root potrebbe corrispondere all’OID del ramo di identifcazione dei

documenti della struttura cui

appartiene l’autore.

extension

[IUD]

Identificativo Unico del Documento all’interno del dominio di identificazione.

Generato dal client dell’autore secondo regole condivise all’interno del dominio di competenza (definito dal root) in maniera tale da assicurare l’univocità di tale attributo all’interno

del medesimo dominio.

assigningAuthorityName

[NOME DOMINIO IDENTIFICAZIONE]

Nome del dominio di identificazione dei documenti.

Può corrispondere al nome della

struttura a cui appartiene l’autore del documento

Esempio :

<id root="2.16.840.1.113883.2.9.2.103.4.4" extension="$ID_UNICO_DOC" assigningAuthorityName="Regione

Abruzzo"/>

In rosso i valori da modificare in nero quelli fissi

$ID_UNICO_DOC = Identificativo Unico Documento all’interno del dominio dei documenti per la Regione Abruzzo

5.6 Tipologia del Documento

L’elemento obbligatorio che indica la tipologia di documento è rappresentato dal tag

<code>.

L’attributo <code> riporta un codice che identifica la tipologia di documento a cui il CDA si riferisce (Prescrizione, Referto di …., lettera di dimissione, Scheda Sanitaria Individuale)

Il valore deve fare riferimento al sistema di codifica LOINC.

Nel caso della Scheda Sanitaria Individuale, il tag <code> deve essere così valorizzato :

<code>:

Attributo	Tipo	Valore	Dettagli
codeSystem	OID	2.16.840.1.113883.6.1	Codifica LOINC
Code	CS	“34133-9”	Codice relativo alla tipologia del documento. (“Summarization of episode note”)
codeSystemName	ST	LOINC
codeSystemVersion	ST	2.19	Versione codifica LOINC
displayName	ST	“SCHEDA SANITARIA INDIVIDUALE”

[CONF-1] The value for “ClinicalDocument / code” SHALL be “34133-9” “Summarization of episode note” 2.16.840.1.113883.6.1 LOINC STATIC

Esempio:

5.7 Data di creazione documento

L’elemento obbligatorio che indica la data di creazione del documento SSI in CDA è rappresentato dal tag <effectiveTime>. L’attributo <effectiveTime> rappresenta una marcatura temporale che deve essere strutturata secondo le modalità di codifica previste da HL7.

Tale valore deve essere quello del client utilizzato dal document SOURCE, opportunamente certificato.

Nel caso della prescrizione l’attributo deve essere valorizzato tramite un tipo Time Stamp (TS) come presentato di seguito:

Attributo

Tipo

Valore

Dettagli

value

[YYYYMMddhhmmss+

|-ZZzz]

Anno, mese, giorno, ora, minuti, secondi

Le ore devono essere riportate nell’intervallo 00:00:00 - 23:59:59. ZZzz rappresenta l’offset rispetto al tempo di Greenwich (GMT – Greenwich Mean Time). L’Italia si trova a GMT+1, quindi ZZzz va valorizzato con +0100. Deve essere

valorizzato almeno fino ai secondi.

[CONF-9] ClinicalDocument / effectiveTime SHALL be expressed with precision to include seconds.

[CONF-10] ClinicalDocument / effectiveTime SHALL include an explicit time zone offset.

Esempio:

In rosso i valori da modificare in nero quelli fissi

$TS_CREAZIONE_SSI = Data (e ora) creazione del documento. Formato [YYYYMMddhhmmss+|-ZZzz] . e.g. 20080712173020+0100 equivale alle 17.30 (e 20 sec) del 12 Luglio 2008 ore .

5.8 Riservatezza del documento

L’elemento obbligatorio che indica la clausola di riservatezza del documento è rappresentato dal tag <confidentialityCode>.

Il tag <confidentialityCode> riporta un codice che identifica il livello di confidenzialità del documento CDA secondo la codifica di “Confidentiality” di HL7

Code * Definition

Normal confidentiality rules (according to good health N (normal) (codeSystem care practice) apply. That is, only authorized individuals 2.16.840.1.113883.5.25) with a legitimate medical or business need may access

this item.

R (restricted) (codeSystem Restricted access, e.g. only to providers having a current 2.16.840.1.113883.5.25) care relationship to the patient.

V (very restricted) (codeSystem Very restricted access as declared by the Privacy Officer 2.16.840.1.113883.5.25) of the record holder.

Nel caso della prescrizione il tag deve essere così valorizzato :

Attributo	Tipo	Valore	Dettagli
codeSystem	OID	2.16.840.1.113883.5.25	OID codifica
code	ST	“N”	Normali regole di riservatezza
codeSystemName	ST	“Confidentiality”	Nome della codifica

Esempio:

5.9 Lingua del documento e Dominio

L’elemento obbligatorio per il SSI che indica la lingua in cui è redatto il documento è rappresentato dal tag <languageCode>.

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)

Nel caso della Scheda Sanitaria Individuale il tag deve essere così valorizzato:

Attributo

Tipo

Valore

Dettagli

code

it-IT oppure it

L’attributo deve essere nella forma nn o nn-CC, dove nn è la codifica ISO- 639-1 della lingua in minuscolo e CC è la codifica ISO-3166 dello Stato in

maiuscolo

[CONF-5] CCD SHALL contain exactly one ClinicalDocument / languageCode.

[CONF-6] ClinicalDocument / languageCode SHALL be in the form nn, or nn-CC. The nn portion SHALL be an ISO-639-1 language code in lower case. The CC portion, if present, SHALL be an ISO-3166 country code in upper case

Esempio:

5.10 Versione del documento

Gli elemento che rappresentano un identificatore comune di tutte le revisioni del documento e la revisione in particolare sono rappresentati dai tag <setId> e <versionNumber>.

Gli elementi opzionali <setID> e <versionNumber> sono da usarsi per gestire le versioni del documento.

Il <setID> resta costante tra le diverse versioni del medesimo documento, identificate internamente dal <versionNumber>.

Esempio d’uso:

Se, per esempio, viene prodotto un documento di Scheda Sanitaria Individuale pubblicato nel FSE e successivamente il document SOURCE, a causa di un errore o per un semplice aggiornamento, decide di modificarlo, il nuovo documento di prescrizione avrà un <id> univoco e diverso dal primo ed un <setID> con valore uguale al <setID> del primo documento pubblicato. Il version number identifica la sequenza dei cambiamenti.

Il nuovo documento modificato sostituisce sempre il documento precedente.

Lo standard prevede inoltre che il nuovo documento abbia una relazione di tipo

<relatedDocument> che punta al documento sostituito.

Anche il <setID>, come l’<id>, deve essere unico; pertanto alla prima creazione del documento si valorizzano i campi <setID>, <versionNumber> ed <id>. Successivamente, nelle

diverse revisioni del documento, si modificherà solo l’<id> con un nuovo IUD, mantenendo il

<setID> costante ed incrementando di 1 il <versionNumber>.

<setID>:

Attributo

Tipo

Valore

Dettagli

root

OID

[OID del dominio di identificazione dei documenti]

Identificativo univoco del dominio di indentificazione dei documenti.

Tale identificativo – riconosciuto pubblicamente - garantisce l’univocità dell’istanza dell’identificativo a livello globale.

Secondo la metodologia di generazione descritta in appendice, tale root potrebbe corrispondere all’OID del ramo di identifcazione dei documenti della struttura cui appartiene

l’autore.

extension

[IURD]

Identificativo Unico della Revisione del documento all’interno del dominio di identificazione.

Generato dal client dell’autore secondo regole condivise all’interno del dominio di competenza (definito dal root) in maniera tale da assicurare l’univocità di tale attributo all’interno del medesimo

dominio.

assigningAuthorityName

[NOME DOMINIO IDENTIFICAZIONE]

Nome del dominio di identificazione dei documenti. Nel caso della metodologia descritta in appendice B può corrispondere al nome della struttura a cui appartiene l’autore

del documento

<versionNumber>:

Attributo

Tipo

Valore

Dettagli

value

INT

[progressivo versione documento]

Ad ogni successiva versione del documento (RPLC), tale numero incrementa di una

unità (partendo da 1)

Esempio :

In rosso i valori da modificare in nero quelli fissi

$SETID_DOC = Identificativo Unico Identificativo univoco delle revisioni del documento all’interno del domionio documentale per la Regione Abruzzo

$ NUM_VERSIONE = numero di versione del documento (intero seriale)

Figura 2: Gestione delle versioni del documento Replace (estratto documentazione HL7)

5.11 Dati anagrafici del paziente

L’elemento obbligatorio che identifica il soggetto cui si riferisce la Scheda Sanitaria Individuale è rappresentato dall’elemento <recordTarget>.

Il <recordTarget> è un elemento composto da un ruolo <patientRole> verso un’entità

<patient>.

Il ruolo <patientRole> prevede genericamente al suo interno almeno un elemento di tipo

<id> destinato ad accogliere la chiave identificativa del paziente..

Diverse sono tuttavia le casistiche possibili e le relative eccezioni, in dipendenza dalla tipologia di soggetto in esame; tali casistiche possono essere così sintetizzate.

Il Cittadino italiano o straniero residente (iscritto SSN) è caratterizzato da due elementi di tipo

<id> contenenti:

1 Il codice assegnato dall’anagrafica regionale (FACOLTATIVO)

2 Il codice fiscale del paziente (OBBLIGATORIO)

Per stranieri temporaneamente presenti <patientRole> DEVE riportare il Codice identificativo STP (vedi tabella seguente per esempio di struttura

<id>:

Attributo	Tipo	Valore	Dettagli
root	OID	[OID ASL/AO]	OID ASL
extension	ST	“4.9.STP” + [NUMERO IDENTIFICAZIONE PERSONALE ]	Identificativo ramo STP + “.STP” + Codice STP
assigningAuthorityName	ST	[Nome ASL/AO]	Nome dell’Azienda Sanitaria

Per soggetti assicurati da istituzioni estere <patientRole> DEVE riportare il

1. Numero di identificazione personale ed il codice dell’istituzione competente

2. Numero di identificazione della Tessera Sanitaria

Per la Scheda Sanitaria Individuale l’elemento è pertanto strutturato come segue

<!—Identificativi del Paziente/Persona Molteplicità 1 * Caso Assistito coperto da SSN -->

<id root="2.16.840.1.113883.2.9.2.103.4.1" extension="$ID_REG_ABRUZZO"

assigningAuthorityName="Regione Abruzzo"/>

<id root="2.16.840.1.113883.2.9.4.3.2" extension="$COD_FISCALE_PAZ"

assigningAuthorityName="MEF"/>

$PATIENT

</patient>

<!— Organizzazione in cui la persona gioca il ruolo di paziente, OPZIONALE -->

<name>Regione Abruzzo</name>

</providerOrganization>

</patientRole>

</recordTarget>

In rosso i valori da modificare in nero quelli fissi

$ID_REG_ABRUZZO = Identificativo unico dell’assistito presso la Regione Abruzzo

$COD_FISCALE_PAZ = Codice fiscale del paziente

$PATIENT = Dettagli anagrafici del paziente. Vedi § 5.11.1 - Dettagli paziente

5.11.1 Dettagli paziente

L’entità <patient> contiene i dettagli anagrafici relativi al paziente.

Riporta alcuni attributi obbligatori con l’indicazione dei dati anagrafici, quali in particolare

<name> (con i componenti <family> e <given>), <administrativeGenderCode>. E’ inoltre facoltativo inserire il luogo di nascita nell’attributo <birthplace>.

Esempio rappresentazione dati anagrafici:

<name>

<family>$COGNOME_PAZ</family>

</name>

<!— TUTTI GLI ALTRI ELEMENTI SONO OPZIONALI Esempio -->

<!— OPZIONALE TUTORE LEGALE Molteplicità O…* -->

$TUTORE

<place>

<!- Esempio di possibile rappresentazione dell’address -->

<addr>

<city>$CITTA_NASCITA</city>

<censusTract>$COD_ISTAT_CITTA_NASCITA</censusTract>

</addr>

</place>

</birthplace>

$NOME_PAZ = Nome del Paziente

$COGNOME_PAZ = Cognome del Paziente

$DATAORA_NASCITA_PAZ = Data Ora nascita

$CITTA_NASCITA = Descrizione Città di Nascita

$COD_ISTAT_CITTA_NASCITA = Codice Istat Città di Nascita

$TUTORE = Dettagli su Tutore. Per dettagli vedi § 5.11.2 - Tutore legale

Si faccia riferimento alla documentazione di HL7 Italia per il Dominio PRPA Person Topic per ciò che concernono le regole di gestione dei campi <name> ; <birthdate> e <birthplace>

5.11.2 Tutore legale

L’ elemento opzionale che rappresenta il tutore legale è definito dalla classe <guardian>.

Il tutore legale è rappresentato dalla classe Guardian per un determinato paziente (istanza della classe Patient). Il tutore può essere una persona (istanza della classe Person) o un’organizzazione (istanza della classe Organization).

Sebbene questo elemento sia considerato opzionale per il template CCD, per rispondere alle esigenze espresse dal garante in materia di raccolta di consenso da parte del MMG/PLS, il tavolo TSE ritiene opportuno includere SEMPRE tale elemento valorizzandolo eventualmente con nullFlavor=”NA” nel caso questo non sia applicabile.

Nel caso l’elemento non sia stato valorizzato con un nullFlavor, questo DOVRA’ riportare i dettagli del Tutore Legale valorizzando l’elemento <guardianPerson>, nel caso di PERSONE,

<guardianOrganzation> in caso di ORGANIZZAZIONI. Esempio d’uso (Guardian Person):

<!— Opzionale -->

<id root="2.16.840.1.113883.2.9.4.3.2" extension="$COD_FISCALE_TUTOR"

assigningAuthorityName="MEF"/>

<name>

<family>$COGNOME</family>

</name>

</guardianPerson>

</guardian>

$COD_FISCALE_TUTOR = Codice Fiscale Tutore Legale

$NOME = Nome del Tutore Legale

$COGNOME = Cognome del Tutore Legale

5.12 Autore e autenticatore

5.12.1 Autore

L’attributo obbligatorio che identifica il soggetto che ha creato il documento.è rappresentato dal tag <author> .

L’author DEVE includere un elemento <author>.<time> che indica la data e l’ora di produzione del documento: la valorizzazione coinciderà con quella di

<clinicalDocument>.<effectiveTime> (vedi § 5.7 - Data di creazione documento per ulteriori dettagli )

In questo contesto l'autore del documento è rappresentato sempre da una persona, valorizzata attraverso dall'attributo <assignedPerson>.

L’autore è identificato da almeno i seguenti <id> :

1. Codice Fiscale

2. Identificativo regionale dell’operatore

[CONF-12] CCD SHALL contain one or more ClinicalDocument / author / assignedAuthor / assignedPerson and/or ClinicalDocument / author / assignedAuthor / representedOrganization

Nel contesto del presente documento si richiede che la molteplicità dell’elemento <author> non sia superiore a 1.

Le informazioni riguardanti il nome del Medico sono codificate attraverso il segmento

<name> dell'attributo <assignedPerson>, mentre il Codice Asl di convenzione del Medico titolare delle informazioni presenti nel SSI è codificato attraverso il segmento

<rapresentedOrganization> ricorrendo a appositi <id> che fanno riferimento alle tabelle di codifica degli OID di HL7Italia.

<xxxxxxxxXxxxxx.xxxx>:

<xxxxxxxxxxxXxxxxxxxxxxx.xx>:

Esempio:

<id root="2.16.840.1.113883.2.9.4.3.2" extension="$COD_FISCALE_MMG"

assigningAuthorityName="MEF"/>

<id root="2.16.840.1.113883.2.9.2.103.4.2" extension="$ID_REG_MEDICO"

assigningAuthorityName="Regione Abruzzo"/>

<name>

<family>$COGNOME</family>

</name>

</assignedPerson>

</representedOrganization>

</assignedAuthor>

</author>

In rosso i valori da modificare in nero quelli fissi

$TS_CREAZIONE_SSI = Data (e ora) di creazione del documento. Formato [YYYYMMddhhmmss+|-ZZzz] . e.g. 20080712173020+0100 equivale alle 17.30 (e 20 sec) del 12 Luglio 2008 ore .

$$ID_REG_MEDICO = Identificativo regionale del Medico.

$COD_FISCALE_MMG = Codice fiscale del Medico

$NOME = Nome del Medico

$COGNOME = Cognome del Medico

$ID_ASL = Identificativo dell’ASL di appartenenza del Medico

$NOME_ASL = Nome dell’ASL di appartenenza del Medico

5.12.2 Firmatario del documento

L’attributo OBBLIGATORIO che riporta il firmatario del documento.

Come risulta dallo schema sopra riportato l’elemento contiente un tag:

Ł <time> OBBLIGATORIO con l’indicazione dell’ora di produzione del documento, la sua valorizzazione avviene come per l’elemento <clinicalDocument>.<effectiveTime> (vedi § 5.7 - Data di creazione documento per ulteriori dettagli );

Ł un’attributo <signatureCode>, che indica che lo stato di firma del documento, nel caso dell’SSI SEMPRE valorizzato a “S” (Signed);

Ł ed un <assignedEntity> che descrive l’entità responsabile delle firma dell’SSI.

Nel caso della SSI l’<assignedEntity> sarà sempre di tipo <assignedPerson> e coinciderà con l’autore del documento (<author>). Vedi il § 5.12.1 - Autore per dettagli.

Inoltre DOVRA’ sempre contenere un elemento <assignedEntity>.<id> che contenga il codice fiscale del medico.

Esempio:

<id root="2.16.840.1.113883.2.9.4.3.2" extension="$COD_FISCALE_MMG"

assigningAuthorityName="MEF"/>

<id root="2.16.840.1.113883.2.9.2.103.4.2" extension="$ID_REG_MEDICO"

assigningAuthorityName="Regione Abruzzo"/>

<name>

<family>$COGNOME</family>

</name>

</assignedPerson>

</representedOrganization>

</assignedEntity>

</author>

In rosso i valori da modificare in nero quelli fissi

$TS_ FIRMA_SSI = Data (e ora) di firma del documento (può esser fatta coincidere con quella di creazione del documento). Formato [YYYYMMddhhmmss+|-ZZzz] . e.g.

20080712173020+0100 equivale alle 17.30 (e 20 sec) del 12 Luglio 2008 ore .

$$ID_REG_MEDICO = Identificativo regionale del Medico.

$COD_FISCALE_MMG = Codice fiscale del Medico

$NOME = Nome del Medico

$COGNOME = Cognome del Medico

$ID_ASL = Identificativo dell’ASL di appartenenza del Medico

$NOME_ASL = Nome dell’ASL di appartenenza del Medico

5.13 Custode

L’elemento obbligatorio che identifica l’organizzazione incaricata della custodia del documento originale è rappresentata dal tag <custodian>.

In generale può essere la struttura di cui fa parte l’autore , l’ASL di riferimento, oppure la Regione stessa.

Nel caso del documento in oggetto - all’interno della rete di MMG - si reputa essere la Regione Abruzzo l’organizzazione responsabile della conservazione del documento.

Il <custodian> è un elemento composto da un ruolo di tipo <assignedCustodian> verso un’entità <representedCustodianOrganization>.

Per la corretta generazione del documento è obbligatorio riempire l'attributo <custodian> e

<representedCustodianOrganization>.

L’elemento viene pertanto ad essere strutturato come segue:

<name>Regione Abruzzo</name>

</representedCustodianOrganization>

</assignedCustodian>

</custodian>

5.14 Contatti del paziente

Per veicolare le informazioni relative ai contatti (lista riferimenti) viene usata la classe

<participant>.

Tale elemento nel CDA viene genericamente utilizzato per indicare tutti coloro (persone od organizzazioni) che sono in qualche forme coinvolti nell’atto descritto, ma non esplicitamente referenziate in altri elementi presenti nell’header (author, informant, authenticator,….). L’entità “participant” non deve necessariamente essere coinvolta direttamente nell’atto documentato.

Questo elemento indica un familiare, un parente, assistenti sociali, organizzazioni di volontariato/religiose, ecc., diversi dal tutore legale.

Per indicare la priorità con cui i riferimenti devono essere chiamati si deve fare riferimento all’ordine di elencazione dei <participant>.

Un paziente può essere caratterizzato da uno o più contatti. La tipologia di contatto viene determinata in prima istanza attrverso il classCode dell’ <associatedEntity>

Un <participant> può essere classificato come parente, contatto di emergenza, o, genericamente, chi fornisce assistenza ad anziani/malati (infermiere, badante, ecc.).

L’attributo <typecode> dell’elemento <participant> deve essere sempre valorizzato con “IND” ad indicare una partecipazione “INDIRETTA” all’atto.

Per tutti i contatti – se tale informazione è nota – si deve valorizzare gli elmenti <addr> e

<telecom>, nonché i dettgli anagrafici <associatedPerson><name><family> e

<associatedPerson><name><given> relativi al contatto Parenti.

Nelle sezioni seguenti sono riportati alcuni esempi di uso dell’elemento <participant> per gestire:

Ł parenti

Ł contatti in caso di emergenza

Ł assistenza a malati ed anziani

5.14.1 Parenti

I contatti di tipo “Parente” sono i familiari, i parenti più o meno stretti, ecc.

Sono caratterizzati dai seguenti valori:

<associatedEntity >:

Attributo

Tipo

Valore

Dettagli

classCode

“NOK”

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

Se utilizzato l’elemento <code> DOVREBBE essere valorizzato come indicato in tabella:

Attributo

Tipo

Valore

Dettagli

code

[codice Tipo Parente]

Codice che identifica il tipo di relazione col paziente derivato dalla tabella HL7

PersonalRelationshipRoleType

codeSystem

OID

2.16.840.1.113883.5.111

OID – che identifica la codifica

displayName

[Grado Parentela]

codeSystemName

PersonalRelationshipRoleType

Può essere caratterizzata da un <id> che se presente deve essere valorizzato come segue:

<id>:

Attributo	Tipo	Valore	Dettagli
Root	OID	2.16.840.1.113883.2.9.4.3.2	OID Ministero economia e finanze – CF
Extension	ST	[CODICE FISCALE]	CF del paziente
assigningAuthorityName	ST	“MEF”	Ministero dell’Economia e delle Finanze

5.14.2 Emergenza

I contatti di tipo “contatto di emergenza” sono i contatti da chiamare nel caso di emergenza.

<associatedEntity >:

Attributo

Tipo

Valore

Dettagli

classCode

“ECON”

Codice che identifica il “Contatto di Emergenza“

(Emergency CONtact)

Può essere caratterizzata da un <id> che se presente deve essere valorizzato come segue:

<id>:

Attributo	Tipo	Valore	Dettagli
Root	OID	2.16.840.1.113883.2.9.4.3.2	OID Ministero economia e finanze – CF
Extension	ST	[CODICE FISCALE]	CF del paziente
assigningAuthorityName	ST	“MEF”	Ministero dell’Economia e delle Finanze

5.14.3 Assistenza Malati ed Anziani

I contatti di tipo “assistenza ad anziani e malati” sono tutti coloro che prestano assistenza (infermiere, badante, ecc.)

< associatedEntity >:

Attributo

Tipo

Valore

Dettagli

classCode

“CAREGIVER”

Codice che identifica il contatto “Assistenza ad Anziani e Malati” (Caregiver)

Può essere caratterizzata da un <id> che se presente deve essere valorizzato come segue:

<id>:

Attributo	Tipo	Valore	Dettagli
Root	OID	2.16.840.1.113883.2.9.4.3.2	OID Ministero economia e finanze – CF
Extension	ST	[CODICE FISCALE]	CF del paziente
assigningAuthorityName	ST	“MEF”	Ministero dell’Economia e delle Finanze

Si riportano i constraint definiti per la sezione contatti (support) nel CCD.

CONF-108	CCD MAY contain one or more patient guardians.
CONF-109 A patient guardian SHALL be represented with ClinicalDocument / recordTarget / patientRole / patient / guardian.
CONF-110	CCD MAY contain one or more next of kin.
CONF-111 A next of kin SHALL be represented with ClinicalDocument / participant / associatedEntity.
CONF-112 The value for “ClinicalDocument / participant / @typeCode” in a next of kin participant SHALL be “IND” “Indirect participant” 2.16.840.1.113883.5.90 ParticipationType STATIC.
CONF-113 The value for “ClinicalDocument / participant / associatedEntity / @classCode” in a next of kin participant SHALL be “NOK” “Next of kin” 2.16.840.1.113883.5.41 EntityClass STATIC.
CONF-114 The value for “ClinicalDocument / participant / associatedEntity / code” in a next of kin participant SHOULD be selected from ValueSet 2.16.840.1.113883.1.11.19579 FamilyHistoryRelatedSubjectCode DYNAMIC or 2.16.840.1.113883.1.11.20.21 FamilyHistoryPersonCode DYNAMIC.
CONF-115	CCD MAY contain one or more emergency contact.
CONF-116 An emergency contact SHALL be represented with ClinicalDocument / participant / associatedEntity.
CONF-117 The value for “ClinicalDocument / participant / @typeCode” in an emergency contact participant SHALL be “IND” “Indirect participant” 2.16.840.1.113883.5.90 ParticipationType STATIC.
CONF-118 The value for “ClinicalDocument / participant / associatedEntity / @classCode” in an emergency contact participant SHALL be “ECON” “Emergency contact” 2.16.840.1.113883.5.41 EntityClass STATIC.
CONF-119	CCD MAY contain one or more patient caregivers.
CONF-120 A patient caregiver SHALL be represented with ClinicalDocument / participant / associatedEntity.
CONF-121 The value for “ClinicalDocument / participant / @typeCode” in a patient caregiver participant SHALL be “IND” “Indirect participant” 2.16.840.1.113883.5.90 ParticipationType STATIC.
CONF-122 The value for “ClinicalDocument / participant / associatedEntity / @classCode” in a patient caregiver participant SHALL be “CAREGIVER” “Caregiver” 2.16.840.1.113883.5.41 EntityClass STATIC.

Esempio d’uso:

<addr>

<streetAddressLine>via Salaria, 23</streetAddressLine>

</addr>

<name>

<given>Xxxxx</given>

<family>Xxxxx</family>

</name>

</associatedPerson>

</associatedEntity>

</participant>

<name>

<given>Xxxxxx</given>

<family>Xxxxxxx</family>

</name>

</associatedPerson>

</associatedEntity>

</participant>

Questa sezione puo' essere utilizzata per inserire qualunque tipo di contatto, andando a specializzare il participant.typeCode e participant.classCode

5.14.4 Note implementative

Una gestione fortemente strutturata dei dati anagrafici relativi ai contatti, sebbene a livello informatico auspicabile, non è spesso coerente con le aspettative applicative degli operatori sanitari (i.e il medico è interessato in generale ad avere dei promemoria sui contatti relativi ad un paziente; non è interessato a fare ricerche od analisi su queste informazioni) .

In considerazione di questo, nella maggioranza dei casi gli applicativi avranno informazioni testuali destrutturate, che potranno essere gestite come segue:

<addr>$STR_INDIRIZZO_CONTATTO</addr>

<name>$STR_REF_CONTATTO</name>

</associatedPerson>

</associatedEntity>

</participant>

<addr>$STR_CONTATTO</addr>

</associatedEntity>

</participant>

5.15 documentationOf

Il template CCD richiede che l’elemento documentationOf sia presente e valorizzato. Tale elemento indica che questo documento è stato creato al fine di documentare un evento (<serviceEvent>) di Cura del Paziente.

L’intervallo di durata dell’evento in seguito al quale è stato redatto il Patient Summary è rappresentato mediante un elemento <effectiveTime>.

Nel contesto d’uso della SSI, il tavolo TSE non ritiene tuttavia l’uso di questo elemento essenziale: si mantiene perciò l’obbligatorietà dell’<effectiveTime> solo per conformità al template CCD, richidendone tuttavia la sua valorizzazione a nullFlavor=”NI”.

Uso:

</effectiveTime>

</serviceEvent>

</documentationOf>

5.16 Altre Informazioni

L’header del CDA può contenere altre informazioni realtive al contesto di uso di questo documento (e.g. <dataEnterer>; <informationRecipient>;…..).

Riguardo l’uso di questi elementoi si faccia riferimento alla documentazione ufficiale di HL7 CDA Normative Edition 2005.

6 Body della Scheda Sanitaria Individuale

In questa sezione si definisce il BODY del documento Scheda Sanitaria Individuale, 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 della Scheda Sanitaria Individuale.

Esempio d’uso:

</component>

</component>

... </section>

</component>

</structuredBody>

</component>

La classe <section> è una classe composta che prevede un attributo <text> 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> o tabelle <table>), un attributo <code> OBBLIGATORIO che specifica il codice della tipologia di sezione e uno o più elementi <entry> FACOLTATIVE che ne definiscono il contenuto codificato.

Il contenuto informativo della parte narrativa (<text>) DEVE essere un sovra insieme delle informazioni contenute nella parte codificata (<entry>): i.e. non ci devono essere informazioni veicolate attraverso entry che non abbiano un corrispondente nella parte

testuale.

Nota: tutti gli OID caratterizzati dal codice “99” sono da considerarsi usati solo a titolo esemplificativo. Tali OID dovranno essere opportunamnente valorizzati.

Nota: I template ID caratterizzati dal codice “99” identificano i template che specializzano quelli CCD ed IHE-PCC, specifici per la localizzazione all’interno della Scheda Sanitaruia Individuale.

6.1 Allergie, Intolleranze ed Xxxxxxx (Alerts)

All’interno del modello informativo previsto per il SSI le intolleranze sono state classificate in due macro classi:

Ł Quelle di origine farmacologiche

Ł e quelle di natura diversa (e.g quelle di origine alimentare, ambientale,….)

L’intolleranza/allergia ha normalmente un ‘agente’ al quale il paziente reagisce ed è potenzialemente caratterizzato da specifici sintomi ( reazioni ).

Le intolleranze (allergie e non) sono descritte nella sezione CCD Alerts (crf. Cap 3.8) [template 2.16.840.1.113883.10.20.1.2], a cui è associato il modello informativo seguente. Tale template è specializzato in IHE PCC attraverso il template 1.3.6.1.4.1.19376.1.5.3.1.3.13.

Il modello informativo associato alla sezione degli Alerts è:

La sezione alert include non solo informazioni relative alle intolleranze ma ogni generico allarme.

Possibili asserzioni sono:

Intolleranze/Allergie a Farmaci :

1. Reazione avversa a AUGMENTIN*12cpr riv 875mg+125M 026089019, ( causato prurito e rossore) . Insorgenza 10/05/2005

2. Intolleranza a AUGMENTIN*12cpr riv 875mg+125M (estesa a tutti gli ATC J01C )

3. Intolleranza a P.A. amoxicillina

4. Allergia a P.A. amoxicillina

5. Intolleranza a tutti gli antibiotici tranne amoxicillina

6. Allergia ad ATC J01C

7. Reazione avversa a preparato erboristico con ortica

Altri Allarmi

8. Allergia pollini

9. Allergia prodotti caseari (attenzione possibile shock mortale!)

10. Intolleranza alimentare a formaggio (si gratta tutta la notte)

11. Intolleranza alla luce

12. Allarme: persona con fobie maniacali: non dire mai la parole “gatto” altrimenti si infuria.

13. Non Sono Note Allergie 1

6.1.1 Specifiche di Sezione

Le informazioni relative alle allergie ed alle reazioni avverse ai farmaci, ai mezzi di contrasto, o ad altre sostanze (ed ad eventuali altre condizioni di allarme) sono mappate all’interno del CCD nella sezione “alerts” definito dal template "2.16.840.1.113883.10.20.1.2".

Tale template è specializzato in IHE PCC attraverso il template 1.3.6.1.4.1.19376.1.5.3.1.3.13. Per tale sezione CCD impone i seguenti vincoli:

1 L’impl Guide CCD raccomanda fortemente (SHOULD) - anche se non obbliga - il medico di dichiarare che non è a conoscenza di allergie, qualora non ne dichiari alcuna . Si invitano gli sviluppatori di sw per mmg a prevedere la possibilità di identificare eventuali allergie quando si registrano allarmi e reazioni avverse di qualsiasi tipo. Comunque, già da ora in assenza di alcuna indicazione di allarme sarebbe opportuno esplicitare l’assenza di allergie note.

CONF-256 CCD SHOULD contain exactly one and SHALL NOT contain more than one Alerts section (templateId 2.16.840.1.113883.10.20.1.2). The Alerts section SHALL contain a narrative block, and SHOULD contain clinical statements. Clinical statements SHOULD include one or more problem acts (templateId 2.16.840.1.113883.10.20.1.27). A problem act SHOULD include

one or more alert observations (templateId 2.16.840.1.113883.10.20.1.18).

CONF-257 The absence of known allergies, adverse reactions, or alerts SHALL be explicitly asserted

CONF-258 The alert section SHALL contain Section / code.

CONF-259 The value for “Section / code” SHALL be “48765-2” “Allergies, adverse reactions, alerts” 2.16.840.1.113883.6.1 LOINC STATIC.

CONF-260 The alert section SHALL contain Section / title.

CONF-261 Section / title SHOULD be valued with a case-insensitive language-insensitive text string containing “alert” and/or “allergies and adverse reactions”.

In base alle condizioni sopra espresse la sezione dovrà essere così strutturata:

<title>Allergie, Intolleranze ed Xxxxxxx</title>

<text>

$NARRATIVE_BLOCK

</text>

<entry>

$ALERT

</entry>

</section>

</component>

L’assenza di allergie o reazioni allergiche conosciute DEVE essere esplicitamente indicata. (vedi $ 6.1.5 - Indicazione assenza Allergie Note)

In rosso i valori da modificare in nero quelli fissi

$ID_SEZ = ID Unico della sezione (data type HL7 II )

$NARRATIVE_BLOCK = contenuto della sezione <text> vedi esempio

$ALERT = Allarme (specializzazione dei template ‘2.16.840.1.113883.10.20.1.27' e '1.3.6.1.4.1.19376.1.5.3.1.4.5.3') vedi § 6.1.2 - Descrizione Allarme

6.1.2 Descrizione Allarme

Il dettaglio dell’allarme è gestito attraverso un Problem Act che relativamente al template CCD, segue i seguenti criteri di conformità :

CONF-145 A problem act (templateId 2.16.840.1.113883.10.20.1.27) SHALL be represented with Act.

CONF-146 The value for “Act / @classCode” in a problem act SHALL be “ACT” 2.16.840.1.113883.5.6 ActClass STATIC.

CONF-147 The value for “Act / @moodCode” in a problem act SHALL be “EVN” 2.16.840.1.113883.5.1001 ActMood STATIC.

CONF-148 A problem act SHALL contain at least one Act / id.

CONF-149 The value for “Act / code / @NullFlavor” in a problem act SHALL be “NA” “Not applicable” 2.16.840.1.113883.5.1008 NullFlavor STATIC.

CONF-150 A problem act MAY contain exactly one Act / effectiveTime, to indicate the timing of the concern (e.g. the interval of time for which the problem is a concern).

CONF-151 A problem act SHALL contain one or more Act / entryRelationship.

CONF-152 A problem act MAY reference a problem observation, alert observation or other clinical statement that is the subject of concern, by setting the value for “Act / entryRelationship / @typeCode” to be “SUBJ” 2.16.840.1.113883.5.1002 ActRelationshipType

STATIC.

CONF-153 The target of a problem act with Act / entryRelationship / @typeCode=”SUBJ” SHOULD be a problem observation (in the Problem section) or alert observation (in the Alert

section, see section), but MAY be some other clinical statement.

In base alle condizioni sopra espresse la sezione dovrà essere così strutturata:

<!— template che indica restrizioni specifiche per la SSI -->

<!- OPZIONALE -->

</effectiveTime>

<!—UNA SOLA entryRelationship -->

$ALRT_CONCERN | $OINT_CONCERN | $NO_ALLERGIES

</entryRelationship>

</act>

In rosso i valori da modificare in nero quelli fissi

$ID_SEZ = ID Unico della sezione (data type HL7 II )

$LOW_TS = data di inzio “tracciamento” del problema. Se non noto valorizzare l’elemento col nullFlavor = UNK.

$HIGH_TS = data di fine tracciamento del problema. Non presente se stato diverso da aborted o completed.

$STATUS_CODE = Stato dell’atto (vedi tabella sotto)

$ALRT_CONCERN = Dettagli Allarme Generico (specializzazione dei template 2.16.840.1.113883.10.20.1.18' e 1.3.6.1.4.1.19376.1.5.3.1.4.6') vedi § 6.1.3 - Alert Observation

CONF-262 An alert observation (templateId 2.16.840.1.113883.10.20.1.18) SHALL be represented with Observation.

CONF-263 The value for “Observation / @moodCode” in an alert observation SHALL be “EVN” 2.16.840.1.113883.5.1001 ActMood STATIC.

CONF-264 An alert observation SHALL include exactly one Observation / statusCode.

CONF-265 The value for “Observation / statusCode” in an alert observation SHALL be “completed” 2.16.840.1.113883.5.14 ActStatus STATIC.

CONF-266 An alert observation MAY contain exactly one Observation / effectiveTime, to indicate the biological timing of condition (e.g. the time the condition started, the onset of the illness or symptom, the duration of a condition).

CONF-267 The value for “Observation / value” in an alert observation MAY be selected from ValueSet 2.16.840.1.113883.1.11.20.4 AlertTypeCode STATIC 20061017.

CONF-268 The absence of known allergies SHOULD be represented in an alert observation

by valuing Observation / value with 160244002 “No known allergies” 2.16.840.1.113883.6.96 SNOMED CT STATIC.

CONF-269 An alert observation SHALL contain one or more sources of information, as defined in section.

Dettagli Allarme Generico.

$OINT_CONCERN = Dettagli Intolleranza o allergia (specializzazione dei template 2.16.840.1.113883.10.20.1.18' e 1.3.6.1.4.1.19376.1.5.3.1.4.6') vedi § 6.1.5

6.1.3 Indicazione assenza Allergie Note

CONF-268 The absence of known allergies SHOULD be represented in an alert observation by valuing Observation / value with 160244002 “No known allergies” 2.16.840.1.113883.6.96 SNOMED CT STATIC.

</effectiveTime>

</originalText>

</value>

</observation>

$ID_SEZ = ID Unico della sezione (data type HL7 II )

$LOW_TS = data inizio stato di assenza di allergie. Se non noto valorizzare l’elemento col nullFlavor = UNK.

$REF_ALLARME = riferimento incrociato alla descrizione dell’elemento nella parte narrativa

- Dettagli intolleranza o allergia.

$NO_ALLERGIES = elemento da utilizzare in caso di assenza di allergie note. Vedi § 6.1.6 - Indicazione assenza Allergie Note

I valori ammissibili per STATUS_CODE sono:

Valore Descrizione

active

suspended

Problema attivo : un problema è attivo fino a quando ci si aspetta che possa essere svolta una qualche attività clinica. Per tutti gli altri stati NON devono essere previste attività.

Il problema è da considerarsi attivo, ma può essere “messo da parte”. Per esempio, dopo

un periodo di assenza di sintomi, senza però che si possa stabilire in via definitiva che sia

Pagina 73/ 208

stato risolto.

aborted

completed

Problema da non considerarsi più attivo, senza che sia da considerarsi risolto.

Per esempio il paziente abbandona la cura.

Il problema , l’allergia o lo stato clinico è stato risolto, è non esiste più la necessità di tracciare il problema eccetto che per scopi di storicizzazione.

Per il Patient Summary lo $STATUS_CODE è sempre uguale a active

6.1.3.1 Vincoli Aggiuntivi

1 solo Problem Observation per ogni Problem Act

6.1.4 Alert Observation

CONF-262 An alert observation (templateId 2.16.840.1.113883.10.20.1.18) SHALL be represented with Observation.

CONF-263 The value for “Observation / @moodCode” in an alert observation SHALL be “EVN” 2.16.840.1.113883.5.1001 ActMood STATIC.

CONF-264 An alert observation SHALL include exactly one Observation / statusCode.

CONF-265 The value for “Observation / statusCode” in an alert observation SHALL be “completed” 2.16.840.1.113883.5.14 ActStatus STATIC.

CONF-266 An alert observation MAY contain exactly one Observation / effectiveTime, to

indicate the biological timing of condition (e.g. the time the condition started, the onset of the illness or symptom, the duration of a condition).

CONF-267 The value for “Observation / value” in an alert observation MAY be selected from ValueSet 2.16.840.1.113883.1.11.20.4 AlertTypeCode STATIC 20061017.

CONF-268 The absence of known allergies SHOULD be represented in an alert observation

by valuing Observation / value with 160244002 “No known allergies” 2.16.840.1.113883.6.96 SNOMED CT STATIC.

CONF-269 An alert observation SHALL contain one or more sources of information, as defined in section.

6.1.5 Dettagli Allarme Generico

In caso di indicazione generica di un allarme non associabile ad una reazione avversa (intolleranze, allergie,.) questa sarà descritta attarverso il seguente template.

Il template è conforme con il template “Allergy and Intolerance Entry” (IHE PCC) ed “Alert Observation” (CDD)

<!—OPZIONALE -->

</effectiveTime>

</originalText>

</observation>

In rosso i valori da modificare in nero quelli fissi

$ID_SEZ = ID Unico della sezione (data type HL7 II )

$LOW_TS = data di insorgenza del problema. Se non noto valorizzare l’elemento col nullFlavor

= UNK.

$HIGH_TS = data di risoluzione del problema. Se il problema è ancora attivo questo valore deve essere omesso.

$REF_ALLARME = riferimento incrociato alla descrizione dell’elemento nella parte narrativa

6.1.6 Indicazione assenza Allergie Note

CONF-268 The absence of known allergies SHOULD be represented in an alert observation

by valuing Observation / value with 160244002 “No known allergies” 2.16.840.1.113883.6.96 SNOMED CT STATIC.

</effectiveTime>

</originalText>

</value>

</observation>

$ID_SEZ = ID Unico della sezione (data type HL7 II )

$LOW_TS = data inizio stato di assenza di allergie. Se non noto valorizzare l’elemento col nullFlavor = UNK.

$REF_ALLARME = riferimento incrociato alla descrizione dell’elemento nella parte narrativa

6.1.7 Dettagli intolleranza o allergia

La descrizione di una intolleranza od allergia sarà descritta attraverso un observation conforme al seguente template.

Il template è a sua volta conforme con il template “Allergy and Intolerance Entry” (IHE PCC) ed “Alert Observations” (CDD).

Qui di seguto i vincoli imposti per il CCD

CONF-270 An alert observation MAY contain exactly one alert status observation.

CONF-271 An alert status observation (templateId 2.16.840.1.113883.10.20.1.39) SHALL be a

conformant status observation (templateId 2.16.840.1.113883.10.20.1.57) (as defined in section).

CONF-272 The value for “Observation / value” in an alert status observation SHALL be selected from ValueSet 2.16.840.1.113883.1.11.20.3 AlertStatusCode STATIC 20061017.

<!—OPZIONALE -->

</effectiveTime>

( $CODED_AGENT | $UNCODED_AGENT )

$CODED_REACTION|$UNCODED_REACTION

<!—STATO dell’Allergia molteplicità 0..1-->

$STATO_ALLERGIA

$NOTE

</observation>

In rosso i valori da modificare in nero quelli fissi

$ID_SEZ = ID Unico della sezione (data type HL7 II )

$OBS_CODE = Indica il tipo di reazione avversa che si sta descrivendo: intolleranza genrica, intolleranza non allergica, allergia,…. Viene valorizzato con i dati della tabella seguente.

$LOW_TS = data di insorgenza del problema. Se non noto valorizzare l’elemento col nullFlavor

= UNK.

$HIGH_TS = data di risoluzione del problema. Se il problema è ancora attivo questo valore deve essere omesso.

$REF_ALLARME = riferimento incrociato alla descrizione dell’elemento nella parte narrativa

$CODED_AGENT = Descrizione agente (codificata). Vedi § 0 - l’allergia al farmaco AUGMENTIN*12cpr riv 875mg è un fatto, l’indicazione che possa essere allergico a tutti i Beta- Lattanidi è una inferenza. In tal caso è più appropriato spezzare l’informazioni su due observation diverse invece di usare l’elemento <transaltion>.

Descrizione Agente (Non Codificato

$UNCODED_AGENT = Descrizione agente (non codificata). Vedi § 6.1.8.2 - Descrizione Agente (Codificato.

$CODED_REACTION = Descrizione reazione (codificata). Vedi § 6.1.9.1 - Descrizione Reazioni (Codificata)

$UNCODED_REACTION = Descrizione reazione (non codificata). vedi § 6.1.9.2 - Descrizione Reazioni (Non Codificata)

$STATO_ALLERGIA = Indicazione dello stato clinico del problema rilevato. Vedi § 6.1.10 - Stato dell’allergia

$NOTE = Eventuali Note. Vedi § 6.1.11 - Commenti

Valore

OINT

Descrizione

Ipersensibilità che porta ad una reazione avversa a fronte di una esposizione ad un agente.

ALG

Allergia

DALG

EALG

Altre Allergie

FALG

FNAINT

Food Non-Allergy Intolerance

DNAINT

ENAINT

Environmental Non-Allergy Intolerance

FINT

DINT

Drug Intolerance

EINT

(Valore più generico)

Ipersensibilità ad un agente causato da una risposta immunologioca ad una esposizione iniziale.

Allergia ad un prodotto farmacologico

Allergia non associabile a farmaci o cibo. E.g. Lattice, polline, etc.

Allergia ad una sostanza generalmente consumata per scopi nutritivi

Ipersensibilità che porta ad una reazione avversa, di tipo non immunitario, associabile ad una sostanza generalmente consumata per scopi nutritivi

Ipersensibilità che porta ad una reazione avversa, di tipo non immunitario, associabile ad un farmaco

Ipersensibilità che porta ad una reazione avversa, di tipo non immunitario, non associabile a farmaci o cibo. E.g. Lattice, polline, etc.

Ipersensibilità che porta ad una reazione avversa associabile ad una sostanza generalmente consumata per scopi nutritivi Ipersensibilità che porta ad una reazione avversa associabile ad un farmaco

Environmental Intolerance Ipersensibilità che porta ad una reazione avversa non

associabile a farmaci o cibo. E.g. Lattice, polline, etc.

Food Intolerance

Drug Non-Allergy Intolerance

Food Allergy

Allergia Farmaci

Intolleranza

Tabella 1 - Tabella valori observation.code (allarmi)

6.1.7.1 Vincoli Aggiuntivi

Non è presente il seguente elemento opzionale (<entryRelationship>) severità (2.16.840.1.113883.10.20.1.55)

6.1.8 Descrizione Agente

L'allergia ad un agente (sia esso un farmaco o no) viene descritta attraverso una observation che dovrebbe contenere almeno un elemento di tipo <participant>, che referenzia la sostanza scatenante all’interno di un elemento <playingEntity>.

Tale soluzione è da utilizzarsi anche nel caso in cui la sostanza non sia un materiale prodotto, o sia un non sostanza:

NOTE: The agent responsible for an allergy or adverse reaction is not always a manufactured

material, nor is it necessarily consumed. The following constraints reflect limitations in the base CDA R2 specification, and should be used to represent any type of responsible agent.

Sebbene la struttura consenta di utilizare l’elemento <traslation> per referenziare quasi sinonimi dell’agente in altri schemi di codifica, l’uso di questo elemento deve essere fatto solo nei casi in cui realmente si tratti di mappare la stessa informazione su due schemi diversi sullo stesso atto. Per esempio nell’esempio sopra riportato “Intolleranza a AUGMENTIN*12cpr riv 875mg+125M (estesa a tutti gli ATC J01C )”, l’allergia al farmaco AUGMENTIN*12cpr riv 875mg è un fatto, l’indicazione che possa essere allergico a tutti i Beta-Lattanidi è una inferenza. In tal caso è più appropriato spezzare l’informazioni su due observation diverse invece di usare l’elemento <transaltion>.

6.1.8.1 Descrizione Agente (Non Codificato)

</code>

</playingEntity>

</participantRole>

</participant>

$REF_AGENT = riferimento incrociato alla descrizione dell’agente nella parte narrativa

6.1.8.2 Descrizione Agente (Codificato)

</code>

</playingEntity>

</participantRole>

</participant>

In rosso i valori da modificare in nero quelli fissi

$COD_AGENTE = codice dell’agente scatenante secondo la codifica utilizzata

$DESC_AGENTE = descrizione dell’agente scatenante

$DESC_COD_SYS_AGENT = descrizione del sistema di codifica utilizzato

$COD_SYS_AGENT = OID dello schema di codifica utilizzato per indicare gli agenti. Valori ammessi

$REF_AGENT = riferimento incrociato alla descrizione dell’agente nella parte narrativa

Valore	Descrizione
2.16.840.1.113883.6.73	WHO ATC
2.16.840.1.113883.2.9.6.1.5	AIC
2.16.840.1.113883.6.96	SNOMED - CT

Tabella 2 - Tabella schemi di codifica agenti (allarmi)

6.1.9 Descrizione Reazione

6.1.9.1 Descrizione Reazioni (Codificata)

<!—OPZIONALE -->

</effectiveTime>

<value xsi:type='CD' code='$COD_REAZ' codeSystem='2.16.840.1.113883.6.103'

displayName='$DESC_REAZ' codeSystemName='ICD-9CM (diagnosis codes)'>

</originalText>

</value>

</observation>

</entryRelationship>

In rosso i valori da modificare in nero quelli fissi

$ID_SEZ = ID Unico della sezione (data type HL7 II )

$LOW_TS = data di insorgenza del problema. Se non noto valorizzare l’elemento col nullFlavor

= UNK.

$HIGH_TS = data di risoluzione del problema. Se il problema è ancora attivo questo valore deve essere omesso.

$DESC_REAZ = descrizione della reazione secondo la codifica ICD-9CM

$COD_REAZ = codice della reazione secondo la codifica ICD-9CM

$REF_AGENT = riferimento incrociato alla descrizione della reazione nella parte narrativa

6.1.9.1.1.1 Vincoli aggiuntivi

Non sono presenti i seguenti elementi (<entryRelationship>) opzionali : 1. severità (2.16.840.1.113883.10.20.1.55)

2. stato di salute (2.16.840.1.113883.10.20.1.51)

3. stato clinico (2.16.840.1.113883.10.20.1.39)

4. commenti ('2.16.840.1.113883.10.20.1.40')

Reazioni codificate usando lo schema ICD9-CM

6.1.9.2 Descrizione Reazioni (Non Codificata)

<!—OPZIONALE -->

</effectiveTime>

</originalText>

</value>

</observation>

</entryRelationship>

In rosso i valori da modificare in nero quelli fissi

$ID_SEZ = ID Unico della sezione (data type HL7 II )

$LOW_TS = data di insorgenza del problema. Se non noto valorizzare l’elemento col nullFlavor

= UNK.

$HIGH_TS = data di risoluzione del problema. Se il problema è ancora attivo questo valore deve essere omesso.

$REF_AGENT = riferimento incrociato alla descrizione della reazione nella parte narrativa

6.1.10 Stato dell’allergia

Lo stato dell’allergia è gestito tramite un elemento di tipo observatio. Tale elemento è collegato all’entità di cui descrive lo stato (allergia, porblema,…) mediante una relazione generica di tipo refers to (<entryRelationship typeCode="REFR" >)

<value xsi:type="CE" code="$COD_STATO" codeSystem="2.16.840.1.113883.6.96"

displayName="$DESC_STATO"/>

</observation>

</entryRelationship>

$REF_ALLARME = riferimento incrociato alla descrizione dello stato nella parte narrativa

$DESC_STATO = codice stato della reazione da tabella seguente

$COD_STATO = descrizione stato della reazione da tabella seguente

Codice

Descrizione

55561003

73425007 Non più

Attivo

Descrizine Originale

Active

No Longer Active

Attivo

Tabella 3 - Tabella valori ammessi per codifica dello stato

Nota: I valori selezionati, intersezione fra i valori ammessi per il template CCD 2.16.840.1.113883.10.20.1.39' (55561003 Active; 392521001 Prior History; 73425007 No

Longer Active) e quelli previsti dal template di IHE PCC (55561003 Active ; 73425007- Inactive

; 90734009- Chronic ; 7087005-Intermittent ; 255227004-Recurrent ; 415684004-Rule out ; 410516002-Ruled out ; 413322009-Resolved ) sono ritenuti sufficienti a descrivere lo stato di una allergia.

Nel caso del PS il valore di code è fissato a 55561003 (Attivo).

6.1.11 Commenti

<code code='48767-8' displayName='Annotation Comment'

codeSystem='2.16.840.1.113883.6.1'

codeSystemName='LOINC' />

</act>

</entryRelationship>

In rosso i valori da modificare in nero quelli fissi

$REF_ALLARME = riferimento incrociato al testo presente nella parte narrativa

6.1.11.1 Vincoli Aggiuntivi

Non presente l’elemento opzionale <author>

6.1.12 Esempio

<!--******************************************************** Alerts section

********************************************************-->

<code code="48765-2" displayName="Allergie, Reazioni Avverse, Allarmi"

codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>

<title>Allergie, Reazioni Avverse ed Xxxxxxx</title>

<text>

<paragraph>Elementi <content ID="stato_algs_attivo">Attivi</content> </paragraph>

<tbody>

<tr>

<th>INTOLLERANZE A FARMACI E PARAFARMACI </th>

</tr>

<tr>

<td>

<content ID="sostanza_1">AUGMENTIN*12cpr riv 875mg.</content>

(Causato <content ID="react_1_1"> prurito</content> e <content ID="react_1_2">rossore</content>) . Insorgenza 10/05/2005</td>

</tr>

</tbody>

</table>

</text>

</effectiveTime>

</effectiveTime>

<code code="026089019" codeSystem="2.16.840.1.113883.2.9.6.1.23"

codeSystemName="AIC" displayName=" AUGMENTIN*12cpr riv 875mgs">

</originalText>

</code>

</playingEntity>

</participantRole>

</participant>

</effectiveTime>

</originalText>

</value>

</observation>

</entryRelationship>

</effectiveTime>

</originalText>

</value>

</observation>

</entryRelationship>

</observation>

</entryRelationship>

</act>

</entry>

</component>

</section >

6.2 Problemi (Problems)

Il medico titolare dei dati del paziente, fra tutti i problemi presenti nella cartella informatizzata del paziente, renderà disponibili tutti gli elementi significativi per riassumere la storia clinica e la condizione attuale dell’assistito.

Questa sezione può contenere dati sui problemi clinici, condizioni, sospetti diagnostici e diagnosi certe, sintomi, attuali o passati del paziente; sono inclusi le liste malattie pregresse, gli organi mancanti.

Possono essere elencati in ordine cronologico inverso o in ordine di importanza, a seconda delle finalità della Scheda Sanitaria Individuale.

I problemi sono caratterizati da uno stato, ad esempio: attivo, non attivo, cronico, intermittente, risolto, ricorrente ecc.

In base ai feedback raccolti dai medici è stata scelto di organizzare gli elementi sopra esposti attraverso la seguente classificazione:

I. Note di storia clinica

II. Patologie

III. Episodi in corso

IV. Patologie remote

V. Organi mancanti

VI. Soggettività - Dati riferiti dal paziente (S)

VII. Esami obiettivi (O)

VIII. Valutazione (V)

IX. Piano di Cura2 (P)

In realtà in un metodologia alla medicina orientata ai problemi le informazioni sopra indicate non sono necessariamente su un singolo livello, ma possono essere strutturare e ogni “problema” può includere elementi aggiuntivi che riguardano la Soggettività , l’Oggettività, la Valutazione ed il Piano. (SOVP). Per complicare ulteriormente la casistica inoltre un macro problema potrebbe al proprio interno contenere altri problemi, a loro volta strutturati in ulteriori SOVP.

Per quanto però prima espresso, gli stessi elementi S-O-V-P, possono poter essere gestiti anche al di fuori di un problema “padre”.

In sintesi:

Ł un “Problema” può contenere SOVP e/o altri Problemi , e riferire di terapie , accertamenti , etc

Ł Possono esistere S, O, V , P non inclusi in un problema.

X Xxxxxxxx esserci problemi non strutturati come SOVP.

2 Nota: questa classe di informazione non è registrata nella sezione Problems, bensì in Plano of Care

Per ridurre la complessità delle possibili casistiche relative alle combinazioni fra Problemi e SOVP e fra problemi e problemi, ed evitare di duplicare le stesse informazioni in parti diverse del documento sono state decise le seguenti limitazioni:

I. si considera solo Problemi con VP , trattando tutte le S ed O come elementi non associati ad un problema padre.

II. Si limita ad un solo livello la relazione fra problemi

III. le O, che sono veri e propri accertamenti eseguiti dal medico, sono presentati nel documento come gli altri accertamenti (i.e senza legame al problema)

Esempi Problema

--Valutazione 1

--Valutazione 2

--Piano

Problema

--Piano

-- Problema 1

-------Valutazione 1

-------Valutazione 2

I problemi sono riportabili nel pattern Problems di CCD.

Il modello informativo associato alla sezione dei Problemi è:

Alcuni esempi di rappresentazione del contenuto della sezione sono: Organi Mancanti

Organi mancanti: gamba destra

Note di Storia Clinica

NOTA generale: fin da piccola era malaticcia

Patologie

BRONCHITE ASMATICA (2008 Apr) DIABETE MELLITO (2008 Apr)

BPCO BRONCHITE CRONICA OSTRUTTIVA (2008 Apr) IPERTENSIONE ARTERIOSA (1997)

ANGINA PECTORIS (1997)

Patologie remote

K CUTANEO (1997)

6.2.1 Specifiche di sezione

Sezione che dovrebbe essere presente e che deve essere unica in tutto la Scheda Sanitaria Individuale. Potrà essere presente una sezione narrativa, ma dovrebbe contenere la parte strutturata.

• La parte stutturata dovrebbe contenere uno o più problem acts (templateId 2.16.840.1.113883.10.20.1.27).

• Un problem act dovrebbe dovrà includere uno o più problem observation (templateId 2.16.840.1.113883.10.20.1.28).

CONF-140 CCD SHOULD contain exactly one and SHALL NOT contain more than one Problem section (templateId 2.16.840.1.113883.10.20.1.11). The Problem section SHALL contain a narrative block, and SHOULD contain clinical statements. Clinical statements SHOULD include one or more problem acts (templateId 2.16.840.1.113883.10.20.1.27). A problem act

SHOULD include one or more problem observations (templateId 2.16.840.1.113883.10.20.1.28).

CONF-141: The problem section SHALL contain Section / code.

CONF-142: The value for “Section / code” SHALL be “11450-4” “Problem list” 2.16.840.1.113883.6.1 LOINC STATIC.

CONF-143: The problem section SHALL contain Section / title.

CONF-144: Section / title SHOULD be valued with a case-insensitive language- insensitive text string containing “problems”.

La sezione è individuata da un elemento <templateId root="2.16.840.1.113883.10.20.1.11"/> . e da uno <templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.6”/>

In base alle condizioni sopra espresse la sezione dovrà essere così strutturata:

<code code='11450-4' displayName='Lista dei Problemi'

codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/>

<title>Problemi</title>

<text>

$NARRATIVE_BLOCK

</text>

<entry>

$PROBLEM_ACT

</entry>

</section>

</component>

In rosso i valori da modificare in nero quelli fissi

$ID_SEZ = ID Unico della sezione (data type HL7 II )

$NARRATIVE_BLOCK = contenuto della sezione <text> vedi esempio.

$ PROBLEM_ACT = Problema (inteso nella sua accezione pià generale: organo mancante, problema, S, O. Specializzazione dei template 2.16.840.1.113883.10.20.1.27' e '1.3.6.1.4.1.19376.1.5.3.1.4.5.2') vedi § 6.2.3 - Problema

6.2.2 Modalità di gestione dei problemi “strutturati” (folder)

La descrizione di un problema composto da più episodi collegati viene gestita - all’interno di un Problem Act - tramite relazioni verso clinical statement (act, observation). Questo può essere fatto sia per inclusione all’interno di un singolo atto, sia per riferimento verso elementi esterni.

Inoltre CCD prevede l’uso di un template specifico (Episode Observation) per distinguere fra più occorrenze dello stesso problema. (vedi per dettagli § 6.2.7 - Gestione episodicità )

Nelle figure seguenti sono rappresentate graficamente quanto sopra indicato.

Entry

ACT

id=1

entryRelationship 1…N

Observation problem

entryRelationship

Problem status observation

entryRelationship principale

observation Episode observation

entryRelationship Starts after start collegamento esterno

Entry

ACT

id=2

entryRelationship

Observation problem

entryRelationship

Problem status observation

Observation

Entry

ACT

id=100

entryRelationship

Observation problem

entryRelationship

Problem status observation

entryRelationship

Observation problem

entryRelationship

Problem status observation

Observation

Alla luce di quanto sopra indicato nell’introduzione, si sceglie di adottare la seguente soluzione:

Ł le valutazioni sono gestite “per inclusione” all’interno del problem act principale

Ł i problemi “semplici” referenziati da altri problemi sono gestiti come Observation “per inclusione”

Ł i problemi “composti” (SOVP) referenziati da altri problemi sono gestiti per riferimento all’interno del porblem act principale

Ł le relazioni con Soggettività ed Oggettività potrebbero essere gestite per riferimento all’interno del porblem act principale

6.2.3 Problema

Un problema è descritto attraverso un Problem Act che, relativamente al template CCD, segue i criteri di conformità definiti nella sezione 6.1.2 “Descrizione Allarme”.

In base alle condizioni sopra espresse l’elemento dovrà essere così strutturato:

<!— template che indica restrizioni specifiche per la SSI -->

<!—OPZIONALE -->

<!- OPZIONALE -->

</effectiveTime>

$PROBLEM_OBS

</entryRelationship>

<!—OPZIONALE O..N entry relationships USATO PER LA GESTIONE dell’episodicità -->

$RELAZ_EPISODIO

</entryRelationship>

<!—STATO di salute del paziente Molteplicità 0..1-->

$STATO_SALUTE

( $PROBLEM_OBS | $RIFERIMENTO )

</entryRelationship>

</act>

In rosso i valori da modificare in nero quelli fissi

$ID_SEZ = ID Unico della sezione (data type HL7 II )

$LOW_TS = data di apertura del problema. Se non noto valorizzare l’elemento col nullFlavor =

UNK.

$HIGH_TS = data di chiusura del problema. Non presente se stato diverso da aborted o completed.

$STATUS_CODE = Stato dell’atto , valori ammessi 'active|suspended|aborted|completed'

$PROBLEM_OBS = Dettagli del problema (specializzazione dei template '2.16.840.1.113883.10.20.1.28' e '1.3.6.1.4.1.19376.1.5.3.1.4.5' vedi § 6.2.4 - Dettagli problema

$STATO_SALUTE = Indicazione dello stato del paziente in relazione al problema . vedi § 6.2.6 - Stato di Salute

$RELAZ_EPISODIO = struttura usata per distinguere per distinguere fra più occorrenze dello stesso problema. vedi per dettagli § 6.2.7 - Gestione episodicità )

$RIFERIMENTO = struttura usata per referenziare altri atti (atti, osservazioni, somministrazioni, piani di cura….). Utilizza il template '1.3.6.1.4.1.19376.1.5.3.1.4.4.1'. Vedi § 6.2.8 - Riferimenti Interni

6.2.4 Dettagli problema

Il dettaglio di un problema è descritto come una Observation, che segue almeno i seguenti criteri di conformità :

CONF-154 A problem observation (templateId 2.16.840.1.113883.10.20.1.28) SHALL be represented with Observation.

CONF-155 The value for “Observation / @moodCode” in a problem observation SHALL be “EVN” 2.16.840.1.113883.5.1001 ActMood STATIC.

CONF-156 A problem observation SHALL include exactly one Observation / statusCode.

CONF-157 The value for “Observation / statusCode” in a problem observation SHALL be “completed” 2.16.840.1.113883.5.14 ActStatus STATIC.

CONF-158 A problem observation SHOULD contain exactly one Observation / effectiveTime, to indicate the biological timing of condition (e.g. the time the condition

started, the onset of the illness or symptom, the duration of a condition).

CONF-159 The value for “Observation / code” in a problem observation MAY be selected from ValueSet 2.16.840.1.113883.1.11.20.14 ProblemTypeCode STATIC 20061017.

CONF-160 The value for “Observation / entryRelationship / @typeCode” in a problem

observation MAY be “SUBJ” “Subject” 2.16.840.1.113883.5.1002 ActRelationshipType STATIC to reference an age observation (templateId 2.16.840.1.113883.10.20.1.38).

CONF-161 A problem observation SHALL contain one or more sources of information, as defined in section.

In base alle condizioni sopra espresso l’elemento dovrà essere così strutturato:

<!— template che indica restrizioni specifiche per la SSI -->

<!- OPZIONALE -->

</effectiveTime>

<value xsi:type='CD' ( code='$COD_PROB' displayName='$DESC_PROB' codeSystem="2.16.840.1.113883.6.103" codeSystemName="ICD-9CM (diagnosis codes)" ) |

nullFlavor=”OTH”>

</value>

<!—STATO molteplicità 0..1-->

$STATO_PROBLEMA

$NOTE

</observation>

Nota: se viene usato l’attributo opzionale negationInd = true, si afferma esplicitamente che il problema specifico non è in atto.

In rosso i valori da modificare in nero quelli fissi

$ID_SEZ = ID Unico della sezione (data type HL7 II )

$OBS_CODE , $OBS_DESC = Indica il tipo di problema osservato. Dovrebbe essere valorizzato con i dati della tabella seguente. (Tabella 4 - Codifica Observation (<code>))

$LOW_TS = data di insorgenza del problema. Se non noto valorizzare l’elemento col nullFlavor

= UNK.

Document Metadata

Table of Contents

Specifiche tecniche per la produzione della Scheda Sanitaria Individuale in formato HL7 Versione 3 CDA Rel.2 secondo template CCD Progetto Esecutivo Definitivo Accordo di Programma Quadro Atto Integrativo II - SI-II-09

Document Metadata