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 doc.

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

V34

05/09/2024

2.12.1

2.11.6


1.1

2.3

2.10.15

2.11.1

2.11.7

Recepite modifiche/integrazioni previste dall’Affinity Domain 2.5: Inseriti nuovi valori di assetto organizzativo


Indicazioni per FSE 2.0


Indice

1. SCOPO E RIFERIMENTI DEL DOCUMENTO

7

1.1 Il Fascicolo Sanitario FSE 2.0 7

1.2 Scopo del documento 7

1.3 Riferimenti 8

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 (solo per FSE 1.0) 9

2.3.2 Modello con invio del documento al fascicolo (FSE 1.0 e FSE 2.0) 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 12

2.7.1 Attori 12

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 22

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.10.15 Servizio per il recupero dello stato della transazione 24

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 52

2.12.1 Table 0001 - Administrative Sex 52

2.12.2 Table 0004 – Patient Class 52

2.12.3 Table 0008 Acknowledgement code 52

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

2.12.5 Table 0085 - Observation result status codes interpretation 53

2.12.6 Table 0103 - Processing ID 53

2.12.7 Table 0123 - Result Status 53

2.12.8 Table 0125 – Value Type 53

2.12.9 Table 0190 - Address type 53

2.12.10 Table 0191 – Type Of Referenced Data 54

2.12.11 Table 0203 - Identifier type 54

2.12.12 Table 0270 – Document Type 54

2.12.13 Table 0271 - Document Completion Status 55

2.12.14 Table 0272 - Document Confidentiality Status 55

2.12.15 Table 0291 – Data Subtype 55

2.12.16 Table 0299 – Encoding 56

2.12.17 Table 0357 – Message error condition codes 56

2.12.18 Table 0362 –Facility 56

2.12.19 Table 0363 – Assigning authority 57

2.12.20 Table 0396 – Coding system table 57

2.12.21 Table 0516 – Error severity 57

2.12.1 Table CSI 001 – modalità di dimissione 58

2.12.2 Table CSI 003 – Ruolo Utente (Tabella 4.1-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 58

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

2.12.6 Tabella 3.1-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 Il Fascicolo Sanitario FSE 2.0

Con l’istituzione del FSE 2.0 [DEC-FSE2] e [DEC-FSE2-LINEEG], il modello previsto è quello delineato nelle linee guida regionali [LINEEG].


In particolare, il modello del Fascicolo Sanitario 2.0 prevede che il sistema aziendale (repository) debba inviare i metadati e il documento nel caso delle operazioni di inserimento, sostituzione e append del documento al fine di indicare al Middleware Regionale che si tratta di una pubblicazione di un documento da inviare al Gateway Nazionale.


Negli altri casi, il sistema aziendale deve inviare solo i metadati del documento previsti dal tracciato.


NOTA BENE:

la corrente versione delle specifiche aggiunge le specifiche di integrazione FSE 2.0 che si affiancano alle precedenti FSE 1.0 che rimangono tuttora valide. Non è al momento ancora possibile richiamare i servizi in modalità di integrazione FSE 2.0, sia in ambiente di certificazione che in ambiente di produzione (anche Nazionale).


1.2 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.


Le specifiche dei servizi HL7 consentono 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 (FSE 1.0)

• Gateway Nazionale (FSE 2.0)

Nell’implementare il modello descritto nel presente documento, la comunicazione delle informazioni deve essere il più possibile completa. E’ onere del Sistema Informativo Aziendale comunicare al FSE ogni variazione relativa ai meta-dati ed eventualmente ai documenti al fine di mantenere allineato l’FSE.


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.3 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 (solo per FSE 1.0)

Nel modello senza invio del documento ammesso in FSE 1.0, 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’interoperabilità 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 (FSE 1.0 e FSE 2.0)

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.


Nel caso di invio in modalità FSE 2.0 e l’azienda esegua l’invio da RCD l’azienda dovrà esporre il servizio di recupero del documento GetDocumento secondo le specifiche definite nel documento [SER_RetrievalDoc].


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

]


