FSE

FSE

Componente Locale

Specifica dei Requisiti del protocollo di interoperabilità fra la Componente Locale e i dipartimentali

(modalità HL7 con e senza invio dei documenti clinici)

STATO DELLE VARIAZIONI

VERSIONE	DATA EMISSIONE	PARAGRAFO O PAGINA	DESCRIZIONE DELLA VARIAZIONE
V10	n.d.	Tutto il documento	Revisione dell’intero documento
V11	n.d.	4.8.4 e 4.9	4.8.4 Inserito il parametro privacyDocumentoFse nel segmento PV1.22; 4.8.4.1 Precisazione su alcuni campi del segmento PV1.22 (nuovo paragrafo) 4.9 Aggiunti codici e descrizioni di errore e warning restituiti dalla RegistraEpisodi legati a scarico referto
V12	n.d.	4.8.4	4.8.4 Aggiunta precisazione su invio dati del pagamento ticket, successivamente all’invio del referto
V13	n.d.	Tutto il documento	Revisione dell’intero documento
V14	19/02/2016	2.11.24	Aggiunta maggior dettaglio nelle tipologie di documento
V15	15/05/2018	Tutto il documento	Il documento è stato adeguato in modo da estendere il tracciato al fine di gestire i metadati richiesti per garantire l’interoperabilità nazionale con la componente INI (Infrastruttura Nazionale per l’Interoperabilità) realizzata dal Ministero dell’Economia e delle Finanze secondo quanto previsto dal comma 15-ter, articolo 12 del decreto legge 18 ottobre 2012 n.179 e successive modifiche. Per completezza di informazioni, a differenza delle altre versioni del presente documento, è stato scelto di produrre un solo documento che recepisse gli aggiornamenti del tracciato sia nel caso di invio senza documenti, sia nel caso di invio con documenti. A tal fine sono stati descritti i due modelli "Modello con invio del documento" e "Modello senza invio del documento" e sono state descritte le principali modifiche introdotte dall’integrazione con l'infrastruttura INI.
V16	15/06/2018	2.4.4, 2.11.3	Aggiunta istruzioni di cifratura per segmento PID
V17	19/07/2018	2.4.4	Aggiornata modalità di cifratura dei dati
V18	20/07/2018	2.7.8	Aggiunti diagrammi MDM_T05
V19	01/08/2018	2.7.8,2.10.9, 2.10.10 2.11.5, 2.11.6	Sostituito messaggio MDM_T05 con MDM_T06 Specificazione campi segmenti TXA e OBX Revisione tabelle 0125 e 0191
V20	22/10/2018	2.13.23	Modifica campo MSH.4 Rivista tabella Table 0362 –Facility Revisione Table CSI 003 – Ruolo Utente (Tabella 5.4-1 dell’Affinity Domain)
V21	12/07/2019	2.11.2 2.11.4 2.11.6	Modifica colonna OPT campo XCN EVN-5 Modifica campo PV1.22 (courtesy code) per aggiunta stato pagamento “Rimborso per rottura provetta” Modifica colonna OPT campo OBX.3 (per OBX.2=CE)
V22	24/10/2019	2.11.5	Aggiunta specifica per compilazione campo TXA.12 (numero univo del documento) nel caso di invio recupero pregresso

V23	24/01/2020	2.11.5	Aggiunta valorizzazioni tipologiaDocumentoAlto e tipologiaDocumentoMedio Specificazioni per Modifica campo PV1.22 (courtesy code) per aggiunta stato pagamento “Rimborso (es.per rottura provetta)”
V24	15/04/2020	2.11.16 2.12	Specificazione ed esempi OBX.5 per accession numbers multipli Aggiunta nuovi errori/warning in tab.Codici Errore
V25	15/04/2020	2.11.16 2.11.4	Modifica delle informazioni contenute nel campo OBX.5 per accession numbers Inserito chiarimento rispetto alle informazioni relative al flag “oscuramento per il cittadino”
V26	Luglio 2021	2.11.4	Modifica campo PV1.22 (courtesy code) per aggiunta stato pagamento “F” (Free – es. lettera dimissione)
V27	Luglio 2021	2.11.4	Precisazioni sull’utilizzo del campo PV1-50
V28	26/04/2022	2.12	Rimosso paragrafo ‘Codici di errore’. L’elenco degli errori si trovano su un documento apposito.
V29	29/03/2023	1.2 2.11.5 2.11.7 2.11.2	Riferimenti Aggiunto segmento SFT Aggiunto regime, oscuramento al genitore e la modalità di dimissione nel PV1 Aggiunto eventCode nel OBX
V30	03/07/2023	2.11.5	Chiarimenti su campo PV1.22 (courtesy code), sottocampi leggi speciali, privacy documento, oscuramento all’assistito, oscuramento al genitore. Chiarimenti su campo PV1.45 (data fine episodio)
V31	26/10/2023	2.12.5	Aggiornata tabella 2.12-1 Affinity Domain –Assetto organizzativo / Pratica Clinica o specialistica
V32	02/11/2023	Intero documenti	Corretto riferimento tabelle dell’Affinity Domain 2.4.1
V33	27/12/2023	2.12.1 2.11.6	Recepite modifiche/integrazioni previste dall’Affinity Domain 2.5: • Corretto riferimento codice Vaccino Covid 19. • Deprecato il valore di assetto organizzativo AD_PSC127, AD_PSC082, AD_PSC106 • Aggiornata la tabella dei codici tipo documento medio. Aggiornato il campo codiceFiscale Medico delle sezioni MediciRedattori e MediciValidatori

Indice

1. SCOPO E RIFERIMENTI DEL DOCUMENTO

7

1.1 Scopo del documento 7

1.2 Riferimenti 7

2. INTEGRAZIONE MEDIANTE MESSAGGI HL7

9

2.1 Introduzione 9

2.2 Le “informazioni sanitarie” 9

2.3 I modelli di integrazione con il Fascicolo: con o senza il documento 9

2.3.1 Modello senza invio del documento al fascicolo 9

2.3.2 Modello con invio del documento al fascicolo 10

2.4 Principali modifiche apportate al protocollo con l’introduzione di INI 10

2.4.1 Gestione dei documenti “addendum” 10

2.4.2 Formato e firma dei documenti 10

2.4.3 Dati di dettaglio del Laboratorio di Analisi 10

2.4.4 Cifratura dei dati identificativi e del documento (se inviato) 10

2.5 Le informazioni sanitarie e i messaggi HL7 11

2.6 I messaggi inviati dal ILEC ai sistemi gestionali 11

2.7 I servizi 11

2.7.1 Attori 11

2.7.2 Invia notifica apertura episodio o modifica di un episodio aperto già notificato 13

2.7.3 Invia notifica chiusura episodio o modifica di un episodio chiuso già notificato 14

2.7.4 Invia nuovo referto/documento, o aggiornamento dati strutturati legati ad un referto/documento già notificato 14

2.7.5 Sostituisci referto/documento 16

2.7.6 Invia annullamento episodio 17

2.7.7 Invia annullamento documento 18

2.7.8 Invia addendum ad un referto/documento già notificato 18

2.8 Modalità e ordine di attivazione dei servizi 19

2.9 Vincoli sui dati da inviare 19

2.10 La struttura dei messaggi 20

2.10.1 Messaggio ADT^A01^ADT_A01 – Admit/Visit Notification (Event A01) 20

2.10.2 Messaggio ACK^A01^ACK – ACK Admit/Visit Notification 20

2.10.3 Messaggio ADT^A03^ADT_A03 – Discharge/End Visit (Event A03) 20

2.10.4 Messaggio ACK^A03^ACK – ACK Discharge/End Visit 21

2.10.5 Messaggio ADT^A11^ADT_A09 – Cancel Admit / Visit Notification (Event A11) 21

2.10.6 Messaggio ACK^A11^ACK – ACK Cancel Admit / Visit Notification 21

2.10.7 Messaggio MDM^T02 – Original Document Notification and Content 21

2.10.8 Messaggio ACK^T02^ACK – ACK Original Document Notification and Content 22

2.10.9 Messaggio MDM^T06 – Document addendum notification and content 22

2.10.10 Messaggio ACK^T06^ACK – ACK Document addendum notification and content 22

2.10.11 Messaggio MDM^T10 – Document Replacement Notification and Content 23

2.10.12 Messaggio ACK^T10^ACK – ACK Document Replacement Notification and Content 23

2.10.13 Messaggio MDM^T11 – Document Cancel Notification 23

2.10.14 Messaggio ACK^T11^ACK – Document Cancel Notification 23

2.11 I segmenti dei messaggi 25

2.11.1 Segmento MSH: Message Header Segment 25

2.11.2 Segmento SFT: Software Segment 26

2.11.3 Segmento EVN: Event type 27

2.11.4 Segmento PID: Patient identification 28

2.11.5 Segmento PV1: Patient visit segment 30

2.11.6 Segmento TXA: Transcription Document Header 38

2.11.7 Segmento OBX: Observation Segment 45

2.11.8 Segmento MSA: Message Acknowledgment Segment 50

2.11.9 Segmento ERR: Error segment 50

2.12 Tabelle di codifica 51

2.12.1 Table 0001 - Administrative Sex 51

2.12.2 Table 0004 – Patient Class 51

2.12.3 Table 0008 Acknowledgement code 51

2.12.4 Table 0076 - Message Type - e Table 0003 Event Type 51

2.12.5 Table 0085 - Observation result status codes interpretation 52

2.12.6 Table 0000 - Xxxxxxxxxx XX 52

2.12.7 Table 0123 - Result Status 52

2.12.8 Table 0125 – Value Type 52

2.12.9 Table 0190 - Address type 52

2.12.10 Table 0191 – Type Of Referenced Data 53

2.12.11 Table 0203 - Identifier type 53

2.12.12 Table 0270 – Document Type 53

2.12.13 Table 0271 - Document Completion Status 54

2.12.14 Table 0272 - Document Confidentiality Status 54

2.12.15 Table 0291 – Data Subtype 55

2.12.16 Table 0299 – Encoding 55

2.12.17 Table 0357 – Message error condition codes 55

2.12.18 Table 0361 –Application 56

2.12.19 Table 0362 –Facility 56

2.12.20 Table 0363 – Assigning authority 57

2.12.21 Table 0396 – Coding system table 57

2.12.22 Table 0516 – Error severity 58

2.12.1 Table CSI 001 – modalità di dimissione 58

2.12.2 Table CSI 003 – Ruolo Utente (Tabella 5.4-1 dell’Affinity Domain) 58

2.12.3 Table 0119 - Order control codes 58

2.12.4 Table 2.8-1 Affinity Domain – Facility TypeCode 59

2.12.5 Table 2.12-1 Affinity Domain –Assetto organizzativo / Pratica Clinica o specialistica 59

2.12.6 Tabella 3.2-1 Affinity Domain: Tipologia di attività clinica/organizzativa 61

2.12.1 Table 0032 - Regime 61

2.12.1 Tabella 2.7-1 Affinity Domain: . Value set per il metadato XDSDocumentEntry.eventCodeList 61

1. Scopo e riferimenti del documento

1.1 Scopo del documento

Scopo del presente documento è di descrivere le Specifiche dei Requisiti sulle modalità di interazione dei servizi logici della Componente Locale (o ILEC, indice locale degli eventi clinici) del Fascicolo Sanitario Elettronico (FSE, da ora in poi Fascicolo) con i sistemi informativi delle Aziende Sanitarie.

Le specifiche sono basate sul protocollo HL7v2 e prevedono che l’integrazione del Sistema informativo dell’azienda sanitaria con il Fascicolo avvenga in modo tale che il documento clinico con relativi metadati a corredo venga inviato e mantenuto sull’ILEC del fascicolo appartenente al dominio dell’azienda sanitaria.

In aggiunta a quanto già previsto, saranno descritti i metadati richiesti per la realizzazione dell’interoperabilità con INI da richiedere alle Aziende in fase di alimentazione del Fascicolo presso la Componente Locale delle Aziende.

Per semplificare la lettura rispetto alla versione precedente delle specifiche in alcune tabelle (ove opportuno) è stata inserita come prima colonna l’informazione (VAR) sulla eventuale variazione rispetto alla versione precedente.

Sono stati previsti i seguenti valori:

• N: nuovo campo

• C: campo modificato

• E: campo eliminato

1.2 Riferimenti

• [SRS_INTER_CL_DIP]

DMA-CL-SRS-01-V01-Specifica_modalita_interazione_ComponenteLocale_dipartimentali.pdf, o versioni successive

• [FRAMEWORK]

Specifiche tecniche per l’interoperabilità tra i sistemi regionali di FSE Framework e dataset dei servizi base, Versione 2.4.1, 10/02/2023

• [AFFINITY DOMAIN]

Specifiche tecniche per l’interoperabilità tra i sistemi regionali di FSE Affinity Domain Italia, Versione 2.4.1, 10/02/2023

• [DPCM 178]

Decreto del Presidente del Consiglio dei Ministri 29 settembre 2015, n. 178 - Regolamento in materia di fascicolo sanitario elettronico

• [SER_RetrievalDoc]

DMA-CL-SER-21-V01-Servizio FSERetrievalDocumentService.pdf, o versioni successive

• [SRS_Elenco codici di errore]

DMA-CL-SRS-16-V33-Elenco_codici_di_errore_restituiti_dalla_RegistraEpisodio3

• [CDA] Specifiche dei CDA dei documenti xxxx://xxx.xx0xxxxxx.xx/xx0xxxxxx_X0/xx0xx_xxxxxxxxxxxx

2. Integrazione mediante messaggi HL7

2.1 Introduzione

In questo paragrafo vengono descritti i servizi presentati funzionalmente nel capitolo precedente attraverso diagrammi di sequenza HL7. Tali diagrammi rappresentano l’interazione che avviene fra i diversi attori evidenziando i messaggi HL7 scambiati.

Per descrivere meglio il flusso sono riportate anche alcune attività funzionali che vengono svolte dagli attori.

2.2 Le “informazioni sanitarie”

