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 | PARAGRAFO O PAGINA | DESCRIZIONE DELLA VARIAZIONE |
V10 | Tutto il documento | Revisione dell’intero documento |
V11 | 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 | 4.8.4 | 4.8.4 Aggiunta precisazione su invio dati del pagamento ticket, successivamente all’invio del referto |
V13 | Tutto il documento | Revisione dell’intero documento |
V14 | 2.11.24 | Aggiunta maggior dettaglio nelle tipologie di documento |
V15 | 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 | 2.4.4, 2.11.3 | Aggiunta istruzioni di cifratura per segmento PID |
V17 | 2.4.4 | Aggiornata modalità di cifratura dei dati |
V18 | 2.7.8 | Aggiunti diagrammi MDM_T05 |
V19 | 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 | 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 | 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 | 2.11.5 | Aggiunta specifica per compilazione campo TXA.12 (numero univo del documento) nel caso di invio recupero pregresso |
Indice
1. SCOPO E RIFERIMENTI DEL DOCUMENTO
6
2. INTEGRAZIONE MEDIANTE MESSAGGI HL7
8
2.2 Le “informazioni sanitarie” 8
2.3 I modelli di integrazione con il Fascicolo: con o senza il documento 8
2.3.1 Modello senza invio del documento al fascicolo 8
2.3.2 Modello con invio del documento al fascicolo 9
2.4 Principali modifiche apportate al protocollo con l’introduzione di INI 9
2.4.1 Gestione dei documenti “addendum” 9
2.4.2 Formato e firma dei documenti 9
2.4.3 Dati di dettaglio del Laboratorio di Analisi 9
2.4.4 Cifratura dei dati identificativi e del documento (se inviato) 9
2.5 Le informazioni sanitarie e i messaggi HL7 10
2.6 I messaggi inviati dal ILEC ai sistemi gestionali 10
2.7.2 Invia notifica apertura episodio o modifica di un episodio aperto già notificato 12
2.7.3 Invia notifica chiusura episodio o modifica di un episodio chiuso già notificato 13
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 15
2.7.6 Invia annullamento episodio 16
2.7.7 Invia annullamento documento 17
2.7.8 Invia addendum ad un referto/documento già notificato 17
2.8 Modalità e ordine di attivazione dei servizi 18
2.9 Vincoli sui dati da inviare 18
2.10 La struttura dei messaggi 19
2.10.1 Messaggio ADT^A01^ADT_A01 – Admit/Visit Notification (Event A01) 19
2.10.2 Messaggio ACK^A01^ACK – ACK Admit/Visit Notification 19
2.10.3 Messaggio ADT^A03^ADT_A03 – Discharge/End Visit (Event A03) 19
2.10.4 Messaggio ACK^A03^ACK – ACK Discharge/End Visit 20
2.10.5 Messaggio ADT^A11^ADT_A09 – Cancel Admit / Visit Notification (Event A11) 20
2.10.6 Messaggio ACK^A11^ACK – ACK Cancel Admit / Visit Notification 20
2.10.7 Messaggio MDM^T02 – Original Document Notification and Content 20
2.10.8 Messaggio ACK^T02^ACK – ACK Original Document Notification and Content 21
2.10.9 Messaggio MDM^T06 – Document addendum notification and content 21
2.10.10 Messaggio ACK^T06^ACK – ACK Document addendum notification and content 21
2.10.11 Messaggio MDM^T10 – Document Replacement Notification and Content 21
2.10.12 Messaggio ACK^T10^ACK – ACK Document Replacement Notification and Content 22
2.10.13 Messaggio MDM^T11 – Document Cancel Notification 22
2.10.14 Messaggio ACK^T11^ACK – Document Cancel Notification 22
2.11 I segmenti dei messaggi 23
2.11.1 Segmento MSH: Message Header Segment 23
2.11.2 Segmento EVN: Event type 24
2.11.3 Segmento PID: Patient identification 26
2.11.4 Segmento PV1: Patient visit segment 27
2.11.5 Segmento TXA: Transcription Document Header 33
2.11.6 Segmento OBX: Observation Segment 38
2.11.7 Segmento MSA: Message Acknowledgment Segment 42
2.11.8 Segmento ERR: Error segment 42
2.13.1 Table 0001 - Administrative Sex 50
2.13.2 Table 0004 – Patient Class 50
2.13.3 Table 0008 Acknowledgement code 50
2.13.4 Table 0076 - Message Type - e Table 0003 Event Type 50
2.13.5 Table 0085 - Observation result status codes interpretation 51
2.13.6 Table 0000 - Xxxxxxxxxx XX 51
2.13.7 Table 0123 - Result Status 51
2.13.8 Table 0125 – Value Type 51
2.13.9 Table 0190 - Address type 51
2.13.10 Table 0191 – Type Of Referenced Data 52
2.13.11 Table 0203 - Identifier type 52
2.13.12 Table 0270 – Document Type 52
2.13.13 Table 0271 - Document Completion Status 53
2.13.14 Table 0272 - Document Confidentiality Status 53
2.13.15 Table 0291 – Data Subtype 54
2.13.16 Table 0299 – Encoding 54
2.13.17 Table 0357 – Message error condition codes 54
2.13.18 Table 0361 –Application 54
2.13.19 Table 0362 –Facility 55
2.13.20 Table 0363 – Assigning authority 56
2.13.21 Table 0396 – Coding system table 56
2.13.22 Table 0516 – Error severity 56
2.13.23 Table CSI 003 – Ruolo Utente 57
2.13.24 Table 0119 - Order control codes 57
2.13.25 Table 2.8-1 Affinity Domain – Facility TypeCode 57
2.13.26 Table 2.12-1 Affinity Domain –Assetto organizzativo / Pratica Clinica o specialistica 58
2.13.27 Tabella 3.2-1 Affinity Domain: Tipologia di attività clinica/organizzativa 59
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.1, 30 novembre 2017
• [AFFINITY DOMAIN]
Specifiche tecniche per l’interoperabilità tra i sistemi regionali di FSE Affinity Domain Italia, Versione 2.1, 30 novembre 2017
• [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
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
: FSA TO2
2.7.4 Invia nuovo referto/documento, o aggiornamento dati strutturati legati ad un 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-11-V22-
Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7
Ottobre 2019
uso: Esterno Pagina 15 di 59
: 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. |
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. |
EVN | Event Type | |
PID | Patient Identification | Dati anagrafici del paziente |
PV1 | Patient Visit | Dati di accettazione |
DMA-CL-SRS-11-V22- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7 | Ottobre 2019 | uso: Esterno Pagina 19 di 59 |
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. |
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. |
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 |
} |
DMA-CL-SRS-11-V22- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7 | Ottobre 2019 | uso: Esterno Pagina 20 di 59 |
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. |
EVN | Event Type | |
PID | Patient Identification | Dati anagrafici del paziente |
PV1 | Patient Visit | Dati sulla visita |
TXA | Transcription Document Header | Dati di intestazione del documento |
{ | ||
OBX | Observation/Result (one or more required) | Contenuto del documento |
} |
2.10.10 Messaggio ACK^T06^ACK – ACK Document addendum notification and content
Risposta alla notifica della creazione del documento.
Il messaggio ACK^T06^ACK è costituito dai segmenti elencati nella tabella che segue.
Segmento | Descrizione | Note |
MSH | Message Header | Indicazioni generali sul messaggio inviato. |
[{SFT}] | Software segment | non usato |
MSA | Message acknowledge | |
[{ERR}] | Error information |
2.10.11 Messaggio MDM^T10 – Document Replacement Notification and Content
Notifica di sostituzione del documento, con allegato il contenuto.
Il messaggio MDM^T10 è costituito dai segmenti elencati nella tabella che segue.
Segmento | Descrizione | Note |
MSH | Message Header | Indicazioni generali sul messaggio inviato. |
EVN | Event Type | |
PID | Patient Identification | Dati anagrafici del paziente |
PV1 | Patient Visit | Dati sulla visita |
DMA-CL-SRS-11-V22- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7 | Ottobre 2019 | uso: Esterno Pagina 21 di 59 |
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. |
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 |
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. | ^~\& | ||
C | 3 | 227 | HD | O | Sending Application | Table 0361 – Application | Dipartimentale inviante | ^HIS_DEA |
C | 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 |
C | 5 | 227 | HD | Receiving Application | Table 0361 – Application | Dipartimentale ricevente | ^CL | |
C | 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 | ||
C | 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 |
N | 1 | 20 | IS | O | Namespace Id | Non valorizzare | |
C | 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 |
N | 1 | 20 | IS | O | Namespace Id | Non valorizzare | |
C | 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 |
N | 1 | 20 | IS | O | Namespace Id | Non valorizzare | |
C | 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 |
N | 1 | 20 | IS | O | Namespace Id | Non valorizzare | |
C | 2 | 999 | ST | R | Table 0362 –Facility | Universal ID | L’entità organizzativa che riceve le informazioni. |
2.11.2 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 |
DMA-CL-SRS-11-V22- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7 | Ottobre 2019 | uso: Esterno Pagina 24 di 59 |
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 | |||
N | 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 |
N | 1 | 16 | ST | R | Person Identifier | Codice Fiscale Utente | |
N | 9 | 227 | HD | R | Tab CSI 003 - Ruoli | Assigning Authority | Ruolo (contenuto in HD.2) |
N | 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 |
DMA-CL-SRS-11-V22- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7 | Ottobre 2019 | uso: Esterno Pagina 25 di 59 |
2.11.3 Segmento PID: Patient identification
Il segmento PID contiene i dati del paziente.
Come indicato nel paragrafo 2.4.4 i dati identificativi del paziente e dell’eventuale genitore/tutore devono esserei inviati cifrati. Negli esempi riportati, per maggiore chiarezza, i dati cifrati vengono visualizzati in chiaro.
VAR | SEQ | LEN | DT | OPT | ELEMENT NAME | TBL | NOTE | ESEMPIO |
3 | 250 | CX | R | Patient Identifier List | Lista degli identificativi associati al paziente, contiene le informazioni relative al: codice fiscale (CIFRATO), identificativo anagrafe centrale, identificativo dell’anagrafe locale, ID- AURA. Il CODICE FISCALE va riportato come PRIMO codice della lista. Vedi nota (1) | RSSMRI69A03L219 D^^^^NNITA~1982 7^^^^PZCE~92873^ ^^^PZLO~192383^^ ^^AURA | ||
5 | 250 | XPN | R | Patient Name | Cognome (CIFRATO), Nome (CIFRATO). Vedi nota (2) | XXXXX^XXXXX | ||
7 | 24 | DTM | R | Date/Time of Birth | Data di nascita nel formato aaaammgg | 19690420 | ||
8 | 1 | IS | R | Administrative sex | Table 0001 - Administrative Sex | Sesso del paziente | M | |
11 | 250 | XAD | O | Patient Address | Luogo di nascita del paziente (CIFRATO). Vedi nota (3) | ^^001272^^^100^B | ||
N | 21 | 250 | CX | O | Mother’s Identifier | Contiene in CX.1 il codice fiscale (CIFRATO) del genitore/tutore che ha effettuato la richiesta (riportare per intero anche se CX.1 lungo 15) |
Nota (1)
Struttura campo CX PID-3
SEQ | LEN | DT | OPT | TBL | COMPONENT NAME | Note | |
1 | 15 | ST | R | ID Number | Codice (fiscale,locale,AURA,…). Il codice fiscale è lungo 16 caratteri, ma, anche se eccedente le dimensioni del | Esempio RSSMRI69A03L219D |
DMA-CL-SRS-11-V22- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7 | Ottobre 2019 | uso: Esterno Pagina 26 di 59 |
campo, deve essere riportato per intero e CIFRATO | |||||||
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.4 Segmento PV1: Patient visit segment
Il segmento PV1 contiene i dati caratterizzanti dell’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 | Tipologia dell’accesso del paziente | E |
DMA-CL-SRS-11-V22- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7 | Ottobre 2019 | uso: Esterno Pagina 27 di 59 |
class | ||||||||
C | 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). | ||
E | 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 | ||
C | 22 | 2 | IS | O | Courtesy Code | Questo campo è utilizzato per lo scarico del referto via web. E’ significativo per i messaggi MDM di invio, aggiornamento/sostituzione e annullamento del documento 1)Codice PIN per lo scarico del documento da parte del cittadino, 2)l’indicazione se è un referto scaricabile via web, 3)l’indicazione del pagamento ticket sul documento, 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), 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. 7)Importo ticket da pagare 8)Importo ticket pagato 9)Scaricabile Senza Ticket Pagato (DEPRECATO) – inviare vuoto | 1234567890$S$U$N$ DOC0001$N$36,50$0 $$0 CodicePIN=12345678 90 Referto scaricabile=S Pagato ticket=N Leggi speciali=N Codice documento=DOC001 Oscurato per cittadino=M Importo ticket da pagare=36.50 Importo ticket pagato=0 privacyDocumentoFSE = 0 |
10)Privacy documento FSE Le informazioni sono separate da un carattere $. 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 per rottura provetta. Il flag che indica se il referto è scaricabile via web può valere: S –> scaricabile N -> non scaricabile 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 N-> documento visualizzabile dal cittadino M-> il contenuto del documento è stato illustrato (mediato) da un medico al cittadino e quindi è visualizzabile dal cittadino stesso Privacy documento FSE su richiesta del cittadino può entrare in FSE |
“oscurato”, oppure ereditare le impostazioni di visibilità del fascicolo del paziente 0-> se il referto deve ereditare le caratteristiche di visualizzazione impostate sul fascicolo 1 -> se il referto deve essere oscurato Se il referto è scaricabile deve essere valorizzato anche il codice PIN. NOTA: il PIN generato non deve contenere il carattere $ | ||||||||
N | 24 | 2 | IS | O | Contract Code | Indica se l’inserimento è avvenuto a fronte di una richiesta di consenso al pregresso. Indicare S o N Se non valorizzato viene interpretato come N | N | |
E | 36 | 3 | IS | O | Discharge Disposition | Deprecato. Non valorizzare. | ||
C | 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 | |
C | 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. | 200712041715 | |
50 | 250 | CX | O | Alternate Visit ID | E’ il codice univoco dell’episodio sul sistema originante la richiesta. A seconda del richiedente può contenere: 1. In caso di richiesta da pronto soccorso il numero di passaggio di pronto soccorso per il pronto soccorso; 2. numero di accesso in cartella clinica per le cartelle cliniche ambulatoriali; 3. numero di SDO per applicativi che gestiscono il ricovero; | 200712041715^^^^PS |
Vedi nota (4) |
(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 i codici riportati nella tabella 2.12-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.2-1 dell’Affinity Domain Italia (obbligatorio). | &Ospedale$AD_PSC00 1$CON |
(2) Struttura campo CX PV1-19
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 accesso in cartella clinica nel formato anno (yyyy) + numero 3 numero di SDO | 2008000000143 | |
5 | 5 | ID | O | Table 0363 – Assigning Autority | Identifier Type Code | Tipo di richiesta. È il codice dell’applicativo originante la richiesta che ha generato l’identificativo. Usato per individuare il tipo di richiesta. | PS |
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.5 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.
SEQ | LEN | DT | OPT | TBL | COMPONENT NAME | NOTE | ESEMPIO | |
1 | 4 | SI | R | Set ID- TXA | Dato non utilizzato, impostato ad “1”. | 1 | ||
C | 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 $ Vedi Nota (4) | REF$68604-8 |
C | 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 |
N | 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 | ||
C | 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 | CF^Xxxxx^Xxxxx^^^^^ ^DRS~^CF^Xxxxxxx^ Xxxx^^^^^^DRS |
ruolo Vedi Nota (1) | ||||||||
C | 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) | ||||||||
C | 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) | ||||||||
N | 14 | 427 | EI | O | Placer Order Number | Inserire - NRE (l’elenco dei numeri di ricetta elettronica delle ricette | ^^01010100002^NRE |
dematerializzate prescritte che hanno portato alla generazione del documento/refert o). In EI.3:codice NRE - In EI.4 tipo: NRE Il campo è ripetibile in caso vi siano più NRE | ||||||||
N | 15 | 427 | EI | R | Filler Order Number | - Hash del documento in EI.1 (anche se la lunghezza supera i 199 caratteri) - Dimensione del documento (EI.3) | ab123……e345^^134 5 | |
17 | 2 | ID | R | Table 0271 – Document Completion Status | Document Completion Status | Livello di completamento del documento. Gli unici valori dello stato presi in esame sono quelli che indicano che il documento è stato validato manualmente o legalmente. | LA | |
18 | 2 | ID | O | Table 0272 – Document Confidentiality Status | Document Confidentiality Status | Valorizzato a “R” | R | |
N | 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 | |
C | 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. | CF^Xxxxx^Xxxxx^^^^^ ^PLS^^^^^^20071204 1032~CF^Bianchi^Lu ca^^^^^^PLS^^^^^^2 00712041100 |
Come per i medici redattori è richiesto di indicare il codice fiscale e il ruolo . Vedi nota (2) |
Nota (1) Struttura campo XCN TXA-9
SEQ | LEN | DT | OPT | TBL | COMPONENT NAME | Note | ESEMPIO |
1 | 15 | ST | R | Id Number | Codice fiscale dell’autore del documento (riportare per intero anche se lungo 16) | ||
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 documento | DRS |
15 | 24 | DT M | O | Date/Time Action Performed | Data e ora dell’autenticazione nel formato aaaammgghhmm | 20071204103 2 |
Nota (3) Formato dell’Identificativo Univoco del documento e del repository
Per essere univoco a livello regionale e al fine di adeguarsi al modello di interoperabilità nazionale, l’identificativo deve essere codificato con un OID univoco all’interno Azienda secondo il formato 2.16.840.1.113883.2.9.2.10.4.4.X, dove:
• 2.16.840.1.113883.2.9.2.10.4.4. è il ramo degli OID HL7 Italia per gli identificativi dei documenti della Regione Piemonte (31 caratteri compresi i punti)
• X rappresenta uno specifico documento della Regione Piemonte, composto da 33 caratteri secondo il formato TTAAAN...N dove:
o TT = è il codice tipo struttura, da valorizzare con: “10” per strutture pubbliche,
“11” per strutture private equiparate “12” per le altre strutture private
o AAA = identificativo azienda per le aziende pubbliche oppure il codice assegnato dalla ASL sul progetto ARPE per le aziende private
N...N = numero univoco all’interno dell’azienda, con un massimo di 28 caratteri numerici Es. 2.16.840.1.113883.2.9.2.10.4.4.102010000000000000000000012340088.
Nel caso di invio a fronte di un RECUPERO PREGRESSO (campo PV1.24=S) in questo campo occorre inserire:
1. OID del documento (come su indicato) nel caso il documento che si sta inviando, a seguito del recupero pregresso, è stato generato da subito per il fascicolo con la codifica OID e non con altre codifiche (ovvero quelle utilizzate con la versione del connettore antecedente l'integrazione con INI)
2. OID del documento + $ + codice documento originario nel caso il documento che si sta inviando, a seguito del recupero del pregresso, è stato inizialmente generato per il fascicolo con un'altra codifica (ovvero quelle utilizzate con la versione del connettore antecedente l'integrazione con INI)
Esempio 1:
TXA.12 EI.3 valorizzato con 2.16.840.1.113883.2.9.2.10.4.4.10301000000012345 per un documento che è stato associato da sempre all'OID
Esempio 2:
TXA.12 EI.3 valorizzato con 2.16.840.1.113883.2.9.2.10.4.4.1030100000006789$ABC123XY per un
documento che inizialmente era stato codificato per il fascicolo con il codice ABC123XY
L’identificativo del repository del documento inviato deve avere il seguente formato: 2.16.840.1.113883.2.9.2.10.4.5.X
dove
• 2.16.840.1.113883.2.9.2.10.4.5 indica il ramo degli OID HL7 Italia per gli identificativi dei repository della Regione Piemonte (31 caratteri compresi i punti)
• X indica uno specifico repository dell’Azienda ed è costituito da un codice nel formato TTAAARRRRRRRR, dove:
o TT = codice tipo struttura, da valorizzare con “10” per strutture pubbliche
“11” per strutture private equiparate “12” per le altre strutture private
o AAA= identificativo Azienda per le aziende pubbliche oppure il codice Azienda titolare assegnato dalla ASL di competenza sul progetto ARPE per le Aziende private
o RRRRRRRR = identificativo del repository (al massimo 8 caratteri numerici)
Nota (4) Essendo fisso il valore previsto per il Tipo Documento Basso, in fase di alimentazione del fascicolo, sono consentiti i valori riportati nelle tabelle seguenti:
TipoDocumentoAlto
Codice | Descrizione |
REF | Referto |
LDO | Lettera di Dimissione Ospedaliera |
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 |
ATTO_OPERATORIO | Atto operatorio |
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 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 |
Esempio: REF^68604-8
2.11.6 Segmento OBX: Observation Segment
Il segmento OBX contiene i dati strutturati ed il testo del documento.
VA R | SEQ | LEN | DT | OPT | TBL | COMPONENT NAME | NOTE | ESEMPIO |
1 | 4 | SI | R | Set ID- OBX | Numero da sequenza dell’obx: se nel messaggio ci sono più OBX, ognuno avrà un id crescente. | 1 | ||
2 | 3 | ID | R | Table – 0125 Value Type | Value Type | Specifica il tipo di OBX. | ED | |
C | 3 | 705 | CWE (ex CE) | R | Table 0270 – Documnt type | Observation Identifier | E’ l’identificativo univoco dell’observation (OBX): 1 per le prestazioni è costituito dal codice prestazione secondo la codifica prevista dal Catalogo Regionale e dal codice branca regionale su cui è stata erogata la prestazione. Vedi nota (1). 2 per 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 3 Per il tipo RP (senza invio di documento) indicare il tipo documento medio riportato nel segmento |
TXA Nota (1) | ||||||||
E | 4 | 20 | ST | C | Observation Sub-ID | Deprecato | ||
5 | * | * | C/R | Observation Value | Valore dell’informazione contenuta nell’OBX o valore dell’esame. Nel caso di un allegato, sarà il contenuto dell’allegato (CIFRATO) in formato base64 utilizzando il tipo ED. Nel secondo sottocampo viene riportata una eventuale nota sul risultato. Per il tipo OBX.2 è RP rappresenta (OBX-5.1) l’accession number utilizzato per reperire le immagini nel caso vi sia l’integrazione con i PACS dell’Azienda, il tipo di dato (OBX-5.3) ed il subtipo (OBX-5.4) Nota (2) | 15^Nota risultato | ||
C | 11 | 1 | ID | R/NA | Table 0085 - Observation result status codes interpretation | Observation Result Status | Il campo è valorizzato con “F” quando viene inviato un nuovo documento oppure un dato strutturato validato. Assume valore “C” quando viene inviata una modifica di un dato strutturato oppure un documento che deve sostituire un documento già inviato. Il campo è valorizzato con “B” quando viene inviato un addendum (MDM_T06). | F |
13 | 20 | ST | C | User Defined Access Checks | Quantità, utilizzato per indicare il numero di volte che è stata erogata una prestazione, se è stata eseguita una sola volta conterrà il valore 1. Nel |
caso l’OBX non si riferisca ad una prestazione il campo non sarà valorizzato. | ||||||||
14 | 24 | DTM | O | Date/Time of | Data e ora di erogazione, nel | 20071206150 | ||
Observation | caso della prestazione. | 5 | ||||||
Vuota negli altri casi. | ||||||||
Il formato è aaaammgghhmm. |
(1) Struttura campo CWE OBX-3
Se il campo si riferisce ad una prestazione (OBX.2=CE) :
VA R | SE Q | LEN | DT | OPT | TBL | COMPONENT NAME | Note | ESEMPIO |
C | 1 | 20 | ST | R | Identifier | Codice della prestazione secondo la codifica del catalogo regionale | 89.7 | |
E | 2 | 199 | ST | O | Deprecato. Non valorizzare | |||
C | 3 | 20 | ID | R | Table 0396 - Coding system | Name of Coding System | Sistema di codifica della prestazione. Il valore è CATREG | CATREG |
C | 4 | 20 | ST | R | Alternate Identifier | Codice della branca regionale su cui è erogata la prestazione | 08 | |
E | 6 | 20 | ID | O | Table 0396 - Coding system | Name of Alternate Coding System | Deprecato. Non valorizzare |
Se il campo si riferisce ad un documento (OBX.2=ED)
VA R | SE Q | LEN | DT | OPT | TBL | COMPONENT NAME | Note | ESEMPIO |
C | 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 |
C | 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 |
C | 1 | 20 | ST | R | Identifier | tipologia di documento medio | 11502-2 |
(2) Struttura campo ED OBX-5
SEQ | LEN | DT | OPT | TBL | COMPONENT NAME | NOTE | ESEMPIO |
2 | 9 | ID | R | Table 0191 - Type Of | Type of data | multipart |
DMA-CL-SRS-11-V22- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7 | Ottobre 2019 | uso: Esterno Pagina 40 di 59 |
Referenced Data | |||||||
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 | Accession number | 1555487 | |
3 | 11 | ID | R | Table 0191 - Type Of Referenced Data | Type of Data | fisso | IM |
4 | 32 | ID | R | Table 0291 - Data Subtype | Subtype | fisso | DICOM |
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 |
Esempio:
^multipart^Octet- Stream^Base64^JVBERi0xLjMKJcfsj6IKOCAwIG9iago8PC9MZW5n/GggOSAwIFIvRmlsdGVyIC9GbGF0Z URl
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|CE|89.7&01^^99RPR^100^^99LPR|1|||||||F||1|200703060930 OBX|2|CE|91.90.6&01^^99RPR^201^^99LPR|1||||||F|1|200703060930
OBX|3|ED|REFERTO|1|< referto>
Esempio 2. È stata erogata una prestazione e ad essa, è associato un referto codificato in base64 il cui testo supera 65536 byte: (solo per invio con referto) OBX|1|CE|89.7&01^^99RPR^101^^99LPR|1|||||||F||1|200703060930
OBX|2|ED|REFERTO|1|< referto con dimensione superiore a 65536>
DMA-CL-SRS-11-V22- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7 | Ottobre 2019 | uso: Esterno Pagina 41 di 59 |
Esempio 3. È 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|CE|88.22&01^^99RPR^101^^99LPR|1|||||||F||1|200703060930
OBX|2|RP| |1|1235547^^IM^DICOM||||||F
OBX|3|ED|REFERTO-RIS^^99CDO|1|< referto con dimensione superiore a 65536>
Esempio 4. È stata erogata una prestazione e ad essa è associato un documento conservato nel dipartimentale (per invio senza referto)
OBX|1|CE|88.22&01^^99RPR^101^^99LPR|1|||||||F||1|200703060930 OBX|2|RP| |1|^^RIF^||||||F
(3) Struttura campo CWE OBX-5
SE Q | LEN | DT | OPT | TBL | COMPONENT NAME | NOTE | ESEMPIO |
1 | 20 | ST | O | Identifier | Codice del valore | 531 | |
2 | 199 | ST | O | Text | Testo | ULCERA GASTRICA | |
3 | 20 | ID | O | Table 0396 - Coding system | Name of Coding System | Sistema di codifica utilizzato | I9C |
(4) Struttura campo ST OBX-5
SE Q | LEN | DT | OPT | TBL | COMPONENT NAME | NOTE | ESEMPIO |
1 | 199 | String data |
I valori dei risultati degli esami di laboratorio di analisi non devono essere più comunicati.
2.11.7 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.8 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 | FSE_ER_121^ |
DMA-CL-SRS-11-V22- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7 | Ottobre 2019 | uso: Esterno Pagina 42 di 59 |
generato dell’applicativo che risponde | Non esiste il codice della branca regionale del documento |
(1) Struttura campo CWE ERR-5
SEQ | LEN | DT | OPT | TBL | COMPONENT NAME | NOTE | ESEMPIO |
1 | 20 | ST | O | Identifier | Codice identificativo dell’errore | FSE_ER_121 | |
2 | 199 | ST | O | Text | Testo dell’errore | Non esiste il codice della branca regionale del documento |
In questo paragrafo vengono elencati i codici di errore e le relative descrizioni, restituiti dal Fascicolo. I codici FSE_ER sono codici di errori che hanno determinato il fallimento dell’operazione su FSE.
I codici FSE_WR sono codici di warning che hanno determinato comunque il successo dell’operazione su FSE, in alcuni casi l’operazione può essere stata eseguita solo parzialmente.
Codice | Descrizione |
FSE_ER_000 | Errore di sistema durante l’elaborazione della richiesta. |
FSE_ER_010 | Le seguenti informazioni sono obbligatorie: <elenco dei campi obbligatori non valorizzati> |
FSE_ER_100 | Errore di sistema durante l’acquisizione dei dati |
FSE_ER_101 | Non esiste il codice azienda inviante: codice=<codice azienda inviante> |
FSE_ER_102 | Non esiste il codice applicativo inviante: codice=<codice applicativo inviante> |
FSE_ER_103 | Non esiste il codice del sesso: codice=<codice sesso> |
FSE_ER_104 | Data di nascita non valida: data=<data di nascita> |
FSE_ER_105 | Non esiste il codice dello stato di nascita: codice=<codice stato> |
FSE_ER_106 | Non esiste il codice del comune di nascita: codice=<codice comune> |
FSE_ER_107 | Non esiste il codice dell’azione sull’episodio: codice=<codice azione episodio> |
FSE_ER_108 | Non esiste il codice del tipo episodio: codice=<codice tipo episodio> |
FSE_ER_109 | Data di accettazione non valida: data=<data di accettazione> |
FSE_ER_110 | Ora di accettazione non valida: ora=<ora di accettazione> |
FSE_ER_111 | Non esiste la matricola di accettazione: codice=<codice matricola di accettazione> per l’azienda <codice azienda inviante> |
FSE_ER_112 | Data di dimissione non valida: data=<data di dimissione > |
FSE_ER_113 | Ora di dimissione non valida: ora=<ora di dimissione > |
FSE_ER_114 | Non esiste la matricola di dimissione: codice=<codice matricola di dimissione > per l’azienda <codice azienda inviante > |
FSE_ER_116 | Non esiste il codice dell’azione sul documento: codice=<codice azione documento> |
FSE_ER_117 | Non esiste il codice del tipo documento: codice=<codice tipo documento > |
FSE_ER_118 | Data di validazione del documento non valida: data=<data di validazione> |
FSE_ER_119 | Ora di validazione del documento non valida: ora=<ora di accettazione> |
FSE_ER_120 | Non esiste il codice del formato del documento: codice=<codice formato documento> |
FSE_ER_121 | Non esiste il codice della branca regionale del documento: codice=<codice branca> |
FSE_ER_122 | Non esiste il codice della prestazione regionale del documento: codice=<codice prestazione > |
FSE_ER_123 | Se è valorizzata la matricola di accettazione deve essere valorizzata anche la data di accettazione |
FSE_ER_124 | Se è valorizzata la matricola di dimissione deve essere valorizzata anche la data di dimissione |
FSE_ER_125 | Firma del documento non valida |
FSE_ER_126 | La data fine episodio deve coincidere o essere successiva alla data di inizio episodio |
FSE_ER_140 | Il comune deve essere valorizzato se lo stato è Italia |
FSE_ER_141 | Devono essere valorizzati data, ora, matricola accettazione, insieme al numero SDO (se episodio di ricovero) oppure numero di passaggio di pronto soccorso (se episodio di pronto soccorso) |
FSE_ER_142 | I dati di accettazione data e matricola devono essere valorizzati oppure essere tutti vuoti insieme all’ora |
FSE_ER_143 | I dati di dimissione data e matricola devono essere valorizzati oppure essere tutti vuoti insieme all’ora |
FSE_ER_144 | I campi “Identificativo dell’episodio che ha originato la richiesta” e “Tipo episodio che ha originato la richiesta” devono essere entrambi valorizzati o vuoti. |
FSE_ER_145 | Devono essere valorizzati i campi “Tipo azione documento”, Identificativo del documento”, “Codice tipo documento”, “Data e ora firma o di validazione del documento”, “Firmato digitalmente”, “Documento”, “Formato documento” |
FSE_ER_146 | Sui dati delle prestazioni devono essere valorizzati il codice e la descrizione della prestazione. |
FSE_ER_147 | Non possono essere valorizzati sia il numero SDO che il numero di passaggio di pronto soccorso |
FSE_ER_148 | Il documento non è in formato base64 |
FSE_ER_149 | Deve essere valorizzato il campo “Identificativo del documento” |
FSE_ER_200 | L’IDAURA <numero idaura> e il codice fiscale inviato <codice fiscale> non coincidono con quelli presenti nel Fascicolo. |
FSE_ER_201 | L’IDAURA <numero idaura> inviato non esiste nel Fascicolo. |
FSE_ER_202 | Il paziente con codice fiscale <codice fiscale> non è stato individuato nell’anagrafe del Fascicolo. |
FSE_ER_203 | Non è possibile inserire un episodio annullato. |
FSE_ER_204 | Non è possibile inserire un documento annullato. |
FSE_ER_205 | Non è possibile aggiornare un episodio annullato. Codice episodio <codice episodio dipartimentale> |
FSE_ER_206 | Non è possibile annullare l’episodio <codice episodio dipartimentale> perché non esiste l’episodio per il paziente o l’episodio non è stato inserito dall’applicativo che richiede l’annullamento. |
FSE_ER_207 | Non è possibile annullare il documento perché non esiste l’identificativo del documento <identificativo documento del dipartimentale> per il paziente e l’applicativo inviante. |
FSE_ER_208 | Non è possibile sostituire il documento perché l’identificativo precedente del documento (<identificativo precedente del documento inviato dal dipartimentale>) per il paziente e applicativo inviante non esiste nel fascicolo. |
FSE_ER_209 | Non è possibile sostituire il documento (<identificativo del documento inviato dal dipartimentale>) perché il documento precedente (<identificativo precedente del documento inviato dal dipartimentale>) è stato annullato. |
FSE_ER_211 | Non è stato possibile individuare la matricola <numero matricola> alla data di riferimento <data di riferimento>. |
FSE_ER_212 | Non è stato possibile aggiornare i dati dell’episodio perché è cambiato il tipo episodio. |
FSE_ER_213 | Non è stato possibile aggiornare l’episodio perché è cambiato il numero nosologico ed esistono degli episodi secondari. |
FSE_ER_214 | Non è stato possibile aggiornare l’episodio ambulatoriale perché è cambiato il numero nosologico, vecchio numero=<vecchio numero>, nuovo numero=<nuovo numero> |
FSE_ER_215 | Non è stato possibile aggiornare l’episodio ambulatoriale perché è cambiato il numero di passaggio di pronto soccorso, vecchio numero=<vecchio numero>, nuovo numero=<nuovo numero> |
FSE_ER_216 | Non è stato possibile inserire l’episodio perché non sono valorizzati la data o la matricola di accettazione |
FSE_ER_217 | Non è possibile inserire l’episodio perché la data oppure l’ora oppure la matricola di accettazione non è valorizzata |
FSE_ER_218 | Non è possibile inserire il paziente perché l’IDAURA <idaura> è già presente per un altro paziente |
FSE_ER_219 | Non è possibile registrare i dati relativi ad un paziente minorenne |
FSE_ER_220 | L’Anagrafe Regionale AURA non è disponibile |
FSE_ER_300 | Tipologia di messaggio non supportata |
FSE_ER_301 | Versione del messaggio non supportata |
FSE_ER_302 | Il codice fiscale deve essere valorizzato |
FSE_ER_303 | dato Ditta Inviante obbligatorio |
FSE_ER_304 | codice Ditta Inviante errato |
FSE_ER_305 | dato Applicazione Ricevente obbligatorio |
FSE_ER_306 | codice Applicazione Ricevente errato |
FSE_ER_307 | dato Xxxxx Xxxxxxxxx obbligatorio |
FSE_ER_308 | codice Ditta Ricevente errato |
FSE_ER_309 | dato DataOra Creazione Messaggio obbligatorio |
FSE_ER_310 | formato DataOra Creazione Messaggio errato |
FSE_ER_311 | dato Id Messaggio obbligatorio |
FSE_ER_312 | dato Processing Id obbligatorio |
FSE_ER_313 | dato Versione HL7 obbligatorio |
FSE_ER_314 | dato Applicazione Inviante obbligatorio |
FSE_ER_315 | codice Applicazione Inviante errato |
FSE_ER_316 | Il codice fiscale deve essere lungo 16 caratteri |
FSE_ER_317 | dato Luogo di Nascita obbligatorio |
FSE_ER_318 | dato Cognome obbligatorio |
FSE_ER_319 | dato Nome obbligatorio |
FSE_ER_320 | dato Sesso obbligatorio |
FSE_ER_321 | dato Data di Nascita obbligatorio |
FSE_ER_322 | dato Classe Paziente obbligatorio |
FSE_ER_323 | codice Classe Paziente errato |
FSE_ER_324 | Identificativo dell’episodio obbligatorio |
FSE_ER_325 | dato Data Accettazione obbligatorio |
FSE_ER_326 | dato Data Dimissione obbligatorio |
FSE_ER_328 | dato Formato Allegato obbligatorio |
FSE_ER_329 | dato Id Documento obbligatorio |
FSE_ER_330 | dato Id Documento da Sostituire obbligatorio |
FSE_ER_331 | codice Validazione Documento errato |
FSE_ER_332 | codice Riservatezza Documento errato |
FSE_ER_333 | dato Numero Sequenza OBX obbligatorio |
FSE_ER_334 | dato Tipo OBX obbligatorio |
FSE_ER_335 | codice Tipo OBX errato |
FSE_ER_336 | dato Id OBX obbligatorio |
FSE_ER_337 | formato DataOra di Osservazione errato |
FSE_ER_338 | codice Risultato errato |
FSE_ER_339 | Il messaggio contiene due segmenti SPM consecutivi oppure un segmento SPM che non è seguito da un OBR e almeno un OBX |
FSE_ER_340 | Il documento non è valorizzato |
FSE_ER_341 | Il documento non è firmarto. L'ASO/ASR ha dichiarato di inviare solo documenti firmati |
FSE_ER_342 | Il paziente con codice fiscale {5} non è stato individuato nell'anagrafe del Fascicolo. Codice Fiscale non trovato o rank anagrafico non sufficiente |
FSE_ER_343 | Il paziente con codice fiscale {5} non è stato individuato nell'anagrafe del Fascicolo. Paziente non presente in componente centrale |
FSE_ER_344 | Il paziente con codice fiscale {5} ha un rank non sufficiente |
FSE_ER_345 | Non è possibile inserire l’episodio perché la data di accettazione non è valorizzata |
FSE_ER_346 | Non è possibile inserire l’episodio perché il codice luogo di accettazione non è valorizzato |
FSE_ER_347 | Il codice fiscale inviato {6} non coincide con quello presente nel Fascicolo |
FSE_ER_348 | Il codice fiscale inviato {6} non coincide con quello presente nel Fascicolo in componente centrale |
FSE_ER_350 | Identificativo dell’episodio {5} inesistente |
FSE_ER_351 | Errore durante la registrazione della prestazione |
FSE_ER_352 | Il PV1-19 deve essere uguale al MRG-5 |
FSE_ER_360 | Non è stato possibile individuare il paziente precedente |
FSE_ER_361 | Non è stato possibile individuare il nuovo paziente |
FSE_ER_362 | L’identificativo dell’episodio <identificativo episodio> non esiste per il paziente precedente |
FSE_ER_363 | Non è possibile aggiornare il documento perché è stato annullato |
FSE_ER_364 | Il parametro privacyDocumentoFse può contenere il valore 0 oppure 1. |
FSE_ER_365 | Il parametro scaricabileDalCittadino può contenere il valore S oppure N. |
FSE_ER_366 | Il parametro oscuraScaricoCittadino può contenere il valore S oppure N oppure M. |
FSE_ER_367 | Il parametro soggettoALeggiSpeciali può contenere il valore S oppure N. ( Deprecato ) |
FSE_ER_369 | Identificativo Utente: Codicefiscale formalmente errato |
FSE_ER_370 | Il dato Utente deve prevedere obbligatoriamente il dato IdentificativoUtente e, a scelta, uno tra Codice Matricola e Codice Struttura Utente |
FSE_ER_371 | La richiesta non può essere effettuata in quanto mancano i dati dell'utente |
FSE_ER_372 | Non esiste la matricola utente: codice=<codice matricola utente> |
FSE_ER_373 | Valorizzare a scelta uno solo tra il codice strutturautente o il codice matricola utente |
FSE_ER_374 | Il codice matricola: codice=<codice matricola utente> non è presente in ARPE |
FSE_ER_375 | Non esiste il codice struttura: codice=<Codice Struttura Utente> |
FSE_ER_376 | Se presente, il Codice Struttura Utente deve essere formato dalla concatenazione Codice Azienda|Codice struttura|subcodice struttura |
FSE_ER_377 | Dato RuoloUtente obbligatorio |
FSE_ER_378 | Codice RuoloUtente errato |
FSE_ER_379 | Il Ruolo Utente <RuoloUtente> non rientra tra quelli previsti nell'Affinity Domain |
FSE_ER_380 | Codice idDocumento errato |
FSE_ER_381 | Non è possibile inserire i dati del documento perché non è valorizzato l'identificativo repository in mancanza del documento |
FSE_ER_382 | Dato Tipologia Documento Alto obbligatorio |
FSE_ER_383 | Codice Tipologia Documento Alto errato |
FSE_ER_384 | Dato Tipologia Documento Medio obbligatorio |
FSE_ER_385 | Codice Tipologia Documento Medio errato |
FSE_ER_386 | Dato mimetype errato |
FSE_ER_387 | Dato hash non coerente col documento inviato |
FSE_ER_388 | Dato size del documento non valorizzato |
FSE_ER_389 | Dato mediciRedattori: Codice Fiscale obbligatorio |
FSE_ER_390 | Dato mediciRedattori: Codice Fiscale formalmente errato |
FSE_ER_391 | Dato mediciRedattori: Xxxxx xxxxxx |
FSE_ER_392 | Dato mediciValidatori: Codice Fiscale obbligatorio |
FSE_ER_393 | Dato mediciValidatori: Codice Fiscale formalmente errato |
FSE_ER_394 | Dato mediciValidatori: Xxxxx xxxxxx |
FSE_ER_395 | Dato Conservazione Sostitutiva non valido |
FSE_ER_396 | Dato Tipologia Struttura Produzione Documento non valido |
FSE_ER_397 | Dato Assetto Organizzativo non valido |
FSE_ER_398 | Dato Tipo Attività Clinica non valido |
FSE_ER_399 | Dato Codice Branca Regionale non valido |
FSE_ER_400 | Non è possibile annullare il documento in quanto esistono documenti di addendum legati ad esso |
FSE_ER_401 | Dato IdDocumentoParent obbligatorio se azione documento "Aggiornamento" con invio referto |
FSE_ER_402 | Dato IdDocumentoParent obbligatorio se azione documento "Addendum" |
FSE_ER_403 | Non è possibile inserire un Addendum ad un documento che risulta Addendum |
FSE_WR_202 | L’identificativo del documento è già presente nel Fascicolo, sono stai aggiornati solo i meta- dati. |
FSE_WR_203 | Alcune prestazioni non sono presenti in nessun documento |
FSE_WR_204 | L’episodio non ha documenti |
SCA_ER_000 | Scarico referti: errore di sistema, <descrizione dell’errore> |
SCA_ER_100 | Scarico referti: non è possibile annullare il documento <identificativo del documento> perché non è stato trovato per l’episodio <identificativo episodio> |
SCA_ER_101 | Scarico referti: non è possibile aggiornare il documento perché è stato annullato |
SCA_ER_106 | Scarico referti: il codice PIN deve essere valorizzato |
SCA_ER_107 | Scarico referti: non è possibile registrare le informazioni sul ticket perché non è stato individuato il paziente e l’episodio. |
SCA_ER_108 | Scarico referti: non è possibile registrare le informazioni sul ticket perché non è stato individuato il paziente, l’episodio e il documento. |
SCA_ER_109 | Scarico referti: l’impostazione scaricabileDalCittadino non può essere TRUE se anche oscuraScaricoCittadino vale “S” o “M”. |
SCA_WR_101 | Scarico referti:l’episodio <identificativo episodio> non ha documenti scaricabili da annullare |
SCA_WR_102 | Scarico referti: non è presente l’informazione soggettoALeggiSpeciali ( deprecato ) |
SCA_WR_103 | Scarico referti: non è presente l’informazione privacyDocumentoFse |
SCA_WR_104 | Scarico referti: non è presente l’informazione oscuraScaricoCittadino |
SCA_WR_105 | Scarico referti: non è presente l’informazione scaricabileDalCittadino |
Il presente capitolo descrive tutte le tabelle di codifica utilizzate nel progetto.
2.13.1 Table 0001 - Administrative Sex
Sesso del paziente.
Codice | Descrizione | Descrizione d’uso |
F | Female | Femmina |
M | Male | Maschio |
U | Unknown | Sconosciuto |
2.13.2 Table 0004 – Patient Class
Provenienza del paziente.
Codice | Descrizione | Descrizione d’uso |
E | Emergency | Dati provenienti dal Pronto Soccorso (PS/DEA) |
I | Inpatient | Paziente ricoverato (RO, DH, DS) |
O | Outpatient | Paziente ambulatoriale (AMB) |
2.13.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.13.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 del ricovero ” |
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 ricovero” |
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.13.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.13.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.13.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.13.8 Table 0125 – Value Type
Tipologia del dato caratterizzato all’interno di un OBX.
Codice | Descrizione | Descrizione d’uso |
Identificativi HL7 | ||
CE | 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.13.9 Table 0190 - Address type
Tipo di indirizzo.
Codice | Descrizione | Descrizione d’uso |
Identificativi HL7 | ||
B | Birth | Luogo di nascita |
DMA-CL-SRS-11-V22- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7 | Ottobre 2019 | uso: Esterno Pagina 51 di 59 |
2.13.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.13.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.13.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.
DMA-CL-SRS-11-V22- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7 | Ottobre 2019 | uso: Esterno Pagina 52 di 59 |
TipoDocumentoAlto (Tabella 2.3-1 dell’Affinity Domain Italia)
Codice | Descrizione | |
REF | Referto | |
LDO | Lettera di Dimissione Ospedaliera |
Tipo Documento Medio (Tabella 2-18-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.13.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.13.14 Table 0272 - Document Confidentiality Status
Livello di riservatezza del documento.
Codice | Descrizione | Descrizione d’uso |
Identificativi HL7 | ||
R | Restricted | Accesso ristretto |
DMA-CL-SRS-11-V22- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7 | Ottobre 2019 | uso: Esterno Pagina 53 di 59 |
2.13.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.13.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.13.18 Table 0361 –Application
Dipartimentale inviante o ricevente.
Codice | Descrizione | Descrizione d’uso |
Identificativi CSI | ||
DOSSIER oppure | Componente Locale del FSE |
DMA-CL-SRS-11-V22- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7 | Ottobre 2019 | uso: Esterno Pagina 54 di 59 |
FSATO2 (per retrocompatibilità con TO2) | ||
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 | A.S.L. TORINO 5 |
DMA-CL-SRS-11-V22- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7 | Ottobre 2019 | uso: Esterno Pagina 55 di 59 |
206 | A.S.L. VERCELLI | |
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.13.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.13.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 procedures and diagnostic tests). |
2.13.22 Table 0516 – Error severity
Livello di gravità dell’errore.
Codice | Descrizione | Descrizione d’uso |
DMA-CL-SRS-11-V22- Specifica_protocollo_interoperabilita_CL_dip_c on e senza invio referti-HL7 | Ottobre 2019 | uso: Esterno Pagina 56 di 59 |
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.13.23 Table CSI 003 – Ruolo Utente (Tabella 5.4-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.13.24 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.13.25 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.13.26 Table 2.12-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 |
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 |
Codice | Descrizione |
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 |
2.13.27 Tabella 3.2-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 |