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

Dimensione: px
Iniziare la visualizzazioe della pagina:

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

Transcript

1 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 II - SI-II-09 stazione appaltante: R.T.I. aggiudicatario: DEDALUS S.p.A TELECOM ITALIA S.p.A. Pagina 1/ 223

2 E Standard Specification for Continuity of Care Record is copyright 2006 ASTM International. All rights reserved. Used by permission for the purpose of composing this document. Anyone seeking to implement E must have acquired rights from ASTM International and must adhere to the tenets of their license agreement. Pagina 2/ 223

3 INDICE 1 DEFINIZIONI, ACRONIMI ED ABBREVIAZIONI Acronimi: Abbreviazioni: Convenzioni grafiche e sintattiche RIFERIMENTI Premessa INTRODUZIONE DataSet Clinico Potenzialità Destinatari del Patient Summary Scenario Futuro Modalità Operative CONTENUTO INFORMATIVO Sezione riservata ai dati anagrafici del paziente (<anagrafica>) Lista Riferimenti Autore del documento HEADER DEL PATIENT SUMMARY Root del documento Dominio del documento Identificativo CDA-R Pagina 3/ 223

4 5.4 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 Dati Anagrafici del paziente Codici identificativi del paziente... Errore. Il segnalibro non è definito Dati anagrafici del paziente Tutore legale Autore e autenticatore Autore Firmatario del documento Custode <representedcustodianorganization>... Errore. Il segnalibro non è definito Contatti del paziente Parenti Emergenza Assistenza Malati ed Anziani Note implementative Evento clinico documentato Destinatario del documento: <informationrecipient> Altre Informazioni BODY DEL PATIENT SUMMARY Lista Allergie Template CCD Descrizione Reazione... Errore. Il segnalibro non è definito Descrizione Reazioni (Codificata)... Errore. Il segnalibro non è definito Vincoli aggiuntivi... Errore. Il segnalibro non è definito Descrizione Reazioni (Non Codificata)... Errore. Il segnalibro non è definito Stato dell allergia... Errore. Il segnalibro non è definito. Pagina 4/ 223

5 6.1.4 Commenti... Errore. Il segnalibro non è definito Vincoli Aggiuntivi... Errore. Il segnalibro non è definito Esempio... Errore. Il segnalibro non è definito. 6.2 Lista Problemi SOVP Template CCD Modalità di gestione dei problemi strutturati (folder) Problema Dettagli problema Vincoli aggiuntivi Stato clinico Stato di Salute Gestione episodicità Riferimenti Interni Organi Mancanti Esempio Prescrizioni Riabilitative Prescrizione Prestazione Riabilitativa Prescrizioni Farmaci Prescrizione Farmaco Template CCD Descrizione Terapia Posologia Dettagli Farmaco Ragione Esempio Vaccinazioni Vaccinazione Template CCD Vaccinazione Vincoli aggiuntivi Esempio Narrative Block Coded Entry Lista Rilevazioni Rilevazione Rilevazione Generica Template CCD Esame di Laboratorio, Esame Strumentale, Visita Specialistica Template CCD Esame strumentale Template CCD Pagina 5/ 223

6 Dettagli Procedura Vincoli aggiuntivi Esempio Visita specialistica Template CCD Dettagli Incontro Vincoli aggiuntivi Performer Luogo Esempio Esame di Laboratorio Template CCD Result Organizer Dettaglio Osservazione Esempio Dati Antropometrici Template CCD Esempio di uso Pressione Template CCD Vincoli di conformance Esempio di uso Stile di Vita Template CCD Esempio Narrative Block Costante Biologica Gruppo Sanguigno Template CCD Organi Mancanti Protesi Template CCD Esempi Narrative_Block Anamnesi Familiare Template CCD Familiarità Vincoli aggiuntivi Dettagli su familiarità Vincoli aggiuntivi Causa di morte Informazioni sull età Esempio Narrative Block Pagina 6/ 223

7 Familiarità (Family History Organizer) TABELLE Codifica Istat Regioni Codici Istat Province Codifica Comuni d Italia Codifica ASL Entità che partecipano agli atti (Participation Function) Parentele (PersonalRelationshipRoleType) Unità di misura Tipologie di Encounter (ActEncounterCode) Pagina 7/ 223

8 Revisioni Nella tabella che segue sono riportate le indicazioni sugli aggiornamenti applicati al documento Versione Data Descrizione /11/2007 Prima stesura del documento /07/2008 Aggiornamento a seguito dell incontro di armonizzazione presso il DIT Pagina 8/ 223

9 1 Definizioni, Acronimi ed Abbreviazioni 1.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 OID Object Identifier Struttura dati definita da ISO PS Patient Summary SSI Scheda Sanitaria Individuale 1.2 Abbreviazioni: Sigla e.g. i.e. Esteso Exempli gratia (per esempio) Id est (cioè) Pagina 9/ 223

10 1.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 10/ 223

11 2 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. Pagina 11/ 223

12 2.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. 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 L accordo collettivo nazionale per la disciplina dei rapporti con i medici di medicina generale - ACN e successive modificazioni, contempla l uso da parte dei mmg/pls di uno strumento definito Scheda Sanitaria Individuale per contenere la storia clinica del paziente. Solo da essa si può partire per individuare il data set del Patient Summary; si rimanda all apposito Deliverables WP 21.2 per gli ulteriori approfondimenti per individuare i diversi scenari d utilizzo. Per ciò che concerne l organizzazione del documento: il capitolo 4 Contenuto Informativo sintetizza il contenuto informativo del patient Patient Summary. Il capitolo 5 "Header del Patient Summary riporta le specifiche dell header del CDA, conforme al template CCD, usato per veicolare il Patient Summary. Include vincoli aggiuntivi imposti dalle presenti specifiche. Il capitolo 6 "Body del Patient Summary fornisce una descrizione di dettaglio su come mappare gli elementi non di tipo anagrafico presenti nella struttura dati del Patient Summary all interno del body del CDA. Il capitolo 7 - Tabelleriporta il dettaglio di alcune codifiche usate per il Patient Summary Pagina 12/ 223

13 3 Introduzione Le componenti dati che determineranno il Patient Summary 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: Il Patient Summary è un documento informatico sanitario, firmato digitalmente e contenuto nel Fascicolo Sanitario Elettronico, che riassume la storia clinica del paziente e la situazione corrente. E creato ed aggiornato dal MMG ogni qualvolta intervengono cambiamenti da lui ritenuti rilevanti ai fini della storia del paziente. Contiene un set predefinito di dati clinici significativi per l emergenza (emergency data set). Dal punto di vista funzionale il Patient Summary (P.S.): conterrà i link ai referti che il MMG/PLS ritiene possano migliorare la comprensione del quadro clinico; non potrà essere creato in maniera automatica a partire dal FSE, per l assenza del dato che identifica gli autori responsabili del popolamento del documento. Pagina 13/ 223

14 3.1 DataSet Clinico Poter disporre del PS consentirà di entrare in possesso di quella che nel tempo è stata l unica modalità di scambio dati fra i mmg/pls e gli operatori sanitari coinvolti nel processo di continuità assistenziale dell assistito: la Lettera al Collega. Lo strumento informatico offre, inoltre, la comodità di disporre di tali informazioni in qualunque momento, sempre aggiornate all ultimo allineamento effettuato. I principali dati clinici oggetto di interesse riguarderanno: Dati del Medico responsabile del Paziente; Anagrafica Assistito; Allergie; Lista dei problemi, sia correntemente attivi che conlcusi e non più attivi ; Prescrizioni Riabilitative; Prescrizioni Presidi; Prescrizioni Terapeutiche; Certificati medici; Vaccinazioni; Stili di Vita (Attività Fisica, Fumo, Alcool, ); Pressione Parametri bioumorali ed antropometrici; Dettagli sul contenuto informativo richiesto per il PS sono descritti nella sezione 4- Contenuto Informativo Pagina 14/ 223

15 3.2 Potenzialità E facilmente intuibile come i dati contenuti all interno del PS possano essere determinanti per il processo di continuità assistenziale dell assistito. La cooperazione clinica non può, nell ottica della condivisione, non disporre di tali informazioni che danno un evidente vantaggio sia alla classe medica che all assistito stesso. Questo è un percorso che oramai i fornitori di Sistemi Informativi Sanitari devono tenere sempre più in considerazione per l integrazione dei sistemi in essere e per quelli che implementeranno nel tempo. Il P.S., per i dati in esso contenuto, può soddisfare le richieste di conoscenza dei dati rilevanti della storia clinica dell assistito facendo sì che nell immediato si possa venire a conoscenza delle informazioni essenziali determinanti per la diagnosi e l anamnesi del paziente che si sta prendendo in cura. Il PS essendo la sintesi del quadro clinico dell assistito caratterizzato da immediatezza di consultazione e fruizione sarà usato prevalentemente in ambito DEU, come illustrato nella figura di seguito. Tale meccanismo è a disposizione di qualsiasi operatore in possesso di uno strumento SW che soddisfi le regole di funzionamento dell FSE, compatibilmente con le disposizioni in materia di tutela della riservatezza dei dati sensibili. Operatori come lo Specialista di Reparto, lo Specialista di Ambulatorio, la Guardia Medica, etc. possono entrare in possesso dei dati del Paziente semplicemente acquisendo la SSI contenuta nel Fascicolo Sanitario Elettronico. Pagina 15/ 223

16 3.3 Destinatari del Patient Summary Lo scambio delle informazioni contenute nel PS tra i medici di famiglia, i colleghi ospedalieri, di guardia medica, o qualunque altro operatore sanitario intervenga nel processo di cura del paziente, può assicurare la continuità assistenziale dell assistito, indipendentemente dal medico che lo prende in cura; ciò consentirà di offrire un servizio al cittadino e di ottimizzare anche la spesa sanitaria, oggi sempre più oggetto di attenzione; si pensi agli accertamenti che a volte devono essere ripetuti se sconosciuti dal medico che al momento sta effettuando l anamnesi. Disporre del PS attraverso i sistemi informativi sanitari che ne consentano l accesso per la consultazione può dar risposta a variegate situazioni: per la Medicina di Gruppo o di Rete in orari in cui il proprio medico non è disponibile; per i pazienti gestiti da più professionisti che seguono l evolversi di patologie croniche; anziani in regime di assistenza domiciliare o residenziale; supporto al processo diagnostico in corso di consulenza specialistica o di teleconsulto; continuità informativa da MMG a ospedale; uso per ricerche epidemiologiche; tutto ciò ancor più avvalorato se i professionisti interessati seguono un piano di cura condiviso, a partire da un percorso assistenziale di riferimento predefinito in base all'evidenza clinica. Pagina 16/ 223

17 3.4 Scenario Futuro I dati che conterrà la struttura del PS consentiranno di rendere disponibili le informazioni per quei contatti definiti inattesi, quindi di emergenza, oltre ad offrire, ovviamente, anche tale disponibilità di informazioni per la continuità di cura nelle vie cliniche comuni. Gli accessi al servizio sanitario nazionale per le situazioni di emergenza, necessitano di conoscere la storia clinica del Paziente poiché a volte è il paziente stesso a non poter presentare in maniera esaustiva la propria storia (problemi, allergie, farmaci continuativi, correnti...). Con la disponibilità del PS i pazienti che necessitano di visite specialistiche o che richiedono accessi a strutture sanitarie possono presentarsi presso le strutture consapevoli del fatto che la propria storia clinica, senza eventuali omissioni da parte del paziente per dimenticanza, sia completa. Pagina 17/ 223

