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

Dimensione: px
Iniziare la visualizzazioe della pagina:

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

Transcript

1 Sanitaria Individuale in formato HL7 Versione 3 CDA Rel.2 secondo template CCD Progetto Esecutivo 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. Pagina 1/ 208

2 Pagina 2/ 208

3 INDICE 1 DEFINIZIONI, ACRONIMI ED ABBREVIAZIONI Acronimi: Abbreviazioni: Convenzioni grafiche e sintattiche RIFERIMENTI Premessa Organizzazione del documento INTRODUZIONE Stati del documento HEADER DELLA SCHEDA SANITARIA INDIVIDUALE Root del documento Dominio del documento Identificativo CDA-R Identificativo di template CDA-R2 in uso Identificativo unico del singolo documento Tipologia del Documento Data di creazione documento Riservatezza del documento Lingua del documento e Dominio Versione del documento Pagina 3/ 208

4 4.11 Dati Anagrafici del paziente Dati anagrafici del paziente Tutore legale Autore e autenticatore Autore Firmatario del documento Custode Contatti del paziente Parenti Emergenza Assistenza Malati ed Anziani Note implementative documentationof Altre Informazioni BODY DELLA SCHEDA SANITARIA INDIVIDUALE Allergie, Intolleranze ed Allarmi (Alerts) Specifiche di Sezione Descrizione Allarme Vincoli Aggiuntivi Alert Observation Dettagli Allarme Generico Indicazione assenza Allergie Note Dettagli intolleranza o allergia Vincoli Aggiuntivi Descrizione Agente Descrizione Agente (Non Codificato) Descrizione Agente (Codificato) Descrizione Reazione Descrizione Reazioni (Codificata) Vincoli aggiuntivi Descrizione Reazioni (Non Codificata) Stato dell allergia Commenti Vincoli Aggiuntivi Esempio Problemi (Problems) Specifiche di sezione Modalità di gestione dei problemi strutturati (folder) Problema...94 Pagina 4/ 208

5 5.2.4 Dettagli problema Vincoli aggiuntivi Stato clinico Stato di Salute Gestione episodicità Riferimenti Interni Organi Mancanti Esempio Piani di Cura Specifiche Sezione Dettaglio Attività Piano di Cura Esempi Prescrizione Prestazione Riabilitativa Richiesta osservazione Farmaci (Medications) Specifiche di Sezione Descrizione Terapia Posologia Dettagli Farmaco Ragione Esempio Vaccinazioni (Immunization) Specifiche di Sezione Vaccinazione Vincoli aggiuntivi Esempio Narrative Block Coded Entry Procedure (Procedures) Specifiche di sezione Dettagli Procedura Vincoli aggiuntivi Esempio Visite e Ricoveri (Encounter) Specifiche di sezione Dettagli Incontro Vincoli aggiuntivi Performer Luogo Esempio Risultati esami e visite (Results) Pagina 5/ 208

6 5.8.1 Specifiche di Sezione Result Organizer Dettaglio Osservazione Esempio Rilevazioni (Vital Signs) Specifiche di sezione Vital Sign Organizer Vital Signs Observation Vincoli aggiuntivi NarrativeBlock Stile di Vita (Social History) Specifiche di Sezione Esempio Narrative Block Costante Biologica Gruppo Sanguigno Protesi Organi Mancanti Protesi ed Ausilii (Medical Equipment) Specifiche di sezione Esempi Narrative_Block Anamnesi Familiare (Family History) Specifiche di sezione Familiarità Vincoli aggiuntivi Dettagli su familiarità Vincoli aggiuntivi Causa di morte Informazioni sull età Esempio Narrative Block Familiarità (Family History Organizer) TABELLE Codifica Istat Regioni Tabella A.8 Codici Istat Province Tabella A.9 Codifica Comuni d Italia Pagina 6/ 208

7 6.4 Tabella A.10 Codifica ASL Tabelle di servizio... Errore. Il segnalibro non è definito Participation Function Parentele (PersonalRelationshipRoleType) Unità di misura ActEncounterCode Pagina 7/ 208

8 Revisioni Nella tabella che segue sono riportate le indicazioni sugli aggiornamenti applicati al documento Versione Data Descrizione /07/2008 Prima stesura del documento Pagina 8/ 208

9 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. Pagina 9/ 208

10 2 Definizioni, Acronimi ed Abbreviazioni Pagina 10/ 208

11 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 Pagina 11/ 208

12 2.2 Abbreviazioni: Sigla e.g. i.e. Esteso Exempli gratia (per esempio) Id est (cioè) Pagina 12/ 208

13 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. Pagina 13/ 208

14 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). Pagina 14/ 208

15 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 Risulta inoltre utile per una corretta valutazione di questo documento anche la conoscenza del Technical Framework IHE Patient Care Coordination, Revision 3.0, 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. Pagina 15/ 208

16 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 Pagina 16/ 208

17 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. Pagina 17/ 208

18 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 Pagina 18/ 208

19 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. Pagina 19/ 208

20 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=" xsi:schemalocation="urn:hl7-org:v3 CDA.xsd" xmlns:voc="urn:hl7-org:v3/voc" xmlns="urn:hl7-org:v3"> Pagina 20/ 208

21 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: <realmcode code="it"/> Pagina 21/ 208

22 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 extension ST POCD_HD Esempio : Object Identifier di HL7 per i modelli registrati Codifica identificativa del CDA Release Two Hierarchical Description che è lo schema che contiene la gerarchia delle classi di un documento CDA <typeid root=" " extension="pocd_hd000040"/> Pagina 22/ 208

23 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: Pagina 23/ 208

24 Attributo Tipo Valore Dettagli Root OID OID del catalogo degli schemi dei template di documento per i documenti di Scheda Sanitaria Individuale (Rif: cap 1.4 CCD) extension ST - [CONF-8] [CONF-7] CCD SHALL contain one or more ClinicalDocument / templateid. [CONF-8] At least one ClinicalDocument / templateid SHALL value ClinicalDocument / templateid with , and SHALL NOT contain ClinicalDocument / templateid Il secondo ed il terzo si riferiscono a documenti di tipo Medical Summary come previsti da IHE PCC (root=' ', ' ' ) 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 OID del catalogo degli schemi dei template di documento per i documenti di Scheda Sanitaria Individuale Ipotesi Codice composto PREFISSO: ITPRF extension ST CODICE: SSI per la Identificativo del template di Scheda Sanitaria Individuale documento SCHEDA SANITARIA (generico) INDIVIDUALE VERSIONE: 001 progressivo per il versioning dei template Pagina 24/ 208

25 Esempio: <!-- CCD v1.0 Templates Root --> <templateid root=" "/> <!- Medical Summary --> <templateid root=' '/> <templateid root=' '/> <!-- Identificativo del template di documento SCHEDA SANITARIA INDIVIDUALE in ambito Italiano--> <templateid root=" " extension="itprf_psum_gen-001"/> Pagina 25/ 208

26 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>: root Attributo Tipo Valore Dettagli 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 Pagina 26/ 208

27 appartiene l autore. extension ST [IUD] assigningauthorityname ST [NOME DOMINIO IDENTIFICAZIONE] 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. Nome del dominio di identificazione dei documenti. Può corrispondere al nome della struttura a cui appartiene l autore del documento Esempio : <id root=" " 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 Pagina 27/ 208

28 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 : Pagina 28/ 208

29 <code>: Attributo Tipo Valore Dettagli codesystem OID Codifica LOINC Code CS Codice relativo alla tipologia del documento. ( Summarization of episode note ) codesystemname ST LOINC codesystemversion ST 2.19 Versione codifica LOINC displayname ST SCHEDA SANITARIA INDIVIDUALE [CONF-1] The value for ClinicalDocument / code SHALL be Summarization of episode note LOINC STATIC Esempio: <code code=" " codesystem=" " displayname="scheda SANITARIA INDIVIDUALE" /> Pagina 29/ 208

30 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 TS [YYYYMMddhhmmss+ -ZZzz] Anno, mese, giorno, ora, minuti, secondi Le ore devono essere riportate nell intervallo 00:00:00-23:59:59. ZZzz rappresenta l offset rispetto al tempo di Greenwich (GMT Greenwich Mean Time). L Italia si trova a GMT+1, quindi ZZzz va valorizzato con 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: <effectivetime value="$ts_creazione_ssi"/> Pagina 30/ 208

31 In rosso i valori da modificare in nero quelli fissi $TS_CREAZIONE_SSI = Data (e ora) creazione del documento. Formato [YYYYMMddhhmmss+ -ZZzz]. e.g equivale alle (e 20 sec) del 12 Luglio 2008 ore. Pagina 31/ 208

32 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 * N (normal) (codesystem ) R (restricted) (codesystem ) V (very restricted) (codesystem ) Definition 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. Restricted access, e.g. only to providers having a current care relationship to the patient. Very restricted access as declared by the Privacy Officer of the record holder. Nel caso della prescrizione il tag deve essere così valorizzato : Pagina 32/ 208

33 Attributo Tipo Valore Dettagli codesystem OID OID codifica code ST N Normali regole di riservatezza codesystemname ST Confidentiality Nome della codifica Esempio: <confidentialitycode code="n" codesystem=" " codesystemname="confidentiality"/> Pagina 33/ 208

34 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: ) Nel caso della Scheda Sanitaria Individuale il tag deve essere così valorizzato: Attributo Tipo Valore Dettagli code ST it-it oppure it L attributo deve essere nella forma nn o nn-cc, dove nn è la codifica ISO della lingua in minuscolo e CC è la codifica ISO-3166 dello Stato in maiuscolo [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 language code in lower case. The CC portion, if present, SHALL be an ISO-3166 country code in upper case Esempio: <languagecode code="it-it"/> Pagina 34/ 208

35 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 Pagina 35/ 208

36 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 extension ST [IURD] assigningauthorityname ST [OID del dominio di identificazione dei documenti] [NOME DOMINIO IDENTIFICAZIONE] 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. 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. 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 Pagina 36/ 208

37 <versionnumber>: Attributo Tipo Valore Dettagli value Esempio : INT [progressivo versione documento] Ad ogni successiva versione del documento (RPLC), tale numero incrementa di una unità (partendo da 1) <setid root=" " extension="$setid_doc" assigningauthorityname="regione Abruzzo"/> <versionnumber value="$num_versione"/> 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) Pagina 37/ 208

38 Figura 2: Gestione delle versioni del documento Replace (estratto documentazione HL7) Pagina 38/ 208

39 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) Pagina 39/ 208

40 Per stranieri temporaneamente presenti <patientrole> DEVE riportare il Codice identificativo STP (vedi tabella seguente per esempio di struttura Pagina 40/ 208

41 <id>: Attributo Tipo Valore Dettagli root OID [OID ASL/AO] OID ASL extension ST 4.9.STP + [NUMERO IDENTIFICAZIONE PERSONALE ] assigningauthorityname ST [Nome ASL/AO] Identificativo ramo STP +.STP + Codice STP 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 <recordtarget> <patientrole> <! Identificativi del Paziente/Persona Molteplicità 1 * Caso Assistito coperto da SSN --> <!--Codice Regionale la root corrisponde alla registro degli Assistibili della regione in oggetto --> <id root=" " extension="$id_reg_abruzzo" assigningauthorityname="regione Abruzzo"/> <!-- CODICE FISCALE --> <id root=" " extension="$cod_fiscale_paz" assigningauthorityname="mef"/> <patient> $PATIENT </patient> <! Organizzazione in cui la persona gioca il ruolo di paziente, OPZIONALE --> <providerorganization determinercode="instance"> <id root=" " extension="130" assigningauthorityname="istat" /> <name>regione Abruzzo</name> </providerorganization> </patientrole> </recordtarget> In rosso i valori da modificare in nero quelli fissi Pagina 41/ 208

42 $ID_REG_ABRUZZO = Identificativo unico dell assistito presso la Regione Abruzzo $COD_FISCALE_PAZ = Codice fiscale del paziente $PATIENT = Dettagli anagrafici del paziente. Vedi Dettagli paziente 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> <given>$nome_paz</given> <family>$cognome_paz</family> </name> <administrativegendercode code="m F UN codesystem=" "/> <! TUTTI GLI ALTRI ELEMENTI SONO OPZIONALI Esempio --> <birthtime value="$dataora_nascita_paz"/> <! OPZIONALE TUTORE LEGALE Molteplicità O * --> $TUTORE <birthplace> <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 Pagina 42/ 208

43 $TUTORE = Dettagli su Tutore. Per dettagli vedi 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> 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): <guardian> <! Opzionale --> <id root=" " extension="$cod_fiscale_tutor" assigningauthorityname="mef"/> <guardianperson> <name> <given>$nome</given> <family>$cognome</family> </name> </guardianperson> </guardian> $COD_FISCALE_TUTOR = Codice Fiscale Tutore Legale $NOME = Nome del Tutore Legale $COGNOME = Cognome del Tutore Legale Pagina 43/ 208

44 5.12 Autore e autenticatore 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 Data di creazione documento per ulteriori dettagli ) In questo contesto l'autore del documento è rappresentato sempre da una persona, valorizzata attraverso dall'attributo <assignedperson>. Pagina 44/ 208

45 L autore è identificato da almeno i seguenti <id> : 1. Codice Fiscale 2. Identificativo regionale dell operatore Pagina 45/ 208

46 [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. <assignedperson.name>: Pagina 46/ 208

47 <rapresentedorganization.id>: Pagina 47/ 208

48 Esempio: <author> <time value= $TS_CREAZIONE_SSI"/> <assignedauthor> <!-- Codice FISCALE Metter CF Medico Corretto--> <id root=" " extension="$cod_fiscale_mmg" assigningauthorityname="mef"/> <!-- Codice anagrafica regionale operatori DA CONTROLLARE --> <id root=" " extension="$id_reg_medico" assigningauthorityname="regione Abruzzo"/> <assignedperson> <name> <given>$nome</given> <family>$cognome</family> <suffix>dott.</suffix> </name> </assignedperson> <representedorganization> <!-- Codice Asl di covenzione del Medico titolare delle informazioni --> <id root=" " extension="$id_asl" assigningauthorityname="ssn-min SALUTE - FLS11"/> <name>$nome_asl</name> </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 equivale alle (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 Pagina 48/ 208

49 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 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 Autore per dettagli. Pagina 49/ 208

50 Inoltre DOVRA sempre contenere un elemento <assignedentity>.<id> che contenga il codice fiscale del medico. Esempio: <legalauthenticator> <time value="$ts_firma_ssi"/> <signaturecode code="s"/> <assignedentity> <!-- Codice FISCALE Medico --> <id root=" " extension="$cod_fiscale_mmg" assigningauthorityname="mef"/> <!-- Codice anagrafica regionale operatori --> <id root=" " extension="$id_reg_medico" assigningauthorityname="regione Abruzzo"/> <assignedperson> <name> <given>$nome</given> <family>$cognome</family> <suffix>dott.</suffix> </name> </assignedperson> <representedorganization> <!-- Codice Asl di covenzione del Medico titolare delle informazioni --> <id root=" " extension="$id_asl" assigningauthorityname="ssn-min SALUTE - FLS11"/> <name>$nome_asl</name> </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 equivale alle (e 20 sec) del 12 Luglio 2008 ore. $$ID_REG_MEDICO = Identificativo regionale del Medico. $COD_FISCALE_MMG = Codice fiscale del Medico Pagina 50/ 208

51 $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 Pagina 51/ 208

52 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. Pagina 52/ 208

53 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>. Pagina 53/ 208

54 L elemento viene pertanto ad essere strutturato come segue: <custodian> <!-- Responsabile della conservazione del documento --> <assignedcustodian> <representedcustodianorganization> <id root=" " extension="130" assigningauthorityname="istat" /> <name>regione Abruzzo</name> </representedcustodianorganization> </assignedcustodian> </custodian> Pagina 54/ 208

55 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. Pagina 55/ 208

56 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 Parenti I contatti di tipo Parente sono i familiari, i parenti più o meno stretti, ecc. Pagina 56/ 208

57 Sono caratterizzati dai seguenti valori: Pagina 57/ 208

58 <associatedentity >: Attributo Tipo Valore Dettagli classcode CS 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 CS [codice Tipo Parente] Codice che identifica il tipo di relazione col paziente derivato dalla tabella HL7 PersonalRelationshipRoleType codesystem OID OID che identifica la codifica displayname ST [Grado Parentela] codesystemname ST PersonalRelationshipRoleType Può essere caratterizzata da un <id> che se presente deve essere valorizzato come segue: <id>: Attributo Tipo Valore Dettagli Root OID OID Ministero economia e finanze CF Extension ST [CODICE FISCALE] CF del paziente assigningauthorityname ST MEF Ministero dell Economia e delle Finanze Emergenza I contatti di tipo contatto di emergenza sono i contatti da chiamare nel caso di emergenza. <associatedentity >: Pagina 58/ 208

59 Attributo Tipo Valore Dettagli classcode CS 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 OID Ministero economia e finanze CF Extension ST [CODICE FISCALE] CF del paziente assigningauthorityname ST MEF Ministero dell Economia e delle Finanze 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 CS 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 OID Ministero economia e finanze CF Extension ST [CODICE FISCALE] CF del paziente assigningauthorityname ST MEF Ministero dell Economia e delle Finanze Pagina 59/ 208

60 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 in a next of kin participant SHALL be IND Indirect participant ParticipationType STATIC. CONF-113 The value for ClinicalDocument / participant / associatedentity in a next of kin participant SHALL be NOK Next of kin EntityClass STATIC. CONF-114 The value for ClinicalDocument / participant / associatedentity / code in a next of kin participant SHOULD be selected from ValueSet FamilyHistoryRelatedSubjectCode DYNAMIC or 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 in an emergency contact participant SHALL be IND Indirect participant ParticipationType STATIC. CONF-118 The value for ClinicalDocument / participant / associatedentity in an emergency contact participant SHALL be ECON Emergency contact 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 in a patient caregiver participant SHALL be IND Indirect participant ParticipationType STATIC. CONF-122 The value for ClinicalDocument / participant / associatedentity in a patient caregiver participant SHALL be CAREGIVER Caregiver EntityClass STATIC. Pagina 60/ 208

61 Esempio d uso: <participant typecode="ind"> <associatedentity classcode="caregiver"> <id root=" " extension="rssmra56l20f839c" /> <addr> <streetaddressline>via Salaria, 23</streetAddressLine> <city>roma</city> <postalcode>00168</postalcode> </addr> <telecom value="tel: "/> <associatedperson> <name> <given>mario</given> <family>rossi</family> </name> </associatedperson> </associatedentity> </participant> <participant typecode="ind"> <associatedentity classcode="nok"> <id root=" " extension="trsblm71e57a662f" /> <code code="fth" codesystem=" " codesystemname="personalrelationshiproletype" displayname="padre "/> <telecom value="tel: "/> <associatedperson> <name> <given>teresa</given> <family>bellomo</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 Pagina 61/ 208

62 Note implementative Rete di Medici di Medicina Generale Progetto Esecutivo 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: <participant typecode="ind"> <associatedentity classcode="econ"> <addr>$str_indirizzo_contatto</addr> <associatedperson> <name>$str_ref_contatto</name> </associatedperson> </associatedentity> </participant> <participant typecode="ind"> <associatedentity classcode="nok"> <addr>$str_contatto</addr> </associatedentity> </participant> Pagina 62/ 208

63 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: <documentationof> <serviceevent classcode= PCPR > <effectivetime> <low nullflavor="ni"/> <high nullflavor="ni"/> </effectivetime> </serviceevent> </documentationof> Pagina 63/ 208

64 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 Pagina 64/ 208

65 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> <structuredbody moodcode="evn" classcode="docbody"> <component> <section>... </section> </component> <component> <section>... </section> </component> <component> <section> <!--" "-->... </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. Pagina 65/ 208

66 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. Pagina 66/ 208

67 6.1 Allergie, Intolleranze ed Allarmi (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 ], a cui è associato il modello informativo seguente. Tale template è specializzato in IHE PCC attraverso il template Il modello informativo associato alla sezione degli Alerts è: Pagina 67/ 208

68 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 , ( causato prurito e rossore). Insorgenza 10/05/ 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 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 " ". Tale template è specializzato in IHE PCC attraverso il template 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. Pagina 68/ 208

69 CONF-256 CCD SHOULD contain exactly one and SHALL NOT contain more than one Alerts section (templateid ). The Alerts section SHALL contain a narrative block, and SHOULD contain clinical statements. Clinical statements SHOULD include one or more problem acts (templateid ). A problem act SHOULD include one or more alert observations (templateid ). 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 Allergies, adverse reactions, alerts 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. Pagina 69/ 208

70 In base alle condizioni sopra espresse la sezione dovrà essere così strutturata: <component> <section> <templateid root=' '/> <templateid root=' '/> <id root='$id_sez /> <code code=' ' displayname='allergie, Reazioni Avverse, Allarmi codesystem=' ' codesystemname='loinc'/> <title>allergie, Intolleranze ed Allarmi</title> <text> $NARRATIVE_BLOCK </text> <!-- molteplicità 1 N - Problem Act --> <entry> $ALERT </entry> </section> </component> L assenza di allergie o reazioni allergiche conosciute DEVE essere esplicitamente indicata. (vedi $ 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 ' e ' ') vedi Descrizione Allarme Descrizione Allarme Il dettaglio dell allarme è gestito attraverso un Problem Act che relativamente al template CCD, segue i seguenti criteri di conformità : CONF-145 with Act. A problem act (templateid ) SHALL be represented Pagina 70/ 208

71 CONF-146 The value for Act in a problem act SHALL be ACT ActClass STATIC. CONF-147 The value for Act in a problem act SHALL be EVN ActMood STATIC. CONF-148 A problem act SHALL contain at least one Act / id. CONF-149 The value for Act / code in a problem act SHALL be NA Not applicable 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 to be SUBJ ActRelationshipType STATIC. CONF-153 The target of a problem act with Act / entryrelationship 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: <act classcode='act' moodcode='evn'> <templateid root=' '/> <templateid root=' '/> <templateid root=' '/> <! template che indica restrizioni specifiche per la SSI --> <templateid root= /> <id root='$id_sez /> <code nullflavor='na'/> <statuscode code='$status_code /> <effectivetime> <low ( value= $LOW_TS nullflavor="unk" )/> <!- OPZIONALE --> <high value= $HIGH_TS /> </effectivetime> <! UNA SOLA entryrelationship --> <entryrelationship type='subj'> $ALRT_CONCERN $OINT_CONCERN $NO_ALLERGIES </entryrelationship> </act> Pagina 71/ 208

72 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 ' e ') vedi Alert Observation CONF-262 An alert observation (templateid ) SHALL be represented with Observation. CONF-263 The value for Observation in an alert observation SHALL be EVN 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 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 AlertTypeCode STATIC CONF-268 The absence of known allergies SHOULD be represented in an alert observation by valuing Observation / value with No known allergies 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 ' e ') vedi Indicazione assenza Allergie Note Pagina 72/ 208

