Comportamento previsto del delimitatore finale dell'acceleratore HL7

Question

Considera il seguente segmento PV1 in un messaggio HL7v2.

PV1|1|E|MYLOC||||55555^Doctor^Doc^D^^Dr^^DOCT|||||||HO||||ER||BC|||||||||||||||||||VALUE||REG|||201406270627||||||||55555^Doctor^Secondary^H^^Dr^^DOCT2|

Ci sono 52 campi lì.Il nostro sistema Meditech invia sempre il campo 52 (PV1_52_OtherHealthcareProvider) su questa interfaccia, che qui è rappresentato da 55555^Doctor^Secondary^H^^Dr^^DOCT2.L'ho impostato in questo modo Consenti delimitatori finali è attivo.Come puoi vedere, in questo segmento è presente un delimitatore finale, Tuttavia questo è dopo il campo finale del segmento, che sembra contenere i dati mostrati sopra.

Sarà sempre così, Meditech aggiunge sempre un delimitatore finale su questa interfaccia.

Nessuno degli altri segmenti contiene dati nel campo finale, quindi non abbiamo riscontrato questo problema, nonostante abbiano delimitatori finali.Sul segmento PV1 riceviamo un errore:

Error happened in body during parsing 
Error # 1
Segment Id: PV1
Sequence Number: 1
Error Number: 100
Error Description: Segment sequence error (Unexpected end of message body found)
Encoding System: HL79999

Risulta che ciò è dovuto al delimitatore finale, poiché rimuovendo manualmente il delimitatore e reinviando, l'errore non si verifica.Inoltre, se modifico lo schema per aggiungere un file manichino (PV1_53_ExtraField), il messaggio è consentito.

La mia domanda è questa:Qual è il comportamento previsto di consentire delimitatori finali in questo caso?Dovrebbe consentire l'inserimento di un delimitatore finale Tutto casi, oppure si applica solo ai segmenti in cui il campo finale è privo di dati (ad esempio:campi aggiuntivi alla fine del segmento)?

Answer 1

Nella pipeline di ricezione non è possibile avere un delimitatore dopo l'ultimo campo nel segmento.Sembra che questo sia un bug nell'acceleratore HL7.questa proprietà sembra avere qualche effetto solo sul lato di invio solo se i delimitatori rientrano nel numero definito di campi.

Suggerirei di gestire questo problema nel componente della pipeline di ricezione e di sollevarlo con il supporto Microsoft

Answer 2

Anche se pari Versione standard di messaggistica HL7 2.6 non estendeva il segmento PV1 con altri campi e quindi il codice originale era corretto dal punto di supportare solo 52 campi di segmenti

1. È perfettamente valido estendere il protocollo di messaggistica HL7 con campi e segmenti personalizzati, a condizione che questa estensione sia concordata da tutte le parti coinvolte e documentata nel Dichiarazione di conformità HL7 (puoi trovare alcuni link esplicativi Qui E Qui)

2. Il codice di analisi ed elaborazione dei messaggi dovrebbe essere compatibile sia con le versioni vecchie che con alcune versioni future del protocollo.Il numero di segmenti, i loro nomi, l'ordine, il numero di campi e il numero di componenti nei campi possono essere determinati e gestiti dinamicamente.La sintassi del messaggio è stata progettata per supportarlo.Cose hardcoding come "ci saranno 52 campi nel segmento PV1 indipendentemente da cosa contiene il campo MSH-12 della versione HL7" non è un approccio molto valido in quanto non sarà scalabile

..Qual è il comportamento previsto di Consenti delimitatori finali in questo caso?..

Il comportamento previsto è che la tua applicazione non si bloccherà, non bloccherà l'elaborazione dei dati, se i dati viaggiano attraverso il tuo codice in un altro sistema non dovresti eliminare/rimuovere campi che non capisci (è più o meno scritto nelle specifiche HL7 in qualche luogo..)