Scopo del presente paragrafo è fornire uno schema semantico del contenuto delle “informazioni sanitarie” che transitano dal sistema informativo dell’ASR al FSE ed due schemi sintattici che mappano lo schema dei messaggi HL7 scambiati.

Dati strutturati NONmodificabili:

⮚ Identificativounivocoepisodio

Informazione sanitariaB

Informazione sanitariaA

Episodio

⮚ Dataeoradell’episodio

⮚ Strutturasanitaria

Dati strutturati modificabili:

⮚ Dato1

⮚ Dato2

⮚ Daton

Dati strutturati/Metadati +Referto/Documento

⮚ Prestazione1

⮚ [Altri dati strutturati del referto1]

⮚ Referto1

⮚ Prestazione2

⮚ [Altri dati strutturati del referto2]

⮚ Referto2

⮚ [Altri dati strutturati del documenton]

⮚ Documenton

Figura n. 1– Mappa delle informazioni sanitarie

2.3 I modelli di integrazione con il Fascicolo: con o senza il documento

2.3.1 Modello senza invio del documento al fascicolo

Nel modello senza invio del documento, l’azienda invia i metadati al Fascicolo della Regione Piemonte senza mandare il documento che risiederà presso il repository dell’Azienda stessa.

In tale modello l’Azienda dovrà utilizzare il messaggio MDM^T02 valorizzando i segmenti TXA e OBX per comunicare i soli metadati descritto nel capitolo seguente relativo alle specifiche del protocollo.

In particolare come descritto nella struttura del segmento OBX, per il messaggio MDM^T02, non dovrà essere

valorizzato il campo

• OBX-5 Observation Value,

mentre sarà richiesta l’indicazione del repository da riportare nel campo:

• TXA-12 Unique Document Number (Entity Identifier EI.1)

alle Aziende che aderiranno al nuovo modello in conformità alle specifiche previste dall’inter-operabilità nazionale.

Inoltre l’azienda dovrà esporre il servizio di recupero del documento GetDocumento secondo le specifiche definite nel documento [SER_RetrievalDoc].

2.3.2 Modello con invio del documento al fascicolo

Nel modello con invio del documento, l’azienda invia i metadati e il documento al Fascicolo della Regione Piemonte.

In tale modello l’Azienda dovrà utilizzare il messaggio MDM^T02 valorizzando i segmenti TXA e OBX per comunicare i metadati e il documento descritto nel capitolo seguente relativo alle specifiche del protocollo.

In particolare come descritto nella struttura del segmento OBX, per il messaggio MDM^T02, dovrà essere valorizzato anche il campo OBX-5 Observation Value

2.4 Principali modifiche apportate al protocollo con l’introduzione di INI

Scopo del capitolo è descrivere le principali modifiche apportate all’attuale versione del protocollo con l’introduzione dei metadati richiesti dall’interoperabilità del Fascicolo sanitario regionale con INI.

Per un’analisi di dettaglio apportata ai dati richiesti dal protocollo, fare riferimento ai capitoli successivi.

2.4.1 Gestione dei documenti “addendum”

Il tracciato è stato esteso al fine di consentire la possibilità di inviare documenti in “Addendum” al documento principale nel caso in cui il sistema informativo dell’Azienda li preveda. Le modalità di gestione di questi documenti sono descritti nelle specifiche di dettaglio del tracciato

2.4.2 Formato e firma dei documenti

In coerenza ai requisiti di inter-operabilità nazionale si richiede che i documenti interoperabili, definiti dal decreto [DPCM 178], vengano inviati nel formato pdf con CDA iniettato e firmato con firma PADES BES, secondo le scelte adottate dalla Regione Piemonte e le direttive previste dal tavolo di lavoro inter-regionale sulla firma dei documenti per il Fascicolo Sanitario Nazionale.

2.4.3 Dati di dettaglio del Laboratorio di Analisi

I dati di dettaglio del laboratorio di analisi non vengono più richiesti (valore, range e unità di misura della prestazione).

2.4.4 Cifratura dei dati identificativi e del documento (se inviato)

Tutti i servizi HL7 realizzati per l’adeguamento a INI devono prevedere la cifratura dei dati anagrafici (nome, cognome, codice fiscale, luogo di nascita) e – quando presente - del documento inviato.

La cifratura verrà effettuata dalle Aziende Sanitarie sui campi indicati utilizzando l’algoritmo di cifratura AES con chiave simmetria a 256bit.

Ogni Azienda genererà una propria chiave simmetrica a 256 bit ed, in fase di predisposizione degli ambienti, dovrà comunicare via e-mail al CSI Piemonte la chiave simmetrica utilizzata assieme al codice dell’applicazione del dipartimentale che utilizzerà per inviare i messaggi HL7.

La comunicazione della chiave non dovrà avvenire in chiaro; l’Azienda dovrà cifrare la chiave simmetrica che utilizzerà per le comunicazioni con la chiave pubblica del FSEr (che verrà fornita dal CSI-Piemonte) utilizzando l’algoritmo AES-256 CBC.

2.5 Le informazioni sanitarie e i messaggi HL7

La gestione di un episodio clinico può essere gestito da più messaggi, in generale:

1 da un messaggio di apertura dell’episodio (ADT^A01) che contiene:

1.1 dati strutturati che caratterizzano l’episodio:

1.1.1 identificativo univoco dell’episodio,

1.1.2 data ed ora dell’episodio,

1.1.3 Struttura sanitaria di erogazione;

2 da un messaggio di chiusura dell’episodio (ADT^A03) che contiene:

2.1 dati strutturati che caratterizzano l’episodio:

2.1.1 identificativo univoco dell’episodio,

2.1.2 data ed ora apertura dell’episodio (ovvero di accettazione per episodi di ricovero e di PS),

2.1.3 data ed ora chiusura dell’episodio (ovvero di dimissione per episodi di ricovero e di PS),

2.1.4 Struttura sanitaria di erogazione;

3 da un messaggio per invio dei dati strutturati relativi ad un referto/documento (MDM^T02); qualora l’Azienda non sia dotata di un repository aziendale tale messaggio include anche il documento allegato all’episodio; viene inviato un messaggio per ogni documento da trasmettere; tale messaggio può essere utilizzato anche per aggiornare i dati strutturati legati al documento trasmesso.

4 da un messaggio di invio di documento addendum (MDM^T06)

5 da un messaggio di sostituzione di un documento (MDM^T10– l’OBX contiene il codice del nuovo documento, il nuovo contenuto e lo stato con valore “C”; il segmento TXA contiene l’identificativo del documento obsoleto nel campo “Parent Document Number” e l’identificativo del nuovo documento nel campo “Unique Document Number”);

6 da un messaggio di annullamento di un documento (MDM^T11)

7 da un messaggio di annullamento di un episodio (ADT^A11)

2.6 I messaggi inviati dal ILEC ai sistemi gestionali

In risposta ai messaggi inviati al ILEC dai sistemi informativi aziendali, l’ILEC stesso restituisce il corrispettivo messaggio di acknowledge.

2.7 I servizi

2.7.1 Attori

Nel seguito verranno descritti gli attori che partecipano all'integrazione:

• applicazione dell’Azienda Sanitaria (quale ad esempio: cartella, ambulatoriale, sistema DEA, sistema di ricovero, etc)

• CL: Componente Locale del FSE dedicata ad una Azienda Sanitaria (tale componente fa parte del dominio informatico dell’azienda). In tale componente è presente l’ILEC (Indice Locale degli Eventi Clinici).

Simboli presenti nei diagrammi di sequenza:

Boundary

È un’entità che giace al perimetro del sistema, ma ancora entro esso. Interagisce con attori al di fuori del sistema, entity, controller e altre boundary.

Worker

Rappresenta l’astrazione di un essere umano che agisce entro il sistema. Un worker interagisce con altri worker e entità del sistema.

Entity

Entità passiva che non effettua interazioni per proprio conto. Usato per rappresentare le componenti del sistema informativo dell’Azienda.

: FSA TO2

2.7.2 Invia notifica apertura episodio o modifica di un episodio aperto già notificato

: Applicazione

CL

1 : ADT^A01

3 : ACK^A01^ACK - con ERR

]

