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

Transcript

1 GDL-O Documenti Clinici Specifiche tecniche CDA2 Medicina di laboratorio Centro Veneto Ricerca e Innovazione per la Sanità Digitale pag. 1 di 101

2 Informazioni preliminari Contatti Per ulteriori informazioni, si prega di contattare: Ing. Federica Sandri Viale Oberdan, Treviso Tel Cell fsandri@consorzioarsenal.it Controllo del documento N. documento: CDA2 Medicina di Laboratorio Documenti Clinici v2.0 Stato di avanzamento: versione 2.0 Data di prima emissione: 24/04/13 Ultimo Aggiornamento: 25/08/13 Revisione: versione 2.0 Numero di pagine: 101 Responsabile del documento: Coordinatore della stesura: Autori: Claudio Saccavini Federica Sandri Federica Sandri Elena Vio Elena Martignago pag. 2 di 101

3 Status del documento Versione Status Data Descrizione Modifica 0.1 BOZZA 24/04/2013 Versione 0.1 in attesa di revisione del GDL-O 1.0 Public Comment 18/06/2013 Versione Public Comment 2.0 Versione definitiva 25/07/2013 Versione definitiva in approvazione Unità di Regia pag. 3 di 101

4

5 INDICE Acronimi e definizioni... 11! Introduzione... 13! Iter di approvazione documentale... 14! Summary... 16! L obiettivo del presente documento è quello di definire, secondo lo standard HL7 CDA Rel 2.0, una guida all implementazione per il CDA del Rapporto di Medicina di Laboratorio valido tanto nel contesto Italiano, quanto in quello regionale ! In appendice sono riportate due tabelle contenenti la valorizzazione degli ID e OID necessaria alla corretta strutturazione del documento ! 1.! Il referto... 16! 1.1! Gli standard Tecnologici: il CDA... 16! 1.1.1! Open issues 16! 1.1.2! Obiettivi del CDA nel progetto 16! 1.1.3! Descrizione del CDA 17! 1.1.4! Strutturazione del CDA 17! 1.1.5! Header 19! ! Sezioni dell Header: dati generici legati alla tipologia di documento e alla sua generazione!"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""!#$! ! Elementi speciali: translation e qualifier!""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""!#%! ! Sezioni dell Header: dati legati al soggetto della prestazione!"""""""""""""""""""""""""""""""""""""""""""""!#&! ! Sezioni dell Header: dati legati al custode del documento!""""""""""""""""""""""""""""""""""""""""""""""""""!%'! ! Sezioni dell Header: dati legati all autore ed autenticatore del documento!""""""""""!%#! ! Sezioni dell Header: dati legati al validatore del documento!"""""""""""""""""""""""""""""""""""""""""""""!%(! ! Sezioni dell Header: dati legati al soggetto che trasforma il testo dettato nel documento CDA!""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""!%)! ! Sezioni dell Header: dati legati ai soggetti partecipanti alla realizzazione del documento!"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""!%)! ! Sezioni dell Header: dati legati ai soggetti destinatari di una copia del documento!"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""!%*! ! Sezioni dell Header: dati legati alla prescrizione!"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""!%+! ! Sezioni dell Header: dati legati alla prestazione eseguita!""""""""""""""""""""""""""""""""""""""""""""""""""""!&'! ! Sezioni dell Header: dati legati al versionamento del documento!"""""""""""""""""""""""""""""""!&%! ! Sezioni dell Header: dati legati al consenso all utilizzo da parte di altre strutture sanitarie! &(! ! Sezioni dell Header: dati legati all incontro tra l assistito e la struttura sanitaria nel quale è avvenuto l atto documentato!""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""!&)! pag. 5 di 101

