HL7 Ускоритель заднего разделителя Ожидаемое поведение

Question

Рассмотрим следующий сегмент PV1 в сообщении HL7V2.

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

Там есть 52 поля. Наша система Meditech всегда отправляет поле 52 (PV1_52_OtherhealthcareProvider) на этом интерфейсе, который он представлял здесь 55555^Doctor^Secondary^H^^Dr^^DOCT2. У меня он настроил, так что разрешить трейливые разделители включены. Как видно, в этом сегменте есть конечный разделитель, однако это после окончательного поля в сегменте, что происходит, чтобы содержать данные, показанные выше.

Это всегда будет так, Meditech всегда добавляет трейлинг-разделитель на этот интерфейс.

Ни один из других сегментов не имеет данных в финальном поле, поэтому мы не столкнулись с ними в этом вопросе, несмотря на них, имеющие трейливые разделители. На сегменте PV1 мы получаем ошибку:

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

.

Оказывается, это связано с конечным разделителем, потому что вручную удаляя разделитель и повторное повторное использование, ошибка не возникает. Кроме того, если я изменим схему для добавления поля Bummy (pv1_53_Extrafield), сообщение разрешено.

Мой вопрос в том, что это: как ожидаемое поведение разрешает трейлинг разделители в этом случае? Предполагается ли допустить трейлирующий разделитель в всех случаев или применяется только к сегментам, где окончательное поле недействительна данных (т. Е.: Дополнительные поля в конце сегмента)?

Answer 1

на приемном трубопроводе вы не можете иметь разделителя после последнего поля в сегменте.Похоже, это ошибка в ускорителе HL7.Это свойство, похоже, имеет некоторое влияние на сторону отправки только то, что слишком только в том случае, если разделители в пределах определенного количества полей.

Я бы предложил справиться с этим в получении компонента трубопровода и поднять его с помощью поддержки Microsoft

Answer 2

Хотя даже HL7 Messaging Стандартная версия 2.6 не Расширить сегмент PV1 с другими полями и, таким образом, ваш исходный код был правильным от точки поддержки только 52 поля сегмента

1. Это прекрасно допустимо расширить протокол обмена сообщениями HL7 с пользовательскими полями и пользовательскими сегментами, предоставляя, что это расширение согласовано всеми вовлеченными сторонами и задокументировано в заявлении «Сильно> HL7» (вы можете найти некоторые объяснения ссылок здесь и здесь )

2. Ваш анализ и код обработки сообщений должен быть совместим как с старыми, так и некоторые будущие версии протокола. Количество сегментов, их имена и порядка и количество полей и количество компонентов в полях могут быть определены и динамически обработаны. Синтаксис сообщений был разработан для его поддержки. Харкодирующие вещи, такие как «Там будет 52 поля в сегменте PV1, независимо от того, что поле версия HL7 MSH-12 содержит« не очень хороший подход, так как он не будет масштабироваться

.. Каково ожидаемое поведение разрешенных притягивающих разделителей в этом случае? ..

Ожидаемое поведение состоит в том, что ваше приложение не будет сбиваться, не будет блокировать обработку данных, если данные проходят через код в другой системе, вы не должны бросать / удалить поля, которые вы не понимаете (это более или менее написано в Спецификация HL7 где-то ..)