[Xx

0 : ACK^A01^ACK - no ERR

borazione effettuata correttamente?

alt Ela

[Si]

Figura n. 2– Diagramma sequenza HL7 - Invia notifica apertura episodio

2.7.3 Invia notifica chiusura episodio o modifica di un episodio chiuso già notificato

CL

Figura n. 3– Diagramma sequenza HL7 - Invia notifica chiusura episodio

2.7.4 Invia nuovo referto/documento, o aggiornamento dati strutturati legati ad un

: FSA TO2

referto/documento già notificato

: Applicazione

CL

1 : MDM^T02 Stato OBX-11 = F

3 : ACK^T02^ACK - con ERR

[No]

2 : ACK^T02^ACK - no ERR

xxxxx effettuata correttamente?

alt Elabora

[Sì]

Figura n. 3– Diagramma sequenza HL7- Invia nuovo referto/documento

: CL Dossier

2.7.5 Sostituisci referto/documento

: Dipartimentale

CL

1 : MDM^T10

alt Elaborazione effettuata correttamente?

Stato OBX-11 = C (nel caso di valore modificato) oppure

Stato OBX-11 = D (nel caso di valore cancellato) Referto/Documento nel segmento OBX

Stato OBX-11 = C

TXA-12 e 13 contengono rispettivamente nuovo id e vecchio id del referto/documento

[Sì]

2 : ACK^T10^ACK - no ERR

[No]

3 : ACK^T10^ACK - con ERR

Figura n. 4– Diagramma sequenza HL7- Sostituisci referto/documento

Nel caso di sostituzione di un documento comunicato come addendum il campo TXA-13 dovrà contenere l’id del documento addendum da sostituire.

Il documento parent non subirà modifiche.

DMA-CL-SRS-12-V33-

Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx

Gennaio 2024

uso: Esterno Pagina 16 di 62

: FSA TO2

2.7.6 Invia annullamento episodio

: Applicazione

CL

1 : ADT^A11

alt Elaborazione effettuata correttamente?

[SI]

3 : ACK^A11^ACK - con ERR

[NO]

2 : ACK^A11^ACK - no ERR

Figura n. 5– Diagramma sequenza HL7- Invio annullamento episodio

2.7.7 Invia annullamento documento

L’annullamento del documento è realizzato con il messaggio MDM^T11.

Figura n.7– Diagramma sequenza HL7- Invio annullamento documento

Nel caso di annullamento di un documento al quale sono collegati uno o più addendum, sarà necessario effettuare preventivamente l’annullamento degli addendum, valorizzando il campo TXA-12 con l’identificativo del documento di Addendum.

Una volta eliminati tutti gli addendum sarà possibile eliminare anche il documento parent, con le stesse modalità, valorizzando il campo TXA-12 con l’identificativo del documento parent.

2.7.8 Invia addendum ad un referto/documento già notificato

L’invio di un addendum è realizzato con il messaggio MDM^T06

Figura n.8 – Diagramma sequenza HL7- Invio addendum a documento

2.8 Modalità e ordine di attivazione dei servizi

La modalità e l’ordine di attivazione dei servizi è descritta nel capitolo funzionale; per costruire i diagrammi temporali in HL7 è sufficiente partire dai singoli diagrammi funzionali e sostituire al singolo servizio interessato il corrispondente diagramma HL7.

2.9 Vincoli sui dati da inviare

Si precisa che le ASO/ASL che si integrano con il fascicolo SOLO per l’utilizzo dello scarico referti non dovranno inviare messaggi HL7 legati alla gestione dell’episodio, ma solo i messaggi relativi ai referti.

Pertanto gli applicativi dipartimentali non dovranno inviare messaggi di tipo ADT al fascicolo.

Nel caso in cui si dovesse verificare un annullamento di episodio, a cui è legato un referto già inviato al fascicolo per lo scarico online, il dipartimentale deve inviare un annullamento del documento, attraverso il messaggio MDM^T11.

In caso si verificasse invece lo spostamento di un episodio da un paziente ad un altro, il dipartimentale deve inviare un annullamento del documento, attraverso il messaggio MDM^T11, ed inviare un messaggio MDM^T02 per il referto del paziente nuovo.

2.10 La struttura dei messaggi

Nei paragrafi successivi verranno presentati i segmenti e i campi che sono di interesse per ciascun messaggio. Nel presente capitolo si farà riferimento alla versione 2.6 di HL7.

Il valore della colonna OPT delle tabelle delle descrizioni dei segmenti HL7 può essere: R (obbligatorio), O (facoltativo), C (campo condizionale). Tale informazione va interpretata nel contesto specifico del FSE della Regione Piemonte.

2.10.1 Messaggio ADT^A01^ADT_A01 – Admit/Visit Notification (Event A01)

Il messaggio rappresenta la notifica di accettazione del ricovero di un paziente per gli episodi di ricovero. L’invio del messaggio è facoltativo per gli episodi di tipo ambulatoriale in quanto, in assenza del messaggio ADT^A01^ADT_A01, alla ricezione di un messaggio MDM il sistema provvederà in autonomia a creare anche il corrispondente episodio.

Il messaggio ADT^A01^ADT_A01 è obbligatorio nel caso di apertura di un episodio di ricovero qualora la matricola di dimissione sia differente dalla matricola di dimissione.

Il messaggio ADT^A01^ADT_A01 è costituito dai segmenti elencati nella tabella che segue.

Segmento	Descrizione	Note
MSH	Message Header	Indicazioni generali sul messaggio inviato.
[SFT]	Software segment	identificativo applicazione, identificativo fornitore e versione
EVN	Event Type
PID	Patient Identification	Dati anagrafici del paziente
PV1	Patient Visit	Dati di accettazione

2.10.2 Messaggio ACK^A01^ACK – ACK Admit/Visit Notification

Risposta alla notifica di accettazione del ricovero di un paziente per gli episodi di ricovero. Il messaggio ACK^A01^ACK è costituito dai segmenti elencati nella tabella che segue.

Segmento	Descrizione	Note
MSH	Message Header	Indicazioni generali sul messaggio inviato.
[{SFT}]	Software segment	non usato
MSA	Message acknowledge
[{ERR}]	Error information

2.10.3 Messaggio ADT^A03^ADT_A03 – Discharge/End Visit (Event A03)

Il messaggio rappresenta la notifica di dimissione di un paziente per gli episodi di ricovero.

Il messaggio ADT^A03^ADT_A03 è obbligatorio nel caso in cui si sia inviato, per il medesimo episodio, un messaggio ADT^A01^ADT_A01 e la matricola di dimissione sia diversa da quella di accettazione.

Il messaggio ADT^A03^ADT_A03 è costituito dai segmenti elencati nella tabella che segue.

Segmento	Descrizione	Note
MSH	Message Header	Indicazioni generali sul messaggio inviato.
[SFT]	Software segment	identificativo applicazione, identificativo fornitore e versione
EVN	Event Type

DMA-CL-SRS-12-V33- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx Gennaio 2024 uso: Esterno Pagina 20 di 62

PID	Patient Identification	Dati anagrafici del paziente
PV1	Patient Visit	Dati di accettazione

2.10.4 Messaggio ACK^A03^ACK – ACK Discharge/End Visit

Risposta alla notifica di dimissione di un paziente per gli episodi di ricovero.

Il messaggio ACK^A03^ACK è costituito dai segmenti elencati nella tabella che segue.

Segmento	Descrizione	Note
MSH	Message Header	Indicazioni generali sul messaggio inviato.
[{SFT}]	Software segment	non usato
MSA	Message acknowledge
[{ERR}]	Error information

2.10.5 Messaggio ADT^A11^ADT_A09 – Cancel Admit / Visit Notification (Event A11)

Il messaggio rappresenta la notifica di annullamento di un episodio di ricovero.

Il messaggio ADT^A11^ADT_A09 è costituito dai segmenti elencati nella tabella che segue.

Segmento	Descrizione	Note
MSH	Message Header	Indicazioni generali sul messaggio inviato.
[SFT]	Software segment	identificativo applicazione, identificativo fornitore e versione
EVN	Event Type
PID	Patient Identification	Dati anagrafici del paziente
PV1	Patient Visit	Dati di accettazione

Nel PV1 deve essere riportato il numero nosologico da annullare.

2.10.6 Messaggio ACK^A11^ACK – ACK Cancel Admit / Visit Notification

Risposta alla notifica di annullamento di un episodio di ricovero.

Il messaggio ACK^A11^ACK è costituito dai segmenti elencati nella tabella che segue.

Segmento	Descrizione	Note
MSH	Message Header	Indicazioni generali sul messaggio inviato.
[{SFT}]	Software segment	non usato
MSA	Message acknowledge
[{ERR}]	Error information

2.10.7 Messaggio MDM^T02 – Original Document Notification and Content

Il messaggio è utilizzato per notificare un documento validato; il documento è inteso come costituito da alcuni metadati e dal suo contenuto.

Ogni messaggio MDM^T02 contiene uno ed un solo documento.

Il messaggio MDM^T02 è costituito dai segmenti elencati nella tabella che segue.

Segmento	Descrizione	Note
MSH	Message Header	Indicazioni generali sul messaggio inviato.
[SFT]	Software segment	identificativo applicazione, identificativo fornitore e versione
EVN	Event Type

DMA-CL-SRS-12-V33- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx Gennaio 2024 uso: Esterno Pagina 21 di 62

PID	Patient Identification	Dati anagrafici del paziente
PV1	Patient Visit	Dati sulla visita
TXA	Transcription Document Header	Dati di intestazione del documento
{
OBX	Observation/Result (one or more required)	Contenuto del documento
}

2.10.8 Messaggio ACK^T02^ACK – ACK Original Document Notification and Content

Risposta alla notifica della creazione del documento.

Il messaggio ACK^T02^ACK è costituito dai segmenti elencati nella tabella che segue.

Segmento	Descrizione	Note
MSH	Message Header	Indicazioni generali sul messaggio inviato.
[{SFT}]	Software segment	non usato
MSA	Message acknowledge
[{ERR}]	Error information

2.10.9 Messaggio MDM^T06 – Document addendum notification and content

Il messaggio è utilizzato per notificare un documento addendum di un documento precedentemente inviato; il documento è inteso come costituito da alcuni metadati e dal suo contenuto.

Ogni messaggio MDM^T06 contiene uno ed un solo documento.

Il messaggio MDM^T06 è costituito dai segmenti elencati nella tabella che segue.

Segmento	Descrizione	Note
MSH	Message Header	Indicazioni generali sul messaggio inviato.
[SFT]	Software segment	identificativo applicazione, identificativo fornitore e versione
EVN	Event Type
PID	Patient Identification	Dati anagrafici del paziente
PV1	Patient Visit	Dati sulla visita
TXA	Transcription Document Header	Dati di intestazione del documento
{
OBX	Observation/Result (one or more required)	Contenuto del documento
}

2.10.10 Messaggio ACK^T06^ACK – ACK Document addendum notification and content

Risposta alla notifica della creazione del documento.

Il messaggio ACK^T06^ACK è costituito dai segmenti elencati nella tabella che segue.

Segmento	Descrizione	Note
MSH	Message Header	Indicazioni generali sul messaggio inviato.
[{SFT}]	Software segment	non usato
MSA	Message acknowledge
[{ERR}]	Error information

DMA-CL-SRS-12-V33- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx Gennaio 2024 uso: Esterno Pagina 22 di 62

2.10.11 Messaggio MDM^T10 – Document Replacement Notification and Content

Notifica di sostituzione del documento, con allegato il contenuto.

Il messaggio MDM^T10 è costituito dai segmenti elencati nella tabella che segue.

Segmento	Descrizione	Note
MSH	Message Header	Indicazioni generali sul messaggio inviato.
[SFT]	Software segment	identificativo applicazione, identificativo fornitore e versione
EVN	Event Type
PID	Patient Identification	Dati anagrafici del paziente
PV1	Patient Visit	Dati sulla visita
TXA	Transcription Document Header	Dati di intestazione del documento
{
OBX	Observation/Result (one or more required)	Contenuto del documento
}

2.10.12 Messaggio ACK^T10^ACK – ACK Document Replacement Notification and Content

Risposta alla notifica della sostituzione del documento.

Il messaggio ACK^T10^ACK è costituito dai segmenti elencati nella tabella che segue.

Segmento	Descrizione	Note
MSH	Message Header	Indicazioni generali sul messaggio inviato.
[{SFT}]	Software segment	non usato
MSA	Message acknowledge
[{ERR}]	Error information

2.10.13 Messaggio MDM^T11 – Document Cancel Notification

Notifica di annullamento del documento.

Il messaggio MDM^T11 è costituito dai segmenti elencati nella tabella che segue.

Segmento	Descrizione	Note
MSH	Message Header	Indicazioni generali sul messaggio inviato.
[SFT]	Software segment	identificativo applicazione, identificativo fornitore e versione
EVN	Event Type
PID	Patient Identification	Dati anagrafici del paziente
PV1	Patient Visit	Dati sulla visita
TXA	Transcription Document Header	Dati di intestazione del documento

2.10.14 Messaggio ACK^T11^ACK – Document Cancel Notification

Risposta alla notifica della cancellazione del documento.

Il messaggio ACK^T11^ACK è costituito dai segmenti elencati nella tabella che segue.

Segmento	Descrizione	Note
MSH	Message Header	Indicazioni generali sul messaggio inviato.
[{SFT}]	Software segment	non usato
MSA	Message acknowledge
[{ERR}]	Error information

DMA-CL-SRS-12-V33- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx Gennaio 2024 uso: Esterno Pagina 23 di 62

2.11 I segmenti dei messaggi

2.11.1 Segmento MSH: Message Header Segment

Il segmento MSH è uno dei segmenti di controllo. Fornisce una serie di informazioni generali, tra le quali:

🟃 chi invia

🟃 chi riceve

🟃 quale messaggio si sta inviando

🟃 data e ora di creazione del messaggio

🟃 l’identificativo univoco per il riconoscimento del messaggio.

VAR	SEQ	LEN	DT	O P T	ELEMENT NAME	TBL	NOTE	ESEMPIO
	1	1	ST	R	Field Separator		Contiene il carattere pipe “|” ed identifica il carattere usato come separatore nel resto del messaggio.	|
	2	4	ST	R	Encoding Characters		Contiene i separatori utilizzati, ovvero “^~\&” per identificare il separatore, rispettivamente, del componente, di ripetizione, di escape e di sottocomponente.	^~\&
	3	227	HD	O	Sending Application	Table 0361 – Application	Dipartimentale inviante	^HIS_DEA
	4	227	HD	O	Sending Facility	Table 0362 – Facility	L’entità organizzativa responsabile dell’invio delle informazioni. INDICARE IL CODICE ASR INVIANTE. Per i privati rappresenta la ASR indicata sul sistema AURA	^203
	5	227	HD		Receiving Application	Table 0361 – Application	Dipartimentale ricevente	^CL
	6	227	HD	O	Receiving Facility	Table 0362 – Facility	L’entità organizzativa che riceve le informazioni. Xxxxx ricevente	^CSI
	7	24	DT M	R	Date/Time Of Message		Data e ora in cui è stato creato il messaggio dal sistema inviante. Il formato è aaaammgghhMMss. Il valore è analogo al valore del campo EVN^ Recorded Date/Time.	20080104130101
	9	15	MS G	R	Message Type	Table 0076 message code Table 0003 trigger code	Tipo del messaggio HL7. L’informazione specifica il codice del messaggio (es: ADT, MDM, etc), il trigger event (R01, A01, etc)	MDM^T02

	10	199	ST	R	Message Control ID		Identificativo unico del messaggio, generato dall’inviante.	34
	11	3	PT	R	Processing ID	Table 0000 - Xxxxxxxxxx XX		P
	12	60	VID	R	Version ID		Identifica la versione HL7 ed è utilizzata dal sistema ricevente per interpretare correttamente il messaggio. Il valore del campo è fissato a “2.6”.	2.6

Struttura del campo HD MSH-3

VAR	SE Q	LEN	DT	OPT	TBL	COMPONENT NAME	Note
	1	20	IS	O		Namespace Id	Non valorizzare
	2	999	ST	R	Table 0361 – Application	Universal ID	Dipartimentale inviante

Struttura del campo HD MSH-4

VAR	SE Q	LEN	DT	OPT	TBL	COMPONENT NAME	Note
	1	20	IS	O		Namespace Id	Non valorizzare
	2	999	ST	R	Table 0362 –Facility	Universal ID	L’entità organizzativa responsabile dell’invio delle informazioni.

Struttura del campo HD MSH-5

VA R	SEQ	LEN	DT	OPT	TBL	COMPONENT NAME	Note
	1	20	IS	O		Namespace Id	Non valorizzare
	2	999	ST	R	Table 0361 – Application	Universal ID	Dipartimentale ricevente

Struttura del campo HD MSH-6

VA R	SEQ	LEN	DT	OPT	TBL	COMPONENT NAME	Note
	1	20	IS	O		Namespace Id	Non valorizzare
	2	999	ST	R	Table 0362 –Facility	Universal ID	L’entità organizzativa che riceve le informazioni.

2.11.2 Segmento SFT: Software Segment

Il segmento SFT contiene le informazioni richieste dall’Affinity Domain Italia previste per l’identificativo applicazione, identificativo fornitore e versione.

VAR SEQ LEN DT O P ELEMENT NAME TBL NOTE ESEMPIO

DMA-CL-SRS-12-V33- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx Gennaio 2024 uso: Esterno Pagina 26 di 62

				T
N	1	567	XO N	R	Software Vendor Organization		Contiene l’identificativo del fornitore. Valorizzare XON.1	FORNITOREX
N	2	15	ST	R	Software Certified Version or Release Number		Contiene la versione dell’applicazione.	1.5
N	3	20	ST	R	Software Product Name		Contiene l’identificativo dell’applicazione	APPLICX

NOTA. L’identificativo del fornitore, dell’applicazione e la versione da inviare devono essere quelle comunicate in fase di accreditamento con il Gateway (riferimento xxxxx://xxxxxx.xxx/xxxxxxxxx-xxxxxx/xx- fse-accreditati).

2.11.3 Segmento EVN: Event type

Il segmento EVN è uno dei segmenti di controllo. Sono specificate le informazioni: data e ora di creazione del messaggio e utente.

VAR	SEQ	LEN	DT	OPT	ELEMENT NAME	TBL	NOTE	ESEMPIO
	2	24	ID	R	Recorded Date/Time		Data e ora registrazione evento nel formato aaaammgghhMMss. Il valore è analogo al valore del campo MSH^ Date/Time Of Message.	20080104130101
	5	250	XCN	R	Operator ID		Rappresenta i dati dell’utente che fa richiesta del servizio di interoperabilità. Contiene il codice fiscale, il ruolo e la struttura di appartenenza.

Struttura del campo XCN EVN-5

VA R	SEQ	LEN	DT	OPT	TBL	COMPONENT NAME	Note
	1	16	ST	R		Person Identifier	Codice Fiscale Utente
	9	227	HD	R	Tab CSI 003 - Ruoli	Assigning Authority	Ruolo (contenuto in HD.2)
	23	750	CW E	R		Assigning Agency or Department	Per la struttura dell’utente indicare in CWE.1 alternativamente - Codice matricola ARPE Oppure - Codice Azienda+Codice struttura + subcodice eventuale

Esempio: CCCNNN69A03L219D^^^^^^^^&MEDOSP^^^^^^^^^^^^^^21001012300 CCCNNN69A03L219D^^^^^^^^&MEDOSP^^^^^^^^^^^^^^1234

Struttura del campo HD XCN -9 ENV-5

SEQ	LEN	DT	OPT	TBL	COMPONENT NAME	Note
1	00	XX	X		Xxxxxxxxx Xx	Lasciare vuoto
2	000	XX	X	Xxx XXX 000	Xxxxxxxxx XX	Ruolo di interoperabilità Esempio &MEDOSP

Struttura del campo XXX XXX-00 XXX-0

SEQ	LEN	DT	OPT	TBL	COMPONENT NAME	Note
1	20	ST	O		Identifier	Per la struttura dell’utente indicare in alternativa - Codice matricola ARPE Oppure (separati con $) - Codice Azienda$Codice struttura+subcodice eventuale Esempio 1234 Esempio 210$01012300

2.11.4 Segmento PID: Patient identification

Il segmento PID contiene i dati del paziente.

Come indicato nel paragrafo 2.4.4 i dati identificativi del paziente e dell’eventuale genitore/tutore devono esserei inviati cifrati. Negli esempi riportati, per maggiore chiarezza, i dati cifrati vengono visualizzati in chiaro.

VAR	SEQ	LEN	DT	OPT	ELEMENT NAME	TBL	NOTE	ESEMPIO
	3	250	CX	R	Patient Identifier List		Lista degli identificativi associati al paziente, contiene le informazioni relative al: codice fiscale (CIFRATO), identificativo anagrafe centrale, identificativo dell’anagrafe locale, ID- AURA. Il CODICE FISCALE va riportato come PRIMO codice della lista. Vedi nota (1)	RSSMRI69A03L219 D^^^^NNITA~1982 7^^^^PZCE~92873^ ^^^PZLO~192383^^ ^^AURA
	5	250	XPN	R	Patient Name		Cognome (CIFRATO), Nome (CIFRATO). Vedi nota (2)	XXXXX^XXXXX
	7	24	DTM	R	Date/Time of Birth		Data di nascita nel formato aaaammgg	19690420
	8	1	IS	R	Administrative sex	Table 0001 - Administrative Sex	Sesso del paziente	M
	11	250	XAD	O	Patient		Luogo di nascita del	^^001272^^^100^B

					Address		paziente (CIFRATO). Vedi nota (3)
	21	250	CX	O	Mother’s		Contiene in CX.1 il
					Identifier		codice fiscale
							(CIFRATO) del
							genitore/tutore che ha
							effettuato la richiesta
							(riportare per intero anche
							se CX.1 lungo 15)

Nota (1)

Struttura campo CX PID-3

SEQ	LEN	DT	OPT	TBL	COMPONENT NAME	Note
1	15	ST	R		ID Number	Codice (fiscale,locale,AURA,…). Il codice fiscale è lungo 16 caratteri, ma, anche se eccedente le dimensioni del campo, deve essere riportato per intero e CIFRATO	Esempio RSSMRI69A03L219D
5	5	ID	R	Table 0203 - Identifier type	Identifier Type Code		Esempio NNITA

Il campo è ripetibile.

Il codice fiscale (NNITA) è obbligatorio.

Esempi: RSSMRI69A03L219D^^^^NNITA

19827^^^^PZCE A92873^^^^PZLO

23456^^^^AURA

Nota (2)

Struttura campo XPN PID-5

SEQ	LEN	DT	OPT	TBL	COMPONENT NAME	Note
1	194	FN	R		Family Name	Cognome (CIFRATO)
2	30	ST	R		Given Name	Nome (CIFRATO)

Esempio:

XXXXX^XXXXX

Nota (3)

Struttura campo XAD PID-11

	SEQ	LEN	DT	OPT	TBL	COMPONENT NAME	Note
	3	50	ST	R	ISTAT	City	Codice del Comune (CIFRATO)
	6	3	ID	R	ISTAT	Country	Codice dello stato (CIFRATO)
	7	3	ID	R	Table 0190 - Address type	Address type	Tipo di indirizzo

Per il luogo di nascita devono essere valorizzati solo i campi 3 e 6.

Per pazienti nati all’estero l’istat di nascita deve essere composto da ‘999’ + il codice dello stato di nascita. Esempi:

^^001272^^^100^B

^^999257^^^257^B

Il campo PID.23 non va valorizzato.

2.11.5 Segmento PV1: Patient visit segment

Il segmento PV1 contiene i dati caratterizzanti l’episodio:

• tipologia dell’accesso del paziente,

• struttura e medico che effettua la prestazione,

• identificativo univo dell’episodio,

• informazioni sull’accettazione e dimissione del paziente.

VA R	SEQ	LE N	DT	OP T	ELEMENT NAME	TBL	NOTE	ESEMPIO
	2	1	IS	R	Patient class	Table 0004 Patient class	Tipologia dell’episodio	E
	3	80	PL	O	Assigned patient location		Include le seguenti informazioni: - matricola della UP - matricola centro prelievo - tipologia struttura che ha prodotto il documento - Assetto Organizzativo - Tipologia di attività clinica Vedi nota (1).
	11	80	PL	O	Temporary Locaton	ISTAT	Deprecato
	19	250	CX	O	Visit Number		Identificativo dell'episodio. Può contenere per le diagnostiche il numero di passaggio della diagnostica per il pronto soccorso il numero di passaggio in pronto soccorso per la cartella clinica il numero di accesso in cartella clinica per la gestione del ricovero il numero di SDO Vedi nota (0)	00000000000^^^^LIS
	21	2	IS	O	Charge price indicator	0032	Valorizzare con il regime	SSN
C	22	2	IS	O	Courtesy Code		Questo campo è utilizzato per inviare informazioni aggiuntive sul documento. E’ significativo per i messaggi MDM	1234567890$S$U$N$ DOC0001$N$36,50$0 $$0

di invio, aggiornamento/sostituzione e annullamento del documento 1)Codice PIN per lo scarico del documento da parte del cittadino, 2)l’indicazione se è un referto scaricabile via web, 3)l’indicazione del pagamento ticket sul documento ATTENZIONE: l’informazione del pagamento deve essere comunque inviata per tutte le tipologie di documento per rendere possibile lo scarico/visualizzazione del documento sia su ROL che su FSE.
4)il flag che indica se il documento contiene dati soggetti a leggi speciali quali per esempio sieropositività, aborti/ivg ecc. (vedi paragrafo vincoli sui dati da inviare). Se il tag viene valorizzato con ‘S’ allora il campo privacy deve essere valorizzato con 1 (ovvero il documento che contiene prestazioni ‘soggette a leggi speciali’ deve essere inviato come ‘oscurato ai professionisti sanitari’)
5)codice documento che identifica il documento da scaricare.
6)Flag che indica se il documento è oscurato per il cittadino in quanto un operatore sanitario che ha redatto il referto ha dichiarato che il documento non è scaricabile perché deve essere consegnato dal medico direttamente al cittadino. Il documento oscurato al cittadino diventerà ‘visibile’ dallo stesso quando un professionista sanitario effettua la ‘mediazione’ di tale documento (inoltrando così al FSEr l’aggiornamento di tale valore). Se il documento oscurato al cittadino è stato inviato anche come oscurato ai professionisti sanitari (valore privacy documento =1) questo documento non potrà essere visualizzato né dal cittadino né dal professionista sanitario (che dunque non potrà procedere con la mediazione dello stesso). CodicePIN=12345678 90 Referto scaricabile=S Pagato ticket=N Leggi speciali=N Codice documento=DOC001 Oscurato per cittadino=M Importo ticket da pagare=36.50 Importo ticket pagato=0 privacyDocumentoFSE = 0 oscuramentoGenitore =N