18 3.5 Modalità Operative L obiettivo di favorire il processo di continuità assistenziale dell assistito può venire meno se i dati presenti nel PS non sono completi o non vengono resi disponibili. Ciò può avvenire per due motivi: mancato inserimento delle informazioni da parte del medico; carenza strutturale della cartella ambulatoriale in uso dal medico di medicina generale o dal pediatra di libera scelta, che ne impedisce di fatto l inserimento dei dati previsti. Nel primo caso occorre sensibilizzare gli operatori sanitari coinvolti affinché il successo dei progetti che prevedono lo scambio di tali informazioni non venga meno. Lo scoglio da superare è quello di non snaturare la professionalità del medico obbligandolo a dedicare parte del suo tempo all inserimento dei dati distraendolo dal paziente da curare. In particolare è necessario che gli strumenti SW siano user-friendly, facilmente utilizzabili prevedendo automatismi che limitino e facilitino l inserimento, l acquisizione e la messa a disposizione dei dati che costituiranno il P.S. Mentre, nel secondo caso, questo processo potrà risentire molto dalle iniziative che le aziende potranno intraprendere per migliorare i propri software per consentire alle cartelle di disporre di tutti quegli strumenti necessari a completare la struttura del PS stesso. In mancanza di tali dati è inevitabile che la completezza del PS viene meno e chi consulterà le informazioni ne risentirà qualitativamente. In conclusione si evidenzia che il ciclo di vita del documento, in particolare la revisione (modifica), comporta l obsolescenza del precedente. Pagina 18/ 223

19 4 Contenuto Informativo Nel presente capitolo è descritto in forma strutturata il contneuto informativo che il documento di Patient Summary dovrebbe riportare. La struttura principale prevede le seguenti tipologie di informazioni: Per ulteriori sulle informazioni di tipo anagrafico e sull autore si rimanda ai successivi sottoparagrafi. Dettagli sui rimanenti elementi sono invece descritti nel capitolo 6 Body del Patient Summary Pagina 19/ 223

20 4.1 Sezione riservata ai dati anagrafici del paziente (<anagrafica>) Tag Principal e Anagraf ica Tag Riferimento Descrizione campo Dizionario identificativi Identificativo dell assistito, di tipo Multiplo, ogni fonte di origine del dato può inserire il proprio identificativo usato all interno del proprio N/A sistema informatico cognome Cognome assistito N/A X nome Nome assistito N/A X sesso dizionario Administr ativegen dercode datanascita Data nascita assistito N/A X codfiscaleassistit Codice Fiscale N/A X o codcomunenasci ta Codice ISTAT comune nascita ISTAT comunenascita Descrizione comune nascita ISTAT indirizzoresidenza Indirizzo residenza assistito N/A capresidenza Cap residenza assistito Poste codcomuneresid Codice ISTAT residenza assistito Italiane ISTAT enza comuneresidenza Descrizione comune residenza ISTAT frazioneresidenza Descrizione località/frazione residenza N/A Ob bl. X siglaprovinciaresi denza Sigla provincia residenza Agenzia del Territorio note N/A listariferimenti Riferimenti per Eventuali Contatti N/A In grassetto sono riportati gli elementi riconducibili direttamente alla sezione anagrafica (<recordtarget>) dell'header del PS La listariferimenti verrà modellata nella sezione <partecipant> dell'header. Pagina 20/ 223

21 4.1.1 Lista Riferimenti Rete di Medici di Medicina Generale Progetto Esecutivo La lista dei riferimenti fornisce una serie di informazioni che possono far raggiungere l assistito per eventuali comunicazioni. Riferimento Il dato priorità conterrà un valore numerico che consentirà di ordinare l elenco dei riferimenti in base ad un ordine prioritario di consultazione/chiamata. Il Raggruppamento Codice potrà contenere diverse tipologie di informazioni come ad esempio il grado di parentele del contatto es. Padre, Madre, Convivente, mentre il dato descrizione conterrà i valori relativi alla tipologia precedentemente indicata esempio il numero di telefono cellulare, abitazione Tag Principale Tag Riferimento Descrizione campo Dizionario Obbl. riferimenti priorità Priorità di consultazione/chiamata Da 1 a n nominativo Nominativo Persona o Ente N/A X indirizzo Indirizzo Persona o Ente N/A lista Elenco N/A listatelefoni Elenco Telefoni N/A note N/A Pagina 21/ 223

22 I riferimenti saranno modellati nel CCD attraverso elementi di tipo <participant> attraverso cui potranno essere identificati parenti, contatti di emergenza, etc etc. Pagina 22/ 223

23 4.2 Autore del documento L elemento <autore> include le informazioni relative al medico titolare dei dati del paziente che mette a disposizione tali informazioni. Tag Principale Tag Riferimento Descrizione campo Dizionario Obbl. codfiscalemedico Codice Fiscale del Medico titolare delle informazioni presenti nel P.S. N/A X cognomemedico Cognome del Medico titolare delle informazioni presenti nel P.S. N/A X autore nomemedico Nome del Medico titolare delle informazioni presenti nel P.S. N/A X codregionalemedico codaslmedico Codice Regionale del Medico titolare delle informazioni presenti nel P.S. Codice Asl di convenzione del Medico titolare delle informazioni presenti nel P.S. N/A Ministero Salute Tutti campi richiesti per l'identificazione dell'autore del PS sono presenti nella sezone <author> e in particolare nella sotto sezione < representedorganization> sono modellabili i codici relativi a codaslmedico e provaslmedico. Pagina 23/ 223

24 5 Header del Patient Summary 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 del Patient Summary in formato CCD. Pagina 24/ 223

25 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 25/ 223

26 5.2 Dominio del documento L elemento obbligatorio che indica il dominio di appartenenza del documento, ovvero l Italia, è rappresentato dalla proprietà <realmcode> Più precisamente esso indica l esistenza di una serie di restrizioni applicate per il dominio ITALIANO al profilo CCD, definite nell ambito di HL7 Italia. Questo valore è fisso e non modificabile. Attributo Tipo Valore Dettagli Code CE IT Definisce l id di contesto per l Italia. Esempio d uso: <realmcode code="it"/> Pagina 26/ 223

27 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 d uso: <typeid root=" " extension="pocd_hd000040"/> 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 Pagina 27/ 223

28 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 Patient Summary è caratterizzato da almeno due elementi <templateid>: 1. 1 E' prevista dallo standard la possibilità di utilizzare template con diversi livelli di granularità, potendo anche specificare template differenti in punti diversi del documento. Pagina 28/ 223

29 Il primo elemento <templateid> è valorizzato secondo le regole di conformance previste dall implementation guide del CCD, ed è pertanto costituito dal solo elemento <root> valorizzato come segue: Attributo Tipo Valore Dettagli Root OID OID del catalogo degli schemi dei template di documento per i documenti di Patient Summary (Rif: cap 1.4 CCD) extension ST - [CONF-8] [CONF-8] At least one ClinicalDocument / templateid SHALL value ClinicalDocument / templateid with , and SHALL NOT contain ClinicalDocument / templateid il secondo si riferisce al documento di Patient Summary in termini di imposizione di una serie di costraint sul modello previsto dal CCD, 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 Patient Summary Ipotesi Codice composto PREFISSO: ITPRF CODICE: PSUM _GEN extension ST VERSIONE: 001 progressivo per il versioning dei template per il Patient Summary Identificativo del template di (generico) documento PATIENT SUMMARY [CONF-7] CCD SHALL contain one or more ClinicalDocument / templateid. Esempio d uso: <!-- CCD v1.0 Templates Root --> <templateid root=" "/> <!-- Identificativo del template di documento PATIENT SUMMARY in ambito Italiano--> <templateid root=" " extension=" ITPRF_PSUM_GEN-001"/> Pagina 29/ 223

30 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 patient summary, 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 indetificazione 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 Pagina 30/ 223

31 documenti della struttura cui 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 d uso: <id root=" " extension=" " assigningauthorityname="ausl LATINA 1"/> Pagina 31/ 223

32 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, patient summary) Il valore deve fare riferimento al sistema di codifica LOINC. Nel caso del Patient Summary, il tag <code> deve essere così valorizzato : Pagina 32/ 223

33 <code>: Attributo Tipo Valore Dettagli codesystem OID Codifica LOINC Code CS codesystemname ST LOINC codesystemversion ST 2.19 displayname ST PATIENT SUMMARY Codice relativo alla tipologia del documento. ( Summarization of episode note ) Versione codifica LOINC (OPZIONALE) Nome usato dal sistema inviante per rappresentare il codice in oggetto ai propri utenti 2 [CONF-1] The value for ClinicalDocument / code SHALL be Summarization of episode note LOINC STATIC Per individuare nel realm Italiano le successive tipologie di patient summary il codice espresso nell elemento <code> potrà essere tradotto in un codesystem definito in ambito italiano e condiviso all interno del dominio FSE. In tale contesto è quindi ammesso l utilizzo all interno dell elemento <code> degli elementi <translation>.. L elemento <translation> è concepito per tradurre il concetto originale in un diverso schema di codifica, assumendo quindi che il nuovo codice sia un quasi-sinonimo del codice orginale. In tale contesto è quindi ammesso l utilizzo all interno dell elemento code di un <translation> che DEVE essere così valorizzato: <code><translation>: Attributo Tipo Valore Dettagli codesystem OID Codice corrispondente allo schema di codifica adottato. 2 Il display name deve essere usato per aiutare la comprensione umana del code value veicolato. Il suo valore non può alterare il significato del code value, né essere usato la classificazione del documento od altre esigenze funzionali. Lo standard non richiede al sistema ricevente di utilizzare la stessa rappresentazione impiegata dall inviante, fatto salvo che venga preservato il significato del codice. Questo Significa che l inviante potrebbe usare dizioni alternative a quella indicata a titolo esemplificativo sopra. Pagina 33/ 223

34 Attributo Tipo Valore Dettagli Codice relativo alla specifica code CS [CODICE_TIPO_PS] tipologia di documento. codesystemname ST [NOME_SCHEMA] Nome dello schema di codifica displayname ST Nome tipo di documento Nota: Tale codice NON PUO mai confliggere con il codice LOINC Summarization of episode note Esempio: <code code=" " codesystem=" " displayname="patient SUMMARY"> <translation code="x " codesystem=" " codesystemname="nome_schema" /> </code> Pagina 34/ 223

35 5.7 Data di creazione documento L elemento obbligatorio che indica la data di creazione del documento PS 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 Ad esempio le si indicano [CONF-9] ClinicalDocument / effectivetime SHALL be expressed with precision to include seconds. [CONF-10] ClinicalDocument / effectivetime SHALL include an explicit time zone offset. Esempio d uso: <effectivetime value=" "/> L esempio indica le 14:00:00 (ora Italiana) del 07 Aprile Pagina 35/ 223

36 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 36/ 223

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

38 5.9 Lingua del documento e Dominio L elemento obbligatorio per il PS 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 del Patient Summary 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 d uso: <languagecode code="it-it"/> Pagina 38/ 223

39 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 Patient Summary 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> uguale al 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 globalmente ; per poter soddisfare tale condizione, si suggerisce pertanto di valorizzare alla prima creazione del documento i campi <setid> ed <id> allo stesso modo modificando successivamente nelle diverse revisioni solo Pagina 39/ 223

40 l <id> con un nuovo IUD e 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 indetificazione 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 40/ 223

41 <versionnumber>: Attributo Tipo Valore Dettagli value Esempio d uso: INT [progressivo versione documento] <setid root=" " extension=" dw322" assigningauthorityname="ausl LATINA 1" /> <versionnumber value="1" /> Ad ogni successiva versione del documento (RPLC), tale numero incrementa di una unità (partendo da 1) Figura 1: Gestione delle versioni del documento Replace (estratto documentazione HL7) Pagina 41/ 223

