В данной краткой статье про причины возникновения нового стандарта HL7 FHIR (Health Level 7 — Fast Healthcare Interoperability Resources) и ожидаемые на этом пути трудности.
Данная небольшая статья написана как комментарий к моей предыдущей статье, в частности в той её части, где BC Holmes рассуждает, что «один из способов количественной оценки сложности HL7v3 в подсчёте уровней вложенности типичного сообщения. Оно, как правило, имеет в 5-10 раз больше XML узлов, чем любые другие стандарты основанные на XML, такие как Interactive Financial eXchange (IFX) или Amazon EC2 SOAP API.
Ниже приведённая статья опять же мой вольный перевод сравнения, а точнее указания на недостатки HL7v3 и достоинства HL7 FHIR (Fast Healthcare Interoperability Resources). Статья «The HL7 Games: Catching FHIR» написана BC Holmes (именно так, но поскольку я с ней лично не знаком, то не было возможности спросить, что значит имя «BC»), человеком, которая не на абстрактных примерах, а очень даже конкретно знает об HL7v3, причём с точки зрения реализации многих из его доменов и сообщений.
Ниже приведённая статья — мой вольный перевод сравнительного (достаточно поверхностного) анализа стандартов HL7 и openEHR опубликованной в electronic Journal of Health Informatics 2010 Vol 5 под названием “Putting Health Record Interoperability Standards to Work”. Сама статья, как это принято говорить, любезно предоставлена одним из авторов, правда, ввиду давности публикации, я воздержался от кучи дополнительных вопросов.
В этой небольшой статье хотелось бы затронуть некоторые, может быть для кого-то не совсем очевидные, аспекты тестирования интерфейсов медицинских систем. И хотя чаще всего взаимодействие подобных систем строится на основе одного из протоколов Health Level 7 (HL7), это не обязательное условие, могут быть использованы и другие способы коммуникации (как пример, можно назвать ASTM Continuity of Care Records (CCR) до того, как он был адаптирован HL7 под названием CCD).
Данная короткая статья мой вольный перевод поста на блоге Rene Spronk на тему “Analysis of CDA R2 testing tools — most requirements are neither tested nor respected” [1], которая сама по себе основана на презентации сделанной во время конференции IHIC (International HL7 Interoperability Conference) в Праге в начале 2015 года. [2]
PS. Ссылки на видео и прочие материалы в конце статьи.
Если вы читали книжки про Health Level 7 (HL7) или проходили курсы, или может учавствовали в конференциях, смотрели презентации и т.д. и т.п., то наверняка обращали внимание, что чаще всего они начинаются с утверждения, что основной целью деятельность организации Health Level 7 является улучшение interoperability или интероперабельности.
Среди стандартов Health Level 7 (HL7), не смотря на название организации, есть такие, которые не относятся напрямую к передаче медицинских данных. Стандарт «HL7 EHR-System Functional Model» или «HL7 Функциональная Модель системы ЭМК», вторая версия которого с существенными дополнениями опубликована в апреле 2014 года, относится именно к таким стандартам. Данный стандарт носит нормативный, а не рекомендательный характер, одобрен ANSI в 2007, в 2009 первая версия стандарта, после ревизии ISO и CEN, опубликована как ISO/HL7 10781.
Продолжение статьи про HL7. Начало смотрите здесь. Как и в прошлой части, мои комментарии италиком под «прим переводчика».
Не смотря на то, что HL7v2 был коммерчески успешным, многие в сообществе HL7 решили улучшить и сам протокол, и методологию его формирования. Большинство согласны, что основные недостатки HL7 V2 следующие:
После небольших, несколько специфичных статей, я решил сделать вольный перевод презентации от Corepoint Health про развитие стандартов HL7, с некоторыми моими комментариями. Думаю, это будет полезно и для тех кто знает, чтобы обновить свои знания, и для тех кто не в курсе, что это вообще такое.