Среди стандартов Health Level 7 (HL7), не смотря на название организации, есть такие, которые не относятся напрямую к передаче медицинских данных. Стандарт «HL7 EHR-System Functional Model» или «HL7 Функциональная Модель системы ЭМК», вторая версия которого с существенными дополнениями опубликована в апреле 2014 года, относится именно к таким стандартам. Данный стандарт носит нормативный, а не рекомендательный характер, одобрен ANSI в 2007, в 2009 первая версия стандарта, после ревизии ISO и CEN, опубликована как ISO/HL7 10781. Стандарт можно свободно скачать на сайте HL7.org под названием HL7 EHR-System Functional Model, Release 2. В стандарт входит описание стандарта и как им пользоваться, и приложение со списком функций.
Прежде чем кто-то из вас побежит его скачивать, минуточку внимания. Данный стандарт несколько сложен для понимания, поскольку ориентирован точно не на программистов, и даже не на бизнес аналитиков, а уровнем несколько повыше. Следующая картинка условно показывает место этого стандарта среди всех других публикуемых HL7.
Т.е., прежде чем начинать знакомиться с функциональной моделью, неплохо бы посмотреть HL7V3 Domain Analysis Model для выбранной вами медицинской области, например, HL7 Version 3 Domain Analysis Model: Emergency Medical Services. Стандарт HL7 Domain Analysis Model содержит большое количество Use Case, Activity и прочих типов UML диаграмм по какой-то конкретной области медицинских услуг (в данном случае неотложная медицинская помощь) и, вероятно, отражает best practice собранную многочисленными экспертами по данному направлению. Стандарт, опять же применительно к Emergency Medical Services, помогает разобраться кто, как и кому передаёт медицинскую информацию в случае оказания неотложной медицинской помощи и транспортировки больного. Аналогичные модели существуют для других областей.
Теперь, когда мы знаем какие основные компоненты системы необходимо будет реализовать, можно воспользоваться следующим стандартом, который и описывается в этой статье, чтобы выяснить какие функции эти компоненты системы должны выполнять в идеальном случае.
Для начала рассмотрим типичные (гипотетические) сценарии, в которых, по мнению самих составителей стандарта HL7 EHR-S FM, он может использоваться. (глава 5 Anticipated Uses стандарта) Приведённые сценарии, понятное дело, отражают заморские реалии.
И так, первый сценарий: Группа докторов, владеющих частной клиникой, использует некую медицинскую систему для финансовых операций: выставление счетов, планирование и прочее, но не хранит в ней ЭМК пациентов. По некоторым причинам данная система в течении последующих 2 лет должна быть обновлена или заменена. Группа докторов берёт стандарт HL7 EHR-S FM и, имея большой практический опыт, начинают смотреть какие функции из раздела Функции Лечебного Процесса больше всего подходят к их идеальной EHR системе. В это время административный персонал клиники изучает список функций из радела Вспомогательные Функции, а технический персонал – из информационной инфраструктуры. Далее они создают Функциональный Профиль объединяющий все эти требования.
Второй сценарий: Некая медицинская информационная система крупного госпиталя была недавно обновлена для соответствия требованиям HIPAA. Однако это обновление не включало поддержку клинических решений, мониторинг производительности системы, отчётность и т.п. Директор по информационным технологиям госпиталя просит группу врачей рассмотреть функции лечебного процесса и функции обеспечения лечебного процесса. В это время IT группа изучает функции информационной поддержки. Далее список был консолидирован и отправлен поставщику информационной системы госпиталя для добавления требуемых функций.
Сценарий третий: Некий поставщих медицинских систем имеет в разработке различные системы поддержки ЭМК ориентированные на крупные госпитали и подобные организации. В то же время компания хотела бы выйти на рынок систем для частных практик и небольших клиник, но в этом случае им надо удовлетворять требованиям Medicare. Кроме требований Medicare компания также хотела бы добавить ряд функций чтобы успешно конкурировать с существующими на этом рынке системами. Рассмотрев список функций в различных секциях стандарта HL7 EHR-S FM, представители компании пришли к выводу, что им требуются совсем небольшие изменения в существующих системах для успешной конкуренции.
Как вы могли заметить, во всех трёх случаях речь идёт о некоем списке функций, который все изучают. И это действительно так. В первой версии стандарта было три секции (или группы), во второй версии их уже 7. Соответственно, количество функций рекомендуемых для типичной медицинской системы также выросло со 140 до 322, а критериев их проверки с 972 до 2310. Представленная ниже картинка показывает, как организованы эти секции (группы функций):
Каждая секция состоит из набора функций, каждая из которых, в свою очередь, может иметь уточняющие подфункции и соответствующие этой функции критерии проверки. Глава 4 Overview and Definition of the Functional Model, рассказывает, как функции представлены в стандарте.
Так, например, Overarching (Общий раздел) содержит всего одну функцию – OV.1 – которая гласит, что критерии проверки данной секции относятся ко всем EHR системам и, следовательно, должны быть включены во все функциональные профили.
Раздел Care Provision (Лечебный Процесс) имеет несколько функций, одна из которых CP.1.1 Manage Patient History имеет 14 подфункций, например, таких как CP.1.1.2 — The system SHALL provide the ability to manage the identity of clinicians involved in patient history elements according to scope of practice, organizational policy, and/or jurisdictional law.
И так далее. Очевидно, что перечислять все функции нет ни какого смысла. Секции и функции, интересные для IT отделов, как всегда находятся в подвале, а именно, Record Infrastructure и Trust Infrastructure. Возможно кто-то захочет познакомиться с ними поближе.
Как было описано в сценариях выше, стандарт не подразумевает, что все перечисленные функции обязательны к реализации в типичной EHR системе, поэтому пользователь стандарта может создать свой собственный Функциональный Профиль выбрав только необходимое в контексте применения какой-то определённой мед системы. Следующая картинка условно показывает такой профиль охватывающий все 7 секций.
В общем случае, реальная EHR система, как утверждают составители стандарта, может соответствовать более чем одному Функциональному Профилю (правда я не совсем понимаю как, что мешает их объединить). Самая большая глава в стандарте, глава 6 Conformance Clause описывает как создавать профили, какую структуру они имеют, как добавлять функции, как выбирать условия проверки, как они должны правильно записываться на английском языке и прочее.
Чтобы не начинать с нуля, на сайте HL7.org, в разделе Standards > EHR Profiles, кроме самого стандарта, можно также скачать уже готовые профили для различных областей, например, HL7 EHR Pharmacist/Pharmacy Provider Functional Profile или HL7 EHR Child Health Functional Profile.
Хотя сам стандарт несколько шире, чем просто перечисление секций и функции, некоторые его части применимы только для англоязычных стран. Например, как упоминалось выше, требования к описаниям требований проверки. Какие слова можно использовать, какие слова нельзя, что они обозначают и прочее. Так, reconcile (согласовывать) не рекомендуется использовать, а вот harmonize (согласовывать) можно, хотя первое встречается сплошь и рядом, а второе вряд ли кто-нибудь припомнит в документации к информационным системам.
Возвращаясь к первой картинке в этой статье. После того, как функции системы определены, в оставшихся двух правых колонках, Сообщения и Документы, находятся технические стандарты HL7 для взаимодействия (передачи данных) с другими системами и представления медицинских данных.
Я сознательно не стал делать обзор по главам стандарта, в этом мало смысла. Самое интересное, на мой взгляд, пройтись по функциям, и посмотреть насколько ваша система соответствует требованиям HL7. Это если вы поставщик мед систем. А если потребитель медицинской системы, то этот же набор функций возможно поможет подготовиться к тендеру.
Прежде чем кто-то из вас побежит его скачивать, минуточку внимания. Данный стандарт несколько сложен для понимания, поскольку ориентирован точно не на программистов, и даже не на бизнес аналитиков, а уровнем несколько повыше. Следующая картинка условно показывает место этого стандарта среди всех других публикуемых HL7.
Т.е., прежде чем начинать знакомиться с функциональной моделью, неплохо бы посмотреть HL7V3 Domain Analysis Model для выбранной вами медицинской области, например, HL7 Version 3 Domain Analysis Model: Emergency Medical Services. Стандарт HL7 Domain Analysis Model содержит большое количество Use Case, Activity и прочих типов UML диаграмм по какой-то конкретной области медицинских услуг (в данном случае неотложная медицинская помощь) и, вероятно, отражает best practice собранную многочисленными экспертами по данному направлению. Стандарт, опять же применительно к Emergency Medical Services, помогает разобраться кто, как и кому передаёт медицинскую информацию в случае оказания неотложной медицинской помощи и транспортировки больного. Аналогичные модели существуют для других областей.
Теперь, когда мы знаем какие основные компоненты системы необходимо будет реализовать, можно воспользоваться следующим стандартом, который и описывается в этой статье, чтобы выяснить какие функции эти компоненты системы должны выполнять в идеальном случае.
Для начала рассмотрим типичные (гипотетические) сценарии, в которых, по мнению самих составителей стандарта HL7 EHR-S FM, он может использоваться. (глава 5 Anticipated Uses стандарта) Приведённые сценарии, понятное дело, отражают заморские реалии.
И так, первый сценарий: Группа докторов, владеющих частной клиникой, использует некую медицинскую систему для финансовых операций: выставление счетов, планирование и прочее, но не хранит в ней ЭМК пациентов. По некоторым причинам данная система в течении последующих 2 лет должна быть обновлена или заменена. Группа докторов берёт стандарт HL7 EHR-S FM и, имея большой практический опыт, начинают смотреть какие функции из раздела Функции Лечебного Процесса больше всего подходят к их идеальной EHR системе. В это время административный персонал клиники изучает список функций из радела Вспомогательные Функции, а технический персонал – из информационной инфраструктуры. Далее они создают Функциональный Профиль объединяющий все эти требования.
Второй сценарий: Некая медицинская информационная система крупного госпиталя была недавно обновлена для соответствия требованиям HIPAA. Однако это обновление не включало поддержку клинических решений, мониторинг производительности системы, отчётность и т.п. Директор по информационным технологиям госпиталя просит группу врачей рассмотреть функции лечебного процесса и функции обеспечения лечебного процесса. В это время IT группа изучает функции информационной поддержки. Далее список был консолидирован и отправлен поставщику информационной системы госпиталя для добавления требуемых функций.
Сценарий третий: Некий поставщих медицинских систем имеет в разработке различные системы поддержки ЭМК ориентированные на крупные госпитали и подобные организации. В то же время компания хотела бы выйти на рынок систем для частных практик и небольших клиник, но в этом случае им надо удовлетворять требованиям Medicare. Кроме требований Medicare компания также хотела бы добавить ряд функций чтобы успешно конкурировать с существующими на этом рынке системами. Рассмотрев список функций в различных секциях стандарта HL7 EHR-S FM, представители компании пришли к выводу, что им требуются совсем небольшие изменения в существующих системах для успешной конкуренции.
Как вы могли заметить, во всех трёх случаях речь идёт о некоем списке функций, который все изучают. И это действительно так. В первой версии стандарта было три секции (или группы), во второй версии их уже 7. Соответственно, количество функций рекомендуемых для типичной медицинской системы также выросло со 140 до 322, а критериев их проверки с 972 до 2310. Представленная ниже картинка показывает, как организованы эти секции (группы функций):
Каждая секция состоит из набора функций, каждая из которых, в свою очередь, может иметь уточняющие подфункции и соответствующие этой функции критерии проверки. Глава 4 Overview and Definition of the Functional Model, рассказывает, как функции представлены в стандарте.
Так, например, Overarching (Общий раздел) содержит всего одну функцию – OV.1 – которая гласит, что критерии проверки данной секции относятся ко всем EHR системам и, следовательно, должны быть включены во все функциональные профили.
Раздел Care Provision (Лечебный Процесс) имеет несколько функций, одна из которых CP.1.1 Manage Patient History имеет 14 подфункций, например, таких как CP.1.1.2 — The system SHALL provide the ability to manage the identity of clinicians involved in patient history elements according to scope of practice, organizational policy, and/or jurisdictional law.
И так далее. Очевидно, что перечислять все функции нет ни какого смысла. Секции и функции, интересные для IT отделов, как всегда находятся в подвале, а именно, Record Infrastructure и Trust Infrastructure. Возможно кто-то захочет познакомиться с ними поближе.
Как было описано в сценариях выше, стандарт не подразумевает, что все перечисленные функции обязательны к реализации в типичной EHR системе, поэтому пользователь стандарта может создать свой собственный Функциональный Профиль выбрав только необходимое в контексте применения какой-то определённой мед системы. Следующая картинка условно показывает такой профиль охватывающий все 7 секций.
В общем случае, реальная EHR система, как утверждают составители стандарта, может соответствовать более чем одному Функциональному Профилю (правда я не совсем понимаю как, что мешает их объединить). Самая большая глава в стандарте, глава 6 Conformance Clause описывает как создавать профили, какую структуру они имеют, как добавлять функции, как выбирать условия проверки, как они должны правильно записываться на английском языке и прочее.
Чтобы не начинать с нуля, на сайте HL7.org, в разделе Standards > EHR Profiles, кроме самого стандарта, можно также скачать уже готовые профили для различных областей, например, HL7 EHR Pharmacist/Pharmacy Provider Functional Profile или HL7 EHR Child Health Functional Profile.
Хотя сам стандарт несколько шире, чем просто перечисление секций и функции, некоторые его части применимы только для англоязычных стран. Например, как упоминалось выше, требования к описаниям требований проверки. Какие слова можно использовать, какие слова нельзя, что они обозначают и прочее. Так, reconcile (согласовывать) не рекомендуется использовать, а вот harmonize (согласовывать) можно, хотя первое встречается сплошь и рядом, а второе вряд ли кто-нибудь припомнит в документации к информационным системам.
Возвращаясь к первой картинке в этой статье. После того, как функции системы определены, в оставшихся двух правых колонках, Сообщения и Документы, находятся технические стандарты HL7 для взаимодействия (передачи данных) с другими системами и представления медицинских данных.
Я сознательно не стал делать обзор по главам стандарта, в этом мало смысла. Самое интересное, на мой взгляд, пройтись по функциям, и посмотреть насколько ваша система соответствует требованиям HL7. Это если вы поставщик мед систем. А если потребитель медицинской системы, то этот же набор функций возможно поможет подготовиться к тендеру.
Домашнее задание
В англоязычной литературе встречаются три типа медицинских систем – EHR, EMR и PHR – которые на русский можно перевести как ЭМК. Из-за этого смысл и функциональность систем теряется. Даже некоторые англоговорящие коллеги иногда путаются в этих терминологиях. Предлагаю вам самим поискать и разобраться в чём их сходство и различие.
Only registered users can participate in poll. Log in, please.
Нужна ли книга для изучения стандарта передачи мед данных HL7V3 на русском языке (английская версия содержит 120 страниц):
41.94% Да, я бы купил.13
51.61% Ну, если халявная, можно глянуть.16
6.45% Я вообще не понимаю о чём это. :)2
31 users voted. 5 users abstained.