Ниже приведённая статья опять же мой вольный перевод сравнения, а точнее указания на недостатки 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, как это декларируется на странице вендора.)