6 1.1.6! Body 49! ! Il referto di laboratorio!""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""!($! 1.2! Lo standard di interoperabilità clinica: LOINC... 65! 1.2.1! Open issues 65! 1.2.2! Introduzione 65! 1.2.3! Scenario: codifiche utilizzate in laboratorio 65! 1.2.4! Definizione LOINC 66! 1.2.5! Obiettivi nell applicazione della codifica LOINC 66! 1.2.6! Metodologia applicata per la codifica LOINC 67! 1.2.7! Stato dell arte nell applicazione della codifica LOINC 69! 1.2.8! Strutturazione delle codifiche LOINC all interno del Body del CDA2 69! ! Dettaglio della struttura di un observation nel caso sia necessario riportare doppia unità di misura (focus utilizzo codifica LOINC)!"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""!,$! APPENDICE A Data Type... 72! APPENDICE B Uso delle variabili per la produzione di CDA... 75! APPENDICE C Esempi di utilizzo componenti Body CDA... 79! APPENDICE D Vocabolari... 83! APPENDICE E extension di Aziende e Presidi... 85! APPENDICE F Esempi di strutturazione... 91! APPENDICE G- OID ! APPENDICE H- ID CDA2 LAB ! BIBLIOGRAFIA ! pag. 6 di 101

7 INDICE DELLE IMMAGINI Figura 1 Iter di approvazione documentale... 14! Figura 2- Rappresentazione grafica di un documento CDA... 18! Figura 3- Struttura Body CDA del referto di laboratorio... 51! Figura 4- Associazioni tra codici interni e codici LOINC... 67! pag. 7 di 101

8 INDICE DELLE TABELLE Tabella 1 Principali componenti di un documento CDA... 18! Tabella 2 Legenda dei colori delle tabelle descrittive del CDA... 20! Tabella 3 Primo blocco dell'header: dati generici legati alla tipologia di documento e alla sua generazione... 22! Tabella 4 Possibili valorizzazioni degli attributi dell'elemento ClinicalDocument/code 23! Tabella 5 Specialità di Laboratorio... 23! Tabella 6 Elementi opzionali translation e qualifier che specificano l elemento code 24! Tabella 7 Secondo blocco dell Header: dati legati al soggetto della prestazione... 28! Tabella 8 Possibili valorizzazioni dell attributo use... 28! Tabella 9 Possibili valorizzazioni degli attributi dell'elemento ClinicalDocument/ recordtarget/ patientrole/ id... 29! Tabella 10 Possibili valorizzazioni dell'attributo extension dell elemento ClinicalDocument/ recordtarget/ patient Role/ providerorganization/ Id... 30! Tabella 11 Terzo blocco dell Header: dati legati al custode del documento... 31! Tabella 12 Quarto blocco dell Header: dati legati all autore del documento... 33! Tabella 13 Quinto blocco dell Header: dati legati all autenticatore del documento. 34! Tabella 14 Sesto blocco dell Header: dati legati al validatore del documento... 35! Tabella 15 Settimo blocco dell Header: dati legati al trascrittore del documento... 36! Tabella 16 Ottavo blocco dell Header: dati legati ai soggetti partecipanti alla realizzazione del documento... 37! Tabella 17 Nono blocco dell Header: dati legati ai soggetti destinatari di una copia del documento... 39! Tabella 18 Decimo blocco dell Header: dati legati alla prescrizione... 41! Tabella 19 Undicesimo blocco dell Header: dati legati alla prestazione eseguita... 43! pag. 8 di 101

9 Tabella 20 Dodicesimo blocco dell Header: dati legati al versionamento del documento... 44! Tabella 21 Possibili valorizzazioni dell elemento ClinicalDocument/ relateddocument/ typecode... 45! Tabella 22 Tredicesimo blocco dell Header: dati legati al consenso all uso del documento da parte delle altre aziende sanitarie... 46! Tabella 23 Quattordicesimo blocco dell Header: dati legati all evento scatenante la generazione del documento... 48! Tabella 24 Possibili valorizzazioni dell elemento ClinicalDocument/ componentof/ ecompassingencounter/ encounterparticipant/ typecode... 48! Tabella 25 Principali componenti del Body... 49! Tabella 26 Elementi che compongono l'identificativo della specialità dell'osservazione <code>... 53! Tabella 27 Tipologie di collegamento all'interno del <text>... 53! Tabella 28 Elementi presenti nell'<organizer> CLUER... 61! Tabella 29 Elementi presenti nell'<organizer> BATTERY... 62! Tabella 30 Elementi presenti nell'osservazione singola: <observation>... 64! Tabella 31 Data type... 74! Tabella 32 Variabili per produrre il CDA... 77! Tabella 33 codifiche degli allegati multimediali... 83! Tabella 34 simboli usati per le unità di misura... 84! Tabella 35 OID dei vocabolari... 84! Tabella 36 OID degli schemi di identificazione esterna... 84! Tabella 37 OID degli schemi di identificazione esterna... 84! Tabella 38 Possibili valorizzazioni degli attributi che caratterizzano l ID di un Azienda o di un Presidio... 85! Tabella 39 Extension delle aziende e presidi secondo il Ministero della Salute... 89! pag. 9 di 101

10

11 Acronimi e definizioni CDA Clinical Document Architecture HL7 Health Level Seven IHE FSE r NRE MMG PLS TS SAR SAC Integrating the Healthcare Enterprise Fascicolo Sanitario Elettronico Regionale Numero di Ricetta Elettronica Medico di Medicina Generale Pediatra di Libera Scelta Tessera Sanitaria Sistema di Accoglienza Regionale Sistema di Accoglienza Centrale pag. 11 di 101

12

13 Introduzione Il presente documento di linee guida è stato redatto all interno del GDL-O Documenti Clinici, gruppo di lavoro operativo del progetto Fascicolo Sanitario Elettronico Regionale. Il documento riprende quanto già definito e realizzato dal progetto regionale Veneto ESCAPE. Viene presentato di seguito l iter di approvazione documentale a cui la documentazione redatta da all interno del progetto FSEr dovrà essere sottoposta. pag. 13 di 101

14 Iter di approvazione documentale Figura 1 Iter di approvazione documentale v 0.n! ATUS BOZZA! il documento è stato redatto all interno del GDL-O di competenza, le modifiche e i commenti devono essere inviati all indirizzo del coordinatore alla stesura del presente documento (riferimento paragrafo Informazioni generali Contatti in incipit al presente documento) integrati i commenti e/o le eventuali modifiche del GDL-O vengono redatte le varie versioni v 0.n. Una volta definita una v 0.n definitiva all interno del GDL-O, questo ha 15 gg per apportare ulteriori modifiche sempre inviandole all indirizzo del coordinatore alla stesura. v 1.n! ATUS PUBBLIC COMMENT! il documento in formato PDF viene pubblicato sul sito di e attraverso lo strumento del FORUM tutta la comunità di pag. 14 di 101

15 può lasciare un proprio commento al documento pubblicato. I commenti saranno rilasciati seguendo delle specifiche istruzioni, disponibili sul sito di. Il periodo di pubblic comment durerà 30 gg. Durante il periodo di public comment analizzerà i commenti rilasciati, proponendo una possibile soluzione. Ogni commento e la relativa risposta rimarranno visibili all intera comunità che potrà intervenire nella discussione. Alla fine del periodo di public comment tutti i commenti analizzati da verranno sottoposti al GDL-O di competenza. In caso di approvazione i cambiamenti verranno integrati al documento di riferimento. Il GDL-O di competenza valuterà la rilevanza dei cambiamenti apportati al documento e deciderà l eventuale pubblicazione dello stesso per un ulteriore periodo di public comment (pubblicazione v 1.n). L iter di pubblicazione e revisione si conclude nel momento in cui non sono apportati cambiamenti sostanziali al documento secondo decisione del GDL-O di competenza. La versione definitiva andrà quindi in approvazione al TSE-R e all Unità di Regia. v 2.0! APPROVATO! il documento in formato PDF approvato dall Unità di Regia sarà reso pubblico. pag. 15 di 101

16 Summary L obiettivo del presente documento è quello di definire, secondo lo standard HL7 CDA Rel 2.0, una guida all implementazione per il CDA del Rapporto di Medicina di Laboratorio valido tanto nel contesto Italiano, quanto in quello regionale. In appendice sono riportate due tabelle contenenti la valorizzazione degli ID e OID necessaria alla corretta strutturazione del documento. 1. Il referto All interno di questa sezione saranno rinvenibili gli approfondimenti degli aspetti meramente tecnologici legati alla redazione di un referto, operati attraverso l analisi della struttura di un documento clinico che necessiti di essere interscambiato. 1.1 Gli standard Tecnologici: il CDA Open issues Sviluppo delle specifiche per il body del referto generico e del referto radiologico Obiettivi del CDA nel progetto Per consentire l utilizzo delle informazioni raccolte in contesti clinico-scientifico internazionali, utilizzando gli standard ICT-Medicali, la piattaforma tecnologica definita da HL7 permette di definire una struttura di documento clinico interscambiabile. Il CDA (Clinical Document Architecture), standard della famiglia HL7, ha raggiunto ormai una strutturazione stabile ed è utilizzato proprio per scambiare informazioni tra entità extra-aziendali. L obiettivo di questa sezione del documento è descrivere le modalità di creazione del documento informatico di referto secondo lo standard HL7 CDA Rel 2.0 nel rispetto delle indicazioni fornite dal Tavolo permanente di Sanità Elettronica afferente al Dipartimento per la Digitalizzazione della Pubblica Amministrazione e l Innovazione Tecnologica secondo il quale il documento di referto deve essere strutturato in varie forme, in base al tipo di informazione in esso memorizzate ovvero in base al fatto che si tratti di referto generico, di laboratorio e radiologico. Non è invece obiettivo di questo paragrafo spiegare nel dettaglio tutti i componenti del referto strutturato secondo lo standard HL7 CDA Rel. 2, bensì quello di fornire indicazioni di massima per supportare il lettore all approccio di documenti più specifici indicati nella bibliografia, poiché si rischierebbe di ripetere quanto già detto nei documenti stessi. pag. 16 di 101

17 1.1.3 Descrizione del CDA La diffusione capillare della refertazione in formato digitale e la consegna on-line dei referti richiedono interventi di armonizzazione sul formato standard del referto, per garantire modalità di interscambio del dato indipendente dalle piattaforme. Lo standard HL7 Clinical Document Archietecture (CDA) Rel. 2.0 risulta quindi necessario alla strutturazione di un documento clinico che faciliti lo scambio di informazioni cliniche tra i vari attori che concorrono all erogazione dei servizi sanitari. Un documento CDA è un oggetto informativo strutturato in grado di contenere testi immagini, suoni ed altri contenuti multimediali. Esso è composto da differenti blocchi informativi che veicolano informazioni relative ad esempio al paziente, al medico, alla struttura sanitaria, all autore del documento, al firmatario del documento, agli eventi clinici, alle osservazioni o alle procedure mediche a cui il documento si riferisce. Ogni documento peraltro DEVE essere, come prescrive lo standard, human readable e quindi in grado di essere visualizzato in maniera algoritmica dal ricevente del documento senza la necessità di conoscerne le specificità. Da un punto di vista tecnico, la struttura dei documenti CDA deriva in modo formale dal Reference Information Model (RIM) di HL7 versione 3. L utilizzo formale del RIM di HL7v3 garantisce la flessibilità necessaria anche in relazione alle future evoluzioni dello standard fornendo un modello per l implementazione di documenti strutturati. Lo standard CDA si presta alla rappresentazione di diverse tipologie di documenti clinici fornendo peraltro un elevato grado di flessibilità nelle modalità di rappresentazione di concetti. In tale contesto è quindi necessario, anche in funzione delle specificità del paese nella gestione delle informazioni e processi sanitari, adattare lo standard in relazione ai singoli oggetti informativi che si vuole rappresentare (ad es.: prescrizione farmaceutica, prescrizione specialistica, referto, lettera di dimissione, ) fornendo per ciascuno di questi il dettaglio relativo alla modalità di rappresentazione in CDA dei concetti, delle informazioni e delle codifiche in essi contenute Strutturazione del CDA Un documento CDA è composto da una serie di blocchi logici caratterizzati da uno specifico significato semantico. È opportuno precisare che lo standard CDA fornisce un modello astratto per la rappresentazione delle informazioni cliniche ed assolutamente indipendente dalle modalità specifiche di realizzazione/serializzazione. La rappresentazione in formato XML è solo una delle possibili modalità di implementazione, o per meglio dire, l unica per la quale HL7 abbia attualmente fornito una guida di implementazione. pag. 17 di 101

18 La rappresentazione in formato XML delle classi del documento CDA segue l XML Implementation Technology Specification (ITS) V3, che descrive le modalità di serializzazione dei concetti, datatype e vocabolari astratti di HL7 nello specifico formato tecnologico XML. SEZIONE Root del documento CDA Header SCOPO ClinicalDocument è l elemento root per la struttura XML che rappresenta il documento CDA. Ogni documento deve iniziare con questo elemento comprendente gli attributi xsi:schemalocation, xmlns e xmlsn:xsi. Identifica e classifica il documento dando informazioni sull autenticazione, sul paziente, sull evento di cura e sugli attori sanitari coinvolti Contiene il report clinico e può alternativamente contenere un corpo non CDA Body strutturato o un insieme di markup che ne descrivono il contenuto Tabella 1 Principali componenti di un documento CDA!"#$%&'(")*!+!"#$"%!"#$!"#$%&'!"#!"#$%"$#&'()*+,-!"##"$%&'!"#$%!"#$!"#"!"#$%"$#&'!"##$%#&% Figura 2- Rappresentazione grafica di un documento CDA pag. 18 di 101

