Как я могу использовать Mirth-Javascript для удаления разрывов строк в сообщениях HL7? - PullRequest
1 голос
/ 27 марта 2019

HL7-сообщение приходит в Mirth и выдает ошибку «обработки».В самом низу сообщения в формате Raw находится частичная строка, отделенная от строки над ней.Я должен вручную исправить это каждый раз.Я надеюсь использовать Mirth-Javascript в качестве фильтра сообщений, который может это исправить, чтобы все происходило без вмешательства человека.

Ниже фрагмент кода вызывает ошибку.В этом примере это самая последняя строка сообщения HL7.

OBX|68|FT|PT6663&IMP^PET/CT Imaging Whole Body||

||||||F|||202254836969552|||

В настоящее время мое единственное исправление состоит в том, чтобы открыть сообщение HL7 и вручную перейти к разрыву строки и поднять его до строки над ней, чтоявляется частью сегмента.

Сообщение HL7 должно выглядеть следующим образом:

OBX|68|FT|PT1103&IMP^PET/CT Imaging Whole Body||||||||F|||20190327101958|||

Ответы [ 3 ]

0 голосов
/ 29 марта 2019

По вашему вопросу, поле HL7, содержащее разрывы строк, равно OBX(5,1), в котором должно храниться значение наблюдения.

Значение наблюдения может содержать разрывы строк как часть данных. Разрыв строки (<CR> или ASCII 13) является разделителем сегментов по умолчанию. Если это получено как часть данных, будут проблемы при синтаксическом анализе сообщения. Это основная причина проблемы, о которой вы упоминали в вопросе.

Как упомянуто @AlonEitan в комментарии:

Разделитель сегментов не подлежит обсуждению. Это всегда возврат каретки .

В идеале, эти разрывы строк следует заменять их escape-последовательностью при создании сообщения HL7. Более подробная информация об этом уже дана в одном из моих предыдущих ответов здесь .

Итак, ваше входящее сообщение

OBX|68|FT|PT6663&IMP^PET/CT Imaging Whole Body||

||||||F|||202254836969552|||

должно быть на самом деле

OBX|68|FT|PT6663&IMP^PET/CT Imaging Whole Body||\X0D\\X0D\||||||F|||202254836969552|||

По поводу вашего фактического вопроса о том, как это сделать с помощью Mirth / Javascript, в вашем конкретном случае использования не должно быть необходимости. Это преобразование должно быть сделано до отправки сообщения в Mirth. Поэтому тот, кто отправляет вам это сообщение, должен создать его следующим образом.

Во время отображения значения наблюдения в пользовательском интерфейсе вам снова нужно выполнить обратный процесс.

Edit:

Если разрыв строки отличается от <CR> (ASCII 13), то соответствующий HEX следует заменить на \X0D\. Подробности указаны в моем связанном ответе; Я не повторяю это здесь.

0 голосов
/ 12 апреля 2019

Удаление всех разрывов строк было бы подходом, но позже это может стать проблемой, вы можете установить скрипт замены, который вместо '/ n' ищет '| / n |' или подобная строка, таким образом, это решило бы эту конкретную проблему, а также любые другие нежелательные разрывы строк между вертикальными разделителями, хотя это не помогло бы, если бы оно разрывалось где-либо еще, так что имейте это в виду.

0 голосов
/ 28 марта 2019

Удалите все линейные тормоза в препроцессоре канала или сценарии вложения, а затем вставьте их обратно на основе имен сегментов. Лучше всего было бы остановить систему генерации сообщений, вставив линейные тормоза в поле OBX.5.

...