73 CONF-268 The absence of known allergies SHOULD be represented in an alert observation by valuing Observation / value with No known allergies SNOMED CT STATIC. <observation classcode="obs" moodcode="evn" negationind="false"> <templateid root=" "/> <templateid root=" "/> <templateid root=" "/> <!-- Alert observation template --> <id root='$id_sez /> <code code="alg" codesystem=" " displayname="allergie"/> <statuscode code="completed"/> <effectivetime> <low ( value= $LOW_TS nullflavor="unk" )/> </effectivetime> <value xsi:type="cd" code=" " codesystem=" " displayname="nessuna Allergia Nota"> <originaltext> <reference value="#$ref_allarme"/> </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 Indicazione assenza Allergie Note I valori ammissibili per STATUS_CODE sono: Valore active Descrizione 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à. suspended 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

74 aborted stato risolto. Rete di Medici di Medicina Generale Progetto Esecutivo Problema da non considerarsi più attivo, senza che sia da considerarsi risolto. Per esempio il paziente abbandona la cura. completed 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 Vincoli Aggiuntivi 1 solo Problem Observation per ogni Problem Act Pagina 74/ 208

75 6.1.4 Alert Observation CONF-262 An alert observation (templateid ) SHALL be represented with Observation. CONF-263 The value for Observation in an alert observation SHALL be EVN 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 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 AlertTypeCode STATIC CONF-268 The absence of known allergies SHOULD be represented in an alert observation by valuing Observation / value with No known allergies SNOMED CT STATIC. CONF-269 An alert observation SHALL contain one or more sources of information, as defined in section 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) <observation classcode='obs' moodcode='evn' negationind='false'> <templateid root=' '/> <templateid root=' '/> <templateid root= '/> <id root='$id_sez /> <code code='issue codesystem=' ' /> <statuscode code='completed'/> Pagina 75/ 208

76 <effectivetime> <low ( value= $LOW_TS nullflavor="unk" )/> <! OPZIONALE --> <high value= $HIGH_TS /> </effectivetime> <value xsi:type="cd" nullflavor= OTH > <originaltext> <reference value="#$ref_allarme"/> </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 Indicazione assenza Allergie Note CONF-268 The absence of known allergies SHOULD be represented in an alert observation by valuing Observation / value with No known allergies SNOMED CT STATIC. <observation classcode="obs" moodcode="evn" negationind="false"> <templateid root=" "/> <templateid root=" "/> <templateid root=" "/> <!-- Alert observation template --> <id root='$id_sez /> <code code="alg" codesystem=" " displayname="allergie"/> <statuscode code="completed"/> <effectivetime> <low ( value= $LOW_TS nullflavor="unk" )/> Pagina 76/ 208

77 </effectivetime> <value xsi:type="cd" code=" " codesystem=" " displayname="nessuna Allergia Nota"> <originaltext> <reference value="#$ref_allarme"/> </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 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 ) SHALL be a conformant status observation (templateid ) (as defined in section). CONF-272 The value for Observation / value in an alert status observation SHALL be selected from ValueSet AlertStatusCode STATIC Pagina 77/ 208

78 <observation classcode='obs' moodcode='evn' negationind='false'> <templateid root=' '/> <templateid root=' '/> <templateid root=' '/> <id root='$id_sez /> <code code='$obs_code codesystem=' ' codesystemname='observationintolerancetype'/> <statuscode code='completed'/> <effectivetime> <low ( value= $LOW_TS nullflavor="unk" ) /> <! OPZIONALE --> <high value= $HIGH_TS /> </effectivetime> <value xsi:type="cd" code=" " codesystem=" " displayname="adverse reaction to substance"/> ( $CODED_AGENT $UNCODED_AGENT ) <!-- Descrizione Reazioni molteplicità > $CODED_REACTION $UNCODED_REACTION <! STATO dell Allergia molteplicità > $STATO_ALLERGIA <!-- Descrizione Commenti e Note molteplicità > $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 Pagina 78/ 208

79 $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 Descrizione Agente (Codificato. $CODED_REACTION = Descrizione reazione (codificata). Vedi Descrizione Reazioni (Codificata) $UNCODED_REACTION = Descrizione reazione (non codificata). vedi Descrizione Reazioni (Non Codificata) $STATO_ALLERGIA = Indicazione dello stato clinico del problema rilevato. Vedi Stato dell allergia $NOTE = Eventuali Note. Vedi Commenti Pagina 79/ 208

80 Valore Descrizione OINT Intolleranza Ipersensibilità che porta ad una reazione avversa a fronte di una esposizione ad un agente. (Valore più generico) ALG Allergia Ipersensibilità ad un agente causato da una risposta immunologioca ad una esposizione iniziale. DALG Allergia Farmaci Allergia ad un prodotto farmacologico EALG Altre Allergie Allergia non associabile a farmaci o cibo. E.g. Lattice, polline, etc. FALG Food Allergy Allergia ad una sostanza generalmente consumata per scopi nutritivi FNAINT DNAINT ENAINT Food Non-Allergy Intolerance Drug Non-Allergy Intolerance Environmental Non-Allergy Intolerance 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. FINT Food Intolerance Ipersensibilità che porta ad una reazione avversa associabile ad una sostanza generalmente consumata per scopi nutritivi DINT Drug Intolerance Ipersensibilità che porta ad una reazione avversa associabile ad un farmaco EINT Environmental Intolerance Ipersensibilità che porta ad una reazione avversa non associabile a farmaci o cibo. E.g. Lattice, polline, etc. Tabella 1 - Tabella valori observation.code (allarmi) Vincoli Aggiuntivi Non è presente il seguente elemento opzionale (<entryrelationship>) severità ( ) 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. Pagina 80/ 208

81 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> Descrizione Agente (Non Codificato) <participant typecode='csm'> <participantrole classcode='manu'> <playingentity classcode='mmat'> <code nullflavor="oth"> <originaltext><reference value='#$ref_agent'/></orginaltext> </code> </playingentity> </participantrole> </participant> $REF_AGENT = riferimento incrociato alla descrizione dell agente nella parte narrativa Descrizione Agente (Codificato) <participant typecode='csm'> <participantrole classcode='manu'> <playingentity classcode='mmat'> <code code='$cod_agente' codesystem='$cod_sys_agent' codesystemname="$desc_cod_sys_agent" displayname= $DESC_AGENTE > <originaltext><reference value='#$ref_agent'/></orginaltext> </code> </playingentity> </participantrole> </participant> Pagina 81/ 208

82 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 WHO ATC AIC SNOMED - CT Tabella 2 - Tabella schemi di codifica agenti (allarmi) Descrizione Reazione Descrizione Reazioni (Codificata) <entryrelationship typecode='mfst'> <observation classcode='obs' moodcode='evn' > <templateid root=" "/> <templateid root=" "/> <templateid root=" "/> <id root='$id_sez /> <code code=' ' displayname='sintomo' codesystem=' ' codesystemname='snomed CT'/> <statuscode code='completed'/> <effectivetime> <low ( value= $LOW_TS nullflavor="unk" ) /> <! OPZIONALE --> <high value= $HIGH_TS /> </effectivetime> <value xsi:type='cd' code='$cod_reaz' codesystem=' ' displayname='$desc_reaz' codesystemname='icd-9cm (diagnosis codes)'> <originaltext> Pagina 82/ 208

83 <reference value='#$ref_agent'/> </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 Vincoli aggiuntivi Non sono presenti i seguenti elementi (<entryrelationship>) opzionali : 1. severità ( ) 2. stato di salute ( ) 3. stato clinico ( ) 4. commenti (' ') Reazioni codificate usando lo schema ICD9-CM Descrizione Reazioni (Non Codificata) <entryrelationship typecode='mfst'> <observation classcode='obs' moodcode='evn' > <templateid root=" "/> <templateid root=" "/> <templateid root=" "/> <id root='$id_sez /> <code code=' ' displayname='sintomo' codesystem=' ' codesystemname='snomed CT'/> Pagina 83/ 208

84 <statuscode code='completed'/> <effectivetime> <low ( value= $LOW_TS nullflavor="unk" ) /> <! OPZIONALE --> <high value= $HIGH_TS /> </effectivetime> <value xsi:type='cd' nullflavor= OTH > <originaltext> <reference value='#$ref_agent'/> </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 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" >) <entryrelationship typecode='refr' inversionind='false'> <observation classcode='obs' moodcode='evn'> <templateid root=' '/> <templateid root=' '/> <templateid root=' '/> <templateid root=' '/> <code code=' ' displayname='status' codesystem=' ' codesystemname='loinc' /> Pagina 84/ 208

85 <text><reference value= #$REF_STATO /></text> <statuscode code='completed'/> <value xsi:type="ce" code="$cod_stato" codesystem=" " 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 Descrizine Originale Attivo Active Non più Attivo No Longer Active Tabella 3 - Tabella valori ammessi per codifica dello stato Nota: I valori selezionati, intersezione fra i valori ammessi per il template CCD ' ( Active; Prior History; No Longer Active) e quelli previsti dal template di IHE PCC ( Active ; Inactive ; Chronic ; Intermittent ; Recurrent ; Rule out ; Ruled out ; Resolved ) sono ritenuti sufficienti a descrivere lo stato di una allergia. Nel caso del PS il valore di code è fissato a (Attivo) Commenti <entryrelationship typecode='subj' inversionind='true'> Pagina 85/ 208

86 <act classcode='act' moodcode='evn'> <templateid root=' '/> <templateid root=' '/> <templateid root=" "/> <code code=' ' displayname='annotation Comment' codesystem=' ' codesystemname='loinc' /> <text><reference value='#$ref_commenti'/></text> <statuscode code='completed' /> </act> </entryrelationship> In rosso i valori da modificare in nero quelli fissi $REF_ALLARME = riferimento incrociato al testo presente nella parte narrativa Vincoli Aggiuntivi Non presente l elemento opzionale <author> Esempio <!--******************************************************** Alerts section ********************************************************--> <component> <section > <templateid root=" "/> <templateid root=" "/> <id root="36e3e920-7b14-11db-9fe c9a66"/> <code code=" " displayname="allergie, Reazioni Avverse, Allarmi" codesystem=" " codesystemname="loinc"/> <title>allergie, Reazioni Avverse ed Allarmi</title> <!--==================================================================================--> <!-- NARRATIVE BLOCK --> <!--==================================================================================--> Pagina 86/ 208

87 <text> <paragraph>elementi <content ID="stato_algs_attivo">Attivi</content> </paragraph> <table border="1" width="100%"> <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> <!-- ============================== --> <!-- Intolleranza Farmaci --> <!-- AUGMENTIN*12cpr riv 875mg. (Causato prurito e rossore). Insorgenza 10/05/ > <!-- Due reazioni codificate e data di insorgenza--> <!-- ============================== --> <entry typecode="driv"> <act classcode="act" moodcode="evn"> <templateid root=" "/> <templateid root=" "/> <templateid root=" "/> <templateid root=" "/> <id root="36e3e930-7b14-11db-9fe c9a66"/> <code nullflavor="na"/> <statuscode code="active"/> <effectivetime> <low nullflavor="unk"/> </effectivetime> <!--Note strutturate relative al farmaco--> <entryrelationship typecode="subj"> <observation classcode="obs" moodcode="evn" negationind="false"> <templateid root=" "/> <templateid root=" "/> <templateid root=" "/> <id root="4adc1020-7b14-11db-9fe c9a66"/> <code code="dint" displayname="intolleranza ai Farmaci" codesystem=" "/> Pagina 87/ 208

88 <statuscode code="completed"/> <effectivetime> <low value=" "/> </effectivetime> <value xsi:type="cd" code=" " codesystem=" " displayname="adverse reaction to substance"/> <participant typecode="csm"> <participantrole classcode="manu"> <playingentity classcode="mmat"> <code code=" " codesystem=" " codesystemname="aic" displayname=" AUGMENTIN*12cpr riv 875mgs"> <originaltext> <reference value="#sostanza_1"/> </originaltext> </code> </playingentity> </participantrole> </participant> <entryrelationship typecode="mfst" inversionind="true"> <observation classcode="obs" moodcode="evn" negationind="false"> <templateid root=" "/> <templateid root=" "/> <templateid root=" "/> <code code=" " displayname="sintomo" codesystem=" " codesystemname="snomed CT"/> <statuscode code="completed"/> <effectivetime> <low nullflavor="unk"/> </effectivetime> <value xsi:type="cd" code="698" codesystem=" " codesystemname="icd-9cm (diagnosis codes)" displayname="prurito"> <originaltext> <reference value="#react_1_1"/> </originaltext> </value> </observation> </entryrelationship> <entryrelationship typecode="mfst" inversionind="true"> <observation classcode="obs" moodcode="evn"> <templateid root=" "/> <code code=" " displayname="sintomo" codesystem=" " codesystemname="snomed CT"/> Pagina 88/ 208

89 <statuscode code="completed"/> <effectivetime> <low nullflavor="unk"/> </effectivetime> <value xsi:type="cd" code="78262" codesystem=" " codesystemname="icd-9cm (diagnosis codes)" displayname="rossore"> <originaltext> <reference value="#react_1_2"/> </originaltext> </value> </observation> </entryrelationship> </observation> </entryrelationship> </act> </entry> </component> </section > Pagina 89/ 208

90 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 Cura 2 (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. Possonon esserci problemi non strutturati come SOVP. 2 Nota: questa classe di informazione non è registrata nella sezione Problems, bensì in Plano of Care Pagina 90/ 208

91 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. III. Esempi Si limita ad un solo livello la relazione fra problemi 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) Problema --Valutazione 1 --Valutazione 2 --Piano Problema --Piano -- Problema Valutazione Valutazione 2 I problemi sono riportabili nel pattern Problems di CCD. Il modello informativo associato alla sezione dei Problemi è: Pagina 91/ 208

92 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) Pagina 92/ 208

93 6.2.1 Specifiche di sezione Rete di Medici di Medicina Generale Progetto Esecutivo 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 ). Un problem act dovrebbe dovrà includere uno o più problem observation (templateid ). CONF-140 CCD SHOULD contain exactly one and SHALL NOT contain more than one Problem section (templateid ). The Problem section SHALL contain a narrative block, and SHOULD contain clinical statements. Clinical statements SHOULD include one or more problem acts (templateid ). A problem act SHOULD include one or more problem observations (templateid ). CONF-141: The problem section SHALL contain Section / code. CONF-142: The value for Section / code SHALL be Problem list LOINC STATIC. CONF-143: The problem section SHALL contain Section / title. CONF-144: Section / title SHOULD be valued with a case-insensitive languageinsensitive text string containing problems. La sezione è individuata da un elemento <templateid root=" "/>. e da uno <templateid root=" /> In base alle condizioni sopra espresse la sezione dovrà essere così strutturata: <component> <section> <templateid root=' '/> <templateid root=' '/> <id root='$id_sez /> <code code=' ' displayname='lista dei Problemi' codesystem=' ' codesystemname='loinc'/> <title>problemi</title> <text> $NARRATIVE_BLOCK </text> <!--1..* Problem Concern Entry element --> Pagina 93/ 208

94 <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 ' e ' ') vedi Problema 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 Gestione episodicità ) Nelle figure seguenti sono rappresentate graficamente quanto sopra indicato. Pagina 94/ 208

95 Entry ACT id=1 entryrelationship principale observation Episode observation entryrelationship Starts after start collegamento esterno entryrelationship 1 N Observation problem Observation entryrelationship Problem status observation Entry ACT id=2 entryrelationship Observation problem Observation entryrelationship Problem status observation Pagina 95/ 208

96 Entry ACT id=100 entryrelationship Observation problem Observation entryrelationship Problem status observation entryrelationship Observation problem Observation entryrelationship Problem status 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 Problema Un problema è descritto attraverso un Problem Act che, relativamente al template CCD, segue i criteri di conformità definiti nella sezione Descrizione Allarme. In base alle condizioni sopra espresse l elemento dovrà essere così strutturato: Pagina 96/ 208

97 <act classcode='act' moodcode='evn'> <templateid root=' '/> <templateid root=' '/> <templateid root=' '/> <! template che indica restrizioni specifiche per la SSI --> <templateid root= /> <id root='$id_sez /> <code nullflavor='na'/> <! OPZIONALE --> <statuscode code='$status_code /> <effectivetime> <low ( value= $LOW_TS nullflavor="unk" )/> <!- OPZIONALE --> <high nullflavor= $HIGH_TS /> </effectivetime> <!-- 1..N entry relationships USATO PER INDICARE IL PROBLEMA PRINCIPALE--> <entryrelationship type='subj'> $PROBLEM_OBS </entryrelationship> <! OPZIONALE O..N entry relationships USATO PER LA GESTIONE dell episodicità --> <entryrelationship typecode="subj" inversionind="true"> $RELAZ_EPISODIO </entryrelationship> <! STATO di salute del paziente Molteplicità > $STATO_SALUTE <!-- OPZIONALE usato per gestire le relazioni SOVP / Terapie molteplicità 0 N --> <entryrelationship type='refr'> ( $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 ) Pagina 97/ 208

98 $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 ' ' e ' ' vedi Dettagli problema $STATO_SALUTE = Indicazione dello stato del paziente in relazione al problema. vedi Stato di Salute $RELAZ_EPISODIO = struttura usata per distinguere per distinguere fra più occorrenze dello stesso problema. vedi per dettagli Gestione episodicità ) $RIFERIMENTO = struttura usata per referenziare altri atti (atti, osservazioni, somministrazioni, piani di cura.). Utilizza il template ' '. Vedi Riferimenti Interni 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 ) SHALL be represented with Observation. CONF-155 The value for Observation in a problem observation SHALL be EVN 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 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 ProblemTypeCode STATIC CONF-160 The value for Observation / entryrelationship in a problem observation MAY be SUBJ Subject ActRelationshipType STATIC to reference an age observation (templateid ). 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: Pagina 98/ 208

99 <observation classcode='obs' moodcode='evn' negationind='false true '> <templateid root=' '/> <templateid root=' '/> <! template che indica restrizioni specifiche per la SSI --> <templateid root= /> <id root='$id_sez /> <code code='$obs_code' displayname='$obs_desc' codesystem=' ' codesystemname='snomed CT'/> <statuscode code='completed'/> <effectivetime> <low ( value= $LOW_TS nullflavor="unk" )/> <!- OPZIONALE --> <high nullflavor= $HIGH_TS /> </effectivetime> <value xsi:type='cd' ( code='$cod_prob' displayname='$desc_prob' codesystem=" " codesystemname="icd-9cm (diagnosis codes)" ) nullflavor= OTH > <originaltext><reference value='#$ref_problema'/></originaltext> </value> <! STATO molteplicità > $STATO_PROBLEMA <!-- Descrizione Commenti e Note molteplicità > $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. $HIGH_TS = data di risoluzione del problema. Se il problema è ancora attivo questo valore deve essere omesso. $DESC_PROB = descrizione del problema (e.g diagnosi) secondo la codifica ICD-9CM Pagina 99/ 208