7)Importo ticket da pagare:

Indica l’importo inteso in euro che deve essere ancora pagato dal paziente. Tale importo può essere nullo, pari a una parte o all’intero costo del ticket, rispettivamente a seconda che il paziente abbia già pagato tutto (o sia esente), abbia pagato parte del ticket o non abbia pagato nulla.

Formato: numero decimale avente il carattere “.” come divisore e NON la “,”.

Esempio: “21.50”.

8) Importo ticket Pagato.

Indica l’importo inteso in euro che è già stato pagato dal paziente. .

Formato: numero decimale avente il carattere “.” come divisore e NON la “,”.

Vale l’equazione:

Importo ticket da pagare =Importo tot.ticket – Importo ticket pagato

9)Scaricabile Senza Ticket Pagato (DEPRECATO) – inviare vuoto

10)Privacy documento FSE

Le informazioni sono separate da un carattere $.

11)OscuramentoGenitore

Indica se il documento del minorenne è oscurato al genitore.

Per il pagamento ticket i valori ammessi sono:

- S: pagato ticket

- N: non pagato ticket

- E: esente

- P: pagamento parziale o incompleto

- U: non definito/informazione non reperibile

- R: rimborso (es.per rottura provetta). Il valore “R” NON DEVE essere inviato - in caso di aggiornamento dei metadati – se in un procedente invio era stato inviato “E”

- F Free : Il valore “F” va indicato per

tutti quei documenti che NON sono soggetti a pagamento da parte del cittadino (es Lettera di dimissione)

Nel caso di invio di R il valore del campo Importo ticket da pagare deve essere negativo o nullo

(es -5.00)

Il flag che indica se il referto è scaricabile via web può valere: S –> scaricabile

N -> non scaricabile

Se il referto è scaricabile deve essere valorizzato anche il codice PIN.

NOTA: il PIN generato non deve contenere il carattere $

Il flag che indica se il referto contiene

dati soggetti a leggi speciali può valere:

S-> se li contiene

N-> se non li contiene

Il codice che identifica il documento da scaricare è un codice che viene presentato al cittadino nella maschera per lo scarico dei referti affinché possa identificare il pin da utilizzare. Tale informazione è necessaria soprattutto nel caso in cui venga prodotto più di un documento a fronte di una richiesta esami e i documenti abbiano codice pin diverso. Questa informazione deve essere stampata anche sul foglio di promemoria consegnato al cittadino.

Il flag di oscuramento per il cittadino (documento che richiede la mediazione del medico)

può valere:

S -> documento non visualizzabile dal cittadino, su richiesta di

un operatore sanitario. Il documento non sarà disponibile per il Ritiro referti online (anche quando il documento verrà mediato e quindi impostato a M)

N-> documento visualizzabile dal cittadino

M-> il contenuto del documento è stato illustrato (ovvero mediato) da un medico al cittadino e quindi è visualizzabile dal cittadino su FSE ma non sarà disponibile per il Ritiro referti online

Privacy documento FSE

0-> se il referto è visibile agli operatori sanitati

1 -> se il referto deve essere oscurato agli operatori sanitati

Il campo privacyDocumento consente all’assistito di oscurare un documento a tutti i professionisti sanitari (esclusi i medici che hanno redatto o validato il referto) e ai delegati deboli(*). In questo caso non verranno restituiti neppure i metadati del documento.

(*) L’assistito può delegate soggetti terzi alla consultazione del proprio fascicolo. I delegati, contrariamente ai professionisti sanitari, possono accedere al fascicolo sanitario del delegante anche se il consenso alla consultazione è negato. Il delegante può attribuire due tipologie di deleghe indicate come ‘delega debole’ o ‘delega forte’. Se la delega è di grado ‘debole’, il delegato non vedrà i documenti puntualmente oscurati. Se la delega è di grado ‘forte’ il delegato vedrà anche i documenti puntualmente oscurati. La delega genitore-minore è sempre di grado ‘forte’. I genitori pertanto vedranno anche i documenti oscurati puntualmente (ma non quelli oscurati al genitore).

OscuramentoGenitore, i valori ammessi sono:

S -> oscurato al genitore

N o non valorizzato -> non oscurato al genitore

Nel caso in cui il documento si riferisca ad un assistito minorenne e il campo OscuramentoGenitore non sia valorizzato verrà restituito un warning

							non bloccante.
	24	2	IS	O	Contract Code		Indica se l’inserimento è avvenuto a fronte di una richiesta di consenso al pregresso. Indicare S o N Se non valorizzato viene interpretato come X	X
X	00	0	IS	O	Discharge Disposition	Table CSI 001	Modalità di dimissione, da valorizzare nel caso di invio di lettera di dimissione o di verbale di pronto soccorso.	0
	44	24	DT M	C	Admit Date/Time		Può contenere: 1. Data e ora di accettazione del ricovero, oppure 2. Data e ora della visita ambulatoriale, oppure 3. Data e ora di accesso al pronto soccorso. Nel formato aaaammgghhmm.	200712041505
	45	24	DT M	C	Discharge Date/Time		Può contenere: 1. Data e ora di dimissione, oppure 2. Data e ora di uscita dal pronto soccorso. 3. Data e ora di chiusura della visita ambulatoriale Nel formato aaaammgghhmm. La data di dimissione/uscita/chiusura deve essere valorizzata ogni volta che l’episodio risulta concluso poiché tale valore condiziona la visibilità dei referti inviati. L’assenza di questa data determina la manca restituzione ai cittadini e ai medici dei metadati e del documento associato all’episodio in oggetto. Al momento, per limitare i disagi nella consultazione dei documenti, il vincolo sulla restituzione dei dati privi di data di dimissione è rimasto per i documenti associati ad un episodio di ricovero . I documenti associati ad un episodio di PS privi di data fine saranno visualizzati trascorsi tre giorni dalla data di inizio, mentre i documenti associati ad altri tipi di episodio che non siano episodio di ricovero o di PS sono mostrati anche se privi della data di fine	200712041715

50 250 CX O Alternate Visit ID Identificativo che permette di associare in modo univoco l’episodio in questione con quello che ha originato la richiesta ; a seconda del tipo di episodio può corrispondere al Numero Nosologico del ricovero o al Numero di Passaggio PS. A seconda del richiedente può contenere: 1. In caso di episodio di pronto soccorso il numero di passaggio di pronto soccorso; 2. In caso di episodio di ricovero il numero di SDO;
Vedi nota (0) 000000000000^^^^PS

(1) Struttura campo PL PV1-3