42 5.11 Dati Anagrafici del paziente L elemento obbligatorio che identifica il soggetto cui si riferisce il Patient Summary è rappresentato dal tag <recordtarget>. Il <recordtarget> è un elemento composto da un ruolo <patientrole> verso un entità <patient>. Per il Patient Summary l elemento è pertanto strutturato come segue: <recordtarget> <patientrole> <patient>...</patient> <patientrole> <recordtarget> 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. Pagina 42/ 223

43 Il Cittadino italiano o straniero residente (iscritto SSN) è caratterizzato da due elementi di tipo <id> contenenti: Il codice assegnato dall anagrafica regionale (FACOLTATIVO) Il codice fiscale del paziente (OBBLIGATORIO) Primo <id>: Attributo Tipo Valore Dettagli root OID [OID REGIONE] extension ST [CODICE IDENTIFICATIVO] OID schema di identificazione regionale Codice anagrafica regionale Secondo <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 Esempio d uso: <recordtarget> <patientrole> <!--Codice Regionale--> <id root=" " extension=" " assigningauthorityname="regione Toscana"/> <!--CODICE FISCALE--> <id root=" " extension="crllnz99m22g999t" assigningauthorityname="mef"/> <patient> <patient> </patientrole> </recordtarget> Per stranieri temporaneamente presenti <patientrole> DEVE riportare il Codice identificativo STP (vedi tabella seguente per esempio di struttura Pagina 43/ 223

44 <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 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 d uso: <recordtarget> <patientrole> <id../> <id../> <patient> <name> <family>guido</family> <given>rossi</given> </name> <birthplace> <place> <addr>...</addr> </place> </birthplace> <administrativegendercode code="m" codesystem=" "/> </patient> </patientrole> </recordtarget> Pagina 44/ 223

45 Tutore legale Rete di Medici di Medicina Generale Progetto Esecutivo 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. <recordtarget> <patientrole> <patient> <name> <administrativegendercode/> <birthtime/> <!--Tutore legale: puo essere una persona o un'organizzazione aventi il ruolo di tutore--> <guardian> <id root=" " assigningauthorityname=" MEF" extension="crllnz73m22f839t"/> <guardianperson> <name> <family>lorenzi</family> <!--cognome gardian--> <given>lorenzo</given> <!--nome guardian--> </name> </guardianperson> </guardian> </name> </patient> </patientrole> </recordtarget> Pagina 45/ 223

46 5.12 Autore e autenticatore Autore L attributo obbligatorio che identifica il soggetto che ha creato il documento.è rappresentato dla tag <author>. <author.time>: Attributo Tipo Valore Dettagli value TS [YYYYMMddhhmmss+ -ZZzz] Anno, mese, giorno, ora, minuti, secondi In questo contesto l'autore del documento è una persona, valorizzata attraverso dall'attributo <assignedperson>. Pagina 46/ 223

47 L autore è identificato da più <id>. La classe deve contenere un attributo <time> obbligatorio con l indicazione dell ora di produzione del documento: la valorizzazione viene effettuata come nel caso dell attributo <effectivetime> e deve essere uguale. Primo id <assignedauthor.id>: Pagina 47/ 223

48 Attributo Tipo Valore Dettagli root OID OID Ministero economia e finanze CF extension ST [CODICE FISCALE] Codice Fiscale dell autore del documento Secondo id <assignedauthor.id>: Attributo Tipo Valore Dettagli root OID [OID REGIONE].4.2 extension ST [CODICE IDENTIFICATIVO] OID schema di identificazione regionale operatori Codice anagrafica regionale operatori [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 PS è codificato attraverso il segmento <rapresentedorganization> ricorrendo a appositi <id> che fanno riferimento alle tabelle di codifica degli OID di HL7Italia. Pagina 48/ 223

49 <assignedperson.name>: Rete di Medici di Medicina Generale Progetto Esecutivo <rapresentedorganization.id>: Pagina 49/ 223

50 Esempio d uso: <author> <time value=" "/> <assignedauthor> <!-- Codice FISCALE--> <id root=" " extension="xxxyyy99m22g999t"/> <!-- Codice anagrafica regionale operatori--> <id root=" " extension="87245"/> <assignedperson> <name> <given>guido</given> <family>rossi</family> <suffix>dott.</suffix> </name> </assignedperson> <representedorganization> <!-- Codice Asl di covenzione del Medico titolare delle informazioni presenti nel PS root ed extension da collegare alla tabella A.10 del PED --> <id root=" " extension="110"/> </representedorganization> </assignedauthor> </author> Firmatario del documento L attributo obbligatorio che riporta il firmatario del documento è rappresentato dal tag <legalauthenticator>. La classe deve contenere un tag <time> obbligatorio con l indicazione dell ora di produzione del documento (la valorizzazione viene effettuata come nel caso dell attributo <effectivetime>, un attributo <signaturecode>, ed un <assignedentity> destinato ad accogliere l <id> del medico. Nel caso del PS l autore ed il firmatario del documento devono essere la stessa persona fisica. Pagina 50/ 223

51 <time>: 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 Ad esempio le si indicano Per le modalità di firma del documento (XML-Signature Enveloped), si vedano le indicazioni riportate. Pagina 51/ 223

52 <signaturecode>: Attributo Tipo Valore Dettagli code ST S Codice che indica che il documento è firmato digitalmente <assignedentity><id>: Attributo Tipo Valore Dettagli root OID OID Ministero economia e finanze - CF extension ST [CODICE FISCALE] Pagina 52/ 223

53 Esempio d uso: <legalauthenticator> <time value=" "/> <signaturecode code="s"/> <assignedentity classcode="assigned"> <id root=" " extension="xxxyyy99m22g999t"/> <assignedperson> <name> <given>guido</given> <family>rossi</family> <suffix>dott.</suffix> </name> </assignedperson> </assignedentity> </legalauthenticator> Pagina 53/ 223

54 5.13 Custode L elemento obbligatorio che identifica l organizzazione incaricata della custodia del documento originale è rappresentata dal tag <custodian>. Tale organizzazione è solitamente la struttura di cui fa parte colui che ha creato il documento (MMG -ASL). Pagina 54/ 223

55 Il <custodian> è un elemento composto da un ruolo di tipo <assignedcustodian> verso un entità <representedcustodianorganization>. Per la corretta generazione del documento è obbligatorio riempire l'attributo <custodian> e <representedcustodianorganization>. L elemento viene pertanto ad essere strutturato come segue: <custodian> <assignedcustodian> <representedcustodianorganization> </representedcustodianorganization> </assignedcustodian> </custodian> La classe <representedcustodianorganization> deve pertanto contenere al suo interno un <id> che riporta l identificativo della struttura documento che ha la responsabilità della conservazione del documento. root extension Attributo Tipo Valore Dettagli [OID dominio di Identificativo del dominio di OID indentificazione delle identificazione delle organizzazioni ] organizzazioni ST [ID ORGANIZZAZIONE] Identificativo dell organizzazione (ASL, Regione) da parte del dominio di indetificazione definito nella root. Per le strutture che ricadono sotto la competenza delle ASL/AO è pertanto previsto che sia assegnato da parte di queste, dove non già esistente, un identificativo univoco. Pagina 55/ 223

56 Esempio d uso: <custodian> <assignedcustodian> <representedcustodianorganization> <id root=" " extension="130106"/> <name>asl Teramo</name> </representedcustodianorganization> </assignedcustodian> </custodian> Pagina 56/ 223

57 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 57/ 223

58 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 58/ 223

59 Sono caratterizzati dai seguenti valori: Pagina 59/ 223

60 <associatedentity >: Attributo Tipo Valore Dettagli classcode CS NOK Codice che identifica il contatto Parente (Next Of Kin) <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 PersonalRelations hiproletype 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. Pagina 60/ 223

61 <associatedentity >: 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 61/ 223

62 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 62/ 223

63 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 Note implementative Una gestione fortemente strutturata dei dati anagrafici relativi ai contatti, sebbene a livello informatico auspicabile, non è spesso coerente con le aspettative applicative degli operatori sanitari (i.e il medico è interessato in generale ad avere dei promemoria sui contatti relativi ad un paziente; non è interessato a fare ricerche od analisi su queste informazioni). Pagina 63/ 223

64 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> 5.1 Evento clinico documentato Il documento di Patient Summary costituisce una vista delle cure cui si è sottoposto un paziente durante un determinato periodo di tempo, che per il contesto in esame, potrebbe anche coincidere con l intero arco di vita. In conformità con quanto previsto dalla guida di implementazione di CCD, la durata dell arco temporale cui il Patient Summary si riferisce viene veicolata all interno degli elementi (OBBLIGATORI) <documentationof> e <serviceevent> (<effectivetime>). L elemento <documentationof> deve essere strutturato come segue: <documentationof> <serviceevent> </serviceevent> </documentationof L elemento <serviceevent> descrive il servizio entro cui e per il quale il documento è stato generato. L intervallo di durata dell evento in seguito al quale è stato redatto il Patient Summary è rappresentato mediante un elemento <effectivetime>. Nel contesto d uso del Patient Summary, 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. <ServiceEvent>: Pagina 64/ 223

65 Attributo Tipo Valore Dettagli classcode CS PCPR Codice che identifica l evento da cui ha origine il PS <effectivetime xsi:type= IVL_TS >: Attributo Tipo Valore Dettagli low TS nullflavor = NI inizio intervallo. high TS nullflavor = NI fine intervallo. Esempio d uso: <documentationof> <serviceevent classcode="pcpr"> <effectivetime> <low nullflavor="ni"/><high nullflavor="ni"/> </effectivetime> </serviceevent> </documentationof> 5.2 Destinatario del documento: <informationrecipient> Elemento OPZIONALE che rappresenta il destinatario del documento. Da non usarsi nel contesto d uso del Patient Summary. Pagina 65/ 223

66 5.3 Altre Informazioni L header del CDA può contenere altre informazioni realtive al contesto di uso di questo documento (e.g. <dataenterer>;.) Riguardo l uso di questi elementoi si faccia riferimento alla documentazione ufficiale di HL7 CDA Normative Edition Pagina 66/ 223

67 6 Body del Patient Summary In questa sezione si definisce il BODY del documento Patient Summary, in formato strutturato, composto dalla classe <structuredbody> che tramite una relazione di <component> contiene una o più sezioni di tipo <section> che riportano il contenuto effettivo del patient summary. 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>), un attributo <code> OBBLIGATORIO che specifica il codice della tipologia di sezione e uno o più elementi <entry> FACOLTATIVE che ne definiscono il contenuto. 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 67/ 223

68 6.1 Lista Allergie All interno del modello informativo previsto per il PS - definito nel capitolo 4- Contenuto Informativo - 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,.) Così strutturate: Allergie di tipo farmacologiche. Tag Principale Tag Riferimento Descrizione campo Dizionario datarilievo Data manifestazione allergia N/A Obbl. codatc Codice ATC della sostanza allergiefarmacologiche molecola codaic Descrizione molecola in chiaro Codice AIC farmaco scatenante N/A nomefarmaco note Descrizione farmaco scatenante N/A N/A Pagina 68/ 223

69 Altre Allergie. Tag Principale Tag Riferimento Descrizione campo Dizionario Obbl. altreallergie datarilievo codiceallergia descrizione note Data manifestazione allergia N/A Dizionario sostanza scatenante N/A N/A L intolleranza/allergia ha normalmente un agente al quale il paziente reagisce ed è potenzialemente caratterizzato da specifici sintomi ( reazioni ). Le allergie sono riportabili nel pattern Alerts di CCD (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 69/ 223

70 La sezione alert include non solo informazioni relative alle intolleranze ma ogni tipo di 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!) Pagina 70/ 223

71 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 Template CCD 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: 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 asserted CONF-258 The absence of known allergies, adverse reactions, or alerts SHALL be explicitly 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. 3 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 71/ 223

72 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 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. Pagina 72/ 223

73 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= active /> <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> 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. Pagina 73/ 223

74 $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 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"/> Pagina 74/ 223

75 <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 Vincoli Aggiuntivi 1 solo Problem Observation per ogni Problem Act Pagina 75/ 223

76 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'/> <effectivetime> <low ( value= $LOW_TS nullflavor="unk" )/> Pagina 76/ 223

77 <! 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" )/> </effectivetime> <value xsi:type="cd" code=" " codesystem=" " displayname="nessuna Allergia Nota"> <originaltext> <reference value="#$ref_allarme"/> </originaltext> </value> </observation> Pagina 77/ 223

78 $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 78/ 223

79 <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 $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 Pagina 79/ 223

80 $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 80/ 223

81 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 81/ 223

82 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> 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 Pagina 82/ 223

83 $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> <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 ) Pagina 83/ 223