100 $COD_ PROB = codice del problema (e.g diagnosi) secondo la codifica ICD-9CM $REF_PROBLEMA = riferimento incrociato al testo presente nella parte narrativa $STATO_PROBLEMA = Indicazione dello stato del problema rilevato. Vedi 0 - Non sono presenti i seguenti elementi (<entryrelationship>) opzionali : 5. severità ( ) 6. stato di salute ( ) Stato clinico $NOTE = Eventuali Note. Vedi Commenti Codice ($OBS_CODE) Disp. Name ($OBS_DESC) Elemento Corrispondente Condition Organo Mancante Symptom Oggettività Finding Oggettività Complaint Soggettività Functional limitation Problem Problema Diagnosis Valutazione Tabella 4 - Codifica Observation (<code>) Vincoli aggiuntivi Non sono presenti i seguenti elementi (<entryrelationship>) opzionali : 7. severità ( ) 8. stato di salute ( ) Stato clinico Lo stato del problema è gestito tramite un elemento di tipo observatio. Tale elemento è collegato all entità di cui descrive lo stato (allergia, problema, ) mediante una relazione generica di tipo refers to (<entryrelationship typecode="refr" >) Pagina 100/ 208

101 <entryrelationship typecode='refr' inversionind='false'> <observation classcode='obs' moodcode='evn'> <templateid root=' '/> <templateid root=' '/> <templateid root=' '/> <code code=' ' displayname='status' codesystem=' ' codesystemname='loinc' /> <text><reference value= #$REF_STATO /></text> <statuscode code='completed'/> <value xsi:type="ce" code="$cod_stato" codesystem=" " 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 Active Attivo Inactive Non Attivo Chronic Cronico Intermittent Intermittente Recurrent Ricorrente Rule out Da escludere Ruled out Escluso Resolved Risolto Tabella 5 - Tabella valori ammessi per codifica dello stato Stato di Salute Lo stato di salute del paziente associato al problema è gestito tramite un elemento di tipo observatio. Tale elemento è collegato all entità di cui descrive lo stato ( problema, ) mediante una relazione generica di tipo refers to (<entryrelationship typecode="refr" >) Pagina 101/ 208

102 <entryrelationship typecode='refr' inversionind='false'> <observation classcode='obs' moodcode='evn'> <templateid root=' '/> <templateid root=' '/> <templateid root=' '/> <code code=' ' displayname='status' codesystem=' ' codesystemname='loinc' /> <text><reference value= #$REF_STATO /></text> <statuscode code='completed'/> <value xsi:type="ce" code="$cod_stato" codesystem=" " 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 Pagina 102/ 208

103 Codice Descrizione Alive and well Sano In remission In via di guarigione Symptom Senza Sintomi free Chronically Malato Cronico ill Severely ill Severamente Malato Disabled Disabile Severely disabled Severamente disabile Deceased Deceduto Tabella 6 - Tabella valori ammessi per codifica dello stato di salute Gestione episodicità La gestiuone dell episodicità, cioè la capacità di distinguere il singolo episodio tra una molteplicità di occorrenze riferite allo stesso problema, può essere gestita attraverso il template Tale template segue le seguenti specifiche CONF-168 A problem act MAY contain exactly one episode observation. CONF-169 An episode observation (templateid ) SHALL be represented with Observation. CONF-170 The value for Observation in an episode observation SHALL be OBS ActClass STATIC. CONF-171 The value for Observation in an episode observation SHALL be EVN ActMood STATIC. CONF-172 An episode observation SHALL include exactly one Observation / statuscode. CONF-173 The value for Observation / statuscode in an episode observation SHALL be completed ActStatus STATIC. CONF-174 The value for Observation / Code in an episode observation SHOULD be ASSERTION ActCode STATIC. Pagina 103/ 208

104 CONF-175 Observation / value in an episode observation SHOULD be the following SNOMED CT expression: <value xsi:type="cd" code=" " codesystem=" " displayname="clinical finding"> <qualifier> <name code=" " displayname="episodicity"/> <value code=" " displayname="new episode"/> </qualifier> </value> CONF-176 An episode observation SHALL be the source of exactly one entryrelationship whose value for entryrelationship is SUBJ Has subject ActRelationshipType STATIC. This is used to link the episode observation to the target problem act or social history observation. CONF-177 An episode observation MAY be the source of one or more entryrelationship whose value for entryrelationship is SAS Starts after start ActRelationshipType STATIC. The target of the entryrelationship SHALL be a problem act or social history observation. This is used to represent the temporal sequence of episodes. L attributo inversionind può essere usato per invertire sorgente->target nella relazione entryrelationship Riferimenti Interni Il CDA permette l uso di riferimenti ad altre informazioni presenti in altri componenti/entry dello stesso documento. Per gestire tali riferimenti IHE PCC definisce il template così strutturato. <entryrelationship typecode='$tipo_rel' inversionind='true false'> <act classcode='act' moodcode='$act_mood'> <templateid root=' '/> <id root='$id_ref /> <!- Obbligatorio coincide col codice presente nell elemento referenziato; se non esite valorizzato a NA --> <code ( code='$cod_act' codesystem='$cod_sys_act' codesystemname="$desc_cod_sys_act" displayname= $DESC_ACT nullflavor= NA )> </act> </entryrelationship> Pagina 104/ 208

105 In rosso i valori da modificare in nero quelli fissi $ID_REF = ID Unico della sezione/elemento da referenziare (data type HL7 II ) $TIPO_REL = indica il tipo di relazione, definito a livello di singola entry. Codice derivato dalla tabella ActRelationshipType $ACT_MOOD = Indica se l atto è concepito come un fatto, una intenzione, una richiesta una aspettativa, ect ect. Derivato dal vocabolario di HL7 ActMood. $COD_ACT = codice dell atto referenziato $DESC_ACT = descrizione dell atto referenziato $DESC_COD_SYS_ACT = descrizione del sistema di codifica utilizzato $COD_SYS_ACT = OID dello schema di codifica utilizzato Organi Mancanti Il dato può essere presente con indicazioni da parte della Fonte Dati che inserisce l informazione. Un organo mancante viene rappresentato come un problem act (si veda Dettagli problema) Esempio <component> <section> <templateid root=' '/> <templateid root=' '/> <id root=' /> <code code=' ' displayname='lista dei Problemi' codesystem=' ' codesystemname='loinc'/> <title>problemi</title> <text> descrizione testuale con riferimenti <content ID="diagn_1_1"> bronchite</content>. </text> <!-- primo Problem act template descritto nella sezione Problem del SSI --> <act classcode='act' moodcode='evn'> <templateid root=' '/> <templateid root=' '/> Pagina 105/ 208

106 <templateid root=' '/> <! template che indica restrizioni specifiche per la SSI --> <templateid root= /> <!-- Problem act template --> <id root="ec8a6ff8-ed4b-4f7e-82c3-e98e58b45de7"/> <code nullflavor="na"/> <effectivetime> <low value=" "/> </effectivetime> <!--Codice ICD IX CM diagnosi--> <entryrelationship typecode="subj"> <observation classcode="obs" moodcode="evn"> <!-- Problem observation template --> <templateid root=" "/> <templateid root=' '/> <! template che indica restrizioni specifiche per la SSI --> <templateid root= /> <!--id univoco della diagnosi--> <id root="ab1791b0-5c71-11db-b0de c9a66"/> <code code=" " displayname= Diagnosi codesystem=" "/> <statuscode code="completed"/> <effectivetime> <low value=" "/> </effectivetime> <!--codicd9--> <value xsi:type="ce" code="930.5" codesystemname="icd9cm" codesystem=" " displayname="bronchite"/> <originaltext> <reference value="#diagn_1_1"/> </originaltext> <!--Stato della diagnosi--> <entryrelationship typecode="refr"> <observation classcode="obs" moodcode="evn"> <templateid root=" "/> <!-- Problem status observation template --> <code code=" " codesystem=" " displayname="status"/> <!--soluzioneproblema--> <statuscode code="completed"/> <value xsi:type="ce" code=" " Pagina 106/ 208

107 codesystem=" " displayname=" Risolto"/> </observation> </entryrelationship> </observation> </entryrelationship> </act> </entry> Nuovo Episodio: <!-- registrazione di un episodio collegato --> <entry typecode="driv"> <act classcode="act" moodcode="evn"> <templateid root=" "/> <!-- Problem act template --> <id root="d11275e9-67ae-11db-bd c9a66"/> <code nullflavor="na"/> <effectivetime> <low value=" "/> </effectivetime> <entryrelationship typecode="subj"> <observation classcode="obs" moodcode="evn"> <!-- Problem observation template --> <templateid root=" "/> <templateid root=' '/> <! template che indica restrizioni specifiche per la SSI --> <templateid root= /> <!--id univoco della diagnosi--> <id root="ab1791b0-6c72-11db-b0de c9a66"/> <code code=" " displayname= Diagnosi codesystem=" "/> <statuscode code="completed"/> <effectivetime> <low value=" "/> </effectivetime> <!--codicd9--> <value xsi:type="ce" code="930.5" codesystemname="icd9cm" codesystem=" " displayname="bronchite"/> Pagina 107/ 208

108 <!--esempio di act nexted si parte da qui--> <entryrelationship typecode="subj" > <observation classcode="obs" moodcode="evn"> <templateid root=" "/> <!-- Episode observation template --> <code code="assertion" codesystem=" "/> <statuscode code="completed"/> <effectivetime> <low value=" "/> </effectivetime> <value xsi:type="cd" code=" " codesystem=" " displayname="clinical finding"> <qualifier> <name code=" " displayname="episodicity"/> <value code=" " displayname="new episode"/> </qualifier> </value> <entryrelationship typecode="sas"> <act classcode="act" moodcode="evn"> <id root="ec8a6ff8-ed4b-4f7e-82c3-e98e58b45de7"/> <code/> </act> </entryrelationship> </observation> </entryrelationship> </act> </entry> </section> </component> Pagina 108/ 208

109 6.3 Piani di Cura Tutte le informazioni relative a piani di cura riabilitativi o terapeutici (incluso anche gli elementi P (Piano) delle schede SOVP) devono essere descritte all interno della sezione Plan of Care. Questa sezione può contenere anche informazioni concernenti memo clinici od esiti attesi (goal) Specifiche Sezione La struttura della sezione Plan of Care è definita all interno del CCD attraverso il template , i cui vincoli di sezione sono qui di seguito specificati: CCD SHOULD contain exactly one and SHALL NOT contain more than one Plan of Care section (templateid ). The Plan of Care section SHALL contain a narrative block, and SHOULD contain clinical statements. Clinical statements SHALL include one or more plan of care activities (templateid ). CONF-481: The plan of care section SHALL contain Section / code. CONF-482: The value for Section / code SHALL be Treatment plan LOINC STATIC. CONF-483: The plan of care section SHALL contain Section / title. CONF-484: Section / title SHOULD be valued with a case-insensitive languageinsensitive text string containing plan. Per la gestione dei piani di cura IHE-PCC prevede l adozione del template Care Plan Section ( The care plan section shall contain a narrative description of the expectations for care including proposals, goals, and order requests for monitoring, tracking, or improving the condition of the patient. ) (tale template è coerente con il template ) <component> <section> <templateid root=" "/> <templateid root=' '/> <id root='$id_sez /> <code code=' ' displayname='treatment PLAN' Pagina 109/ 208

110 codesystem=' ' codesystemname='loinc'/> <title>piano di Cura</text> <text> $NARRATIVE_BLOCK </text> <! OPZIONALE molteplicità 0..N --> <entry> $PLAN_ACTIVITY </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 $PLAN_ACTIVITY = Dettaglio delle attività previste dal Piano. Vedi Dettaglio Attività Piano di Cura Dettaglio Attività Piano di Cura Le singole attività previste dal piano devono essere descritte facendo riferimento al template , i cui vincoli sono indicati qui di seguito CONF-485: A plan of care activity (templateid ) SHALL be represented with Act, Encounter, Observation, Procedure, SubstanceAdministration, or Supply. CONF-486: A plan of care activity SHALL contain at least one [Act Encounter Observation Procedure SubstanceAdministration Supply] / id. CONF-487: A plan of care activity SHALL contain exactly one [Act Encounter Observation Procedure SubstanceAdministration Supply] CONF-488: The value for [Act Encounter Procedure] in a plan of care activity SHALL be [ INT (intent) ARQ (appointment request) PRMS (promise) PRP (proposal) RQO (request)] ActMood STATIC. CONF-489: The value for [SubstanceAdministration Supply] in a plan of care activity SHALL be [ INT (intent) PRMS (promise) PRP (proposal) RQO (request)] ActMood STATIC. Pagina 110/ 208

111 CONF-490: The value for Observation in a plan of care activity SHALL be [ INT (intent) PRMS (promise) PRP (proposal) RQO (request) GOL (goal)] ActMood STATIC. INT (intent) ARQ (appt request) PRMS (promise) PRP (proposal ) RQO (request) GOL (goal) Act Encounte Procedur Substanc Supply Observati r e e Admin on Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Not Allowed Not Allowed Not Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Allowed In base alle considerazioni fatte il set di informazioni attese sarà: <act classcode="" moodcode=""> <templateid root=" "/> <templateid root= /> <!-- Plan of Activity activity template --> <id root='$id_sez /> <code code='$cod_act' codesystem='$cod_sys_act' codesystemname="$desc_cod_sys_act" displayname= $DESC_ACT > <statuscode code="$status_code"/> <originaltext><reference value='#$ref_act'/></orginaltext> </code> <! OPZIONALE può essere espresso sia nella forma di data precisa effectivetime@value --> <! che di intervallo (aperto o chiuso) effectivetime.low, effectivetime.high --> <! ALMENO UNO dei DUE coponenti deve essere presente --> ( <effectivetime value= $TS_PLAN /> OR <effectivetime > <low value="$low_ts"/> Pagina 111/ 208

112 <high value="$high_ts"/> </effectivetime > </act> L esempio sopra è stato fatto riferendosi ad un generico act, nel caso di altri artefatti (e.g. substanceadministration, procedure, ) l esempio dovrà essere declinato in base agli elementi obbligatori richiesti dall artefatto scelto. Per esempio per il substanceadministration, <consumable><manufacturedproduct><manufacturedlabeleddrug> </manufacturedlabeleddrug></manufacturedproduct>consumable> In rosso i valori da modificare in nero quelli fissi $ID_SEZ = ID Unico della sezione (data type HL7 II ) $STATUS_CODE = Codice stato derivato da ActStatus [ ]. Restrizioni alla tabella referenziata potranno essere applicate in base al tipo di artefatto usato. $COD_ ACT = codice relativo all attività del piano di cura nel sistema di codifica individuato $DESC_ACT = descrizione codice relativo all attività del piano di cura nel sistema di codifica individuato $DESC_COD_SYS_ ACT = descrizione del sistema di codifica utilizzato $COD_SYS_ ACT = OID dello schema di codifica utilizzato per indicare gli agenti. Valori ammessi $REF_ ACT = riferimento incrociato alla descrizione dell attività nella parte narrativa $TS_PLAN = data (prevista) dell attività del piano $LOW_TS = data di inzio (prevista) dell attività del piano $HIGH_TS = data di fine (prevista) dell attività del piano Esempi Prescrizione Prestazione Riabilitativa La prescrizione di riabilitazione si modella come un ACT oppure con Procedure e visto che è una prescrizione con moodcode RQO : <act classcode="act" moodcode="rqo"> Pagina 112/ 208

113 Il codice di prestazione viene descritto con un code: <code xsi:type="ce" code="466.0" codesystemname="codprestazione" codesystem=" " displayname="riabilitazione all'anca"> </code> Il codice ICD9 del problema associato con la sua descrizione, viene descritto in un campo entryrelationship con typecode "RSON": <entryrelationship typecode="rson"> Che contiene un observation con un campo value contenente il code ICD9CM del problema associato con la sua descrizione: <value xsi:type="ce" code="717.85" codesystemname="icd9cm" codesystem=" " displayname="old disruption of other ligaments of knee"/> Le note sono descritte in un campo testo: <text> Note della prescrizione Riabilitativa descrizione problema associato </text> La data della prescrizione viene inserita all'interno di un campo effectivetime: <effectivetime xsi:type="ivl_ts"> <low value=" "/> </effectivetime> Richiesta osservazione Pagina 113/ 208

114 <observation classcode="obs" moodcode="rqo"> <templateid root=" "/> <!-- Plan of Activity activity template --> <id root="9a6d1bac-17d a4-1121bc809b4a"/> <code code=" " codesystem=" " displayname="pulmonary function test"/> <statuscode code="new"/> <effectivetime> <low value=" "/> </effectivetime> </observation> Pagina 114/ 208

115 6.4 Farmaci (Medications) Tutte le informazioni relative a prescrizioni e somministrazione di farmaci devono essere descritte all interno della sezione Medications. Al contario del documento relativo al Patient Summary, in cui si suppone che la sezione includa solo le informazioni relative alle terapie in corso; nel caso della SSI la sezione dovrebbe includere la storia delle prescrizioni fatte. Nota: informazioni relative a somministrazioni di vaccini devono essere riportate nella sezione Immunization. Esempi di asserzioni sono : Terapie Continuative: 1. Nitrodur Mg 10*15cer 10mg/24h (dalle 8 alle 22) 2. Moduretic*20cpr 5/50mg (1 la settimana) 3. Tenormin*14cpr 100mg (una la mattina) 4. Dilzene*50cpr 60mg R.M. (una ogni otto ore) Il modello informativo associato alla sezione medications è: Pagina 115/ 208

116 6.4.1 Specifiche di Sezione Tutte le informazioni relative a prescrizioni e somministrazione di farmaci devono essere descritte all interno della sezione Medications. Il template che identifica tale sezione è il Qui di seguito un estratto dei vincoli imposti a questo template: CONF-298 CCD SHOULD contain exactly one and SHALL NOT contain more than one Medications section (templateid ). The Medications section SHALL contain a narrative block, and SHOULD contain clinical statements. Clinical statements SHOULD include one or more medication activities (templateid ) and/or supply activities (templateid ). CONF-298 CONF-300: The absence of known medications SHALL be explicitly asserted. The medications section SHALL contain Section / code. Pagina 116/ 208

117 CONF-301: The value for Section / code SHALL be History of medication use LOINC STATIC. CONF-302: The medications section SHALL contain Section / title. Il template sopra referenziato prevede la distinzione fra le informazioni relative alla distribuzione dei farmaci ( Supply ) e la loro somministrazione ( Substance Adminstration ). Sebbene la prescrizione farmacologia assuma spesso la doppia valenza di richiesta di fornitura di farmaci da parte delle farmacie e di indicazione circa l assuzione del farmaco da parte del paziente, nel contesto del SSI si ritiene idoneo privilegiare il secondo aspetto. Il riferimento da prendere per la registrazione delle terapie farmacologiche è quindi il template Medication Activities. Il template previsto dal CCD è specializzato da IHE PCC attraverso il template Medications Section ( The medications section shall contain a description of the relevant medications for the patient, e.g. an ambulatory prescription list. It shall include entries for medications as described in the Entry Content Module. ). In base alle condizioni sopra espresse la sezione dovrà essere così strutturata: <component> <section> <templateid root=' '/> <templateid root=' '/> <id root='$id_sez /> <code code=' ' displayname='history OF MEDICATION USE' codesystem=' ' codesystemname='loinc'/> <title>terapie</title> <text> $NARRATIVE_BLOCK </text> <!-- molteplicità 1 N Descrizione Terapia Farmacologica --> <entry> $MEDICATION </entry> </section> </component> Pagina 117/ 208

118 L assenza di terapie conosciute DEVE essere esplicitamente indicata all interno del Narrative Block. 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 $MEDICATION = Dettaglio Terapia Farmacologica (vedi Descrizione Terapia) Descrizione Terapia Le informazioni relative all attività di prescrizione somministrazione dei farmaci deve essere rappresentata attraverso il template Medication Activities, i cui vincoli sono: CONF-304: A medication activity (templateid ) SHALL be represented with SubstanceAdministration. CONF-305: The value for SubstanceAdministration in a medication activity SHALL be EVN or INT ActMood STATIC. CONF-306: A medication activity SHALL contain at least one SubstanceAdministration / id. CONF-307: A medication activity SHOULD contain exactly one SubstanceAdministration / statuscode. CONF-308: A medication activity SHOULD contain one or more SubstanceAdministration / effectivetime elements, used to indicate the actual or intended start and stop date of a medication, and the frequency of administration.. CONF-309: A medication activity SHOULD contain exactly one SubstanceAdministration / routecode. CONF-310: The value for SubstanceAdministration / routecode in a medication activity SHOULD be selected from the HL7 RouteOfAdministration ( ) code system. CONF-311: A medication activity SHOULD contain exactly one SubstanceAdministration / dosequantity or SubstanceAdministration / ratequantity. CONF-312: A medication activity MAY contain exactly one SubstanceAdministration / maxdosequantity, which represents a maximum dose limit. CONF-313: A medication activity MAY contain one or more SubstanceAdministration / performer, to indicate the person administering a substance. CONF-314: A medication activity MAY have one or more associated consents, represented in the CCD Header as ClinicalDocument / authorization / consent. Pagina 118/ 208