19 1.1.5 Header I documenti CDA sono documenti XML composti da un intestazione, denominata Header, e da un corpo, denominato Body. L intestazione del documento contiene delle informazioni che permettono l indicizzazione e la ricerca del documento stesso secondo alcuni attributi comuni e condivisi. Caratteristiche essenziali del documento CDA sono: Persistenza: un documento clinico continua ad esistere in uno stato inalterato per un periodo di tempo definito da leggi o regolamenti locali; Autorità assegnata: gestione responsabile delle risorse, un documento clinico è mantenuto da un'organizzazione responsabile; Potenziale per l'autenticazione: un documento clinico è una raccolta di informazioni che possono essere autenticate giuridicamente; Contesto: un documento clinico stabilisce il contesto predefinito per i suoi contenuti; Interezza: l'autenticazione di un documento clinico viene applicata all'intero e non a porzioni del documento; Leggibilità umana: un documento clinico è leggibile da un umano e non solo da una macchina. L header, quindi, identifica e classifica il documento fornendo informazioni sull autenticazione, gli attori sanitari, il paziente e i fornitori di prestazioni sanitarie. Nei sottoparagrafi che seguono, vengono presentati in modo essenziale tutti gli elementi dei documenti CDA ed i loro attributi suddivisi nei blocchi che è possibile individuare all interno dell Header. In APPENDICE A sono riportate per esteso le tipologie di dato indicate nelle tabelle per gli elementi e loro attributi, mentre in APPENDICE B sono indicate le possibili variabili da sostituire all interno del documento CDA. Dalla definizione della struttura del documento CDA, talvolta possono essere omessi alcuni attributi degli elementi ed i relativi valori poiché già esplicitati in precedenza nello stesso tipo di elementi e a meno che la loro specificazione non sia assolutamente necessaria. Gli OID utilizzati per alcuni codici nel documento non sono ancora assegnati o possono non avere in alcuni casi, la struttura corretta. Le codifiche ufficiali e le loro pag. 19 di 101