SEQ	LEN	DT	OPT	TBL	COMPONENT NAME	NOTE	ESEMPIO
1	20	IS	O		Point of care	Matricola (ARPE): - Nel caso di messaggio ADT^A01 è la matricola di accettazione/ammissione. - Nel caso di messaggio ADT^A03 è la matricola di dimissione. - Per i messaggi MDM è la matricola della struttura che produce il documento. Nel caso di Lettera di Dimissione è la matricola della struttura di dimissione	2209
2	20	IS	O		Room	Codice che identifica la matricola (ARPE) che identifica il centro prelievi.	2210
4	227	HD	C	Affinity Domain	Facility	Da inviare solo per i messaggi MDM^T02 e MDM^T10 In HD.2 concatenare (separati con $) - Tipologia struttura. Valore scelto tra i valori della Tab. 2.8-1 Affinity Domain Italia (opzionale). - Assetto organizzativo (Codifica della classificazione della pratica clinica o specialistica che ha portato alla creazione del documento). Sono ammessi	&Ospedale$AD_PSC00 1$CON

i codici riportati nella tabella 2.13-1 Affinity Domain Italia (obbligatorio).

- Tipo di attività clinica. Codice della tipologia di attività clinica/organizzativa che ha portato alla condivisione del documento. Sono ammessi i codici riportati nella tabella 3.1-1 dell’Affinity Domain Italia

(obbligatorio).

(2) Struttura campo CX PV1-19

VA R	SEQ	LEN	DT	OPT	TBL	COMPONENT NAME	NOTE	ESEMPIO
	1	15	ST	R		ID Number	Identificativo dell’episodio, può contenere: 1 numero di passaggio di pronto soccorso; 2 numero di accesso in cartella clinica nel formato anno (yyyy) + numero; 3 numero di SDO; 4 identificativo richiesta anatomia patologica; 5 numero di accesso per la radiologia; 6 numero di accesso per il laboratorio analisi	200800000014 3
	5	5	ID	O	Table 0363 – Assigning Autority	Identifier Type Code	Tipo di richiesta. E’ il codice dell’applicativo che ha generato l’identificativo. Usato per individuare il tipo di richiesta.	LIS

Nota (4) Struttura campo CX PV1-50

SE Q	LE N	DT	OP T	TBL	COMPONENT NAME	NOTE	ESEMPIO
1	15	ST	R		ID Number	Può contenere: 1 numero di passaggio di pronto soccorso 2 numero di SDO	2008000000143
5	5	ID	O	Table 0363 – Assigning Autority	Identifier Type Code	Tipo di richiesta. È il codice della tipologia di applicativo originante la richiesta che ha generato	PS

DMA-CL-SRS-12-V33- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx Gennaio 2024 uso: Esterno Pagina 37 di 62

l’identificativo, in particolare deve essere impostato con:

1. SDO se ID Number è un numero di SDO

2. PS se ID Number è un numero di passaggio di pronto soccorso

Note:

la valorizzazione della sezione CX PV1-50 permette di far confluire nello stesso episodio di ricovero o di passaggio di PS i referti relativi a prestazioni ambulatoriali che vengono trasmessi con: un valore di identificativo dell’episodio (PV1-19) proprio e quindi diverso da quello dell’episodio di ricovero o di passaggio di PS, e un valore di tipo_episodio ‘uguale a O’.

Nel caso in cui i referti vengano inviati con lo stesso valore di identificativo dell’Episodio (PV1-19) del ricovero o del passaggio di PS, la loro riconduzione all’episodio è automatica e quindi non devono essere valorizzati i campi presenti nel CX PV1-50.

Per quanto riguarda l’invio da parte del dipartimentale a FSE, occorre tenere conto che la disponibilità del referto validato non coincide con l’evidenza del pagamento del ticket. Si deve pertanto inviare i referti appena disponibili (firmati/validati, con ticket pagato o meno) e successivamente – quando avviene segnalazione del pagamento – inviare nuovamente il documento comprensivo del metadato che dichiara l'avvenuto pagamento parziale o totale, fino al completamento del pagamento.

2.11.6 Segmento TXA: Transcription Document Header

Il segmento TXA contiene i dati caratterizzanti del documento:

tipologia, formato, stato e identificativo unico del documento, livello di validazione del documento e medici che hanno redatto e autenticato il documento.

La struttura del messaggio MDM^T02 prevede la presenza di un solo segmento TXA (e quindi, la specifica di un solo identificativo di documento), pertanto, nell’ipotesi che debbano essere inviati più documenti/referti, è necessario generare un messaggio MDM^T02 per ogni documento/referto.

VA R	SEQ	LEN	DT	OPT	TBL	COMPONENT NAME	NOTE	ESEMPIO
	1	4	SI	R		Set ID- TXA	Dato non utilizzato, impostato ad “1”.	1
	2	30	IS	R	Table 0270 – Document Type	Document Type	Tipologia del documento. In coerenza con le specifiche di interoperabilità INI il tipo documento deve essere codificato indicando la coppia di valori TipoDocumentoAlto, TipoDocumentoMedio. I valori vanno separati con $	REF$68604-8

							Vedi Nota (4)
	3	2	ID	C	Table 0191 – Type Of Referenced Data	Document Content Presentation	E’ il formato dell’allegato, qualora esso sia presente nel messaggio. Nota 1: i valori della tabella sono stati cambiati Nota 2: Non valorizzare in caso di annullamento (messaggio MDM^T11)	PD
	7	24	DTM	C		Transcription Date/Time	Indica, nel caso di un referto, la data di disponibilità per lo scarico da parte del cittadino che effettui la consultazione La data è nel formato aaaammgg
	9	250	XCN	R	Tab CSI 003 -	Originator	Lista dei medici che	CF^Xxxxx^Xxxxx^^^^^
					Ruoli	Code/Name	redigono il documento	^DRS~^CF^Xxxxxxx^
							Per quanto riguarda	Xxxx^^^^^^DRS
							l’autore del documento
							occorre indicare
							obbligatoriamente il
							Codice fiscale documento
							o il numero di Partita IVA
							(della persona giuridica al
							quale si riferisce l’autore
							del documento) attribuito
							al medico redattore e
							opzionalmente il suo
							ruolo
							Vedi Nota (1)
	12	427	EI	R		Unique	Contiene l’identificativo	2.16.840.1.113883.2.9
						Document	del repository che	.2.10.4.5.1020112345
						Number	custodisce il documento,	678198237^^
							nel caso risieda presso	2.16.840.1.113883.2.9
							l’azienda (dovrà essere	.2.10.4.4.1020100000
							valorizzato per le Aziende	000000000000000123
							che aderiranno al nuovo	40088
							modello in conformità alle
							specifiche previste
							dall’inter-operabilità
							nazionale)
							E’ seguito dal numero
							univoco del documento
							generato/gestito
							dall’entità organizzativa
							responsabile dell’invio
							delle informazioni.

							Al fine di adeguarsi al modello nazionale, il dato deve essere generato esclusivamente secondo la codifica OID di HL7, che prevede l’utilizzo del ramo degli identificativi dei documenti della Regione Piemonte. In tal modo l’identificativo sarà univoco a livello regionale. Il formato sarà: 2.16.840.1.113883.2.9.2.1 0.4.4.X Vedi nota (3)
	13	427	EI	C		Parent	Numero univoco del	^^198256
						Document	documento
						Number	che deve essere sostituito
							Il campo potrà contenere	2.16.840.1.113883.2.9
							sia il vecchio	.2.10.4.5.1020112345
							identificativo, se si deve	678198237^^
							agire su un documento	2.16.840.1.113883.2.9
							trasmesso con le vecchie	.2.10.4.4.1020100000
							modalità, che	000000000000000123
							l’identificativo con il	40088
							nuovo formato (Nota 3)
	14	427	EI	O		Placer Order Number	Inserire - NRE (l’elenco dei numeri di ricetta elettronica delle ricette dematerializzate prescritte che hanno portato alla generazione del documento/refert o). In EI.3:codice NRE - In EI.4 tipo: NRE	^^01010100002^NRE
							Il campo è ripetibile in caso vi siano più NRE
	15	427	EI	R		Filler Order Number	- Hash del documento in EI.1 (anche se la lunghezza supera i 199 caratteri)	ab123……e345^^134 5
							- Dimensione del

							documento (EI.3)
	17	2	ID	R	Table 0271 – Document Completion Status	Document Completion Status	Livello di completamento del documento. Gli unici valori dello stato presi in esame sono quelli che indicano che il documento è stato validato manualmente o legalmente.	LA
	18	2	ID	O	Table 0272 – Document Confidentiality Status	Document Confidentiality Status	Valorizzato a “R”	R
	20	2	ID	O		Document Storage Status	Indica se il documento trasmesso è memorizzato anche negli archivi di conservazione sostitutiva. Valori ammessi S o N. Il valore “S” indica la conservazione sostitutiva del documento.	S
	22	250	PPN	O		Authentication Person, Time stamp	Lista dei medici che hanno validato o firmato il documento e quando. Per il verbale di pronto soccorso e la lettera di dimissione coincide con il medico dimettente. Come per i medici redattori è richiesto di indicare il codice fiscale o il numero di Partita IVA (della persona giuridica al quale si riferisce l’autore del documento) e il ruolo . Vedi nota (2)	RSSMRA80A01H501 U^Rossi^Xxxxx^^^^^^ PLS^^^^^^200712041 032~ BNCLCU80A41H501 U^Bianchi^LucIa^^^^ ^^PLS^^^^^^2007120 41100 12345678901^Aziend a^Sanitaria^^^^^^DR S^^^^^^20071204103 2

Nota (1) Struttura campo XCN TXA-9

SEQ	LEN	DT	OPT	TBL	COMPONENT NAME	Note	ESEMPIO
1	15	ST	R		Id Number	Codice fiscale dell’autore del documento (riportare per intero anche se lungo 16) oppure il numero di Partita IVA della persona giuridica al quale si riferisce l’autore del documento
2	194	FN	R		Family name	Xxxxxxx	Xxxxx
3	30	ST	R		Given name	Nome	Xxxxx

DMA-CL-SRS-12-V33- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx Gennaio 2024 uso: Esterno Pagina 41 di 62

9 227 HD R Tab CSI 003 Assigning Authority Ruolo dell’autore del documento

Esempio nel caso di informazioni relative all’autore del documento CCCNNN99E99XXXY^Xxxxx^Xxxxx^^^^^^&MRP

Nota (2) Struttura campo PPN TXA-22

SEQ	LEN	DT	OPT	TBL	COMPONENT NAME	Note	ESEMPIO
1	15	ST	R		Person Identifier	Codice fiscale del medico validatore del documento oppure partita IVA
2	194	FN	O		Family name	Cognome / descrizione persona giurigica	Xxxxx
3	30	ST	O		Given name	Nome/ descrizione persona giurigica	Xxxxx
9	227	HD	O	Tab CSI 003	Assigning Authority	Ruolo del medico validatore del documento	DRS
15	24	DT M	O		Date/Time Action Performed	Data e ora dell’autenticazione nel formato aaaammgghhmm	20071204103 2

Nota (3) Formato dell’Identificativo Univoco del documento e del repository

Per essere univoco a livello regionale e al fine di adeguarsi al modello di interoperabilità nazionale, l’identificativo deve essere codificato con un OID univoco all’interno Azienda secondo il formato 2.16.840.1.113883.2.9.2.10.4.4.X, dove:

• 2.16.840.1.113883.2.9.2.10.4.4. è il ramo degli OID HL7 Italia per gli identificativi dei documenti della Regione Piemonte (31 caratteri compresi i punti)

• X rappresenta uno specifico documento della Regione Piemonte, composto da 33 caratteri secondo il formato TTAAAN...N dove:

o TT = è il codice tipo struttura, da valorizzare con: “10” per strutture pubbliche,

“11” per strutture private equiparate “12” per le altre strutture private

o AAA = identificativo azienda per le aziende pubbliche oppure il codice assegnato dalla ASL sul progetto ARPE per le aziende private

N...N = numero univoco all’interno dell’azienda, con un massimo di 28 caratteri numerici Es. 2.16.840.1.113883.2.9.2.10.4.4.102010000000000000000000012340088.

Nel caso di invio a fronte di un RECUPERO PREGRESSO (campo PV1.24=S) in questo campo occorre inserire:

1. OID del documento (come su indicato) nel caso il documento che si sta inviando, a seguito del recupero pregresso, è stato generato da subito per il fascicolo con la codifica OID e non con altre codifiche (ovvero quelle utilizzate con la versione del connettore antecedente l'integrazione con INI)

2. OID del documento + $ + codice documento originario nel caso il documento che si sta inviando, a seguito del recupero del pregresso, è stato inizialmente generato per il fascicolo con un'altra codifica (ovvero quelle utilizzate con la versione del connettore antecedente l'integrazione con INI)

Esempio 1:

TXA.12 EI.3 valorizzato con 2.16.840.1.113883.2.9.2.10.4.4.10301000000012345 per un documento che è stato associato da sempre all'OID

Esempio 2:

TXA.12 EI.3 valorizzato con 2.16.840.1.113883.2.9.2.10.4.4.1030100000006789$ABC123XY per un

documento che inizialmente era stato codificato per il fascicolo con il codice ABC123XY

L’identificativo del repository del documento inviato deve avere il seguente formato: 2.16.840.1.113883.2.9.2.10.4.5.X

dove

• 2.16.840.1.113883.2.9.2.10.4.5 indica il ramo degli OID HL7 Italia per gli identificativi dei repository della Regione Piemonte (31 caratteri compresi i punti)

• X indica uno specifico repository dell’Azienda ed è costituito da un codice nel formato TTAAARRRRRRRR, dove:

o TT = codice tipo struttura, da valorizzare con “10” per strutture pubbliche

“11” per strutture private equiparate “12” per le altre strutture private

o AAA= identificativo Azienda per le aziende pubbliche oppure il codice Azienda titolare assegnato dalla ASL di competenza sul progetto ARPE per le Aziende private

o RRRRRRRR = identificativo del repository (al massimo 8 caratteri numerici)

Nota (4) Essendo fisso il valore previsto per il Tipo Documento Basso, in fase di alimentazione del fascicolo, sono consentiti i valori riportati nelle tabelle seguenti:

TipoDocumentoAlto