84 $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'/> <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 Pagina 84/ 223

85 $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' /> <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 Pagina 85/ 223

86 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'> <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> Pagina 86/ 223

87 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 --> <!--==================================================================================--> <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--> Pagina 87/ 223

88 <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=" "/> <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"/> <statuscode code="completed"/> Pagina 88/ 223

89 <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/ 223

90 6.2 Lista Problemi Rete di Medici di Medicina Generale Progetto Esecutivo Il medico titolare dei dati del paziente, fra tutti i problemi presenti nella cartella informatizzata del paziente, renderà disponibili solo quelli che ritiene 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 gli liste malattie pregresse, organi mancanti. Possono essere elencati in ordine cronologico inverso o in ordine di importanza, a seconda delle finalità del patient summary. 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 4 (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 4 Nota: questa classe di informazione non è registrata nella sezione Problems, bensì in Plano of Care Pagina 90/ 223

91 Possono esistere S, O, V, P non inclusi in un problema. Possonon esserci problemi non strutturati come SOVP. 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/ 223

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

93 L elemento problema, strutturato come indicato nel diagramma seguente, potrà contenere da zero a più SOVP. Tag Principale Tag Riferimento Descrizione campo Dizionario Obbl. dataapertura Data apertura del problema N/A X codicd9 Codice ICD IX CM diagnosi ICD IX CM X descrizione Descrizione problema N/A problema datachiusura Data archiviazione problema N/A soluzioneproblema Risoluzione problema: Risolto Non risolto Cronico SNOMED-CT SOVP Soggettività, Oggettività, Valutazione, Piano N/A note N/A L ultimo SOVP può essere la sintesi dei SOVP precedenti SOVP Ulteriori dettagli a completamento delle informazioni in precedenza evidenziate, riguardano la Soggettività l Oggettività, la Valutazione ed il Piano oggetto di inserimento da parte del medico in base a quanto può emergere durante la visita medica del paziente. Inoltre, il dato Codice ICD-IX-CM e relativa denominazione consentiranno di determinare la natura delle valutazioni a quale problema è associato. Pagina 93/ 223

94 Tag Principale Tag Riferimento Descrizione campo Dizionario Obbl. Data Data inserimento N/A soggettività Informazioni riferite dal soggetto N/A SOVP oggettività Note sulla sintomatologia N/A valutazione Note sulla Obiettività N/A piano Note sull'orientamento diagnostico N/A codidc9 Codice ICD IX CM ICD IX CM denominazione Descrizione Diagnosi N/A Template CCD Sezione che dovrebbe essere presente e che deve essere unica in tutto il PS 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 ). Pagina 94/ 223

95 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=" /> La sezione è individuata da un elemento <code> (livello 2) che ne specifica il contenuto che è così strutturato: <section><code>: Attributo Tipo Valore Dettagli code CS Codice che identifica il contenuto della sezione codesystem OID Codifica LOINC codesystemname ST LOINC - Esempio d uso: ******************************************************** Problems section ******************************************************** --> <component> <section> <templateid root=" "/> <!-- Problem section template --> <code code=" " codesystem=" "/> <title>problems</title> Pagina 95/ 223

96 Contiene un elemento <text> obbligatorio [CONF-140]. L elemento <text> deve contenere al suo interno la descrizione narrativa di ogni singolo problema il medico ritiene significativo per riassumere la storia clinica dell assistito ed eventualmente lo stato (attivo, non attivo, cronico, intermittente, risolto, ricorrente) dello scopo del documento (Livello 1). Esempio d uso: <text> descrizione testuale con riferimenti <content ID="diagn_1_1"> bronchite</content>. </text> 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 --> <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. Pagina 96/ 223

97 $ 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 97/ 223

98 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 98/ 223

99 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 Template CCD In base alle condizioni sopra espresse l elemento dovrà essere così strutturato: Pagina 99/ 223

100 <act classcode='act' moodcode='evn'> <templateid root=' '/> <templateid root=' '/> <templateid root=' '/> <! template che indica restrizioni specifiche per il PS --> <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 ) $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 Pagina 100/ 223

101 $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: <observation classcode='obs' moodcode='evn' negationind='false true '> <templateid root=' '/> <templateid root=' '/> <! template che indica restrizioni specifiche per il PS --> <templateid root= /> <id root='$id_sez /> Pagina 101/ 223

102 <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 $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 Pagina 102/ 223

103 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" >) <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 Pagina 103/ 223

104 $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" >) <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 Pagina 104/ 223

105 Alive and Sano well 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. CONF-175 Observation / value in an episode observation SHOULD be the following SNOMED CT expression: <value xsi:type="cd" code=" " Pagina 105/ 223

106 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> 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 Pagina 106/ 223

107 $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 PS --> <act classcode='act' moodcode='evn'> <templateid root=' '/> <templateid root=' '/> <templateid root=' '/> <! template che indica restrizioni specifiche per il PS --> <templateid root= /> <!-- Problem act template --> <id root="ec8a6ff8-ed4b-4f7e-82c3-e98e58b45de7"/> <code nullflavor="na"/> <effectivetime> <low value=" "/> </effectivetime> <!--Codice ICD IX CM diagnosi--> Pagina 107/ 223

108 <entryrelationship typecode="subj"> <observation classcode="obs" moodcode="evn"> <!-- Problem observation template --> <templateid root=" "/> <templateid root=' '/> <! template che indica restrizioni specifiche per il PS --> <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=" " 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"/> Pagina 108/ 223

109 <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 il PS --> <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"/> <!--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 109/ 223

110 Pagina 110/ 223

111 6.3 Prescrizioni Riabilitative Prescrizioni multiple destinate a contenere le richieste di prestazioni riabilitative Prescrizione Prestazione Riabilitativa Prescrizioni riabilitativa con i dettagli della richiesta effettuata dal medico. Tag Principale Tag Riferimento Descrizione campo Dizionario Obbl. codprestazione Codice Prestazione N/A X dataprescrizione Data prescrizione N/A X prescrizioneriabilitazione codicd9 diagnosi Codice ICD9-CM problema associato Descrizione problema associato Rif. Tab. ICDIX CM N/A X quantita Quantità esami N/A note La prescrizione di riabilitazione si modella come un ACT oppure con Procedure e visto che è una prescrizione con moodcode RQO : N/A <act classcode="act" moodcode="rqo"> Le prescrizioni riabilitative saranno gestate all interno della sezione Plan Of Care (cfr 3.16) Il codice di prestazione viene descritto con un code: <code xsi:type="ce" code="466.0" codesystemname="codprestazione" codesystem=" " displayname="riabilitazione all'anca"> </code> Pagina 111/ 223

112 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> Pagina 112/ 223

113 6.4 Prescrizioni Farmaci Struttura multipla per contenere le prescrizioni terapeutiche Prescrizione Farmaco La Struttura conterrà tutti i dettagli della prescrizione farmacologia. Tag Principale Tag Riferimento Descrizione campo Dizionario Obbl. codaic Codice AIC farmaco X nomefarmaco Descrizione farmaco N/A X prescrizionefarmaco dataprescrizione Data prescrizione N/A X quantità Quantità confezioni N/A NOTA AIFA posologia Posologia N/A note N/A Tutte le informazioni relative a prescrizioni e somministrazione di farmaci devono essere descritte all interno della sezione Medications. Per il Patient Summary, in cui si suppone che la sezione includa solo le informazioni relative alle terapie in corso. 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) Pagina 113/ 223

114 Il modello informativo associato alla sezione medications è: Template CCD La sezione del CCD deputata a raccogliere le informazioni relative alle prescrizioni farmacologiche è la Medications (cfr CCD cap 3.9). Tale sezione deve essere usata, oltre che per referenziare le prescrizoni farmacologiche di interesse, anche per indicare le eventuali somministrazioni ricevute dal paziente. 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 PS si ritiene idoneo privilegiare il secondo aspetto. Il riferimento da prendere per la registrazione delle terapie farmacologiche è quindi il template Medication Activities. Pagina 114/ 223

115 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> 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: Pagina 115/ 223

116 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. 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. Pagina 116/ 223

117 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> <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> Pagina 117/ 223

118 <! 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 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"> Pagina 118/ 223

119 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"> <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 Pagina 119/ 223

120 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 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. 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> <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. Pagina 120/ 223

121 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. 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 Pagina 121/ 223

122 $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 Ragione 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 122/ 223

123 <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 --> </section> </component> Pagina 123/ 223

124 6.5 Vaccinazioni Le vaccinazioni potranno essere molteplici la struttura seguente consentirà di contenerle se presenti Vaccinazione La Vaccinazione conterrà i dati presenti nella seguente struttura. Tag Principale Tag Riferimento Descrizione campo Dizionario Obbl. datavaccinazione Data somministrazine N/A X codicevaccino Codice Vaccino vaccinazione vaccino Descrizione Vaccinazione N/A X numgiornivalidita Giorni di validità del vaccino N/A note N/A Template CCD 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. CONF-378: The value for Section / code SHALL be History of immunizations LOINC STATIC. CONF-379: The immunizations section SHALL contain Section / title. Pagina 124/ 223

125 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 Vaccinazione 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=' '/> Pagina 125/ 223

126 <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 --> <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> Pagina 126/ 223

127 <! 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 $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 ' ) Pagina 127/ 223

128 6.5.4 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> <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=" "/> Pagina 128/ 223

129 <consumable typecode="csm"> <manufacturedproduct classcode="manu"> <manufacturedlabeleddrug classcode="mmat" determinercode="kind"> <code nullflavor="oth"> <originaltext> <reference value="#vac_2"/> </originaltext> <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 129/ 223

130 6.6 Lista Rilevazioni Le rilevazioni riguardano i dati di tipo Generico, Antropometrici e la pressione Rilevazione La rilevazione può essere di un tipo specifico, quindi a scelta, una sotto-struttura esclude l altra. Quindi, ogni struttura conterrà un solo tipo di dato: rilevazione generica, esame di laboratorio, esame strumentale, visita specialistica, dati antropometrici o pressione Rilevazione Generica Consente l inserimento di qualsiasi tipo di informazione non codificata. Pagina 130/ 223

131 Tag Principale Tag Riferimento Descrizione campo Dizionario Obbl. dataesecuzione Data Esecuzione N/A X rilevazionegenerica Testo Valore Testuale N/A Template CCD 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. 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: Pagina 131/ 223

132 In base alle condizioni sopra espresso l elemento dovrà essere così strutturato: <component> <section> <templateid root=' '/> <templateid root=' '/> <id root='$id_sez /> <code code='8716-3' displayname='vital SIGNS' codesystem=' ' codesystemname='loinc'/> <title>parametri Vitali</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 Pagina 132/ 223