20 modifiche DEVONO essere richieste direttamente alle organizzazioni o agli enti competenti. Colore Significato Elemento del CDA Attributi dell elemento che precede Valorizzazione costante dell attributo stabilita per il CDA Dati specifici dell azienda ULSS/AO produttrice del referto Dati specifici per il paziente Tabella 2 Legenda dei colori delle tabelle descrittive del CDA Sezioni dell Header: dati generici legati alla tipologia di documento e alla sua generazione No Element Name # Tipo Valore attributo Descrizione/commenti sull'elemento o attributo 1 realmcode 1..1 Dominio di appartenenza del documento 2 code 1..1 IT 3 typeid 1..1 II Indica che il documento è strutturato secondo le specifiche di HL7-CDA Rel root 1..1 UID Object Identifier di HL7 per i modelli registrati 5 extension 1..1 POCD_HD Codifica identificativa del "CDA Rel 2 Hierarchical Description" che è lo schema che contiene la gerarchia delle classi di un documento CDA 6 templateid 1..1 Identifica la specifica versione del template di riferimento che deve essere utilizzata dal document consumer per la validazione del documento corrente 7 root 1..1 UID OID dell'ente che manutiene gli schemi dei template di documento per la sanità elettronica 8 extension 0..1 $VEREMP$ Nome del template 9 assigningauthorityname 0..1 $AUTHORITY$ 10 Id 1..1 II 11 root 1..1 UID $OID root dell'azienda$.$identificativi dei documenti di laboratorio$ Identifica univocamente il documento Identificativo univoco del dominio di identificazione dei documenti. Tale identificativo, riconosciuto pubblicamente, garantisce l'univocità dell'istanza dell'identificativo a livello globale o internazionale pag. 20 di 101

21 No Element Name # Tipo Valore attributo Descrizione/commenti sull'elemento o attributo $IDDOC$ Estensione dell'identificativo univoco all'interno del dominio di identificazione, generato dal client 12 extension 1..1 dell'autore secondo regole es condivise in modo da evitare collisioni all'interno del medesimo dominio di competenza (ULSS/AO) 13 displayable 0..1 BL TRUE Permette la visibilità del dato nel rendering $AUTHORITY$ Nome che identifica 14 assigningauthorityname 0..1 l'autorità che fornisce es. "ASL 5 di Montalbano Jonico l'extension (ULSS/AO di (MT)" competenza) 15 code 1..1 CE Indica la tipologia di documento Codice che identifica la tipologia di documento a cui il CDA si riferisce (prescrizione, tipologia $CODELOINC$ referto, lettera di dimissione, 16 code 1..1 patient summary). Il valore es DEVE fare riferimento al sistema di codifica LOINC o, in assenza di codici specifici, ad un'ulteriore codifica condivisa 17 codesystem 1..1 UID OID del sistema di codifica dei codici di documento LOINC 18 codesystemname 1..1 LOINC Nome del vocabolario 19 codesystemversion 0..1 es Versione del vocabolario LOINC di riferimento 20 displayname 0..1 $CODENAMELOINC$ Descrizione del codice es. Referto di Laboratorio 21 title 0..1 Referto di Laboratorio É opzionale ma necessario quando il documento deve essere visualizzato tramite style-sheet 22 effectivetime 1..1 Data di creazione del documento CDA 23 value 1..1 TS [yyyymmddhhmmss+ -ZZzz] Il valore deve essere quello del client utilizzato dal document source, opportunamente certificato. DEVE avere la precisione almeno del secondo. Le ore devono essere riportate nell'intervallo 00:00:00-23:59:59. ZZzz rappresenta l'offset rispetto al tempo di Greenwich (in Italia per l'ora solare e per l'ora legale) pag. 21 di 101

22 No Element Name # Tipo Valore attributo Descrizione/commenti sull'elemento o attributo 24 confidentialitycode 1..1 CE Livello di riservatezza del documento 25 code 1..1 CS N o R o V N = normal; R = restricted; V = very restricted 26 codesystem 1..1 UID OID del sistema di codifica 27 codesystemname 1..1 HL7 Confidentiality Nome del sistema di codifica utilizzato 28 displayname 1..1 Normale o Accesso ristretto o Accesso molto ristretto 29 languagecode 1..1 Indica la lingua in cui è redatto il documento 30 code 1..1 CS it-it Codice conforme alle specifiche dell'ietf (Internet Engineering Task Force) RFC 3066 (OID: ) 31 setid 1..1 II Ha valore costante tra le diverse versioni del medesimo documento 32 root 1..1 UID root del ClinicalDocument/id Identificativo univoco del dominio di identificazione dei documenti. Tale identificativo, riconosciuto pubblicamente, garantisce l'univocità dell'istanza dell'identificativo a livello globale 33 extension 1..1 $IDDOC$ Identificativo univoco della revisione 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. Valore relativo alla versione corrente del documento 34 assigningauthorityname 1..1 $AUTHORITY$ Nome descrittivo assegnato alla ASL/AO a cui l'oid della root fa riferimento 35 versionnumber 1..1 Valore intero usato per identificare le versioni successive del documento 36 value 1..1 INT Ad ogni successiva versione del documento, tale numero deve essere incrementato di una unità (partendo da 1) Tabella 3 Primo blocco dell'header: dati generici legati alla tipologia di documento e alla sua generazione pag. 22 di 101

23 È importante soffermarsi sull elemento code per fare alcune precisazioni. Infatti gli attributi dell elemento code possono essere valorizzati in modo diverso in base alla tipologia di documento da produrre. Elemento Code Attributi Code display Codice LOINC Descrizione UDY REPORT Possibili valori UDY REPORT DIAGNOIC IMAGING LABORATORY REPORT Tabella 4 Possibili valorizzazioni degli attributi dell'elemento ClinicalDocument/code Per quanto riguarda il Rapporto di Medicina di Laboratorio, se il documento contiene esami afferenti a più specialità assume valore del codice LOINC relativo al Laboratory Report, altrimenti, se contiene una sola specialità, assume uno dei valori dei codici LOINC riportati nelle Specialità di Laboratorio. Codice LOINC Descrizione BLOOD BANK UDIES CELL MARKER UDIES CHEMIRY UDIES COAGULATION UDIES THERAPEUTIC DRUG MONITORING UDIES FERTILITY UDIES HEMATOLOGY UDIES HLA UDIES MICROBIOLOGY UDIES SEROLOGY UDIES TOXICOLOGY UDIES URINALYSIS UDIES BLOOD GAS UDIES CELL COUNT + DIFFERENTIAL UDIES MICROBIAL SUSCEPTIBILITY UDIES MOLOECULAR PATHOLOGY UDIES LABORATORY UDIES CHEMIRY CHALLANGE UDIES CYTOLOGY UDIES Tabella 5 Specialità di Laboratorio Elementi speciali: translation e qualifier Per elementi di tipo CE (Coded With Equivalents, vedi APPENDICE A Data Type) è probabile che si abbia la necessità di utilizzare un sistema di codifica alternativo e/o specificarli con un livello di granularità superiore a quanto fornisce già il sistema di pag. 23 di 101

