Ниже приведённая статья опять же мой вольный перевод сравнения, а точнее указания на недостатки HL7v3 и достоинства HL7 FHIR (Fast Healthcare Interoperability Resources). Статья «The HL7 Games: Catching FHIR» написана BC Holmes (именно так, но поскольку я с ней лично не знаком, то не было возможности спросить, что значит имя «BC»), человеком, которая не на абстрактных примерах, а очень даже конкретно знает об HL7v3, причём с точки зрения реализации многих из его доменов и сообщений. Тем более, что она была менеджером одного из средств разработки HL7v3.
В связи с этим статья изобилует деталями, так что, если ваш опыт в этой области мал или, тем более, если вы вообще не знакомы с v3, то, зачастую, понять, о чём она говорит, будет весьма трудно. Например, если вы ни когда не использовали средства моделирования RMIM и дальнейшей сериализации в XML схемы, то будет трудно понять, почему возникают проблемы с именованием, когда в модели ActRelationships класс называется «componentOf2», а в XML схеме он же имеет тип «Component6». (Как это сделано, например, в CMET COCT_RM360000UV01 — MedicationOrder Universal. Там же можно найти другие подобные примеры, «subjectOf1» имеет тип «Subject4» и т.д.)
Переводить всю статью BC Holmes я, естественно, не буду, призываю вас к самостоятельному внимательному прочтению. Ниже будут приведены только выжимки из каждого из замечаний и что FHIR может предложить для решения оных. В конце моей статьи будет одна интересная «интересность». Мои комментарии, как и в прошлый раз, в квадратных скобках.
Итак, начнём.
В самом начале BC Holmes утверждает, что ни для кого не должно быть сюрпризом, по крайне мере для тех, кто участвовал в многочисленных реализациях HL7v3 в Канаде, что стандарт v3 практически повсеместно считается провалившимся. В общем случае, я бы утверждала, пишет она, что стандарт не удался по следующим причинам:
• Модели и сообщения HL7v3 гораздо сложнее, чем в любом другом стандарте обмена сообщениями на основе XML.
• Эту сложность невозможно устранить путём написания более толковой и понятной документации, т.к. руководство по реализации должно быть склеено из многочисленных разнообразных источников, таких как документация по UV [universal] реализации [собственно сам v3 стандарт], канадский стандарт на реализацию от Canada Health Infoway, и стандарты и руководства по реализации от конкретных юрисдикций или провинций.
• Стандарту HL7v3 не хватает полезной модели для создания расширений. Так, официальный процесс «ограничения» [constrain] стандарта для нужд конкретной юрисдикции редко достигает требуемых целей. В конечном счёте, все юрисдикции пришли к реализациям, которые в той или иной степени отличаются от опубликованного стандарта, в целях поддержания своих существующих мед процессов.
• Определённые в стандарте HL7v3 типы данных представляют ряд сложностей для реализации HL7v3 совместимых систем. [О типах данных я писал в этой статье.]
• И последнее, терминология оказалось достаточно сложной областью.
Рассмотрим теперь эти утверждения подробнее, пишет Holmes, и рассмотрим, в какой степени FHIR решает указанные проблемы.
Сложность
То, что стандарт HL7v3 слишком сложен, в данный момент должно быть принято как свершившийся факт. Intelliware в этом смысле была первой Кассандрой, которая пророчила об этом ещё в 2007 году, после реализации одного из наших первых POS приложений. С тех пор это эхо отзывалась многократно среди других разработчиков. Так что я уверена, что любой, кто хоть раз сталкивался с реализацией v3, не сомневается в его сложности.
Один из способов количественной оценки этой сложности в подсчёте уровней вложенности типичного v3 сообщения, оно, как правило, имеет в 5-10 раз больше XML узлов [Интересно, что в русской Wiki слово node в статье про XML не встречается ни разу!], чем любые другие стандарты основанные на XML, такие как Interactive Financial eXchange (IFX) или Amazon EC2 SOAP API. Кто-то может сказать, что бизнес процессы в здравоохранении существенно сложнее и семантически богаче, чем в финансовой области и, тем более, в книгоиздательстве. На мой взгляд, проблема не в этом – я имела опыт модернизации системы на базе HL7v2 представленной в XML [сообщение v2 может быть представлено не только палочками и крышечками, но и в XML формате] заменой этого на HL7v3, и видела увеличение сложности на порядок. Так что, скорее всего, это характерная особенность HL7v3. В любом случае, разработчики сталкиваются с сообщениями, уровень сложности которых превышает всё, что они могли видеть до этого. [Интересно, а что скажет разработчик, который видел только v3, а потом перешёл на что-то другое. Вероятно, всё остальное будет как два байта об асфальт.]
Всякий хлам
HL7v3 сообщения часто содержат много ненужного «хлама», наиболее ярким примером которого являются структурные атрибуты «moodCode» и «classCode». В 99% случаев эти атрибуты не имеют ни какого смысла в сообщении. Отрадно видеть, что в FHIR все подобные атрибуты остались за бортом.
Проблемы именования
James Agnew однажды заметил, что в то время как HL7v3 был задуман как рай для medical informatists по моделированию сообщений [Смотри мою статью Что такое HL7], он стал сущим адом для разработчиков. В каком-то смысле процесс моделирования привёл к появлению ненужного «хлама», о чём сказано выше. Более серьёзная проблема в способе именования сущностей в сообщении v3.
Если вы попробуете найти какой-то простой термин, например, «prescription» [рецепт], то вы навряд ли найдете сообщение или его часть с таким названием. Возможно, вы найдете что-то подобное, вроде «activate prescription request», но придётся очень внимательно изучать именование сущностей в данном сообщении, после чего вы, возможно, обнаружите, что рецепт скрывается под именем «combined medication request».
[В статье приводятся примеры, часть которых я поместил в начале моей статьи. От себя лично могу добавить, что возьмите CDA и подумайте, почему в одних классах, например, AssignedEntity атрибут addr предшествует telecom, в то время как в других классах, например, Organization порядок следования тех же атрибутов обратный, т.е. вначале telecom, потом addr. При сериализации в XML порядок следования элементов будет иметь значение и может привести к ошибке.]
К счастью, ясность обозначений полей ресурсов имеет первоочередное значение в FHIR и, даже, такие простые и понятные вещи как «dob» заменены на более интернациональные «birthDate».
Вложенность
Возьмём v3 clinical document messages которые должны использоваться примерно также как документы CDA [Не совсем понятно о чём тут речь, в стандарте несколько доменов имеющих структуру аналогичную CDA, например, Clinical Decision Support, Medical Records и отдельно Clinical Statement как составная часть других моделей.]. В HL7v3 документ спрятан глубоко внутри сообщения, так, изображение или PDF вложен в конструкцию, которая пытается описать структуру неструктурированных данных. Данная конструкция, в свою очередь, вложена в другую конструкцию с мета-данными об авторстве, дате и пациенте. На этом вложенность не кончается, всё это вложено в другие конверты, которые так и называются control act wrapper [полное название Trigger Event Control Act Wrapper] и transport wrapper. Ко всему прочему, сообщение v3, как правило, само по себе завёрнуто в SOAP сообщение. Прям как загадка, завернутая в тайну и помещенная внутрь головоломки.
В отличие от этого, одной из приятных особенностей FHIR является плоское представление сообщения. Даже в самых сложных случаях данные не далее 10-ти уровней вложенности, а чаще всего в 5-ти уровнях от корня сообщения. Такая плоская структура также позволяет избежать дублирования данных, в то время как в HL7v3 возможно воспроизвести данные несколько раз в разных частях сообщения, что особенно характерно для врача, участвующего в лечебном процессе, а также для данных о заболевании, которые могут повторяться в рецептах.
Различные обёртки для v3 были заменены современным стандартом OAuth [Было бы не плохо, если бы кто-то, кто знаком с этим, прокомментировал особенности использования OAuth]. Даже проблема с множественными данными – continuation pointer (дай мне следующие 50 пациентов которые соответствуют критериям поиска) – реализована с помощью существующего стандарта Atom.
Документация
Наличие документации было одной из головных болей HL7v3. Если с другими технологиями проблема в том, что документации не хватает, то в случае с v3 всё как раз наоборот, тут просто гора документации, часто разработанная различными организациями, зачастую недоступная для разработчиков ввиду платного доступа и т.д.
Одна из значимых вещей, которую сделали в FHIR – это разместили всю документации в открытом доступе на сайте. Вероятно ввиду того, что документация по FHIR нацелена на реализацию, она весьма конкретная и изобилует деталями. [Ну, messaging и documents пока что написаны весьма даже поверхностно. Если нужно сделать сложный запрос, не городить же это всё в url, messaging подойдет куда лучше.]
Расширяемость
В общем случае, в HL7v3 мире, специалисты определяют какое-то взаимодействие мед систем и производят на свет описание в виде Model Interchange Format (MIF) файла. Разработчики берут этот файл и создают из него сообщение. [В теории. На практике средств работы с MIF файлам как на пальцах одной руки.] Очень часто возникает необходимость передать данные, которые изначально не заложены в сообщение, и тут начинаются проблемы. [Проблемы начинаются ещё и с тем, что при изменении XML схемы нет возможности отобразить эти изменения в MIF, ни каких автоматизированных средства для этого не предусмотрено. Что мгновенно делает первоначальный MIF не нормативным для конкретной реализации. В частности, по этой же причине CDA MIF представлен в ballot edition, но отсутствует в normative edition — потому, что CDA схема была изменена.]
Возможно из-за первоначальной приверженности к правилу 80/20, в FHIR реализован достаточно хороший механизм для создания расширений. Любой ресурс можно расширить. Расширения имеют простой формат — ключ-значение. Значение может быть как простым типом данных, так и сложным за счёт вложенных расширений.
Могу спорить, что расширения станут одной из самых полезных функций в FHIR.
Типы данных
Работы над HL7v3 начались до того как большинство современных стандартов, таких как XML, появились на свет. Даже не смотря на то, что сообщение HL7v3 представлено в формате XML, HL7v3 ни когда в точности не соответствовал XML. Типы данных один из примеров этому. Например, в HL7v3 определены примитивные типы данных ST (String) и BL (Boolean), которые существенно отличаются от типов данных характерных для XML, в результате чего их трудно использовать с коммерческими средствами разработки.
FHIR, наученный горьким опытом, для примитивных типов данных (boolean, string, date, uri и т.д.) использует всё тоже самое, что и XML. Более сложные типы данных (Address, Coding, Quantity, HumanName и т.д.) основываются на всё тех же примитивных данных. Побочный эффект подобной переделки типов данных в возможности валидации сообщений и тестировании.
Терминология
Терминология – это представление определенных концепций в кодированном виде. Существенное время по реализации мед системы тратится на принятия решений о том, как кодировать концепции. Использовать ли для классификации болезней ICD-10 или SNIOMED CT? А для записи лекарственных средств использовать DIN или RxNorm? Ко всему прочему, для обеспечения совместимости, необходимо решить, как внутренние коды системы соотносятся с внешними словарями [с тем же SNOMED CT].
FHIR не слишком далеко ушёл в использовании терминологии, хотя и избегает использование некоторых видов кодов в сообщении.
Палочки и крышечки
До тех пор, пока мы не увидим достаточно большое решение, основанное на FHIR, мы вряд ли сможем сказать, станет ли FHIR лучшим решением с точки поддержки реальной совместимости, чем HL7v2. Может так статься, что FHIR просто станет средством, которые заменит HL7v2 сообщения более современным REST/JSON аналогом. И даже если так и случится, я всё равно буду заявлять, что FHIR является лучшим решением, чем HL7v2 или HL7v3.
Заключение
Даже не смотря на свою новизну, FHIR кажется более привлекательной альтернативой HL7v3, тем более что он построен на современных стандартах, таки как REST, JSON, OAuth и даже, как ни странно, Atom [Кто хорошо знаком с Atom, объясните, почему это должно быть странно?]. Поэтому для организаций мы рекомендуем:
• Оценить применимость FHIR в вашей среде – даже небольшой proof-of-concept проект может помочь понять насколько стандарт подходит для ваших нужд;
• Лучше использовать FHIR, чем изобретать свой собственный API;
• Избегайте использовать HL7v3 в новых проектах если на то нет объективных причин (существующий код, точки доступа на v3);
• Рассмотреть возможность замены HL7v2 интерфейсов на FHIR.
[На этом статья BC Holmes заканчивается, далее продолжение моей статьи.]
Ну а теперь обещанное «интересное». Имеется комментарий Lloyd McKenzie на замечания BC Holmes. Кто не знает, кто такой Ллойд, это один из активных создателей стандарта HL7v3, в частности, RMIM Designer его детище, а также один из трёх пожарников (FHIR-man) допиливающих напильником стандарт FHIR до его реального использования. Тем интереснее услышать, что он думает. Постараюсь перевести как можно точнее к оригиналу, т.к. его ответ на одном из закрытых форумов Canada Health Infoway и доступа снаружи туда, вроде как, нет. Чтобы было понятнее, Ллойд находится в Канаде, поэтому часть его комментариев относятся к реализации v3 в Канаде.
«Я думаю – [пишет Ллойд] — есть разные способы классифицировать «провал» стандарта. Совершенно точно доказано, что можно реализовать v3 (при должном уровне времени и инвестиций) достигнув как минимум какой-то степени совместимости. С этой точки зрения стандарт можно считать успешным.
Однако есть и другие области, где трудно утверждать об их успешности:
• Поддержка рынком оказалось более чем ограниченная, чем ожидалось первоначально. Помимо CDA, v3 в значительной степени ограничился крупными, финансируемыми государственными структурами, проектами, с серьёзным финансированием, кучей времени и влияния.
• Совместимость весьма проблематична. Канада, Великобритания и Нидерланды реализовали основанную на v3 рецептуру лекарств, но потребуются существенные преобразования сообщений, чтобы достигнуть совместимости [между этими реализациями]. Несколько в меньшей степени, аналогичные проблемы взаимодействия существуют между провинциями в Канаде. Некоторые из них вызваны различными решениями, но тот факт, что введение каждого нового элемента нарушает совместимость, только усложняет проблему.
• С точки зрения разработчиков, довольно трудно найти тех, кто в восторге от лёгкости, скорости и затрат на реализацию совместимости с HL7v3 (или CDA). Среди тех, кто испытывает радость от этого, чаще всего встречаются v3 консультанты. [В частности, такие как я – пишет Ллойд.]
Мне на самом деле нравится v3 с точки зрения его моделирования. Получился очень мощный инструмент моделирования. Но я пришёл к выводу, что методология и стандарты, которые выходят из него не приносят результата сопоставимого с затраченными инвестициями.
Я не утверждаю, что FHIR станет панацеей, он всё ещё в разработке. Но он уже в состоянии решить некоторые проблемы возникающие с v3, такие как сложность обучения, чрезмерно сложные сообщения, различия между сообщениями от разных разработчиков и недостаток механизма расширений. И что гораздо важнее, он набирает значительную силу среди разработчиков в среде, где ни кто не может однозначно сказать «да будет так», где разные разработчики смотрят на примеры и говорят, «а что, и я так смогу». Это совсем не то, что происходило с v3 и в редких случаях происходило с CDA.
Учитывая уже сделанные инвестиции в v3 в Канаде и тот факт, что FHIR ещё не нормативный, было бы преждевременно говорить о миграции существующих реализаций, но вероятно имеет смысл начать исследовать возможность использования FHIR для новых реализаций и решить, подойдёт ли он в случае, когда или если вдруг мы решим перейти на него. (Я думаю FHIR – это единственная возможность когда либо увидеть значительную совместимость систем между различными юрисдикциями.)
В завершении [пишет Ллойд]:
• Я создал многочисленные v3 модели и руководства по реализации, обучал v3 по всему миру и участвовал в реализации нескольких v3 проектов. Я получал весьма неплохо как консультант по v3.
• Теперь я трачу кучу своего времени, и времени моего работодателя, работая над FHIR на добровольной основе. [Далее Ллойд сетует, что в финансовом выражении это приносит мало пользы.] Тем, кто будет реализовывать FHIR, не понадобится такая серьёзная поддержка как в случае с v3. С другой стороны, всё равно будет достаточно много консалтинговой работы по созданию толковых руководств разработчика, достижения консенсуса между заинтересованными сторонами (совместимость, в конце концов, в том, чтобы заинтересованные стороны согласились какую часть информации можно передавать), словарей терминов и так далее.»
=====
Собственно, на этом можно и завершить. Возможно, кто-то ожидал сравнение двух стандартов по пунктам, под микроскопом. Но на сегодняшний день FHIR вызывает больше вопросов, чем ответов; реальных, а не игрушечных, реализаций пока нет, поэтому сравнение провести достаточно сложно. (Из IBS тут никого нет, насколько я понимаю, чтобы рассказать, в какой степени Think!EHR поддерживает FHIR, как это декларируется на странице вендора.)
В связи с этим статья изобилует деталями, так что, если ваш опыт в этой области мал или, тем более, если вы вообще не знакомы с v3, то, зачастую, понять, о чём она говорит, будет весьма трудно. Например, если вы ни когда не использовали средства моделирования RMIM и дальнейшей сериализации в XML схемы, то будет трудно понять, почему возникают проблемы с именованием, когда в модели ActRelationships класс называется «componentOf2», а в XML схеме он же имеет тип «Component6». (Как это сделано, например, в CMET COCT_RM360000UV01 — MedicationOrder Universal. Там же можно найти другие подобные примеры, «subjectOf1» имеет тип «Subject4» и т.д.)
Переводить всю статью BC Holmes я, естественно, не буду, призываю вас к самостоятельному внимательному прочтению. Ниже будут приведены только выжимки из каждого из замечаний и что FHIR может предложить для решения оных. В конце моей статьи будет одна интересная «интересность». Мои комментарии, как и в прошлый раз, в квадратных скобках.
Итак, начнём.
В самом начале BC Holmes утверждает, что ни для кого не должно быть сюрпризом, по крайне мере для тех, кто участвовал в многочисленных реализациях HL7v3 в Канаде, что стандарт v3 практически повсеместно считается провалившимся. В общем случае, я бы утверждала, пишет она, что стандарт не удался по следующим причинам:
• Модели и сообщения HL7v3 гораздо сложнее, чем в любом другом стандарте обмена сообщениями на основе XML.
• Эту сложность невозможно устранить путём написания более толковой и понятной документации, т.к. руководство по реализации должно быть склеено из многочисленных разнообразных источников, таких как документация по UV [universal] реализации [собственно сам v3 стандарт], канадский стандарт на реализацию от Canada Health Infoway, и стандарты и руководства по реализации от конкретных юрисдикций или провинций.
• Стандарту HL7v3 не хватает полезной модели для создания расширений. Так, официальный процесс «ограничения» [constrain] стандарта для нужд конкретной юрисдикции редко достигает требуемых целей. В конечном счёте, все юрисдикции пришли к реализациям, которые в той или иной степени отличаются от опубликованного стандарта, в целях поддержания своих существующих мед процессов.
• Определённые в стандарте HL7v3 типы данных представляют ряд сложностей для реализации HL7v3 совместимых систем. [О типах данных я писал в этой статье.]
• И последнее, терминология оказалось достаточно сложной областью.
Рассмотрим теперь эти утверждения подробнее, пишет Holmes, и рассмотрим, в какой степени FHIR решает указанные проблемы.
Сложность
То, что стандарт HL7v3 слишком сложен, в данный момент должно быть принято как свершившийся факт. Intelliware в этом смысле была первой Кассандрой, которая пророчила об этом ещё в 2007 году, после реализации одного из наших первых POS приложений. С тех пор это эхо отзывалась многократно среди других разработчиков. Так что я уверена, что любой, кто хоть раз сталкивался с реализацией v3, не сомневается в его сложности.
Один из способов количественной оценки этой сложности в подсчёте уровней вложенности типичного v3 сообщения, оно, как правило, имеет в 5-10 раз больше XML узлов [Интересно, что в русской Wiki слово node в статье про XML не встречается ни разу!], чем любые другие стандарты основанные на XML, такие как Interactive Financial eXchange (IFX) или Amazon EC2 SOAP API. Кто-то может сказать, что бизнес процессы в здравоохранении существенно сложнее и семантически богаче, чем в финансовой области и, тем более, в книгоиздательстве. На мой взгляд, проблема не в этом – я имела опыт модернизации системы на базе HL7v2 представленной в XML [сообщение v2 может быть представлено не только палочками и крышечками, но и в XML формате] заменой этого на HL7v3, и видела увеличение сложности на порядок. Так что, скорее всего, это характерная особенность HL7v3. В любом случае, разработчики сталкиваются с сообщениями, уровень сложности которых превышает всё, что они могли видеть до этого. [Интересно, а что скажет разработчик, который видел только v3, а потом перешёл на что-то другое. Вероятно, всё остальное будет как два байта об асфальт.]
Всякий хлам
HL7v3 сообщения часто содержат много ненужного «хлама», наиболее ярким примером которого являются структурные атрибуты «moodCode» и «classCode». В 99% случаев эти атрибуты не имеют ни какого смысла в сообщении. Отрадно видеть, что в FHIR все подобные атрибуты остались за бортом.
Проблемы именования
James Agnew однажды заметил, что в то время как HL7v3 был задуман как рай для medical informatists по моделированию сообщений [Смотри мою статью Что такое HL7], он стал сущим адом для разработчиков. В каком-то смысле процесс моделирования привёл к появлению ненужного «хлама», о чём сказано выше. Более серьёзная проблема в способе именования сущностей в сообщении v3.
Если вы попробуете найти какой-то простой термин, например, «prescription» [рецепт], то вы навряд ли найдете сообщение или его часть с таким названием. Возможно, вы найдете что-то подобное, вроде «activate prescription request», но придётся очень внимательно изучать именование сущностей в данном сообщении, после чего вы, возможно, обнаружите, что рецепт скрывается под именем «combined medication request».
[В статье приводятся примеры, часть которых я поместил в начале моей статьи. От себя лично могу добавить, что возьмите CDA и подумайте, почему в одних классах, например, AssignedEntity атрибут addr предшествует telecom, в то время как в других классах, например, Organization порядок следования тех же атрибутов обратный, т.е. вначале telecom, потом addr. При сериализации в XML порядок следования элементов будет иметь значение и может привести к ошибке.]
К счастью, ясность обозначений полей ресурсов имеет первоочередное значение в FHIR и, даже, такие простые и понятные вещи как «dob» заменены на более интернациональные «birthDate».
Вложенность
Возьмём v3 clinical document messages которые должны использоваться примерно также как документы CDA [Не совсем понятно о чём тут речь, в стандарте несколько доменов имеющих структуру аналогичную CDA, например, Clinical Decision Support, Medical Records и отдельно Clinical Statement как составная часть других моделей.]. В HL7v3 документ спрятан глубоко внутри сообщения, так, изображение или PDF вложен в конструкцию, которая пытается описать структуру неструктурированных данных. Данная конструкция, в свою очередь, вложена в другую конструкцию с мета-данными об авторстве, дате и пациенте. На этом вложенность не кончается, всё это вложено в другие конверты, которые так и называются control act wrapper [полное название Trigger Event Control Act Wrapper] и transport wrapper. Ко всему прочему, сообщение v3, как правило, само по себе завёрнуто в SOAP сообщение. Прям как загадка, завернутая в тайну и помещенная внутрь головоломки.
В отличие от этого, одной из приятных особенностей FHIR является плоское представление сообщения. Даже в самых сложных случаях данные не далее 10-ти уровней вложенности, а чаще всего в 5-ти уровнях от корня сообщения. Такая плоская структура также позволяет избежать дублирования данных, в то время как в HL7v3 возможно воспроизвести данные несколько раз в разных частях сообщения, что особенно характерно для врача, участвующего в лечебном процессе, а также для данных о заболевании, которые могут повторяться в рецептах.
Различные обёртки для v3 были заменены современным стандартом OAuth [Было бы не плохо, если бы кто-то, кто знаком с этим, прокомментировал особенности использования OAuth]. Даже проблема с множественными данными – continuation pointer (дай мне следующие 50 пациентов которые соответствуют критериям поиска) – реализована с помощью существующего стандарта Atom.
Документация
Наличие документации было одной из головных болей HL7v3. Если с другими технологиями проблема в том, что документации не хватает, то в случае с v3 всё как раз наоборот, тут просто гора документации, часто разработанная различными организациями, зачастую недоступная для разработчиков ввиду платного доступа и т.д.
Одна из значимых вещей, которую сделали в FHIR – это разместили всю документации в открытом доступе на сайте. Вероятно ввиду того, что документация по FHIR нацелена на реализацию, она весьма конкретная и изобилует деталями. [Ну, messaging и documents пока что написаны весьма даже поверхностно. Если нужно сделать сложный запрос, не городить же это всё в url, messaging подойдет куда лучше.]
Расширяемость
В общем случае, в HL7v3 мире, специалисты определяют какое-то взаимодействие мед систем и производят на свет описание в виде Model Interchange Format (MIF) файла. Разработчики берут этот файл и создают из него сообщение. [В теории. На практике средств работы с MIF файлам как на пальцах одной руки.] Очень часто возникает необходимость передать данные, которые изначально не заложены в сообщение, и тут начинаются проблемы. [Проблемы начинаются ещё и с тем, что при изменении XML схемы нет возможности отобразить эти изменения в MIF, ни каких автоматизированных средства для этого не предусмотрено. Что мгновенно делает первоначальный MIF не нормативным для конкретной реализации. В частности, по этой же причине CDA MIF представлен в ballot edition, но отсутствует в normative edition — потому, что CDA схема была изменена.]
Возможно из-за первоначальной приверженности к правилу 80/20, в FHIR реализован достаточно хороший механизм для создания расширений. Любой ресурс можно расширить. Расширения имеют простой формат — ключ-значение. Значение может быть как простым типом данных, так и сложным за счёт вложенных расширений.
Могу спорить, что расширения станут одной из самых полезных функций в FHIR.
Типы данных
Работы над HL7v3 начались до того как большинство современных стандартов, таких как XML, появились на свет. Даже не смотря на то, что сообщение HL7v3 представлено в формате XML, HL7v3 ни когда в точности не соответствовал XML. Типы данных один из примеров этому. Например, в HL7v3 определены примитивные типы данных ST (String) и BL (Boolean), которые существенно отличаются от типов данных характерных для XML, в результате чего их трудно использовать с коммерческими средствами разработки.
FHIR, наученный горьким опытом, для примитивных типов данных (boolean, string, date, uri и т.д.) использует всё тоже самое, что и XML. Более сложные типы данных (Address, Coding, Quantity, HumanName и т.д.) основываются на всё тех же примитивных данных. Побочный эффект подобной переделки типов данных в возможности валидации сообщений и тестировании.
Терминология
Терминология – это представление определенных концепций в кодированном виде. Существенное время по реализации мед системы тратится на принятия решений о том, как кодировать концепции. Использовать ли для классификации болезней ICD-10 или SNIOMED CT? А для записи лекарственных средств использовать DIN или RxNorm? Ко всему прочему, для обеспечения совместимости, необходимо решить, как внутренние коды системы соотносятся с внешними словарями [с тем же SNOMED CT].
FHIR не слишком далеко ушёл в использовании терминологии, хотя и избегает использование некоторых видов кодов в сообщении.
Палочки и крышечки
До тех пор, пока мы не увидим достаточно большое решение, основанное на FHIR, мы вряд ли сможем сказать, станет ли FHIR лучшим решением с точки поддержки реальной совместимости, чем HL7v2. Может так статься, что FHIR просто станет средством, которые заменит HL7v2 сообщения более современным REST/JSON аналогом. И даже если так и случится, я всё равно буду заявлять, что FHIR является лучшим решением, чем HL7v2 или HL7v3.
Заключение
Даже не смотря на свою новизну, FHIR кажется более привлекательной альтернативой HL7v3, тем более что он построен на современных стандартах, таки как REST, JSON, OAuth и даже, как ни странно, Atom [Кто хорошо знаком с Atom, объясните, почему это должно быть странно?]. Поэтому для организаций мы рекомендуем:
• Оценить применимость FHIR в вашей среде – даже небольшой proof-of-concept проект может помочь понять насколько стандарт подходит для ваших нужд;
• Лучше использовать FHIR, чем изобретать свой собственный API;
• Избегайте использовать HL7v3 в новых проектах если на то нет объективных причин (существующий код, точки доступа на v3);
• Рассмотреть возможность замены HL7v2 интерфейсов на FHIR.
[На этом статья BC Holmes заканчивается, далее продолжение моей статьи.]
Ну а теперь обещанное «интересное». Имеется комментарий Lloyd McKenzie на замечания BC Holmes. Кто не знает, кто такой Ллойд, это один из активных создателей стандарта HL7v3, в частности, RMIM Designer его детище, а также один из трёх пожарников (FHIR-man) допиливающих напильником стандарт FHIR до его реального использования. Тем интереснее услышать, что он думает. Постараюсь перевести как можно точнее к оригиналу, т.к. его ответ на одном из закрытых форумов Canada Health Infoway и доступа снаружи туда, вроде как, нет. Чтобы было понятнее, Ллойд находится в Канаде, поэтому часть его комментариев относятся к реализации v3 в Канаде.
«Я думаю – [пишет Ллойд] — есть разные способы классифицировать «провал» стандарта. Совершенно точно доказано, что можно реализовать v3 (при должном уровне времени и инвестиций) достигнув как минимум какой-то степени совместимости. С этой точки зрения стандарт можно считать успешным.
Однако есть и другие области, где трудно утверждать об их успешности:
• Поддержка рынком оказалось более чем ограниченная, чем ожидалось первоначально. Помимо CDA, v3 в значительной степени ограничился крупными, финансируемыми государственными структурами, проектами, с серьёзным финансированием, кучей времени и влияния.
• Совместимость весьма проблематична. Канада, Великобритания и Нидерланды реализовали основанную на v3 рецептуру лекарств, но потребуются существенные преобразования сообщений, чтобы достигнуть совместимости [между этими реализациями]. Несколько в меньшей степени, аналогичные проблемы взаимодействия существуют между провинциями в Канаде. Некоторые из них вызваны различными решениями, но тот факт, что введение каждого нового элемента нарушает совместимость, только усложняет проблему.
• С точки зрения разработчиков, довольно трудно найти тех, кто в восторге от лёгкости, скорости и затрат на реализацию совместимости с HL7v3 (или CDA). Среди тех, кто испытывает радость от этого, чаще всего встречаются v3 консультанты. [В частности, такие как я – пишет Ллойд.]
Мне на самом деле нравится v3 с точки зрения его моделирования. Получился очень мощный инструмент моделирования. Но я пришёл к выводу, что методология и стандарты, которые выходят из него не приносят результата сопоставимого с затраченными инвестициями.
Я не утверждаю, что FHIR станет панацеей, он всё ещё в разработке. Но он уже в состоянии решить некоторые проблемы возникающие с v3, такие как сложность обучения, чрезмерно сложные сообщения, различия между сообщениями от разных разработчиков и недостаток механизма расширений. И что гораздо важнее, он набирает значительную силу среди разработчиков в среде, где ни кто не может однозначно сказать «да будет так», где разные разработчики смотрят на примеры и говорят, «а что, и я так смогу». Это совсем не то, что происходило с v3 и в редких случаях происходило с CDA.
Учитывая уже сделанные инвестиции в v3 в Канаде и тот факт, что FHIR ещё не нормативный, было бы преждевременно говорить о миграции существующих реализаций, но вероятно имеет смысл начать исследовать возможность использования FHIR для новых реализаций и решить, подойдёт ли он в случае, когда или если вдруг мы решим перейти на него. (Я думаю FHIR – это единственная возможность когда либо увидеть значительную совместимость систем между различными юрисдикциями.)
В завершении [пишет Ллойд]:
• Я создал многочисленные v3 модели и руководства по реализации, обучал v3 по всему миру и участвовал в реализации нескольких v3 проектов. Я получал весьма неплохо как консультант по v3.
• Теперь я трачу кучу своего времени, и времени моего работодателя, работая над FHIR на добровольной основе. [Далее Ллойд сетует, что в финансовом выражении это приносит мало пользы.] Тем, кто будет реализовывать FHIR, не понадобится такая серьёзная поддержка как в случае с v3. С другой стороны, всё равно будет достаточно много консалтинговой работы по созданию толковых руководств разработчика, достижения консенсуса между заинтересованными сторонами (совместимость, в конце концов, в том, чтобы заинтересованные стороны согласились какую часть информации можно передавать), словарей терминов и так далее.»
=====
Собственно, на этом можно и завершить. Возможно, кто-то ожидал сравнение двух стандартов по пунктам, под микроскопом. Но на сегодняшний день FHIR вызывает больше вопросов, чем ответов; реальных, а не игрушечных, реализаций пока нет, поэтому сравнение провести достаточно сложно. (Из IBS тут никого нет, насколько я понимаю, чтобы рассказать, в какой степени Think!EHR поддерживает FHIR, как это декларируется на странице вендора.)