133 Per ulteriori dettagli riferirsi alle sezioni e Esame di Laboratorio, Esame Strumentale, Visita Specialistica L elemento esamelaboratorio, esamestrumentale e visitaspecialistica sono tutti di tipo RilevazioneType.che estende RilevazioneGenerica. La struttura conterrà tutte le informazioni essenziali a determinare il tipo di accertamento e il relativo esito. Tag Principale Tag Riferimento Descrizione campo Dizionario Obbl. rilevazionetype esamestrumentale esamelaboratorio visitaspecialistica tiporisultato codice Conterrà la tipologia dell indagine eseguita Codice tipo esame eseguito Codifica della Fonte di Origine del Dato N/A N/A dataesecuzione Data Prelievo N/A X codicd9 diagnosi Codice ICD9-CM problema associato Descrizione problema associato ICDIX CM N/A testo Valore Testuale N/A X Un esame di laboratorio, strumentale o una visita specialistica vengono modellate con dettagli espandibili e con actrelationship Template CCD Vengono usati a seconda del tipo di informazione da trasferire i template "Encounters" (crf. Cap 3.15) Results (crf. Cap. 3.13) o Procedures (crf Cap 3.14). Le visite specialistiche saranno sempre rapprestentate da Encounter, mentre esami strumentali e di laboratorio potranno essere riportati in termini di procedura o report. Qui di seguito alcuni esempi di uso dei tre template con i relativi vincoli di conformità. Pagina 133/ 223

134 Esame strumentale Rete di Medici di Medicina Generale Progetto Esecutivo 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. 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. Il modello informativo associato alla sezione delle Procedures è: Pagina 134/ 223

135 Template CCD Le specifiche di questa sezione ( procedures ) è definito dal template CCD ; i cui vincoli sono: 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. Pagina 135/ 223

136 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> <! 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 Pagina 136/ 223

137 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) 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 Pagina 137/ 223

138 ), 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 --> <! --> $RIF_ENCOUNTER <! OPZIONALE Ragione della procedura --> <! --> $RAGIONE </procedure> 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 : Pagina 138/ 223

139 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..--> </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 139/ 223

140 Visita specialistica Rete di Medici di Medicina Generale Progetto Esecutivo 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 è: Template CCD La sezione Encounter deve rispettare il template CCD ; i cui vincoli sono: Pagina 140/ 223

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

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

M. Ciampi. Consiglio Nazionale delle Ricerche Dipartimento delle Tecnologie dell Informazione e delle Comunicazioni

M. Ciampi. Consiglio Nazionale delle Ricerche Dipartimento delle Tecnologie dell Informazione e delle Comunicazioni Presidenza del Consiglio dei Ministri Dipartimento per la digitalizzazione della PA e l innovazione tecnologica Consiglio Nazionale delle Ricerche Dipartimento delle Tecnologie dell Informazione e delle

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

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

DOCUMENTO DI SPECIFICA DEI REQUISITI SOFTWARE

DOCUMENTO DI SPECIFICA DEI REQUISITI SOFTWARE DOCUMENTO DI SPECIFICA DEI REQUISITI SOFTWARE Tabella dei contenuti 1. Introduzione 1.1 Propositi 1.2 Obiettivi 1.3 Definizioni, acronimi ed abbreviazioni 1.4 Riferimenti 1.5 Panoramica 2. Descrizione

Dettagli

DISCIPLINARE TECNICO Modalità tecniche per la predisposizione e l invio telematico dei dati delle certificazioni di malattia all INPS

DISCIPLINARE TECNICO Modalità tecniche per la predisposizione e l invio telematico dei dati delle certificazioni di malattia all INPS DISCIPLINARE TECNICO Modalità tecniche per la predisposizione e l invio telematico dei dati delle certificazioni di malattia all INPS 1. Introduzione Il presente documento ha lo scopo di definire le modalità

Dettagli

1. DISTRIBUZIONE Datore di Lavoro Direzione RSPP Responsabile Ufficio Tecnico Responsabile Ufficio Ragioneria (Ufficio Personale) Ufficio Segreteria

1. DISTRIBUZIONE Datore di Lavoro Direzione RSPP Responsabile Ufficio Tecnico Responsabile Ufficio Ragioneria (Ufficio Personale) Ufficio Segreteria Acquedotto Langhe e Alpi Cuneesi SpA Sede legale in Cuneo, corso Nizza 9 acquedotto.langhe@acquambiente.it www.acquambiente.it SGSL Procedura Gestione dei documenti e del 06/05/2013 1. DISTRIBUZIONE Datore

Dettagli

4.5 CONTROLLO DEI DOCUMENTI E DEI DATI

4.5 CONTROLLO DEI DOCUMENTI E DEI DATI Unione Industriale 35 di 94 4.5 CONTROLLO DEI DOCUMENTI E DEI DATI 4.5.1 Generalità La documentazione, per una filatura conto terzi che opera nell ambito di un Sistema qualità, rappresenta l evidenza oggettiva

Dettagli

Gestione dei documenti e delle registrazioni Rev. 00 del 11.11.08

Gestione dei documenti e delle registrazioni Rev. 00 del 11.11.08 1. DISTRIBUZIONE A tutti i membri dell organizzazione ING. TOMMASO 2. SCOPO Descrivere la gestione della documentazione e delle registrazioni del sistema di gestione 3. APPLICABILITÀ La presente procedura

Dettagli

«Gestione dei documenti e delle registrazioni» 1 SCOPO... 2 2 CAMPO DI APPLICAZIONE E GENERALITA... 2 3 RESPONSABILITA... 2 4 DEFINIZIONI...

«Gestione dei documenti e delle registrazioni» 1 SCOPO... 2 2 CAMPO DI APPLICAZIONE E GENERALITA... 2 3 RESPONSABILITA... 2 4 DEFINIZIONI... Pagina 1 di 6 INDICE 1 SCOPO... 2 2 CAMPO DI APPLICAZIONE E GENERALITA... 2 3 RESPONSABILITA... 2 4 DEFINIZIONI... 2 5 RESPONSABILITA... 2 5.3 DESTINATARIO DELLA DOCUMENTAZIONE... 3 6 PROCEDURA... 3 6.1

Dettagli

L esperienza ligure del FSE: il Conto Corrente Salute

L esperienza ligure del FSE: il Conto Corrente Salute Regione Liguria L esperienza ligure del FSE: il Conto Corrente Salute Roma, 24 febbraio 2010 Maria Franca Tomassi La strategia Il Sistema Informativo Regionale Integrato per lo sviluppo della società dell

Dettagli

Corso: Sistemi di elaborazione delle informazioni 2. Anno Accademico: 2007/2008. Docente: Mauro Giacomini

Corso: Sistemi di elaborazione delle informazioni 2. Anno Accademico: 2007/2008. Docente: Mauro Giacomini Corso: Sistemi di elaborazione delle informazioni 2. Anno Accademico: 2007/2008. Docente: Mauro Giacomini Organizzazione no-profit per lo sviluppo di standard che fornisce linee guida per: lo scambio la

Dettagli

SISTEMA DI GESTIONE PER LA QUALITA Capitolo 4

SISTEMA DI GESTIONE PER LA QUALITA Capitolo 4 1. REQUISITI GENERALI L Azienda DSU Toscana si è dotata di un Sistema di gestione per la qualità disegnato in accordo con la normativa UNI EN ISO 9001:2008. Tutto il personale del DSU Toscana è impegnato

Dettagli

Comunicare per «costruire salute» FORUM PA Roma, 29 maggio 2013. L uso dell ICT per lo sviluppo del «Sistema Informativo Sociosanitario»

Comunicare per «costruire salute» FORUM PA Roma, 29 maggio 2013. L uso dell ICT per lo sviluppo del «Sistema Informativo Sociosanitario» Comunicare per «costruire salute» FORUM PA Roma, 29 maggio 2013 L uso dell ICT per lo sviluppo del «Sistema Informativo Sociosanitario» Chiara Penello Decreto Crescita 2.0 (DL 179/2012 conv. in Legge n.

Dettagli

APERTURA DEL CONTO CORRENTE SALUTE

APERTURA DEL CONTO CORRENTE SALUTE REGIONE LIGURIA AZIENDA SANITARIA LOCALE n. 4 CHIAVARESE Via G.B. Ghio, 9-16043 Chiavari CONTO CORRENTE SALUTE Progetto sperimentale INFORMATIVA PER CONSENSO AL TRATTAMENTO DEI DATI PERSONALI per APERTURA

Dettagli

La centralità del paziente tra MMG Distretto e Ospedale: il Fascicolo Sanitario Elettronico. Daniele Donato Azienda ULSS 16 - Padova

La centralità del paziente tra MMG Distretto e Ospedale: il Fascicolo Sanitario Elettronico. Daniele Donato Azienda ULSS 16 - Padova La centralità del paziente tra MMG Distretto e Ospedale: il Fascicolo Sanitario Elettronico Daniele Donato Azienda ULSS 16 - Padova Premesse 2010 Centralità del paziente Continuità delle cure Appropriatezza

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

Organizzazione degli archivi

Organizzazione degli archivi COSA E UN DATA-BASE (DB)? è l insieme di dati relativo ad un sistema informativo COSA CARATTERIZZA UN DB? la struttura dei dati le relazioni fra i dati I REQUISITI DI UN DB SONO: la ridondanza minima i

Dettagli

la legge sulla privacy e il trattamento dei dati sanitari

la legge sulla privacy e il trattamento dei dati sanitari l azienda a informa la legge sulla privacy e il trattamento assistenza domiciliare prestazioni farmaceutiche visita specialistica assistenza residenziale pronto soccorso ricovero in ospedale FASCICOLO

Dettagli

Integrazione del progetto CART regione Toscana nel software di CCE K2

Integrazione del progetto CART regione Toscana nel software di CCE K2 Integrazione del progetto CART regione Toscana nel software di CCE K2 Data Creazione 04/12/2012 Versione 1.0 Autore Alberto Bruno Stato documento Revisioni 1 Sommario 1 - Introduzione... 3 2 - Attivazione

Dettagli

MANUALE DELLA QUALITA Revisione: Sezione 4 SISTEMA DI GESTIONE PER LA QUALITA

MANUALE DELLA QUALITA Revisione: Sezione 4 SISTEMA DI GESTIONE PER LA QUALITA Pagina: 1 di 5 SISTEMA DI GESTIONE PER LA QUALITA 4.0 SCOPO DELLA SEZIONE Illustrare la struttura del Sistema di Gestione Qualità SGQ dell Istituto. Per gli aspetti di dettaglio, la Procedura di riferimento

Dettagli

Ministero della Salute

Ministero della Salute Ministero della Salute MATTONE PATIENT FILE Anagrafe delle Persone Fisiche Gianni Maglione Regione Friuli Venezia Giulia Roma 19 giugno 2007 2005 Anagrafe delle Persone Fisiche: il mandato Fornire Linee

Dettagli

Le Raccomandazioni ministeriali per la prevenzione dei rischi in chirurgia: linee di indirizzo regionali di implementazione a livello aziendale

Le Raccomandazioni ministeriali per la prevenzione dei rischi in chirurgia: linee di indirizzo regionali di implementazione a livello aziendale Le Raccomandazioni ministeriali per la prevenzione dei rischi in chirurgia: linee di indirizzo regionali di implementazione a livello aziendale PREMESSA Il Ministero del Lavoro, della Salute e delle Politiche

Dettagli

ARCHIVIO UNICO REGIONALE DEGLI ASSISTITI organizzazione e modalità di gestione

ARCHIVIO UNICO REGIONALE DEGLI ASSISTITI organizzazione e modalità di gestione ARCHIVIO UNICO REGIONALE DEGLI ASSISTITI organizzazione e modalità di gestione Pagina 1 di 55 SOMMARIO Sezione 1 - Gestione dei dati anagrafici dei cittadini a fini sanitari...3 Premessa...4 Scheda n.1:

Dettagli

MANUALE DELLA QUALITÀ Pag. 1 di 6

MANUALE DELLA QUALITÀ Pag. 1 di 6 MANUALE DELLA QUALITÀ Pag. 1 di 6 INDICE GESTIONE DELLE RISORSE Messa a disposizione delle risorse Competenza, consapevolezza, addestramento Infrastrutture Ambiente di lavoro MANUALE DELLA QUALITÀ Pag.

Dettagli

Banca dati Professioniste in rete per le P.A. Guida all uso per le Professioniste

Banca dati Professioniste in rete per le P.A. Guida all uso per le Professioniste Banca dati Professioniste in rete per le P.A. Guida all uso per le Professioniste versione 2.1 24/09/2015 aggiornamenti: 23-set-2015; 24-set-2015 Autore: Francesco Brunetta (http://www.francescobrunetta.it/)

Dettagli

Politica per la Sicurezza

Politica per la Sicurezza Codice CODIN-ISO27001-POL-01-B Tipo Politica Progetto Certificazione ISO 27001 Cliente CODIN S.p.A. Autore Direttore Tecnico Data 14 ottobre 2014 Revisione Resp. SGSI Approvazione Direttore Generale Stato

Dettagli

Allegato B) PROCEDURA PER LA GESTIONE AZIENDALE DEI CASI DI EVENTI SENTINELLA 1. PREMESSA E INDICAZIONI GENERALI

Allegato B) PROCEDURA PER LA GESTIONE AZIENDALE DEI CASI DI EVENTI SENTINELLA 1. PREMESSA E INDICAZIONI GENERALI Allegato B) PROCEDURA PER LA GESTIONE AZIENDALE DEI CASI DI EVENTI SENTINELLA 1. PREMESSA E INDICAZIONI GENERALI In base alla delibera della Giunta Regionale N 225 del 3/4/2006, la direzione sanitaria