24 codifica utilizzato. È possibile soddisfare tali esigenze attraverso l uso degli elementi translation e qualifier. Translation è un elemento concepito per mappare il codice originale in un diverso schema di codifica: si assume che il nuovo codice schema di codifica sia un quasi-sinonimo del codice originale. Quindi quest elemento può essere utilizzato quando sono presenti ad esempio una codifica LOINC ed il suo relativo codice interno o locale. L elemento qualifier è utilizzato per specializzare il tipo di documento riferito in translation. Si suggerisce di utilizzare l elemento qualifier per aumentare la specificità della codifica dei documenti. Viene utilizzato per specializzare il tipo di documento specificato all interno degli esami ClinicalDocument/code e ClinicalDocument/code/translation. No Element Name # Tipo Valore attributo 37 code CE 38 translation 0..1 CD 39 code 0..1 CS $CODEGLCDA$ 40 codesystem 0..1 UID $CVCSGLCDA$ 41 codesystemname 0..1 $AUTHORITY$ 42 codesystemversion displayname 0..1 $CIDGLCDA$ Descrizione/commenti sull'elemento o attributo Sinonimo del codice precedente secondo un altro sistema di codifica 44 qualifier 0..1 CR Specifica il tipo di specialità 45 value 0..1 CD Contiene la codifica del documento specializzato 46 code 0..1 CS $CVCGLCDA$ 47 codesystem 0..1 UID $CVCSGLCDA$ 48 displayname 0..1 $CVDGLCDA$ Tabella 6 Elementi opzionali translation e qualifier che specificano l elemento code Sezioni dell Header: dati legati al soggetto della prestazione No Element Name # Tipo Valore attributo 49 recordtarget 1..1 SET<RecordTarget> 50 typecode 1..1 CS RCT 51 contextcontrolcode 1..1 CS OP 52 patientrole 1..1 PatientRole 53 classcode 1..1 CS PAT Descrizione/commenti sull'elemento o attributo Identifica una persona che riceve cure sanitarie da una struttura pag. 24 di 101

25 No Element Name # Tipo Valore attributo Descrizione/commenti sull'elemento o attributo 54 addr 0..* AD Indirizzo del paziente 55 use 1..1 SET<AD> HP o H o TMP Specifica il tipo di indirizzo; vedi Tabella 8 56 country city censustract 0..1 $ATORESIDENZA ISO3$ $COMUNE DIRESIDENZATEO$ $CODICEIAT COMUNEDIRESIDENZA$ Si usa un codice ISO (a due oppure tre lettere) per la nazione di residenza. Se country = ITA, city o censustrac devono essere valorizzati Descrizione testuale del comune Codice IAT del comune 59 useableperiod 0..* SXCM_TS Intervallo di validità delle informazioni nei campi riservati all indirizzo 60 telecom 0..* TEL Recapito telefonico, , fax, ecc. del paziente 61 use 1..1 SET<TEL> HP o WP o MC Specifica il tipo di indirizzo raggiungibile da un'apparecchiatura di telecomunicazione; vedi Tabella 8 62 value 1..1 URL 63 useableperiod 0..* SXCM_TS Intervallo di validità delle informazioni nei campi riservati all indirizzo telecom 64 id 1..3 SET<II> Vedi Tabella 9 65 root 1..1 UID 66 extension assigningauthorityname patient 1..1 Patient 69 classcode 1..1 CS PSN 70 determinercode 1..1 CS INANCE 71 nullflavor 0..1 Contiene i dati anagrafici del soggetto della prestazione Se il soggetto della prestazione non appartiene alla specie umana allora l'attributo nullflavor DEVE essere valorizzato con OTH, quindi gli altri elementi di patient non verranno valorizzati pag. 25 di 101

26 No Element Name # Tipo Valore attributo 72 name 1..1 SET<PN> 73 family 1..1 $COGNOME$ 74 given 1..1 $NOME$ 75 nullflavor administrativegendercode 1..1 CE 77 code 1..1 $CODESEX$ Descrizione/commenti sull'elemento o attributo Viene valorizzato con "MSK" nel caso di referti in cui sia prevista la possibilità di anonimato; allora gli elementi family e given NON DEVONO essere presenti 78 codesystem 1..1 UID OID fisso 79 codesystemname 1..1 HL7 AdministrativeGender Stringa fissa 80 codesystemversion Stringa fissa attualmente displayname 0..1 $DISPLAYSEX$ Come viene rappresentata la codifica del sesso del paziente 82 birthtime value 1..1 TS 84 maritalstatuscode 0..1 CE Vedi indicazioni HL7 85 religiousaffiliationcode 0..1 CE Vedi indicazioni HL7 86 racecode 0..1 CE Vedi indicazioni HL7 87 ethnicgroupcode 0..1 CE Vedi indicazioni HL7 88 guardian 0..* SET<Guardian> Nel caso di soggetto minore, può essere usato per definire colui che rappresenta il soggetto della prestazione (persona o organizzazione) 89 classcode 1..1 CS GUARD 90 id 0..* SET<II> 91 code 0..1 CE 92 addr 0..* SET<AD> 93 telecom 0..* SET<TEL> Person 94 guardianchoice 1..1 Organization 95 guardianperson 1..1 Person 96 classcode 1..1 CS PSN 97 determinercode 1..1 CS INANCE 98 name 0..* SET<PN> 99 family 1..1 $GUARDIANFAMILY$ 100 given 1..1 $GUARDIANGIVEN$ In alternativa al guardianorganization pag. 26 di 101

27 No Element Name # Tipo Valore attributo Descrizione/commenti sull'elemento o attributo 101 guardianorganization 1..1 Organization In alternativa al guardianperson 102 name 0..* $NOMERUTAFF$ Descrizione testuale della struttura 103 id 0..* Identifica la struttura 104 root 1..1 UID $ROOTRUTAFF$ 105 extension 1..1 $IDRUTAFF$ 106 assigningauthorityn ame 1..1 $AUTHRUTAFF$ 107 birthplace 0..1 Birthplace 108 classcode 1..1 CS BIRTHPL 109 nullflavor place 1..1 Place 111 nullflavor classcode 1..1 CS PLC 113 determinercode 1..1 CS INANCE 114 name 0..1 EN 115 addr 0..1 AD 116 use 1..1 SET<AD> Vedi Tabella isnotordered 0..1 BL 118 country city censustract providerorganization 0..1 Organization $ATONASCITA ISO3$ $COMUNE DINASCITATEO$ $CODICEIAT COMUNEDINASCITA$ 122 classcode 1..1 CS ORG 123 determinercode 1..1 CS INANCE 124 id 0..* SET<II> 125 root 1..1 UID $OID AZIENDA$ Si usa un codice ISO (a due oppure tre lettere) per la nazione di nascita. Se country = ITA, city o censustrac devono essere valorizzati Descrizione testuale del comune di nascita Codice IAT del comune di nascita Entità di livello superiore che fa giocare il ruolo di paziente alla persona, di conseguenza può contenere ad es. la struttura che ha erogato la prestazione, quella che ha registrato il paziente, l'asl, la regione.. pag. 27 di 101

