Template  Referto di Medicina di Laboratorio (LAB)

Elemento root per la struttura XML che rappresenta il documento CDA. Ogni documento CDA iniziare con l'elemento ClinicalDocument , che comprende gli attributi speciali xsi:schemaLocation, xmlns e xmlsn:xsi, i quali specificano il riferimento ad un namespace esterno, come esemplificato nel codice XML seguente:

Questo elemento segnala l’attuazione di vincoli specifici del dominio di autenticazione. Il valore del suo attributo @code identifica il dominio di identificazione in questione.

Questo elemento non dovrebbe essere utilizzato per identificare il paese di origine.

Elemento che indica che il documento è strutturato secondo le specifiche HL7-CDA . L'elemento rappresenta un identificatore univoco (di tipo HL7 Instance Identifier) ed è composto dagli attributi seguenti.

Versione del Template.

Elemento che identifica univocamente l'istanza di ogni documento CDA. L'elemento <id> è un valore del tipo HL7 "Instance Identifier" ed è composto in generale da un attributo @root che riporta un codice OID, un attributo @extension che riporta un codice specifico ed un attributo @assigningAuthorityName con il nome dell'organizzazione che è responsabile della identificazione posta nell’attributo @extension. Ogni singola istanza di documento CDA (Referto Laboratorio Analisi) deve essere dotata di un identificativo universalmente univoco, che andrà specificato nell'elemento <id> del documento. L’assegnazione ad ogni entità generatrice di documenti di un nodo OID, a cui riferirsi per generare sequenze univoche di identificatori, garantisce l’unicità dei documenti.

Elemento che indica la tipologia di documento.

L'elemento <code> riporta un codice che identifica la tipologia di documento a cui il CDA si riferisce. Il valore deve fare riferimento al sistema di codifica LOINC.

In particolare, si dovrà utilizzare il codice LOINC “1502-2” - Referto di Laboratorio Analisi - per identificare il documento clinico strutturato deò Laboratorio Analisi (LIS).

Per indirizzare le problematiche di mapping della codifica LOINC di <ClinicalDocument>/<code> in un altro sistema di codifica, ad esempio un sistema di codifica locale, si rimanda all’uso di <code>/<translation>.

L'elemento rappresenta il titolo del documento CDA

Estensione che indica lo stato del documento.

L’attributo @code di tale elemento può essere valorizzato con “active” nel caso in cui il referto non è ancora finalizzato, o con “completed” se il documento è nel suo stato finale.

Si raccomanda di usare questa estensione solo nel caso del referto non ancora finalizzato ("active").

Elemento che indica la data di creazione del documento CDA. L'elemento <effectiveTime> rappresenta un codice temporale, che sarà essere valorizzato attraverso un tipo Time Stamp (TS), come presentato di seguito. Tale valore deve essere quello del client utilizzato dal document source, opportunamente certificato.

Elemento che indica la lingua in cui è redatto il documento. L'elemento rappresenta un codice conforme alle specifiche dell'IETF (Internet Engineering Task Force) RFC 3066 (OID:2.16.840.1.113883.6.121).

Elemento che consente di gestire le revisioni del documento, o eventuali addendum integrativi.

<setId> e <versionNumber> sono, secondo lo standard CDA, elementi opzionali, o meglio, condizionalmente obbligatori.

Nel caso di sostituzione del documento, l'elemento <setId> ha un valore costante tra le diverse versioni del medesimo documento, mentre l'elemento <versionNumber> cambia al variare della revisione.

Tutte le nuove versioni del documento devono avere un <id> univoco e diverso da quello delle versioni precedenti ed un <setId> uguale a quello definito nel primo documento pubblicato.

Il nuovo documento creato tramite il replace deve comprendere un elemento <relatedDocument> che punta al documento sostituito.

Anche l'elemento <setId>, come l'elemento <id>, deve essere globalmente unico. È consigliato, pertanto, valorizzare, alla prima creazione del documento, i campi <setId> e <id> allo stesso modo, modificando successivamente nelle diverse revisioni solo l'elemento <id> con un nuovo IUD e lasciando costante il valore dell'elemento <setId>.