Dettagli

MANUALE DI UTILIZZO: INTRANET PROVINCIA DI POTENZA

MANUALE DI UTILIZZO: INTRANET PROVINCIA DI POTENZA MANUALE DI UTILIZZO: INTRANET PROVINCIA DI POTENZA Fornitore: Publisys Prodotto: Intranet Provincia di Potenza http://www.provincia.potenza.it/intranet Indice 1. Introduzione... 3 2. I servizi dell Intranet...

Dettagli

INTRODUZIONE AL MANUALE DELLA QUALITA

INTRODUZIONE AL MANUALE DELLA QUALITA INTRODUZIONE AL MANUALE DELLA QUALITA Elaborazione Verifica Approvazione Il Responsabile Qualità Il Rappresentante della Direzione Il Dirigente Scolastico (.. ) (. ) ( ) Data Data Data Rev Causale (emis./revis.)

Dettagli

PROTOCOLLO D INTESA PER L INSERIMENTO DEI PAZIENTI PSICHIATRICI NELLE RSA e NEI CDI

PROTOCOLLO D INTESA PER L INSERIMENTO DEI PAZIENTI PSICHIATRICI NELLE RSA e NEI CDI PROTOCOLLO D INTESA PER L INSERIMENTO DEI PAZIENTI PSICHIATRICI NELLE RSA e NEI CDI Indice : 1. Scopo del protocollo 2. Invio 3. Verifiche 2.1 tipologia dell utenza 2.2 procedura segnalazione 2.3 procedura

Dettagli

5.1.1 Politica per la sicurezza delle informazioni

5.1.1 Politica per la sicurezza delle informazioni Norma di riferimento: ISO/IEC 27001:2014 5.1.1 Politica per la sicurezza delle informazioni pag. 1 di 5 Motivazione Real Comm è una società che opera nel campo dell Information and Communication Technology.

Dettagli

Obiettivo formativo: Principi, procedure e strumenti per il governo clinico delle attività sanitarie

Obiettivo formativo: Principi, procedure e strumenti per il governo clinico delle attività sanitarie Mostra Dettagli Obiettivo formativo: Principi, procedure e strumenti per il governo clinico delle attività sanitarie Il sistema sanitario è un sistema complesso in cui interagiscono molteplici fattori

Dettagli

SISTEMI DI MISURAZIONE DELLA PERFORMANCE

SISTEMI DI MISURAZIONE DELLA PERFORMANCE SISTEMI DI MISURAZIONE DELLA PERFORMANCE Dicembre, 2014 Il Sistema di misurazione e valutazione della performance... 3 Il Ciclo di gestione della performance... 5 Il Sistema di misurazione e valutazione

Dettagli

COMUNE DI CASAVATORE. Provincia di Napoli REGOLAMENTO DEL PORTALE INTERNET COMUNALE

COMUNE DI CASAVATORE. Provincia di Napoli REGOLAMENTO DEL PORTALE INTERNET COMUNALE COMUNE DI CASAVATORE Provincia di Napoli REGOLAMENTO DEL PORTALE INTERNET COMUNALE INDICE Articolo 1 Oggetto del regolamento e riferimenti normativi Articolo 2 Principi generali Articolo 3 Scopo del portale

Dettagli

Appendice III. Competenza e definizione della competenza

Appendice III. Competenza e definizione della competenza Appendice III. Competenza e definizione della competenza Competenze degli psicologi Lo scopo complessivo dell esercizio della professione di psicologo è di sviluppare e applicare i principi, le conoscenze,

Dettagli

La continuità assistenziale: il modello PAI. Divisione Oncologia Medica

La continuità assistenziale: il modello PAI. Divisione Oncologia Medica La continuità assistenziale: il modello PAI LIVIA DE SIO Divisione Oncologia Medica ACO A.C.O. SanFilippoNeriRoma RETE SANITARIA IN ONCOLOGIA: obiettivi Presa in carico del paziente in modo globale Riconoscimentoi

Dettagli

CARTA DEI SERVIZI. Presentazione. Composizione della medicina in rete. Attività ambulatoriale. Visite domiciliari. Prestazioni. Personale di studio

CARTA DEI SERVIZI. Presentazione. Composizione della medicina in rete. Attività ambulatoriale. Visite domiciliari. Prestazioni. Personale di studio CARTA DEI SERVIZI Presentazione Composizione della medicina in rete Attività ambulatoriale Visite domiciliari Prestazioni Personale di studio Formazione continua dei i medici della medicina in rete Partecipazione

Dettagli

Guida all uso del web service SDMX

Guida all uso del web service SDMX Guida all uso del web service SDMX Introduzione L obiettivo di questo documento è l illustrazione sintetica degli step che tecnicamente bisogna compiere affinché un generico client sia in grado di interagire

Dettagli

SVILUPPO, CERTIFICAZIONE E MIGLIORAMENTO DEL SISTEMA DI GESTIONE PER LA SICUREZZA SECONDO LA NORMA BS OHSAS 18001:2007

SVILUPPO, CERTIFICAZIONE E MIGLIORAMENTO DEL SISTEMA DI GESTIONE PER LA SICUREZZA SECONDO LA NORMA BS OHSAS 18001:2007 Progettazione ed erogazione di servizi di consulenza e formazione M&IT Consulting s.r.l. Via Longhi 14/a 40128 Bologna tel. 051 6313773 - fax. 051 4154298 www.mitconsulting.it info@mitconsulting.it SVILUPPO,

Dettagli

4 Congresso nazionale Società Italiana Telemedicina e sanità elettronica

4 Congresso nazionale Società Italiana Telemedicina e sanità elettronica 4 Congresso nazionale Società Italiana Telemedicina e sanità elettronica Telemedicina: una sfida per la sostenibilità del sistema sanitario Integrazione dei servizi di Telemedicina con il Fascicolo Sanitario

Dettagli

PO 01 Rev. 0. Azienda S.p.A.

PO 01 Rev. 0. Azienda S.p.A. INDICE 1 GENERALITA... 2 2 RESPONSABILITA... 2 3 MODALITA DI GESTIONE DELLA... 2 3.1 DEI NEOASSUNTI... 3 3.2 MANSIONI SPECIFICHE... 4 3.3 PREPOSTI... 4 3.4 ALTRI INTERVENTI FORMATIVI... 4 3.5 DOCUMENTAZIONE

Dettagli

Regione Toscana. ARPA Fonte Dati. Manuale Amministratore. L. Folchi (TAI) Redatto da

Regione Toscana. ARPA Fonte Dati. Manuale Amministratore. L. Folchi (TAI) Redatto da ARPA Fonte Dati Regione Toscana Redatto da L. Folchi (TAI) Rivisto da Approvato da Versione 1.0 Data emissione 06/08/13 Stato DRAFT 1 Versione Data Descrizione 1,0 06/08/13 Versione Iniziale 2 Sommario

Dettagli

COMUNE DI RAVENNA GUIDA ALLA VALUTAZIONE DELLE POSIZIONI (FAMIGLIE, FATTORI, LIVELLI)

COMUNE DI RAVENNA GUIDA ALLA VALUTAZIONE DELLE POSIZIONI (FAMIGLIE, FATTORI, LIVELLI) COMUNE DI RAVENNA Il sistema di valutazione delle posizioni del personale dirigente GUIDA ALLA VALUTAZIONE DELLE POSIZIONI (FAMIGLIE, FATTORI, LIVELLI) Ravenna, Settembre 2004 SCHEMA DI SINTESI PER LA

Dettagli

INDICE PR 13 COMUNICAZIONE E GESTIONE DELLE INFORMAZIONI 1 SCOPO 2 CAMPO DI APPLICAZIONE 3 TERMINOLOGIA E ABBREVIAZIONI 4 RESPONSABILITÀ

INDICE PR 13 COMUNICAZIONE E GESTIONE DELLE INFORMAZIONI 1 SCOPO 2 CAMPO DI APPLICAZIONE 3 TERMINOLOGIA E ABBREVIAZIONI 4 RESPONSABILITÀ PAG 1 /7 INDICE 1 SCOPO 2 CAMPO DI APPLICAZIONE 3 TERMINOLOGIA E ABBREVIAZIONI 4 RESPONSABILITÀ 5 MODALITÀ ESECUTIVE 5.1 Comunicazione verso l'esterno 5.1.1 Utenti dei corsi 5.1.2 Potenziali utenti 5.2

Dettagli

Riepilogo delle modifiche di PA-DSS dalla versione 2.0 alla 3.0

Riepilogo delle modifiche di PA-DSS dalla versione 2.0 alla 3.0 Settore delle carte di pagamento (PCI) Standard di protezione dei dati per le applicazioni di pagamento () Riepilogo delle modifiche di dalla versione 2.0 alla 3.0 Novembre 2013 Introduzione Il presente

Dettagli

SCHEDA PROGETTO PER L IMPIEGO DI VOLONTARI IN SERVIZIO CIVILE IN ITALIA

SCHEDA PROGETTO PER L IMPIEGO DI VOLONTARI IN SERVIZIO CIVILE IN ITALIA (Allegato 1) SCHEDA PROGETTO PER L IMPIEGO DI VOLONTARI IN SERVIZIO CIVILE IN ITALIA ENTE 1) Ente proponente il progetto: Cooperativa Nuovi Sviluppi Via J. Kennedy n. 24 90019 Trabia (PA) P.IVA 04654320821

Dettagli

GUIDA RAPIDA PER LA COMPILAZIONE DELLA SCHEDA CCNL GUIDA RAPIDA PER LA COMPILAZIONE DELLA SCHEDA CCNL

