Какие проблемы возникают при работе с сообщениями HL7?

12

Я тестирую продукт для предприятий здравоохранения, и мы работаем с сообщениями HL7. Я видел, как люди стонали по другому вопросу о проблемах с HL7, но не упомянув о специфике. Может ли кто-нибудь дать мне представление о том, какие проблемы или классы проблем мы должны специально искать?

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

testing parsing hl7 Этель Эванс
источник

Ответы:

13

Я предполагаю, что вы имеете дело с HL7 v2.x

HL7 добровольно чрезвычайно гибок. Это имеет большие преимущества, но также создает проблемы. Основное правило, которое нужно иметь в виду, заключается в том, что каждая реализация будет отличаться. Если вы развернете один и тот же продукт в 2 разных средах (например, в 2 больницах), правило обмена данными, вероятно, будет другим. Ваш продукт должен быть готов удовлетворить эти скрытые требования, если вы хотите иметь возможность масштабировать количество интерфейсов HL7, с которыми он будет взаимодействовать.

В большинстве систем здравоохранения, работающих с HL7, мы сталкиваемся с частичным списком общих проблем:

  • Каждая система может интерпретировать значение каждого элемента данных. Также контекст и рабочие процессы могут влиять на семантику. Я видел некоторые системы, использующие номер счета (PID.18) или номер посещения (PV1.19), чтобы определить пациента, который должен был соответствовать некоторым клиническим рабочим процессам. Этот тип семантического разрыва, вероятно, окажет некоторое влияние на то, как система получает эти данные.
  • Обязательно и необязательно: поскольку часть данных может быть обменена для достижения нескольких целей в нескольких различных контекстах, большинство сегментов и полей документированы как необязательные в официальной документации (и некоторых анализаторах). Однако для удовлетворения конкретных рабочих процессов продукты для здравоохранения, вероятно, добавят правила ограничения данных и ослабят некоторые другие. В большинстве случаев для их выявления необходимо проводить индивидуальный анализ.
  • Таблицы: HL7 предоставляет список предлагаемых значений для некоторых полей. Например, предлагаемый список значений для пола имеет длину 6 ... Очевидно, что большинство систем не реализуют все 6, но какова ваша стратегия отображения, если вы получаете такую, которую вы не поддерживаете заранее?
  • Сегменты и поля могут быть настроены: длина поля, типы данных и другие атрибуты определения могут быть настроены. Вам необходимо сопоставить его с известной вам структурой данных без потери важной информации.

jlmorin

www.caristix.com

jlmorin
источник
6

Несколько проблем, с которыми я столкнулся:

  • В некоторых организациях могут использоваться разные версии HL7, поэтому у вас могут возникнуть проблемы с совместимостью («перекрестное прохождение»). Конечно, вы столкнетесь с этим, если будете участвовать в какой-либо межорганизационной передаче данных.
  • Нет никакого семантического стандарта (для v2.x, я думаю, что v3, возможно, начал решать эту проблему), поэтому даже если вы знаете, какие данные должны быть в конкретной области, вы можете не знать точное значение или представление этих байтов.
  • HL7 - это нестандартный стандарт. Он поддерживает специфику производителя, Z-segmentsкоторая широко используется и полностью запатентована.
  • HL7 v2.x (многие значения x все еще используются в дикой природе) является проприетарным форматом, отличным от XML, поэтому для работы с ним вам потребуется анализатор HL7. (Это, вы знаете, так как у вас уже есть библиотека синтаксического анализа HL7, просто включающая ее для других)