Nel caso di addendum integrativo al documento, questo deve avere un <id> univoco e diverso da quello dei documenti precedenti associati, l’elemento <setId> assume un nuovo valore rispetto al documento iniziale, mentre l'elemento <versionNumber> riparte per ciascun addendum.

Il nuovo documento addendum deve comprendere un elemento <relatedDocument> che punta al documento iniziale.

Identificativo dell’insieme di istanze che definiscono le diverse versioni di questo documento. Tale identificativo è unico all’interno del dominio di identificazione. È tipicamente originato dal sistema che genera il documento, secondo regole condivise all’interno dello spazio di identificazione, in maniera tale da assicurare l'univocità di tale attributo all'interno del medesimo dominio.

Nome dell’organizzazione responsabile per il dominio di identificazione dei documenti.

Il soggetto della prestazione può essere di tre tipologie:

• Soggetto Umano (Human Patient)

• Soggetto non appartenente alla specie umana (Non-Human Subject), ad esempio un animale

• Soggetto appartenente alla specie umana (soggetto) associato con soggetto non appartenente alla specie umana (Human Patient with Non-Human Subject), ad esempio un alimento che è stato ingerito da un soggetto. Questa tipologia di soggetto della prestazione potrà essere utilizzata quando il Referto di Medicina di Laboratorio contiene osservazioni relative ad un soggetto ed osservazioni effettuate su di un campione non appartenente alla specie umana in relazione con il soggetto

Nel caso di Paziente (Human Patient)

L'elemento patientRole deve prevedere al suo interno almeno un elemento di tipo id, destinato ad accogliere la chiave identificativa del paziente, secondo gli schemi assegnati da ogni singola organizzazione, ed eventualmente ulteriori elementi di tipo id, destinati ad accogliere le informazioni relative ad altri identificativi (regionali, nazionali, europei, termporanei, ecc).

L' elemento id può essere valorizzato con le seguenti informazioni:

• Cittadino italiano o straniero residente, iscritto SSN (Codice Fiscale)

• Soggetti assicurati da istituzioni estere (TEAM);

• Europei non iscritti al SSN (ENI);

• Stranieri Temporaneamente Presenti (STP);

• Codice ANA;

Nel caso del Soggetto non appartenente alla specie umana (Non-Human Subject)

L’id rappresenta l’identificativo del soggetto non appartenente alla specie umana

Nel caso di Paziente (Human Patient with Non-Human Subject)

Il recordTarget identifica il soggetto paziente. Si osserva che a livello di Header CDA non sono gestiti l’identificativo ed i dettagli del soggetto non appartenente alla specie umana associato con il soggetto.

Nel caso di Paziente (Human Patient) l'elemento patient è obbligatorio.

Se il soggetto della prestazione non appartiene alla specie umana (Non-Human Subject) allora recordTarget/patientRole/patient/@nullflavor DEVE essere valorizzato con OTH.

Per i soggetti umani deve essere presente un elemento <name>. Può essere valorizzato con nullFlavor per indicare l'indisponibilità del dato

L'attributo @value deve essere valorizzato con il seguente formato YYYYMMddhhmmss

Il tag è <assignedAuthor> e può contenere al suo interno:

• un tag <id> che identifica univocamente il medico autore del documento tramite il suo codice fiscale;

• un tag <assignedPerson> che definisce il nome e cognome dell’autore del documento;

• un tag <representedOrganization> che prevede al suo interno un tag che identifica univocamente la struttura/organizzazione di appartenenza dell’autore

L'elemento telecom dettaglia i recapiti di contatto dell'autore.

L'elemento assignedAuthoringDevice indica il dispositivo e/o l’applicazione software che ha generato il documento.

L'elemento identifica la data e ora in cui è stata trascritto il documento. è possibile usare nullFlavor in caso di assenza del dato.

Il custodian è l’organizzazione responsabile della conservazione dell’originale del documento, al momento della generazione.