119 CONF-361: If manufacturedmaterial / code contains a precoordinated unit dose (e.g. metoprolol 25mg tablet ), then SubstanceAdministration / dosequantity SHALL be a unitless number that indicates the number of products given per administration. CONF-362: If manufacturedmaterial / code does not contain a precoordinated unit dose (e.g. metoprolol product ), then SubstanceAdministration / dosequantity SHALL be a physical quantity that indicates the amount of product given per administration. Tale template è specializzato da IHE-PCC attraverso la famiglia di template Medications ( This content module describes the general structure for a medication. All medication administration acts will be derived from this content module ), così ulteriormente specializzabile: Dosaggio Normale ( Normal Dosing ) : usato per indicare terapie che non richiedono una gestione particolare delle sostanze o dei dosaggi: non hanno <substanceadministation> acts subordinati. Dosaggio progressivo ( Tapered Doses ) : usato quando c è una variazione progressiva nel tempo delle dosi di uno specifico farmaco. Dosaggi spezzati ( Split Dosing ) : usato per gestire dosaggi diversi nel tempo esempio dosaggi a giorni alternati. Dosaggio Condizionale ( Conditional Dosing ) : usato per gestire dosaggi condizionali esempio dipendenti dal valore di uno specifico parametro vitale (e.g livello glicemia) Combination Medications : usato per la gestione di combinazioni di farmaci (e.g cocktail, ) Si faccia riferimento al Technical Framework di IHE-PCC per ulteriori dettagli. Nel contesto della SSI si considerano al momento solo la definizione di dosaggi normali (template ' ') <substanceadministration classcode='sbadm' moodcode='int EVN'> <templateid root=' '/> <templateid root=' '/> <templateid root=' '/> <templateid root= /> <id root='$id_sez /> <text><reference value='#$ref_med'/></text> Pagina 119/ 208

120 <statuscode code='completed'/> <! Obbligatorio indica il periodo di inizio e fine della terapia --> <!-- Se non noto deve essere valorizzato a UNK --> <effectivetime xsi:type='ivl_ts'> <low ( value= $LOW_TS nullflavor="unk" )/> <!- OPZIONALE --> <high value= $HIGH_TS nullflavor="pinf" /> </effectivetime> <! OPZIONALE usato per indicare la posologia: e.g. 2 volte il giorno,.--> <effectivetime operator='a' xsi:type='ts PIVL_TS EIVL_TS PIVL_PPD_TS SXPR_TS'> $POSOLOGIA </effectivetime> <! OPZIONALE --> <routecode $COD_VIA_SOMM > <! OPZIONALE --> <dosequantity>$dose</dosequantity> <! OPZIONALE --> <approachsitecode $COD_APP_COD></approachSiteCode> <! OPZIONALE --> <ratequantity>$rate</ratequantity> <consumable> $FARMACO </consumable> <! OPZIONALE USATO PER INDICARE LA RAGIONE della somministrazione --> $RAGIONE </substanceadministation> In rosso i valori da modificare in nero quelli fissi $ID_SEZ = ID Unico della sezione (data type HL7 II ) $REF_MED = riferimento incrociato alla descrizione della terapia nella parte narrativa $FARMACO = Descrizone del farmaco somministrato/prescritto $LOW_TS = data di inzio terapia. Se non noto valorizzare l elemento col nullflavor = UNK. $HIGH_TS = data di fine terapia del problema. Non presente se stato diverso da aborted o completed. $POSOLOGIA = Informazioni concernenti la posologia. La strutturazione di questo elemento dipende dal tipo di dato usato. (vedi anche Posologia) $COD_VIA_SOMM = codifica via di somministrazione. Da vocabolario HL7 RouteOfAdministration $DOSE = Fornisce indicazioni circa il dosaggio. Deve essere strutturato nella forma <low value=' ' unit=' '/><high value=' ' unit=' '/>. Se non si tratta di un range si usano due valori low Pagina 120/ 208

121 ed high coincidenti. Se la dose si riferisce a unità intere (e.g capsule, tavolette, ) l attributo units non deve essere usato. $RATE = frequenza di erogazione. Deve essere strutturato nella forma <low value=' ' unit=' '/><high value=' ' unit=' '/>. Se non si tratta di un range si usano due valori low ed high coincidenti. $COD_APP_COD = Codice che descrive il sito di somministrazione $REF_APP_SITE = Riferimento alla parte narrativa dove è descritto il sito di somminstrazione $RAGIONE = Ragione della somministrazione. Utilizza il template ' '. Vedi Ragione. NOTA: gli elementi <routecode>, <dosequantity>, <approachsitecode> e <ratequantity> DOVREBBERO includere un riferimento diretto alla parte narrativa attraverso un elemento di tipo < originaltext><reference> La somministrazione di un farmaco sarà indicata attraverso l elemento : <substanceadministration classcode="sbadm" moodcode="evn"> mentre la prescrizione, cioé l indicazione da parte del medico curante affinché il paziente prenda quel farmaco, si indica utilizzando l elemento <substanceadministration classcode="sbadm" moodcode="int"> Si faccia riferimento alla documentazione del CDA-R2 per maggiori dettagli riguardo la struttura dell elemento < substanceadministration> Per quanto riguarda la caratterizzazione di farmaco continuativo dobbiamo distinguere con il non continuativo mettendo nell' effective time la data di fine. (high); nel primo caso si espliciterà la condizione tramitre l attributo nullflavor settato a PINF. Nota: questa soluzione non è in linea con l indicazione di IHE-PCC che suppone di avere sempre nel campo high un valore non infinito: anche in caso di terapie continuative l elemento high dovrebbe indicare la data in cui la terapia si dovrebbe concludere in base a quanto prescritto. Non Continuativo: esiste una data di inizio ed una data di fine (high). <effectivetime xsi:type="ivl_ts"> Pagina 121/ 208

122 <low value=" "/> <high value=" "/> </effectivetime> Continuativo: esiste una data di inizio (low) e non una data di fine. <effectivetime xsi:type="ivl_ts"> <low value=" "/> < high nullflavor="pinf"/> </effectivetime> Le Note possono essere inserite nella sezione narrative block relativo alla sezione. Mentre la diagnosi e la Nota AIFA ex CUF associata alla substance administration può gestita attraverso una entryrelationship di tipo RSON : Posologia L elemento <effectivetime> può inoltre essere utilizzato anche per indicare la frequenza di assunzione di un farmaco (e.g due volte al giorno, prima dei pasti, etc etc). Le informazioni circa la posologia sono poi completate con l indicazione della dose (e.g 1 fiala; 30 mg; ) tramite l elemento <dosequantity>. L elemento <dosequantity> all interno del <substanceadministration> può essere usato per indicare la dose del farmaco che deve essere somministrata. Tale elemento NON deve essere usato per indicare la quantità delle confezioni da fornire al paziente (tale informazione può essere passata attraverso l elemento <supply>). Se indicate le unità di misura sono derivate dal vocabolario HL7 UnitsOfMeasureCaseSensitive Nella tabella seguente alcuni esempi di uso in base alla frequenza Freq Descrizione b.i.d. Twice a day q12h Every 12 hours XML Representation <effectivetime xsi:type='pivl_ts' institutionspecified='true' operator='a'> <period value='12' unit='h' /></effectivetime> <effectivetime xsi:type='pivl_ts' institutionspecified='false' operator='a'> <period value='12' unit='h' /></effectivetime> Pagina 122/ 208

123 Once t.i.d. q8h Once, on at 1:18am. Three times a day, at times determined by the person administering the medication. Every 8 hours qam In the morning Every day at 8 in the morning for 10 minutes q4-6h Every 4 to 6 hours. <effectivetime xsi:type='ts' value=' '/> <effectivetime xsi:type='pivl_ts' institutionspecified='true' operator='a'> <period value='8' unit='h' /></effectivetime> <effectivetime xsi:type='pivl_ts' institutionspecified='false' operator='a'> <period value='8' unit='h' /></effectivetime> <effectivetime xsi:type='eivl' operator='a'> <event code='acm'/></effectivetime> <effectivetime xsi:type='pivl_ts' operator='a'> <phase> <low value=" " inclusive="true"/> <width value="10" unit="min"/> </phase> <period value='1' unit='d'/></effectivetime> <effectivetime xsi:type='pivl_ppd_ts' institutionspecified='false' operator='a'> <period value='5' unit='h' /> <standarddeviation value='1' unit='h'></effectivetime> Dettagli Farmaco Nel template CCD il farmaco è rappresentato attraverso il template , i cui vincoli sono : CONF-357: A ManufacturedProduct in a product template SHALL contain exactly one manufacturedproduct / manufacturedmaterial. CONF-358: A manufacturedmaterial in a product template SHALL contain exactly one manufacturedmaterial / code. CONF-361: If manufacturedmaterial / code contains a precoordinated unit dose (e.g. metoprolol 25mg tablet ), then SubstanceAdministration / dosequantity SHALL be a unitless number that indicates the number of products given per administration. CONF-362: If manufacturedmaterial / code does not contain a precoordinated unit dose (e.g. metoprolol product ), then SubstanceAdministration / dosequantity SHALL be a physical quantity that indicates the amount of product given per administration. CONF-363: A manufacturedmaterial in a product template SHALL contain exactly one Material / code / originaltext, which represents the generic name of the product. CONF-364: A manufacturedmaterial in a product template MAY contain exactly one Material / name, which represents the brand name of the product. Pagina 123/ 208

124 CONF-366: A ManufacturedProduct in a product template MAY contain one or more manufacturedproduct / id, which uniquely represent a particular kind of product. CONF-367: If ManufacturedProduct in a product template contains manufacturedproduct / id, then ManufacturedProduct SHOULD also contain manufacturedproduct / manufacturerorganization. Questo template è specializzato da IHE-PCC attraverso il template Product Entry ( The product entry describes a medication or immunization used in a <substanceadministration> act ) In base alle condizioni sopra espresse la sezione dovrà essere così strutturata: <manufacturedproduct> <templateid root=' '/> <templateid root=' '/> <manufacturedmaterial> <code code="$cod_aic" codesystem=" " codesystemname="aic" displayname="$desc_aic"> <originaltext><reference value='#$ref_farm'/></originaltext> <! OPZIONALE --> <translation code="$cod_atc" codesystem=" " codesystemname="atc" displayname="$desc_atc"/> </code> </manufacturedmaterial> </manufacturedproduct> In rosso i valori da modificare in nero quelli fissi $REF_FARM = riferimento incrociato alla descrizione del prodotto all interno della parte narrativa $COD_AIC ($DESC_AIC) = codice AIC (descrizione) del farmaco somministrato/prescritto $COD_ ATC ($DESC_ ATC) = codice ATC (descrizione) associato al farmaco somministrato/prescritto Pagina 124/ 208

125 6.4.5 Ragione Rete di Medici di Medicina Generale Progetto Esecutivo Il CDA permette l uso di riferimenti ad altre informazioni presenti in altri componenti/entry dello stesso documento. Per gestire tali riferimenti IHE PCC definisce il template così strutturato. (vedi Riferimenti Interni) In questo contesto il tipo di relazione deve essere valorizzato a RSON e l act MOOD a EVN <entryrelationship typecode='rson > <act classcode='act' moodcode='evn > Esempio <component> <section> <! OMISSIS --> <!-- La struttura utiizzata per la parte narrative block è del tutto esemplificativa altre forme di presentazione (e.g table) potranno essere adottate --> <text> <list> <item> <content ID="presc1_therapy_2">Prednisone 20mg qd</content> <list> <caption>dettagli Somminstrazioni:</caption> <item>via di Somministrazione: Bocca</item> <item> altre note </item> <item> altre note </item> </list> </item> </list> </text> <!--================================= --> <entry> <! > <!-- DETTAGLIO PRIMA PRESCRIZIONE--> > Pagina 125/ 208

126 <substanceadministration classcode="sbadm" moodcode="int"> <id root="id-1a-prescrizione"/> <text>prednisone 20mg qd</text> <effectivetime xsi:type='ivl_ts'> <low nullflavor="unk" /> </effectivetime> <effectivetime operator='a' xsi:type="pivl_ts" institutionspecified="true"> <period value="24" unit="h"/> </effectivetime> <routecode code="po" codesystem=" " codesystemname="routeofadministration" displayname="via Orale"/> <dosequantity value="20" unit="mg"/> <consumable> <manufacturedproduct> <manufacturedlabeleddrug> <code code=" " codesystemname="aic" displayname="deltacortene 10 cpr 25" codesystem=" > <translation code="h02ab07" codesystemname="atc" displayname="prednisone" codesystem= /> </code> </manufacturedlabeleddrug> </manufacturedproduct> </consumable> <!-- ESEMPIO DI REFERENZIAZIONE DI TERAPIA --> <entryrelationship typecode= RSON > <act classcode='act' moodcode='$act_mood'> <templateid root=' '/> <!-- codifica procedura --> <id root="id-terapia-1"/> <code nullflavor= NA /> </act> </entryrelationship> <! OMISSIS --> </component> </section> Pagina 126/ 208

127 6.5 Vaccinazioni (Immunization) Definisce lo stato attuale di immunizzazione (vaccinazioni) del paziente e le vaccinazioni effettuate dal MMG/PLS a cui il paziente si è sottoposto in passato. Esempio di uso: 10/05/2007 Febbre Gialla (Viaggio in Indonesia). Lotto: 356/B/ /02/2005 Tetano 2 (IMOVAXTETANO*1SIR 0,5 ml) (AIC ) 13/06/2007 DIFTERITE/TETANO Le informazioni gestite per indicare i dettagli della vaccinazione saranno: 1. Nome Vaccino (Obbligatorio) 2. Numero Richiamo (se indicato) 3. Periodo di copertura 4. Data Somministrazione (Obbligatorio) 5. Farmaco Utilizzato (codice AIC) 6. Lotto Vaccino 7. Eventuale Reazione 8. Note Per rappresentare le vaccinazioni si fa riferimento al template Immunization ( ). Al momento tale sezione viene utilizzata per riportare le vaccinazioni, non le immunizzazione naturali. Quest ultime potranno essere derivate eventualmente dalle patologie (o storia delle malattie) remote (seizone problems ). La base di rappresentazione delle vaccinazioni è la stessa usata per le prescrizioni farmacologiche (Medication), espresso dal seguente modello informativo: Pagina 127/ 208

128 6.5.1 Specifiche di Sezione Viene utilizzato per la rappresentazione delle vaccinazioni il template Immunization: , i cui vincoli sono qui di seguito elencati: CONF-376: CCD SHOULD contain exactly one and SHALL NOT contain more than one Immunizations section (templateid ). The Immunizations section SHALL contain a narrative block, and SHOULD contain clinical statements. Clinical statements SHOULD include one or more medication activities (templateid ) and/or supply activities (templateid ). CONF-377: The immunizations section SHALL contain Section / code. Pagina 128/ 208

129 CONF-378: The value for Section / code SHALL be History of immunizations LOINC STATIC. CONF-379: The immunizations section SHALL contain Section / title. Tale templateè quindi ulteriormente definito dal template immunizations di IHE PCC (' ') Per veicolare le informazioni relative alle vaccinazioni si usa preferenzialmente l elemento <substanceadministration> facendo riferimento all effettiva somministrazione del farmaco: <substanceadministration classcode="sbadm" moodcode="evn"> <component> <section> <templateid root=' '/> <templateid root=' '/> <id root='$id_sez /> <code code=' ' displayname='history OF IMMUNIZATIONS' codesystem=' ' codesystemname='loinc'/> <title>vaccinazioni</title> <text> $NARRATIVE_BLOCK </text> <!- molteplicità 1 N - Immunization element --> <entry> $IMM_ITEM </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 $IMM_ITEM = Vaccinazione (specializzazione dei ' ' e ' ') vedi Vaccinazione Pagina 129/ 208

130 6.5.2 Vaccinazione Rete di Medici di Medicina Generale Progetto Esecutivo La base di rappresentazione delle vaccinazioni è la stessa usata per le prescrizioni farmacologiche (Medication) si veda tale sezione per i vincoli imposto dal CCD per la gestione dell elemento substanceadministration. In base a tali vincoli la struttura usata per veicolare le informazioni relative alla vaccinazione è la seguente: <substanceadministration classcode="sbadm moodcode='evn' negationind='true false'> <templateid root=' '/> <templateid root=' '/> <templateid root=' '/> <id root='$id_sez /> <code code='immuniz' codesystem=' ' codesystemname='actcode'/> <text><reference value='#$ref_desc_vacc /></text> <statuscode code='completed'/> <effectivetime value='$data_vacc'/> <consumable typecode='csm'> <manufacturedproduct classcode='manu'> <manufacturedlabeleddrug classcode='mmat' determinercode='kind'> <! MANCA AL MOMENTO UNA CODIFICA CONDIVISA DEI VACCINI (DA DEFINIRE)--> ( <code code='$cod_vacc' codesystem= ' codesystemname='$cod_sc_vacc' displayname= $DESC_VACC > OR <! IN ASSENZA DI CODIFICA DEFINITA USARE la seguente soluzione --> <code nullflavor= OTH > ) <originaltext><reference value='#$ref_desc_vaccino'/></originaltext> <! OPZIONALE: se è noto il codice AIC del farmaco viene passato così --> <translation code='$cod_farm' codesystem= codesystemname='aic' displayname= $DESC_FARM > <originaltext><reference value='#$ref_farmaco'/></originaltext> </translation> ) </code> </manufacturedlabeleddrug> </manufacturedproduct> </consumable> <! Elemento Opzionale per indicare il numero di dose --> Pagina 130/ 208

131 <entryrelationship typecode='subj'> <observation classcode="obs" moodcode="evn"> <templateid root=' '/> <code code=' ' displayname='dose Number' codesystem=' ' codesystemname='loinc'/> <statuscode code='completed'/> <value xsi:type='int' value='$num_richiamo'/> </observation> </entryrelationship> <! OPZIONALE PERIODO DI COPERTURA --> <entryrelationship typecode="refr"> <observation classcode="obs" moodcode="evn"> <!-- Periodo Copertura --> <code code=" " codesystem=" " codesystemname="loinc" displayname="vaccines DUE NEXT"/> <statuscode code="completed"/> <value xsi:type="pq" value="$val_cop_vacc" unit="$unit_val_cop_vacc"/> </observation> </entryrelationship> <! Elemento Opzionale indica reazioni avverse --> $REAZIONI <! Elemento Opzionale Opzionali Note --> $NOTE </substanceadministration> In rosso i valori da modificare in nero quelli fissi $ID_SEZ = ID Unico della sezione (data type HL7 II ) $REF_DESC_VACC = riferimento incrociato alla descrizione dell intero elemento (vaccinazione) all interno della parte narrativa $DATA_VACC = Data della vaccinazione $COD_VACC ($DESC_VACC ) = Codice (descrizione) del vaccino all interno dello schema di codifica individuato (Nota: manca al momento una codifica condivisa dei vaccini ); $COD_SC_VACC = OID dello schema di codifica usato per i vaccini $REF_DESC_VACCINO = riferimento incrociato alla descrizione del vaccino all interno della parte narrativa Pagina 131/ 208