28 No Element Name # Tipo Valore attributo 126 extension assigningauthorityname 1..1 $AUTHORITY$ 128 displayable 0..1 BL TRUE 129 nullflavor name 0..* SET<ON> 131 telecom 0..* SET<TEL> 132 addr 0..* SET<AD> 133 standardindustryclasscode 0..1 CE 134 asorganizationpartof 0..1 OrganizationPartOf 135 classcode 1..1 CS PART 136 id 0..* SET<II> 137 code 0..1 CE 138 statuscode 0..1 CS 139 effectivetime 0..1 IVL<TS> 140 wholeorganization 0..1 Organization Tabella 7 Secondo blocco dell Header: dati legati al soggetto della prestazione Descrizione/commenti sull'elemento o attributo Per la compilazione dell'attributo extension, vedi la Tabella 10 dell elemento providerorganization/ extention Gli elementi di tipo CS non permettono la definizione esplicita di codesystem, codesystemname displayname, codesystemversion, in qunato " " Nelle tabelle sotto vengono riportate le possibili valorizzazioni degli attributi use rispettivamente nel caso in cui si tratti dell elemento addr o telecom. ClinicalDocument/recordTarget/patientRole/addr@use HP Primary Home H Home TMP Temprary Address ClinicalDocument/recordTarget/patientRole/telecom@use HP Home Phone WP Worh Phone MC Mobile Cellular Tabella 8 Possibili valorizzazioni dell attributo use pag. 28 di 101