L'elemento intendedRecipient indica la persona (e.g medico di base) od organizzazione a cui è destinato il documento.

L'elemento deve contenere al suo interno almeno uno tra i seguenti elementi:

• <informationRecipient>

• <receivedOrganization>

La data e orario deveessere riportata nell’elemento authenticator/time valorizzato secondo il seguente formato YYYYMMddhhmmss.

Il tag participant è un elemento opzionale ed è usato per rappresentare tutti coloro (persone od organizzazioni) che sono in qualche forma coinvolti nell’atto descritto, ma non esplicitamente referenziate in altri elementi (author, informant, authenticator, etc.).

Per rappresentare la data e orario d’inoltro della richiesta al laboratorio, l’elemento participant deve avere i seguenti attributi così valorizzati:

• participant/@typeCode : REF

• participant/@contextControlCode: OP

• participant/functionCode/@code : RIC

Per rappresentare la data e orario di prenotazione (es. CUP), l’elemento participant deve avere i seguenti attributi così valorizzati:

• participant/@typeCode : REF

• participant/@contextControlCode: OP

• participant/functionCode/@code : PRE

Nel caso in cui nel Referto di Medicina di Laboratorio si voglia mappare il medico di base richiedente l’analisi di laboratorio, si utilizza l’elemento participant che DEVE avere i seguenti attributi così valorizzati:

• participant/@typeCode : REF

• participant/functionCode/@code : PCP

• participant/associatedEntity/@classCode PROV

Nel caso in cui nel Referto di Medicina di Laboratorio si voglia mappare il medico ospedaliero richiedente l’analisi di laboratorio, si utilizza l’elemento participant che deve avere i seguenti attributi così valorizzati:

• participant/@typeCode REF

• participant/functionCode/@code : ATTPHYS

• participant/associatedEntity/@classCode PROV

Nel caso in cui nel Referto di Medicina di Laboratorio si voglia mappare il responsabile della struttura che eroga il servizio relativo al Referto di Medicina di Laboratorio (ad esempio il primario del laboratorio prime contractor), si utilizza l'elemento participant che deve avere i seguenti attributi così valorizzati:

• participant/@typeCode RESP

• participant/associatedEntity/@classCode : EMP

Si osserva che per quanto riguarda la valorizzazione dell’attributo participant/functionCode/@code nel caso della data e orario richiesta e nel caso della data e orario prenotazione, non essendo disponibili nel vocabolario ParticipationFunction di HL7 org i valori appropriati, il vocabolario in questione è stato esteso ossia:

• OID vocabolario esteso: 2.16.840.1.113883.2.9.5.1.88;

• Descrizione vocabolario esteso: Estensione Vocabolario ParticipationFunction;

• Valori aggiunti al vocabolario: RIC (richiedente) e PRE (prenotatore)

Nel caso del Referto di Medicina di laboratorio il tag time, presente nel participant, può essere utilizzato per veicolare l’informazione relativa alla data e orario d’inoltro della richiesta al laboratorio di analisi da parte, per esempio, del punto prelievo, del reparto ospedaliero o di altra struttura.

Con l'elemento scopingOrganization si indica la struttura coinvolta in qualche modo nella realizzazione del documento.

Nell’elemento participant/associatedEntity/scopingOrganization si può inoltre indicare la struttura che ha effettuato la prenotazione. In questo caso l’attributo @classCode di participant/associatedEntity che indica il ruolo giocato dall’organizzazione in questa partecipazione può essere valorizzato con QUAL (Qualified Entity).

In inFulfillmentOf/order possono essere mappati gli identificativi delle seguenti tipologie di richieste:

• la/le richieste gestita/e dal punto prelievi verso il laboratorio di analisi;

• la/le richieste pervenuta/e da un determinato reparto all’interno di una struttura ospedaliera verso il laboratorio di analisi;

1. richiesta interna ad un ricovero

2. richiesta interna al PS

• la/le prescrizione/i cartacea/e