132 $COD_FARM ($DESC_FARM) = codice AIC (descrizione) del farmaco usato per la vaccinazione $REF_FARMACO = riferimento incrociato alla descrizione del farmaco usato per la vaccinazione all interno della parte narrativa $NUM_RICHIAMO = numero del richiamo $VAL_COP_VACC = Periodo di copertura del vaccino in base, valore espresso secondo le unità indicate dal parametro ($UNIT_VAL_COP_VACC) $REAZIONI: descrizione della possibili reazioni. Per dettagli vedi Descrizione Reazione $NOTE = Eventuali Note. Vedi Commenti NOTA: Il numero di lotto dovrà essere passato all interno del narrative block, in quanto l elemento <lotnumbertext> è presente per <manufacturedmaterial>, ma non per <manufacturedlabeleddrug> Vincoli aggiuntivi Non sono presenti i seguenti elementi opzionali : 1. <routecode code='' codesystem='' codesystemname='routeofadministration'/> 2. <approachsitecode code='' codesystem='' codesystemname='humansubstanceadministrationsite'/> 3. <dosequantity value='' units=''/> 4. Attività di Prescrizione (<entryrelationship typecode='refr'> ( template ' ) Esempio Narrative Block <text> <table border="1" width="100%"> <tbody> <tr ID="vac_desc_1"> <td>10/05/2007</td> <td> <content ID="vac_1">Febbre Gialla </content> <content ID="vac_note_1">(Viaggio in Indonesia). Lotto: 356/B/123456</content> </td> </tr> <tr ID="vac_desc_2"> <td>11/02/2005</td> Pagina 132/ 208

133 <td> <content ID="vac_2">Tetano</content> 2 (<content ID="vac_farm_2">IMOVAXTETANO*1SIR 0,5 ml</content>) (AIC )</td> </tr> <tr ID="vac_desc_3"> <td>13/06/2007</td> <td> <content ID="vac_3">DIFTERITE/TETANO</content> </td> </tr> </tbody> </table> </text> Coded Entry <entry> <!--==========================================================--> <!-- 11/02/20052 (IMOVAXTETANO*1SIR 0,5 ml) (AIC )--> <!--==========================================================--> <substanceadministration classcode="sbadm" moodcode="evn"> <templateid root=" "/> <templateid root=" "/> <templateid root=" "/> <id root="36e7e830-7b14-11db-9ff c9b66"/> <code code="immuniz" codesystem=" " codesystemname="actcode"/> <text> <reference value="#vac_desc_2"/> </text> <statuscode code="completed"/> <effectivetime value=" "/> <consumable typecode="csm"> <manufacturedproduct classcode="manu"> <manufacturedlabeleddrug classcode="mmat" determinercode="kind"> <code nullflavor="oth"> <originaltext> <reference value="#vac_2"/> </originaltext> Pagina 133/ 208

134 <translation code=" " codesystem=" " codesystemname="aic" displayname="imovaxtetano*1sir 0,5 ml"> <originaltext> <reference value="#vac_farm_2"/> </originaltext> </translation> </code> </manufacturedlabeleddrug> </manufacturedproduct> </consumable> <!-- Elemento Opzionale indica il numero di vaccinazione --> <entryrelationship typecode="subj"> <observation classcode="obs" moodcode="evn"> <templateid root=" "/> <code code=" " displayname="dose Number" codesystem=" " codesystemname="loinc"/> <statuscode code="completed"/> <value xsi:type="int" value="2"/> </observation> </entryrelationship> </substanceadministration> </entry> Pagina 134/ 208

135 6.6 Procedure (Procedures) Tutte le procedure diagnostiche, interventistiche, chirurgiche, terapeutiche relative alla storia clinica del paziente e di interesse all interno del documento SSI devono essere rappresentate all interno della sezione Procedures. Il modello informativo associato a questa sezione è il seguente : Specifiche di sezione Le specifiche di questa sezione ( procedures ) è definito dal template CCD ; i cui vincoli sono: Pagina 135/ 208

136 The template identifier for the procedures section is This section defines all interventional, surgical, diagnostic, or therapeutic procedures or treatments pertinent to the patient historically at the time the document is generated. The section may contain all procedures for the period of time being summarized, but should include notable procedures. CONF-422 CCD SHOULD contain exactly one and SHALL NOT contain more than one Procedures section (templateid ). The Procedures section SHALL contain a narrative block, and SHOULD contain clinical statements. Clinical statements SHOULD include one or more procedure activities (templateid ). CONF-423 The procedure section SHALL contain Section / code. CONF-424 The value for Section / code SHALL be History of procedures LOINC STATIC. CONF-425 The procedure section SHALL contain Section / title. Tale template è usato in forma specializzata all interno di IHE PCC per gestire la lista delle procedure chirurgiche ( ) List of Surgeries Section Come indicato in precedenza un esame strumentale potrà essere descritto attraverso un elemento di tipo <procedure>, in tal caso il template di riferimento sarà Procedures. Esempio d uso: <component> <section> <templateid root=" "/> <templateid root=" "/> <templateid root= /> <! OPZIONALE --> <templateid root=" "/> <id root='$id_sez /> <code code=" " codesystem=" " displayname="history of procedures"/> <title>procedure</title> <text> $NARRATIVE_BLOCK </text> <entry> Pagina 136/ 208

137 <! OPZIONALE Molteplicità 0 N Procedure codificate --> $PROCEDURA </entry> </component> </section> 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 $PROCEDURA = dettagli procedura. Vedi Dettagli Procedura Dettagli Procedura L identificativo del template usatop per descrivere una procedura è CONF-427 A procedure activity (templateid ) SHALL be represented with Act, Observation, or Procedure. CONF-428 The value for [Act Observation Procedure] in a procedure activity SHALL be EVN ActMood STATIC. CONF-429 A procedure activity SHALL contain at least one [Act Observation Procedure] / id. CONF-430 A procedure activity SHALL contain exactly one [Act Observation Procedure] / statuscode. CONF-431 The value for [Act Observation Procedure] / statuscode in a procedure activity SHALL be selected from ValueSet ProcedureStatusCode STATIC Codice Descrizione cancelled Cancelled Held On Hold Active In Progress Aborted Not Completed completed Completed Tabella (ProcedureStatusCode) Pagina 137/ 208

138 CONF-432 A procedure activity SHOULD contain exactly one [Act Observation Procedure] / effectivetime. Ciascuna procedura documentata dovrà contenere esattamente uno ed uno soltanto codice identificativo sia che sia stata modellata con Act Observation Procedure CONF-433 A procedure activity SHALL contain exactly one [Act Observation Procedure] / code. CONF-434 The value for [Act Observation Procedure] / code in a procedure activity SHOULD be selected from LOINC (codesystem ) or SNOMED CT (codesystem ), and MAY be selected from CPT-4 (codesystem ), ICD9 Procedures (codesystem ), ICD10 Procedure Coding System (codesystem ). <procedure classcode='proc' moodcode='evn INT'> <templateid root=' '/> <! OPZIONALE SE moodcode è EVN --> <templateid root=' '/> <! OPZIONALE SE moodcode è INT --> <templateid root=' '/> <id root='$id_sez /> <code code='$proc_code' codesystem='$proc_cod_sys codesystemname='$proc_cod_sys_name' /> <text><reference value='#ref_proc /></text> <statuscode code='completed active aborted cancelled'/> <effectivetime > <low value="$low_ts"/> <high value="$high_ts"/> </effectivetime > <! OPZIONALE Riferimento ad Encounter --> <! entryrelationship@typecode='refr' --> $RIF_ENCOUNTER <! OPZIONALE Ragione della procedura --> <! entryrelationship@typecode='rson' --> $RAGIONE </procedure> Pagina 138/ 208

139 In rosso i valori da modificare in nero quelli fissi $ID_SEZ = ID Unico della sezione (data type HL7 II ) $PROC_CODE = Codice tipo di procedura. $PROC_COD_SYS ($PROC_COD_SYS_NAME )= OID (nome) del Nomenclatore usato per le procedure $REF_PROC= riferimento incrociato alla descrizione dell intero elemento (procedura) all interno della parte narrativa $LOW_TS = data di inzio (prevista) della procedura $HIGH_TS = data di fine (prevista) della procedura $RIF_ENCOUNTER = Riferimento a encounter associato alla procedura. Utilizza il template ' '. Vedi Riferimenti Interni (In questo caso entryrelationship@typecode='refr') $RAGIONE = Ragione della procedura. Utilizza il template ' '. Vedi Ragione Vincoli aggiuntivi Non sono presenti i seguenti elementi opzionali : 1. <prioritycode code=''/> 2. <approachsitecode code='' displayname='' codesystem='' codesystemname=''/> 3. <targetsitecode code='' displayname='' codesystem='' codesystemname=''/> 4. <author /> 5. <informant /> Esempio <component> <section> <templateid root=" "/> <templateid root=" "/> <templateid root= /> <templateid root=" "/> <id root="36e8e830-7b14-11db-9ff c9b66"/> <code code=" " codesystem=" " displayname="history of procedures"/> <title>procedure</title> <text> <!--..OMISSIS..--> Pagina 139/ 208

140 </text> <entry> <! OPZIONALE Molteplicità 0 N Procedure codificate --> <procedure classcode='proc' moodcode='int'> <templateid root=' '/> <templateid root=' '/> <id root="36e8e930-7b14-11db-9ff c9b66"/> <code code="88.72" codesystem=" " codesystemname="icd9-cm" displayname="diagnostic ultrasound of heart"> <text><reference value='#proc_1_1 /></text> <statuscode code= active /> <effectivetime > <low value=" "/> </effectivetime > <entryrelationship typecode="rson"> <id root="36e8e930-7b14-11db-9fe c9b66"/> <code code="140" codesystem=" " codesystemname="icd-9cm (diagnosis codes) displayname="ima"> </entryrelationship> </procedure> </entry> </component> </section> Pagina 140/ 208

141 6.7 Visite e Ricoveri (Encounter) Tutte le informazioni relative a visite specialistiche o ricoveri (od in generale ad accessi) sono rappresentate nel CCD attraverso la sezione Encounter. Il modello informativo associato alla sezione Encounters è: Pagina 141/ 208

142 6.7.1 Specifiche di sezione Rete di Medici di Medicina Generale Progetto Esecutivo La sezione Encounter deve rispettare il template CCD ; i cui vincoli sono: CONF-453 CCD SHOULD contain exactly one and SHALL NOT contain more than one Encounters section (templateid ). The Encounters section SHALL contain a narrative block, and SHOULD contain clinical statements. Clinical statements SHOULD include one or more encounter activities (templateid ). CONF-454 The encounters section SHALL contain Section / code. CONF-455 The value for Section / code SHALL be History of encounters LOINC STATIC. CONF-456 The encounters section SHALL contain Section / title. CONF-457 Section / title SHOULD be valued with a case-insensitive language-insensitive text string containing encounters. Questo template viene ulteriormente specializzato all interno di IHE PCC dal template Encounter Histories Section ( The encounter history section contains coded entries describing the patient history of encounters. ) <component> <section> <templateid root=' '/> <templateid root=' '/> <id root='$id_sez /> <code code=' ' displayname='history OF ENCOUNTERS' codesystem=' ' codesystemname='loinc'/> <title>visite e Ricoveri</title> <text> $NARRATIVE_BLOCK </text> <entry> <! Molteplicità 1.. N --> $ENCOUNTER </entry> </section> </component> In rosso i valori da modificare in nero quelli fissi Pagina 142/ 208

143 $ID_SEZ = ID Unico della sezione (data type HL7 II ) $NARRATIVE_BLOCK = contenuto della sezione <text> vedi esempio $ENCOUNTER = dettagli incontro (visita, ricovero, ). Vedi Dettagli Incontro Dettagli Incontro CONF-458 An encounter activity (templateid ) SHALL be represented with Encounter. CONF-459 The value for Encounter in an encounter activity SHALL be ENC ActClass STATIC. CONF-460 The value for Encounter in an encounter activity SHALL be EVN ActMood STATIC. CONF-461 CONF-462 An encounter activity SHALL contain at least one Encounter / id. An encounter activity SHOULD contain exactly one Encounter / code. CONF-463 The value for Encounter / code in an encounter activity SHOULD be selected from ValueSet EncounterCode ActCode DYNAMIC. CONF-464 An encounter activity MAY contain exactly one Encounter / effectivetime, to indicate date, time, and/or duration of an encounter Attraverso il tag <code> viene specializzato l'encounter per indicare una specifica visita specialistica. <encounter classcode='enc' moodcode='evn'> <templateid root=' '/> <templateid root=' '/> <templateid root=' '/> <id root='$id_sez /> <code code='$enc_code' codesystem=' ' codesystemname='actencountercode' /> <text><reference value='#ref_enc /></text> <effectivetime > <low value="$low_ts"/> <high value="$high_ts"/> </effectivetime > <! OPZIONALE molteplicità 0 * --> <!-- Descrive gli operatori che prestano servizi durante l encounter --> Pagina 143/ 208

144 $PERFORMER <! OPZIONALE Luogo della visita / ricovero --> $LOCATION </encounter> In rosso i valori da modificare in nero quelli fissi $ID_SEZ = ID Unico della sezione (data type HL7 II ) $ENC_CODE = Codice tipo di encounter da tabella HL7 ActEncounterCode (vedi 7.8) $REF_ENC = riferimento incrociato alla descrizione dell intero elemento (incontro) all interno della parte narrativa $LOW_TS = data di inzio (prevista) dell encounter $HIGH_TS = data di fine (prevista) dell encounter $PERFORMER = Operatore che ha prestato servizi durante la visita (o il ricovero). Vedi "Performer" per i dettagli. $LOCATION =Luogo della visita / rciovero. Per dettagli vedi Errore. L'origine riferimento non è stata trovata. Errore. L'origine riferimento non è stata trovata Vincoli aggiuntivi 1. Limitato il moodcode dell encounter a EVN (valori possibili 'APT ARQ EVN') (e quindi usa il solo template ) 2. Non usato l elemento opzionale <author /> 3. Non usato l elemento opzionale < informant /> Performer Operatore che ha prestato i servizi di cura (e.g medico specialista che effettua la visita) durante l encounter. E rappresentato attraverso l elemento performer. <performer typecode='prf'> <!-- OPZIONALE presente solo se diverso da encounter.effectivetime --> <time> <low value="$low_ts"/> <high value="$high_ts"/> </time> Pagina 144/ 208

145 </performer> <assignedentity>$medico</assignedentity> In rosso i valori da modificare in nero quelli fissi $LOW_TS = data di inzio (prevista) del servizio prestato $HIGH_TS = data di fine (prevista) del servizio prestato $MEDICO = dati relativi all operatore. Per la struttura di questo elemento si faccia riferimento alle specifiche definite per l elemento <author> ( Autore) Luogo Le informazioni sul luogo in cui saranno rpestati i servizi relativi all encounter sono descritti attraverso un elemento di tipo participant così strutturato. <participant typecode='loc'> <templateid root=" "/> <participantrole classcode='sdloc'> <! OPZIONALE --> <id root='$id_sez /> <! OPZIONALE --> <code $COD_STRUTTURA /> <! OPZIONALE --> <addr>$addr</addr> <! OPZIONALE --> <telecom $TEL /> <playingentity classcode='plc' determinercode='inst'> <name>$nome</name> </playingentity> </participantrole> </participant> In rosso i valori da modificare in nero quelli fissi $ID_SEZ = ID Unico della sezione (data type HL7 II ) $COD_STRUTTURA = Codice della struttura (data type HL7 CE) $ADDR = Indirizzo della struttura. $TEL = riferimenti contatti telefonici, mail, www della struttura Pagina 145/ 208

146 $NOME = Nome dellla struttura Rete di Medici di Medicina Generale Progetto Esecutivo Esempio <component> <section> <templateid root=" "/> <templateid root=' '/> <code code=' ' displayname='history OF ENCOUNTERS' codesystem=' ' codesystemname='loinc'/> <title>visite e Ricoveri</title> <text> <!- OMISSIS --> </text> <entry typecode="driv"> <encounter classcode="enc" moodcode="evn"> <templateid root=' '/> <templateid root=' '/> <templateid root=' '/> <id root="2a d11-439e-92b3-5d9915ff4de8"/> <code code="genrl" codesystem=" " displayname="general" /> <text><reference value='#visita_1/></text> <effectivetime > <low value=" "/> <high value=" "/> </effectivetime > <participant typecode="loc"> <templateid root=" "/> <!-- Location participation template --> <participantrole classcode="sdloc"> <playingentity classcode="plc"> <name>studio Medico Perfetti Ricasoli</name> </playingentity> </participantrole> </participant> </encounter> </entry> </section> </component> Pagina 146/ 208

147 6.8 Risultati esami e visite (Results) Tutti i risultati di indagini diagnostiche (strumentali o di laboratorio), visite specialistiche, etc etc sono rappresentate all interno della Scheda Sanitaria Individuale all interno della sezione Results Il modello informativo associato alla sezione Results è: Specifiche di Sezione Come indicato nella parte introduttiva i risultati di un esame di laboratorio, così come quello strumentale, potrà essere descritto attraverso il template Results ( ) Pagina 147/ 208

148 CONF-388 CCD SHOULD contain exactly one and SHALL NOT contain more than one Results section (templateid ). The Results section SHALL contain a narrative block, and SHOULD contain clinical statements. Clinical statements SHOULD include one or more result organizers (templateid ), each of which SHALL contain one or more result observations (templateid ). CONF-389 The result section SHALL contain Section / code. CONF-390 The value for Section / code SHALL be Relevant diagnostic tests and/or laboratory data LOINC STATIC. tests and/or laboratory data LOINC STATIC. CONF-391: The results section SHALL contain Section / title. CONF-392: Section / title SHOULD be valued with a case-insensitive languageinsensitive text string containing results. Esempio d uso: <component> <section> <templateid root=" "/> <templateid root= /> <! OPZIONALE Presente se non ci sono elementi codificati --> <templateid root=' '/> <id root='$id_sez /> <!-- Results section template --> <code code=" " codesystem=" " codesystemname="loinc" displayname="relevant diagnostic tests and/or laboratory data"/> <title>risultati</title> <text> $NARRATIVE_BLOCK </text> <! Molteplicità 0 N --> <entry> $RES_ORGANIZER $RES_OBS </entry> </section> </component> In rosso i valori da modificare in nero quelli fissi Pagina 148/ 208

149 $ID_SEZ = ID Unico della sezione (data type HL7 II ) $NARRATIVE_BLOCK = contenuto della sezione <text> vedi esempio. Include eventuali link a documenti esterni. $RES_ORGANIZER = Organizer contentente le diverse osservazioni. Vedi Result Organizer $RES_OBS = Dettaglio singola osservazione. Vedi Dettaglio Osservazione Result Organizer Un result organizer identifica un insieme di osservazioni, tale elemento identifica le informazioni comuni a tutte le observation. CONF-393: A result organizer (templateid ) SHALL be represented with Organizer. CONF-394: The value for Organizer in a result organizer SHALL be EVN ActMood STATIC. CONF-395: CONF-396: CONF-397: A result organizer SHALL contain at least one Organizer / id. A result organizer SHALL contain exactly one Organizer / statuscode. A result organizer SHALL contain exactly one Organizer / code. ASTM CCR defines a restricted set of required result Type codes (see ResultTypeCode in section 7.3 Summary of CCD value sets), used to categorize a result into one of several commonly accepted values (e.g. Hematology, Chemistry, Nuclear Medicine ). These values are often implicit in the Organizer / code (e.g. an Organizer / code of complete blood count implies a ResultTypeCode of Hematology ). To better support translations between CCD and ASTM s XML CCR format, CCD requires Organizer / code to include a ResultTypeCode either directly or as a translation of a code from some other code system. CONF-398: The value for Organizer / code in a result organizer SHOULD be selected from LOINC (codesystem ) or SNOMED CT (codesystem ), and MAY be selected from CPT-4 (codesystem ) or ValueSet ResultTypeCode STATIC. CONF-399: A result organizer SHOULD include one or more Organizer / specimen if the specimen isn't inherent in Organizer / code. CONF-400: Organizer / specimen SHALL NOT conflict with the specimen inherent in Organizer / code. CONF-401: Organizer / specimen / specimenrole / id SHOULD be set to equal a Procedure / specimen / specimenrole / id (see section 3.14 Procedures) to indicate that the Results and the Procedure are referring to the same specimen. CONF-402: A result organizer SHALL contain one or more Organizer / component. Pagina 149/ 208

150 CONF-403: The target of one or more result organizer Organizer / component relationships MAY be a procedure, to indicate the means or technique by which a result is obtained, particularly if the means or technique isn t inherent in Organizer / code or if there is a need to further specialize the Organizer / code value. CONF-404: A result organizer Organizer / component / procedure MAY be a reference to a procedure described in the Procedure section. (See section 5.3 InternalCCRLink for more on referencing within CCD). CONF-405: The target of one or more result organizer Organizer / component relationships SHALL be a result observation. <entry typecode="driv"> <organizer classcode="battery CLUSTER" moodcode="evn"> <templateid root=" "/> <id root='$id_sez /> <code $COD_ORG_RES /> <statuscode code="completed"/> <!-- DataEsecuzione : data esecuzione batteria esami--> <effectivetime value="$ts"/> <component> $RES_OBS </component> </organizer> </entry> In rosso i valori da modificare in nero quelli fissi $ID_SEZ = ID Unico della sezione (data type HL7 II ) $TS = data esecuzione della batteria di esami $COD_ORG_RES = Codice (data type HL7 CE) che identifica il tipo di batteria di esami effettuata. Se non esiste una codice corrispondente alla batteria di esami fatta utilizzare il valore nullflavor= OTH. $RES_OBS = Dettaglio singola osservazione. Vedi Dettaglio Osservazione Dettaglio Osservazione CONF-407: A result observation (templateid ) SHALL be represented with Observation. Pagina 150/ 208

151 CONF-408: The value for Observation in a result observation SHALL be EVN ActMood STATIC. CONF-409: A result observation SHALL contain at least one Observation / id. CONF-410: A result observation SHALL contain exactly one Observation / statuscode. CONF-411: A result observation SHOULD contain exactly one Observation / effectivetime, which represents the biologically relevant time (e.g. time the specimen was obtained from the patient). CONF-412: A result observation SHALL contain exactly one Observation / code. CONF-413: The value for Observation / code in a result observation SHOULD be selected from LOINC (codesystem ) or SNOMED CT (codesystem ), and MAY be selected from CPT-4 (codesystem ). CONF-414: A result observation MAY contain exactly one Observation / methodcode if the method isn't inherent in Observation / code or if there is a need to further specialize the method in Observation / code. CONF-415: Observation / methodcode SHALL NOT conflict with the method inherent in Observation / code. CONF-416: A result observation SHALL contain exactly one Observation / value. CONF-417: Where Observation / value is a physical quantity, the unit of measure SHALL be expressed using a valid Unified Code for Units of Measure (UCUM) expression. CONF-418: A result observation SHOULD contain exactly one Observation / interpretationcode, which can be used to provide a rough qualitative interpretation of the observation, such as N (normal), L (low), S (susceptible), etc. Interpretation is generally provided for numeric results where an interpretation range has been defined, or for antimicrobial susceptibility test interpretation. CONF-419: A result observation SHOULD contain one or more Observation / referencerange to show the normal range of values for the observation result. CONF-420: A result observation SHALL NOT contain Observation / referencerange / observationrange / code, as this attribute is not used by the HL7 Clinical Statement or Lab Committee models. In base alle condizioni sopra espresse tale elemento potrà essere così strutturato: <entry typecode="driv"> <organizer classcode="obs" moodcode="evn"> <templateid root=" "/> <id root='$id_sez /> <code $COD_OBS_RES /> <text><reference value='#$ref_obs /></text> Pagina 151/ 208

152 <statuscode code='completed'/> <effectivetime ( value= $DT_OBS nullflavor= UNK ) /> <value xsi:type="pq" value="$obs_value" unit="$obs_unit"/> <interpretationcode code="$int_code" codesystem=" "/> <referencerange> <observationrange> ( <text> <reference value="#$ref_range" /> </text> OR <value xsi:type="ivl_pq">$range_value</value> ) </observationrange> </referencerange> </entry> In rosso i valori da modificare in nero quelli fissi $ID_SEZ = ID Unico della sezione (data type HL7 II ) $DT_OBS = data a cui l osservazione di riferisce. $VAL_OBS = valore numerico della misura. $VAL_UNIT = unità di misura usata. $REF_OBS = riferimento incrociato alla descrizione della misura nella parte narrativa $REF_RANGE_TXT = Riferimento alla parte narrativa su intervallo di valori di riferimento $RANGE_VALUE = Valorizzazione (come IVL_PQ) dell intervallo di valori di riferimento $INT_CODE = Codice di interpretazione dei risultati. Valore derivato dalla tabella HL7 ObservationInterpretation Esempio <entry typecode="driv"> <organizer classcode="battery" moodcode="evn"> <templateid root=" "/> <id root="7d5a02b0-67a4-11db-bd c9a66"/> <code code=" " codesystem=" " displayname="cbc WO DIFFERENTIAL"/> <statuscode code="completed"/> <effectivetime value=" "/> <component> <observation classcode="obs" moodcode="evn"> <templateid root=" "/> <!-- Result observation template --> Pagina 152/ 208

153 <id root="107c2dc0-67a5-11db-bd c9a66"/> <code code=" " codesystem=" " displayname="wbc"/> <statuscode code="completed"/> <effectivetime value=" "/> <value xsi:type="pq" value="6.7" unit="10+3/ul"/> <referencerange> <observationrange> <value xsi:type="ivl_pq"> <low value="4.3" unit="10+3/ul"/> <high value="10.8" unit="10+3/ul"/> </value> </observationrange> </referencerange> </observation> </component> </organizer> </entry> Pagina 153/ 208

154 6.9 Rilevazioni (Vital Signs) I risultati delle rilevazioni effettuate dal medico relative a dati antropometriche (altezza, peso, BMI), misure di pressione, battito cardiaco, frequenza di respirazione, etc etc sono gestite nella SSI all interno della sezione Vital Signs. Tale sezione, sebbene separata in una sezione ad hoc per seguire le convenzioni cliniche, è rappresentata usando le stesse convenzioni usate per i risultati delle altre rilevazioni (sezione Results )[vedi Risultati esami e visite (Results)] Esempi di asserzioni: 1. altezza: 30/04/ cm 2. peso: 30/04/ Kg 3. bmi: 30/04/ circonferenza vita: 30/04/ media ultime 4 rilevazioni PA: PA 20/4/ Specifiche di sezione La sezione Vital Signs, utilizzata per indicare i parametri vitali, è conforme al template CCD Questa sezione è composto da una parte testuale più eventualmente da uno o più organizer. I vincoli imposti dal CCD per questa sezioni sono: CONF-381: CCD SHOULD contain exactly one and SHALL NOT contain more than one Vital signs section (templateid ). The Vital signs section SHALL contain a narrative block, and SHOULD contain clinical statements. Clinical statements SHOULD include one or more vital signs organizers (templateid ), each of which SHALL contain one or more result observations (templateid ). CONF-382: The vital signs section SHALL contain Section / code. CONF-383: The value for Section / code SHALL be Vital signs LOINC STATIC. CONF-384: The vital signs section SHALL contain Section / title. CONF-385: Section / title SHOULD be valued with a case-insensitive languageinsensitive text string containing vital signs. Pagina 154/ 208

155 Tale struttura è ulteriormente specializzata dal template IHE PCC Vital Signs Section ( The vital signs section shall contain a narrative description of the measurement results of a patient s vital signs. ) Il modello informativo di riferimento per la sezione è rappresentato dal seguente modello dati: In base alle condizioni sopra espresso l elemento dovrà essere così strutturato: <component> <section> <templateid root=' '/> <templateid root=' '/> <!-- OPZIONALE : da usarsi se presenti elementi codificati --> <templateid root=' /> Pagina 155/ 208

156 <id root='$id_sez /> <code code='8716-3' displayname='vital SIGNS' codesystem=' ' codesystemname='loinc'/> <title>parametri Vitali</title> <text> $NARRATIVE_BLOCK </text> <! OPZIONALE Molteplicità 0 N --> <entry> $VS_ORGANIZER $ VS_OBS </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 $VS_ORGANIZER = Organizer che contiene le informazioni sulle misure dei parametri vitali. Vedi Vital Sign Organizer $VS_OBS = Dettaglio informazioni sulle misure dei parametri vitali. Vedi Vital Signs Observation Vital Sign Organizer L organizer che contiente i valori dei parametri è definita dal template , che una specializzazione del Result Organizer (templateid ) [Vedi per dettagli] Il template prevede i seguenti requisiti aggiuntivi CONF-386: A vital signs organizer (templateid ) SHALL be a conformant results organizer (templateid ). CONF-387: A vital signs organizer SHALL contain one or more sources of information, as defined in section 5.2 Source. Il template è ulteriormente specializzato da IHE PCC (templateid ' ') Pagina 156/ 208

157 In base ai vincoli sopra espressi la sezione deve essere così strutturata: <organizer classcode='cluster' moodcode='evn'> <templateid root=' '/> <templateid root=' '/> <templateid root=' '/> <id root='$id_sez /> <code code=' ' displayname='vital signs' codesystem=' ' codesystemname='snomed CT'/> <statuscode code='completed'/> <effectivetime value="$ts"/> <! Molteplicità 1 N Vital signs observations --> <component typecode='comp'> $VS_OBS </component> </organizer> In rosso i valori da modificare in nero quelli fissi $ID_SEZ = ID Unico della sezione (data type HL7 II ) $TS = data in cui le misure sono state effettuate $VS_OBS = Dettaglio informazioni sulle misure dei parametri vitali. Vedi Vital Signs Observation Vital Signs Observation Una vital signs observation è una semplice osservazione che usa un volcabolario specificio ed eredita i vincoli relativi alle result observation definite dal template CCD (template ' '). In IHE PCC tali vincoli sono definiti dal template <observation classcode='obs' moodcode='evn'> <templateid root=' '/> <templateid root=' '/> <templateid root=' '/> <id root='$id_sez /> <code code='$obs_cod' codesystem=' ' codesystemname='loinc'/> <text><reference value='#$ref_obs /></text> <statuscode code='completed'/> <effectivetime ( value= $DT_OBS nullflavor= UNK ) /> Pagina 157/ 208

158 <value xsi:type="pq" value="$obs_value" unit="$obs_unit"/> <! OPZIONALE --> <interpretationcode code="$int_code" codesystem=" "/> </observation> In rosso i valori da modificare in nero quelli fissi $ID_SEZ = ID Unico della sezione (data type HL7 II ) $OBS_CODE = Codice relativo alla misura effettuata. Deve essere derivato da uno dei codici preenti nelal tabella seguente $DT_OBS = data a cui l osservazione di riferisce. $VAL_OBS = valore numerico della misura. $VAL_UNIT = unità di misura usata. $REF_OBS = riferimento incrociato alla descrizione della misura nella parte narrativa $INT_CODE = Codice di interpretazione dei risultati. Valore derivato dalla tabella HL7 ObservationInterpretation LOINC Description Units RESPIRATION RATE /min HEART BEAT OXYGEN SATURATION % INTRAVASCULAR SYSTOLIC mm[hg] INTRAVASCULAR DIASTOLIC BODY TEMPERATURE Cel BODY HEIGHT (MEASURED) m, cm BODY HEIGHT^LYING CIRCUMFRENCE.OCCIPITAL-FRONTAL (TAPE MEASURE) BODY WEIGHT (MEASURED) kg, g Vincoli aggiuntivi Non sono presenti i seguenti elementi opzionali: Pagina 158/ 208

159 1. <repeatnumber value=' '/> 2. <methodcode code=' ' codesystem=' ' codesystemname=' '/> 3. <targetsitecode code=' ' codesystem=' ' codesystemname=' '/> NarrativeBlock <text> <table border="1" width="100%"> <thead> <tr> <th >Data</th> <th>parametro</th> <th>valore</th> <th>note</th> </tr> </thead> <tbody> <tr> <td>30/04/2008</td> <td>altezza</td> <td>165 cm</td> <td> </td> </tr> <tr> <td>30/04/2008</td> <td>peso</td> <td>78.8 Kg</td> <td> </td> </tr> <tr> <td>30/04/2008</td> <td>bmi</td> <td>28.7</td> <td> </td> </tr> <tr> <td>30/04/2008</td> <td>circonferenza Vita</td> <td>234</td> Pagina 159/ 208

160 </text> <td> </td> </tr> <tr> <td>10/12/ /04/2008</td> <td>media ultime 4 rilevazioni PA</td> <td>84-150</td> <td> </td> </tr> <tr> <td>20/04/2008</td> <td>pa</td> <td>87 90</td> <td> </td> </tr> </tbody> </table> Pagina 160/ 208

161 Pagina 161/ 208

162 6.10 Stile di Vita (Social History) Destinata alla rappresentazione di tutte le condizioni di vita rilevanti per il quadro clinico del paziente, include: fattori di rischio condizioni lavorative ed ambientali: (dove vivi, ) stile di vita stato sociale: o livello di istruzione o età o stato civile/figli. Nota: in tale sezione devono essere riportati SOLO gli ultimi dati aggiornati per ogni tipo di osservazione e SOLO se clinicamente ancora significativi Esempi di informazioni gestite: 1 Forte fumatore 2 Astemio 3 Laureato 4 In pensione, ex impiegata 5 Sposata, due figli Specifiche di Sezione Le informazioni relative alle condizioni di vita sono mappate all interno del CCD nella sezione Social History definito dal template " ". Tale template è specializzato in IHE PCC attraverso il template ( The social history section shall contain a narrative description of the person s beliefs, home life, community life, work life, hobbies, and risky habits. ) CONF-232: CCD SHOULD contain exactly one and SHALL NOT contain more than one Social history section (templateid ). The Social history section SHALL contain a narrative block, and SHOULD contain clinical statements. Clinical statements SHOULD include one or more social history observations (templateid ). CONF-233: The social history section SHALL contain Section / code. CONF-234: The value for Section / code SHALL be Social history LOINC STATIC. Pagina 162/ 208

163 CONF-235: The social history section SHALL contain Section / title. CONF-236: Section / title SHOULD be valued with a case-insensitive languageinsensitive text string containing social history. In base alle condizioni sopra espresso la sezione potrà essere così strutturata: <component> <section> <templateid root=' '/> <templateid root=' '/> <id root='$id_sez /> <code code=' ' displayname='social HISTORY' codesystemname='loinc'/> <title>stili di Vita (Social History)</title> <text> $NARRATIVE_BLOCK </text> </section> </component> codesystem=' ' 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 Esempio Narrative Block <text> <table border="1" width="100%"> <tbody> <tr> <th colspan="2">fattori di Rischio</th> </tr> <tr> Pagina 163/ 208

164 </table> </text> <td>fumo</td> <td>forte Fumatore</td> </tr> <tr> <td>consumo Alcool</td> <td>astemio</td> </tr> <tr> <th colspan="2">altro</th> </tr> <tr> <td>titolo di Studio</td> <td>laureata</td> </tr> <tr> <td>professione </td> <td>in pensione, ex impiegata</td> </tr> <tr> <td colspan="2">condizione Familiare Sposata, due figli</td> </tr> </tbody> Pagina 164/ 208

165 6.11 Costante Biologica La struttura conterrà le informazioni relative alla situazione clinica del paziente di tipo permanente Gruppo Sanguigno La rilevazione del gruppo sanguigno o fenotipo è un risultato di una indagine di laboratorio ed è quindi strutturabile secondo il template Results che ha identificatore Si veda il capitolo Errore. L'origine riferimento non è stata trovata. per l implementazione. I risultati devono essere inseriti in un organizer che contenga due Observation, una per il gruppo sanguigno e l altra per il fattore RH Protesi Vedi sezione Protesi Organi Mancanti Vedi sezione Organi Mancanti Pagina 165/ 208

166 6.12 Protesi ed Ausilii (Medical Equipment) Tutte le informazioni relativi a protesi od ausili sono registrate all interno di questo documento all interno della sezione Medical Equipment. In generale tale sezione descrive tutti i dispositivi medici o equipoaggiamenti / ausilli (impiantati od esterni) che servono di supporto per il paziente. Esempi di informazioni gestate: Protesi, impianti, ausili 1. PORTATORE PACE MAKER (ICD9-CM V4501) (Maggio 2008) 2. DOTATO TEMPORANEAMENTE DI STAMPELLE Specifiche di sezione Le informazioni relative alle protesi ed ausilii sono mappate all interno del CCD nella sezione Medical Equipment definito dal template " ". Il template segue la stessa struttura e vincoli del template Medication, usato nel capitolo Errore. L'origine riferimento non è stata trovata.. Tale template è specializzato in IHE PCC attraverso il template ( The medical devices section contains narrative text describing the patient history of medical device use. ) CONF-371:CCD SHOULD contain exactly one and SHALL NOT contain more than one Medical Equipment section (templateid ). The Medical Equipment section SHALL contain a narrative block, and SHOULD contain clinical statements. Clinical statements SHOULD include one or more supply activities (templateid ) and MAY include one or more medication activities (templateid ). CONF-372: The medical equipment section SHALL contain Section / code. CONF-373: The value for Section / code SHALL be History of medical device use LOINC STATIC. CONF-374: The medical equipment section SHALL contain Section / title. CONF-375: Section / title SHOULD be valued with a case-insensitive languageinsensitive text string containing equipment. In base alle condizioni sopra espresso la sezione potrà essere così strutturata: Pagina 166/ 208

167 <component> <section> <templateid root=' '/> <templateid root=' '/> <id root='$id_sez /> <code code=' ' displayname='history OF MEDICAL DEVICE USE' codesystem=' ' codesystemname='loinc'/> <title>protesi, Impianti ed Ausilii</title> <text> $NARRATIVE_BLOCK </text> </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 Esempi Narrative_Block <text> <table border="1" width="100%"> <tbody> <tr><td>portatore PACE MAKER (ICD9-CM V4501) (Maggio 2008)</td> </tr> <tr><td>dotato TEMPORANEAMENTE DI STAMPELLE</td></tr> </tbody> </table> </text> Pagina 167/ 208

168 6.13 Anamnesi Familiare (Family History) Qui viene riportata l anamnesi familiare dei genitori e parenti biologici, rilevante per definire il profilo di rischio del paziente. I dati si possono sinteticamente definire come una lista di patologie geneticamente rilevanti che influenzano/hanno influenzato i parenti: Grado di parentela biologica (Padre, Madre, fratelli, nonni, figli, collaterali) Patologie del parente note Esempi di asserzioni sulla familiarità possono essere : 1. Familiarità per ASMA (439.9): ASSENTE 2. Familiarità per K SISTEMA NERVOSO (129.9) [senza altra informazione] 3. Familiarità per DEFICIT VISIVI (369.2) : padre, nonna paterna, zio 4. Familiarità per IMA PRECOCE : padre morto prima dei 51 anni di IMA [Inf. Mioc. Acuto, ma non esiste un codice per IMA PRECOCE] 5. Familiarità per Diabete : padre insorgenza a 15 anni. 6. Familiarità per Diabete : nonna paterna NON DIABETICA 7. Il paziente non ricorda casi di diabete in famiglia, ma sa che qualcuno ha avuto problemi di ipertensione Specifiche di sezione Le informazioni relative all anamnesi familiare sono mappate all interno del CCD nella sezione Family History definito dal template " ". Il modello informativo relativo al template è: Pagina 168/ 208

Guida alle specifiche del template CDA Verbale di Pronto Soccorso.

Guida alle specifiche del template CDA Verbale di Pronto Soccorso. Guida alle specifiche del template CDA Verbale di Pronto Soccorso. Data Ver Descrizione Modifica 18/11/2016 1 Prima emissione LAZIOcrea S.p.A. Società a Socio unico Regione Lazio Cap. Soc. 924.400,00 Sede

Dettagli

Specifiche tecniche per la produzione del Patient Summary in formato HL7 Versione 3 CDA Rel.2 secondo template CCD. Progetto Esecutivo Definitivo

Specifiche tecniche per la produzione del Patient Summary in formato HL7 Versione 3 CDA Rel.2 secondo template CCD. Progetto Esecutivo Definitivo Patient Summary in formato HL7 Versione 3 CDA Rel.2 secondo template CCD Progetto Esecutivo Accordo di Programma Quadro "Sviluppo della Società dell'informazione nella Regione Abruzzo" Atto Integrativo

Dettagli

TSE Tavolo di lavoro permanente per la Sanità Elettronica delle Regioni e delle Provincie Autonome

TSE Tavolo di lavoro permanente per la Sanità Elettronica delle Regioni e delle Provincie Autonome TSE Tavolo di lavoro permanente per la Sanità Elettronica delle Regioni e delle Provincie Autonome Specifiche tecniche per la creazione del Documento di Referto di anatomia patologica secondo lo Versione

Dettagli

HL7 Italia. V3it TC. HL7 -V3 Technical Committee Dominio CDA Template Lettera di dimissione Ospedaliera. Versione 1.

HL7 Italia.  V3it TC. HL7 -V3 Technical Committee Dominio CDA Template Lettera di dimissione Ospedaliera. Versione 1. www.hl7italia.it V3it TC HL7 -V3 Technical Committee Dominio CDA Template Lettera di dimissione Ospedaliera Versione 1.0 Marzo 2014 HL7 Version 3 Standard, 2007 Health Level Seven, Inc. All Rights Reserved.

Dettagli

TSE Tavolo di lavoro permanente per la Sanità Elettronica delle Regioni e delle Provincie Autonome

TSE Tavolo di lavoro permanente per la Sanità Elettronica delle Regioni e delle Provincie Autonome TSE Tavolo di lavoro permanente per la Sanità Elettronica delle Regioni e delle Provincie Autonome Specifiche tecniche per la creazione del Profilo Sanitario Sintetico secondo lo standard HL7-CDA Rel.

Dettagli

TSE Tavolo di lavoro permanente per la Sanità Elettronica delle Regioni e delle Provincie Autonome

TSE Tavolo di lavoro permanente per la Sanità Elettronica delle Regioni e delle Provincie Autonome TSE Tavolo di lavoro permanente per la Sanità Elettronica delle Regioni e delle Provincie Autonome Specifiche tecniche per la creazione del Certificato INPS secondo Versione 02.20 15/06/2010 Pagina 1 di

Dettagli

Guida alle specifiche del template CDA Lettera di dimissione Ospedaliera.

Guida alle specifiche del template CDA Lettera di dimissione Ospedaliera. Guida alle specifiche del template CDA Lettera di dimissione Ospedaliera. Data Ver Descrizione Modifica 18/11/2016 1 Prima emissione LAZIOcrea S.p.A. Società a Socio unico Regione Lazio Cap. Soc. 924.400,00

Dettagli

Specifiche tecniche per la creazione dei "Documenti di raccolta e gestione del consenso" secondo lo standard HL7-CDA Rel. 2

Specifiche tecniche per la creazione dei Documenti di raccolta e gestione del consenso secondo lo standard HL7-CDA Rel. 2 TSE Tavolo di lavoro permanente delle Regioni e delle Provincie Autonome Specifiche tecniche per la creazione dei "Documenti di raccolta e gestione del consenso" secondo lo standard HL7-CDA Rel. 2 Versione

Dettagli

HL7 Italia. Implementation Guide Clinical Document Architecture (CDA) Rel. 2. Lettera di Dimissione Ospedaliera (LDO) (IT Realm)

HL7 Italia.  Implementation Guide Clinical Document Architecture (CDA) Rel. 2. Lettera di Dimissione Ospedaliera (LDO) (IT Realm) www.hl7italia.it Implementation Guide Clinical Document Architecture (CDA) Rel. 2 Lettera di Dimissione Ospedaliera (LDO) (IT Realm) Standard Informativo Versione 1.0 Marzo 1 HL7 Version 3 Standard, 14

Dettagli

HL7 Italia. Implementation Guide. Clinical Document Architecture (CDA) Rel. 2. Profilo Sanitario Sintetico (Patient Summary)

HL7 Italia.  Implementation Guide. Clinical Document Architecture (CDA) Rel. 2. Profilo Sanitario Sintetico (Patient Summary) www.hl7italia.it Implementation Guide Clinical Document Architecture (CDA) Rel. 2 Profilo Sanitario Sintetico (Patient Summary) (IT Realm) Standard Informativo Versione 1.1 Novembre 2011 HL7 Version 3

Dettagli

IBSE Infrastruttura di Base della Sanità Elettronica

IBSE Infrastruttura di Base della Sanità Elettronica 1 2 3 4 5 6 7 8 9 10 IBSE Infrastruttura di Base della Sanità Elettronica 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 PATIENT SUMMARY Definizione dei contenuti del Patient

Dettagli

Standard tecnici per la creazione del Documento di Prescrizione

Standard tecnici per la creazione del Documento di Prescrizione TSE Tavolo di lavoro permanente Delle Regioni e delle Province Autonome Standard tecnici per la creazione del Documento di Prescrizione Pagina 1 di 139 Indice 1 Status del documento... 6 2 Obiettivi del

Dettagli

Specifiche tecniche per il referto di laboratorio secondo lo standard HL7 CDA Release 2.0

Specifiche tecniche per il referto di laboratorio secondo lo standard HL7 CDA Release 2.0 Schema di referto 1di 62 CDA release 2 Specifiche tecniche per il referto di laboratorio secondo lo standard HL7 CDA Release 2.0 Indice 1 Introduzione... 3 2 Struttura dello schema... 4 2.1 Elementi Obbligatori...

Dettagli

HL7 Italia. Implementation Guide. Clinical Document Architecture (CDA) Rel. 2. Profilo Sanitario Sintetico (Patient Summary)

HL7 Italia.  Implementation Guide. Clinical Document Architecture (CDA) Rel. 2. Profilo Sanitario Sintetico (Patient Summary) www.hl7italia.it Implementation Guide Clinical Document Architecture (CDA) Rel. 2 Profilo Sanitario Sintetico (Patient Summary) (IT Realm) Standard Informativo Versione 1.2 Ballot HL7 Version 3 Standard,

Dettagli

Clinical Document Architecture (CDA)

Clinical Document Architecture (CDA) Clinical Document Architecture (CDA) Occorre strutturare un referto? interoperabilità!!! i sistemi di laboratorio sono sempre più calati in contesti integrati, la parola d ordine d è INTEROPERABILITÀ...

Dettagli

Trillium II. Reinforcing the Bridges and Scaling up EU/US Cooperation on Patient Summary

Trillium II. Reinforcing the Bridges and Scaling up EU/US Cooperation on Patient Summary This project has received funding from the European Union s Horizon 2020 research and innovation programme under grant agreement No 727745 Trillium II Reinforcing the Bridges and Scaling up EU/US Cooperation

Dettagli

DOCUMENTAZIONE TECNICA ADD-ON MILLEWIN ACCREDITAMENTO E.TOSCANA COMPLIANCE

DOCUMENTAZIONE TECNICA ADD-ON MILLEWIN ACCREDITAMENTO E.TOSCANA COMPLIANCE DOCUMENTAZIONE TECNICA ADD-ON MILLEWIN Data di emissione: Ottobre 2012 Autore: Emanuela Consoli Revisione: 01.00 Indice 1. Contesto di riferimento 3 2. Descrizione del sistema 4 3. Architettura dell'applicazione

Dettagli

Arsenàl.IT. Centro Veneto Ricerca e Innovazione per la Sanità Digitale. GDL-O Documenti Clinici

Arsenàl.IT. Centro Veneto Ricerca e Innovazione per la Sanità Digitale. GDL-O Documenti Clinici GDL-O Documenti Clinici Linee guida funzionali sulla Lettera di Dimissione Ospedaliera (LDO) Arsenàl.IT Centro Veneto Ricerca e Innovazione per la Sanità Digitale pag. 1 di 22 pag. 2 di 22 5 Informazioni

Dettagli

TIPI DI DATO NELLA CARTELLA CLINICA ELETTRONICA: I DOCUMENTI TESTUALI. Corso di Informatica Medica

TIPI DI DATO NELLA CARTELLA CLINICA ELETTRONICA: I DOCUMENTI TESTUALI. Corso di Informatica Medica Università degli Studi di Trieste Corso di Laurea Magistrale in INGEGNERIA CLINICA TIPI DI DATO NELLA CARTELLA CLINICA ELETTRONICA: I DOCUMENTI TESTUALI Corso di Informatica Medica Docente Sara Renata

Dettagli

Il Progetto LUMIR Lucania Medici In Rete

Il Progetto LUMIR Lucania Medici In Rete Il Progetto LUMIR Lucania Medici In Rete Fabrizio L. Ricci Il Sistema LuMiR Scanzano Jonico, 15 Marzo 2008 Introduzione Il progetto LUMIR Il sistema informatico LUMIR Il prototipo zero (P0) Evoluzioni

Dettagli

TSE Tavolo di lavoro permanente per la Sanità Elettronica delle Regioni e delle Province Autonome

TSE Tavolo di lavoro permanente per la Sanità Elettronica delle Regioni e delle Province Autonome TSE Tavolo di lavoro permanente per la Sanità Elettronica delle Regioni e delle Province Autonome Standard tecnici per la creazione del Documento di Prescrizione da inviare al SAC Versione 1.0 04/11/2010

Dettagli

SMS Gateway - Specifiche WS. Specifica Tecnica

SMS Gateway - Specifiche WS. Specifica Tecnica Specifica Tecnica Revisione Data Elaborato da Verificato da Note 1 21/02/13 Stefano Peruzzi Gianni Antini Mod. ST-rev002_2013-02-21 Pag. 1/11 Indice 1 Oggetto...3 2 Scopo del documento...3 3 Riferimenti...3

Dettagli

DOCUMENTAZIONE TECNICA ADD-ON MILLEWIN ACCREDITAMENTO E.TOSCANA COMPLIANCE. Data di emissione: Luglio 2014 Autore: Emanuela Consoli Revisione: 01.

DOCUMENTAZIONE TECNICA ADD-ON MILLEWIN ACCREDITAMENTO E.TOSCANA COMPLIANCE. Data di emissione: Luglio 2014 Autore: Emanuela Consoli Revisione: 01. DOCUMENTAZIONE TECNICA ADD-ON MILLEWIN ACCREDITAMENTO Data di emissione: Luglio 2014 Autore: Emanuela Consoli Revisione: 01.00 Indice 1. Contesto di riferimento 3 2. Descrizione del sistema 4 3. Architettura

Dettagli

Corso di Informatica Medica

Corso di Informatica Medica Università degli Studi di Trieste Corso di Laurea Magistrale in INGEGNERIA CLINICA LA CARTELLA CLINICA ELETTRONICA Corso di Informatica Medica Docente Sara Renata Francesca MARCEGLIA Dipartimento di Ingegneria

Dettagli

Il progetto MEDIR Rete dei Medici di Medicina Generale e Pediatri di Libera Scelta e Fascicolo Sanitario Elettronico

Il progetto MEDIR Rete dei Medici di Medicina Generale e Pediatri di Libera Scelta e Fascicolo Sanitario Elettronico Il progetto MEDIR Rete dei Medici di Medicina Generale e Pediatri di Libera Scelta e Fascicolo Sanitario Elettronico Obiettivi Supportare l efficienza delle cure primarie attraverso l integrazione in rete

Dettagli

1. INTRODUZIONE GAZZETTA UFFICIALE DELLA REPUBBLICA ITALIANA Serie generale - n. 195 A LLEGATO A

1. INTRODUZIONE GAZZETTA UFFICIALE DELLA REPUBBLICA ITALIANA Serie generale - n. 195 A LLEGATO A A LLEGATO A FUNZIONI E SERVIZI DELL INFRASTRUTTURA NAZIONALE PER L INTEROPERABILITÀ DEI FASCICOLI SANITARI ELETTRONICI 1. Introduzione. 2. Servizi per la gestione dei documenti disponibili alle strutture

Dettagli

TRACCIATO RECORD BONIFICI DOMICILIATI

TRACCIATO RECORD BONIFICI DOMICILIATI Tracciato record bonifici domiciliati Ed. Novembre 2015 TRACCIATO RECORD BONIFICI DOMICILIATI Poste Italiane S.p.A. Patrimonio BancoPosta 1 di 7 TRACCIATO RECORD BONIFICI DOMICILIATI DEFINIZIONE DI SUPPORTO

Dettagli

Continuità di cura: esperienze italiane ed europee a confronto L esperienza di Regione Lombardia Marco Pantera Lombardia Informatica

Continuità di cura: esperienze italiane ed europee a confronto L esperienza di Regione Lombardia Marco Pantera Lombardia Informatica Terzo incontro con la HIMSS Italian Community Continuità di cura: esperienze italiane ed europee a confronto L esperienza di Regione Lombardia Marco Pantera Lombardia Informatica Milano, 21 Febbraio 2018

Dettagli

TRACCIATO RECORD valido dal 2 invio 2007 Nota:

TRACCIATO RECORD valido dal 2 invio 2007 Nota: TRACCIATO RECORD valido dal 2 invio 2007 Nota: Le modifiche rispetto al precedente tracciato riguardano esclusivamente la tabella B e sono riferite alla lunghezza del campo importo unitario parte intera

Dettagli

SCHEDA DESCRITTIVA DEL SIP PER LA TIPOLOGIA DOCUMENTARIA CONTRATTO. [versione 1.0 del 4/6/2014]

SCHEDA DESCRITTIVA DEL SIP PER LA TIPOLOGIA DOCUMENTARIA CONTRATTO. [versione 1.0 del 4/6/2014] SCHEDA DESCRITTIVA DEL P PER LA TIPOLOGIA DOCUMENTARIA CONTRATTO [versione 1.0 del 4/6/2014] CONTRATTO Estratto da LINEE GUIDA PER LA REALIZZAZIONE DEI PACCHETTI DI VERSAMENTO (P) 1. Descrizione della

Dettagli

DISCIPLINARE TECNICO. Istruzioni per la compilazione e la codifica delle informazioni riportate nella scheda di dimissione ambulatoriale ospedaliera.

DISCIPLINARE TECNICO. Istruzioni per la compilazione e la codifica delle informazioni riportate nella scheda di dimissione ambulatoriale ospedaliera. DISCIPLINARE TECNICO Istruzioni per la compilazione e la codifica delle informazioni riportate nella scheda di dimissione ambulatoriale ospedaliera. 1.1 ISTRUZIONI DI CARATTERE GENERALE La scheda di dimissione

Dettagli

MANUALE GESTIONE DISTRETTI TRACCIATO FARMED. Azienda Ospedaliera San Giovanni Addolorata

MANUALE GESTIONE DISTRETTI TRACCIATO FARMED. Azienda Ospedaliera San Giovanni Addolorata MANUALE GESTIONE DISTRETTI TRACCIATO FARMED Azienda Ospedaliera San Giovanni Addolorata TP001 - Template Areas Verticale Direzione Consulenza Soluzioni e applicazioni Area AMC v 1.0 INFORMAZIONI SULLA

Dettagli

Fascicolo Sanitario. «La roadmap e l accelerazione in atto» Agenzia per l Italia Digitale. Presidenza del Consiglio dei Ministri

Fascicolo Sanitario. «La roadmap e l accelerazione in atto» Agenzia per l Italia Digitale. Presidenza del Consiglio dei Ministri Fascicolo Sanitario Elettronico «La roadmap e l accelerazione in atto» Ing. Stefano van der Byl Fascicolo Sanitario Elettronico 1/2 «Il FSE è l insieme dei dati e documenti digitali di tipo sanitario e

Dettagli

Specifiche tracciato record file C1 e C2 specialistica ambulatoriale

Specifiche tracciato record file C1 e C2 specialistica ambulatoriale Specifiche tracciato record file C1 e C2 specialistica ambulatoriale Il nome del file trasmesso e rimasto invariato es: Laboratorio Verdi con codice STS 150000 per il mese di gennaio 2007 trasmetterà il

Dettagli

Il Modello di Attuazione della Sanità Elettronica in Regione Lombardia:

Il Modello di Attuazione della Sanità Elettronica in Regione Lombardia: Chiara Penello Il Modello di Attuazione della Sanità Elettronica in Regione Lombardia: A metà degli anni 90, contemporaneamente alla riforma della Sanità lombarda, introdotta con la Legge 31/97, si è riorganizzato

Dettagli

IL FASCICOLO SANITARIO ELETTRONICO IN REGIONE CALABRIA 3

IL FASCICOLO SANITARIO ELETTRONICO IN REGIONE CALABRIA 3 Con il Patrocinio della Regione Calabria Con il Patrocinio della Regione Calabria IVA t IL FASCICOLO SANITARIO ELETTRONICO IN REGIONE CALABRIA La parola ai protagonisti Dott. Zappia Vincenzo Segretario

Dettagli

PROFILO SANITARIO SINTETICO

PROFILO SANITARIO SINTETICO del del del del del del SEZIONE INTESTAZIONE Cognome Cognome dell' Testo libero Nome Nome completo dell' (come risulta in anagrafe) Testo libero Codice fiscale Codice fiscale dell' Agenzia Entrate Sesso

Dettagli

Adriano MARCOLONGO - direttore centrale salute, integrazione sociosanitaria, politiche sociali e famiglia, R.A. FVG

Adriano MARCOLONGO - direttore centrale salute, integrazione sociosanitaria, politiche sociali e famiglia, R.A. FVG Adriano MARCOLONGO - direttore centrale salute, integrazione sociosanitaria, politiche sociali e famiglia, R.A. FVG Maurizio BLANCUZZI direttore del servizio sistema informativo salute e politiche sociali

Dettagli

Il Fascicolo Sanitario Elettronico della Regione Autonoma della Sardegna: stato dell arte ed evoluzione

Il Fascicolo Sanitario Elettronico della Regione Autonoma della Sardegna: stato dell arte ed evoluzione Verso la cartella clinica elettronica: standard internazionali e piattaforme aperte in informatica sanitaria Il Fascicolo Sanitario Elettronico della Regione Autonoma della Sardegna: stato dell arte ed

Dettagli

COMUNE DI SANT ANNA ARRESI

COMUNE DI SANT ANNA ARRESI COMUNE DI SANT ANNA ARRESI AREA AMMINISTRATIVA UFFICIO SEGRETERIA UFFICIO PROTOCOLLO PRODUZIONE E CONSERVAZIONE DEL REGISTRO GIORNALIERO DI PROTOCOLLO 1. Introduzione e breve inquadramento normativo Dal

Dettagli

Arsenàl.IT. Centro Veneto Ricerca e Innovazione per la Sanità Digitale. Arsenàl.IT. Fascicolo Sanitario Elettronico Regione del Veneto

Arsenàl.IT. Centro Veneto Ricerca e Innovazione per la Sanità Digitale. Arsenàl.IT. Fascicolo Sanitario Elettronico Regione del Veneto GDL-O Documenti Clinici Specifiche tecniche CDA2 Medicina di laboratorio Centro Veneto Ricerca e Innovazione per la Sanità Digitale pag. 1 di 101 Informazioni preliminari Contatti Per ulteriori informazioni,

Dettagli

PO.1. GESTIONE E ORGANIZZAZIONE DELLA DOCUMENTAZIONE

PO.1. GESTIONE E ORGANIZZAZIONE DELLA DOCUMENTAZIONE PO.1. INDICE 1. SCOPO 2. CAMPO DI APPLICAZIONE 3. RESPONSABILITA 4. DESCRIZIONE DELLE ATTIVITÀ 5. INDICATORI DI PROCESSO 6. RIFERIMENTI 7. ARCHIVIAZIONI 8. TERMINOLOGIA ED ABBREVIAZIONI 9. DOCUMENTI DI

Dettagli

FSE Componente Locale Specifica del servizio di recupero documento nel dipartimentale/repository dell Azienda

FSE Componente Locale Specifica del servizio di recupero documento nel dipartimentale/repository dell Azienda FSE Componente Locale Specifica del servizio di recupero documento nel dipartimentale/repository dell Azienda Pagina 1 di 15 STATO DELLE VARIAZIONI VERSIONE PARAGRAFO O DESCRIZIONE DELLA VARIAZIONE PAGINA

Dettagli

Mediasoft snc. Classi documentali. Allegato al manuale di Conservazione sostitutiva. Versione 1.0.2 del 2 novebre 2015

Mediasoft snc. Classi documentali. Allegato al manuale di Conservazione sostitutiva. Versione 1.0.2 del 2 novebre 2015 Mediasoft snc Classi documentali Allegato al manuale di Conservazione sostitutiva Versione 1.0.2 del 2 novebre 2015 Emissione del documento Azione Data Nominativo Funzione Redazione 02-11-2015 Paolo Scarabelli

Dettagli

Non si applica nel caso di prescrizione di stupefacenti oppure di farmaci per la terapia del dolore che sono prescritti sui relativi modelli

Non si applica nel caso di prescrizione di stupefacenti oppure di farmaci per la terapia del dolore che sono prescritti sui relativi modelli Non si applica nel caso di prescrizione di stupefacenti oppure di farmaci per la terapia del dolore che sono prescritti sui relativi modelli speciali. MODELLO VALIDO PER TUTTI I TIPI DI PRESCRIZIONE a.

Dettagli

Ordinanza del DFI sulla cartella informatizzata del paziente

Ordinanza del DFI sulla cartella informatizzata del paziente rdinanza del DI sulla cartella informatizzata del paziente (CIP-DI) Versione del 04.07.2017 per la consultazione Modifica del dicembre 2017 Il Dipartimento federale dell interno (DI), ordina: I L'allegato

Dettagli

Il Sistema Informativo Regionale

Il Sistema Informativo Regionale Il Sistema Informativo Regionale basato sul sistema LuMiR da dove abbiamo iniziato le soluzioni ICT devono garantire in modo organico, ad operatori e pazienti, l'acquisizione, la trasmissione, la disponibilità

Dettagli

A. Nesti A.M. Fino. L. Genovesi REGISTRO DELLE MODIFICHE REVISIONE DESCRIZIONE EMISSIONE. 00 Prima emissione 06/05/2014

A. Nesti A.M. Fino. L. Genovesi REGISTRO DELLE MODIFICHE REVISIONE DESCRIZIONE EMISSIONE. 00 Prima emissione 06/05/2014 Codice: CERTQUAL.TT.SOMO141 TITOLO DOCUMENTO: TIPO DOCUMENTO: EMESSO DA: Operativo Addendum Documento di supporto ai servizi per le Banche facenti parte del Gruppo Cariparma Crédit Agricole Telecom Italia

Dettagli

I documenti clinici e dati sanitari nel Fascicolo Sanitario Ing. Chiara Basile

I documenti clinici e dati sanitari nel Fascicolo Sanitario Ing. Chiara Basile I documenti clinici e dati sanitari nel Fascicolo Sanitario Ing. Chiara Basile I Contenuti del Fascicolo Sanitario Elettronico Nucleo minimo Altri Documenti a) dati identificativi e amministrativi dell'assistito;

Dettagli

FAQ - Integrazioni Servizi Sistema Informativo Fascicolo Sanitario Elettronico (F.S.E.) della Regione Lazio

FAQ - Integrazioni Servizi Sistema Informativo Fascicolo Sanitario Elettronico (F.S.E.) della Regione Lazio FAQ - Integrazioni Servizi Sistema Informativo Fascicolo Sanitario Elettronico (F.S.E.) della Regione Lazio 1 Status del Documento Rev. Data Descrizione Modifica 1 23/05/2017 Prima versione 2 INDICE 1

Dettagli

Matera, 15 giugno 2010 Auditorium San Giuseppe Moscati Ospedale di Matera

Matera, 15 giugno 2010 Auditorium San Giuseppe Moscati Ospedale di Matera Matera, 15 giugno 2010 Auditorium San Giuseppe Moscati Ospedale di Matera Unita di Pronto Soccorso e Osservazione Breve Direttore C.Sinno Rel. Inf..DELLE CAVE FLORA M. 15 GIUGNO 2010 Il sistema di "triage"

Dettagli

La documentazione a supporto della cartella clinica

La documentazione a supporto della cartella clinica La documentazione a supporto della cartella clinica Alberto Cazzulani Dipartimento di Radiologia A.O. Franco Vimercati A.O. Fatebenefratelli ed Oftalmico / P Dipartimento di Radiologia A.O. Salvini Garbagnate

Dettagli

HL7 Italia. Dominio AMPRPA Patient Topic Specifica di Localizzazione Italiana. (IT Realm)

HL7 Italia.  Dominio AMPRPA Patient Topic Specifica di Localizzazione Italiana. (IT Realm) www.hl7italia.it Dominio AMPRPA Patient Topic Specifica di Localizzazione Italiana (IT Realm) Standard informativo Versione 1.2 Febbraio 2011 HL7 Version 3 Standard, 2010 Health Level Seven International.

Dettagli

Allegato C. Servizio di messa a disposizione dei dati del Sistema TS

Allegato C. Servizio di messa a disposizione dei dati del Sistema TS Allegato C Servizio di messa a disposizione dei dati del 1 INDICE 1. INTRODUZIONE 3 2. SERVIZI PER LA MESSA A DISPOSIZIONE AI SISTEMI REGIONALI DI FSE DELLE INFORMAZIONI RESE DISPONIBILI DAL SISTEMA 4

Dettagli

Piano dei Test e Collaudo del software Titolo Documento

Piano dei Test e Collaudo del software Titolo Documento Controllo delle copie Il presente documento, se non preceduto dalla pagina di controllo identificata con il numero della copia, il destinatario, la data e la firma autografa del Responsabile della Documentazione,

Dettagli

GESTIONE E ORGANIZZAZIONE DELLA DOCUMENTAZIONE DEL SISTEMA GESTIONE QUALITÀ

GESTIONE E ORGANIZZAZIONE DELLA DOCUMENTAZIONE DEL SISTEMA GESTIONE QUALITÀ Pagina 1 di 5 DOCUMENTAZIONE DEL SISTEMA GESTIONE QUALITÀ INDICE 1. SCOPO 2. CAMPO DI APPLICAZIONE 3. RESPONSABILITA 4. DESCRIZIONE DELLE ATTIVITÀ 5. INDICATORI DI PROCESSO 6. RIFERIMENTI 7. ARCHIVIAZIONE

Dettagli

Modello restituzione SDO

Modello restituzione SDO Modello restituzione SDO Campo di applicazione Il presente documento si applica ai flussi di competenza anno 2016 e successivi; le modalità di restituzione relative alla competenze anteriori al 2016 rimangono

Dettagli

Convegno Annuale AISIS

Convegno Annuale AISIS Convegno Annuale AISIS ICT Masterplan 2016-2018 Piano per lo sviluppo strategico delle tecnologie informatiche dell Azienda Sanitaria dell Alto Adige Ing. Christian Steurer Cagliari, 13 e 14 ottobre 2016

Dettagli

Carta Regionale dei Servizi

Carta Regionale dei Servizi Carta Regionale dei Servizi Alberto Daprà Vice Presidente Lombardia Informatica 18/04/2012 Aspetti generali - Carta Regionale dei Servizi Un importante ed innovativo strumento di dialogo con la Pubblica

Dettagli

PIANO DELLE ATTIVITÀ

PIANO DELLE ATTIVITÀ giunta regionale 9^ legislatura ALLEGATOA alla Dgr n. 2703 del 29 dicembre 2014 pag. 1/6 PIANO DELLE ATTIVITÀ Si riporta di seguito il nuovo piano delle susseguente alla redazione del piano di progetto

Dettagli

REGIONE BASILICATA UFFICIO S. I. R. S.

REGIONE BASILICATA UFFICIO S. I. R. S. UFFICIO S. I. R. S. Modellazione dati Id Base Dati CONTROLLO DEL DOCUMENTO APPROVAZIONI Redatto da: Approvato da: Data Autore Ing. Vincenzo Fiore VARIAZIONI Versione prec. Data Autore Paragrafi modificati

Dettagli

IL FASCICOLO SANITARIO ELETTRONICO IN REGIONE CALABRIA 3

IL FASCICOLO SANITARIO ELETTRONICO IN REGIONE CALABRIA 3 Con il Patrocinio della Regione Calabria Con il Patrocinio della Regione Calabria IVA t IL FASCICOLO SANITARIO ELETTRONICO IN REGIONE CALABRIA 3 La parola ai protagonisti Dr. Scillone 24 Luglio 2013 T-Hotel

Dettagli

SPECIFICA TECNICA N relativa alle. Caratteristiche tecniche dell interconnessione tra reti di telecomunicazioni

SPECIFICA TECNICA N relativa alle. Caratteristiche tecniche dell interconnessione tra reti di telecomunicazioni SPECIFICA TECNICA N. 763-3 relativa alle Caratteristiche tecniche dell interconnessione tra reti di telecomunicazioni Trattamento del Routing Number (RgN) per l accesso ai servizi di Rete Intelligente

Dettagli

IL FASCICOLO SANITARIO ELETTRONICO

IL FASCICOLO SANITARIO ELETTRONICO PALERMO 9 OTTOBRE 2018 GIUSEPPE CESARETTI GIANNI DI BIASE Società Generale d Informatica SOGEI S.p.A. INDICE DEGLI ARGOMENTI 1. STORIA DEL FSE 2. FAQ: domande e risposte per introdurre l argomento 3. IL

Dettagli

Nuovo Sistema Informativo. Bolzano, 29 Febbraio 2016

Nuovo Sistema Informativo. Bolzano, 29 Febbraio 2016 Nuovo Sistema Informativo Bolzano, 29 Febbraio 2016 Nuovo Sistema Informativo Medici cure primarie Cittadini / e Tutte le unità operative e i reparti dell Azienda Sanitaria Medici ospedalieri e del territorio

Dettagli

Gestione del protocollo informatico con OrdineP-NET

Gestione del protocollo informatico con OrdineP-NET Ordine dei Farmacisti Della Provincia di Livorno Gestione del protocollo informatico con OrdineP-NET Manuale gestore DT-Manuale gestore Gestione del protocollo informatico con OrdineP-NET (per utenti servizio

Dettagli

SCHEDA DESCRITTIVA DEL SIP PER LA TIPOLOGIA DOCUMENTARIA CUD. [versione 1.0 del 6/6/2014]

SCHEDA DESCRITTIVA DEL SIP PER LA TIPOLOGIA DOCUMENTARIA CUD. [versione 1.0 del 6/6/2014] SCHEDA DESCRITTIVA DEL P PER LA TIPOLOGIA DOCUMENTARIA [versione 1.0 del 6/6/2014] Estratto da LINEE GUIDA PER LA REALIZZAZIONE DEI PACCHETTI DI VERSAMENTO (P) 1. Descrizione della tipologia documentaria

Dettagli

MANUALE DELLA QUALITÀ SEZIONE 4.2: REQUISITI RELATIVI ALLA DOCUMENTAZIONE

MANUALE DELLA QUALITÀ SEZIONE 4.2: REQUISITI RELATIVI ALLA DOCUMENTAZIONE REV. 00 Pagina 1/4 MANUALE DELLA QUALITÀ Rif.to: UNI EN ISO 9001:2008 PARTE 4: SISTEMA DI GESTIONE PER LA QUALITÀ SEZIONE 4.2: REQUISITI RELATIVI ALLA DOCUMENTAZIONE SOMMARIO A Scopo B Documenti del SQ

Dettagli

HL7 Italia

HL7 Italia www.hl7italia.it Implementation Guide Clinical Document Architecture (CDA) Rel. 2 Referto di Medicina di Laboratorio (IT Realm) Standard Informativo Versione 1.1 Ballot HL7 Version 3 Standard, 2015 Health

Dettagli

Dipartimento dei Vigili del Fuoco del Soccorso Pubblico e della Difesa Civile

Dipartimento dei Vigili del Fuoco del Soccorso Pubblico e della Difesa Civile ALLEGATO 3 GENERAZIONE DEL MESSAGGIO CAP DAL FORM DI SO115 DEL CORPO NAZIONALE DEI VIGILI DEL FUOCO (CNVVF) Mediante l implementazione di un opportuno substrato software, è possibile generare messaggi

Dettagli

Compilazione delle schede informatiche

Compilazione delle schede informatiche Compilazione delle schede informatiche a) L operatore della deve compilare i seguenti campi: Scheda evento: numero telefonico del chiamante; numero telefonico per contattare l assistito, qualora si trovi

Dettagli

Motore Sanità Trieste 20 giugno Fascicolo Sanitario: middleware o sistema dedicato? Il Modello Veneto

Motore Sanità Trieste 20 giugno Fascicolo Sanitario: middleware o sistema dedicato? Il Modello Veneto Motore Sanità Trieste 20 giugno 2014 Fascicolo Sanitario: middleware o sistema dedicato? Il Modello Veneto Ing. Lorenzo Gubian Settore Sistema Informatico SSR Area Sanità e Sociale Regione Veneto Norme

Dettagli

INTERFACCIAMENTO CON GLI APPLICATIVI DELLA RETE MMG

INTERFACCIAMENTO CON GLI APPLICATIVI DELLA RETE MMG PIANO DI TEST DEL MODULO APPLICATIVO DI INTERFACCIAMENTO CON GLI APPLICATIVI DELLA RETE MMG PROGETTO ESECUTIVO DEFINITIVO Accordo di Programma Quadro "Sviluppo della Società dell'informazione nella Regione

Dettagli

Alfonso Maurizio Urso (CNR-ICAR) Fascicolo Sanitario Elettronico e salute sostenibile. Roma - 25 maggio 2017

Alfonso Maurizio Urso (CNR-ICAR) Fascicolo Sanitario Elettronico e salute sostenibile. Roma - 25 maggio 2017 Innovazione tecnologica e salute sostenibile Alfonso Maurizio Urso (CNR-ICAR) Fascicolo Sanitario Elettronico e salute sostenibile Roma - 25 maggio 2017 Cosa è il Fascicolo Sanitario Elettronico Il Fascicolo

Dettagli

Il Fascicolo Sanitario Elettronico

Il Fascicolo Sanitario Elettronico Il Fascicolo Sanitario Elettronico Dott.ssa Antonella Di Giacinto, Dott.ssa Maria Pia Randazzo Ufficio Coordinamento e sviluppo NSIS Direzione generale del Sistema informativo Ministero del Lavoro, della

Dettagli

SCHEDA DESCRITTIVA DEL SIP PER LA TIPOLOGIA DOCUMENTARIA MODELLO 770. [versione 1.0 del 17/6/2014]

SCHEDA DESCRITTIVA DEL SIP PER LA TIPOLOGIA DOCUMENTARIA MODELLO 770. [versione 1.0 del 17/6/2014] SCHEDA DESCRITTIVA DEL P PER LA TIPOLOGIA DOCUMENTARIA MODELLO 770 [versione 1.0 del 17/6/2014] Estratto da LINEE GUIDA PER LA REALIZZAZIONE DEI PACCHETTI DI VERSAMENTO (P) MODELLO 770 1. Descrizione della

Dettagli

FSE Fascicolo Sanitario Elettronico. Piano dei test. Servizio RegistraEpisodio con invio referti

FSE Fascicolo Sanitario Elettronico. Piano dei test. Servizio RegistraEpisodio con invio referti FSE Fascicolo Sanitario Elettronico Servizio RegistraEpisodio con invio referti Pagina 1 di 78 STATO DELLE VARIAZIONI VERSIONE PARAGRAFO O DESCRIZIONE DELLA VARIAZIONE PAGINA 1 Tutto il documento Versione

Dettagli

STRUTTURA E METADATI DELL UNITÀ DOCUMENTARIA. Tipologia CONTRATTO

STRUTTURA E METADATI DELL UNITÀ DOCUMENTARIA. Tipologia CONTRATTO STRUTTURA E METADATI DELL UNITÀ DOCUMENTARIA Tipologia CONTRATTO Indice INDICE... 2 INTRODUZIONE... 3 1. STRUTTURA DELL UNITÀ DOCUMENTARIA... 4 2. METADATI... 5 2.1. Metadati di identificazione... 5 2.2.

Dettagli

FSE Fascicolo Sanitario Elettronico. Piano dei test. Servizio RegistraEpisodio senza invio referti

FSE Fascicolo Sanitario Elettronico. Piano dei test. Servizio RegistraEpisodio senza invio referti FSE Fascicolo Sanitario Elettronico Servizio RegistraEpisodio senza invio referti Pagina 1 di 76 STATO DELLE VARIAZIONI VERSIONE PARAGRAFO O DESCRIZIONE DELLA VARIAZIONE PAGINA 1 Tutto il documento Versione

Dettagli

Mercadante Raffaella LA CARTELLA INFERMIERISTICA

Mercadante Raffaella LA CARTELLA INFERMIERISTICA Mercadante Raffaella LA CARTELLA INFERMIERISTICA CARTELLA INFERMIERISTICA STRUMENTO INFORMATIVO utile per PROGETTARE GESTIRE L INTERVENTO ASSISTENZIALE VALUTARE COMUNICARE TRA GLI OPERATORI DOCUMENTARE

Dettagli

La progettazione concettuale

La progettazione concettuale PROGETTAZIONE La progettazione concettuale Sintesi tra la visione degli utenti e la visione dei progettisti. I progettisti devono essere certi di aver compreso esattamente e completamente le esigenze degli

Dettagli

Specifiche di interfaccia applicativa per l invio delle pratiche protesti

Specifiche di interfaccia applicativa per l invio delle pratiche protesti ALLEGATO A Specifiche di interfaccia applicativa per l invio delle pratiche protesti come da DM 14 novembre 2018 art. 2 comma 5 Versione 1.0 Maggio 2019 Indice 1 Introduzione al documento... 3 1.1 Scopo

Dettagli

Struttura Dati Popolamento INA

Struttura Dati Popolamento INA Struttura Dati Popolamento INA Documento: INA-SAIA_Struttura_Dati_e_Validazione_Popolamento_INA_v3.02 Versione: v3.02 Stato: Emesso Data: 22/03/2012 Deliverable di riferimento: Cronologia Versioni Versione

Dettagli

Documento Tecnico Operativo. Invio PEC On Line - IPOL

Documento Tecnico Operativo. Invio PEC On Line - IPOL Invio PEC On Line - IPOL Il documento descrive le funzionalità operative e le Oggetto Versione modalità di utilizzo dell applicativo Invio PEC On Line che permette di inviare messaggi di Posta Elettronica

Dettagli

La CC è la raccolta organica e funzionale dei dati attinenti ai singoli casi di ricovero:

La CC è la raccolta organica e funzionale dei dati attinenti ai singoli casi di ricovero: DI FATTO La CC è la raccolta organica e funzionale dei dati attinenti ai singoli casi di ricovero: identificazione della struttura di ricovero generalità dell assistito caratteristiche del ricovero anamnesi

Dettagli

LA DEFINIZIONE DELLE PROPRIETÀ. proprietà 1

LA DEFINIZIONE DELLE PROPRIETÀ. proprietà 1 LA DEFINIZIONE DELLE PROPRIETÀ proprietà 1 proprietà L alternativa alla proprietà opzionale è la proprietà totale (1,m) (n,m) per la quale bisognerà specificare separatamente dallo schema l obbligatorietà

Dettagli

INFORMATICA SANITARIA Domande ed Esercizi di Preparazione all Esame (Parti 1-4)

INFORMATICA SANITARIA Domande ed Esercizi di Preparazione all Esame (Parti 1-4) Università degli Studi di Padova Corso di Laurea Specialistica in Bioingegneria A.A. 2006-2007 2007 INFORMATICA SANITARIA Domande ed Esercizi di Preparazione all Esame (Parti 1-4) Giovanni Sparacino Dipartimento

Dettagli

Gestione della privacy in un sistema informativo ospedaliero ed erogazione di nuovi servizi

Gestione della privacy in un sistema informativo ospedaliero ed erogazione di nuovi servizi E. O. Ospedali Galliera Genova Gestione della privacy in un sistema informativo ospedaliero ed erogazione di nuovi servizi Responsabile SC Sistemi Informativi E Telecomunicazioni carlo.berutti@galliera.it

Dettagli

Ed. Febbraio 2018 MODALITÀ DI GENERAZIONE DEL BARCODE SUI PLICHI

Ed. Febbraio 2018 MODALITÀ DI GENERAZIONE DEL BARCODE SUI PLICHI Ed. Febbraio 2018 MODALITÀ DI GENERAZIONE DEL BARCODE SUI PLICHI 1 INDICE 1 DOCUMENTI CITATI... 2 2 SCOPO E CAMPO DI APPLICAZIONE... 3 3 TERMINI E DEFINIZIONI... 4 4 SPECIFICHE TECNICHE... 5 4.1 Generalità...

Dettagli

Progetto Tessera Sanitaria. Fascicolo Sanitario Elettronico. Infrastruttura Nazionale per l Interoperabilità. Servizi di Sussidiarietà

Progetto Tessera Sanitaria. Fascicolo Sanitario Elettronico. Infrastruttura Nazionale per l Interoperabilità. Servizi di Sussidiarietà Servizi di Sussidiarietà art. 12 - comma 15-ter D.L. 179/2012 comma 382 della Legge di Bilancio 2017 Art. 12 del d.l. 179/2012, convertito, con modificazioni, dalla legge n. 221/2012. 1. ll è l insieme

Dettagli

MANUALE D USO OPERATORE ECONOMICO

MANUALE D USO OPERATORE ECONOMICO MANUALE D USO OPERATORE ECONOMICO Aggiornato a gennaio 2019 Manuale GPA Operatore Economico Pagina 0 Sommario Sommario... 1 1. Registrazione nuovo operatore economico... 2 2. Registrazione Raggruppamento

Dettagli

U N I V E R S I T À D E G L I S T U D I D I S A L E R N O

U N I V E R S I T À D E G L I S T U D I D I S A L E R N O U N I V E R S I T À D E G L I S T U D I D I S A L E R N O Standard di codifica per le entità didattiche Versione 10.0 Autore Stato Revisore Ufficio Pianificazione e Sviluppo Approvato P.Casalaspro Data

Dettagli

Servizio AFT Umbria. Manuale Advmednet

Servizio AFT Umbria. Manuale Advmednet Servizio AFT Umbria Manuale Advmednet Le Aggregazioni Funzionali Territoriali (AFT) sono forme organizzative della Medicina Generale. I medici di medicina generale partecipano obbligatoriamente alle aggregazioni

Dettagli

INTRODUZIONE INTERFACCIA UTENTE SCENARIO D INTEGRAZIONE CON L ANAGRAFE REGIONALE FILTRI DI RICERCA MINIMI RICHIESTI...

INTRODUZIONE INTERFACCIA UTENTE SCENARIO D INTEGRAZIONE CON L ANAGRAFE REGIONALE FILTRI DI RICERCA MINIMI RICHIESTI... !!!" "!!"!# $! !!!$ 1. INTRODUZIONE... 4 1.1. INTERFACCIA UTENTE... 5 1.2. SCENARIO D INTEGRAZIONE CON L ANAGRAFE REGIONALE... 10 1.3. FILTRI DI RICERCA MINIMI RICHIESTI... 11 2. MODALITA DI RICERCA E

Dettagli

SCHEDA DESCRITTIVA DEL SIP PER LA TIPOLOGIA DOCUMENTARIA LIBRO GIORNALE. [versione 1.0 del 17/6/2014]

SCHEDA DESCRITTIVA DEL SIP PER LA TIPOLOGIA DOCUMENTARIA LIBRO GIORNALE. [versione 1.0 del 17/6/2014] SCHEDA DESCRITTIVA DEL P PER LA TIPOLOGIA DOCUMENTARIA LIBRO GIORNALE [versione 1.0 del 17/6/2014] Estratto da LINEE GUIDA PER LA REALIZZAZIONE DEI PACCHETTI DI VERSAMENTO (P) LIBRO GIORNALE 1. Descrizione

Dettagli

Regolamento Europeo 2016/679 del Protezione delle persone fisiche con riguardo al trattamento dei dati personali

Regolamento Europeo 2016/679 del Protezione delle persone fisiche con riguardo al trattamento dei dati personali Regolamento Europeo 2016/679 del 27.4.2016 Protezione delle persone fisiche con riguardo al trattamento dei dati personali Definizione di un «Codice di Condotta» per la sanità Fabrizio Massimo Ferrara

Dettagli