[No

2 : 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-V34-FSE20-

Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx

Settembre 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


PID

Patient Identification

Dati anagrafici del paziente

PV1

Patient Visit

Dati di accettazione



DMA-CL-SRS-12-V34-FSE20-

Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx

Settembre 2024

uso: Esterno Pagina 20 di 62


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


PID

Patient Identification

Dati anagrafici del paziente

PV1

Patient Visit

Dati sulla visita


DMA-CL-SRS-12-V34-FSE20-

Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx

Settembre 2024

uso: Esterno Pagina 21 di 62


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



2.10.11 Messaggio MDM^T10 – Document Replacement Notification and Content

Notifica di sostituzione del documento, con allegato il contenuto.


DMA-CL-SRS-12-V34-FSE20-

Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx

Settembre 2024

uso: Esterno Pagina 22 di 62


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-V34-FSE20-

Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx

Settembre 2024

uso: Esterno Pagina 23 di 62


2.10.15 Servizio per il recupero dello stato della transazione

I sistemi dei Repository Aziendali dopo aver inviato al Fascicolo Sanitario della Regione Piemonte la pubblicazione di un documento (nuovo documento o sostituzione di un documento) devono richiamare il servizio REST sul Middleware Regionale per verificare lo stato della transazione tramite workflowIntanceid (il workflowInstanceId è lo stesso valore attribuito in fase di validazione del documento sul Gateway Nazionale). Per i dettagli tecnici del servizio si può far riferimento ai documenti del gateway [GTW].


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


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


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

N

8

..

ST

O

Security


workflowInstanceIdrestituito dal Gateway Nazionale per i documenti validati per FSE 2.0. Nel caso di invio di documenti non inviati in validazione al gateway (modalità FSE 1.0) il

campo va lasciato vuoto.

2.16.840.1.113883.

2.9.2.41503.4.4.e5

b5a6cf88b2a6b292 d7e4ba8f860c283d c11f243d764f1b47 de1ce498a1dd22.e x000000x0



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 0103 - Processing ID


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


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


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 T

ELEMENT NAME

TBL

NOTE

ESEMPIO


1

567

XO N

R

Software Vendor Organization


Contiene l’identificativo del fornitore.

Valorizzare XON.1

FORNITOREX


2

15

ST

R

Software Certified Version or Release Number


Contiene la versione dell’applicazione.

1.5


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

20

IS

O


Namespace Id

Lasciare vuoto

2

999

ST

R

Tab CSI 003

Universal ID

Ruolo di interoperabilità Esempio &MEDOSP


Struttura del campo CWE XCN-23 ENV-5

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 Address


Luogo di nascita del paziente (CIFRATO). Vedi nota (3)

^^001272^^^100^B


21

250

CX

O

Mother’s Identifier


Contiene in CX.1 il 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: ROSSI^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)



DMA-CL-SRS-12-V34-FSE20-

Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx

Settembre 2024

uso: Esterno Pagina 29 di 62



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



22

2

IS

O

Courtesy Code


Questo campo è utilizzato per inviare informazioni aggiuntive sul documento.

E’ significativo per i messaggi MDM 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


1234567890$S$U$N$ DOC0001$N$36,50$0

$$0

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









sanitario (che dunque non potrà procedere con la mediazione dello stesso).


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 N

N


36

3

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

200712041715









associati ad altri tipi di episodio che non siano episodio di ricovero o di PS sono mostrati anche se privi della data di fine



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

&Ospedale$AD_PSC00 1$CON








classificazione della pratica clinica o specialistica che ha portato alla creazione del documento). Sono ammessi 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


DMA-CL-SRS-12-V34-FSE20-

Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx

Settembre 2024

uso: Esterno Pagina 37 di 62


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

PS


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

REF$68604-8


DMA-CL-SRS-12-V34-FSE20-

Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx

Settembre 2024

uso: Esterno Pagina 38 di 62









TipoDocumentoAlto, TipoDocumentoMedio. I valori vanno separati con $


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

ab123……e345^^134 5









EI.1 (anche se la lunghezza supera i 199 caratteri)


- 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



DMA-CL-SRS-12-V34-FSE20-

Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx

Settembre 2024

uso: Esterno Pagina 41 di 62








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

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)


DMA-CL-SRS-12-V34-FSE20-

Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx

Settembre 2024

uso: Esterno Pagina 42 di 62


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 (Tabella 2-19-1 dell’Affinity Domain Italia ed estensioni regionali)


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