Codice	Descrizione
REF	Referto
LDO	Lettera di Dimissione Ospedaliera
SUM	Summary
TAC	Taccuino
PRS	Prescrizione
ESE	Esenzione
XXX	Xxxxxxxxx

TipoDocumentoMedio

Codice	Descrizione
11502-2	Referto di Laboratorio
34105-7	Lettera di dimissione ospedaliera
59258-4	Verbale di pronto soccorso
68604-8	Referto radiologico
11526-1	Referto di anatomia patologica
11488-4	Referto specialistico
REG-80755-2	PT delle malattie renali croniche e insufficienza renale
REG-80774-3	PT delle malattie reumatiche croniche
REG-80744-6	PT delle malattie intestinali croniche
REG-77442-2	PT delle malattie cardiovascolari croniche
REG-80761-0	PT delle malattie neurodegenerative
REG-80796-6	PT delle malattie respiratorie croniche
REG-80772-7	PT dell’insufficienza respiratoria in età evolutiva
REG-68782-2	PT dell’asma in età evolutiva

REG-68894-5	PT delle malattie endocrine in età evolutiva
REG-68867-1	PT delle malattie renali croniche in età evolutiva
REG-18776-5	PT (altro)
REG-87273-9	Scheda Vaccinale
REG-82593-5	Certificato Vaccinale
60591-5	Patient Summary
REG-81334-5	Piano di cura personalizzato
68814-3	BILANCIO DI SALUTE
97499-8	CERTIFICATO DI GUARIGIONE DA Covid-19
55750-4	RESOCONTO SICUREZZA DEL PAZIENTE
103140-0	DOCUMENTO INSERITO DAL CITTADINO
102033-8	DOCUMENTO PROVENIENTE DA RETI DI PATOLCIA
103144-2	MEDICAL EQUIPMENT DISPENSED
103146-7	SPECIALIST CARE DISPENSED BRIEF
103147-5	SPECIALIST CARE DISPENSED EXTENDED
101136-0	LETTERA DI FINE TRATTAMENTO
101134-5	PROMEMORIA DI APPUNTAMENTO
101133-7	CONSENSO ALLA DONAZIONE
100971-1	CARTELLA CLINICA

I valori di tipo documento Medio e tipo documento Alto devono essere valorizzati in modi coerente.

La tabella che segue indica la relazione tra i valori da riportare nei tag tipologiaDocumentoAlto e tipologiaDocumentoMedio:

Codice tipoDocumentoAlto	Descrizione tipo documento alto	Codice tipoDocumentoMedio	Descrizione tipo documento medio
REF	Referto	11502-2	Referto di Laboratorio
LDO	Lettera di dimissione ospedaliera	34105-7	Lettera di dimissione ospedaliera
REF	Referto	59258-4	Verbale di pronto soccorso
REF	Referto	68604-8	Referto di radiologia
REF	Referto	11526-1	Referto di anatomia patologica
REF	Referto	11488-4	Referto specialistico
XXX	Xxxxxxxxx	REG-80755-2	PT delle malattie renali croniche e insufficienza renale
XXX	Xxxxxxxxx	REG-80774-3	PT delle malattie reumatiche croniche
XXX	Xxxxxxxxx	REG-80744-6	PT delle malattie intestinali croniche
XXX	Xxxxxxxxx	REG-77442-2	PT delle malattie

			cardiovascolari croniche
XXX	Xxxxxxxxx	REG-80761-0	PT delle malattie neurodegenerative
XXX	Xxxxxxxxx	REG-80796-6	PT delle malattie respiratorie croniche
XXX	Xxxxxxxxx	REG-80772-7	PT dell’insufficienza respiratoria in età evolutiva
XXX	Xxxxxxxxx	REG-68782-2	PT dell’asma in età evolutiva
XXX	Xxxxxxxxx	REG-68894-5	PT delle malattie endocrine in età evolutiva
XXX	Xxxxxxxxx	REG-68867-1	PT delle malattie renali croniche in età evolutiva
XXX	Xxxxxxxxx	REG-18776-5	PT (altro)
REF	Referto	REG-87273-9	Scheda Vaccinale
SUM	Summary	REG-82593-5	Certificato Vaccinale
SUM	Summary	60591-5	Patient Summary
SUM	Summary	REG-59283-2	Bilancio di salute
SUM	Summary	REG-81334-5	Piano di cura personalizzato

Esempio: REF^68604-8

2.11.7 Segmento OBX: Observation Segment

Il segmento OBX contiene i dati strutturati ed eventuale documento (base64).

VA R	SEQ	LEN	DT	OPT	TBL	COMPONENT NAME	NOTE	ESEMPIO
	1	4	SI	R		Set ID- OBX	Numero da sequenza dell’obx: se nel messaggio ci sono più OBX, ognuno avrà un id crescente.	1
	2	3	ID	R	Table – 0125 Value Type	Value Type	Specifica il tipo di OBX.	ED
C	3	705	CWE (ex CE)	R	Table 0270 – Documnt type	Observation Identifier	E’ l’identificativo univoco dell’observation (OBX): 1 per le prestazioni è costituito dal codice prestazione secondo la codifica prevista dal Catalogo Regionale e dal codice branca regionale su cui è stata erogata la prestazione. Vedi nota (1). 2 Per le codifiche previste da INI nell’eventCodeList dell’Affinity Domain Italia per ulteriore specificazione associata al documento. Vedi nota (1). 3 per il tipo ED (quindi

							l’observation contiene un referto) contiene la tipologia di documento medio che deve corrispondere al tipo documento medio riportato nel segmento TXA 4 Per il tipo RP (senza invio di documento) indicare il tipo documento medio riportato nel segmento TXA Nota (1)
	4	20	ST	C		Observation Sub-ID	Deprecato
	5	*	*	C/R		Observation Value	Valore dell’informazione contenuta nell’OBX o valore dell’esame. Nel caso di un allegato, sarà il contenuto dell’allegato (CIFRATO) in formato base64 utilizzando il tipo ED. Nel secondo sottocampo viene riportata una eventuale nota sul risultato. Per il tipo OBX.2 è RP rappresenta (OBX-5.1) l’accession number utilizzato per reperire le immagini nel caso vi sia l’integrazione con i PACS dell’Azienda, il tipo di dato (OBX-5.3) ed il subtipo (OBX-5.4) Nota (2)	15^Nota risultato
	11	1	ID	R/NA	Table 0085 - Observation result status codes interpretation	Observation Result Status	Il campo è valorizzato con “F” quando viene inviato un nuovo documento oppure un dato strutturato validato. Assume valore “C” quando viene inviata una modifica di un dato strutturato oppure un documento che deve sostituire un documento già inviato. Il campo è valorizzato con “B” quando viene inviato un addendum (MDM_T06).	F
	13	20	ST	C		User Defined Access Checks	Quantità, utilizzato per

							indicare il numero di volte che è stata erogata una prestazione, se è stata eseguita una sola volta conterrà il valore 1. Nel caso l’OBX non si riferisca ad una prestazione il campo non sarà valorizzato.
	14	24	DTM	O		Date/Time of	Data e ora di erogazione, nel	20071206150
						Observation	caso della prestazione.	5
							Vuota negli altri casi.
							Il formato è aaaammgghhmm.

(1) Struttura campo CWE OBX-3

Se il campo si riferisce ad una prestazione se OBX.2=CE o CWE e CWE.3=CATREG :

VA R	SE Q	LEN	DT	OPT	TBL	COMPONENT NAME	Note	ESEMPIO
	1	20	ST	R		Identifier	Codice della prestazione secondo la codifica del catalogo regionale	89.7
	3	20	ID	R	Table 0396 - Coding system	Name of Coding System	Sistema di codifica Il valore da usare è CATREG	CATREG
	4	20	ST	R		Alternate Identifier	Codice della branca regionale su cui è erogata la prestazione	08

Se il campo si riferisce ad un eventCode se OBX.2=CE o CWE e CWE.3=EVENTCODE:

VA R	SE Q	LEN	DT	OPT	TBL	COMPONENT NAME	Note	ESEMPIO
N	1	20	ST	R	Tabella INI Tabella 2.7-1	Identifier	Codice dell’eventCodeList secondo la codifica INI - Tabella 2.7-1 dell’Affinity Domain Italia.	LP418019-8
N	3	20	ID	R	Table 0396 - Coding system	Name of Coding System	Sistema di codifica Il valore da usare è EVENTCODE	EVENTCO DE

Se il campo si riferisce ad un documento (OBX.2=ED)

VA R	SE Q	LEN	DT	OPT	TBL	COMPONENT NAME	Note	ESEMPIO
	1	20	ST	R		Identifier	tipologia di documento medio	11502-2

Se il campo si riferisce all’invio dei metadati di un documento senza invio del documento, delle prestazioni e dell’accession number , poiché deve essere inviato almeno un OBX valorizzare:

VA R	SE Q	LEN	DT	OPT	TBL	COMPONENT NAME	Note	ESEMPIO
	1	20	ST	R		Identifier	tipologia di documento medio	11502-2

DMA-CL-SRS-12-V33- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx Gennaio 2024 uso: Esterno Pagina 47 di 62

Se il campo si riferisce ad un accession number (OBX.2=RP)

VA R	SE Q	LEN	DT	OPT	TBL	COMPONENT NAME	Note	ESEMPIO
	1	20	ST	R		Identifier	tipologia di documento medio	11502-2

(2) Struttura campo ED OBX-5 (invio documento)

SEQ	LEN	DT	OPT	TBL	COMPONENT NAME	NOTE	ESEMPIO
2	9	ID	R	Table 0191 - Type Of Referenced Data	Type of data		multipart
3	18	ID	O	Table 0291 - Data Subtype	Data Subtype		Octet-stream
4	6	ID	R	Table 0299 - Encoding	Encoding		Base64
5	65536	TX	O		Data	Vuoto nel caso di invio senza documento allegato. (CIFRATO se inviato)

Struttura campo RP OBX-5 (invio di immagini )

SEQ	LEN	DT	OPT	TBL	COMPONENT NAME	NOTE	ESEMPIO
1	999	ST	R		Pointer	Contiene info relative all’immagini DICOM: • accession number • aetitle • patientID • issuer	1555487
3	11	ID	R	Table 0191 - Type Of Referenced Data	Type of Data	fisso	IM
4	32	ID	R	Table 0291 - Data Subtype	Subtype	fisso	DICOM

NOTA:

Il campo OBX-5\RP-1contiene le informazioni per individuare le immagini associate al documento di radiologia. In particolare, il campo contiene le seguenti informazioni:

• accession number: permette di individuare uno studio di immagini all’interno di un PACS

• aetitle: permette di individuare il PACS che detiene le immagini associate all’accession number

• patientID: contiene l’identificativo del paziente dell’anagrafica del PACS

• issuer: permette di individuare l’organizzazione dell’azienda che ha emesso l’ID del paziente Se il campo è valorizzato, deve essere obbligatoriamente esplicitato almeno l’accession number Formato: le informazioni devono essere strutturare come segue:

OBX|2|RP||1|<AccessionNumber>$< aetitle>$<patientID>$<issuer>^^IM^DICOM||||||F

Es:

• caso in cui si invia solo accession number e aetitle:

OBX|2|RP||1|access1$PACSTO$$^^IM^DICOM||||||F

• caso in cui si inviano tutte le informazioni previste:

OBX|2|RP||1|access1$PACSTO$PID1001$123^^IM^DICOM||||||F

• caso in cui si inviano tutte le informazioni previste al netto dell’issuer:

OBX|2|RP||1|access1$PACSTO$PID1001$^^IM^DICOM||||||F

• caso in cui si invia SOLO accession number: OBX|2|RP||1|access1$$$^^IM^DICOM||||||F

• caso in cui si invia SOLO accession number: OBX|2|RP||1|access1^^IM^DICOM||||||F

Qualora occorra inviare più di un accession number ripetere il segmento OBX per ogni accession number. Esempio:

OBX|2|RP||1|ACCNUM0001$$$^^IM^DICOM||||||F OBX|3|RP||1|ACCNUM0002$$$^^IM^DICOM||||||F

Struttura campo RP OBX-5 nel caso di invio del messaggio senza referto (documento/referto nel repository aziendale)

SEQ	LEN	DT	OPT	TBL	COMPONENT NAME	NOTE	ESEMPIO
3	11	ID	R	Table 0191 - Type Of Referenced Data	Type of Data		RIF

Esempi di utilizzo del segmento OBX per invio di doc base 64 OBX|1|ED|11502-2||^multipart^Octet-stream^Base64^JVBER…j6IKOCA

N.B. Anche se l’allegato supera 65536 byte in formato base64 deve comunque essere scritto completamente in questo campo senza suddividerlo. Il documento va cifrato secondo le specifiche indicate nel paragrafo 2.4.4

Altri esempi di utilizzo del segmento OBX. (anche in caso di invio senza referto)

Esempio 1. Sono state erogate due prestazioni (visita e prick) e ad esse, è associato un solo referto:

OBX|1|ED|11502-2||^multipart^Octet-stream^Base64^JVBER…j6IKOCA OBX|2|CE|90.62.2^^CATREG^98||||||||F||1|201903060930 OBX|3|CE|90.82.5^^CATREG^98||||||||F||1|201903060930

Esempio 2. È stata erogata una prestazione e ad essa è associato un riferimento ad un’immagine DICOM ed un referto codificato in base64 il cui testo supera 65536 byte:

OBX|1|ED|68604-8|1|< referto con dimensione superiore a 65536> OBX|2|RP||1|ACCNUM0001^^IM^DICOM||||||F

OBX|3|CE| 89.71^^CATREG^08||||||||F||1|201903060930

Esempio 3. È stata erogata una prestazione e ad essa è associato un documento conservato nel dipartimentale

(per invio senza referto) OBX|1|RP| |1|^^RIF^||||||F

OBX|2|CE|89.71^^CATREG^08|1|||||||F||1|200703060930

I valori dei risultati degli esami di laboratorio di analisi non devono essere più comunicati.

2.11.8 Segmento MSA: Message Acknowledgment Segment