GUIDA RAPIDA PER LA COMPILAZIONE DELLA SCHEDA CCNL GUIDA RAPIDA PER LA COMPILAZIONE DELLA SCHEDA CCNL GUIDA RAPIDA BOZZA 23/07/2008 INDICE 1. PERCHÉ UNA NUOVA VERSIONE DEI MODULI DI RACCOLTA DATI... 3 2. INDICAZIONI GENERALI... 4 2.1. Non modificare la struttura dei fogli di lavoro... 4 2.2. Cosa significano

Dettagli

Archivi e database. Prof. Michele Batocchi A.S. 2013/2014

Archivi e database. Prof. Michele Batocchi A.S. 2013/2014 Archivi e database Prof. Michele Batocchi A.S. 2013/2014 Introduzione L esigenza di archiviare (conservare documenti, immagini, ricordi, ecc.) è un attività senza tempo che è insita nell animo umano Primi

Dettagli

Women In Development UN MODELLO EUROPEO PER LO SVILUPPO LOCALE GENDER ORIENTED PIANO DI COMUNICAZIONE

Women In Development UN MODELLO EUROPEO PER LO SVILUPPO LOCALE GENDER ORIENTED PIANO DI COMUNICAZIONE Women In Development UN MODELLO EUROPEO PER LO SVILUPPO LOCALE GENDER ORIENTED PIANO DI COMUNICAZIONE Introduzione Il progetto W.In D. (Women In Development) si inserisce nelle attività previste e finanziate

Dettagli

MODELLO ORGANIZZATIVO REGIONALE PER LA GESTIONE DEL RISCHIO CLINICO.

MODELLO ORGANIZZATIVO REGIONALE PER LA GESTIONE DEL RISCHIO CLINICO. ALLEGATO A MODELLO ORGANIZZATIVO REGIONALE PER LA GESTIONE DEL RISCHIO CLINICO. il sistema organizzativo che governa le modalità di erogazione delle cure non è ancora rivolto al controllo in modo sistemico

Dettagli

INTESA TRA COMUNE DI MILANO E AZIENDA SANITARIA LOCALE CITTA DI MILANO PER LA SOMMINISTRAZIONE DI FARMACI NEI SERVIZI ALL INFANZIA (0-6 ANNI)

INTESA TRA COMUNE DI MILANO E AZIENDA SANITARIA LOCALE CITTA DI MILANO PER LA SOMMINISTRAZIONE DI FARMACI NEI SERVIZI ALL INFANZIA (0-6 ANNI) INTESA TRA COMUNE DI MILANO E AZIENDA SANITARIA LOCALE CITTA DI MILANO PER LA SOMMINISTRAZIONE DI FARMACI NEI SERVIZI ALL INFANZIA (0-6 ANNI) Al fine di garantire un approccio coordinato alla gestione

Dettagli

Guida all accesso al portale e ai servizi self service

Guida all accesso al portale e ai servizi self service Guida all accesso al portale e ai servizi self service INDICE PREMESSA 2 pag. 1 INTRODUZIONE 2 2 MODALITÀ DI PRIMO ACCESSO 2 2.1 LA CONVALIDA DELL INDIRIZZO DI POSTA ELETTRONICA 2 2.2 L INSERIMENTO DELLA

Dettagli

ALLEGATO. Fase operativa area socio-sanitaria (ASL)

ALLEGATO. Fase operativa area socio-sanitaria (ASL) ALLEGATO PROGETTO DI IMPLEMENTAZIONE DI UN SISTEMA INFORMATIZZATO PER LA DEFINIZIONE DI UN PAI INTEGRATO A FAVORE DI CITTADINI IN CONDIZIONI DI NON AUTOSUFFICIENZA Ne La DGR n. 8243 del 22.10.2008, allegato

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

EXPLOit Content Management Data Base per documenti SGML/XML

EXPLOit Content Management Data Base per documenti SGML/XML EXPLOit Content Management Data Base per documenti SGML/XML Introduzione L applicazione EXPLOit gestisce i contenuti dei documenti strutturati in SGML o XML, utilizzando il prodotto Adobe FrameMaker per

Dettagli

Airone Gestione Rifiuti Funzioni di Esportazione e Importazione

Airone Gestione Rifiuti Funzioni di Esportazione e Importazione Airone Gestione Rifiuti Funzioni di Esportazione e Importazione Airone Funzioni di Esportazione Importazione 1 Indice AIRONE GESTIONE RIFIUTI... 1 FUNZIONI DI ESPORTAZIONE E IMPORTAZIONE... 1 INDICE...

Dettagli

Politica del WHOIS relativa al nome a dominio.eu

Politica del WHOIS relativa al nome a dominio.eu Politica del WHOIS relativa al nome a dominio.eu 1/7 DEFINIZIONI I termini definiti nei Termini e Condizioni e/o nelle Regole di risoluzione delle controversie del.eu sono contraddistinti nel presente

Dettagli

REGOLAMENTO SUL TRATTAMENTO DEI DATI PERSONALI

REGOLAMENTO SUL TRATTAMENTO DEI DATI PERSONALI COMUNE DI VIANO PROVINCIA DI REGGIO EMILIA REGOLAMENTO SUL TRATTAMENTO DEI DATI PERSONALI Approvato con deliberazione di G.C. n. 73 del 28.11.2000 INDICE TITOLO 1 ART. 1 ART. 2 ART. 3 ART. 4 ART. 5 ART.

Dettagli

Il glossario della Posta Elettronica Certificata (PEC) Diamo una definizione ai termini tecnici relativi al mondo della PEC.

Il glossario della Posta Elettronica Certificata (PEC) Diamo una definizione ai termini tecnici relativi al mondo della PEC. Il glossario della Posta Elettronica Certificata (PEC) Diamo una definizione ai termini tecnici relativi al mondo della PEC. Avviso di mancata consegna L avviso, emesso dal sistema, per indicare l anomalia

Dettagli

VERIFICHE E APPROVAZIONI CONTROLLO APPROVAZIONE

VERIFICHE E APPROVAZIONI CONTROLLO APPROVAZIONE VERIFICHE E APPROVAZIONI VERSIONE REDAZIONE CONTROLLO APPROVAZIONE AUTORIZZAZIONE EMISSIONE NOME DATA NOME DATA NOME DATA V01 L. Neri 25/02/2010 C. Audisio 08/03/10 M.Rosati 09/03/10 STATO DELLE VARIAZIONI

Dettagli

ING SW. Progetto di Ingegneria del Software. e-travel. Requisiti Utente. Specifiche Funzionali del Sistema

ING SW. Progetto di Ingegneria del Software. e-travel. Requisiti Utente. Specifiche Funzionali del Sistema Pagina: 1 e-travel ING SW Progetto di Ingegneria del Software e-travel Requisiti Utente Specifiche Funzionali del Sistema e Pagina: 2 di 9 Indice dei contenuti 1 INTRODUZIONE... 3 1.1 SCOPO DEL DOCUMENTO...

Dettagli

Migliorare l informazione e l accesso ai servizi per il cittadino: il ruolo dell Azienda e del Medico di Famiglia

Migliorare l informazione e l accesso ai servizi per il cittadino: il ruolo dell Azienda e del Medico di Famiglia Migliorare l informazione e l accesso ai servizi per il cittadino: il ruolo dell Azienda e del Medico di Famiglia Dr. Alberto Carrera Responsabile Sistema Informativo Aziendale ASL1 Imperiese Dr. Roberto

Dettagli

Struttura documenti del SGQ

Struttura documenti del SGQ pag. 1 di 9 TITOLO Struttura documenti del SGQ Destinatari del documento: Elaborato da: RQ Verificato da: RQ Approvato da: DS Rev. 0 Data: Data: Data: Firma Firma Firma pag. 2 di 9 REVISIONI DEL DOCUMENTO

Dettagli

PROCEDURE - GENERALITA

PROCEDURE - GENERALITA PROCEDURE - GENERALITA Le PROCEDURE sono regole scritte, utili strumenti di buona qualità organizzativa, con le quali lo svolgimento delle attività viene reso il più possibile oggettivo, sistematico, verificabile,

Dettagli

Notiziario settimanale 24-30 giugno 2002. Indirizzi e-mail e invio di pubblicità. Documento dei Garanti UE sul nuovo software Microsoft

Notiziario settimanale 24-30 giugno 2002. Indirizzi e-mail e invio di pubblicità. Documento dei Garanti UE sul nuovo software Microsoft Newsletter Notiziario settimanale Indirizzi e-mail e invio di pubblicità Documento dei Garanti UE sul nuovo software Microsoft Obblighi a tutela della privacy per i gestori Tlc 1 Newsletter 2002 LA SOLA

Dettagli

2. Test di interoperabilità del sistema di gestione della PEC - Punto 1 della circolare 7 dicembre 2006, n. 51.

2. Test di interoperabilità del sistema di gestione della PEC - Punto 1 della circolare 7 dicembre 2006, n. 51. In esito all emanazione della circolare 7 dicembre 2006, n. CR/51 - che disciplina l attività di vigilanza e di controllo svolta da AGID nei confronti dei gestori di Posta Elettronica Certificata (PEC)

Dettagli

Ministero dell Interno

Ministero dell Interno ALLEGATO ALLA CIRCOLARE - FL 7/2012 LINEE GUIDA PER L ISCRIZIONE DEI REVISORI DEI CONTI DEGLI ENTI LOCALI nell elenco, di cui al Decreto del Ministro dell Interno 15 febbraio 2012, n. 23, recante il Regolamento

Dettagli

Ambulatorio Virtuale Medinformatica Sistema On Line per richiedere Appuntamenti e Ricette

Ambulatorio Virtuale Medinformatica Sistema On Line per richiedere Appuntamenti e Ricette Ambulatorio Virtuale Medinformatica Sistema On Line per richiedere Appuntamenti e Ricette Egregio Dottore, Gentile Dottoressa, abbiamo il piacere di presentarle il nuovo sistema informatico per la gestione

Dettagli

CORSO ACCESS PARTE II. Esistono diversi tipi di aiuto forniti con Access, generalmente accessibili tramite la barra dei menu (?)

CORSO ACCESS PARTE II. Esistono diversi tipi di aiuto forniti con Access, generalmente accessibili tramite la barra dei menu (?) Ambiente Access La Guida di Access Esistono diversi tipi di aiuto forniti con Access, generalmente accessibili tramite la barra dei menu (?) Guida in linea Guida rapida Assistente di Office indicazioni

Dettagli

REGOLAMENTO PER L EROGAZIONE DEL BUONO SOCIALE ANZIANI

REGOLAMENTO PER L EROGAZIONE DEL BUONO SOCIALE ANZIANI SETTEMBRE 2008 REGOLAMENTO PER L EROGAZIONE DEL BUONO SOCIALE ANZIANI Relazione tecnica Il presente regolamento è lo strumento di cui si sono dotati i Comuni del Distretto 5, secondo quanto previsto dalla

Dettagli

documento di specifiche tecniche pubblicate sul sito Internet del Ministero all indirizzo www.nsis.salute.gov.it. ;

documento di specifiche tecniche pubblicate sul sito Internet del Ministero all indirizzo www.nsis.salute.gov.it. ; documento di specifiche tecniche pubblicate sul sito Internet del Ministero all indirizzo www.nsis.salute.gov.it. ; g) al paragrafo 3.1. Alimentazione del Sistema informativo, la tabella 2: alimentazione

Dettagli

STATUTO DELL AZIENDA OSPEDALIERO-UNIVERSITARIA MEYER INDICE SEZIONE