29 Diverse sono le casistiche possibili e le relative eccezioni per la caratterizzazione dell elemento ClinicalDocument/recordTarget/patientRole/id. Tali casistiche dipendono dalla tipologia di soggetto e possono essere sintetizzate nella tabella che segue. id root Variabile da sostituire 1 Soggetti Cittadini Italiani o Stranieri residenti (iscritti SSN) Codice fiscale (obbligatorio) Codice assegnato dall anagrafica Regionale [regione].4.1 $IDCF$ $REGCODE$ Attributi extention Valore [codice fiscale] [codice identificativo] assigningautority Name Ministero economia e finanza [nome regione] 1.3 Identificativo univoco del paziente nel Sistema Informativo Locale HIS [root dell'azienda Sanitaria] $IDHIS$ [identificativo univoco] $HISS$ 2 Soggetti Stranieri Temporaneamente Presenti (P) Identificativo regionale P Identificativo univoco del paziente nel Sistema Informativo Locale HIS [regione].4.1 [root dell'azienda Sanitaria] 3 Soggetti assicurati da istituzioni estere Numero della tessera TEAM (Tessera Europea di Assicurazione Malattia) Numero di identificazione personale TEAM Identificativo univoco del paziente nel Sistema Informativo Locale HIS [root dell'azienda Sanitaria] $IDP$ $IDHIS$ $CODICE TEAM$ $IDTEAM$ $IDHIS$ P +[codice identificativo P] [identificativo univoco] [stato estero]. [numero seriale] [stato estero]. [numero identificativo personale] [identificativo univoco] [nome_regione/ ULSS] $HISS$ [istituzione estera] es. SSN-MIN SALUTE [istituzione estera] es. SSN-MIN SALUTE $HISS$ Tabella 9 Possibili valorizzazioni degli attributi dell'elemento ClinicalDocument/ recordtarget/ patientrole/ id Il D.lgs. n.196/03 Codice in materia di protezione dei dati personali basa la materia della riservatezza e della sicurezza nel trattamento dei dati sul principio di pag. 29 di 101

30 necessità di detto trattamento, sancito dal suo art. 3:" I sistemi informativi e i programmi informatici sono configurati riducendo al minimo l'utilizzazione di dati personali e di dati identificativi, in modo da escluderne il trattamento quando le finalità perseguite nei singoli casi possono essere realizzate mediante, rispettivamente, dati anonimi od opportune modalità che permettano di identificare l'interessato solo in caso di necessità". Il medesimo decreto definisce quindi all'art.4, co. 1, lett. n) il dato anonimo come quello "che in origine, o a seguito di trattamento, non può essere associato ad un interessato identificato o identificabile". Continuando con il principio di necessità del trattamento, il Codice all'art.22, co. 3 asserisce che " I soggetti pubblici possono trattare solo i dati sensibili e giudiziari indispensabili per svolgere attività istituzionali che non possono essere adempiute, caso per caso, mediante il trattamento di dati anonimi o di dati personali di natura diversa". Onde ottemperare questi fondamentali dettami normativi, e qualora venga richiesta l'anonimizzazione del dato, gli elementi anagrafici name e birthplace, vanno riportati sprovvisti di valori, ma devono ambedue essere decorati con l attributo nullfavour= MSK per permettere la comprensione al document consumer. NB: nessun ulteriore utilizzo/valore dell attributo nullflavor è ammesso. Per caratterizzare in modo completo l ente che ha erogato la prestazione all origine del CDA, ClinicalDocument/recordTarget/patientRole/providerOrganization/Id, è possibile utilizzare lo schema che segue. In ogni caso gli attributi root ed assigningauthorityname saranno caratterizzati in accordo con la tipologia di Id scelta caso per caso. 1 id AREA-DOMINIO 2 id dell'azienda 3 id PRESIDIO 4 id REPARTO Variabile da sostituire $AREA-DOMINIO$ $AZIENDA$ $PRESIDIO$ Extension Valore Identificativo univoco del dipartimento o raggruppamento a cui appartiene Identificativo univoco dell'azienda Sanitaria Identificativo univoco del presidio all'interno dell'azienda Identificativo univoco del reparto $REPARTO$ all'interno dell'azienda Tabella 10 Possibili valorizzazioni dell'attributo extension dell elemento ClinicalDocument/ recordtarget/ patient Role/ providerorganization/ Id pag. 30 di 101

31 Sezioni dell Header: dati legati al custode del documento Per identificare l organizzazione a cui è lasciata la custodia del documento originale, solitamente la struttura di cui fa parte colui che ha creato il documento, viene utilizzato l elemento custodian di cui vengono riportati gli elementi caratteristici nella tabella sotto. No Element Name # Tipo Valore attributo 141 custodian 1..1 Custodian 142 typecode 1..1 CS C Descrizione/commenti sull'elemento o attributo Identifica l'organizzazione incaricata della custodia del documento originale 143 assignedcustodian 1..1 AssignedCustodian Ruolo del custode 144 classcode 1..1 CS ASSIGNED 145 representedcustodianorganizati on 1..1 CustodianOrganization 146 classcode 1..1 CS ORG 147 determinercode 1..1 CS INANCE 148 id 1..* SET<II> 149 root 1..1 UID [OID dominio di identificazione delle organizzazioni] 150 extension 1..1 $IDCUODIAN$ 151 assigningauthorityname 0..1 $AUTHORITY$ 152 name 0..1 ON $NAMECUODIAN ORGANIZATION$ 153 telecom 0..1 TEL 154 addr 0..1 AD Tabella 11 Terzo blocco dell Header: dati legati al custode del documento Entità che svolge il ruolo di custode Riporta l'identificativo della struttura che ha la responsabilità della conservazione del documento Identificativo del dominio di identificazione delle organizzazioni Identificativo dell'organizzazione (ULSS, Regione) da parte del dominio di identificazione definito nell'attributo root Relativamente alle strutture che ricadono sotto la competenza della ULSS/AO, si prevede che un identificativo univoco, se non già esistente, sia assegnato da parte di queste. pag. 31 di 101

32 Sezioni dell Header: dati legati all autore ed autenticatore del documento No Element Name # Tipo Valore attributo 155 author 1..* SET<Author> 156 typecode 1..1 CS AUT 157 functioncode 0..1 CE 158 contextcontrolcode 1..1 CS OP 159 time 1..1 TS 160 value assignedauthor 1..1 AssignedAuthor 162 nullflavor 0..1 [YYYYmmgghhmmss + -ZZzz] 163 classcode 1..1 CS ASSIGNED 164 id 1..2 SET<II> 165 root 1..1 UID extension 1..1 $CODFISCAUT$ 167 displayable 0..1 BL 168 assigningauthorityname Code 0..1 CE 170 addr 0..* SET<AD> 171 telecom 0..* SET<TEL> 172 assignedauthorchoice 0..1 Person AuthoringDevice 173 assignedperson 0..1 Person 174 name 0..2 Ministero Economia e Finanze 175 prefix 0..1 $PREFASAUT$ 176 family 1..1 $COGNASAUT$ 177 given 1..1 $NOMEASAUT$ 178 assignedauthoringdevice 1..1 AuthoringDevice 179 classcode 1..1 CS DEV 180 determinercode 1..1 CS INANCE 181 code 0..1 CE 182 manufacturermodelname 0..1 SC 183 softwarename 0..1 SC Descrizione/commenti sull'elemento o attributo Identifica il soggetto che ha creato il documento: può essere una persona o una macchina Data e ora di produzione del documento: il formato può essere scelto con la precisione voluta Root del ministero dell economia e finanza Codice fiscale (obbligatorio) del medico autore del documento CDA Dispositivo e/o applicazione software che ha generato il documento pag. 32 di 101

33 No Element Name # Tipo Valore attributo 184 asmaintainedentity 0..* SET<MaintainedEntity> 185 classcode 1..1 CS MNT 186 effectivetime 0..1 IVL<TS> 187 maintainingperson 1..1 Person 188 representedorganization 0..1 Organization Tabella 12 Quarto blocco dell Header: dati legati all autore del documento Descrizione/commenti sull'elemento o attributo L attore che ha legalmente autenticato e quindi firmato digitalmente il documento prodotto in locale è rappresentato dall elemento ClinicalDocument/legalAuthenticator. Nella tabella che segue sono riportati i valori necessari alla valorizzazione del legalauthenticator. No Element Name # Tipo Valore attributo 189 legalauthenticator 1..1 LegalAuthenticator 190 typecode 1..1 CS LA 191 contextcontrolcode 1..1 CS OP 192 time 1..1 TS [YYYYmmgghhmmss+ -ZZzz] 193 signaturecode 1..1 " " 194 code 1..1 S 195 assignedentity 1..1 AssignedEntity 196 Id 1..1 SET<II> 197 root 1..1 UID extension 1..1 $CODFISCLEGAUTH$ 199 displayable 0..1 BL Descrizione/commen sull'elemento o attributo Riporta il firmatario del documento Data e ora in cui è stata apposta la firma Indica se il documento è firmato elettronicamente o manualmente Codice che identifica che il documento è firmato digitalmente Root del ministero dell economia e finanza Codice fiscale del medico che firma 200 assigningauthorityname 0..1 Ministero Economia e Finanze 201 addr 0..1 AD 202 telecom 0..1 TEL 201 assignedperson name prefix 0..1 $PREFLEGAUTH$ 204 family 1..1 $COGNLEGAUTH$ 205 given 1..1 $NOMELEGAUTH$ pag. 33 di 101

34 No Element Name # Tipo Valore attributo 206 representedorganization 0..1 organization 207 id 0..1 SET<II> 208 root 1..1 UID Descrizione/commen sull'elemento o attributo Root dell Azienda Sanitaria 209 extension 1..1 Codice unità operativa 210 displayable 0..1 BL 211 assigningauthorityname name asorganizationpartof 0..1 organizationpartof code 0..1 CE 214 code codesystem 1..1 UID 216 codesystemname 0..1 Nome dell unità operativa e del primario associato Codice aziendale definito per il dipartimento Root dell Azienda Sanitaria 217 displayname 0..1 Nome del Dipartiment 218 wholeorganization 0..1 organization id root 1..1 UID extension displayable 0..1 BL 222 assigningauthorityname 0..1 Ministero della Salute 223 name 0..1 Root del ministero della salute Codice della ulss definito dal ministero della salute Nome dell Azienda Sanitaria Regione Veneto Tabella 13 Quinto blocco dell Header: dati legati all autenticatore del documento Per la valorizzazione degli attributi dell elemento assignedentity/id, il Tavolo permanente di Sanità Elettronica da l'indicazione di utilizzare il codice fiscale del firmatario e quindi l OID del Ministero dell Economia e delle Finanze. Attenzione! Si nota come gli elementi dalla riga 206 alla riga 223 debbano essere, per il progetto Veneto ESCAPE, obbligatoriamente inseriti e valorizzati come definito per permettere la corretta renderizzazione attraverso stylesheet delle informazioni necessarie alla valorizzazione del contenuto proprio dell intestazione del referto di Medicina di Laboratorio. pag. 34 di 101

35 Sezioni dell Header: dati legati al validatore del documento L elemento ClinicalDocument/authenticator è un elemento opzionale che identifica la persona che garantisce la correttezza delle informazioni riportate nel documento. Questa sezione però deve essere riportata in tutti i casi NON si abbia la coincidenza tra il garante ed il firmatario del documento. No Element Name # Tipo Valore attributo 208 authenticator 0..* SET<Authenticator> 209 typecode 1..1 CS AUTHEN 210 time 1..1 TS 211 signaturecode 1..1 CS [YYYYmmgghhmmss+ - " " 212 code 1..1 S 213 assignedentity 1..1 AssignedEntity 214 id 1..1 SET<II> 215 root 1..1 UID 216 extension 1..1 $CODREGLEGAUTH$ 217 displayable 0..1 BL Descrizione/commenti sull'elemento o attributo Data e ora di apposizione della firma Codice che identifica che il documento è firmato digitalmente Vedi indicazioni date per il legalauthenticator 218 assigningauthorityname 0..1 $AUTHORITY$ 219 assignedperson 0..1 Vedi indicazioni date per il legalauthenticator Tabella 14 Sesto blocco dell Header: dati legati al validatore del documento Secondo quanto stabilito nell incontro del 7 settembre 2011 tenutosi in Regione Veneto tra i fornitori dei sistemi informativi di laboratorio, il rappresentante per la Regione Ing. Gubian ed i referenti di, è consigliato l utilizzo dell elemento authenticator nel caso in cui il validatore sia unico per tutti gli esami descritti nel documento. Nel caso in cui invece i validatori siano più di uno, si consiglia di non utilizzare l elemento authenticator e di riportare i riferimenti di chi ha validato lo specifico esame all interno della sezione di riferimento nel body dedicata allo specifico esame utilizzando l apposito elemento participant. pag. 35 di 101

36 Sezioni dell Header: dati legati al soggetto che trasforma il testo dettato nel documento CDA No Element Name # Tipo Valore attributo 220 dataenterer 0..1 DataEnterer 221 typecode 1..1 CS ENT 222 contextcontrolcode 1..1 CS OP 223 time 0..1 TS 224 assignedentity 1..1 AssignedEntity 225 classcode 1..1 CS ASSIGNED 226 id 1..* SET<II> 227 root 1..1 UID 228 extension displayable 0..1 BL 230 assigningauthorityname code 0..1 CE 232 addr 0..* SET<AD> 233 telecom 0..* SET<TEL> 234 assignedperson 0..1 Person 235 name 0..1 $CODFISCDENT$ e/o $CODREGDENT$ Ministero Economia e Finanze e/o $AUTHORITY$ 236 prefix 0..1 $PREFDENT$ 237 family 1..1 $COGNDENT$ 238 given 1..1 $NOMEDENT$ 239 representedorganization 0..1 Organization Tabella 15 Settimo blocco dell Header: dati legati al trascrittore del documento Descrizione/commenti sull'elemento o attributo Soggetto che trasforma un testo dettato nel documento CDA. Data e ora in cui è stato trascritto il documento. Il formato può essere scelto con la precisione voluta Descrive in forma leggibile il nome della persona che ha trascritto il documento Sezioni dell Header: dati legati ai soggetti partecipanti alla realizzazione del documento No Element Name # Tipo Valore attributo 240 participant 0..* SET<Participant1> Descrizione/commenti sull'elemento o attributo Rappresenta tutti coloro che sono in qualche modo coinvolti nell'atto descritto, ma non esplicitamente referenziate in altri elementi pag. 36 di 101

37 No Element Name # Tipo Valore attributo 241 typecode 1..1 CS $PART_TYPE$ 242 functioncode 0..1 CE 243 contextcontrolcode 1..1 CS OP 244 time 0..1 IVL<TS> 245 associatedentity 1..1 AssociatedEntity 246 classcode 1..1 CS 247 id 0..* SET<II> 248 root 1..1 UID 249 extension 1..1 $CODREGPART$ 250 displayable 0..1 BL 251 assigningauthorityname 0..1 $AUTHORITY$ 252 code 0..1 CE 253 addr 0..* SET<AD> 254 telecom 0..* SET<TEL> 255 associatedperson 0..1 Person 256 name prefix 0..1 $PREFPART$ 258 family 1..1 $COGNPART$ 259 given 1..1 $NOMEPART$ Descrizione/commenti sull'elemento o attributo Attributo con valore da ricercarsi nel ruolo svolto dal soggetto che si intende descrivere: Nel caso di validatore del rapporto o degli esami, l attributo DEVE assumere il valore AUTHEN Nel caso di specifico macchinario che effettua gli esami di laboratorio (ad esempio un analizzatore), l attributo DEVE assumere il valore DEV Nel caso di soggetto che trascrive gli esami, l attributo DEVE assumere il valore ENT Nel caso di soggetto responsabile della fornitura dei risultati, l attributo DEVE assumere il valore RESP. OID della struttura che contiene le anagrafiche del personale Codice personale interno al dominio Se omesso è implicitamente a FALSE Per descrivere in forma leggibile il nome del soggetto che ha partecipato alla stesura del documento 260 scopingorganization 0..1 Organization Tabella 16 Ottavo blocco dell Header: dati legati ai soggetti partecipanti alla realizzazione del documento pag. 37 di 101

38 L elemento opzionale participant è usato per rappresentare tutti coloro, persone od organizzazioni, che sono in vario modo coinvolti nell atto descritto, ma non esplicitamente referenziate in altri elementi (es. autore, custode, validatore, firmatario..). Non devono essere necessariamente entità coinvolte direttamente nell atto documentato. Inoltre è consigliabile utilizzare questo elemento nel body, come stabilito nell incontro del 7 ottobre 2011 in Regione Veneto, in particolare qualora gli attori referenziati siano coinvolti in uno o più particolari esami documentati in particolari sottosezioni del body Sezioni dell Header: dati legati ai soggetti destinatari di una copia del documento L elemento informationrecipient è opzionale e riporta l identificativo dei destinatari che dovrebbero ricevere una copia del documento (persone, es. medico di base, od organizzazione). Secondo quanto stabilito nell incontro del 7 settembre 2011 tenutosi in Regione Veneto, questo elemento anche se opzionale è da considerarsi importante per l implementazione del CDA del referto di laboratorio. No Element Name # Tipo Valore attributo 261 informationrecipient 0..* SET<InformationRecipient> 262 typecode 1..1 CS PRCP 263 intendedrecipient 1..1 IntendedRecipient 264 classcode 1..1 CS ASSIGNED 265 id 0..* SET<II> 266 root 1..1 UID 267 extension 1..1 $CODMED CONSULTARGET$ 268 assigningauthoritynam e 0..1 $AUTHORITY$ 269 addr 0..* SET<AD> 270 telecom 0..* SET<TEL> 271 informationrecipient 0..1 Person 272 name 0..1 Descrizione/commenti sull'elemento o attributo Persone od organizzazione a cui è destinato il documento. Se è valorizzato è obbligatorio valorizzare almeno uno dei due informationrecipient o receivedorganization Medico destinatario del documento pag. 38 di 101