FSE
FSE
Componente Locale
Specifica dei Requisiti del protocollo di interoperabilità fra la Componente Locale e i dipartimentali
(modalità HL7 con e senza invio dei documenti clinici)
STATO DELLE VARIAZIONI
VERSIONE | DATA EMISSIONE | PARAGRAFO O PAGINA | DESCRIZIONE DELLA VARIAZIONE |
V10 | n.d. | Tutto il documento | Revisione dell’intero documento |
V11 | n.d. | 4.8.4 e 4.9 | 4.8.4 Inserito il parametro privacyDocumentoFse nel segmento PV1.22; 4.8.4.1 Precisazione su alcuni campi del segmento PV1.22 (nuovo paragrafo) 4.9 Aggiunti codici e descrizioni di errore e warning restituiti dalla RegistraEpisodi legati a scarico referto |
V12 | n.d. | 4.8.4 | 4.8.4 Aggiunta precisazione su invio dati del pagamento ticket, successivamente all’invio del referto |
V13 | n.d. | Tutto il documento | Revisione dell’intero documento |
V14 | 19/02/2016 | 2.11.24 | Aggiunta maggior dettaglio nelle tipologie di documento |
V15 | 15/05/2018 | Tutto il documento | Il documento è stato adeguato in modo da estendere il tracciato al fine di gestire i metadati richiesti per garantire l’interoperabilità nazionale con la componente INI (Infrastruttura Nazionale per l’Interoperabilità) realizzata dal Ministero dell’Economia e delle Finanze secondo quanto previsto dal comma 15-ter, articolo 12 del decreto legge 18 ottobre 2012 n.179 e successive modifiche. Per completezza di informazioni, a differenza delle altre versioni del presente documento, è stato scelto di produrre un solo documento che recepisse gli aggiornamenti del tracciato sia nel caso di invio senza documenti, sia nel caso di invio con documenti. A tal fine sono stati descritti i due modelli "Modello con invio del documento" e "Modello senza invio del documento" e sono state descritte le principali modifiche introdotte dall’integrazione con l'infrastruttura INI. |
V16 | 15/06/2018 | 2.4.4, 2.11.3 | Aggiunta istruzioni di cifratura per segmento PID |
V17 | 19/07/2018 | 2.4.4 | Aggiornata modalità di cifratura dei dati |
V18 | 20/07/2018 | 2.7.8 | Aggiunti diagrammi MDM_T05 |
V19 | 01/08/2018 | 2.7.8,2.10.9, 2.10.10 2.11.5, 2.11.6 | Sostituito messaggio MDM_T05 con MDM_T06 Specificazione campi segmenti TXA e OBX Revisione tabelle 0125 e 0191 |
V20 | 22/10/2018 | 2.13.23 | Modifica campo MSH.4 Rivista tabella Table 0362 –Facility Revisione Table CSI 003 – Ruolo Utente (Tabella 5.4-1 dell’Affinity Domain) |
V21 | 12/07/2019 | 2.11.2 2.11.4 2.11.6 | Modifica colonna OPT campo XCN EVN-5 Modifica campo PV1.22 (courtesy code) per aggiunta stato pagamento “Rimborso per rottura provetta” Modifica colonna OPT campo OBX.3 (per OBX.2=CE) |
V22 | 24/10/2019 | 2.11.5 | Aggiunta specifica per compilazione campo TXA.12 (numero univo del documento) nel caso di invio recupero pregresso |
V23 | 24/01/2020 | 2.11.5 | Aggiunta valorizzazioni tipologiaDocumentoAlto e tipologiaDocumentoMedio Specificazioni per Modifica campo PV1.22 (courtesy code) per aggiunta stato pagamento “Rimborso (es.per rottura provetta)” |
V24 | 15/04/2020 | 2.11.16 2.12 | Specificazione ed esempi OBX.5 per accession numbers multipli Aggiunta nuovi errori/warning in tab.Codici Errore |
V25 | 15/04/2020 | 2.11.16 2.11.4 | Modifica delle informazioni contenute nel campo OBX.5 per accession numbers Inserito chiarimento rispetto alle informazioni relative al flag “oscuramento per il cittadino” |
V26 | Luglio 2021 | 2.11.4 | Modifica campo PV1.22 (courtesy code) per aggiunta stato pagamento “F” (Free – es. lettera dimissione) |
V27 | Luglio 2021 | 2.11.4 | Precisazioni sull’utilizzo del campo PV1-50 |
V28 | 26/04/2022 | 2.12 | Rimosso paragrafo ‘Codici di errore’. L’elenco degli errori si trovano su un documento apposito. |
V29 | 29/03/2023 | 1.2 2.11.5 2.11.7 2.11.2 | Riferimenti Aggiunto segmento SFT Aggiunto regime, oscuramento al genitore e la modalità di dimissione nel PV1 Aggiunto eventCode nel OBX |
V30 | 03/07/2023 | 2.11.5 | Chiarimenti su campo PV1.22 (courtesy code), sottocampi leggi speciali, privacy documento, oscuramento all’assistito, oscuramento al genitore. Chiarimenti su campo PV1.45 (data fine episodio) |
V31 | 26/10/2023 | 2.12.5 | Aggiornata tabella 2.12-1 Affinity Domain –Assetto organizzativo / Pratica Clinica o specialistica |
V32 | 02/11/2023 | Intero documenti | Corretto riferimento tabelle dell’Affinity Domain 2.4.1 |
Indice
1. SCOPO E RIFERIMENTI DEL DOCUMENTO
7
2. INTEGRAZIONE MEDIANTE MESSAGGI HL7
9
2.2 Le “informazioni sanitarie” 9
2.3 I modelli di integrazione con il Fascicolo: con o senza il documento 9
2.3.1 Modello senza invio del documento al fascicolo 9
2.3.2 Modello con invio del documento al fascicolo 10
2.4 Principali modifiche apportate al protocollo con l’introduzione di INI 10
2.4.1 Gestione dei documenti “addendum” 10
2.4.2 Formato e firma dei documenti 10
2.4.3 Dati di dettaglio del Laboratorio di Analisi 10
2.4.4 Cifratura dei dati identificativi e del documento (se inviato) 10
2.5 Le informazioni sanitarie e i messaggi HL7 11
2.6 I messaggi inviati dal ILEC ai sistemi gestionali 11
2.7.2 Invia notifica apertura episodio o modifica di un episodio aperto già notificato 13
2.7.3 Invia notifica chiusura episodio o modifica di un episodio chiuso già notificato 14
2.7.4 Invia nuovo referto/documento, o aggiornamento dati strutturati legati ad un referto/documento già notificato 14
2.7.5 Sostituisci referto/documento 16
2.7.6 Invia annullamento episodio 17
2.7.7 Invia annullamento documento 18
2.7.8 Invia addendum ad un referto/documento già notificato 18
2.8 Modalità e ordine di attivazione dei servizi 19
2.9 Vincoli sui dati da inviare 19
2.10 La struttura dei messaggi 20
2.10.1 Messaggio ADT^A01^ADT_A01 – Admit/Visit Notification (Event A01) 20
2.10.2 Messaggio ACK^A01^ACK – ACK Admit/Visit Notification 20
2.10.3 Messaggio ADT^A03^ADT_A03 – Discharge/End Visit (Event A03) 20
2.10.4 Messaggio ACK^A03^ACK – ACK Discharge/End Visit 21
2.10.5 Messaggio ADT^A11^ADT_A09 – Cancel Admit / Visit Notification (Event A11) 21
2.10.6 Messaggio ACK^A11^ACK – ACK Cancel Admit / Visit Notification 21
2.10.7 Messaggio MDM^T02 – Original Document Notification and Content 21
2.10.8 Messaggio ACK^T02^ACK – ACK Original Document Notification and Content 22
2.10.9 Messaggio MDM^T06 – Document addendum notification and content 22
2.10.10 Messaggio ACK^T06^ACK – ACK Document addendum notification and content 22
2.10.11 Messaggio MDM^T10 – Document Replacement Notification and Content 23
2.10.12 Messaggio ACK^T10^ACK – ACK Document Replacement Notification and Content 23
2.10.13 Messaggio MDM^T11 – Document Cancel Notification 23
2.10.14 Messaggio ACK^T11^ACK – Document Cancel Notification 23
2.11 I segmenti dei messaggi 25
2.11.1 Segmento MSH: Message Header Segment 25
2.11.2 Segmento SFT: Software Segment 26
2.11.3 Segmento EVN: Event type 27
2.11.4 Segmento PID: Patient identification 28
2.11.5 Segmento PV1: Patient visit segment 30
2.11.6 Segmento TXA: Transcription Document Header 38
2.11.7 Segmento OBX: Observation Segment 44
2.11.8 Segmento MSA: Message Acknowledgment Segment 49
2.11.9 Segmento ERR: Error segment 49
2.12.1 Table 0001 - Administrative Sex 51
2.12.2 Table 0004 – Patient Class 51
2.12.3 Table 0008 Acknowledgement code 51
2.12.4 Table 0076 - Message Type - e Table 0003 Event Type 51
2.12.5 Table 0085 - Observation result status codes interpretation 52
2.12.6 Table 0000 - Xxxxxxxxxx XX 52
2.12.7 Table 0123 - Result Status 52
2.12.8 Table 0125 – Value Type 52
2.12.9 Table 0190 - Address type 52
2.12.10 Table 0191 – Type Of Referenced Data 53
2.12.11 Table 0203 - Identifier type 53
2.12.12 Table 0270 – Document Type 53
2.12.13 Table 0271 - Document Completion Status 54
2.12.14 Table 0272 - Document Confidentiality Status 54
2.12.15 Table 0291 – Data Subtype 55
2.12.16 Table 0299 – Encoding 55
2.12.17 Table 0357 – Message error condition codes 55
2.12.18 Table 0361 –Application 56
2.12.19 Table 0362 –Facility 56
2.12.20 Table 0363 – Assigning authority 57
2.12.21 Table 0396 – Coding system table 57
2.12.22 Table 0516 – Error severity 58
2.12.1 Table CSI 001 – modalità di dimissione 58
2.12.2 Table CSI 003 – Ruolo Utente (Tabella 5.4-1 dell’Affinity Domain) 58
2.12.3 Table 0119 - Order control codes 58
2.12.4 Table 2.8-1 Affinity Domain – Facility TypeCode 59
2.12.5 Table 2.12-1 Affinity Domain –Assetto organizzativo / Pratica Clinica o specialistica 59
2.12.6 Tabella 3.2-1 Affinity Domain: Tipologia di attività clinica/organizzativa 61
2.12.1 Tabella 2.7-1 Affinity Domain: . Value set per il metadato XDSDocumentEntry.eventCodeList 61
1. Scopo e riferimenti del documento
Scopo del presente documento è di descrivere le Specifiche dei Requisiti sulle modalità di interazione dei servizi logici della Componente Locale (o ILEC, indice locale degli eventi clinici) del Fascicolo Sanitario Elettronico (FSE, da ora in poi Fascicolo) con i sistemi informativi delle Aziende Sanitarie.
Le specifiche sono basate sul protocollo HL7v2 e prevedono che l’integrazione del Sistema informativo dell’azienda sanitaria con il Fascicolo avvenga in modo tale che il documento clinico con relativi metadati a corredo venga inviato e mantenuto sull’ILEC del fascicolo appartenente al dominio dell’azienda sanitaria.
In aggiunta a quanto già previsto, saranno descritti i metadati richiesti per la realizzazione dell’interoperabilità con INI da richiedere alle Aziende in fase di alimentazione del Fascicolo presso la Componente Locale delle Aziende.
Per semplificare la lettura rispetto alla versione precedente delle specifiche in alcune tabelle (ove opportuno) è stata inserita come prima colonna l’informazione (VAR) sulla eventuale variazione rispetto alla versione precedente.
Sono stati previsti i seguenti valori:
• N: nuovo campo
• C: campo modificato
• E: campo eliminato
• [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
In questo paragrafo vengono descritti i servizi presentati funzionalmente nel capitolo precedente attraverso diagrammi di sequenza HL7. Tali diagrammi rappresentano l’interazione che avviene fra i diversi attori evidenziando i messaggi HL7 scambiati.
Per descrivere meglio il flusso sono riportate anche alcune attività funzionali che vengono svolte dagli attori.
2.2 Le “informazioni sanitarie”
Scopo del presente paragrafo è fornire uno schema semantico del contenuto delle “informazioni sanitarie” che transitano dal sistema informativo dell’ASR al FSE ed due schemi sintattici che mappano lo schema dei messaggi HL7 scambiati.
Dati strutturati NONmodificabili:
⮚ Identificativounivocoepisodio
Informazione sanitariaB
Informazione sanitariaA
Episodio
⮚ Dataeoradell’episodio
⮚ Strutturasanitaria
Dati strutturati modificabili:
⮚ Dato1
⮚ Dato2
⮚ Daton
Dati strutturati/Metadati +Referto/Documento
⮚ Prestazione1
⮚ [Altri dati strutturati del referto1]
⮚ Referto1
⮚ Prestazione2
⮚ [Altri dati strutturati del referto2]
⮚ Referto2
⮚ [Altri dati strutturati del documenton]
⮚ Documenton
Figura n. 1– Mappa delle informazioni sanitarie
2.3 I modelli di integrazione con il Fascicolo: con o senza il documento
2.3.1 Modello senza invio del documento al fascicolo
Nel modello senza invio del documento, l’azienda invia i metadati al Fascicolo della Regione Piemonte senza mandare il documento che risiederà presso il repository dell’Azienda stessa.
In tale modello l’Azienda dovrà utilizzare il messaggio MDM^T02 valorizzando i segmenti TXA e OBX per comunicare i soli metadati descritto nel capitolo seguente relativo alle specifiche del protocollo.
In particolare come descritto nella struttura del segmento OBX, per il messaggio MDM^T02, non dovrà essere
valorizzato il campo
• OBX-5 Observation Value,
mentre sarà richiesta l’indicazione del repository da riportare nel campo:
• TXA-12 Unique Document Number (Entity Identifier EI.1)
alle Aziende che aderiranno al nuovo modello in conformità alle specifiche previste dall’inter-operabilità nazionale.
Inoltre l’azienda dovrà esporre il servizio di recupero del documento GetDocumento secondo le specifiche definite nel documento [SER_RetrievalDoc].
2.3.2 Modello con invio del documento al fascicolo
Nel modello con invio del documento, l’azienda invia i metadati e il documento al Fascicolo della Regione Piemonte.
In tale modello l’Azienda dovrà utilizzare il messaggio MDM^T02 valorizzando i segmenti TXA e OBX per comunicare i metadati e il documento descritto nel capitolo seguente relativo alle specifiche del protocollo.
In particolare come descritto nella struttura del segmento OBX, per il messaggio MDM^T02, dovrà essere valorizzato anche il campo OBX-5 Observation Value
2.4 Principali modifiche apportate al protocollo con l’introduzione di INI
Scopo del capitolo è descrivere le principali modifiche apportate all’attuale versione del protocollo con l’introduzione dei metadati richiesti dall’interoperabilità del Fascicolo sanitario regionale con INI.
Per un’analisi di dettaglio apportata ai dati richiesti dal protocollo, fare riferimento ai capitoli successivi.
2.4.1 Gestione dei documenti “addendum”
Il tracciato è stato esteso al fine di consentire la possibilità di inviare documenti in “Addendum” al documento principale nel caso in cui il sistema informativo dell’Azienda li preveda. Le modalità di gestione di questi documenti sono descritti nelle specifiche di dettaglio del tracciato
2.4.2 Formato e firma dei documenti
In coerenza ai requisiti di inter-operabilità nazionale si richiede che i documenti interoperabili, definiti dal decreto [DPCM 178], vengano inviati nel formato pdf con CDA iniettato e firmato con firma PADES BES, secondo le scelte adottate dalla Regione Piemonte e le direttive previste dal tavolo di lavoro inter-regionale sulla firma dei documenti per il Fascicolo Sanitario Nazionale.
2.4.3 Dati di dettaglio del Laboratorio di Analisi
I dati di dettaglio del laboratorio di analisi non vengono più richiesti (valore, range e unità di misura della prestazione).
2.4.4 Cifratura dei dati identificativi e del documento (se inviato)
Tutti i servizi HL7 realizzati per l’adeguamento a INI devono prevedere la cifratura dei dati anagrafici (nome, cognome, codice fiscale, luogo di nascita) e – quando presente - del documento inviato.
La cifratura verrà effettuata dalle Aziende Sanitarie sui campi indicati utilizzando l’algoritmo di cifratura AES con chiave simmetria a 256bit.
Ogni Azienda genererà una propria chiave simmetrica a 256 bit ed, in fase di predisposizione degli ambienti, dovrà comunicare via e-mail al CSI Piemonte la chiave simmetrica utilizzata assieme al codice dell’applicazione del dipartimentale che utilizzerà per inviare i messaggi HL7.
La comunicazione della chiave non dovrà avvenire in chiaro; l’Azienda dovrà cifrare la chiave simmetrica che utilizzerà per le comunicazioni con la chiave pubblica del FSEr (che verrà fornita dal CSI-Piemonte) utilizzando l’algoritmo AES-256 CBC.
2.5 Le informazioni sanitarie e i messaggi HL7
La gestione di un episodio clinico può essere gestito da più messaggi, in generale:
1 da un messaggio di apertura dell’episodio (ADT^A01) che contiene:
1.1 dati strutturati che caratterizzano l’episodio:
1.1.1 identificativo univoco dell’episodio,
1.1.2 data ed ora dell’episodio,
1.1.3 Struttura sanitaria di erogazione;
2 da un messaggio di chiusura dell’episodio (ADT^A03) che contiene:
2.1 dati strutturati che caratterizzano l’episodio:
2.1.1 identificativo univoco dell’episodio,
2.1.2 data ed ora apertura dell’episodio (ovvero di accettazione per episodi di ricovero e di PS),
2.1.3 data ed ora chiusura dell’episodio (ovvero di dimissione per episodi di ricovero e di PS),
2.1.4 Struttura sanitaria di erogazione;
3 da un messaggio per invio dei dati strutturati relativi ad un referto/documento (MDM^T02); qualora l’Azienda non sia dotata di un repository aziendale tale messaggio include anche il documento allegato all’episodio; viene inviato un messaggio per ogni documento da trasmettere; tale messaggio può essere utilizzato anche per aggiornare i dati strutturati legati al documento trasmesso.
4 da un messaggio di invio di documento addendum (MDM^T06)
5 da un messaggio di sostituzione di un documento (MDM^T10– l’OBX contiene il codice del nuovo documento, il nuovo contenuto e lo stato con valore “C”; il segmento TXA contiene l’identificativo del documento obsoleto nel campo “Parent Document Number” e l’identificativo del nuovo documento nel campo “Unique Document Number”);
6 da un messaggio di annullamento di un documento (MDM^T11)
7 da un messaggio di annullamento di un episodio (ADT^A11)
2.6 I messaggi inviati dal ILEC ai sistemi gestionali
In risposta ai messaggi inviati al ILEC dai sistemi informativi aziendali, l’ILEC stesso restituisce il corrispettivo messaggio di acknowledge.
Nel seguito verranno descritti gli attori che partecipano all'integrazione:
• applicazione dell’Azienda Sanitaria (quale ad esempio: cartella, ambulatoriale, sistema DEA, sistema di ricovero, etc)
• CL: Componente Locale del FSE dedicata ad una Azienda Sanitaria (tale componente fa parte del dominio informatico dell’azienda). In tale componente è presente l’ILEC (Indice Locale degli Eventi Clinici).
Simboli presenti nei diagrammi di sequenza:
Boundary
È un’entità che giace al perimetro del sistema, ma ancora entro esso. Interagisce con attori al di fuori del sistema, entity, controller e altre boundary.
Worker
Rappresenta l’astrazione di un essere umano che agisce entro il sistema. Un worker interagisce con altri worker e entità del sistema.
Entity
Entità passiva che non effettua interazioni per proprio conto. Usato per rappresentare le componenti del sistema informativo dell’Azienda.
: FSA TO2
2.7.2 Invia notifica apertura episodio o modifica di un episodio aperto già notificato
: Applicazione
CL
1 : ADT^A01
3 : ACK^A01^ACK - con ERR
]
[Xx
0 : ACK^A01^ACK - no ERR
borazione effettuata correttamente?
alt Ela
[Si]
Figura n. 2– Diagramma sequenza HL7 - Invia notifica apertura episodio
2.7.3 Invia notifica chiusura episodio o modifica di un episodio chiuso già notificato
CL
Figura n. 3– Diagramma sequenza HL7 - Invia notifica chiusura episodio
2.7.4 Invia nuovo referto/documento, o aggiornamento dati strutturati legati ad un
: FSA TO2
referto/documento già notificato
: Applicazione
CL
1 : MDM^T02 Stato OBX-11 = F
3 : ACK^T02^ACK - con ERR
[No]
2 : ACK^T02^ACK - no ERR
xxxxx effettuata correttamente?
alt Elabora
[Sì]
Figura n. 3– Diagramma sequenza HL7- Invia nuovo referto/documento
: CL Dossier
2.7.5 Sostituisci referto/documento
: Dipartimentale
CL
1 : MDM^T10
alt Elaborazione effettuata correttamente?
Stato OBX-11 = C (nel caso di valore modificato) oppure
Stato OBX-11 = D (nel caso di valore cancellato) Referto/Documento nel segmento OBX
Stato OBX-11 = C
TXA-12 e 13 contengono rispettivamente nuovo id e vecchio id del referto/documento
[Sì]
2 : ACK^T10^ACK - no ERR
[No]
3 : ACK^T10^ACK - con ERR
Figura n. 4– Diagramma sequenza HL7- Sostituisci referto/documento
Nel caso di sostituzione di un documento comunicato come addendum il campo TXA-13 dovrà contenere l’id del documento addendum da sostituire.
Il documento parent non subirà modifiche.
DMA-CL-SRS-12-V32-
Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx
Novembre 2023
uso: Esterno Pagina 16 di 62
: FSA TO2
2.7.6 Invia annullamento episodio
: Applicazione
CL
1 : ADT^A11
alt Elaborazione effettuata correttamente?
[SI]
3 : ACK^A11^ACK - con ERR
[NO]
2 : ACK^A11^ACK - no ERR
Figura n. 5– Diagramma sequenza HL7- Invio annullamento episodio
2.7.7 Invia annullamento documento
L’annullamento del documento è realizzato con il messaggio MDM^T11.
Figura n.7– Diagramma sequenza HL7- Invio annullamento documento
Nel caso di annullamento di un documento al quale sono collegati uno o più addendum, sarà necessario effettuare preventivamente l’annullamento degli addendum, valorizzando il campo TXA-12 con l’identificativo del documento di Addendum.
Una volta eliminati tutti gli addendum sarà possibile eliminare anche il documento parent, con le stesse modalità, valorizzando il campo TXA-12 con l’identificativo del documento parent.
2.7.8 Invia addendum ad un referto/documento già notificato
L’invio di un addendum è realizzato con il messaggio MDM^T06
Figura n.8 – Diagramma sequenza HL7- Invio addendum a documento
2.8 Modalità e ordine di attivazione dei servizi
La modalità e l’ordine di attivazione dei servizi è descritta nel capitolo funzionale; per costruire i diagrammi temporali in HL7 è sufficiente partire dai singoli diagrammi funzionali e sostituire al singolo servizio interessato il corrispondente diagramma HL7.
2.9 Vincoli sui dati da inviare
Si precisa che le ASO/ASL che si integrano con il fascicolo SOLO per l’utilizzo dello scarico referti non dovranno inviare messaggi HL7 legati alla gestione dell’episodio, ma solo i messaggi relativi ai referti.
Pertanto gli applicativi dipartimentali non dovranno inviare messaggi di tipo ADT al fascicolo.
Nel caso in cui si dovesse verificare un annullamento di episodio, a cui è legato un referto già inviato al fascicolo per lo scarico online, il dipartimentale deve inviare un annullamento del documento, attraverso il messaggio MDM^T11.
In caso si verificasse invece lo spostamento di un episodio da un paziente ad un altro, il dipartimentale deve inviare un annullamento del documento, attraverso il messaggio MDM^T11, ed inviare un messaggio MDM^T02 per il referto del paziente nuovo.
2.10 La struttura dei messaggi
Nei paragrafi successivi verranno presentati i segmenti e i campi che sono di interesse per ciascun messaggio. Nel presente capitolo si farà riferimento alla versione 2.6 di HL7.
Il valore della colonna OPT delle tabelle delle descrizioni dei segmenti HL7 può essere: R (obbligatorio), O (facoltativo), C (campo condizionale). Tale informazione va interpretata nel contesto specifico del FSE della Regione Piemonte.
2.10.1 Messaggio ADT^A01^ADT_A01 – Admit/Visit Notification (Event A01)
Il messaggio rappresenta la notifica di accettazione del ricovero di un paziente per gli episodi di ricovero. L’invio del messaggio è facoltativo per gli episodi di tipo ambulatoriale in quanto, in assenza del messaggio ADT^A01^ADT_A01, alla ricezione di un messaggio MDM il sistema provvederà in autonomia a creare anche il corrispondente episodio.
Il messaggio ADT^A01^ADT_A01 è obbligatorio nel caso di apertura di un episodio di ricovero qualora la matricola di dimissione sia differente dalla matricola di dimissione.
Il messaggio ADT^A01^ADT_A01 è costituito dai segmenti elencati nella tabella che segue.
Segmento | Descrizione | Note |
MSH | Message Header | Indicazioni generali sul messaggio inviato. |
[SFT] | Software segment | identificativo applicazione, identificativo fornitore e versione |
EVN | Event Type | |
PID | Patient Identification | Dati anagrafici del paziente |
PV1 | Patient Visit | Dati di accettazione |
2.10.2 Messaggio ACK^A01^ACK – ACK Admit/Visit Notification
Risposta alla notifica di accettazione del ricovero di un paziente per gli episodi di ricovero. Il messaggio ACK^A01^ACK è costituito dai segmenti elencati nella tabella che segue.
Segmento | Descrizione | Note |
MSH | Message Header | Indicazioni generali sul messaggio inviato. |
[{SFT}] | Software segment | non usato |
MSA | Message acknowledge | |
[{ERR}] | Error information |
2.10.3 Messaggio ADT^A03^ADT_A03 – Discharge/End Visit (Event A03)
Il messaggio rappresenta la notifica di dimissione di un paziente per gli episodi di ricovero.
Il messaggio ADT^A03^ADT_A03 è obbligatorio nel caso in cui si sia inviato, per il medesimo episodio, un messaggio ADT^A01^ADT_A01 e la matricola di dimissione sia diversa da quella di accettazione.
Il messaggio ADT^A03^ADT_A03 è costituito dai segmenti elencati nella tabella che segue.
Segmento | Descrizione | Note |
MSH | Message Header | Indicazioni generali sul messaggio inviato. |
[SFT] | Software segment | identificativo applicazione, identificativo fornitore e versione |
EVN | Event Type |
DMA-CL-SRS-12-V32- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx | Novembre 2023 | uso: Esterno Pagina 20 di 62 |
PID | Patient Identification | Dati anagrafici del paziente |
PV1 | Patient Visit | Dati di accettazione |
2.10.4 Messaggio ACK^A03^ACK – ACK Discharge/End Visit
Risposta alla notifica di dimissione di un paziente per gli episodi di ricovero.
Il messaggio ACK^A03^ACK è costituito dai segmenti elencati nella tabella che segue.
Segmento | Descrizione | Note |
MSH | Message Header | Indicazioni generali sul messaggio inviato. |
[{SFT}] | Software segment | non usato |
MSA | Message acknowledge | |
[{ERR}] | Error information |
2.10.5 Messaggio ADT^A11^ADT_A09 – Cancel Admit / Visit Notification (Event A11)
Il messaggio rappresenta la notifica di annullamento di un episodio di ricovero.
Il messaggio ADT^A11^ADT_A09 è costituito dai segmenti elencati nella tabella che segue.
Segmento | Descrizione | Note | |
MSH | Message Header | Indicazioni generali sul messaggio inviato. | |
[SFT] | Software segment | identificativo applicazione, identificativo fornitore e versione | |
EVN | Event Type | ||
PID | Patient Identification | Dati anagrafici del paziente | |
PV1 | Patient Visit | Dati di accettazione |
Nel PV1 deve essere riportato il numero nosologico da annullare.
2.10.6 Messaggio ACK^A11^ACK – ACK Cancel Admit / Visit Notification
Risposta alla notifica di annullamento di un episodio di ricovero.
Il messaggio ACK^A11^ACK è costituito dai segmenti elencati nella tabella che segue.
Segmento | Descrizione | Note |
MSH | Message Header | Indicazioni generali sul messaggio inviato. |
[{SFT}] | Software segment | non usato |
MSA | Message acknowledge | |
[{ERR}] | Error information |
2.10.7 Messaggio MDM^T02 – Original Document Notification and Content
Il messaggio è utilizzato per notificare un documento validato; il documento è inteso come costituito da alcuni metadati e dal suo contenuto.
Ogni messaggio MDM^T02 contiene uno ed un solo documento.
Il messaggio MDM^T02 è costituito dai segmenti elencati nella tabella che segue.
Segmento | Descrizione | Note |
MSH | Message Header | Indicazioni generali sul messaggio inviato. |
[SFT] | Software segment | identificativo applicazione, identificativo fornitore e versione |
EVN | Event Type |
DMA-CL-SRS-12-V32- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx | Novembre 2023 | uso: Esterno Pagina 21 di 62 |
PID | Patient Identification | Dati anagrafici del paziente |
PV1 | Patient Visit | Dati sulla visita |
TXA | Transcription Document Header | Dati di intestazione del documento |
{ | ||
OBX | Observation/Result (one or more required) | Contenuto del documento |
} |
2.10.8 Messaggio ACK^T02^ACK – ACK Original Document Notification and Content
Risposta alla notifica della creazione del documento.
Il messaggio ACK^T02^ACK è costituito dai segmenti elencati nella tabella che segue.
Segmento | Descrizione | Note |
MSH | Message Header | Indicazioni generali sul messaggio inviato. |
[{SFT}] | Software segment | non usato |
MSA | Message acknowledge | |
[{ERR}] | Error information |
2.10.9 Messaggio MDM^T06 – Document addendum notification and content
Il messaggio è utilizzato per notificare un documento addendum di un documento precedentemente inviato; il documento è inteso come costituito da alcuni metadati e dal suo contenuto.
Ogni messaggio MDM^T06 contiene uno ed un solo documento.
Il messaggio MDM^T06 è costituito dai segmenti elencati nella tabella che segue.
Segmento | Descrizione | Note |
MSH | Message Header | Indicazioni generali sul messaggio inviato. |
[SFT] | Software segment | identificativo applicazione, identificativo fornitore e versione |
EVN | Event Type | |
PID | Patient Identification | Dati anagrafici del paziente |
PV1 | Patient Visit | Dati sulla visita |
TXA | Transcription Document Header | Dati di intestazione del documento |
{ | ||
OBX | Observation/Result (one or more required) | Contenuto del documento |
} |
2.10.10 Messaggio ACK^T06^ACK – ACK Document addendum notification and content
Risposta alla notifica della creazione del documento.
Il messaggio ACK^T06^ACK è costituito dai segmenti elencati nella tabella che segue.
Segmento | Descrizione | Note |
MSH | Message Header | Indicazioni generali sul messaggio inviato. |
[{SFT}] | Software segment | non usato |
MSA | Message acknowledge | |
[{ERR}] | Error information |
DMA-CL-SRS-12-V32- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx | Novembre 2023 | uso: Esterno Pagina 22 di 62 |
2.10.11 Messaggio MDM^T10 – Document Replacement Notification and Content
Notifica di sostituzione del documento, con allegato il contenuto.
Il messaggio MDM^T10 è costituito dai segmenti elencati nella tabella che segue.
Segmento | Descrizione | Note |
MSH | Message Header | Indicazioni generali sul messaggio inviato. |
[SFT] | Software segment | identificativo applicazione, identificativo fornitore e versione |
EVN | Event Type | |
PID | Patient Identification | Dati anagrafici del paziente |
PV1 | Patient Visit | Dati sulla visita |
TXA | Transcription Document Header | Dati di intestazione del documento |
{ | ||
OBX | Observation/Result (one or more required) | Contenuto del documento |
} |
2.10.12 Messaggio ACK^T10^ACK – ACK Document Replacement Notification and Content
Risposta alla notifica della sostituzione del documento.
Il messaggio ACK^T10^ACK è costituito dai segmenti elencati nella tabella che segue.
Segmento | Descrizione | Note |
MSH | Message Header | Indicazioni generali sul messaggio inviato. |
[{SFT}] | Software segment | non usato |
MSA | Message acknowledge | |
[{ERR}] | Error information |
2.10.13 Messaggio MDM^T11 – Document Cancel Notification
Notifica di annullamento del documento.
Il messaggio MDM^T11 è costituito dai segmenti elencati nella tabella che segue.
Segmento | Descrizione | Note |
MSH | Message Header | Indicazioni generali sul messaggio inviato. |
[SFT] | Software segment | identificativo applicazione, identificativo fornitore e versione |
EVN | Event Type | |
PID | Patient Identification | Dati anagrafici del paziente |
PV1 | Patient Visit | Dati sulla visita |
TXA | Transcription Document Header | Dati di intestazione del documento |
2.10.14 Messaggio ACK^T11^ACK – Document Cancel Notification
Risposta alla notifica della cancellazione del documento.
Il messaggio ACK^T11^ACK è costituito dai segmenti elencati nella tabella che segue.
Segmento | Descrizione | Note |
MSH | Message Header | Indicazioni generali sul messaggio inviato. |
[{SFT}] | Software segment | non usato |
MSA | Message acknowledge | |
[{ERR}] | Error information |
DMA-CL-SRS-12-V32- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx | Novembre 2023 | uso: Esterno Pagina 23 di 62 |
2.11.1 Segmento MSH: Message Header Segment
Il segmento MSH è uno dei segmenti di controllo. Fornisce una serie di informazioni generali, tra le quali:
🟃 chi invia
🟃 chi riceve
🟃 quale messaggio si sta inviando
🟃 data e ora di creazione del messaggio
🟃 l’identificativo univoco per il riconoscimento del messaggio.
VAR | SEQ | LEN | DT | O P T | ELEMENT NAME | TBL | NOTE | ESEMPIO |
1 | 1 | ST | R | Field Separator | Contiene il carattere pipe “|” ed identifica il carattere usato come separatore nel resto del messaggio. | | | ||
2 | 4 | ST | R | Encoding Characters | Contiene i separatori utilizzati, ovvero “^~\&” per identificare il separatore, rispettivamente, del componente, di ripetizione, di escape e di sottocomponente. | ^~\& | ||
3 | 227 | HD | O | Sending Application | Table 0361 – Application | Dipartimentale inviante | ^HIS_DEA | |
4 | 227 | HD | O | Sending Facility | Table 0362 – Facility | L’entità organizzativa responsabile dell’invio delle informazioni. INDICARE IL CODICE ASR INVIANTE. Per i privati rappresenta la ASR indicata sul sistema AURA | ^203 | |
5 | 227 | HD | Receiving Application | Table 0361 – Application | Dipartimentale ricevente | ^CL | ||
6 | 227 | HD | O | Receiving Facility | Table 0362 – Facility | L’entità organizzativa che riceve le informazioni. Xxxxx ricevente | ^CSI | |
7 | 24 | DT M | R | Date/Time Of Message | Data e ora in cui è stato creato il messaggio dal sistema inviante. Il formato è aaaammgghhMMss. Il valore è analogo al valore del campo EVN^ Recorded Date/Time. | 20080104130101 | ||
9 | 15 | MS G | R | Message Type | Table 0076 message code Table 0003 trigger code | Tipo del messaggio HL7. L’informazione specifica il codice del messaggio (es: ADT, MDM, etc), il trigger event (R01, A01, etc) | MDM^T02 |
10 | 199 | ST | R | Message Control ID | Identificativo unico del messaggio, generato dall’inviante. | 34 | ||
11 | 3 | PT | R | Processing ID | Table 0000 - Xxxxxxxxxx XX | P | ||
12 | 60 | VID | R | Version ID | Identifica la versione HL7 ed è utilizzata dal sistema ricevente per interpretare correttamente il messaggio. Il valore del campo è fissato a “2.6”. | 2.6 |
Struttura del campo HD MSH-3
VAR | SE Q | LEN | DT | OPT | TBL | COMPONENT NAME | Note |
1 | 20 | IS | O | Namespace Id | Non valorizzare | ||
2 | 999 | ST | R | Table 0361 – Application | Universal ID | Dipartimentale inviante |
Struttura del campo HD MSH-4
VAR | SE Q | LEN | DT | OPT | TBL | COMPONENT NAME | Note |
1 | 20 | IS | O | Namespace Id | Non valorizzare | ||
2 | 999 | ST | R | Table 0362 –Facility | Universal ID | L’entità organizzativa responsabile dell’invio delle informazioni. |
Struttura del campo HD MSH-5
VA R | SEQ | LEN | DT | OPT | TBL | COMPONENT NAME | Note |
1 | 20 | IS | O | Namespace Id | Non valorizzare | ||
2 | 999 | ST | R | Table 0361 – Application | Universal ID | Dipartimentale ricevente |
Struttura del campo HD MSH-6
VA R | SEQ | LEN | DT | OPT | TBL | COMPONENT NAME | Note |
1 | 20 | IS | O | Namespace Id | Non valorizzare | ||
2 | 999 | ST | R | Table 0362 –Facility | Universal ID | L’entità organizzativa che riceve le informazioni. |
2.11.2 Segmento SFT: Software Segment
Il segmento SFT contiene le informazioni richieste dall’Affinity Domain Italia previste per l’identificativo applicazione, identificativo fornitore e versione.
VAR | SEQ | LEN | DT | O P | ELEMENT NAME | TBL | NOTE | ESEMPIO |
DMA-CL-SRS-12-V32- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx | Novembre 2023 | uso: Esterno Pagina 26 di 62 |
T | ||||||||
N | 1 | 567 | XO N | R | Software Vendor Organization | Contiene l’identificativo del fornitore. Valorizzare XON.1 | FORNITOREX | |
N | 2 | 15 | ST | R | Software Certified Version or Release Number | Contiene la versione dell’applicazione. | 1.5 | |
N | 3 | 20 | ST | R | Software Product Name | Contiene l’identificativo dell’applicazione | APPLICX |
NOTA. L’identificativo del fornitore, dell’applicazione e la versione da inviare devono essere quelle comunicate in fase di accreditamento con il Gateway (riferimento xxxxx://xxxxxx.xxx/xxxxxxxxx-xxxxxx/xx- fse-accreditati).
2.11.3 Segmento EVN: Event type
Il segmento EVN è uno dei segmenti di controllo. Sono specificate le informazioni: data e ora di creazione del messaggio e utente.
VAR | SEQ | LEN | DT | OPT | ELEMENT NAME | TBL | NOTE | ESEMPIO |
2 | 24 | ID | R | Recorded Date/Time | Data e ora registrazione evento nel formato aaaammgghhMMss. Il valore è analogo al valore del campo MSH^ Date/Time Of Message. | 20080104130101 | ||
5 | 250 | XCN | R | Operator ID | Rappresenta i dati dell’utente che fa richiesta del servizio di interoperabilità. Contiene il codice fiscale, il ruolo e la struttura di appartenenza. |
Struttura del campo XCN EVN-5
VA R | SEQ | LEN | DT | OPT | TBL | COMPONENT NAME | Note |
1 | 16 | ST | R | Person Identifier | Codice Fiscale Utente | ||
9 | 227 | HD | R | Tab CSI 003 - Ruoli | Assigning Authority | Ruolo (contenuto in HD.2) | |
23 | 750 | CW E | R | Assigning Agency or Department | Per la struttura dell’utente indicare in CWE.1 alternativamente - Codice matricola ARPE Oppure - Codice Azienda+Codice struttura + subcodice eventuale |
Esempio: CCCNNN69A03L219D^^^^^^^^&MEDOSP^^^^^^^^^^^^^^21001012300 CCCNNN69A03L219D^^^^^^^^&MEDOSP^^^^^^^^^^^^^^1234
Struttura del campo HD XCN -9 ENV-5
SEQ | LEN | DT | OPT | TBL | COMPONENT NAME | Note |
1 | 00 | XX | X | Xxxxxxxxx Xx | Lasciare vuoto | |
2 | 000 | XX | X | Xxx XXX 000 | Xxxxxxxxx XX | Ruolo di interoperabilità Esempio &MEDOSP |
Struttura del campo XXX XXX-00 XXX-0
SEQ | LEN | DT | OPT | TBL | COMPONENT NAME | Note |
1 | 20 | ST | O | Identifier | Per la struttura dell’utente indicare in alternativa - Codice matricola ARPE Oppure (separati con $) - Codice Azienda$Codice struttura+subcodice eventuale Esempio 1234 Esempio 210$01012300 |
2.11.4 Segmento PID: Patient identification
Il segmento PID contiene i dati del paziente.
Come indicato nel paragrafo 2.4.4 i dati identificativi del paziente e dell’eventuale genitore/tutore devono esserei inviati cifrati. Negli esempi riportati, per maggiore chiarezza, i dati cifrati vengono visualizzati in chiaro.
VAR | SEQ | LEN | DT | OPT | ELEMENT NAME | TBL | NOTE | ESEMPIO |
3 | 250 | CX | R | Patient Identifier List | Lista degli identificativi associati al paziente, contiene le informazioni relative al: codice fiscale (CIFRATO), identificativo anagrafe centrale, identificativo dell’anagrafe locale, ID- AURA. Il CODICE FISCALE va riportato come PRIMO codice della lista. Vedi nota (1) | RSSMRI69A03L219 D^^^^NNITA~1982 7^^^^PZCE~92873^ ^^^PZLO~192383^^ ^^AURA | ||
5 | 250 | XPN | R | Patient Name | Cognome (CIFRATO), Nome (CIFRATO). Vedi nota (2) | XXXXX^XXXXX | ||
7 | 24 | DTM | R | Date/Time of Birth | Data di nascita nel formato aaaammgg | 19690420 | ||
8 | 1 | IS | R | Administrative sex | Table 0001 - Administrative Sex | Sesso del paziente | M | |
11 | 250 | XAD | O | Patient | Luogo di nascita del | ^^001272^^^100^B |
Address | paziente (CIFRATO). Vedi nota (3) | |||||||
21 | 250 | CX | O | Mother’s | Contiene in CX.1 il | |||
Identifier | codice fiscale | |||||||
(CIFRATO) del | ||||||||
genitore/tutore che ha | ||||||||
effettuato la richiesta | ||||||||
(riportare per intero anche | ||||||||
se CX.1 lungo 15) |
Nota (1)
Struttura campo CX PID-3
SEQ | LEN | DT | OPT | TBL | COMPONENT NAME | Note | |
1 | 15 | ST | R | ID Number | Codice (fiscale,locale,AURA,…). Il codice fiscale è lungo 16 caratteri, ma, anche se eccedente le dimensioni del campo, deve essere riportato per intero e CIFRATO | Esempio RSSMRI69A03L219D | |
5 | 5 | ID | R | Table 0203 - Identifier type | Identifier Type Code | Esempio NNITA |
Il campo è ripetibile.
Il codice fiscale (NNITA) è obbligatorio.
Esempi: RSSMRI69A03L219D^^^^NNITA
19827^^^^PZCE A92873^^^^PZLO
23456^^^^AURA
Nota (2)
Struttura campo XPN PID-5
SEQ | LEN | DT | OPT | TBL | COMPONENT NAME | Note |
1 | 194 | FN | R | Family Name | Cognome (CIFRATO) | |
2 | 30 | ST | R | Given Name | Nome (CIFRATO) |
Esempio:
XXXXX^XXXXX
Nota (3)
Struttura campo XAD PID-11
SEQ | LEN | DT | OPT | TBL | COMPONENT NAME | Note | |
3 | 50 | ST | R | ISTAT | City | Codice del Comune (CIFRATO) | |
6 | 3 | ID | R | ISTAT | Country | Codice dello stato (CIFRATO) | |
7 | 3 | ID | R | Table 0190 - Address type | Address type | Tipo di indirizzo |
Per il luogo di nascita devono essere valorizzati solo i campi 3 e 6.
Per pazienti nati all’estero l’istat di nascita deve essere composto da ‘999’ + il codice dello stato di nascita. Esempi:
^^001272^^^100^B
^^999257^^^257^B
Il campo PID.23 non va valorizzato.
2.11.5 Segmento PV1: Patient visit segment
Il segmento PV1 contiene i dati caratterizzanti l’episodio:
• tipologia dell’accesso del paziente,
• struttura e medico che effettua la prestazione,
• identificativo univo dell’episodio,
• informazioni sull’accettazione e dimissione del paziente.
VA R | SEQ | LE N | DT | OP T | ELEMENT NAME | TBL | NOTE | ESEMPIO |
2 | 1 | IS | R | Patient class | Table 0004 Patient class | Tipologia dell’episodio | E | |
3 | 80 | PL | O | Assigned patient location | Include le seguenti informazioni: - matricola della UP - matricola centro prelievo - tipologia struttura che ha prodotto il documento - Assetto Organizzativo - Tipologia di attività clinica Vedi nota (1). | |||
11 | 80 | PL | O | Temporary Locaton | ISTAT | Deprecato | ||
19 | 250 | CX | O | Visit Number | Identificativo dell'episodio. Può contenere per le diagnostiche il numero di passaggio della diagnostica per il pronto soccorso il numero di passaggio in pronto soccorso per la cartella clinica il numero di accesso in cartella clinica per la gestione del ricovero il numero di SDO Vedi nota (0) | 00000000000^^^^LIS | ||
21 | 2 | IS | O | Charge price indicator | 0032 | Valorizzare con il regime | SSN | |
C | 22 | 2 | IS | O | Courtesy Code | Questo campo è utilizzato per inviare informazioni aggiuntive sul documento. E’ significativo per i messaggi MDM | 1234567890$S$U$N$ DOC0001$N$36,50$0 $$0 |
di invio, aggiornamento/sostituzione e annullamento del documento 1)Codice PIN per lo scarico del documento da parte del cittadino, 2)l’indicazione se è un referto scaricabile via web, 3)l’indicazione del pagamento ticket sul documento ATTENZIONE: l’informazione del pagamento deve essere comunque inviata per tutte le tipologie di documento per rendere possibile lo scarico/visualizzazione del documento sia su ROL che su FSE. 4)il flag che indica se il documento contiene dati soggetti a leggi speciali quali per esempio sieropositività, aborti/ivg ecc. (vedi paragrafo vincoli sui dati da inviare). Se il tag viene valorizzato con ‘S’ allora il campo privacy deve essere valorizzato con 1 (ovvero il documento che contiene prestazioni ‘soggette a leggi speciali’ deve essere inviato come ‘oscurato ai professionisti sanitari’) 5)codice documento che identifica il documento da scaricare. 6)Flag che indica se il documento è oscurato per il cittadino in quanto un operatore sanitario che ha redatto il referto ha dichiarato che il documento non è scaricabile perché deve essere consegnato dal medico direttamente al cittadino. Il documento oscurato al cittadino diventerà ‘visibile’ dallo stesso quando un professionista sanitario effettua la ‘mediazione’ di tale documento (inoltrando così al FSEr l’aggiornamento di tale valore). Se il documento oscurato al cittadino è stato inviato anche come oscurato ai professionisti sanitari (valore privacy documento =1) questo documento non potrà essere visualizzato né dal cittadino né dal professionista sanitario (che dunque non potrà procedere con la mediazione dello stesso). | CodicePIN=12345678 90 Referto scaricabile=S Pagato ticket=N Leggi speciali=N Codice documento=DOC001 Oscurato per cittadino=M Importo ticket da pagare=36.50 Importo ticket pagato=0 privacyDocumentoFSE = 0 oscuramentoGenitore =N |
7)Importo ticket da pagare: Indica l’importo inteso in euro che deve essere ancora pagato dal paziente. Tale importo può essere nullo, pari a una parte o all’intero costo del ticket, rispettivamente a seconda che il paziente abbia già pagato tutto (o sia esente), abbia pagato parte del ticket o non abbia pagato nulla. Formato: numero decimale avente il carattere “.” come divisore e NON la “,”. Esempio: “21.50”. 8) Importo ticket Pagato. Indica l’importo inteso in euro che è già stato pagato dal paziente. . Formato: numero decimale avente il carattere “.” come divisore e NON la “,”. Vale l’equazione: Importo ticket da pagare =Importo tot.ticket – Importo ticket pagato 9)Scaricabile Senza Ticket Pagato (DEPRECATO) – inviare vuoto 10)Privacy documento FSE Le informazioni sono separate da un carattere $. 11)OscuramentoGenitore Indica se il documento del minorenne è oscurato al genitore. Per il pagamento ticket i valori ammessi sono: - S: pagato ticket - N: non pagato ticket - E: esente - P: pagamento parziale o incompleto - U: non definito/informazione non reperibile - R: rimborso (es.per rottura provetta). Il valore “R” NON DEVE essere inviato - in caso di aggiornamento dei metadati – se in un procedente invio era stato inviato “E” - F Free : Il valore “F” va indicato per |
tutti quei documenti che NON sono soggetti a pagamento da parte del cittadino (es Lettera di dimissione) Nel caso di invio di R il valore del campo Importo ticket da pagare deve essere negativo o nullo (es -5.00) Il flag che indica se il referto è scaricabile via web può valere: S –> scaricabile N -> non scaricabile Se il referto è scaricabile deve essere valorizzato anche il codice PIN. NOTA: il PIN generato non deve contenere il carattere $ Il flag che indica se il referto contiene dati soggetti a leggi speciali può valere: S-> se li contiene N-> se non li contiene Il codice che identifica il documento da scaricare è un codice che viene presentato al cittadino nella maschera per lo scarico dei referti affinché possa identificare il pin da utilizzare. Tale informazione è necessaria soprattutto nel caso in cui venga prodotto più di un documento a fronte di una richiesta esami e i documenti abbiano codice pin diverso. Questa informazione deve essere stampata anche sul foglio di promemoria consegnato al cittadino. Il flag di oscuramento per il cittadino (documento che richiede la mediazione del medico) può valere: S -> documento non visualizzabile dal cittadino, su richiesta di un operatore sanitario. Il documento non sarà disponibile per il Ritiro referti online (anche quando il documento verrà mediato e quindi impostato a M) N-> documento visualizzabile dal cittadino |
M-> il contenuto del documento è stato illustrato (ovvero mediato) da un medico al cittadino e quindi è visualizzabile dal cittadino su FSE ma non sarà disponibile per il Ritiro referti online Privacy documento FSE 0-> se il referto è visibile agli operatori sanitati 1 -> se il referto deve essere oscurato agli operatori sanitati Il campo privacyDocumento consente all’assistito di oscurare un documento a tutti i professionisti sanitari (esclusi i medici che hanno redatto o validato il referto) e ai delegati deboli(*). In questo caso non verranno restituiti neppure i metadati del documento. (*) L’assistito può delegate soggetti terzi alla consultazione del proprio fascicolo. I delegati, contrariamente ai professionisti sanitari, possono accedere al fascicolo sanitario del delegante anche se il consenso alla consultazione è negato. Il delegante può attribuire due tipologie di deleghe indicate come ‘delega debole’ o ‘delega forte’. Se la delega è di grado ‘debole’, il delegato non vedrà i documenti puntualmente oscurati. Se la delega è di grado ‘forte’ il delegato vedrà anche i documenti puntualmente oscurati. La delega genitore-minore è sempre di grado ‘forte’. I genitori pertanto vedranno anche i documenti oscurati puntualmente (ma non quelli oscurati al genitore). OscuramentoGenitore, i valori ammessi sono: S -> oscurato al genitore N o non valorizzato -> non oscurato al genitore Nel caso in cui il documento si riferisca ad un assistito minorenne e il campo OscuramentoGenitore non sia valorizzato verrà restituito un warning |
non bloccante. | ||||||||
24 | 2 | IS | O | Contract Code | Indica se l’inserimento è avvenuto a fronte di una richiesta di consenso al pregresso. Indicare S o N Se non valorizzato viene interpretato come X | X | ||
X | 00 | 0 | IS | O | Discharge Disposition | Table CSI 001 | Modalità di dimissione, da valorizzare nel caso di invio di lettera di dimissione o di verbale di pronto soccorso. | 0 |
44 | 24 | DT M | C | Admit Date/Time | Può contenere: 1. Data e ora di accettazione del ricovero, oppure 2. Data e ora della visita ambulatoriale, oppure 3. Data e ora di accesso al pronto soccorso. Nel formato aaaammgghhmm. | 200712041505 | ||
45 | 24 | DT M | C | Discharge Date/Time | Può contenere: 1. Data e ora di dimissione, oppure 2. Data e ora di uscita dal pronto soccorso. 3. Data e ora di chiusura della visita ambulatoriale Nel formato aaaammgghhmm. La data di dimissione/uscita/chiusura deve essere valorizzata ogni volta che l’episodio risulta concluso poiché tale valore condiziona la visibilità dei referti inviati. L’assenza di questa data determina la manca restituzione ai cittadini e ai medici dei metadati e del documento associato all’episodio in oggetto. Al momento, per limitare i disagi nella consultazione dei documenti, il vincolo sulla restituzione dei dati privi di data di dimissione è rimasto per i documenti associati ad un episodio di ricovero . I documenti associati ad un episodio di PS privi di data fine saranno visualizzati trascorsi tre giorni dalla data di inizio, mentre i documenti associati ad altri tipi di episodio che non siano episodio di ricovero o di PS sono mostrati anche se privi della data di fine | 200712041715 |
50 | 250 | CX | O | Alternate Visit ID | Identificativo che permette di associare in modo univoco l’episodio in questione con quello che ha originato la richiesta ; a seconda del tipo di episodio può corrispondere al Numero Nosologico del ricovero o al Numero di Passaggio PS. A seconda del richiedente può contenere: 1. In caso di episodio di pronto soccorso il numero di passaggio di pronto soccorso; 2. In caso di episodio di ricovero il numero di SDO; Vedi nota (0) | 000000000000^^^^PS |
(1) Struttura campo PL PV1-3
SEQ | LEN | DT | OPT | TBL | COMPONENT NAME | NOTE | ESEMPIO |
1 | 20 | IS | O | Point of care | Matricola (ARPE): - Nel caso di messaggio ADT^A01 è la matricola di accettazione/ammissione. - Nel caso di messaggio ADT^A03 è la matricola di dimissione. - Per i messaggi MDM è la matricola della struttura che produce il documento. Nel caso di Lettera di Dimissione è la matricola della struttura di dimissione | 2209 | |
2 | 20 | IS | O | Room | Codice che identifica la matricola (ARPE) che identifica il centro prelievi. | 2210 | |
4 | 227 | HD | C | Affinity Domain | Facility | Da inviare solo per i messaggi MDM^T02 e MDM^T10 In HD.2 concatenare (separati con $) - Tipologia struttura. Valore scelto tra i valori della Tab. 2.8-1 Affinity Domain Italia (opzionale). - Assetto organizzativo (Codifica della classificazione della pratica clinica o specialistica che ha portato alla creazione del documento). Sono ammessi | &Ospedale$AD_PSC00 1$CON |
i codici riportati nella tabella 2.13-1 Affinity Domain Italia (obbligatorio). - Tipo di attività clinica. Codice della tipologia di attività clinica/organizzativa che ha portato alla condivisione del documento. Sono ammessi i codici riportati nella tabella 3.1-1 dell’Affinity Domain Italia (obbligatorio). |
(2) Struttura campo CX PV1-19
VA R | SEQ | LEN | DT | OPT | TBL | COMPONENT NAME | NOTE | ESEMPIO |
1 | 15 | ST | R | ID Number | Identificativo dell’episodio, può contenere: 1 numero di passaggio di pronto soccorso; 2 numero di accesso in cartella clinica nel formato anno (yyyy) + numero; 3 numero di SDO; 4 identificativo richiesta anatomia patologica; 5 numero di accesso per la radiologia; 6 numero di accesso per il laboratorio analisi | 200800000014 3 | ||
5 | 5 | ID | O | Table 0363 – Assigning Autority | Identifier Type Code | Tipo di richiesta. E’ il codice dell’applicativo che ha generato l’identificativo. Usato per individuare il tipo di richiesta. | LIS |
Nota (4) Struttura campo CX PV1-50
SE Q | LE N | DT | OP T | TBL | COMPONENT NAME | NOTE | ESEMPIO |
1 | 15 | ST | R | ID Number | Può contenere: 1 numero di passaggio di pronto soccorso 2 numero di SDO | 2008000000143 | |
5 | 5 | ID | O | Table 0363 – Assigning Autority | Identifier Type Code | Tipo di richiesta. È il codice della tipologia di applicativo originante la richiesta che ha generato | PS |
DMA-CL-SRS-12-V32- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx | Novembre 2023 | uso: Esterno Pagina 37 di 62 |
l’identificativo, in particolare deve essere impostato con: 1. SDO se ID Number è un numero di SDO 2. PS se ID Number è un numero di passaggio di pronto soccorso |
Note:
la valorizzazione della sezione CX PV1-50 permette di far confluire nello stesso episodio di ricovero o di passaggio di PS i referti relativi a prestazioni ambulatoriali che vengono trasmessi con: un valore di identificativo dell’episodio (PV1-19) proprio e quindi diverso da quello dell’episodio di ricovero o di passaggio di PS, e un valore di tipo_episodio ‘uguale a O’.
Nel caso in cui i referti vengano inviati con lo stesso valore di identificativo dell’Episodio (PV1-19) del ricovero o del passaggio di PS, la loro riconduzione all’episodio è automatica e quindi non devono essere valorizzati i campi presenti nel CX PV1-50.
Per quanto riguarda l’invio da parte del dipartimentale a FSE, occorre tenere conto che la disponibilità del referto validato non coincide con l’evidenza del pagamento del ticket. Si deve pertanto inviare i referti appena disponibili (firmati/validati, con ticket pagato o meno) e successivamente – quando avviene segnalazione del pagamento – inviare nuovamente il documento comprensivo del metadato che dichiara l'avvenuto pagamento parziale o totale, fino al completamento del pagamento.
2.11.6 Segmento TXA: Transcription Document Header
Il segmento TXA contiene i dati caratterizzanti del documento:
tipologia, formato, stato e identificativo unico del documento, livello di validazione del documento e medici che hanno redatto e autenticato il documento.
La struttura del messaggio MDM^T02 prevede la presenza di un solo segmento TXA (e quindi, la specifica di un solo identificativo di documento), pertanto, nell’ipotesi che debbano essere inviati più documenti/referti, è necessario generare un messaggio MDM^T02 per ogni documento/referto.
VA R | SEQ | LEN | DT | OPT | TBL | COMPONENT NAME | NOTE | ESEMPIO |
1 | 4 | SI | R | Set ID- TXA | Dato non utilizzato, impostato ad “1”. | 1 | ||
2 | 30 | IS | R | Table 0270 – Document Type | Document Type | Tipologia del documento. In coerenza con le specifiche di interoperabilità INI il tipo documento deve essere codificato indicando la coppia di valori TipoDocumentoAlto, TipoDocumentoMedio. I valori vanno separati con $ | REF$68604-8 |
Vedi Nota (4) | ||||||||
3 | 2 | ID | C | Table 0191 – Type Of Referenced Data | Document Content Presentation | E’ il formato dell’allegato, qualora esso sia presente nel messaggio. Nota 1: i valori della tabella sono stati cambiati Nota 2: Non valorizzare in caso di annullamento (messaggio MDM^T11) | PD | |
7 | 24 | DTM | C | Transcription Date/Time | Indica, nel caso di un referto, la data di disponibilità per lo scarico da parte del cittadino che effettui la consultazione La data è nel formato aaaammgg | |||
9 | 250 | XCN | R | Tab CSI 003 - Ruoli | Originator Code/Name | Lista dei medici che redigono il documento Per quanto riguarda l’autore del documento occorre indicare obbligatoriamente il Codice fiscale e opzionalmente il suo ruolo Vedi Nota (1) | CF^Xxxxx^Xxxxx^^^^^ ^DRS~^CF^Xxxxxxx^ Xxxx^^^^^^DRS | |
12 | 427 | EI | R | Unique | Contiene l’identificativo | 2.16.840.1.113883.2.9 | ||
Document | del repository che | .2.10.4.5.1020112345 | ||||||
Number | custodisce il documento, | 678198237^^ | ||||||
nel caso risieda presso | 2.16.840.1.113883.2.9 | |||||||
l’azienda (dovrà essere | .2.10.4.4.1020100000 | |||||||
valorizzato per le Aziende | 000000000000000123 | |||||||
che aderiranno al nuovo | 40088 | |||||||
modello in conformità alle | ||||||||
specifiche previste | ||||||||
dall’inter-operabilità | ||||||||
nazionale) | ||||||||
E’ seguito dal numero | ||||||||
univoco del documento | ||||||||
generato/gestito | ||||||||
dall’entità organizzativa | ||||||||
responsabile dell’invio | ||||||||
delle informazioni. | ||||||||
Al fine di adeguarsi al | ||||||||
modello nazionale, il dato | ||||||||
deve essere generato | ||||||||
esclusivamente secondo la | ||||||||
codifica OID di HL7, che |
prevede l’utilizzo del ramo degli identificativi dei documenti della Regione Piemonte. In tal modo l’identificativo sarà univoco a livello regionale. Il formato sarà: 2.16.840.1.113883.2.9.2.1 0.4.4.X Vedi nota (3) | ||||||||
13 | 427 | EI | C | Parent | Numero univoco del | ^^198256 | ||
Document | documento | |||||||
Number | che deve essere sostituito | |||||||
Il campo potrà contenere | 2.16.840.1.113883.2.9 | |||||||
sia il vecchio | .2.10.4.5.1020112345 | |||||||
identificativo, se si deve | 678198237^^ | |||||||
agire su un documento | 2.16.840.1.113883.2.9 | |||||||
trasmesso con le vecchie | .2.10.4.4.1020100000 | |||||||
modalità, che | 000000000000000123 | |||||||
l’identificativo con il | 40088 | |||||||
nuovo formato (Nota 3) | ||||||||
14 | 427 | EI | O | Placer Order Number | Inserire - NRE (l’elenco dei numeri di ricetta elettronica delle ricette dematerializzate prescritte che hanno portato alla generazione del documento/refert o). In EI.3:codice NRE - In EI.4 tipo: NRE | ^^01010100002^NRE | ||
Il campo è ripetibile in caso vi siano più NRE | ||||||||
15 | 427 | EI | R | Filler Order Number | - Hash del documento in EI.1 (anche se la lunghezza supera i 199 caratteri) | ab123……e345^^134 5 | ||
- Dimensione del documento (EI.3) | ||||||||
17 | 2 | ID | R | Table 0271 – Document Completion | Document Completion Status | Livello di completamento del documento. Gli unici valori dello stato | LA |
Status | presi in esame sono quelli che indicano che il documento è stato validato manualmente o legalmente. | |||||||
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 e il ruolo . Vedi nota (2) | CF^Xxxxx^Xxxxx^^^^^ ^PLS^^^^^^20071204 1032~CF^Bianchi^Lu ca^^^^^^PLS^^^^^^2 00712041100 |
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) | ||
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 | ||
2 | 194 | FN | O | Family name | Xxxxxxx | Xxxxx | |
3 | 30 | ST | O | Given name | Nome | Xxxxx | |
9 | 227 | HD | O | Tab CSI 003 | Assigning Authority | Ruolo del medico validatore del | DRS |
DMA-CL-SRS-12-V32- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx | Novembre 2023 | uso: Esterno Pagina 41 di 62 |
documento | |||||||
15 | 24 | DT M | O | Date/Time Action Performed | Data e ora dell’autenticazione nel formato aaaammgghhmm | 20071204103 2 |
Nota (3) Formato dell’Identificativo Univoco del documento e del repository
Per essere univoco a livello regionale e al fine di adeguarsi al modello di interoperabilità nazionale, l’identificativo deve essere codificato con un OID univoco all’interno Azienda secondo il formato 2.16.840.1.113883.2.9.2.10.4.4.X, dove:
• 2.16.840.1.113883.2.9.2.10.4.4. è il ramo degli OID HL7 Italia per gli identificativi dei documenti della Regione Piemonte (31 caratteri compresi i punti)
• X rappresenta uno specifico documento della Regione Piemonte, composto da 33 caratteri secondo il formato TTAAAN...N dove:
o TT = è il codice tipo struttura, da valorizzare con: “10” per strutture pubbliche,
“11” per strutture private equiparate “12” per le altre strutture private
o AAA = identificativo azienda per le aziende pubbliche oppure il codice assegnato dalla ASL sul progetto ARPE per le aziende private
N...N = numero univoco all’interno dell’azienda, con un massimo di 28 caratteri numerici Es. 2.16.840.1.113883.2.9.2.10.4.4.102010000000000000000000012340088.
Nel caso di invio a fronte di un RECUPERO PREGRESSO (campo PV1.24=S) in questo campo occorre inserire:
1. OID del documento (come su indicato) nel caso il documento che si sta inviando, a seguito del recupero pregresso, è stato generato da subito per il fascicolo con la codifica OID e non con altre codifiche (ovvero quelle utilizzate con la versione del connettore antecedente l'integrazione con INI)
2. OID del documento + $ + codice documento originario nel caso il documento che si sta inviando, a seguito del recupero del pregresso, è stato inizialmente generato per il fascicolo con un'altra codifica (ovvero quelle utilizzate con la versione del connettore antecedente l'integrazione con INI)
Esempio 1:
TXA.12 EI.3 valorizzato con 2.16.840.1.113883.2.9.2.10.4.4.10301000000012345 per un documento che è stato associato da sempre all'OID
Esempio 2:
TXA.12 EI.3 valorizzato con 2.16.840.1.113883.2.9.2.10.4.4.1030100000006789$ABC123XY per un
documento che inizialmente era stato codificato per il fascicolo con il codice ABC123XY
L’identificativo del repository del documento inviato deve avere il seguente formato: 2.16.840.1.113883.2.9.2.10.4.5.X
dove
• 2.16.840.1.113883.2.9.2.10.4.5 indica il ramo degli OID HL7 Italia per gli identificativi dei repository della Regione Piemonte (31 caratteri compresi i punti)
• X indica uno specifico repository dell’Azienda ed è costituito da un codice nel formato TTAAARRRRRRRR, dove:
o TT = codice tipo struttura, da valorizzare con “10” per strutture pubbliche
“11” per strutture private equiparate “12” per le altre strutture private
o AAA= identificativo Azienda per le aziende pubbliche oppure il codice Azienda titolare assegnato dalla ASL di competenza sul progetto ARPE per le Aziende private
o RRRRRRRR = identificativo del repository (al massimo 8 caratteri numerici)
Nota (4) Essendo fisso il valore previsto per il Tipo Documento Basso, in fase di alimentazione del fascicolo, sono consentiti i valori riportati nelle tabelle seguenti:
TipoDocumentoAlto
Codice | Descrizione |
REF | Referto |
LDO | Lettera di Dimissione Ospedaliera |
SUM | Summary |
TAC | Taccuino |
PRS | Prescrizione |
ESE | Esenzione |
XXX | Xxxxxxxxx |
TipoDocumentoMedio
Codice | Descrizione |
11502-2 | Referto di Laboratorio |
34105-7 | Lettera di dimissione ospedaliera |
59258-4 | Verbale di pronto soccorso |
68604-8 | Referto radiologico |
11526-1 | Referto di anatomia patologica |
11488-4 | Referto specialistico |
REG-80755-2 | PT delle malattie renali croniche e insufficienza renale |
REG-80774-3 | PT delle malattie reumatiche croniche |
REG-80744-6 | PT delle malattie intestinali croniche |
REG-77442-2 | PT delle malattie cardiovascolari croniche |
REG-80761-0 | PT delle malattie neurodegenerative |
REG-80796-6 | PT delle malattie respiratorie croniche |
REG-80772-7 | PT dell’insufficienza respiratoria in età evolutiva |
REG-68782-2 | PT dell’asma in età evolutiva |
REG-68894-5 | PT delle malattie endocrine in età evolutiva |
REG-68867-1 | PT delle malattie renali croniche in età evolutiva |
REG-18776-5 | PT (altro) |
REG-87273-9 | Scheda Vaccinale |
REG-82593-5 | Certificato Vaccinale |
60591-5 | Patient Summary |
REG-81334-5 | Piano di cura personalizzato |
I valori di tipo documento Medio e tipo documento Alto devono essere valorizzati in modi coerente.
La tabella che segue indica la relazione tra i valori da riportare nei tag tipologiaDocumentoAlto e tipologiaDocumentoMedio:
Codice tipoDocumentoAlto | Descrizione tipo documento alto | Codice tipoDocumentoMedio | Descrizione tipo documento medio |
REF | Referto | 11502-2 | Referto di Laboratorio |
LDO | Lettera di dimissione ospedaliera | 34105-7 | Lettera di dimissione ospedaliera |
REF | Referto | 59258-4 | Verbale di pronto soccorso |
REF | Referto | 68604-8 | Referto di radiologia |
REF | Referto | 11526-1 | Referto di anatomia patologica |
REF | Referto | 11488-4 | Referto specialistico |
XXX | Xxxxxxxxx | REG-80755-2 | PT delle malattie renali croniche e insufficienza renale |
XXX | Xxxxxxxxx | REG-80774-3 | PT delle malattie reumatiche croniche |
XXX | Xxxxxxxxx | REG-80744-6 | PT delle malattie intestinali croniche |
XXX | Xxxxxxxxx | REG-77442-2 | PT delle malattie cardiovascolari croniche |
XXX | Xxxxxxxxx | REG-80761-0 | PT delle malattie neurodegenerative |
XXX | Xxxxxxxxx | REG-80796-6 | PT delle malattie respiratorie croniche |
XXX | Xxxxxxxxx | REG-80772-7 | PT dell’insufficienza respiratoria in età evolutiva |
XXX | Xxxxxxxxx | REG-68782-2 | PT dell’asma in età evolutiva |
XXX | Xxxxxxxxx | REG-68894-5 | PT delle malattie endocrine in età evolutiva |
XXX | Xxxxxxxxx | REG-68867-1 | PT delle malattie renali croniche in età evolutiva |
XXX | Xxxxxxxxx | REG-18776-5 | PT (altro) |
REF | Referto | REG-87273-9 | Scheda Vaccinale |
SUM | Summary | REG-82593-5 | Certificato Vaccinale |
SUM | Summary | 60591-5 | Patient Summary |
SUM | Summary | REG-59283-2 | Bilancio di salute |
SUM | Summary | REG-81334-5 | Piano di cura personalizzato |
Esempio: REF^68604-8
2.11.7 Segmento OBX: Observation Segment
Il segmento OBX contiene i dati strutturati ed eventuale documento (base64).
VA R | SEQ | LEN | DT | OPT | TBL | COMPONENT NAME | NOTE | ESEMPIO |
1 | 4 | SI | R | Set ID- OBX | Numero da sequenza dell’obx: se nel messaggio ci sono più OBX, ognuno avrà un id crescente. | 1 |
DMA-CL-SRS-12-V32- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx | Novembre 2023 | uso: Esterno Pagina 44 di 62 |
2 | 3 | ID | R | Table – 0125 Value Type | Value Type | Specifica il tipo di OBX. | ED | |
C | 3 | 705 | CWE (ex CE) | R | Table 0270 – Documnt type | Observation Identifier | E’ l’identificativo univoco dell’observation (OBX): 1 per le prestazioni è costituito dal codice prestazione secondo la codifica prevista dal Catalogo Regionale e dal codice branca regionale su cui è stata erogata la prestazione. Vedi nota (1). 2 Per le codifiche previste da INI nell’eventCodeList dell’Affinity Domain Italia per ulteriore specificazione associata al documento. Vedi nota (1). 3 per il tipo ED (quindi l’observation contiene un referto) contiene la tipologia di documento medio che deve corrispondere al tipo documento medio riportato nel segmento TXA 4 Per il tipo RP (senza invio di documento) indicare il tipo documento medio riportato nel segmento TXA Nota (1) | |
4 | 20 | ST | C | Observation Sub-ID | Deprecato | |||
5 | * | * | C/R | Observation Value | Valore dell’informazione contenuta nell’OBX o valore dell’esame. Nel caso di un allegato, sarà il contenuto dell’allegato (CIFRATO) in formato base64 utilizzando il tipo ED. Nel secondo sottocampo viene riportata una eventuale nota sul risultato. Per il tipo OBX.2 è RP rappresenta (OBX-5.1) l’accession number utilizzato per reperire le immagini nel caso vi sia l’integrazione con i | 15^Nota risultato |
DMA-CL-SRS-12-V32- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx | Novembre 2023 | uso: Esterno Pagina 45 di 62 |
PACS dell’Azienda, il tipo di dato (OBX-5.3) ed il subtipo (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 - | LP418019-8 |
DMA-CL-SRS-12-V32- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx | Novembre 2023 | uso: Esterno Pagina 46 di 62 |
Tabella 2.7-1 dell’Affinity Domain Italia. | ||||||||
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. (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-V32- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx | Novembre 2023 | uso: Esterno Pagina 47 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 (documento/referto nel repository aziendale)
SEQ | LEN | DT | OPT | TBL | COMPONENT NAME | NOTE | ESEMPIO |
3 | 11 | ID | R | Table 0191 - Type Of Referenced Data | Type of Data | RIF |
Esempi di utilizzo del segmento OBX per invio di doc base 64 OBX|1|ED|11502-2||^multipart^Octet-stream^Base64^JVBER…j6IKOCA
DMA-CL-SRS-12-V32- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx | Novembre 2023 | uso: Esterno Pagina 48 di 62 |
Altri esempi di utilizzo del segmento OBX. (anche in caso di invio senza referto)
Esempio 1. Sono state erogate due prestazioni (visita e prick) e ad esse, è associato un solo referto:
OBX|1|ED|11502-2||^multipart^Octet-stream^Base64^JVBER…j6IKOCA OBX|2|CE|90.62.2^^CATREG^98||||||||F||1|201903060930 OBX|3|CE|90.82.5^^CATREG^98||||||||F||1|201903060930
Esempio 2. È stata erogata una prestazione e ad essa è associato un riferimento ad un’immagine DICOM ed un referto codificato in base64 il cui testo supera 65536 byte:
OBX|1|ED|68604-8|1|< referto con dimensione superiore a 65536> OBX|2|RP||1|ACCNUM0001^^IM^DICOM||||||F
OBX|3|CE| 89.71^^CATREG^08||||||||F||1|201903060930
Esempio 3. È stata erogata una prestazione e ad essa è associato un documento conservato nel dipartimentale (per invio senza referto)
OBX|1|RP| |1|^^RIF^||||||F OBX|2|CE|89.71^^CATREG^08|1|||||||F||1|200703060930
I valori dei risultati degli esami di laboratorio di analisi non devono essere più comunicati.
2.11.8 Segmento MSA: Message Acknowledgment Segment
SEQ | LEN | DT | OPT | TBL | COMPONENT NAME | NOTE | ESEMPIO |
1 | 2 | ID | R | Table 0008 Acknowledgement code | Acknowledgment Code | Messaggio elaborato correttamente o errore | AA |
2 | 20 | ST | R | Message Control ID | Identificativo unico del messaggio, generato dall’inviante, cui l’ACK è riferito. | 34 |
2.11.9 Segmento ERR: Error segment
SEQ | LEN | DT | OPT | TBL | COMPONENT NAME | NOTE | ESEMPIO |
3 | 705 | CWE | R | Table 0357 | HL7 Error Code | Codice di errore XX0 | 000 |
0 | 0 | XX | R | Table 0516 | Severity | ||
5 | 705 | CWE | O | Table 0533 | Application Error Code | Codice e descrizione di errore generato dell’applicativo che risponde | FSE_ER_121^ Non esiste il codice della branca regionale del documento |
DMA-CL-SRS-12-V32- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx | Novembre 2023 | uso: Esterno Pagina 49 di 62 |
(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 |
Il presente capitolo descrive tutte le tabelle di codifica utilizzate nel progetto.
2.12.1 Table 0001 - Administrative Sex
Sesso del paziente.
Codice | Descrizione | Descrizione d’uso |
F | Female | Femmina |
M | Male | Maschio |
U | Unknown | Sconosciuto |
2.12.2 Table 0004 – Patient Class
Provenienza del paziente.
Codice | Descrizione | Descrizione d’uso |
E | Emergency | Dati relativi ad un episodio Pronto Soccorso (PS/DEA) |
I | Inpatient | Dati relativi a un episodio di ricovero (RO, DH, DS) |
O | Outpatient | Dati relativi ad un episodio ambulatoriale (AMB) o collegato ad un episodio di ricovero o di pronto soccorso |
2.12.3 Table 0008 Acknowledgement code
Ditta inviante o ricevente.
Codice | Descrizione | Descrizione d’uso |
AA | Application Accept | Il messaggio è stato correttamente processato |
AE | Application Error | Si è verificato un errore sintattico |
CE | Commit Error | Si è verificato un errore sul DBMS |
2.12.4 Table 0076 - Message Type - e Table 0003 Event Type
Tipo di messaggio.
Codice | Descrizione | Descrizione d’uso |
ADT^A01^ADT_A01 | ADT^A01^ADT_A01 | Utilizzato nel messaggio “Notifica dell’accettazione dell’episodio” |
ACK^A01^ACK | ACK^A01^ACK | Acknowlwdge a ADT^A01 |
ADT^A03^ADT_A03 | ADT^A03^ADT_A03 | Utilizzato nel messaggio “Notifica della dimissione di un paziente ricoverato” |
ACK^A03^ACK | ACK^A03^ACK | Acknowlwdge a ADT^A03 |
ADT^A11^ADT_A09 | ADT^A11^ADT_A09 | Utilizzato nel messaggio “Notifica dell’annullamento dell’episodio” |
ACK^A11^ACK | ACK^A11^ACK | Acknowlwdge a ADT^A11 |
MDM^T02 | MDM^T02 | Utilizzato nel messaggio “Notifica della creazione del documento” |
ACK^T02^ACK | ACK^T02^ACK | Acknowlwdge a MDM^T02 |
MDM^T10 | MDM^T10 | Utilizzato nel messaggio “Notifica della sostituzione del documento” |
ACK^T10^ACK | ACK^T10^ACK | Acknowlwdge a MDM^T10 |
MDM^T11 | MDM^T11 | Utilizzato nel messaggio “Notifica dell’annullamento del |
documento” |
2.12.5 Table 0085 - Observation result status codes interpretation
Codifica dello stato del segmento OBX (dato strutturato oppure documento).
Codice | Descrizione | Descrizione d’uso |
Identificativi HL7 | ||
F | Final results; Can only be changed with a corrected result. | Stato del dato/informazione e del documento inviato per la prima volta. |
C | Record coming over is a correction and thus replaces a final result | Stato che indica che il valore che viene inviato è stato modificato. |
D | Deletes the OBX record | Stato che indica la cancellazione del dato. |
B | Appended Report - Final results reviewed and further information provided for clarity without change to the original result values. | Stato che indica l’invio di informazioni aggiuntive (addendum) senza modifica dei dati precedentemente comunicati |
2.12.6 Table 0000 - Xxxxxxxxxx XX
Definisce in quale ambiente è stato costruito il messaggio. Il valore utilizzato è fisso.
Codice | Descrizione | Descrizione d’uso |
Identificativi HL7 | ||
P | Production | Produzione |
2.12.7 Table 0123 - Result Status
Codifica dello stato del segmento OBR (episodio).
Codice | Descrizione | Descrizione d’uso |
Identificativi HL7 | ||
F | Final results; results stored and verified. Can only be changed with a corrected result. | Stato dell’episodio che viene inviato per la prima volta. |
X | No results available; Order canceled. |
2.12.8 Table 0125 – Value Type
Tipologia del dato caratterizzato all’interno di un OBX.
Codice | Descrizione | Descrizione d’uso |
Identificativi HL7 | ||
CE | Coded Entry (mantenuto per retrocompatibilità) | Utilizzato per registrare dati codificati: prestazioni |
CWE | Coded Entry | Utilizzato per registrare dati codificati: prestazioni |
ED | Encapsulated Data | Utilizzato per allegare documenti nei formati previsti. |
RP | Reference Pointer | Utilizzato per inviare l’informazione dell’accession number. Qualora il sistema non invii il documento e nessuna altra informazione, poiché il segmento OBX è obbligatorio nei messaggi MDM utilizzare la codifica RP indicando la tipologia del documento (vd. campo OBX.3 ) |
2.12.9 Table 0190 - Address type
Tipo di indirizzo.
Codice | Descrizione | Descrizione d’uso |
DMA-CL-SRS-12-V32- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx | Novembre 2023 | uso: Esterno Pagina 52 di 62 |
Identificativi HL7 | ||
B | Birth | Luogo di nascita |
2.12.10 Table 0191 – Type Of Referenced Data
Specifica il formato e il tipo di firma (se presente) dell’allegato; l’informazione è presente nel segmento TXA; il testo del referto/documento è presente nel segmento OBX.
Codice | Descrizione | Ambito di validità | Descrizione d’uso |
Identificativi HL7 | |||
multipart | MIME multipart package | OBX | usato per i documenti |
Identificativi (estensione CSI) | |||
IM | Image Data | OBX | Usato per l’invio dell’accession number al fine di reperire le immagini radiologiche |
PD | 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 modo coerente. Le codifiche riportate seguono le specifiche previste dal progetto di interoperabilità nazionale riportate nel documento di Affinity Domain Italia.
TipoDocumentoAlto (Tabella 2.3-1 dell’Affinity Domain Italia)
Codice | Descrizione | |
REF | Referto | |
LDO | Lettera di Dimissione Ospedaliera |
Tipo Documento Medio (Tabella 2-19-1 dell’Affinity Domain Italia)
Codice | Descrizione | Corripondenza con vecchio valore (deprecato) |
11502-2 | Referto di Laboratorio | REFERTO_LIS: Referto di laboratorio di analisi |
34105-7 | Lettera di dimissione ospedaliera | LET_DIMISSIONE: Lettera di dimissione |
59258-4 | Verbale di pronto soccorso | DEA_VERBALE: Xxxxxxx di pronto soccorso |
68604-8 | Referto radiologico | REFERTO_RIS: Referto di radiologia |
11526-1 | Referto di anatomia patologica | REFERTO_AP: Referto di anatomia patologica |
11488-4 | Referto specialistico | REFERTO: Referto |
ATTO_OPERATORIO | Atto operatorio (Codice Regionale) | ATTO_OPERATORIO |
- | - | DEA_TRIAGE (DEPRECATO) |
- | - | ANAMNESI (DEPRECATO |
- | - | SDO (DEPRECATO) |
- | - | REFERTO_CICLO (DEPRECATO) |
La tabella che segue indica la relazione tra i valori di Tipo Documento Alto e Tipo Documento Medio:
Codice tipologiaDocumentoAlto | Descrizione tipo documento alto | Codice tipologiaDocumentoMedio | Descrizione tipo documento medio |
REF | Referto | 11502-2 | Referto di Laboratorio |
LDO | Lettera di dimissione ospedaliera | 34105-7 | Lettera di dimissione ospedaliera |
REF | Referto | 59258-4 | Verbale di pronto soccorso |
REF | Referto | 68604-8 | Referto di radiologia |
REF | Referto | 11526-1 | Referto di anatomia patologica |
REF | Referto | 11488-4 | Referto specialistico |
2.12.13 Table 0271 - Document Completion Status
Stato di completezza del documento; l’informazione è contenuta nel segmento TXA.
Codice | Descrizione | Descrizione d’uso |
Identificativi HL7 | ||
AU | Authenticated | Autenticato |
LA | Legally authenticated | Firmato |
2.12.14 Table 0272 - Document Confidentiality Status
Livello di riservatezza del documento.
Codice | Descrizione | Descrizione d’uso |
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 |
Codifica; usato per i documenti.
Codice | Descrizione | Descrizione d’uso |
Identificativi XX0 | ||
Xxxx00 | Encoding as defined by MIME standard RFC 1521 | usato per i pdf |
2.12.17 Table 0357 – Message error condition codes
Codice | Descrizione | Descrizione d’uso |
0 | Message accepted | Success. Optional, as the AA conveys success. Used for systems that must always return a status code. |
100 | Segment sequence error | Error: The message segments were not in the proper order, or required segments are missing. |
101 | Required field missing | Error: A required field is missing from a segment |
102 | Data type error | Error: The field contained data of the wrong data type, e.g. an NM field contained "FOO". |
103 | Table value not found | Error: A field of data type ID or IS was compared against the corresponding table, and no match was found. |
200 | Unsupported message type | Rejection: The Message Type is not supported. |
201 | Unsupported event code | Rejection: The Event Code is not supported. |
202 | Unsupported processing id | Rejection: The Processing ID is not supported. |
203 | Unsupported version id | Rejection: The Version ID is not supported. |
204 | Unknown key identifier | Rejection: The ID of the patient, order, etc., was not found. Used for transactions other than additions, e.g. transfer of a non-existent patient. |
205 | Duplicate key identifier | Rejection: The ID of the patient, order, etc., already exists. Used in response to addition transactions (Admit, New Order, etc.). |
206 | Application record locked | Rejection: The transaction could not be performed at the application storage level, e.g., database locked. |
207 | Application internal error | Rejection: A catchall for internal errors not explicitly covered by other codes. |
In caso di errore non dovuto al formato HL7 verrà inviato 207.
2.12.18 Table 0361 –Application
Dipartimentale inviante o ricevente.
Codice | Descrizione | Descrizione d’uso |
Identificativi CSI | ||
DOSSIER oppure FSATO2 (per retrocompatibilità con TO2) | Componente Locale del FSE | |
HIS_DEA | Pronto soccorso ex ASL4 | |
HIS_AMB | Cartella clinica allergologia e pneumologia ex ASL 4 | |
PATO2000 | Anatomia patologica ex ASL4 | |
INFOCLIN1 | Cartella clinica di cardiologia | Prima installazione |
INFOCLIN2 | Cartella clinica di cardiologia | Seconda installazione |
IE-DEA | Pronto soccorso ex ASL 3 | |
INFOCLIN | Cartella clinica di cardiologia | |
ADTWEB | ADT ESEL | |
OPENLIS | LIS ESEL | |
XXXXX | SIT ESEL | |
XMPI | Anagrafe centrale ESEL | |
WINSAP | Anatomia patologica ESEL | |
DNLAB | LIS NOEMALIFE | |
IMAGOWEB | Radiologia Elco | |
GALENUS | Cartella Clinica Nefrologia e Dialisi Infogramma | |
ORMAWIN | Blocco Operatorio Avelco | |
DNLAB.NOEMALIFE .201.01 | NOEMALIFE ASL TO1 | |
DNLAB.NOEMALIFE .205.01 | NOEMALIFE ASL TO5 | |
TO4TRAK | TRAKCARE ASL TO4 | |
Per l’FSE la regola per comporre il codice dell’applciazione inviante è la seguente:
<nome applicativo>.<fornitore>.<ASL/ASO>.<NN> dove:
<nome applicativo> nome applicativo inviante
<fornitore> fornitore dell'applicativo
<ASL/ASO> codice dell'Azienda
<NN> è un progressivo per distinguere le installazioni dell'applicativo se presso l'Azienda ce ne fossero più di una
Nelle stringhe dei nomi solo lettere e numeri. Esempio: DOSSIER.GPI.906.01
L’entità organizzativa responsabile dell’invio o della ricezione delle informazioni. CODICE ASR INVIANTE. Per i privati rappresenta la ASR indicata sul sistema AURA
Codice | Descrizione | Descrizione d’uso |
Identificativi CSI | ||
203 | X.X.X. XXXXXX 0 | |
000 | X.X.X. XXXXXX 4 | |
205 | X.X.X. XXXXXX 0 | |
000 | X.X.X. XXXXXXXX | |
207 | X.X.X. XXXXXX | |
000 | X.X.X. XXXXXX | |
209 | A.S.L. VERBANO-CUSIO-OSSOLA | |
210 | A.S.L. CUNEO 1 | |
211 | A.S.L. CUNEO 2 | |
212 | A.S.L. ASTI | |
213 | X.X.X. XXXXXXXXXXX | |
000 | X.X.X. XXXXX' XX XXXXXX | |
904 | AZIENDA OSP. S.XXXXX | |
905 | AZIENDA OSP. MAGGIORE DELLA CARITA' | |
906 | AZIENDA OSP. X.XXXXX E CARLE | |
907 | AZIENDA OSP. S.XXXXXXX XXXXXX/XXXXXX | |
908 | AZIENDA OSP. ORDINE MAURIZIANO DI TORINO | |
909 | AZIENDA OSP. CITTA DELLA SALUTE E DELLA SCIENZA DI TORINO |
2.12.20 Table 0363 – Assigning authority
Applicativo che genera il codice, usato per individuare il tipo del codice di richiesta.
Codice | Descrizione | Descrizione d’uso |
Identificativi CSI | ||
PS | Pronto soccorso | |
SDO | Gestione ricovero | |
CC | Cartella clinica | |
AP | Anatomia patologica | |
LIS | Laboratorio analisi | |
RIS | Radiologia |
2.12.21 Table 0396 – Coding system table
Sistemi di codifica utilizzati per caratterizzare le informazioni (prestazioni, etc).
Codice | Descrizione | Descrizione d’uso |
99zzz | Local general code (where z is an alphanumeric character) | 99CDO: codifica CSI per i tipi di documenti 99RPR: codifica catalogo regionale della prestazione |
LN | LOINC | |
I9C | ICD-9CM - Commission on Professional and Hospital Activities, 0000 Xxxxx Xxxx, Xxx Xxxxx, XX 00000 (includes all |
DMA-CL-SRS-12-V32- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7.docx | Novembre 2023 | uso: Esterno Pagina 57 di 62 |
procedures and diagnostic tests). |
2.12.22 Table 0516 – Error severity
Livello di gravità dell’errore.
Codice | Descrizione | Descrizione d’uso |
W | Warning | Transaction successful, but there may be issues |
I | Information | Transaction was successful but includes information e.g., inform patient |
E | Error | Transaction was unsuccessful |
In caso di comunicazione di errore verrà inviato E.
2.12.1 Table CSI 001 – modalità di dimissione
Codice | Descrizione |
0 | ricoverato nella stessa struttura |
1 | deceduto |
2 | dimissione a domicilio |
5 | rifiuta il ricovero |
6 | trasferito ad altra struttura di ricovero |
7 | trasferito in altra struttura (RSA - RAF - Ospedale di comunità, ecc.) |
8 | trasferito in altro Pronto Soccorso della stessa Azienda |
A | solo accesso, senza erogazione di prestazioni |
M | solo accesso, senza erogazione di prestazioni, seguito da parte del MMG presente in pronto soccorso |
2.12.2 Table CSI 003 – Ruolo Utente (Tabella 4.1-1 dell’Affinity Domain)
L’informazione è riportata nel segmento EVN e TXA
Codice | Descrizione | Mappatura con ruoli del DPCM sul FSE |
AAS | Personale di assistenza ad alta specializzazione | Medico / Dirigente sanitario |
APR | Medico Medicina Generale Pediatra di Libera Scelta | Medico di Medicina Generale / Pediatra di Libera Scelta |
PSS | Professionista del sociale | Professionista del sociale |
INF | Personale infermieristico | Infermiere o altro Professionista Sanitario |
OAM | Operatore amministrativo | Operatore Amministrativo |
DRS | Dirigente sanitario | Medico / Dirigente sanitario |
RSA | Medico RSA | Medico RSA |
MRP | Medico Rete di Patologia | Medico Rete di Patologia |
2.12.3 Table 0119 - Order control codes
Definisce in quale ambiente è stato costruito il messaggio. Il valore utilizzato è fisso.
Codice | Descrizione | Descrizione d’uso |
Identificativi HL7 | ||
NW | New order/service | Nuova richiesta di xxxxx accettata dal LIS |
2.12.4 Table 2.8-1 Affinity Domain – Facility TypeCode
Code | DisplayName | Descrizione |
Ospedale | Ospedale | Indica che il documento è stato prodotto a seguito di un ingresso ospedaliero del paziente |
Prevenzione | Prevenzione | Indica che il documento è stato prodotto a seguito di uno screening o di medicina preventiva |
Territorio | Territorio | Indica che il documento è stato prodotto a seguito di un incontro con uno specialista territoriale (MMG / PLS / Medico RSA, ecc.) |
2.12.5 Table 2.13-1 Affinity Domain –Assetto organizzativo / Pratica Clinica o specialistica
Codice | Descrizione |
AD_PSC001 | Allergologia |
AD_PSC002 | Day Hospital |
AD_PSC003 | Anatomia e Istologia Patologica |
AD_PSC005 | Angiologia |
AD_PSC006 | Cardiochirurgia Pediatrica |
AD_PSC007 | Cardiochirurgia |
AD_PSC008 | Cardiologia |
AD_PSC009 | Chirurgia Generale |
AD_PSC010 | Chirurgia Maxillo-facciale |
AD_PSC011 | Chirurgia Pediatrica |
AD_PSC012 | Chirurgia Plastica |
AD_PSC013 | Chirurgia Xxxxxxxx |
AD_PSC014 | Chirurgia Vascolare |
AD_PSC015 | Medicina Sportiva |
AD_PSC018 | Ematologia e Immunoematologia |
AD_PSC019 | Malattie Endocrine, del Ricambio e della Nutrizione |
AD_PSC020 | Immunologia |
AD_PSC021 | Geriatria |
AD_PSC024 | Malattie Infettive e Tropicali |
AD_PSC025 | Medicina del Lavoro |
AD_PSC026 | Medicina Generale |
AD_PSC027 | Medicina Legale |
AD_PSC028 | Unita Spinale |
AD_PSC029 | Nefrologia |
AD_PSC030 | Neurochirurgia |
AD_PSC031 | Nido |
AD_PSC032 | Neurologia |
AD_PSC033 | Neuropsichiatria Infantile |
AD_PSC034 | Oculistica |
AD_PSC035 | Odontoiatria e Stomatologia |
AD_PSC036 | Ortopedia e Traumatologia |
AD_PSC037 | Ostetricia e Ginecologia |
Codice | Descrizione |
AD_PSC038 | Otorinolaringoiatria |
AD_PSC039 | Pediatria |
AD_PSC040 | Psichiatria |
AD_PSC042 | Tossicologia |
AD_PSC043 | Urologia |
AD_PSC046 | Grandi Ustioni Pediatriche |
AD_PSC047 | Grandi Ustionati |
AD_PSC048 | Nefrologia (Abilitazione Trapianto Xxxx) |
AD_PSC049 | Terapia Intensiva |
AD_PSC050 | Unita Coronarica |
AD_PSC051 | Astanteria |
AD_PSC052 | Dermatologia |
AD_PSC054 | Emodialisi |
AD_PSC055 | Farmacologia Clinica |
AD_PSC056 | Recupero e Riabilitazione Funzionale |
AD_PSC057 | Fisiopatologia della Riabilitazione Umana |
AD_PSC058 | Gastroenterologia |
AD_PSC060 | Lungodegenti |
AD_PSC061 | Medicina Nucleare |
AD_PSC062 | Neonatologia |
AD_PSC064 | Oncologia |
AD_PSC065 | Oncoematologia Pediatrica |
AD_PSC066 | Oncoematologia |
AD_PSC068 | Pneumologia, Fisiopatologia Respiratoria, Tisiologia |
AD_PSC069 | Radiologia |
AD_PSC070 | Radioterapia |
AD_PSC071 | Reumatologia |
AD_PSC073 | Terapia Intensiva Neonatale |
AD_PSC074 | Radioterapia Oncologica |
AD_PSC075 | Neuro-Riabilitazione |
AD_PSC076 | Neurochirurgia Pediatrica |
AD_PSC077 | Nefrologia Pediatrica |
AD_PSC078 | Urologia Pediatrica |
AD_PSC082 | Anestesia e Rianimazione |
AD_PSC097 | Detenuti |
AD_PSC098 | Day Surgery Plurispecialistica |
AD_PSC100 | Laboratorio Analisi Chimico Cliniche |
AD_PSC101 | Microbiologia e Virologia |
AD_PSC102 | Centro Trasfusionale e Immunoematologico |
AD_PSC103 | Radiodiagnostica |
AD_PSC104 | Neuroradiologia |
AD_PSC106 | Pronto Soccorso e OBI |
AD_PSC107 | Poliambulatorio |
AD_PSC109 | Centrale Operativa 118 |
AD_PSC121 | Comparti Operatori - Degenza Ordinaria |
AD_PSC122 | Comparti Operatori - Day Surgery |
AD_PSC126 | Libera Professione Degenza |
AD_PSC127 | Hospice Ospedaliero |
AD_PSC129 | Trapianto Organi e Tessuti |
AD_PSC130 | Medicina di Base |
AD_PSC131 | Assistenza Territoriale |
Codice | Descrizione |
AD_PSC199 | Raccolta Consenso |
AD_PSC999 | Altro |
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 |
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 |
J07BX03 | 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. |