SEQ	LEN	DT	OPT	TBL	COMPONENT NAME	NOTE	ESEMPIO
1	2	ID	R	Table 0008 Acknowledgement code	Acknowledgment Code	Messaggio elaborato correttamente o errore	AA
2	20	ST	R		Message Control ID	Identificativo unico del messaggio, generato dall’inviante, cui l’ACK è riferito.	34

2.11.9 Segmento ERR: Error segment

SEQ	LEN	DT	OPT	TBL	COMPONENT NAME	NOTE	ESEMPIO
3	705	CWE	R	Table 0357	HL7 Error Code	Codice di errore XX0	000
0	0	XX	R	Table 0516	Severity
5	705	CWE	O	Table 0533	Application Error Code	Codice e descrizione di errore generato dell’applicativo che risponde	FSE_ER_121^ Non esiste il codice della branca regionale del documento

(1) Struttura campo CWE ERR-5

SEQ	LEN	DT	OPT	TBL	COMPONENT NAME	NOTE	ESEMPIO
1	20	ST	O		Identifier	Codice identificativo dell’errore	FSE_ER_121
2	199	ST	O		Text	Testo dell’errore	Non esiste il codice della branca regionale del documento

2.12 Tabelle di codifica

Il presente capitolo descrive tutte le tabelle di codifica utilizzate nel progetto.

2.12.1 Table 0001 - Administrative Sex

Sesso del paziente.

Codice	Descrizione	Descrizione d’uso
F	Female	Femmina
M	Male	Maschio
U	Unknown	Sconosciuto

2.12.2 Table 0004 – Patient Class

Provenienza del paziente.

Codice	Descrizione	Descrizione d’uso
E	Emergency	Dati relativi ad un episodio Pronto Soccorso (PS/DEA)
I	Inpatient	Dati relativi a un episodio di ricovero (RO, DH, DS)
O	Outpatient	Dati relativi ad un episodio ambulatoriale (AMB) o collegato ad un episodio di ricovero o di pronto soccorso

2.12.3 Table 0008 Acknowledgement code

Ditta inviante o ricevente.

Codice	Descrizione	Descrizione d’uso
AA	Application Accept	Il messaggio è stato correttamente processato
AE	Application Error	Si è verificato un errore sintattico
CE	Commit Error	Si è verificato un errore sul DBMS

2.12.4 Table 0076 - Message Type - e Table 0003 Event Type

Tipo di messaggio.

Codice	Descrizione	Descrizione d’uso
ADT^A01^ADT_A01	ADT^A01^ADT_A01	Utilizzato nel messaggio “Notifica dell’accettazione dell’episodio”
ACK^A01^ACK	ACK^A01^ACK	Acknowlwdge a ADT^A01
ADT^A03^ADT_A03	ADT^A03^ADT_A03	Utilizzato nel messaggio “Notifica della dimissione di un paziente ricoverato”
ACK^A03^ACK	ACK^A03^ACK	Acknowlwdge a ADT^A03
ADT^A11^ADT_A09	ADT^A11^ADT_A09	Utilizzato nel messaggio “Notifica dell’annullamento dell’episodio”
ACK^A11^ACK	ACK^A11^ACK	Acknowlwdge a ADT^A11
MDM^T02	MDM^T02	Utilizzato nel messaggio “Notifica della creazione del documento”
ACK^T02^ACK	ACK^T02^ACK	Acknowlwdge a MDM^T02
MDM^T10	MDM^T10	Utilizzato nel messaggio “Notifica della sostituzione del documento”
ACK^T10^ACK	ACK^T10^ACK	Acknowlwdge a MDM^T10
MDM^T11	MDM^T11	Utilizzato nel messaggio “Notifica dell’annullamento del

documento”

2.12.5 Table 0085 - Observation result status codes interpretation

Codifica dello stato del segmento OBX (dato strutturato oppure documento).

Codice	Descrizione	Descrizione d’uso
	Identificativi HL7
F	Final results; Can only be changed with a corrected result.	Stato del dato/informazione e del documento inviato per la prima volta.
C	Record coming over is a correction and thus replaces a final result	Stato che indica che il valore che viene inviato è stato modificato.
D	Deletes the OBX record	Stato che indica la cancellazione del dato.
B	Appended Report - Final results reviewed and further information provided for clarity without change to the original result values.	Stato che indica l’invio di informazioni aggiuntive (addendum) senza modifica dei dati precedentemente comunicati

2.12.6 Table 0000 - Xxxxxxxxxx XX

Definisce in quale ambiente è stato costruito il messaggio. Il valore utilizzato è fisso.

Codice	Descrizione	Descrizione d’uso
	Identificativi HL7
P	Production	Produzione

2.12.7 Table 0123 - Result Status

Codifica dello stato del segmento OBR (episodio).

Codice	Descrizione	Descrizione d’uso
	Identificativi HL7
F	Final results; results stored and verified. Can only be changed with a corrected result.	Stato dell’episodio che viene inviato per la prima volta.
X	No results available; Order canceled.

2.12.8 Table 0125 – Value Type

Tipologia del dato caratterizzato all’interno di un OBX.

Codice	Descrizione	Descrizione d’uso
	Identificativi HL7
CE	Coded Entry (mantenuto per retrocompatibilità)	Utilizzato per registrare dati codificati: prestazioni
CWE	Coded Entry	Utilizzato per registrare dati codificati: prestazioni
ED	Encapsulated Data	Utilizzato per allegare documenti nei formati previsti.
RP	Reference Pointer	Utilizzato per inviare l’informazione dell’accession number. Qualora il sistema non invii il documento e nessuna altra informazione, poiché il segmento OBX è obbligatorio nei messaggi MDM utilizzare la codifica RP indicando la tipologia del documento (vd. campo OBX.3 )

2.12.9 Table 0190 - Address type

Tipo di indirizzo.

Codice Descrizione Descrizione d’uso

DMA-CL-SRS-12-V33- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx Gennaio 2024 uso: Esterno Pagina 52 di 62

	Identificativi HL7
B	Birth	Luogo di nascita

2.12.10 Table 0191 – Type Of Referenced Data

Specifica il formato e il tipo di firma (se presente) dell’allegato; l’informazione è presente nel segmento TXA; il testo del referto/documento è presente nel segmento OBX.

Codice	Descrizione	Ambito di validità	Descrizione d’uso
	Identificativi HL7
multipart	MIME multipart package	OBX	usato per i documenti
	Identificativi (estensione CSI)
IM	Image Data	OBX	Usato per l’invio dell’accession number al fine di reperire le immagini radiologiche
PD	Pdf	TXA	In caso di documento non firmato
PC	Pdf con CDA iniettato	TXA	In caso di documento non firmato
PD$C	Pdf, firmato CADES	TXA	In caso di documento firmato
PC$C	Pdf con CDA iniettato, firmato CADES	TXA	In caso di documento firmato
PD$PB	Pdf, firmato PADES BES	TXA	In caso di documento firmato
PC$PB	Pdf con CDA iniettato, firmato PADES BES	TXA	In caso di documento firmato

Il tipo di firma concorre a determinare se il documento è inter-operabile ovvero può essere reso disponibile sull’infrastruttura nazionale. E’ quindi necessario indicare il codice corretto in relazione al tipo di firma applicato.

2.12.11 Table 0203 - Identifier type

Tabella con la codifica delle autorità che assegnano gli identificativi. Il codice può essere lungo al massimo 5 caratteri.

Codice	Descrizione	Descrizione d’uso
	Identificativi anagrafici(HL7)
NNITA	National Person Identifier where the xxx is the ISO table 3166 3- character (alphabetic) country code	Codice fiscale
PNT	Temporary Living Subject Number	Codice STP
	Identificativi anagrafici(estensione CSI)
PZCE	Codice anagrafico anagrafe centrale AULA dell'Azienda Sanitaria
PZLO	Codice anagrafico anagrafe locale del dipartimentale
AURA	Codice anagrafico dell’Anagrafe Unica della Regione Piemonte degli Assistiti
	Identificativi di accesso (estensione CSI)
PS	Passaggio di pronto soccorso
SDO	Numero della SDO
CC	Numero di passaggio in cartella clinica
AP	Identificativo richiesta dell’anatomia patologica
RADIO	Numero di accesso in radiologia
LIS	Identificativo richiesta di laboratorio analisi

2.12.12 Table 0270 – Document Type

Tipologia del documento; l’informazione è contenuta nel segmento TXA.

Per il tipo documento sarà necessario indicare la coppia di valori tipo documento alto/tipo documento medio in

DMA-CL-SRS-12-V33- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx Gennaio 2024 uso: Esterno Pagina 53 di 62

modo coerente. Le codifiche riportate seguono le specifiche previste dal progetto di interoperabilità nazionale riportate nel documento di Affinity Domain Italia.

TipoDocumentoAlto (Tabella 2.3-1 dell’Affinity Domain Italia)

Codice	Descrizione
REF	Referto
LDO	Lettera di Dimissione Ospedaliera

Tipo Documento Medio (Tabella 2-19-1 dell’Affinity Domain Italia)

