Продолжение статьи про HL7. Начало смотрите здесь.
Как и в прошлой части, мои комментарии италиком под «прим переводчика».

Не смотря на то, что HL7v2 был коммерчески успешным, многие в сообществе HL7 решили улучшить и сам протокол, и методологию его формирования. Большинство согласны, что основные недостатки HL7 V2 следующие:
• Отсутствие согласованной модели данных, которая только подразумевается в стандарте V2.
• Отсутствие формальных методов моделирования данных и сообщений, что приводит к несогласованности в рамках стандарта и к трудности понимания того, как элементы сообщение соотносятся друг с другом (Прим переводчика — кто знает, вспомните группы ORC/OBR/OBX/NTE).
• Отсутствие четко определенных пользовательских ролей и способов их использвания. Без определенния пользовательских ролей, вендор вправе сам выбирать какую часть стандарта поддерживать, а какую нет, что ведёт к разнообразию реализаций одних и тех же клинических функций.
• Отсутствие точности в описании стандарта. То, что было позитивным моментом на начальной стадии становления стандарта стало его головной болью в том смысле, что стандарт поддерживает только те 80% на которые первоначально и расчитывали.

В конце стародавних 90-ых часть HL7 сообщества решило собраться чтобы порешить таки вышеприведённые проблемы. Цели создания нового стандарты были следующие:
• Интернационализация – HL7 V3 должен был быть в состоянии адаптироваться под нужды прочих стран входящих в сообщество HL7.
• Упорядоченная модель данных — HL7 V3 должен был определить какие типы данных он поддерживает для создания приложений.
• Точность в описании стандарта – все недостатки в описании найденные в HL7 V2 предлагалось устранить в новой версии.

По мере того как сообщество HL7 развивало новый стандарт, было решено отказаться от «крышечек» и «палочек» и следующую версию стандарта создать абсолютной новой, по ряду причин не совместимой с HL7v2. В первую очередь, если бы V3 был также обратно совместим с V2 как все версии до этого, то попытка модифицировать типы данных и внедрить пользовательские роли было бы крайне сложно сделать из-за обилия реализаций (legacy systems). Кроме того, стандарту необходимо качественное обновление, чтобы улучшить реализацию клинических интерфейсов.

В 2005 году появилась первая версия HL7 V3 под названием HL7V3 Normative Edition 2005. В середине 2006 следующая. С тех пор развитие стандарта идёт циклически – каждая новая версия проходит три этапа голосования и тестирования в рамках сообщества HL7 и одно нормативное издание для общего пользования.

С самого начала V3 обещал реализовать новый дивный мир с «90 или более процентов» покрытия требований интерфейса. К достоинствам стандарта относится точная модель данных, точность описнаия стандарта и наличие use case.

Что же получилось в результате. Как упомяналось выше, если версия HL7 V2 была создана программистами, то в реализации HL7 V3 поучавствовали правительственные организации и Medical Informatists (для которых я не могу найти русский аналог, прим переводчика). Всё это означает следующий уровень формального моделирования и сложности внутренней структуры и взаимодействия элементов, который радикально выше в V3, по сравнению с V2. (Прим переводчика – Тут имеет смысл заметить, что стандарт HL7 V3 даже повлиял на UML, правда, за давностью лет, я не нашёл какие именно части UML были изменены, чтобы удовлетворять моделям HL7v3.)

Решение HL7 использовать для третей версии формат XML, несовместимый с V2 означает, что существующие V2 интерфейсы не смогут, без существенных изменений, общаться с новыми V3 интерфейсами. (Прим переводчика – Даже если V2 сообщения перевести в их XML представление, что описано в стандарте HL7 Version 2: XML Encoding Rules.) Это ведёт к тому, что все системы должны реализовать оба стандарта, что на практике ведёт к существенному удорожанию разработки и может стать преградой к дальнейшему продвижению стандарта.

В каких случаях имеет смысл использовать HL7 V3.
• Приложения без унаследованных (legacy) систем, когда каждая сторона интерфейса под контролем и нет необходимости реализовывать устаревшие стандарты для совместимости.
• Новые приложения, в которых HL7V2 ни когда не использовался. Такое характерно для стран присоединившихся к HL7 относительно недавно, например, Нидерланды.
• Политически однородная среда – т.е. в условиях когда единый центр принимает решение об использовании того или иного стандарта всеми игроками в определённом регионе, например, National Health Service в Англии или Canadian Institute for Health Informatics в Канаде.

Что касается США, то в настоящий момент HL7V3 не получил большого распросранения. Ежегодный выпуск новой версии стандарта вызывает неуверенность потенциальных вендоров в возможности реализации и постоянного обновления. В данном случае они находятся в состоянии низкого старта, ожидая когда мед учреждения или регулирующие органы потребуют внедрения именно этой версии. Ну и, на часто задаваемый вопрос «исчезнет ли HL7v2 в скором времени?» ответ обычно «нет», поскольку с точки зрения финансов потрачена уйма денег и человеко-часов на его реализацию и поддержку в живом состояннии. (Прим переводчика – что совершенно не так для множества стран вступивших в HL7 после 2005 года.)

Что должен знать разработчик HL7V3:
• Помните, что V3 использует только 5% возможностей стандарта XML.
• Заказчики зачастую не в состоянии оценить требования по реализации HL7v3 (Прим переводчика – Учитывая три группы пользователей, перечисленных в прошлой статье, множество разработчиков также не в состоянии оценить все требования, накладываемые регулирующими органами на разработку клинических интерфейсов. Одно только требование к де-идентификации данных чего стОит.)
• RIM и типы данных в V3 необходимо тщательно изучать. Сравните типы данных V3 и то как эти данные сохраняются в вашей базе данных и отображаются конечному пользователю. Вполне вероятно, что база данных не сохраняет всю информацию, требуемую по стандарту (Прим переводчика – Что очень часто случается с legacy systems.)
• Если создаёте новое приложение, то имеет смысл посмотреть на модель RIM и типы данных V3, в тоже время, ранние попытки использовать их в качестве логической схемы базы данных показали, что такая структура оказывается крайне неэффективной по производительности и впоследствии требует существенной денормализации.
• Использование пользовательских ролей V3 может привести к необходимости реализовать дополнительные функции в вашем приложении.

Прим переводчика – Презентации от Corepoint Health далее перечисляет пункты которые рекомендуется учитывать мед организации, решившей внедрить HL7 V3. Но все пункты достаточно специфичны и основаны на том, что организация уже имеет успешно работающие HL7 V2 интерфейсы на которые потрачены значительные средства и время. Т.е. опять всё упирается в финансы и целесообразность внедрения HL7 V3. Случаи, когда вообще ни каких интерфейсов нет или используются локальные интерфейсы, созданные небольшой группой разработчиков, не рассматриваются.