STATUTO DELL AZIENDA OSPEDALIERO-UNIVERSITARIA MEYER INDICE SEZIONE STATUTO DELL AZIENDA OSPEDALIERO-UNIVERSITARIA MEYER INDICE SEZIONE Titolo 3 - PROGRAMMAZIONE E SVILUPPO DELLA RETE PEDIATRICA REGIONALE Art. 20 - Art. 21 - Art. 22 - Art. 23 - Art. 24 - Art. 25 - Verso

Dettagli

4.6 APPROVVIGIONAMENTO

4.6 APPROVVIGIONAMENTO Unione Industriale 43 di 94 4.6 APPROVVIGIONAMENTO 4.6.1 Generalità Il capitolo indica le modalità con le quali la filatura conto terzi deve gestire il rapporto di subfornitura nell ambito di un sistema

Dettagli

PG03.GTP GESTIONE DEI DOCUMENTI DI LAVORO

PG03.GTP GESTIONE DEI DOCUMENTI DI LAVORO Pagina n. 1 di 7 APAT L.93/01 - progetto a gestione diretta di APAT : circuiti di interconfronto per l individuazione di un gruppo tecnico permanente regionale o multi regionale (GTP) per il monitoraggio

Dettagli

INFORMATIVA DELL INIZIATIVA CARTA ROMA

INFORMATIVA DELL INIZIATIVA CARTA ROMA INFORMATIVA DELL INIZIATIVA CARTA ROMA Informativa dell iniziativa Carta Roma realizzata dall Amministrazione di Roma Capitale - Dipartimento Promozione dei Servizi Sociali e della Salute Viale Manzoni,

Dettagli

AZIENDA SANITARIA LOCALE TO1 - SC MEDICINA LEGALE - OBITORIO CIVICO

AZIENDA SANITARIA LOCALE TO1 - SC MEDICINA LEGALE - OBITORIO CIVICO AZIENDA SANITARIA LOCALE TO1 - SC MEDICINA LEGALE - OBITORIO CIVICO PROCEDURA PR02 - Audit Interni Edizione 1 Approvata dal Direttore della SC Medicina Legale Emessa dal Referente Aziendale per la Qualità

Dettagli

INDICE. Istituto Tecnico F. Viganò PROCEDURA PR 01. Rev. 2 Data 20 Maggio 2009. Pagina 1 di 9 TENUTA SOTTO CONTROLLO DEI DOCUMENTI

INDICE. Istituto Tecnico F. Viganò PROCEDURA PR 01. Rev. 2 Data 20 Maggio 2009. Pagina 1 di 9 TENUTA SOTTO CONTROLLO DEI DOCUMENTI INDICE 1 di 9 1. SCOPO 2. CAMPO DI APPLICAZIONE 3. TERMINOLOGIA E ABBREVIAZIONI 4. RESPONSABILITÀ 5. MODALITÀ OPERATIVE 5.1. Redazione e identificazione 5.2. Controllo e verifica 5.3. Approvazione 5.4.

Dettagli

Manuale della qualità. Procedure. Istruzioni operative

Manuale della qualità. Procedure. Istruzioni operative Unione Industriale 19 di 94 4.2 SISTEMA QUALITÀ 4.2.1 Generalità Un Sistema qualità è costituito dalla struttura organizzata, dalle responsabilità definite, dalle procedure, dai procedimenti di lavoro

Dettagli

AUDIT. 2. Processo di valutazione

AUDIT. 2. Processo di valutazione AUDIT 2. Processo di valutazione FASE ATTIVITA DESCRIZIONE Inizio dell'audit Inizio dell attività Costituzione del gruppo di valutazione sulla base delle competenze generali e specifiche e dei differenti

Dettagli

La tua guida per accedere al Fascicolo Sanitario Elettronico (FSE)

La tua guida per accedere al Fascicolo Sanitario Elettronico (FSE) La tua guida per accedere al Fascicolo Sanitario Elettronico (FSE) GESTIONE ACCESSO SEMPLIFICATO AI SERVIZI (GASS) Di cosa si tratta? È una nuova modalità di accesso online ai servizi socio-sanitari, tramite

Dettagli

MANUALE MOODLE STUDENTI. Accesso al Materiale Didattico

MANUALE MOODLE STUDENTI. Accesso al Materiale Didattico MANUALE MOODLE STUDENTI Accesso al Materiale Didattico 1 INDICE 1. INTRODUZIONE ALLA PIATTAFORMA MOODLE... 3 1.1. Corso Moodle... 4 2. ACCESSO ALLA PIATTAFORMA... 7 2.1. Accesso diretto alla piattaforma...

Dettagli

Michele Bonamigo Amministratore Unico

Michele Bonamigo Amministratore Unico Michele Bonamigo Amministratore Unico La Società La società, di recente costituzione, è a tutti gli effetti una start-up Ha l obiettivo di proporre soluzioni di nicchia nel mondo della sanità Per lo sviluppo

Dettagli

Informativa sulla privacy

Informativa sulla privacy Informativa sulla privacy Data di inizio validità: 1 Maggio 2013 La presente informativa sulla privacy descrive il trattamento dei dati personali immessi o raccolti sui siti nei quali la stessa è pubblicata.

Dettagli

Istruzione Operativa Richiesta di Offerta on-line in busta chiusa digitale

Istruzione Operativa Richiesta di Offerta on-line in busta chiusa digitale Istruzione Operativa Richiesta di Offerta on-line in busta chiusa digitale ATAF avvierà la gara on-line secondo le modalità di seguito descritte, in particolare utilizzando lo strumento RDO on-line disponibile

Dettagli

CP Customer Portal. Sistema di gestione ticket unificato

CP Customer Portal. Sistema di gestione ticket unificato CP Customer Portal Sistema di gestione ticket unificato Sommario CP Customer Portal...1 Sistema di gestione ticket unificato...1 Sommario...2 Flusso gestione ticket...3 Modalità di apertura ticket...3

Dettagli

PROCEDURA DI SISTEMA GESTIONE E ORGANIZZAZIONE DELLA DOCUMENTAZIONE

PROCEDURA DI SISTEMA GESTIONE E ORGANIZZAZIONE DELLA DOCUMENTAZIONE Pagina 1 di 7 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. ALLEGATI

Dettagli

IL CICLO DI VITA DEL PROGETTO. Elementi essenziali di progetto. Fasi e tappe Gli Approcci

IL CICLO DI VITA DEL PROGETTO. Elementi essenziali di progetto. Fasi e tappe Gli Approcci UNIVERSITA MILANO BICOCCA Corso di laurea di primo livello in servizio sociale anno accademico 2009-2010 Progettare il sociale Prof. Dario A. Colombo IL CICLO DI VITA DEL PROGETTO Elementi essenziali di

Dettagli

PROCEDURA APERTA PER L AFFIDAMENTO DELLA REALIZZAZIONE DI UN APP PER LA PRENOTAZIONE DELLE PRESTAZIONI SANITARIE E SERVIZI CONNESSI.

PROCEDURA APERTA PER L AFFIDAMENTO DELLA REALIZZAZIONE DI UN APP PER LA PRENOTAZIONE DELLE PRESTAZIONI SANITARIE E SERVIZI CONNESSI. Allegato 1) PROCEDURA APERTA PER L AFFIDAMENTO DELLA REALIZZAZIONE DI UN APP PER LA PRENOTAZIONE DELLE PRESTAZIONI SANITARIE E SERVIZI CONNESSI Allegato tecnico Introduzione Si richiede di realizzare una

Dettagli

Manuale Operatore Punto Assistito Salute. FSE (Fascicolo Sanitario Elettronico)

Manuale Operatore Punto Assistito Salute. FSE (Fascicolo Sanitario Elettronico) Manuale Operatore Punto Assistito Salute FSE (Fascicolo Sanitario Elettronico) Versione 3.0.0 1 Sommario Introduzione 3 Autenticazione e accesso 3 Scelta ruolo 6 Ricerca del cittadino 6 Homepage del FSE

Dettagli

GESTIONE DEI DOCUMENTI, DEI DATI E DELLE REGISTRAZIONI

GESTIONE DEI DOCUMENTI, DEI DATI E DELLE REGISTRAZIONI Pagina 1 di 5 0. INDICE 0. INDICE... 1 1. SCOPO E CAMPO DI APPLICAZIONE... 2 2. RIFERIMENTI... 2 3. MODALITÀ OPERATIVE... 2 3.1 Emissione... 2 3.2 Identificazione... 3 3.3 Distribuzione... 3 3.4 Modifica

Dettagli

Database. Si ringrazia Marco Bertini per le slides

Database. Si ringrazia Marco Bertini per le slides Database Si ringrazia Marco Bertini per le slides Obiettivo Concetti base dati e informazioni cos è un database terminologia Modelli organizzativi flat file database relazionali Principi e linee guida

Dettagli

1. Introduzione e finalità delle Linee guida

1. Introduzione e finalità delle Linee guida LINEE GUIDA PER L ACQUISTO DI TRATTAMENTI ALL ESTERO - Versione finale, 09.11.2005 1. Introduzione e finalità delle Linee guida Il Gruppo ad alto livello sui servizi sanitari e l'assistenza medica ha deciso

Dettagli

Gestione Turni. Introduzione

Gestione Turni. Introduzione Gestione Turni Introduzione La gestione dei turni di lavoro si rende necessaria quando, per garantire la continuità del servizio di una determinata struttura, è necessario che tutto il personale afferente

Dettagli

I SERVIZI ONLINE E MOBILE

I SERVIZI ONLINE E MOBILE I SERVIZI ONLINE E MOBILE Focus servizi on line UniSalute: registrazione Sul sito www.unisalute.it per accedere alle funzionalità dell area riservata è necessario inserire user e password personali nel

Dettagli

Light CRM. Documento Tecnico. Descrizione delle funzionalità del servizio

Light CRM. Documento Tecnico. Descrizione delle funzionalità del servizio Documento Tecnico Light CRM Descrizione delle funzionalità del servizio Prosa S.r.l. - www.prosa.com Versione documento: 1, del 11 Luglio 2006. Redatto da: Michela Michielan, michielan@prosa.com Revisionato

Dettagli

I flussi ed i sistemi informativi come strumento di valorizzazione e di monitoraggio del sistema di assistenza territoriale a garanzia dei LEA

I flussi ed i sistemi informativi come strumento di valorizzazione e di monitoraggio del sistema di assistenza territoriale a garanzia dei LEA I flussi ed i sistemi informativi come strumento di valorizzazione e di monitoraggio del sistema di assistenza territoriale a garanzia dei LEA Vito Bavaro Ufficio Sistemi Informativi e Flussi Informativi

Dettagli

FONDO UNICO NAZIONALE PER L ASSICURAZIONE CONTRO I RISCHI DI NON AUTOSUFFICIENZA DEI DIPENDENTI DEL SETTORE ASSICURATIVO

FONDO UNICO NAZIONALE PER L ASSICURAZIONE CONTRO I RISCHI DI NON AUTOSUFFICIENZA DEI DIPENDENTI DEL SETTORE ASSICURATIVO FONDO UNICO NAZIONALE PER L ASSICURAZIONE CONTRO I RISCHI DI NON AUTOSUFFICIENZA DEI DIPENDENTI DEL SETTORE ASSICURATIVO RICHIESTA DI RICONOSCIMENTO DELLA PERDITA DI AUTOSUFFICIENZA (da inviare a mezzo

Dettagli

Allegato C REQUISITI ALTRI SERVIZI ALLA PERSONA. Requisiti Altri servizi alla persona

Allegato C REQUISITI ALTRI SERVIZI ALLA PERSONA. Requisiti Altri servizi alla persona REQUISITI ALTRI SERVIZI ALLA PERSONA Requisiti Altri servizi alla persona Note per la compilazione delle schede dei requisiti Il legale rappresentante o l'operatore individuale compila una scheda dei requisiti

Dettagli