• la/le prescrizione/i dematerializzata/e

• Se è una Prescrizione, l’attributo @root di un elemento in fulfillmentOf/order/id/ deve essere valorizzato con l’OID che identifica le prescrizioni.

• Se la prescrizione è dematerializzata l’attributo @root dell’elemento inFulfillmentOf/order/id/ deve essere valorizzato con l’OID 2.16.840.1.113883.2.9.4.3.9

• Se la ricetta è cartacea (RUR) l’attributo @root dell’elemento inFulfillmentOf/order/id DEVE essere valorizzato con l’OID 2.16.840.1.113883.2.9.4.3.4

• Se la/le richieste pervenuta/e da un determinato reparto all’interno di una struttura ospedaliera verso il laboratorio di analisi, l’attributo @root dell’elemento inFulfillmentOf/order/id dovrebbe essere valorizzato con l’OID che identifica gli ordini interni.

L’attributo @extension dell’elemento inFulfillmentOf/order/id deve essere valorizzato con l’identificativo della Prescrizione o richiesta.

Possibili valori estratti dal Vocabolario HL7 Priority Code:

• R: Routine

• P: preop

• UR: urgent

• EM: Emergency

L'attributo riporta la versione del vocabolario

L'attributo valorizza con la descrizione del codice nel vocabolario HL7 ActPriority

L'attributo @code deve asuemere uno dei seguenti valori:

• active, nel caso in cui lo stato di produzione dei risultati sia parziale ma potrebbe essere completato in futuro;

• completed, nel caso in cui lo stato di produzione dei risultati sia completo;

Se serviceEvent/statusCode non è presente nel documento CDA, allora si assume che l’atto documentato sia in stato "completed" ed il referto di laboratorio si assume completo.

Se gli esami del Referto di Medicina di Laboratorio sono stati eseguiti da un unico laboratorio, l'elemento serviceEvent/performer è un elemento obbligatorio.

L’attributo relatedDocument/@typeCode può essere valorizzato come segue:

• APND (append): può essere usato in caso di documenti CDA ottenuti aggiungendo al documento “sorgente”;

• RPLC (replace): può essere usato in caso di documenti CDA ottenuti sostituendo il documento “sorgente”;

• XFRM (Transform): deve essere usato in caso di documenti CDA ottenuti come trasformazione di altri documenti “sorgente” (e.g. DICOM SR).

Un documento CDA conforme può avere un singolo RelatedDocument con typeCode "APND"; un singolo RelatedDocument con typeCode "RPLC"; un singolo RelatedDocument con typeCode "XFRM"; una combinazione di due RelatedDocuments con typeCodes "XFRM" e "RPLC"; o una combinazione di due documenti correlati con typeCodes "XFRM" e "APND". Non sono ammesse altre combinazioni

• In caso di integrativo o sostitutivo, l'elemento <parentDocument>. deve contenere un elemento <id> con valore degli attributi @root e @extension pari ai codici del documento di cui si fa il replace o l’append

• Nel caso di utilizzo dell’attributo XFRM per esplicitare la corrispondenza con il documento all’interno del sistema RIS, l'elemento <parentDocument> deve contenere un elemento <id> con valore degli attributi @root e @extension contenenti i riferimenti del documento nel sistema RIS.

L’elemento <componentOf> è opzionale, ma diventa obbligatorio nel caso in cui l’incontro tra paziente e struttura avviene nell’ambito del ricovero

L’elemento descrive l’incontro tra soggetto e la struttura sanitaria durante il quale è stato richiesto il servizio che ha fornito come risultato la generazione del Referto di Medicina di Laboratorio. L’incontro tra soggetto e la struttura può avvenire per esempio nell’ambito di un ricovero, nell’ambito di un’accettazione di un punto prelievi/ambulatorio, etc

Il tag <encompassingEncounter>/<id> è un elemento opzionale, ma diventa obbligatorio nel caso di ricovero. In tal caso viene usato per veicolare il numero nosologico.

