В данной краткой статье про причины возникновения нового стандарта HL7 FHIR (Health Level 7 — Fast Healthcare Interoperability Resources) и ожидаемые на этом пути трудности.
И так, в результате критики со стороны сообщества разработчиков (например тут), а также вероятности сокращения финансирования разработки HL7v3 со стороны US HITECH (Health Information Technology for Economic and Clinical Health), январь 2011 ознаменовался новым веянием со стороны Совета Управляющих HL7 на тему о том, как стандарт обмена сообщениями HL7 может быть улучшен. Это развязало руки (и креативность) независимой группе HL7 архитекторов в обсуждении нового подхода обмена информацией в медицинских системах, что первоначально привело к появлению RFH (Resources for Health) позже переименованного в FHIR (Fast Healthcare Interoperability Resources).
Данный новый подход основан на принципах RESTful, как завещал великий Roy Thomas Fielding в своей 5-ой главе. По идее (разработчиков стандарта), FHIR призван упростить и ускорить внедрение HL7 став гораздо проще в реализации и, в тоже время, надежным, и, насколько возможно, основываться на открытых Интернет стандартах.
В отличие от HL7v2 и, в большей степени, от HL7v3, документация FHIR содержит примеры реализации всех артефактов (ресурсов) и ссылки на их использование в сторонних проектах на разных платформах, включая тестовые сервера доступные в Интернете. Группа HL7 утверждает, что HL7v3 всё же не будет выкинут на помойку мёртвых технологий, подчёркивая, что FHIR был создан учитывая опыт с v3.
Процесс разработки FHIR
В то время как HL7v2 разрабатывался по методологии ad hoc (также известная как «как бог на душу положит»), а HL7v3 следовал жёстко прописанному, основанному на моделях, процессу под названием HDF (HL7 Development Framework), FHIR использует инкрементный и итеративный подход к разработке стандарта (обычно так по болоту с кочки на кочку пробираются). Инкрементный подход характеризуется разработкой небольших кусочков стандарта в единицу времени, которые сразу же тестируются и, в случае успеха, инкорпорируются обратно в процесс разработки, после чего весь процесс повторяется.
Артефакты FHIR
FHIR нацелен на определение основных сущностей в медицинской области в качестве ресурсов, чтобы в дальнейшем использовать их в обмене мед данными. Таким образом, каждый ресурс есть отдельная чётко идентифицируемая сущность, например, Patient, Person, Location, Organization и т.д. Спецификация FHIR, доступная по адресу — hl7.org/fhir — описывает следующие атрибуты ресурсов:
• Ресурсы должны иметь чёткие границы, которые соответствуют одной или нескольким логическим областям.
• Ресурсы должны отличаться друг от друга по смыслу, а не по типу использования. Так, возможность различного использования результатов лаб анализов не должна приводить к созданию множества ресурсов.
• Ресурсы должны обладать понятным идентификатором.
• Ресурсы должны представлять достаточно распространённые сущности, чтобы их можно было использовать в различных мед/бизнес областях.
• Ресурсы не должны быть слишком специфичными или слишком подробными, чтобы не препятствовать использованию в различных мед/бизнес областях.
• Ресурсы должны быть взаимоисключающими [Хотя так декларируется, но на практике я этого не вижу, так Patient и Person в каком-то смысле взаимозаменяемы. Возможно, было бы логично если бы ресурс Patient содержал элемент person как ссылку на ресурс Person.] [1]
• Ресурсы должны использовать другие ресурсы, но это должно выливаться не просто в композицию отдельных ресурсов, а создавать новый контент.
• Ресурсы должны быть организованы в логические структуры, основанные на общности ресурсов и с чем они связаны.
• Ресурсы должны быть достаточно большими, чтобы обеспечить значимый контекст. Если ресурс содержит всего пару атрибутов, то скорее всего, он слишком мал, чтобы обеспечить адекватное представление мед данных.
На момент написания этой статьи определено 89 ресурсов и, вероятно, это число будет расти. Пожарники (FHIRman) из HL7 предполагают, что в конечном итоге будет около 150 ресурсов. Заявляется, что разработка ресурсов будет вестись аналогично v3, но при этом представление ресурсов будет оставаться достаточно простым. Напомним, что в HL7v3, структуры аналогичные ресурсам, достаточно давно определены и называются CMET (Common Message Element Types). Если в самой первой версии HL7v3 количество CMET ровнялось 27, то в моей последней версии (NE 2014) их 181. Отсюда можно сделать вывод, что либо не все ресурсы ещё определены, либо пожарники переосмыслили суть некоторых CMET и разработали ресурсы гораздо эффективнее.
Критика FHIR
В среде ориентированной на ресурсы, каковой является FHIR, очень легко реализовать базовые артефакты, их передачу от одной системы к другой и хранение. Любой, немного знакомый с REST архитектурой, может сделать это за несколько минут с тестовыми FHIR серверами. Однако пока не понятно, как простые ресурсы будут объединятся в бОльшие структуры с большим количеством связей. Также, ни чего не говорится о поддержке рабочих процессов в клиниках за пределами стандартных CRUD операций. Это может привести к различиям в реализации и, как мы видели и на примере с HL7v2, и на примере с HL7v3, к отсутствию интероперабельности (проще говоря, совместимости мед систем).
Например, ресурсы относящиеся к набору других ресурсов, такие как Composition или Bundle, достаточно хорошо определены в стандарте, но более сложные агрегаты, как, например, Invoice, не прописаны. (Можно сказать, что подобное и не должно быть прописано в стандарте, но подобные вопросы появятся на первой же неделе реальной реализации бизнес процессов.) На момент написания этой статьи, такие понятия как Document и Message, и их отличия от агрегатов (таких как Composition) также не достаточно ясно прописаны. Более того, утверждается, что FHIR все эти message вообще не нужны, т.к. REST архитектура предназначена для другого.
Однако подобная критика вполне решаема в рамках разработки стандарта и зависит только от участников FHIR группы. А вот что от них не зависит, так это внешние факторы, и их можно проследить на следующем цикле:
1. Разработчики создают стандарт который есть самое лучшее, что можно было придумать на данный момент (так было и с HL7v2, и с HL7v3, и с CDA, и теперь с FHIR). Все рады, все счастливы.
2. Но заставить стандарт размножаться во множестве реализаций достаточно трудная задача и дело тут чаще всего не в используемых технологиях. Что гораздо важнее, показать, как стандарт вписывается в ежедневный рабочий/бизнес процесс организации, учитывая защиту персональных данных, внутриполитические интересы различных групп, демонстрируя возврат инвестиций и т.д. и т.п.
3. Но мы трудностей не боимся, поэтому все как один впрягаются в борьбу за светлое будущее стандарта. Однако эта дорога чаще всего не самая короткая и усеяна трупами разочаровавшихся. Остаются только самые сильные, многих девелоперов охватывает скука.
4. В борьбе с внешними факторами разработчики стандарта не всегда успевают создать достаточное количество средств разработки для работы с самим стандартом. Но им всегда хочется что-то улучшить, поэтому они начинают… смотреть на самые передовые технологии что вокруг них.
5. While (true) возврат на шаг #1.
Как не трудно заметить, второй пункт в этом бесконечном цикле самый важный. Для того, чтобы FHIR стал успешным, некоторые монстры на арене мед систем, в особенности в США, должны решиться реализовать параллельные интерфейсы с поддержкой HL7v2/HL7v3 и FHIR, в надежде, что разработчики перейдут на FHIR по объективным причинам (например, меньшие финансовые затраты на поддержку интерфейса). Думаю, многие смотрят на разработку SMART-on-FHIR от Cerner Corporation именно в таком ракурсе. Сюда же можно отнести Argonaut Project поддерживаемый такими известными игроками как Epic, Cerner, Meditech, McKesson и Mayo Clinic. Также могут быть интересны драфт версии опубликованных IHE профайлов — MHD (Mobile access to Health Documents) и PDQm (Patient Demographics Query for Mobile).
Ну и, в завершении, побаловаться с тестовым FHIR сервером, причём даже код не придётся писать, можно на — fhirtest.uhn.ca – это те же самые ребята, которые пишут HAPI для HL7v2, а теперь и HAPI-FHIR.
Со своей стороны хотелось бы видеть рассказ от ребят с fhirbase о типичной (и не очень) архитектуре HL7 системы основанной на FHIR, желательно с примерами «было так, стало так».
А покамест я пойду тестировать интерфейс клиента, написанного под DOS на чистом С и работающего с майнфреймом такого же возраста. Дымом от FHIR там даже и не пахнет, ни в финансовом плане, ни в техническом. Да и HL7v2 там с очень сильным нестандартным акцентом (от Z-сегментов глаза рябит).
=====
1. Комментарий от Lloyd McKenzie по поводу Patient и Person и почему они так представлены в FHIR DSTU2. "Most systems won't implement Person. Person is intended for systems that maintain Person registries to allow linkage between Patient records, Practitioner records, RelatedPerson records or some combination of the above. Much of the information on Patient is role-specific. Person is role-independent."
И так, в результате критики со стороны сообщества разработчиков (например тут), а также вероятности сокращения финансирования разработки HL7v3 со стороны US HITECH (Health Information Technology for Economic and Clinical Health), январь 2011 ознаменовался новым веянием со стороны Совета Управляющих HL7 на тему о том, как стандарт обмена сообщениями HL7 может быть улучшен. Это развязало руки (и креативность) независимой группе HL7 архитекторов в обсуждении нового подхода обмена информацией в медицинских системах, что первоначально привело к появлению RFH (Resources for Health) позже переименованного в FHIR (Fast Healthcare Interoperability Resources).
Данный новый подход основан на принципах RESTful, как завещал великий Roy Thomas Fielding в своей 5-ой главе. По идее (разработчиков стандарта), FHIR призван упростить и ускорить внедрение HL7 став гораздо проще в реализации и, в тоже время, надежным, и, насколько возможно, основываться на открытых Интернет стандартах.
В отличие от HL7v2 и, в большей степени, от HL7v3, документация FHIR содержит примеры реализации всех артефактов (ресурсов) и ссылки на их использование в сторонних проектах на разных платформах, включая тестовые сервера доступные в Интернете. Группа HL7 утверждает, что HL7v3 всё же не будет выкинут на помойку мёртвых технологий, подчёркивая, что FHIR был создан учитывая опыт с v3.
Процесс разработки FHIR
В то время как HL7v2 разрабатывался по методологии ad hoc (также известная как «как бог на душу положит»), а HL7v3 следовал жёстко прописанному, основанному на моделях, процессу под названием HDF (HL7 Development Framework), FHIR использует инкрементный и итеративный подход к разработке стандарта (обычно так по болоту с кочки на кочку пробираются). Инкрементный подход характеризуется разработкой небольших кусочков стандарта в единицу времени, которые сразу же тестируются и, в случае успеха, инкорпорируются обратно в процесс разработки, после чего весь процесс повторяется.
Артефакты FHIR
FHIR нацелен на определение основных сущностей в медицинской области в качестве ресурсов, чтобы в дальнейшем использовать их в обмене мед данными. Таким образом, каждый ресурс есть отдельная чётко идентифицируемая сущность, например, Patient, Person, Location, Organization и т.д. Спецификация FHIR, доступная по адресу — hl7.org/fhir — описывает следующие атрибуты ресурсов:
• Ресурсы должны иметь чёткие границы, которые соответствуют одной или нескольким логическим областям.
• Ресурсы должны отличаться друг от друга по смыслу, а не по типу использования. Так, возможность различного использования результатов лаб анализов не должна приводить к созданию множества ресурсов.
• Ресурсы должны обладать понятным идентификатором.
• Ресурсы должны представлять достаточно распространённые сущности, чтобы их можно было использовать в различных мед/бизнес областях.
• Ресурсы не должны быть слишком специфичными или слишком подробными, чтобы не препятствовать использованию в различных мед/бизнес областях.
• Ресурсы должны быть взаимоисключающими [Хотя так декларируется, но на практике я этого не вижу, так Patient и Person в каком-то смысле взаимозаменяемы. Возможно, было бы логично если бы ресурс Patient содержал элемент person как ссылку на ресурс Person.] [1]
• Ресурсы должны использовать другие ресурсы, но это должно выливаться не просто в композицию отдельных ресурсов, а создавать новый контент.
• Ресурсы должны быть организованы в логические структуры, основанные на общности ресурсов и с чем они связаны.
• Ресурсы должны быть достаточно большими, чтобы обеспечить значимый контекст. Если ресурс содержит всего пару атрибутов, то скорее всего, он слишком мал, чтобы обеспечить адекватное представление мед данных.
На момент написания этой статьи определено 89 ресурсов и, вероятно, это число будет расти. Пожарники (FHIRman) из HL7 предполагают, что в конечном итоге будет около 150 ресурсов. Заявляется, что разработка ресурсов будет вестись аналогично v3, но при этом представление ресурсов будет оставаться достаточно простым. Напомним, что в HL7v3, структуры аналогичные ресурсам, достаточно давно определены и называются CMET (Common Message Element Types). Если в самой первой версии HL7v3 количество CMET ровнялось 27, то в моей последней версии (NE 2014) их 181. Отсюда можно сделать вывод, что либо не все ресурсы ещё определены, либо пожарники переосмыслили суть некоторых CMET и разработали ресурсы гораздо эффективнее.
Критика FHIR
В среде ориентированной на ресурсы, каковой является FHIR, очень легко реализовать базовые артефакты, их передачу от одной системы к другой и хранение. Любой, немного знакомый с REST архитектурой, может сделать это за несколько минут с тестовыми FHIR серверами. Однако пока не понятно, как простые ресурсы будут объединятся в бОльшие структуры с большим количеством связей. Также, ни чего не говорится о поддержке рабочих процессов в клиниках за пределами стандартных CRUD операций. Это может привести к различиям в реализации и, как мы видели и на примере с HL7v2, и на примере с HL7v3, к отсутствию интероперабельности (проще говоря, совместимости мед систем).
Например, ресурсы относящиеся к набору других ресурсов, такие как Composition или Bundle, достаточно хорошо определены в стандарте, но более сложные агрегаты, как, например, Invoice, не прописаны. (Можно сказать, что подобное и не должно быть прописано в стандарте, но подобные вопросы появятся на первой же неделе реальной реализации бизнес процессов.) На момент написания этой статьи, такие понятия как Document и Message, и их отличия от агрегатов (таких как Composition) также не достаточно ясно прописаны. Более того, утверждается, что FHIR все эти message вообще не нужны, т.к. REST архитектура предназначена для другого.
Однако подобная критика вполне решаема в рамках разработки стандарта и зависит только от участников FHIR группы. А вот что от них не зависит, так это внешние факторы, и их можно проследить на следующем цикле:
1. Разработчики создают стандарт который есть самое лучшее, что можно было придумать на данный момент (так было и с HL7v2, и с HL7v3, и с CDA, и теперь с FHIR). Все рады, все счастливы.
2. Но заставить стандарт размножаться во множестве реализаций достаточно трудная задача и дело тут чаще всего не в используемых технологиях. Что гораздо важнее, показать, как стандарт вписывается в ежедневный рабочий/бизнес процесс организации, учитывая защиту персональных данных, внутриполитические интересы различных групп, демонстрируя возврат инвестиций и т.д. и т.п.
3. Но мы трудностей не боимся, поэтому все как один впрягаются в борьбу за светлое будущее стандарта. Однако эта дорога чаще всего не самая короткая и усеяна трупами разочаровавшихся. Остаются только самые сильные, многих девелоперов охватывает скука.
4. В борьбе с внешними факторами разработчики стандарта не всегда успевают создать достаточное количество средств разработки для работы с самим стандартом. Но им всегда хочется что-то улучшить, поэтому они начинают… смотреть на самые передовые технологии что вокруг них.
5. While (true) возврат на шаг #1.
Как не трудно заметить, второй пункт в этом бесконечном цикле самый важный. Для того, чтобы FHIR стал успешным, некоторые монстры на арене мед систем, в особенности в США, должны решиться реализовать параллельные интерфейсы с поддержкой HL7v2/HL7v3 и FHIR, в надежде, что разработчики перейдут на FHIR по объективным причинам (например, меньшие финансовые затраты на поддержку интерфейса). Думаю, многие смотрят на разработку SMART-on-FHIR от Cerner Corporation именно в таком ракурсе. Сюда же можно отнести Argonaut Project поддерживаемый такими известными игроками как Epic, Cerner, Meditech, McKesson и Mayo Clinic. Также могут быть интересны драфт версии опубликованных IHE профайлов — MHD (Mobile access to Health Documents) и PDQm (Patient Demographics Query for Mobile).
Ну и, в завершении, побаловаться с тестовым FHIR сервером, причём даже код не придётся писать, можно на — fhirtest.uhn.ca – это те же самые ребята, которые пишут HAPI для HL7v2, а теперь и HAPI-FHIR.
Со своей стороны хотелось бы видеть рассказ от ребят с fhirbase о типичной (и не очень) архитектуре HL7 системы основанной на FHIR, желательно с примерами «было так, стало так».
А покамест я пойду тестировать интерфейс клиента, написанного под DOS на чистом С и работающего с майнфреймом такого же возраста. Дымом от FHIR там даже и не пахнет, ни в финансовом плане, ни в техническом. Да и HL7v2 там с очень сильным нестандартным акцентом (от Z-сегментов глаза рябит).
=====
1. Комментарий от Lloyd McKenzie по поводу Patient и Person и почему они так представлены в FHIR DSTU2. "Most systems won't implement Person. Person is intended for systems that maintain Person registries to allow linkage between Patient records, Practitioner records, RelatedPerson records or some combination of the above. Much of the information on Patient is role-specific. Person is role-independent."