DMA-CL-SRS-12-V34-FSE20-

Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx

Settembre 2024

uso: Esterno Pagina 43 di 62


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


DMA-CL-SRS-12-V34-FSE20-

Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx

Settembre 2024

uso: Esterno Pagina 44 di 62


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



3

705

CWE

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


C

(vd nota 2)

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

15^Nota risultato









(OBX-5.4)


Nota (2)



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 Observation

Data e ora di erogazione, nel caso della prestazione.

Vuota negli altri casi.

Il formato è aaaammgghhmm.

20071206150

5


(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



DMA-CL-SRS-12-V34-FSE20-

Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx

Settembre 2024

uso: Esterno Pagina 47 di 62


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


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 (modalità FSE 1.0) (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

1555487


DMA-CL-SRS-12-V34-FSE20-

Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx

Settembre 2024

uso: Esterno Pagina 48 di 62








• issuer


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 (modalità FSE 1.0 per invii da RCD)

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 HL7

207

4

2

ID

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 0103 - Processing ID

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-V34-FSE20-

Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx

Settembre 2024

uso: Esterno Pagina 53 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-V34-FSE20-

Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx

Settembre 2024

uso: Esterno Pagina 54 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) e integrazioni regionali: Vd. Nota 4 - campo TXA.2 TipoDocumentoMedio a pagina 43


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


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


DMA-CL-SRS-12-V34-FSE20-

Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx

Settembre 2024

uso: Esterno Pagina 55 di 62


2.12.16 Table 0299 – Encoding

Codifica; usato per i documenti.

Codice

Descrizione

Descrizione d’uso


Identificativi HL7


Base64

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

A.S.L. TORINO 3


204

A.S.L. TORINO 4


205

A.S.L. TORINO 5


206

A.S.L. VERCELLI


207

A.S.L. BIELLA


208

A.S.L. NOVARA


209

A.S.L. VERBANO-CUSIO-OSSOLA



DMA-CL-SRS-12-V34-FSE20-

Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx

Settembre 2024

uso: Esterno Pagina 56 di 62


210

A.S.L. CUNEO 1


211

A.S.L. CUNEO 2


212

A.S.L. ASTI


213

A.S.L. ALESSANDRIA


301

A.S.L. CITTA' DI TORINO


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.19 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.20 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 procedures and diagnostic tests).



2.12.21 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.


DMA-CL-SRS-12-V34-FSE20-

Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx

Settembre 2024

uso: Esterno Pagina 57 di 62


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



DMA-CL-SRS-12-V34-FSE20-

Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx

Settembre 2024

uso: Esterno Pagina 58 di 62


Code

DisplayName

Descrizione

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

Modifica

AD_PSC001

Allergologia


AD_PSC002

Day Hospital


AD_PSC003

Anatomia e Istologia Patologica


AD_PSC004

Osservazione breve intensiva (OBI)

nuovo valore

AD_PSC005

Angiologia


AD_PSC006

Cardiochirurgia Pediatrica


AD_PSC007

Cardiochirurgia


AD_PSC008

Cardiologia


AD_PSC009

Chirurgia Generale


AD_PSC010

Chirurgia Xxxxxxx-Xxxxxxxx


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


AD_PSC038

Otorinolaringoiatria


AD_PSC039

Pediatria


AD_PSC040

Psichiatria


AD_PSC041

Medicina termale

nuovo valore

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

Unità 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_PSC067

Pensionanti

nuovo valore

AD_PSC068

Pneumologia, Fisiopatologia Respiratoria, Tisiologia


AD_PSC069

Radiologia


AD_PSC070

Radioterapia


AD_PSC071

Reumatologia


AD_PSC072

Terapia Intensiva pediatrica

nuovo valore

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

deprecato

AD_PSC094

Terapia semi-intensiva

nuovo valore

AD_PSC096

Terapia del dolore

nuovo valore

AD_PSC097

Detenuti


AD_PSC098

Day Surgery


AD_PSC099

Cure palliative

nuovo valore

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

deprecato

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

deprecato

AD_PSC129

Trapianto Organi e Tessuti


AD_PSC130

Medicina di Base


AD_PSC131

Assistenza Territoriale


AD_PSC199

Xxxxxxxx Consenso

nuovo valore

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.

Document Metadata

Filed: September 11th, 2024