ГРАММ__
источник
2
Худшим из них является отсутствие семантики. Когда даже люди, пишущие стандарт, говорят: «Вы могли бы послать X или Y, но Z также действителен», вы знаете, что у вас есть проблема. Что спасает, так это то, что никто, кроме людей, занимающихся анализом, не должен иметь дело со всем набором опций HL7 - каждый имеет дело с небольшим подмножеством, которое фактически получают их клиенты. Это означает, что написание нового акцептора - это процесс открытия (который я сейчас прохожу), а не «реализация стандартного» упражнения. Да, и угадать, какой вариант нужно отправить, чтобы получить желаемый эффект.
@ +1 за ответ, и с помощью я мог бы дать +1 за включение информации для людей, кроме ОП (меня). @moz - хорошая мысль о том, что нужно просто небольшое подмножество. Это именно наша ситуация. Вы также подтверждаете мое подозрение, что сравнение с данными клиента будет ключевым.
Этель Эванс
1
@ethel и @moz, это именно то мышление, которое делает работу с HL7 настолько сложной, пожалуйста, найдите время, чтобы сделать ваши программы настолько гибкими, насколько это возможно, HL7 - это то место, где YAGNI никоим образом не применим.
Питер Тернер
Хорошо, это имеет смысл. Я не думаю, что наше приложение вызовет какие-либо проблемы с YAGNI, так как мы планируем заранее расширить типы сообщений HL7, которые мы можем использовать для обеспечения ценности. Мы знаем, что не знаем, что нам понадобится в будущем.
Этель Эванс
1
Вот почему я фанат использования библиотек с открытым исходным кодом (HAPI / NHAPI) по крайней мере для принимающей стороны. Намного лучше иметь высокий уровень «мы получили правильное сообщение HL7, но не написали код для его обработки», чем «наш парсер не удался, потому что мы не ожидали этого сообщения». К сожалению, все начинают с малого: «мы просто посылаем X и получаем Y», поэтому гораздо проще взломать что-то вместе, чем просто расширять его каждый раз, когда приходит новое требование, пока в конечном итоге оно не рухнет под весом накопленного запаса.
2

Первая проблема - убедиться, что все знают, что такое HL7.

Это способ заменить кодировщики [медицинской | биллинговой / страховой] и сэкономить деньги [аптеке | банку | страховой компании].

Это морщина на вершине всех нормальных проблем в разработке программного обеспечения.

  1. Сфера Creep
  2. Неполные спецификации
  3. Неверные запатентованные спецификации, которые «не могут быть изменены»

Итак, вы связываетесь со своей [Аптекой | Банком | Страховой компанией], которая хочет выкинуть все деньги из интерфейса HL7 в учреждение, которое использует ваше программное обеспечение. Ваш контракт с учреждением, их контракт с аптекой, [Аптека | Банк | Страховая компания] не имеет ни малейшего представления о том, как работает ваше программное обеспечение, учреждение не имеет ни малейшего понятия, что такое HL7, и вы отмечены галочкой в ​​аптеке, потому что они постоянно говорю вам, что ваше программное обеспечение глючит.

Я считаю, что проблема с HL7 в том, что он в основном делается по дешевке. HL7 3.0 может никогда не осуществиться, потому что он никогда не будет превращаться в деньги.

Если вы собираетесь «платить за HL7», помните, что вы также платите за HL [1-6]. Интерфейс SOAP не является HL7. Анализатор сообщений HL7 - это не HL7 и не генератор сообщений.

Питер Тернер
источник
1
HL7 - это гораздо больше, чем просто для аптек. Чаще всего HL7 используется для подключения разрозненных систем, таких как EMR, к биллинговой системе.
Билл
Наш продукт не предназначен для аптек, даже косвенно, и ответ очень предвзятый с небольшой поддержкой ответа.
Этель Эванс
1
@Ethel Я добавлю несколько регулярных выражений, но ты должен быть более конкретным в своем вопросе. Мы делаем больше, чем аптеки, с нашей 100% собственной реализацией HL7, но основной движущей силой развития всегда является «большая фармация», если другие могут воспользоваться широко используемыми спецификациями, то пусть так и будет.
Питер Тернер
@Peter: я попытаюсь быть более конкретным с тем, почему я думаю, что это не полезно. Во-первых, ваша выделенная цитата кажется предвзятой и неподдерживаемой. Во-вторых, пункты в вашем нумерованном списке либо расплывчаты, либо не добавляют того, что другие ответы сказали более четко. В-третьих, ваш пример сценария очень специфичен и не похож на сценарий, с которым я (и, очевидно, другие) имею дело, делая его неинформативным. В-четвертых, ваше заявление о том, что HL7 сделан по дешевке, кажется предвзятым и не поддерживается. В-пятых, я не делаю "HL7", я работаю с сообщениями HL7, поэтому пункт последнего абзаца потерян.
Этель Эванс
2
@ Этель, с какой стати я должен поддержать свои требования, мне совсем не выгодно рассказывать о HL7, что я знаю по опыту работы с несколькими поставщиками за последние годы, так это то, что когда кто-то говорит, что хочет работать с моим программное обеспечение и отправить им «тестовое сообщение», чтобы они могли получить представление о том, как он должен выглядеть, они разработают своего рода ORM вокруг сообщения, и это будет просто работать для этого. Это не хорошо. Если мой ответ кажется отличным от других, это, конечно, не потому, что я не говорю вам правду. HL7 в основном о деньгах.
Питер Тернер