Il tag <code> può essere utilizzato per indicare il tipo di identificativo gestito nell’ambito del Referto di Medicina di Laboratorio.

Il tag, <encompassingEncounter>/<code>, può assumere per esempio i seguenti valori:

• IMP (inpatient encounter),in casi di ricovero e introduce il numero nosologico;

• AMB (ambulatory) per rappresentare l’identificativo di un incontro avvenuto in una struttura ambulatoriale;

Nel caso in cui, nel Referto di Medicina di Laboratorio, in encompassingEncounter/id venga gestito solo il numero nosologico, non è necessario l’utilizzo dell’encompassingEncounter/code.

Il tag effectiveTime rappresenta la data/ora in cui è avvenuto l'encounter. Si osserva che il tag effectiveTime può anche non essere valorizzato, in questo caso deve essere inserito un NullFlavor,

L'elemento responsibleParty indica la persona responsabile della struttura dove avviene l'incontro con il soggetto che effettua la prestazione.

L’elemento <encompassingEncounter>/<responsibleParty>/<responsibleParty>/<assignedEntity>/<code> può essere valorizzato con RESPRSN (responsible party). Se l’elemento è presente, l’indirizzo e i recapiti telefonici possono essere riportati nell’elemento <assignedEntity>.

L’elemento <location>è opzionale e rappresenta il luogo in cui si è svolto l'incontro tra il soggetto e la struttura sanitaria; ad esempio, nel caso in cui l'incontro sia un ricovero ospedaliero, il tag <location>/<healthCareFacility> può rappresentare il reparto

L'elemento può rappresentare il reparto e il suo identificativo.

L’identificativo del reparto può essere riportato in <location>/<healthCareFacility>/<id>.

Elenco dei Reparti (Struttura ospedaliera) cui l’unità operativa nella quale viene eseguita la prestazione fa capo

Codice Struttura + Sub Codice Struttura Interna + Codice Disciplina che rappresenta l’unità operativa interna a quel particolare dominio + opzionalmente il Codice

• Il Nome del presidio può essere riportato nell’elemento: <healthCareFacility>/<serviceProviderOrganization>/<name>.

• L’identificativo del presidio deve essere riportato <healthCareFacility>/<serviceProviderOrganization>/<id>.

• I recapiti telefonico ed e-mail della segreteria del presidio possono essere riportati nell’elemento: <healthCareFacility>/<serviceProviderOrganization>/<telecom>.

• L’identificativo dell’Azienda Sanitaria di cui il presidio fa parte deve essere riportato in: <healthCareFacility>/<serviceProviderOrganization>/<asOrganizationPartOf>/<id>.

L'attributo può identificare il nome del presidio.

L'attributo identifica i recapiti telefonici ed email della segreteria del presidio.

L'attributo identifica l'Azienda Sanitaria di cui il presidio fa parte

CDA BODY

Livello 2: human-readable body

Un Referto di Medicina di Laboratorio deve avere un body di tipo structuredBody. Il body è organizzato secondo una gerarchia di section in cui è presente il contenuto human-readable del documento. La gerarchia di section può al più essere organizzata su due livelli:

• section di specialità (ad esempio Hematology studies), rappresenta il livello più “alto” di section;

• section foglia, rappresenta il livello “inferiore” di section.

Il CDA del Referto di Medicina di Laboratorio deve contenere l’elemento structuredBody

Il Referto di Medicina di Laboratorio deve contenere almeno una structuredBody/component/section di specialità. La section di specialità può essere instanziata più volte quando ad esempio nel referto sono presenti esami afferenti a diverse specialità, in questo caso si potranno trovare diverse section di specialità, una per ciascuna specialità gestita nel referto del laboratorio.

La structuredBody/component/section di specialità può contenere una o più section foglie innestate, che possono rappresentare una sottosezione del Referto di Medicina di Laboratorio ad esempio una batteria di esami (vedi EMOCROMO), un singolo esame o lo studio completo di un campione (vedi la Microbiologia). Se la section di specialità non contiene section foglie innestate allora è di per sè una section foglia.