Pag.1 ULSS 13 Mirano/Dolo Specifiche integrazione Verticale
Pag.2 Versione 1 Variante 13 Modifiche introdotte rispetto a versione precedente 1.13 Aggiunto campo SPM-2 (ID Campione) 1.12 Estesi valori previsti per TXA.3 PV1.42: specificata valorizzazione. TXA-13: specificata ulteriormente valorizzazione id documento padre. 1.11 MSH: Cambiata descrizione MSH-3-4-5-6 PID: Modificato PID-3, aggiunti PID-19 e PID-21 C: Modificato C-3 1.10 C: C-12 modificato in E TXA: TXA-14 se il paziente è esente non va valorizzato 1.9 per gli MDM MSH: MSH-3-4 -5-6 aggiornato con caso MDM PID: PID-11 modificato in E per residenza e luogo di nascita nel caso di MDM PV1: PV1-2 se campo vuoto valore di default = '' PV1-50 modificato in E C: C-3 modificato in E per sottocampo 4 C-10 modificato in E B: B-2 modificato in E B-4 modificato in E B-46 modificato in E TXA: TXA-10, -14, cambiato obbligatorietà = E TXA-15 cambiato obbligatorietà = Aggiunto possibilità di concordare alcuni codici dipartimentali al posto di codici G2 nel caso degli MDM (unità di consegna). Indicato fop utilizzato per la renderizzazione: 0.94
Pag.3 1.8 B: B-18 cambiato valore obbligatorietà placer field 2 orc-2 orc-4 introdotti tipo documento 10 e 11 per campo TXA-2 specificata obbligatorietà pv1-7 dettagliata descrizione MIME documenti clinici 1.7 Sistemata la formattazione tabella con le corrispondenze Stati Prestazioni -> Stato rdine Messaggi M01-SC/SN, MDMT02, MDMT10: - sul segmento PID hanno ora attributo di obbligatorietà = i campi PID- 3, PID-7, PID-8, - sul segmento PV1 ha ora attributo di obbligatorietà = E il campo PV1-2, Specificata la composizione del segmento MSA nel caso di ACK in risposta a messaggi MDM. 1.6 Lo stato IP (vedi campo C.5) viene ora gestito a livello di singola prestazione. Inserita tabella con le corrispondenze Stati Prestazioni -> Stato rdine 1.5 Specificati nel capitolo 12 il formato richiesto per i documenti inviati al rpy. Cambiato segmento SPM: tolto segmento SPM.2. Modificato contenuto SPM.4 (sottocampi 1,2 e 5), Aggiunto campo SPM.8 con sottocampi 1,2 e 5. Cambiata da a E regola di compilazione dei campi PV1.7 e PV1.19 Corretta valorizzazione di TXA-18 (Document Confidentiality Code) 1.4 Messaggi classi M, ML ed MDM: aggiunto campo B-31 (eason for Study) Messaggi classi M, ML ed MDM: aggiunto campo C-8 (Parent) 1.3 Messaggio M^01 ridefinito in M^01-NW/CA Messaggio M^01-SC ridefinito in M^01-SC/SN Sostituito messaggio UL^22 con M^01-SC/SN Sostituito messaggio ML^33 con ML^33-NW/CA
Pag.4 Aggiunto il campo C-5 rder Status (dimenticanza precededente) sui messaggi ML^21-SC/SN e M^01-SC/SN Aggiunte strutture dei messaggi ML^33-NW/CA, M^01-NW/CA, M^01-SC/SN Aggiunta informazione Chiave impegnativa nell B-47 (ripetizione 5): utilizzata per comunicare a quale impegnativa associare la prestazione aggiuntiva. 1.2 TXA-18: prima era (optional) ora (requested) Aggiunto campo PV1-22 (Courtesy Code) valorizzato con l id del pagamento per la verifica dello stato di pagamento. 1.1 Cambiata dicitura campo HL7 Conditional : da I a E (come da HL7 Italia) Aggiunto disegno su comunicazione cambio stato Tolta tabella codifiche codice civile ripetuta Aggiunta descrizione segmenti PID-PV1-C-B per i messaggi MDM iferimenti [1] referto-cda2-v1.1.pdf
Pag.5 INDICE 1. Finalità del documento... 8 2. Architettura di integrazione... 9 3. Integrazione con Anagrafe Unica: Eventi e messaggi... 10 4. Scenari relativi alle richieste di prestazioni... 11 4.1. Comunicazione richieste di prestazioni... 11 4.2. Comunicazione cambio stato e prestazioni aggiuntive... 12 5. Comunicazione risultati e documenti... 13 6. Gestione codifiche... 14 7. Dettaglio messaggi scambiati... 15 7.1. Struttura (segmenti) dei messaggi considerati... 15 7.2. Descrizione puntuale segmenti-campi dei messaggi... 16 7.2.1. Descrizione segmenti comuni a tutti i messaggi... 16 7.2.2. Descrizione dei segmenti specializzati per messaggi... 20 7.3. APPENDICE A - Tabelle di riferimento... 27
Pag.6 Definizioni e abbreviazioni In uso in questo documento Azienda SI G2-CUP Anagrafe Unica (AU) G2-CUP G2-E G2-ADT PS epository SISTEMA VETICALE ANAGAFE LCALE L azienda ULSS 13 di Dolo/Mirano Sistema informativo ospedaliero Sistema destinato a gestire il Prenotato, Erogato e Pagato dell azienda; è la piattaforma comune su cui poggiamo i sistemi seguenti classificati come G2 Anagrafe Aziendale dei Contatti (Master Patient Index); contiene sia le posizioni anagrafiche si Assistiti dell ULSS di Dolo che quelle di pazienti fuori ULSS che hanno avuto almeno un contatto con l Azienda (è integrata a monte con l anagrafe aziendale). sistema CUP aziendale (rder Placer utilizzato prevalentemente per pazienti esterni) sistema aziendale di rder Entry (rder Placer utilizzato prevalentemente per pazienti interni) sistema aziendale per la gestione amministrativa dei ricoveri (Admission Dismission Transfer) Applicativo di Pronto Soccorso sistema di repository documentale questo termine verrà utilizzato per identificare un sistema software generico utilizzato per la gestione di uno o più servizi su una o più strutture dell Azienda ULSS 13 di Mirano/Dolo e che deve inserirsi nelle logiche di integrazione SI descritte nel documento. anagrafe del Sistema Verticale Appartenenti alla terminologia standard ADT CDA2 CUP Admission/Discharge/Transfer Clinical Document Architecture Applicativo utilizzato dal Centro Unico di Prenotazione HL7 Health Level 7 IHE LIS PAM Integrating the Healthcare Enterprise Laboratory Information System Profilo IHE Patient Administration Management
Pag.7 PDQ PI IS SWF LSWF Profilo IHE Patient Demographics Query Profilo IHE Patient Information econciliation adiology Information System Profilo IHE Scheduled Workflow Profilo IHE Laboratory Scheduled Workflow
Pag.8 1. Finalità del documento Questo documento intende esporre le specifiche tecniche di integrazione di un sistema Verticale (Dipartimentale) nel SI della ULSS 13 di Mirano/Dolo. Il nuovo sistema che viene attivato si deve infatti inserire nel contesto del SI attivo presso l azienda recependo le modalità di integrazione con gli altri moduli e gli standard previsti, in modo da costituire un sistema congruente e centrato sul paziente. Le modalità e le tecnologie di integrazione utilizzate nell architettura di seguito descritti sono diverse. In tutti i casi in cui lo si è ritenuto opportuno tuttavia si è utilizzato HL7 (Health Level Seven), standard internazionale per lo scambio di dati in ambito sanitario. La versione di protocollo HL7 utilizzata è la 2.5. Negli scenari descritti si è fatto laddove possibile riferimento ai profili-attori-transazioni IHE HL7 come previsti dal comitato IHE, anche se non sempre esplicitamente citati nel documento. La definizione dei trigger event e ed il contenuto dei messaggi HL7 sono stati prodotti tenendo conto della delle localizzazioni pubblicate da HL7 Italia al momento in cui si scrive, della realtà della sanità italiana, nonché di quella specifica della ULSS 13. Dove non esplicitamente indicato si sottintende che lo scambio dati avviene su canale di comunicazione socket con protocollo TCP/IP su porte concordare utilizzando MLLP (Multi Lower Layer Protocol). Il formalismo utilizzato per i messaggi HL7 è quello pipe e la modalità di ACK (acknowledge) adottata è quella di tipo riginal Mode. L ack sincrono sarà normalmente un messaggio di tipo ACK (general acknowledgement), restituito sulla stessa socket aperta dall inviante; questo messaggio verrà considerato implicito nella comunicazione tra i sistemi e quindi non verrà riportato nei diagrammi del documento. Laddove invece l ACK sincrono sia di tipo più strutturato, verrà evidenziato ed il corrispondente dialogo (msg+ack) verrà disegnato in rosso. In ogni caso è richiesto un ack sincrono con valenza applicativa.
Pag.9 2. Architettura di integrazione PNT SCCS ANAGAFE UNICA G2 CUP DE ENTY ADT INTEFACCIA HL7 PIATTAFMA SI Sistema Verticale Erogatore MIDDLEWAE HL7 INTEFACCIA HL7 SISTEMI EGATI EPSITY UNIC DATI SANITAI E AMMINISTATIVI FASCICL PAZIENTE VISE EFETI AEA DI MIDDLEWAE SISTEMA TASVESALE SISTEMA VETICALE SISTEMA DI MIDDLEWAE
Pag.10 3. Integrazione con Anagrafe Unica: Eventi e messaggi Il sistema Verticale mantiene la propria anagrafe allineata con AU ricevendo i messaggi che comunicano i movimento avvenuti in AU. ANAGAFE UNICA ADT^A28 ADT^A31 ADT^A40 VETICALE Inserimento nuova anagrafica: Evento: viene inserita una nuova posizione sull Anagrafe Aziendale Messaggio utilizzato: ADT^A28. Aggiornamento anagrafica: Evento: vengono aggiornati uno o più dati relativi ad una posizione sull Anagrafe Aziendale Messaggio utilizzato: ADT^A31. Fusioni anagrafiche: Evento: viene effettuatom il merge anagrafico sull Anagrafe Aziendale; Messaggio utilizzato: ADT^A40.
Pag.11 4. Scenari relativi alle richieste di prestazioni 4.1. Comunicazione richieste di prestazioni In questo paragrafo vengono considerati gli scenari relativi alle richieste (ordini) di prestazioni siano esse per pazienti interni (inpatient) od esterni (outpatient) (profili IHE di riferimento: SWF, LSWF). Esistono tre sistemi di rder Placer standard aziendali cioè il G2-CUP, G2-rder Entry ed il PS. Il sistema G2-CUP è tipicamente ma non esclusivamente utilizzato per la prenotazioni relative a pazienti non ricoverati; il sistema G2-E è tipicamente ma non esclusivamente dedicato alla registrazione di richieste per pazienti ricoverati. Il PS è utilizzato per pazienti in regime di Pronto Soccorso. Il Sistema Verticale può essere a seconda dei casi rappresentare il sistema richiedente (rder Placer) od il sistema erogatore (rder Filler) delle prestazioni. Per la comunicazione tra i due sistemi si utilizzeranno i messaggi HL7 seguenti: M^01-NW/CA: per flussi di richieste che non prevedono la comunicazione di informazioni relative ai campioni di materiale biologico; ML^33-NW/CA: per i flussi di richieste che prevedono la comunicazione di informazioni relative ai campioni di materiale biologico. In tutti gli scenari sopra descritti vengono generati-gestiti i seguenti eventi- messaggi 1. Inserimento nell rder Placer di un nuovo ordine (non per laboratorio analisi). Viene generato un messaggio M^01 con order control=nw e contenente una coppia di segmenti C-B per ogni prestazione richiesta. 2. Cancellazione di un ordine precedentemente comunicato dall rder Placer (non per laboratorio analisi). Viene generato un messaggio M^01 con order control=ca e contenente una coppia di segmenti C-B per ogni prestazione dell ordine. 3. Inserimento nell rder Placer di un nuovo ordine per il laboratorio analisi. Viene generato un messaggio ML^33 con order control=nw e contenente una coppia di segmenti C-B per ogni prestazione richiesta. 4. Cancellazione di un ordine precedentemente comunicato dall rder Placer Viene generato un messaggio ML^33 con order control=ca e contenente una coppia di segmenti C-B per ogni prestazione dell ordine.
Pag.12 4.2. Comunicazione cambio stato e prestazioni aggiuntive L evento qui considerato è un cambio stato di una o più prestazioni effettuato sul Sistema Verticale (rder Filler). Le prestazioni a cui si fa riferimento sono prestazioni native del Placer, nel senso che appartengono a richieste inserite manualmente nel Placer. Questo evento deve scatenare l invio di un messaggio di tipo M^01 SC/SN. Un messaggio potrà contenere una o più prestazioni (coppie di segmenti C-B) di cui è stato aggiornato lo stato. Il campo C-2 dovrà essere valorizzato con: - SC se è la comunicazione di un cambio stato relativo a prestazione richiesta da G2; - SN se è la comunicazione di una prestazioni aggiuntiva eriogata da aggiungere ad una impegnativa originaria della richiesta registrata in G2 Lo stato della ichiesta nel suo complesso sarà derivazione diretta dello stato delle singole prestazioni che la compongono. Gli stati attualmente previsti: o o o o In esecuzione: significa che la prestazione richiesta è stata presa in carico dal sistema Verticale In questo caso il campo C-5 (rder Status) va valorizzato con IP (In progress) Non erogato: significa che la prestazione richiesta non verrà più erogata In questo caso il campo C-5 (rder Status) va valorizzato con CA (Cancelled) Erogato: la prestazione è stata eseguita. In questo caso il campo C-5 (rder Status) va valorizzato con CM (Completed). efertato: la prestazione è stata refertata. Questo cambio stato verrà impostato alla ricezione del referto (ved. Capitolo 2.6). A seconda dei casi il sistema verticale potrà notificare un unico messaggio con tutte le prestazioni della richiesta legandolo ad un proprio evento consuntivante oppure allineare l rder Placer con più messaggi contenenti le diverse prestazioni della richiesta.
Pag.13 5. Comunicazione risultati e documenti Gli eventi presi in considerazione in questo caso sono - Generazione di un documento firmato l Sistema Verticale Erogatore produce un referto su richiesta prodotta da Sistema ichiedente. Parte un MDM_T02 dal Verticale Erogatore, il referto viene inviato al epository perché sia visualizzabile mediante Visore aziendale; se il caso viene anche trasmesso al ichiedente per l estrazione delle informazioni strutturate. Il referto andrà trasmesso sottoforma di MIME con due body codificati in base 64: 1. Un XML-CDA-2 secondo quanto previsto dal documento di specifica del TSE (ved. [1]) 2. Il foglio di stile per la rendirizzazione in PDF mediante FP (versione 0.94) La possibilitàm di inviare il documento in formato PDF invece che CDA2 deve essere concordato con l Azienda Sanitaria. I referti devono essere firmati elettronicamente secondo l ultimo standard di firma digitale in uso in Italia (attualmente CADES). - Sostituzione/Annullo referto firmato Potrebbe verificarsi la necessità di sostituire/annullare un documento precedentemente inviato al repository. In questo caso il verticale erogatore invierà un messaggio MDM_T10 contenente il referto da revisionare/revocare, in questi messaggi si dovrà indicare oltre all'identificativo del nuovo documento anche di quello vecchio. In caso di cancellazione di pura cancellazione dovrà mandare un documento fittizio con la dicitura CANCELLAT.
Pag.14 6. Gestione codifiche Le codifiche delle strutture (reparti, ospedali, unità di erogazione, agende ecc ) e di tutti i dizionari di base saranno quelle del SI. Per mantenere i diversi sistemi allineati a fronte di variazioni nel sistema centrale delle codifiche si potrà valutare la trasmissione in broadcast deii messaggi HL7 tipicamente utilizzati nell implementazione dei Master Files.
Pag.15 7. Dettaglio messaggi scambiati 7.1. Struttura (segmenti) dei messaggi considerati ACK (acknowledge) Segmento MSH MSA DESCIZINE Message Header Message Aknowledgement ADT^A28 (Nuova Anagrafica) e ADT^A31(Modifica Anagrafica) Segmento MSH EVN PID [PD1] PV1 DESCIZINE Message Header Event Type Patient Identification Additional Demographic Patient Visit ADT^A40 (Merge Anagrafiche) Segmento MSH EVN PID PV1 MG DESCIZINE Message Header Event Type Patient Identification Patient Visit Merge Information M^01- NW/CA (Inserimento-cancellazione richiesta di prestazioni) M^01- SC/SN (Comunicazione cambio stato ed aggiunta prestazioni ad impegnativa, anche laboratorio) Segmento MSH EVN PID PV1 {C} {B} DESCIZINE Message Header Event Type Patient Identification Patient Visit Common rder Segment bservation equest Segment
Pag.16 ML^33 NW/CA (Inserimento-cancellazione richiesta di prestazioni per Laboratorio Analisi) Segmento MSH PID PV1 {SPM} {C} {B} DESCIZINE Message Header Patient Identification Patient Visit Speciment Segment Common rder Segment bservation equest Segment MDM^T02 (comunicazione documento) MDM^T10 (comunicazione nuova versione documento) Segmento MSH EVN PID PV1 {C B} TXA BX DESCIZINE Message Header Event Type Patient Identification Patient Visit Common rder bservation equest Transcription Document Header bservation/esult 7.2. Descrizione puntuale segmenti-campi dei messaggi Nelle tabelle contenute in questo documento e destinate a descrivere la composizione ed i contenuti dei messaggi utilizzati, non si riportano tutte le proprietà (es. data type) dei campi considerati; per tali informazioni ci si riferisca allo standard HL7. I campi non utilizzati non vengono riportati sulle tabelle. I campi data-ora se non diversamente specificato sono nel formato YYYYMMDDHHMMSS. 7.2.1. Descrizione segmenti comuni a tutti i messaggi Vengono qui decsritti i segmenti comuni a tutti i messaggi considerati in questo docuemnto. Sulle stesse tabelle si riporta nella colonna nella colonna PT viene riportata l obbligatorietà o meno della valorizzazione. I valori possibili sono: - (requested): cioè il campo deve essere sempre valorizzato; - (opzionale): il campo può essere valorizzato o meno - C (conditional): obbligatorio se vale qualche altra condizione (da specificare puntualmente) - E (required but can be empty): obbligatorio se l informazione è valorizzata nel sistema di origine
Pag.17 MSH - Message header SEQ PT NME ELEMENT DESCIZINE 1 Field Separator 2 Encoding Characters ^~\& 3 Sending Application Componente HD-1= Codice identificativo applicativo inviante. Es: G2 4 Sending Facility Componente HD-1=Nome società produttrice applicativo inviante. Es: INSIELMECAT 5 eceiving Application Componente HD-1= Codice identificativo applicativo destinatario. 6 eceiving Facility Componente HD-1= Società produttrice applicativo destinatario. 7 Date/Time f Message Data e ora di sistema alla generazione del messaggio 9 Message Type Tipo messaggio come da standard: <codice messaggio>^<trigger event>^<struttura messaggio> (es. ADT^A01^ADT_A01). Il terzo campo viene omesso 10 Message Control ID Identificatore univoco del messaggio che deve essere restituito nel messaggio di ACK. 11 Processing ID P 12 Version ID 2.5 EVN Event type SEQ PT NME ELEMENT DESCIZINE 1 Event Type Code <trigger event> 2 ecorded Date/Time Data e ora di sistema alla generazione del messaggio 6 Event ccurred Data e ora di sistema alla generazione del messaggio MSA Message Acknowledge SEQ PT NME ELEMENT DESCIZINE 1 Acknowledgement Code Assume il valore AA in caso di successo AE o A in caso di errore 2 Message Control ID L ID del messaggio cui si risponde con l ACK (campo MSH-10 del messaggio originale). 3 Text Message Breve descrizione dell errore. Valorizzato solo in caso di fallimento (MSA-1 <> AA )
Pag.18 MSA Message Acknowledge (nel caso di ACK su messaggi MDM) SEQ PT NME ELEMENT DESCIZINE 1 Acknowledgement Code Assume il valore AA in caso di successo AE o A in caso di errore 2 Message Control ID L ID del messaggio cui si risponde con l ACK (campo MSH-10 del messaggio originale). Valorizzato solo in caso di fallimento (MSA-1 <> AA ) 3 Text Message In caso di successo (MSA-1 = AA ) riporta l identificativo assegnato dal repository al documento (numerico lungo al max. 22 cifre). In caso di fallimento (MSA-1 <> AA ) riporta una breve descrizione dell errore. E Error SEQ PT NME ELEMENT DESCIZINE 3 HL7 Error Code Codice errore : come da tabella standard HL7 0357 5 Application Error Code Codice errore interno all applicazione ricevente 7 Diagnostic Information Informazione utile all help desk 8 User Message Descrizione testuale dell errore
Pag.19 PID - Patient identification Il segmento viene utilizzato per comunicare i dati anagrafici del paziente. Tale segmento viene spedito con tutti i messaggi considerati in questo documento in modo da consentire quando richiesto ai sistemi destinatari di inserire od aggiornare l anagrafica in gioco alla ricezione del primo messaggio significativo per lo specifico workflow. Nel caso dell ADT^A40 contiene i dati esaustivi dell anagrafica accorpante. SEQ NME ELEMENT DESCIZINE ADTA28 ADTA31 ADTA40 M01 ML33 M01- SC/SN MDMT02 MDMT10 3 Patient Identifier List Contiene più ripetizioni, ognuna relativa ad una tipologia di codice. Sono obbligatori i componenti CX-1 (ID Number) = ID anagrafico nel senso sotto specificato CX-4 (Assigning Authority) che assume i valori: PK (ID anagrafe aziendale) PK_CUP (ID G2) CF (Codice Fiscale) STP (Codice STP) ENI (Tessera ENI) CX-7: inizio validità (se prevista) SSN (Codice Sanitario) TEAM (tessera TEAM) DIP (ID nel sistema di origine) CX-8: fine validità (se prevista) per PK E per CF, SSN,STP, TEAM, ENI per PK,CF,DIP E per SSN,STP, TEAM, ENI 5 Patient Name Contiene una sola ripetizione del campo con cognome e nome del paziente. XPN-1 = Cognome XPN-2 = Nome XPN-7 = L 6 Mother s Maiden Name Contiene una sola ripetizione del campo con cognome e nome della madre del paziente neonato. XPN-1 = Cognome XPN-2 = Nome 7 Date/Time of Birth Data e ora di nascita (l ora è sempre 0000) 8 Administrative Sex Sesso (M: Maschio, F: Femmina, U: Sconosciuto) 11 Patient Address Indirizzo di residenza, domicilio e luogo di nascita XAD-1 = Indirizzo XAD-2 = Descrizione località XAD-3 = Descrizione Comune o Stato estero XAD-4 = sigla della provincia XAD-5 = CAP XAD-6 = Codice ISTAT nazione XAD-7 = Tipologia indirizzo. L (residenza) H (domicilio) N (nascita) XAD-9 = codice catastale del comune XAD-9 = codice ISTAT Comune o Stato estero (E per residenza e luogo di nascita nel caso di MDM) 13 Phone Number Home XTN-12 = recapiti di telefono non formattati. Attualmente nell anagrafe aziendale è un campo testo per cui il dato viene trasmesso senza formattazione così come compilato dall operatore 16 Marital Status CE-1: Codice Stato Civile (ved. User-defined Table 0001 - Marital Status in fondo al documento) CE-2: Descrizione E E 19 SSN Number Patient Codice SSN paziente 21 Mother s Identifier CX-1: ID anagrafe aziendale della madre CX-4: PK 26 Citizenship Cittandinanza CE-1 = ISTAT cittadinanza CE-2 = descrizione cittadinanza 29 Patient Death Date and Time Data decesso (valorizzato se PID.30= Y ) C 30 Patient Death Indicator Y: se deceduto N: se non deceduto
Pag.20 7.2.2. Descrizione dei segmenti specializzati per messaggi PV1 - Patient visit Contiene dati anagrafici e dati relativi all accesso (episodio). SEQ NME ELEMENT DESCIZINE ADTA28 ADTA31 ADTA40 2 Patient Class I: per richieste collegate a fasce contrattuali per Interni (o pre-post ricovero) : per richieste collegate a fasce contrattuali per Esterni Nel caso mancasse, il valore di default è 7 Attending Doctor Medico di base del paziente XCN-1 = Codice regionale medico XCN-2 = Cognome XCN-3 = nome 19 Visit Number Valori per CX-1: XCN-9 = Codice dell azienda Sanitaria di Assistenza del paziente in 6 cifre (3 cifre del codice della regione + 3 cifre del codice regionale dell azienda sanitaria) se tipo episodio (vedi PV1-50.5) è: - pronto soccorso allora Numero Cartella PS - lista di attesa allora Numero Posizione in Lista - degenza o DH allora Numero Nosologico del ricovero - post ricovero allora Numero Nosologico del ricovero da cui deriva - ambulatoriale allora numero appuntamento CX-4 = Codice dell azienda Sanitaria di 6 cifre (3 cifre del codice della regione + 3 cifre del codice regionale dell azienda sanitaria) M01 ML33 22 Courtesy Code ID pagamento (utilizzato per la verifica del pagamento) E 42 Pending Location Struttura destinataria del referto (G2): PL-1 = Codice G2 PL-11.1 = G2 Può essere concordato l utilizzo dei codici aziendali in vece dei codici G2 50 Alternate Visit ID CX.1= ID episodio 1 CX.2= ID accesso (o contatto o encounter) 2 CX.5= tipo episodio (vedi tabella U-0002) 51 Visit Indicator V M01- SC/SN MDMT02 MDMT10 E E E E E 1 E un id che identifica il singolo episodio all interno di accesso del paziente; può corrispondere ad un episodio di PS, alla degenza all interno di un dato reparto (in caso di ricovero su più reparti, solo una fase dunque del ricovero complessivo), un episodio di lista di attesa ; va utilizzato nella chiamata all applicativo rder Entry di Insiel quando previsto nell ambito del SI in modo che le richieste caricate sia collegate all episodio corrispondente. 2 L accesso o encounter o contatto rappresenta appunto un intero accesso del paziente alla struttura sanitaria e può comporsi di una catena di episodi (PS+DEGENZA ecc..); l id accesso corrisponde al primo id episodio (episodio capostipite)
Pag.21 Contiene identificativo anagrafica accorpata. MG Merge Information SEQ ELEMENT NAME DESCIZINE A40 1 Prior Patient Identifier List ID nell anagrafe aziendale dell anagrafica da accorpare
Pag.22 C Common rder Segment SEQ NME ELEMENT DESCIZINE M 01- NW/CA 1 rder Control Per M^01-NW/CA: NW quando viene creata una nuova richiesta CA quando viene cancellata una richiesta Per M^01-SC/SN: SC quando cambio stato di prestazione G2 SN quando aggiunta di prestazione (utilizzabile solo nei casi previsti dal nomenclatore) 2 Placer rder Number EI-1= ID prestazione richiesta su Placer EI-2 = G2 EI-3 = ID prestazione richiesta su Filler (quando nata su Filler) EI-4 = identificativo del filler/verticale (quando nata su Filler) 3 Filler rder Number ML33: ID ordine/richiesta secondo il formato richiesto dal Laboratorio M01: ID appuntamento ML 33 M MDM T02 01- MDM T10 SC/SN E E 4 Placer Group Number ID ordine/richiesta E 5 rder Status Comunica lo cambio stato dal verticale: IP = prestazione presa in carico (attenzione la presa in carico anche di una sola prestazione della richiesta, blocca la possibilità di cancellare la richiesta dal CUP/E) CA = prestazione non erogata CM = prestazione eseguita Se C-1 = SN allora può valere solo CM Vedi di seguito tabella STATI_DINE che descrive le relazioni tra gli stati delle singole prestazioni e quello della richiesta, anche come è visibile sull E/CUP. 7 Quantity/Timing Indica quantità, data e priorità delle prestazioni associate. TQ-1 = quantità, sempre impostato a 1 TQ-4 = - data schedulata o desiderata per l appuntamento nel caso di M^01 e ML^33 - data esecuzione delle prestazione nel caso di M^01-SC/SN, MDM^T02, MDM^T10 TQ-6 = la priorità, con i valori: S=Urgente nel più breve tempo, =routine, I tre componenti sono opzionali, se non specificati vanno intesi come quantità = 1, data = decisa da order filler, priorità =. 8 Parent rder Id SI che accorpa le due richieste effettuate nella stessa sessione di prenotazione (nel SI è anche chiamato impropriamente id_contatto) 9 Date/Time of Transaction Data-ora evento 10 Entered By Username operatore E 12 rdering Provider Medico richiedente/proscrittore XCN-1 = Codice regionale medico XCN-2 = Cognome XCN-3 = Nome 17 Entering rganization Struttura richiedente G2 (unità organizzativa) CE-1 (Identifier) = codice G2 CE-2 (Text) = descrizione CE-3 = Nome del sistema di codifica valorizzato con G2 E E E 18 Entering Device Workstation
Pag.23 Stato prestazione n Stati altre prestazioni dell ordine Stato ordine su E Stato ordine su CUP ANNULLATA ANNULLATA ANNULLAT ANNULLAT PENTATA IN ESECUZINE PENTATA EGATA NN EGATA PENTAT PENTAT PENTATA IN ESECUZINE EGATA NN EGATA IN ESECUZINE IN ESECUZINE EGATA EGATA EGAT EGAT EFETATA PENTATA IN ESECUZINE EGATA NN EGATA PAZIALMENTE EFETAT EGAT EFETATA EFETATA EFETAT EGAT Tabella 1 - STATI DINE Note Comandabile solo da CUP/E e per tutte le prestazioni assieme (ordine) B bservation equest Segment SEQ NME ELEMENT DESCIZINE M01 ML33 2 Placer rder Number ID prestazione richiesta (lo stesso valore del corrispondente C) 4 Universal Service Prestazione richiesta Identifier CE-1 = codice SI della prestazione CE-2 = descrizione prestazione CE-3 = Nome del sistema di codifica; valorizzato con SI 13 elevant Clinical Info Quesito clinico (testuale su SI) E 18 Placer Field 1 Unità o laboratorio di erogazione 19 Placer Field 2 Stanza di erogazione (Agenda o Lista di Accesso) E 30 Transportation Mode Modalità di trasporto (per interni). Vedi tabella HL7 Table 0124 a fine doc. 31 eason for Study Descrizione del quesito diagnostico codificato su SI E 46 Placer Supplemental Service Information Dati impegnativa (prescrizione) CE-1 (1) = numero prescrizione CE-5 (1) = PESC_NUM CE-1 (2) = data prescrizione CE-5 (2) = PESC_DATA CE-1 (3) = fascia contrattuale CE-3 (3) = G2 CE-5 (3) = PESC_FASCIA CE-1 (4) = codice esenzione CE-3 (4) = EGINALE CE-5 (4) = PESC_ESENZ CE-1(5) = chiave impegnativa (valorizzato anche se non esiste un impegnativa reale ) CE-5(5) = PESC_KEY E E M01-SC/SN MDMT02 MDMT10 E E E E
Pag.24 SPM Speciment Segment SEQ NME ELEMENT DESCIZINE ML^33 1 Set ID SPM Progressivo campione all interno del messaggio 2 Speciment ID ID Campione 4 Speciment Type CWE-1: Chiave Materiale CWE-2: Descrizione Materiale CWE-5: Note Materiale 8 Speciment Source Site CWE-1: Chiave Sede Prelievo 17 Specimen Collection Date/Time CWE-2: Descrizione Sede Prelievo CWE-5: Note Sede Prelievo Data-ora prelievo campione
Pag.25 TXA Transcription Document Header SEQ NME ELEMENT DESCIZINE MDMT02 MDMT10 2 Document Type Tipologia del documento. (1=eferto, 2=Scheda operatoria, 3=Lettera di dimissione, 4=Verbale di pronto soccorso, 10=eferto aperto 11=eferto chiuso ) Eventuali altri tipi di documento dovranno essere concordati. 3 Document Content Presentation Formato del documento: CDA2_XSL_PKCS7 se CDA2 contenuto in mime firmato secondo le specifiche riportate più avanti CDA2_XSL se CDA2 contenuto in mime non firmato secondo le specifiche riportate più avanti PDF_PKCS7 se formato PDF firmato CAdES PDF_ADBE se formato PDF firmato PadES PDF se formato PDF non firmato CDA2 se CDA2 puro CDA2_PKCS7 se CDA2 puro firmato 4 Activity Date/Time Data ora produzione o modifica del eferto 9 riginator Code/Name Medico repertante XCN-1 = Codice regionale medico XCN-2 = Cognome XCN-3 = nome 10 Assigned Document Authenticator Medico che autentica il referto XCN-1 = Codice regionale medico XCN-2 = Cognome XCN-3 = nome E 12 Unique Document Number Chiave univoca ed invariante nel tempo del documento sull applicativo d origine 13 Parent Document Number Chiave univoca sull applicativo d origine dell eventuale documento padre. In taluni casi è possibile concordare che sia utilizzata la chiave del repository restituita nell ack relativo al msg della versione precedente. 14 Placer rder Number Chiave dell ordine nell rder Placer Se il paziente è esente non è valorizzato E E 15 Filler rder Number Identificativo richiesta del dipartimentale 17 Document Completion Status Stato del documento: AN annullato (per il documento sostitutivo annullativo) D documento validato LA Legalmente Valido (firmato digitalmente) 18 Document Confidentiality Code Delega-Consenso-Privacy: N = normal (pubblicabile all MMG) = restricted (non pubblicabile all MMG) V = very restricted (da definire)