Які проблеми, як правило, виникають під час роботи з повідомленнями HL7?

Я тестую продукт для підприємств охорони здоров’я, і ми працюємо з повідомленнями HL7. Я бачив людей, що стогнуть над іншим запитанням щодо проблем із HL7, але не згадуючи конкретики. Чи може хтось дати мені кілька уявлень про те, які питання чи класи проблем ми повинні спеціально шукати?

Ми використовуємо деякі добре використані бібліотеки для розбору. Якщо конкретні питання щодо цього чи того, що ми робимо, буде корисним, будь ласка, повідомте мене в коментарях, і я додам питання, якщо зможу.

Я припускаю, що ви маєте справу з HL7 v2.x

HL7 добровільно надзвичайно гнучка. Це має великі переваги, але також викликає проблеми. Основне правило, яке слід пам’ятати, - це те, що кожна реалізація буде різною. Якщо ви розгортаєте той самий продукт у двох різних середовищах (наприклад, 2 лікарні), правило обміну даними, ймовірно, буде іншим. Ваш продукт повинен бути готовий відповідати цим прихованим вимогам, якщо ви хочете мати можливість масштабувати кількість інтерфейсів HL7, з якими він буде взаємодіяти.

У більшості систем охорони здоров’я, що займаються HL7, ми стикаємося з цим частковим переліком загальних проблем:

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

jlmorin

www.caristix.com

Кілька проблем, які я зіткнувся:

• Деякі організації можуть використовувати різні версії HL7, тому у вас виникнуть проблеми з сумісністю ("кросова хода"). Звичайно, ви зіткнетесь з цим, якщо ви залучитесь до будь-яких міжорганізаційних передач даних.
• Немає семантичного стандарту (для v2.x, я думаю, v3, можливо, почав це вирішувати), тому навіть якщо ви знаєте, які дані повинні бути в певному полі, ви можете не знати точного значення або представлення цих байтів.
• HL7 - це нестандартний стандарт. Він підтримує специфіку продавця, Z-segmentsяка широко використовується і є повністю фірмовою.
• HL7 v2.x (багато значень x все ще використовується в дикій природі) - це формат, що не належить до XML, тому для роботи з ним вам потрібен парсер HL7. (Це ви знаєте, оскільки у вас вже є бібліотека для розбору HL7, включаючи її для інших)

Перше питання - переконатися, що всі знають, що таке HL7.

Це спосіб замінити [медичне | виставлення рахунків | страхування] кодерами та заощадити гроші [аптеки | банку | страхової компанії].

Це зморшки поверх усіх нормальних проблем у розробці програмного забезпечення.

1. Область повзучості
2. Неповні технічні характеристики
3. Недійсні технічні характеристики, які "Неможливо змінити"

Отже, ви звертаєтесь до свого [Аптека | Банк | Страхова компанія], який хоче вичавити всі гроші, які вони можуть від інтерфейсу HL7, до об'єкта, який використовує ваше програмне забезпечення. Ваш договір з закладом, їхній договір з аптекою, [Аптека | Банк | Страхова компанія] не має поняття, як працює ваше програмне забезпечення, заклад не має поняття, що таке HL7, і вас відмітили в аптеці, оскільки вони постійно повідомляють вам, що ваше програмне забезпечення баггі.

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

Якщо ви збираєтесь "платити за HL7", пам’ятайте, що ви також платите за HL [1-6]. Інтерфейс SOAP не HL7. Аналізатор повідомлень HL7 не є HL7, не є генератором повідомлень.