Codice	Descrizione	Corripondenza con vecchio valore (deprecato)
11502-2	Referto di Laboratorio	REFERTO_LIS: Referto di laboratorio di analisi
34105-7	Lettera di dimissione ospedaliera	LET_DIMISSIONE: Lettera di dimissione
59258-4	Verbale di pronto soccorso	DEA_VERBALE: Xxxxxxx di pronto soccorso
68604-8	Referto radiologico	REFERTO_RIS: Referto di radiologia
11526-1	Referto di anatomia patologica	REFERTO_AP: Referto di anatomia patologica
11488-4	Referto specialistico	REFERTO: Referto
ATTO_OPERATORIO	Atto operatorio (Codice Regionale)	ATTO_OPERATORIO
-	-	DEA_TRIAGE (DEPRECATO)
-	-	ANAMNESI (DEPRECATO
-	-	SDO (DEPRECATO)
-	-	REFERTO_CICLO (DEPRECATO)

La tabella che segue indica la relazione tra i valori di Tipo Documento Alto e Tipo Documento Medio:

Codice tipologiaDocumentoAlto	Descrizione tipo documento alto	Codice tipologiaDocumentoMedio	Descrizione tipo documento medio
REF	Referto	11502-2	Referto di Laboratorio
LDO	Lettera di dimissione ospedaliera	34105-7	Lettera di dimissione ospedaliera
REF	Referto	59258-4	Verbale di pronto soccorso
REF	Referto	68604-8	Referto di radiologia
REF	Referto	11526-1	Referto di anatomia patologica
REF	Referto	11488-4	Referto specialistico

2.12.13 Table 0271 - Document Completion Status

Stato di completezza del documento; l’informazione è contenuta nel segmento TXA.

Codice	Descrizione	Descrizione d’uso
	Identificativi HL7
AU	Authenticated	Autenticato
LA	Legally authenticated	Firmato

2.12.14 Table 0272 - Document Confidentiality Status

Livello di riservatezza del documento.

Codice Descrizione Descrizione d’uso

DMA-CL-SRS-12-V33- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx Gennaio 2024 uso: Esterno Pagina 54 di 62

	Identificativi HL7
R	Restricted	Accesso ristretto

2.12.15 Table 0291 – Data Subtype

Sottotipo del dato; usato per i documenti.

Codice	Descrizione	Descrizione d’uso
	Identificativi HL7
Octet- stream	Uninterpreted binary data	usato per i pdf
DICOM	Digital Imaging and Communications in Medicine	usato per le immagini DICOM

2.12.16 Table 0299 – Encoding

Codifica; usato per i documenti.

Codice	Descrizione	Descrizione d’uso
	Identificativi XX0
Xxxx00	Encoding as defined by MIME standard RFC 1521	usato per i pdf

2.12.17 Table 0357 – Message error condition codes

Codice	Descrizione	Descrizione d’uso
0	Message accepted	Success. Optional, as the AA conveys success. Used for systems that must always return a status code.
100	Segment sequence error	Error: The message segments were not in the proper order, or required segments are missing.
101	Required field missing	Error: A required field is missing from a segment
102	Data type error	Error: The field contained data of the wrong data type, e.g. an NM field contained "FOO".
103	Table value not found	Error: A field of data type ID or IS was compared against the corresponding table, and no match was found.
200	Unsupported message type	Rejection: The Message Type is not supported.
201	Unsupported event code	Rejection: The Event Code is not supported.
202	Unsupported processing id	Rejection: The Processing ID is not supported.
203	Unsupported version id	Rejection: The Version ID is not supported.
204	Unknown key identifier	Rejection: The ID of the patient, order, etc., was not found. Used for transactions other than additions, e.g. transfer of a non-existent patient.
205	Duplicate key identifier	Rejection: The ID of the patient, order, etc., already exists. Used in response to addition transactions (Admit, New Order, etc.).
206	Application record locked	Rejection: The transaction could not be performed at the application storage level, e.g., database locked.
207	Application internal error	Rejection: A catchall for internal errors not explicitly covered by other codes.

In caso di errore non dovuto al formato HL7 verrà inviato 207.

2.12.18 Table 0361 –Application

Dipartimentale inviante o ricevente.

Codice	Descrizione	Descrizione d’uso
	Identificativi CSI
DOSSIER oppure FSATO2 (per retrocompatibilità con TO2)	Componente Locale del FSE
HIS_DEA	Pronto soccorso ex ASL4
HIS_AMB	Cartella clinica allergologia e pneumologia ex ASL 4
PATO2000	Anatomia patologica ex ASL4
INFOCLIN1	Cartella clinica di cardiologia	Prima installazione
INFOCLIN2	Cartella clinica di cardiologia	Seconda installazione
IE-DEA	Pronto soccorso ex ASL 3
INFOCLIN	Cartella clinica di cardiologia
ADTWEB	ADT ESEL
OPENLIS	LIS ESEL
XXXXX	SIT ESEL
XMPI	Anagrafe centrale ESEL
WINSAP	Anatomia patologica ESEL
DNLAB	LIS NOEMALIFE
IMAGOWEB	Radiologia Elco
GALENUS	Cartella Clinica Nefrologia e Dialisi Infogramma
ORMAWIN	Blocco Operatorio Avelco
DNLAB.NOEMALIFE .201.01	NOEMALIFE ASL TO1
DNLAB.NOEMALIFE .205.01	NOEMALIFE ASL TO5
TO4TRAK	TRAKCARE ASL TO4

Per l’FSE la regola per comporre il codice dell’applciazione inviante è la seguente:

<nome applicativo>.<fornitore>.<ASL/ASO>.<NN> dove:

<nome applicativo> nome applicativo inviante

<fornitore> fornitore dell'applicativo

<ASL/ASO> codice dell'Azienda

<NN> è un progressivo per distinguere le installazioni dell'applicativo se presso l'Azienda ce ne fossero più di una

Nelle stringhe dei nomi solo lettere e numeri. Esempio: DOSSIER.GPI.906.01

2.12.19 Table 0362 –Facility

L’entità organizzativa responsabile dell’invio o della ricezione delle informazioni. CODICE ASR INVIANTE. Per i privati rappresenta la ASR indicata sul sistema AURA

Codice	Descrizione	Descrizione d’uso
	Identificativi CSI
203	X.X.X. XXXXXX 0
000	X.X.X. XXXXXX 4
205	X.X.X. XXXXXX 0
000	X.X.X. XXXXXXXX
207	X.X.X. XXXXXX
000	X.X.X. XXXXXX
209	A.S.L. VERBANO-CUSIO-OSSOLA
210	A.S.L. CUNEO 1
211	A.S.L. CUNEO 2
212	A.S.L. ASTI
213	X.X.X. XXXXXXXXXXX
000	X.X.X. XXXXX' XX XXXXXX
904	AZIENDA OSP. S.XXXXX
905	AZIENDA OSP. MAGGIORE DELLA CARITA'
906	AZIENDA OSP. X.XXXXX E CARLE
907	AZIENDA OSP. S.XXXXXXX XXXXXX/XXXXXX
908	AZIENDA OSP. ORDINE MAURIZIANO DI TORINO
909	AZIENDA OSP. CITTA DELLA SALUTE E DELLA SCIENZA DI TORINO

2.12.20 Table 0363 – Assigning authority

Applicativo che genera il codice, usato per individuare il tipo del codice di richiesta.

Codice	Descrizione	Descrizione d’uso
	Identificativi CSI
PS	Pronto soccorso
SDO	Gestione ricovero
CC	Cartella clinica
AP	Anatomia patologica
LIS	Laboratorio analisi
RIS	Radiologia

2.12.21 Table 0396 – Coding system table

Sistemi di codifica utilizzati per caratterizzare le informazioni (prestazioni, etc).

Codice	Descrizione	Descrizione d’uso
99zzz	Local general code (where z is an alphanumeric character)	99CDO: codifica CSI per i tipi di documenti 99RPR: codifica catalogo regionale della prestazione
LN	LOINC
I9C	ICD-9CM - Commission on Professional and Hospital Activities, 0000 Xxxxx Xxxx, Xxx Xxxxx, XX 00000 (includes all

DMA-CL-SRS-12-V33- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx Gennaio 2024 uso: Esterno Pagina 57 di 62

procedures and diagnostic tests).

2.12.22 Table 0516 – Error severity

Livello di gravità dell’errore.

Codice	Descrizione	Descrizione d’uso
W	Warning	Transaction successful, but there may be issues
I	Information	Transaction was successful but includes information e.g., inform patient
E	Error	Transaction was unsuccessful

In caso di comunicazione di errore verrà inviato E.

2.12.1 Table CSI 001 – modalità di dimissione

Codice	Descrizione
0	ricoverato nella stessa struttura
1	deceduto
2	dimissione a domicilio
5	rifiuta il ricovero
6	trasferito ad altra struttura di ricovero
7	trasferito in altra struttura (RSA - RAF - Ospedale di comunità, ecc.)
8	trasferito in altro Pronto Soccorso della stessa Azienda
A	solo accesso, senza erogazione di prestazioni
M	solo accesso, senza erogazione di prestazioni, seguito da parte del MMG presente in pronto soccorso

2.12.2 Table CSI 003 – Ruolo Utente (Tabella 4.1-1 dell’Affinity Domain)

L’informazione è riportata nel segmento EVN e TXA

Codice	Descrizione	Mappatura con ruoli del DPCM sul FSE
AAS	Personale di assistenza ad alta specializzazione	Medico / Dirigente sanitario
APR	Medico Medicina Generale Pediatra di Libera Scelta	Medico di Medicina Generale / Pediatra di Libera Scelta
PSS	Professionista del sociale	Professionista del sociale
INF	Personale infermieristico	Infermiere o altro Professionista Sanitario
OAM	Operatore amministrativo	Operatore Amministrativo
DRS	Dirigente sanitario	Medico / Dirigente sanitario
RSA	Medico RSA	Medico RSA
MRP	Medico Rete di Patologia	Medico Rete di Patologia

2.12.3 Table 0119 - Order control codes

Definisce in quale ambiente è stato costruito il messaggio. Il valore utilizzato è fisso.

Codice	Descrizione	Descrizione d’uso
	Identificativi HL7
NW	New order/service	Nuova richiesta di xxxxx accettata dal LIS

2.12.4 Table 2.8-1 Affinity Domain – Facility TypeCode

Code	DisplayName	Descrizione
Ospedale	Ospedale	Indica che il documento è stato prodotto a seguito di un ingresso ospedaliero del paziente
Prevenzione	Prevenzione	Indica che il documento è stato prodotto a seguito di uno screening o di medicina preventiva
Territorio	Territorio	Indica che il documento è stato prodotto a seguito di un incontro con uno specialista territoriale (MMG / PLS / Medico RSA, ecc.)

2.12.5 Table 2.13-1 Affinity Domain –Assetto organizzativo / Pratica Clinica o specialistica

Codice	Descrizione
AD_PSC001	Allergologia
AD_PSC002	Day Hospital
AD_PSC003	Anatomia e Istologia Patologica
AD_PSC005	Angiologia
AD_PSC006	Cardiochirurgia Pediatrica
AD_PSC007	Cardiochirurgia
AD_PSC008	Cardiologia
AD_PSC009	Chirurgia Generale
AD_PSC010	Chirurgia Maxillo-facciale
AD_PSC011	Chirurgia Pediatrica
AD_PSC012	Chirurgia Plastica
AD_PSC013	Chirurgia Xxxxxxxx
AD_PSC014	Chirurgia Vascolare
AD_PSC015	Medicina Sportiva
AD_PSC018	Ematologia e Immunoematologia
AD_PSC019	Malattie Endocrine, del Ricambio e della Nutrizione
AD_PSC020	Immunologia
AD_PSC021	Geriatria
AD_PSC024	Malattie Infettive e Tropicali
AD_PSC025	Medicina del Lavoro
AD_PSC026	Medicina Generale
AD_PSC027	Medicina Legale
AD_PSC028	Unita Spinale
AD_PSC029	Nefrologia
AD_PSC030	Neurochirurgia
AD_PSC031	Nido
AD_PSC032	Neurologia
AD_PSC033	Neuropsichiatria Infantile
AD_PSC034	Oculistica
AD_PSC035	Odontoiatria e Stomatologia
AD_PSC036	Ortopedia e Traumatologia
AD_PSC037	Ostetricia e Ginecologia

Codice	Descrizione
AD_PSC038	Otorinolaringoiatria
AD_PSC039	Pediatria
AD_PSC040	Psichiatria
AD_PSC042	Tossicologia
AD_PSC043	Urologia
AD_PSC046	Grandi Ustioni Pediatriche
AD_PSC047	Grandi Ustionati
AD_PSC048	Nefrologia (Abilitazione Trapianto Xxxx)
AD_PSC049	Terapia Intensiva
AD_PSC050	Unita Coronarica
AD_PSC051	Astanteria
AD_PSC052	Dermatologia
AD_PSC054	Emodialisi
AD_PSC055	Farmacologia Clinica
AD_PSC056	Recupero e Riabilitazione Funzionale
AD_PSC057	Fisiopatologia della Riabilitazione Umana
AD_PSC058	Gastroenterologia
AD_PSC060	Lungodegenti
AD_PSC061	Medicina Nucleare
AD_PSC062	Neonatologia
AD_PSC064	Oncologia
AD_PSC065	Oncoematologia Pediatrica
AD_PSC066	Oncoematologia
AD_PSC068	Pneumologia, Fisiopatologia Respiratoria, Tisiologia
AD_PSC069	Radiologia
AD_PSC070	Radioterapia
AD_PSC071	Reumatologia
AD_PSC073	Terapia Intensiva Neonatale
AD_PSC074	Radioterapia Oncologica
AD_PSC075	Neuro-Riabilitazione
AD_PSC076	Neurochirurgia Pediatrica
AD_PSC077	Nefrologia Pediatrica
AD_PSC078	Urologia Pediatrica
AD_PSC082	Anestesia e Rianimazione
AD_PSC097	Detenuti
AD_PSC098	Day Surgery Plurispecialistica
AD_PSC100	Laboratorio Analisi Chimico Cliniche
AD_PSC101	Microbiologia e Virologia
AD_PSC102	Centro Trasfusionale e Immunoematologico
AD_PSC103	Radiodiagnostica
AD_PSC104	Neuroradiologia
AD_PSC106	Pronto Soccorso e OBI
AD_PSC107	Poliambulatorio
AD_PSC109	Centrale Operativa 118
AD_PSC121	Comparti Operatori - Degenza Ordinaria
AD_PSC122	Comparti Operatori - Day Surgery
AD_PSC126	Libera Professione Degenza
AD_PSC127	Hospice Ospedaliero
AD_PSC129	Trapianto Organi e Tessuti
AD_PSC130	Medicina di Base
AD_PSC131	Assistenza Territoriale

Codice	Descrizione
AD_PSC199	Raccolta Consenso
AD_PSC999	Altro

I Valori barrati saranno deprecati nell’A.D. 2.5

2.12.6 Tabella 3.1-1 Affinity Domain: Tipologia di attività clinica/organizzativa

Code	DisplayName	Descrizione
CON	Consulto	Documenti condivisi per richiedere un consulto
DIS	Discharge	Documenti condivisi a seguito di un ricovero
ERP	Erogazione Prestazione Prenotata	Documenti condivisi a seguito di una prestazione programmata/prenotata

2.12.1 Table 0032 - Regime

Le codifiche sono quelle previste dall’Affinity Domain Italia - Tabella 2.24-1. Value set per il metadato XDSDocumentEntry.Slot – administrativeRequest.

Codice	Nome mnemonico	Descrizione utilizzo
SSN	Regime SSN	Documento prodotto in regime SSN (in seguito a impegnativa SSN o screening)
INPATIE NT	Regime di ricovero	Documenti prodotti in: regime di ricovero ad eccezione di ricoveri in libera professione completamente a carico del cittadino, pronto soccorso ad eccezione dei pazienti che non hanno copertura SSN.
NOSSN	Regime privato	Documento prodotto in regime privato per cui il cittadino paga tutte le spese sanitarie (es. ricoveri in libera professione, prestazioni intramoenia, etc.
SSR	Regime SSR	Documento prodotto in regime SSR (all’interno di progettualità regionali)
DONOR	Regime donatori	Documento prodotto in regime per i donatori

2.12.1 Tabella 2.7-1 Affinity Domain: . Value set per il metadato XDSDocumentEntry.eventCodeList

Le codifiche sono quelle previste dall’Affinity Domain Italia - Tabella 2.7-1. Value set per il metadato XDSDocumentEntry.eventCodeList.

Codice	Nome mnemonico	Descrizione utilizzo
J07BN	Vaccino per Covid-19	Fornisce indicazione relativamente all’evento vaccino per Covid-19, dettagliando maggiormente il contenuto del metadato typeCode cui è correlato (ad es. scheda della singola vaccinazione). Il codice utilizzato è individuato dalla classificazione ATC.
LP41801 9-8	Tampone antigenico per Covid- 19	Fornisce indicazione relativamente all’evento tampone antigenico per Covid-19, dettagliando maggiormente il contenuto del metadato typeCode cui è correlato (ad es. referto di laboratorio). Il codice utilizzato è individuato dalla codifica LOINC.
LP41754 1-2	Tampone molecolare per Covid- 19	Fornisce indicazione relativamente all’evento tampone molecolare per Covid-19, dettagliando maggiormente il contenuto del metadato typeCode cui è correlato (ad es. referto di laboratorio). Il codice utilizzato è individuato dalla codifica LOINC.
96118-5	Test Sierologico qualitativo	Fornisce indicazione relativamente all’evento test sierologico qualitativo per Covid-19, dettagliando maggiormente il contenuto del metadato

		typeCode cui è correlato (ad es. referto di laboratorio). Il codice utilizzato è individuato dalla codifica LOINC
94503-0	Test Sierologico quantitativo	Fornisce indicazione relativamente all’evento test sierologico quantitativo per Covid-19, dettagliando maggiormente il contenuto del metadato typeCode cui è correlato (ad es. referto di laboratorio). Il codice utilizzato è individuato dalla codifica LOINC.
LP26746 3-0	Reddito	Consente di specificare che il metadato typeCode (57827-8) cui è correlato, fa riferimento ad un documento di esenzione per reddito. Il codice utilizzato è individuato dalla codifica LOINC.
LP19919 0-2	Patologia	Consente di specificare che il metadato typeCode (57827-8) cui è correlato, fa riferimento ad un documento di esenzione per patologia. Il codice utilizzato è individuato dalla codifica LOINC.
90768-3	Analisi sangue donatore	Consente di specificare che il metadato typeCode (11502-2) cui è correlato, fa riferimento ad un referto di laboratorio contenente i risultati degli esami eseguiti su sangue di donatore. Il codice utilizzato è individuato dalla codifica LOINC
V32	02/11/2023	Corretto riferimento numero tabelle dell’Affinity Domain 2.4.1.