ФЕДЕРАЛЬНОЕ АГЕНТСТВО
ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ
НАЦИОНАЛЬНЫЙ	ГОСТ Р
f СТАНДАРТ \ / РОССИЙСКОЙ	HCO/HL7 10781-
ФЕДЕРАЦИИ	2019

ИНФОРМАТИЗАЦИЯ ЗДОРОВЬЯ

Функциональная модель HL7 системы ведения электронных медицинских карт

Выпуск 2 (ФМ СВ ПЭМК)

(ISO/HL7 10781:2015, IDT)

Издание официальное

Москва Стандартинформ 2019

Предисловие

1    ПОДГОТОВЛЕН Федеральным государственным унитарным предприятием «Российский научно-технический центр информации по стандартизации, метрологии и оценке соответствия» (ФГУП «СТАНДАРТИНФОРМ») на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 468 «Информатизация здоровья»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 29 августа 2019 г. № 577-ст

4    Настоящий стандарт идентичен международному стандарту HCO/HL7 10781:2015 «Информатизация здоровья. Функциональная модель HL7 системы ведения электронных медицинских карт. Выпуск 2 (ФМ СВ ПЭМК)» (ISO/HL7 10781:2015 «Health Informatics — HL7 Electronic Health Records-System Functional Model. Release 2 (EHR FM)». IDT).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА

5    ВВЕДЕН ВПЕРВЫЕ

Правипа применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© ISO, 2015 — Все права сохраняются © Стандартинформ, оформление. 2019

Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Федерального агентства по техническому регулированию и метрологии

II

для операций системы, ее безопасности, эффективности и обеспечения целостности данных, мер защиты неприкосновенности личной жизни и конфиденциальности, а также интероперабельности с другими системами. Функции раздела TI (инфраструктура доверия) являются ключевыми и образующими для всех других функций модели (CP. CPS. POP, AS и RI).

4.2 Функциональные профили

Хотя функциональная модель должна содержать все обоснованно предполагаемые функции СВ ЭМК. она не предназначена быть списком всех функций, содержащихся в конкретной СВ ЭМК. Для ограничения списка функций предусмотренным применением должен использоваться функциональный профиль. В настоящем документе определена функциональная модель и описано общее использование профилей и приоритетов (см. 1.4 «Предполагаемое использование»).

В целом функциональная модель предназначена для описания расширенного набора функций, из которого пользователь может сформировать подмножество. Созданное пользователем подмножество иллюстрирует, что нужно ему в СВ ЭМК В любом конкретном профиле СВ ЭМК будет содержаться только подмножество расширенного набора функций.

Профили Комплексный (Overarching - OV) Оказание медицинской помощи (Care Provision - СР) Поддержка оказания медицинской помощи (Care Provision Support - CPS) Поддержка здоровья населения (Population Health Support - POP) Поддержка администрирования (Administrative Support - AS) Инфраструктура записи (Record Infrastructure - RI) Инфраструктура доверия (Trust Infrastructure - TI)

Рисунок 2 — Профилирование на основе ФМ СВ ЭМК

На рисунке 2 показано, что профиль будет включать все семь разделов функциональной модели, однако в него не обязательно включать все функции и критерии камщого раздела. Профиль может содержать дополнительные функции и критерии, удовлетворяющие требованиям профиля.

Требования к соответствию представляют собой высокоуровневое описание того, что требуется от профилей и реализаций. Его детали в свою очередь ссылаются на другие части стандарта. Требования к соответствию описывают понятия, исключительно важные для понимания и реализации функциональной модели, как например: «Что такое профиль? Что такое критерии соответствия? Как узнать, что является обязательным, а что необязательным?» Требования к соответствию могут также обеспечить взаимодействие между реализующими лицами (изготовителями) и пользователями (покупателями) в части того, что требуется, и наполнить смыслом фразы «профиль, который соответствует» и «система ведения ЭМК. которая соответствует». Кроме того, они служат основой для деятельности по тестированию и сертификации, которая может выполняться организациями, внешними по отношению к HL7.

Дополнительную информацию, относящуюся к правилам выбора и добавлению критериев соответствия при разработке функционального профиля, см. в разделе 7 «Критерии соответствия».

4.3 Компоненты списка функций СВ ЭМК

Список функций СВ ЭМК представляет собой расширенный перечень функций, разбитый на отдельные разделы. Функции описывают поведение системы языком, ориентированным на пользователя, чтобы они были опознаваемы основными участниками СВ ЭМК.

Функции СВ ЭМК могут использоваться для следующих целей:

- Способствовать описанию преимуществ конечного пользователя, например, безопасность пациента. качество и эффективность затрат в терминах стандартных функций СВ ЭМК.

-    Содействовать общему пониманию функций ЭМК. позволяющему разработчикам, изготовителям. пользователям и другим заинтересованным сторонам планировать и оценивать функции СВ ЭМК.

-    Обеспечить инфраструктуру, необходимую для подготовки требований и приложений стандартов следующего уровня, например, описывающих содержание ЭМК, а также кодирование, информационные модели, конструкции и интероперабельность в интересах переносимости информации между подсистемами СВ ЭМК и несколькими СВ ЭМК.

-    Создать стандартизованный метод, с помощью которого каждая сфера применения (страна) может использовать эти функции ЭМК для разных условий оказания медицинской помощи, приложений и приоритетов.

-    Информировать стороны, заинтересованные в поддержке последующего использования данных. первоначально собранных при оказании медицинской помощи (называемого также «вторичным использованием»), о том. какие функции можно ожидать в системе ведения ЭМК.

-    Информировать стороны, заинтересованные в поддержке инфраструктуры медицинской информации, специфичной для сферы применения, о том, какие функции можно ожидать в системе ведения ЭМК.

В функциональной модели HL7 СВ ЭМК каждая функция идентифицирована и описана с помощью указанного ниже набора элементов или компонентов.

Таблица 2 — Пример списка функций

ИД Тип Имя Заявление Описание Критерий соответствия СР1 3 Управление клинической историей Управление компонентами клинической истории пациента, используемыми для представления краткого обзора или подробной информации о здоровье пациента Компоненты клинической истории пациента используются для представления кратких «моментальных снимков» важной информации о состоянии здоровья, включая анамнез пациента, аллергические и побочные реакции, историю лекарственных назначений, проблем пациента, сильные стороны; иммунизацию; медицинское оборудование/из-делия, а также предпочтения пациента и семьи СР1 4 Ф Управление списком проблем Создание и поддержание списков проблем конкретного пациента Список проблем может указывать в том числе хронические заболевания, диагнозы или симптомы, травмы/интоксика-ции (преднамеренные/непред-намеренные), побочное действие лечения (например, лекарств, хирургических операций), функциональные ограничения. посещения или специфичные условия пребывания. диагнозы, или симптомы СР 1.4 К 1. Система ДОЛЖНА обеспечить возможность управлять всеми активными проблемами пациента как дискретными данными СР. 1.4 к 2 Система ДОЛЖНА собирать и предоставлять историю всех проблем пациента

Окончание таблицы 2

ИД Тип Имя Заявление Описание Критерий соответствия СР.1 4 К 3. Система ДОЛЖНА обеспечить возможность управления соответствующими датами, включая дату начала и дату решения проблемы

4.3.1    ИД функции (обязательный подраздел)

Это уникальный идентификатор функции из списка функций (например. СР.1.1), который следует использовать для уникальной идентификации функции при ссылке на нее. ИД функции также используется для идентификации раздела, в который включена функция (СР = раздел Care Provision («Оказание медицинской помощи»)), и иерархии или отношения между функциями (СР.1.1 находится на том же уровне, что СР.1.2. а СР.1.1 является родителем СР. 1.1.1 и потомком СР.1; во многих случаях родитель полностью представлен потомками. Подробное обсуждение и графическое отображение отношения родитель — потомки см. в подразделе 6.6.1 «Иерархическая структура» раздела 6 «Требования к соответствию).

4.3.2    Тип функции (справочный подраздел)

Это обозначение строки как заголовка (Н). функции (F) или критерия соответствия (С). Метка (Т) используется для идентификации нового раздела таблицы и входящих в него функций. Непосредственно с меткой не связаны ни функции, ни критерии.

4.3.3    Имя функции (обязательный подраздел)

Это имя функции; предполагается, что оно уникально в списке функций, но не рекомендуется использовать его для идентификации функции без соответствующего ИД,

Пример — Управление листом лекарственных назначений.

4.3.4    Объявление функции (обязательный подраздел)

Это короткое объявление о назначении данной функции. Его не требуется представлять на структурированном языке, используемом в критериях соответствия (см. ниже). Объявление должно четко идентифицировать назначение и область применения функции.

Пример — Создать и эксплуатировать списки лекарств, специфичные для пациентов.

4.3.5    Описание (справочный подраздел)

Это более подробное описание функции, при необходимости, включающее примеры.

Пример — Листы лекарственных назначений ведутся в точение определенного времени, будь то обращение за амбулаторной помощью, пребывание в стационаре, жизнь пациента. В них хранятся все уместные даты, включая начало медикаментозного лечения, изменение, а также дату окончания лечения. Можно просматривать всю историю медикаментозного лечения по любому препарату, включая альтернативные добавки и лекарственные растения. Листы лекарственных назначений не ограничены рецептами, выписанными поставщиками медицинской помощи, и могут включать, например, сведения об отпуске/поставке из аптеки, лекарства, о приеме которых сообщают пациенты, а также дополнительную информацию, к примеру, специфичную для возраста дозировку.

4.3.6    Критерий соответствия (обязательный подраздел)

Для каждой функции, включенной в список, указаны один или несколько критериев соответствия. Эти критерии, записанные в настоящем стандарте на нормативном языке, описывают требования соответствия функции. Язык описания критерия соответствия хорошо структурирован с помощью стандартизованных компонентов, имеющих определенные значения. Структурированный язык, используемый для определения критериев соответствия в списке функций, определен в подразделах 2.4 «Критерии соответствия» и 2.9 «Иерархия и использование глоссария глаголов действия» раздела «Соответствие».

5 Предполагаемое использование (справочный раздел)

Организация HL7 является международным сообществом и поддерживает разработку функциональных профилей, которые могут быть специфичными для определенной страны спецификациями в рамках данного стандарта (сфера применения HL7). Предполагается, что организация HL7 зарегистри-

рует профили, обозначающие подмножества функций, описанных в модели, предназначенные для применения в специфичных условиях оказания медицинской помощи (например, поведенческое здоровье) или в определенных функциональных областях (например, управление записями и ЭМК. поддерживающая доказательную медицину). Примеры функциональных профилей будут включены в качестве справочных документов в Руководство по созданию функциональных профилей HL7 How-to Guide for Creating Functional Profiles.

5.1    Предполагаемый подход к разработке: функциональные профили

«Функциональный профиль» представляет собой набор избранных функций, применимых для определенной цели, пользователя, условий оказания медицинской помощи, предметной области и т. п. Функциональные профили помогают управлять основным списком функций. Полная функциональная модель не предназначена для применения в какой-либо конкретной реализации СВ ЭМК.

Как таковая, система ведения ЭМК соответствует не непосредственно функциональной модели, а скорее одному или нескольким функциональным профилям. Дополнительную информацию по созданию. регистрации и голосованию по функциональным профилям см. в разделах 2 и 6 главы 2 «Критерии соответствия».

Функциональные профили являются представлением применимых подмножеств функций, описанных в функциональной модели СВ ЭМК. В этой модели читатель увидит длинный список имен и объявлений функций, выступающих в роли обоснованных представлений функций, которые могут потребоваться в клинической среде. Этот список функций не предназначен для использования в своем полном варианте. Например, функции, обозначенные в этой модели, применяются по-разному в разных условиях оказания медицинской помощи. Многие функции, описанные в модели, применимы в условиях частных лечебниц, но некоторые, например, СР.1.7.2.3 (Управление заказами на продукты крови и другие биопрепараты), там применяться не будут. Список функций не считается применимым, пока не создан функциональный профиль, или ограничение.

Создание функционального профиля предназначено для поддержки бизнес-сценария использования СВ ЭМК с помощью выбора применимого подмножества функций из списка функций, определенных в функциональной модели СВ ЭМК. которые в действительности ограничивают модель в соответствии со специфичными требованиями. Например, функциональный профиль может быть создан покупателем для описания требований: изготовителем для описания возможностей специфичных продуктов; любым лицом/субъектом, которому требуется оговорить желательное подмножество функций для конкретной цели, включая условия оказания медицинской помощи в специфичной сфере применения. Когда применимое подмножество функций выбрано, лицо/субъект, создающий профиль, назначает каждой функции приоритет, а именно «essential now» (существенна сейчас), «essential future» (существенна в будущем) или «optional» (необязательная). Дополнительную информацию о шагах по созданию функционального профиля см. в Руководстве HL7 по созданию функциональных профилей и соответствующего инструментария (How-to Guide for Creating Functional Profiles and Related Tooling).

Читатели могут пожелать сосредоточиться на специфичном разделе функциональной модели СВ ЭМК, более подходящим для их повседневной деятельности. Например, клиницист может очень внимательно читать разделы «Оказание медицинской помощи» (Care Provision) и «Поддержка оказания медицинской помощи» (Care Provision Support), в то время как технические специалисты могут сконцентрировать внимание на разделе «Инфраструктура доверия» (Tojst Infrastructure). В рамках организации может быть полезным делегировать ответственность за внимательное ознакомление с различными разделами разным сотрудникам с разными обязанностями и знаниями.

Ниже приведены три зарисовки, помогающие читателям, занимающим различные должности или работающим в разных организациях, представить, как они могли бы изучать и применять функциональную модель СВ ЭМК.

5.1.1    Сценарий 1 — групповая практика

Д-р Смит является участником групповой практики из 50 человек. Практика в настоящее время располагает клинической информационной системой, обеспечивающей выставление счетов, ведение расписаний и другую административную поддержку. В силу ряда причин ее нужно модифицировать или заменить в течение 2 лет. Электронные медицинские карты в ней отсутствуют. Д-р Смит и заинтересованные коллеги анализируют зарегистрированный профиль Ambulatory Саге (амбулаторная помощь), чтобы посмотреть, как условия применения и сценарии иллюстрируют функции ЭМК. релевантные их практике. Они смотрят на приоритеты отдельных функций этого профиля, которые установила группа 8

экспертов, работающая с организацией HL7. Получив хорошее понимание значений функций ЭМК для его практики, д-р Смит и несколько других поставщиков медицинской помощи переходят к разделам «Оказание медицинской помощи» (Care Provision) и «Поддержка оказания медицинской помощи» (Саге Provision Supporl), в то время как административный персонал клиники знакомится с разделом «Административная поддержка» (Administrative Support), а персонал технической поддержки изучает раздел «Инфраструктура доверия» (Trust Infrastructure). Затем все они встречаются для обсухщения своих выводов. Они планируют использовать список функций в ходе обсумщений своей будущей информационной системы с изготовителями, понимая, что некоторые функции еще не будут доступны.

5.1.2    Сценарий 2 — больница

Г-н Джонс занимает должность директора по информационным технологиям в крупной больнице. Два года назад в ней была установлена информационная система, обеспечивающая учет движения пациентов и ввод заказов. Она была модифицирована в целях соответствия закону США HI РА A (Health Insurance Portability and Accountability Act — Закон об ответственности и переносе данных о страховании здоровья). Она не обеспечивает поддержку принятия клинических решений, мониторинг показателей или санитарно-эпидемиологическую отчетность. Г-н Джонс просит главного врача организовать анализ функциональной модели HL7 СВ ЭМК. при этом его персонал также изучает ее. Они оба начинают с профиля Acute Саге (лечение острых заболеваний), поставленного на голосование, чтобы посмотреть, как группа экспертов, работающая с организацией HL7, идентифицировала возможное использование СВ ЭМК в больнице. В этом профиле весьма полезны сценарий и определение приоритетов отдельных функций. Главный врач, несколько врачей и старших медсестер анализируют разделы функциональной модели СВ ЭМК «Оказание медицинской помощи» (Care Provision) и «Поддержка оказания медицинской помощи» (Care Provision Support), представленные в профиле Acute Саге; директора по информационным технологиям и его персонал концентрируют внимание на разделе «Инфраструктура доверия» (Trust Infrastructure), посвященном инфраструктуре треста, но просматривают и разделы «Оказание медицинской помощи» и «Поддержка оказания медицинской помощи». Небольшая группа поставщиков медицинской помощи и специалистов по информационным технологиям встречаются для обсуждения своих выводов. Они планируют использовать список функций в переговорах с изготовителями на предмет добавления в существующую систему функций поддержки принятия решений, мониторинга показателей и санитарно-эпидемиологической отчетности, признавая, что их бюджет позволит лишь незначительное расширение в ближайшее время.

5.1.3    Сценарий 3 — изготовитель информационных систем

Г-жа Грин возглавляет отдел клинических информационных систем крупной компании, занимающейся информатизацией здравоохранения. Их линия продуктов включает системы, специализирующиеся на ведении ЭМК. и интегрированные системы, обеспечивающие ведение ЭМК. Все эти системы обеспечивают некоторую поддержку принятия решений о лекарственных назначениях, но в них отсутствуют функции отчетности и мониторинга показателей. Хотя большинство их клиентов являются крупными медицинскими организациями и больницами, тем не менее компания планирует распространить свою деятельность на рынки небольших практик и медицинской помощи на дому, предложив простую и более дешевую клиническую информационную систему. В преддверии реализации закона о реформе организации Medicare, осуществляемой HHS (U.S. Department of Health & Human Services — Министерство здравоохранения и социального обеспечения США) и предполагающей финансовые стимулы для поставщиков медицинской помощи, использующих информационные технологии для учета движения пациентов, компания предполагает добавить в свои продукты ряд функций, которые выполняпи бы или даже превышали требования системы Medicare. Г-жа Грин просит своих сотрудников проанапизиро-вать весь пакет функциональной модели HL7 СВ ЭМК. а также ознакомиться с примерами профилей для условий оказания медицинской помощи, включенных в качестве приложений в Руководство HL7 How-to Guide for Creating Functional Profiles and Related Tooling. На основе примеров функционапьных профилей, предназначенных для различных условий оказания медицинской помощи, они смогли определить. что можно добавить к разным продуктам достаточно небольшое количество функций и превратить их в высококачественные продукты, которые можно предлагать нынешним и будущим клиентам. Они понимают ценность функциональной модели СВ ЭМК для переговоров со своими клиентами о модификациях или новых приобретениях.

5.2 Примеры текущего использования

5.2.1    Функциональный профиль для клинического исследования, основанный на ФМ СВ ЭМК

Ниже приведен текст пресс-релиза HL7 от ноября 2009 г, демонстрирующий отраслевое применение:

Энн Арбор, Мичиган. США — 5 ноября 2009 года — Health Level Seven® (HL7®), всемирный орган по интероперабельности и стандартам в области медицинской информационной технологии, объединяющий членов из 57 стран, сегодня объявил о публикации первого стандарта, утвернщенного ANSI (American National Standards Institute — Американский национальный институт стандартов), описывающего функциональные требования к системам ведения электронных медицинских карт (СВ ЭМК). используемых при проведении регистрируемых клинических исследований. Функциональный профиль HL7 EHR Clinical Research основан на функциональной модели системы ведения ЭМК. выпуск 1, разработанной Рабочей группой к HL7 EHR и также утвержденной ANSI в качестве американского национального стандарта.

В функциональном профиле EHR Clinical Research описаны высокоуровневые требования, критичные для использования данных электронных медицинских карт при проведении регистрируемых клинических исследований, и представлена дорожная карта интеграции информационной среды, которая должна поддерживать как медицинскую помощь пациенту, так и нижележащие процессы клинических исследований. Согласно Дональду Мону, доктору наук (Donald Mon, PhD), сопредседателю Рабочей группы HL7 EHR и члену совета директоров HL7. «этот профиль является великолепной демонстрацией того, как важные функциональные требования к вторичному использованию данных, например, в клинических исследованиях, могут быть интегрированы в рабочий процесс оказания пациенту медицинской помощи и документироваться в системах ведения ЭМК». Поставщики технологий фармацевтических, биотехнологических, клинических исследований, поставщики технологий медицинской помощи, а также заинтересованные лица из федеральных уполномоченных органов США и Европейского союза сотрудничали в течение двух лет в целях идентификации и анализа широкого списка требований к защите данных, а также регуляторных и этических требований к исследованиям. Функциональный профиль EHR Clinical Research также является ресурсом для комиссии CCHIT (Certification Commission for Healthcare Information Technology — Сертификационная комиссия no медицинским информационным технологиям) Рабочей группы по клиническим исследованиям (Clinical Research Work Group), поскольку он определяет новые критерии сертификации клинических исследований для систем ведения ЭМК. Этот функциональный профиль будет дополнен спецификацией интероперабельности по клиническим исследованиям ЭМК. которая в настоящее время разрабатывается HITSP (Health Information Technology Standards Panel — Совет по стандартам медицинских информационных технологий). Кроме того, д-р Ребекка Куш, президент и генеральный директор CDISC (Clinical Data Interchange Standards Consortium — Консорциума по стандартизации обмена клиническими данными), заявила в своем комментарии. что «CDISC удовлетворен тем. что является компаньоном и вносит свой вклад в стандарты по клиническим исследованиям и понятиям обмена данными eSource навстречу этим инициативам. Конечная цель заключается в ускорении темпа, в котором исследования информируют сферу здравоохранения о преимуществах, получаемых пациентами, и этот функциональный профиль вносит свой вклад в достижение этой цели».

5.2.2    AHRQ объявляет о формате детских электронных медицинских карт

Ниже представлен отрывок из пресс-релиза от февраля 2013 года, демонстрирующего отраслевое применение функционального профиля HL7 Child Health: http^/www.ahrq.gov/news/newsroom/press-releases/2013/chiki3MKpr.html

Преимущества электронных медицинских карт (ЭМК) могут стать более доступными при лечении детей с помощью внедрения формата ЭМК для педиатрической медицинской помощи, объявленного сегодня AHRQ (US. Department of Health and Human Services’ Agency for Healthcare Research and Quality — Управление no исследованиям и качеству здравоохранения Министерства здравоохранения и социальных служб США) и CMS (Centres for Medicare and Medicaid Services — Центры служб Medicare и Medicaid)... Использование ЭМК продолжает улучшать качество и безопасность медицинского обслуживания в США. однако многие существующие системы ведения ЭМК не приспособлены для сбора или обработки информации о здоровье детей. Объявленный сегодня формат ЭМК для педиатрической медицинской помощи предлагает рекомендации по элементам данных, специфичным для детей, например. прививки, а также функциональность, которая позволит разработчикам ЭМК расширить их про-

дукты и включить модули, адаптированные для детей ААР (American Academy of Pediatrics — Американская академия педиатрии) и American Academy of Family Physicians (Американская академия семейных врачей). Формат построен на основе спецификаций из источников, включающих в себя функциональную модель Health Level Seven International (HL7®) СВ ЭМК. функциональный профиль Child Health Рабочей группы HL7 Child Health, и инструментальное средство Health IT for Children Администрации по здравоохранению и услугам (Health Resources and Services Administration) Министерства здравоохранения и социальных служб США.

См. ссылку ниже для доступа к копии документа «Children’s EHR Format» http://healthit.ahrq.gov/ childehrFormat.

5.2.3 Связывание описаний клинического содержания с ФМ СВ ЭМК (справочный подраздел)

Организация HL7 продолжает инициативные работы по связыванию описаний клинического содержания с функциями и критериями в ФМ СВ ЭМК. Эта связь может стать полезной входной информацией для разработчиков систем ведения ЭМК. Примерами таких описаний клинического содержания служат модели DAM (Domain Analysis Model — модель анализа предметной области) и модели DCM (Detailed Clinical Model — детальная клиническая модель). Кахадый из этих примеров может быть связан с применимыми разделами ФМ СВ ЭМК. Например, модель DAM Care Plan (план ведения) может быть соединен с функциями планирования медицинской помощи в разделах «Оказание медицинской помощи» (Care Provision) и «Поддержка оказания медицинской помощи» (Care Provision Support) ФМ СВ ЭМК.

На более детальном уровне модели DCM могут быть связаны со специфичными функциями, описанными в ФМ СВ ЭМК или в функциональных профилях СВ ЭМК. Например, модель DCM для шкалы Алгар может быть связана с СР.3.1 «Провести оценку» и CPS 3.1 «Поддержать стандартные оценки». Другим примером является использование модели DCM артериального давления с СР.3.2 «Управлять клиническими измерениями пациента».

На уровне элементов данных, которые могут быть указаны в модели DCM или в таблице данных, связь с ФМ СВ ЭМК обычно осуществляется с помощью отдельного критерия, например, критерия «Система ДОЛЖНА обеспечить возможность сбора жизненно важных показателей здоровья, включая артериальное давление, температуру, пульс и частоту дыхания в качестве дискретных элементов структурированных или неструктурированных данных» в СР.3.2 «Управлять клиническими измерениями пациента».

В заключение, аналогично функции Т4 «Стандартная терминология и терминологические службы». функция может быть создана для моделей DCM и служб моделей DCM. Работу этой функции можно было бы рассмотреть в следующей версии ФМ СВ ЭМК.

6 Требования к соответствию

6.1    Введение (справочный подраздел)

Ниже представлены Требования к соответствию, утверхщенные Рабочей группой EHR. В качестве важной базовой информации по соответствию необходимо помнить следующее:

1.    Настоящие требования к соответствию определяют, что означает «соответствовать функциональной модели СВ ЭМК».

2.    Соответствие функциональной модели определяется для функциональных профилей предметной области, а также для функциональных профилей-компаньонов Система ведения ЭМК соответствует не непосредственно функциональной модели, а скорее одному или нескольким функциональным профилям.

3.    Критерии соответствия ассоциированы с функциями, описанными в функциональной модели СВ ЭМК.

4.    Настоящие требования к соответствию не указывают процедуры тестирования или валидации для определения, соответствует ли СВ ЭМК функциональному профилю, либо соответствует ли функциональный профиль функциональной модели СВ ЭМК.

6.2    Область действия и сфера применения (обязательный подраздел)

Настоящие требования к соответствию определяют минимальные требования к функциональным профилям, для которых объявлено соответствие ФМ СВ ЭМК. Они также идентифицируют варианты, которыми системы ведения ЭМК достигают соответствия функциональной модели, что возможно че-

рез соответствие системы конкретному профилю функциональной предметной области, нескольким функциональным профилям или сочетанию профилей предметной области и профи лей-компаньонов. Настоящие требования к соответствию указывают:

5.    Назначение, структуру и использование критериев соответствия, которые должны быть включены в функциональную модель и функциональные профили, соответствующие функциональной модели.

6.    Правила определения функциональных профилей, соответствующих функциональной модели.

7.    Отношения между функциональными профилями и системами ведения ЭМК.

8.    Примеры требований к соответствию и сценарии вариантов использования.

9.    Рекомендации по требованиям соответствия, которые функциональный профиль может наложить на системы ведения ЭМК.

10.    Рекомендации по назначению и использованию объявления соответствия системы ведения

ЭМК.

Поскольку требования соответствия функциональных профилей могут быть найдены в данных требованиях к соответствию, то они обязательно дают ссылку на функциональную модель и другие источники.

Настоящие требования к соответствию не указывают процедуры тестирования или валидации для определения, соответствует ли функциональный профиль функциональной модели. Кроме того, они не указывают процедуры тестирования или валидации для определения, соответствует ли система ведения ЭМК функциональному профилю или совпадает с его объявлением соответствия.

6.3 Понятия (обязательный подраздел)

6.3.1 Функциональные профили

Создание функционального профиля представляет собой метод определения подмножеств функциональной модели. Функциональный профиль является спецификацией, использующей функциональную модель для указания, какие функции требуются, желательны или реализуются в определенных системах ведения ЭМК. условиях оказания медицинской помощи либо для других целей (например, профиль для управления записями и доказательной поддержки ЭМК).

Функциональные профили могут быть созданы участниками сообщества здравоохранения, заинтересованными в использовании и/или предоставлении функционального профиля для системы ведения ЭМК. Функциональные профили могут указывать функциональность, которая требуется и желательна для определенных условий оказания медицинской помощи или приложений, либо отражает функциональность, встроенную в систему ведения ЭМК изготовителя.

(Примечание — При создании профиля может быть важным обсуждение клинических процессов и/или взаимодействия участников медицинской помощи В международном стандарте ИСО 13940 «System of concepts to support continuity of care* (Система понятий no обеспечению непрерывности ухода за больным) представлена схема ключевых принципов и процессов предоставления медицинской помощи Крайне желательно проанализировать этот стандарт как часть вашей работы )

После определения функциональный профиль может быть реализован системами ведения ЭМК или послужить основой для создания производных функциональных профилей. Производный функциональный профиль представляет собой функциональный профиль, который создан из существующего функционального профиля, наследуя функции базового (существующего) функционального профиля.

Имеются два типа функциональных профилей. Функциональный профиль предметной области является общим типом профиля, используемого для описания системы ведения ЭМК. ориентированного на использование в одних или нескольких условиях оказания медицинской помощи или на описание систем ведения ЭМК, предназначенных для использования в конкретной сфере в целях выполнения правил, норм и стандартов, применимых к этой сфере. Функциональные профили-компаньоны представляют собой тип профиля, который в обязательном порядке должен быть соединен с одним или несколькими профилями предметной области. Профиль-компаньон должен придать уникальные возможности системе ведения ПЭМК. например, в целях проведения исследований или поддержки доказательной медицины. Например, многим системам ведения ЭМК. используемым в клиниках, не требуется обеспечение поддержки клинических исследований. У клиники, проводящей передовые научные исследования, может существовать потребность в системе ведения ЭМК, имеющей все функции, необхо-12

димые при оказании обычной медицинской помощи, но в дополнение к ним обладающей уникальными возможностями для сбора дополнительных данных, требуемых для научных статей и клинических испытаний.

В ФМ СВ ПЭМК имеются два типа обязательного наследования. Все функциональные профили предметных областей наследуют все функции раздела «Комплексный» (Overarching) и связанные с ними критерии «ДОЛЖЕН». Все критерии, перечисленные в родительской функции, будут применимы ко всем потомкам этой родительской функции.

Существует официальный процесс регистрации и голосования по функциональным профилям. Функциональные профили, представленные в Рабочую группу HL7 EHR с аттестацией соответствия разделу 6 «Требования к соответствию» стандарта HL7 ФМ СВ ЭМК. в случае успешного рассмотрения в рабочей группе получают обозначение «Зарегистрированные функциональные профили». Зарегистрированные функциональные профили, которые проходят тщательное публичное обсуждение о придании им статуса справочных на уровне рабочей группы по процедуре достижения консенсуса, принятой организацией HL7, обозначаются как справочные функциональные профили предметной области или профили-компаньоны организации HL7. Затем справочные функциональные профили HL7 проходят процесс голосования полным составом комитета в соответствии с процедурой достижения консенсуса, принятой организацией HL7. Дополнительную справочную информацию о регистрации функциональных профилей или голосовании по ним см. в руководстве How То Guide for Profiles (в стадии разработки).

6.3.2    Модель соответствия

Соответствие функциональной модели определяется для функциональных профилей. Функциональный профиль предметной области соответствует либо (1) непосредственно функциональной модели, либо (2) другому функциональному профилю предметной области, имеющему соответствие. Примечание: Все функциональные профили предметных областей должны содержать все функции раздела «Комплексный» (Overarching) и связанные с ними критерии «ДОЛЖЕН». Система ведения ЭМК не соответствует функциональной модели непосредственно: вместо этого она соответствует функциональному профилю предметной области или сочетанию профиля предметной области и избранного профиля-компаньона. Таким образом, для функциональных профилей объявляется соответствие функциональной модели, а для систем ведения ПЭМК объявляется соответствие одному или нескольким соответствующим функциональным профилям предметных областей. Для системы ведения ПЭМК также может быть объявлено соответствие функциональному профилю предметной области в сочетании с одним или несколькими профилями-компаньонами. Для нее не может быть объявлено соответствие только профилю-компаньону. Эти соотношения показаны на рисунке 3.

6.3.3    Прослеживаемость профиля

Функциональные профили добавляют функциональной модели специфичность и расширяемость с помощью изменений, допускаемых для базовых функций ФМ и критериев. Правила таких изменений определены в разделе 6 настоящей главы. Требуется также прослеживать любые изменения и дополнения. Для этой цели в описание профиля добавлены две графы. В одной графе для каждого элемента нового профиля документируется уникальный номер строки источника, взятого из функциональной модели (или исходного профиля для производного профиля). Во второй графе приведены коды типа изменений по отношению к источнику, взятому из функциональной модели (или исходного профиля). Вместе обе эти графы прослеживания обеспечивают указание источников функций или критериев, а также того факта, были ли выполнены модификации (или нет) по сравнению с функциональной моделью или исходным профилем. Это может быть важным, когда возникают вопросы, например, откуда он появился, почему вы выбрали или модифицировали его. и т. п. Также полезно иметь обратную прослеживаемость к функциям и критериям функциональной модели, если необходимы пересмотры профиля или производного профиля, отражающие условия оказания медицинской помощи, нормативные и технологические изменения, или в связи с предстоящим переходом на новый выпуск функциональной модели.

6.4 Нормативный язык (обязательный подраздел)

Следующие ключевые слова (т. е. нормативные глаголы) ДОЛЖНЫ использоваться при описании требований соответствия.

-    ДОЛЖЕН (SHALL) — для обозначения обязательного требования, которое должно быть выполнено (реализовано), чтобы соответствовать Синоним — «требуется».

-    НЕ ДОЛЖЕН (SHALL NOT) — для обозначения запрещенного действия. Синоним — «запрещено».

-    ПО ВОЗМОЖНОСТИ ДОЛЖЕН (SHOULD) — для обозначения необязательного рекомендуемого действия, которое пригодно, в частности, без упоминания и исключения других действий. Синоним — «разрешено и рекомендовано».

-    МОЖЕТ (MAY) — для обозначения необязательного, допустимого действия. Синоним — «разрешено».

Содержание

1    Область применения.................................................................1

2    Нормативные ссылки.................................................................2

3    Термины и определения..............................................................3

4    Общий обзор и определение функциональной модели (обязательный)........................3

4.1    Разделы списка функций..........................................................4

4.2    Функциональные профили.........................................................5

4.3    Компоненты списка функций СВ ЭМК................................................5

5    Предполагаемое использование (справочный раздел).....................................7

5.1    Предполагаемый подход к разработке: функциональные профили........................8

5.2    Примеры текущего использования..................................................10

6    Требования к соответствию...........................................................11

6.1    Введение (справочный подраздел)..................................................11

6.2    Область действия и сфера применения (обязательный подраздел).......................11

6.3    Понятия (обязательный подраздел).................................................12

6.4    Нормативный язык (обязательный подраздел).........................................14

6.5    Критерии соответствия (обязательный подраздел).....................................15

6.6    Структура и расширяемость функциональной модели (обязательный подраздел)...........16

6.7    Соответствие функционального профиля (обязательный подраздел)......................17

6.8    Варианты использования и примеры (справочный подраздел)...........................22

7    Глоссарий..........................................................................27

7.1    Предисловие (справочный подраздел)...............................................27

7.2    Введение (обязательный подраздел)................................................27

7.3    Краткий обзор (справочный подраздел)..............................................27

7.4    Структура глаголов действия (обязательный подраздел)................................28

7.5    Рекомендации по применению (справочный подраздел).................................30

Приложение А (обязательное) Список функций.............................................34

Приложение В (справочное) Глоссарий терминов ФМ СВ ЭМК................................35

Приложение С (справочное) История иерархии глаголов действия............................83

Приложение D (справочное) Организации, оказавшие содействие.............................85

Приложение Е (справочное) История вопроса..............................................86

Приложение F (справочное) Выражения признательности....................................88

Приложение G (справочное) Другие предложения и запросы от Рабочей группы EHR.............90

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

национальным стандартам...............................................91

Библиография........................................................................92

Функциональная модель СВ ЭМК (т. е. все главы) содержит обязательные, справочные и ссылочные разделы. В настоящей главе с требованиями соответствия обязательное содержание определяет, каким образом функциональный профиль достигает соответствия функциональной модели.

6.5 Критерии соответствия (обязательный подраздел)

Каждая функция в функциональной модели ассоциирована с рядом критериев соответствия. Эти критерии соответствия формируют основу для определения того, была ли реализована функция.

6.5.1    Критерии в функциональном профиле

Функциональные профили также имеют критерии соответствия, ассоциированные с каждой функцией функционального профиля. Критерии функционального профиля или (1) адаптированы из критериев функциональной модели, включающих в себя специфичную информацию об условиях оказания медицинской помощи или приложении, либо (2) при отсутствии критериев, специфичных для условий оказания медицинской помощи или приложения, наследуются непосредственно от функциональной модели. Функциональные профили предметных областей или профилей-компаньонов МОГУТ менять критерии функциональной модели, чтобы они соответствовали потребностям и приоритетам, для которых создан функциональный профиль, например, за счет придания им большей специфичности, либо меняя их обязательность с «может» или «по возможности должен» на «должен». Функциональные профили МОГУТ менять критерии функции, чтобы позволить их адаптацию к номенклатуре, специфичной для сферы применения, включая языковые различия и следствия переводов на языки, отличающиеся от английского. В этих случаях коды стран (ISO 3166 Country Codes) Международной организации по стандартизации (ИСО) ДОЛЖНЫ быть приложены к ИД функции в функциональном профиле.

Функциональный профиль НЕ ДОЛЖЕН быть менее ограничивающим, чем функциональная модель, за счет изменения обязательности критерия «должен» на «может» или «по возможности должен». Функциональные профили МОГУТ также добавлять дополнительные критерии.

6.5.2    Критерий «условно ОБЯЗАТЕЛЕН»

Критерии соответствия, которые содержат ключевое слово «должен» и зависят от ситуационных условий, называются «условно обязательными» критериями. Такие критерии ДОЛЖНЫ содержать фразу «в соответствии с областью практики, политикой организации или законодательством» или другие подходящие грамматически присоединенные слова (например, «на основе», а не «в соответствии»), «Условно обязательный» критерий используется для подчеркивания только этих условий (т. е. области практики, политики организации и/или законодательства). «Условно обязательный» критерий является обязательным для функциональных профилей и ситуационным для систем ведения ЭМК. А именно:

-    Все функциональные профили предметных областей ДОЛЖНЫ наследовать критерий, если функция появляется в функциональном профиле.

-    Система ведения ЭМК ДОЛЖНА реализовывать критерий, только если критерий применим в соответствии с зависимостью, объявленной в функциональной модели. (Если «условно обязательный» критерий не применим к профилю, то разработчик профиля тем не менее может использовать его по своему желанию.)

6.5.3    Ссылка на другие критерии или функции

Часто существует связь функций и их критериев с другими функциями и критериями. Например, конкретная функция может зависеть от другой функции, или от специфичного критерия, ассоциированного с другой функцией.

Критерий функционального профиля, который ссылается на другую функцию функционального профиля. ДОЛЖЕН ссылаться на эту функцию с помощью указания идентификатора ИД и имени своей функции в форме «Х.п.п (имя)». Если ссылочная функция должна быть реализована, то применяются все критерии «должен» этой функции. Если ссылочная функция является родителем, то в ссылке должно быть явно указано, включены ли дочерние функции в ссылку, все или избранные. Ниже приведены примеры:

-    Система ДОЛЖНА/ ПО ВОЗМОЖНОСТИ ДОЛЖНА/ МОЖЕТ соответствовать TI.1.1 (Авторизация субъекта).

-    Система ДОЛЖНА/ПО ВОЗМОЖНОСТИ ДОЛЖНА/МОЖЕТ соответствовать TI.2 (Аудит) и всем дочерним функциям.

-    Система ДОЛЖНА соответствовать CPS.4 «Поддержка заказов» и отдельной функции (ям). Системы ДОЛЖНЫ соответствовать CPS.4.3 «Нелекарственные назначения». Системы ДОЛЖНЫ соответствовать CPS.4.6 «Поддержка направлений к врачам» и всем дочерним функциям.

Предисловие к MCO/HL7 10781

Международная организация по стандартизации. ИСО (the International Organization for Standardization) является международной организацией, которая была создана национальными организациями по стандартизации (члены ИСО). Работу по подготовке международных стандартов обычно выполняют технические комитеты ИСО. Любой член ИСО. заинтересованный в предмете, по которому создан технический комитет, имеет право на представительство в этом комитете. Международные организации. правительственные и неправительственные, совместно с ИСО. также принимают участие в работе организации. ИСО тесно сотрудничает с Международной электротехнической комиссией (МЭК) по всем вопросам стандартизации в электротехнике.

Международные стандарты составляются в соответствии с Директивами ИСО/МЭК, Часть 2.

Основной задачей технических комитетов является подготовка международных стандартов. Проекты международных стандартов принимаются техническими комитетами и передаются членам ИСО для проведения голосования. Для публикации в качестве международного стандарта необходимо одобрение не менее 75 % членов ИСО. участвующих в голосовании.

Необходимо обратить внимание на то. что некоторые части настоящего документа могут являться обьектами патентных прав. ИСО не обязана определять какие-либо или все части, являющиеся объектами патентных прав.

Настоящий стандарт подготовлен Техническим комитетом ИСО/ТК 215, Информатизация здоровья

Настоящее второе издание аннулирует и заменяет первое издание (HCO/HL7 10781:2009). которое было пересмотрено с технической точки зрения.

Введение

Информация для читателей

Функциональная модель системы ведения ЭМК. выпуск 2.0 основана на ряде предшествующих документов, начиная с версии первого согласованного проекта стандарта от 2004 г, за которым в 2007 г. последовал выпуск 1, а затем в 2009 г. Выпуск 1.1, поставленные на совместное голосование с ИСОЯК 215 и СЕНЯК 251. Выпуск 2.0 учитывает многочисленные изменения, включая комментарии и предложенные изменения, полученные при предыдущих голосованиях, которые Рабочая группа HL7 ЭМК обязалась учесть в будущем. Этот выпуск также включает комментарии, которые были даны в процессе голосования по проекту стандарта ИСО в 2009 г. для будущего рассмотрения, а также анализ голосования только по комментариям, проведенного в мае 2011 г.

Были сделаны другие изменения, учитывающие несколько функциональных профилей системы ведения ЭМК. включенных в выпуски функциональной модели 1 и 1.1. Был получен серьезный опыт в различных предметных областях, а также в профилях-комланьонах. В модель ФМ СВ ЭМК также были включены два других проекта стандарта для пробного использования: модель жизненного цикла HL7 EHR Lifecycle Model и модель интероперабельности HL7 EHR Interoperability Model.

Изменения по сравнению с предыдущими выпусками

Функциональная модель HL7 системы ЭМК. выпуск 2 была в первый раз поставлена на обязательное голосование в мае 2012 г. По результатам первого обязательного голосования были сделаны следующие основные изменения.

-    Обязательные части глоссария перемещены в раздел «Требования к соответствию», поскольку согласованное использование глоссария является ключом к чтению и пониманию модели.

-    Улучшена последовательность представления заголовков, функций и критериев соответствия в модели.

-    С целью упрощения чтения обновлены требования к соответствию, особенно в той мере, насколько это относится к различным типам профилей: профилей предметных областей и профилей-ком-паньонов.

-    Обеспечена ясность описаний функциональности и соответствующих критериев соответствия.

-    Уточнено содержание, чтобы оно было более актуальным.

Комментарии и решения по их учету, принятые при обязательном голосовании 1. можно посмотреть в материалах цикла голосования в мае 2012 г. на веб-сайте HL7 Ballot Website.

История вопроса

Что такое системы ведения электронных медицинских карт?

Эффективное использование информационной технологии является ключевым аспектом улучшения медицинской помощи в терминах безопасности пациента, качества и экономической эффективности. 8 серии отчетов Института медицины США (US Institute of Medicine, ЮМ) идентифицирован кризис «системы» и даны рекомендации преобразования «системы» с помощью применения информационной технологии. Такое изменение возможно с помощью «инфраструктуры, обеспечивающей формирование полностью взаимосвязанной, универсальной, защищенной сети систем, способной предоставить информацию о медицинской помощи пациенту в любое время и в любом месте». (Задачи HHS в «Разработке функционального стандарта HL7 ЭМК» в меморандуме в адрес HIMSS от К. Клэнси и В. Рауба. сопредседателей Совета HHS по применению медицинских информационных технологий от 12 ноября 2003 г.) Критичным основополагающим компонентом для решения этих проблемных аспектов системы и инфраструктуры является система ведения электронных медицинских карт (СВ ЭМК).

При разработке этой функциональной модели СВ ЭМК. организация HL7 полагалась на три хорошо зарекомендовавших себя определения: два были представлены Институтом медицины США, а третье — Европейским комитетом по стандартизации/ Comite Europeen de Normalization (CEN). Данная функциональная модель использует эти существующие определения СВ ЭМК и не пытается создать еще одно определение СВ ЭМК.

Существующие определения системы ведения ЭМК

В отчете ЮМ от 1991 г «The Computer-Based Patient Record: An Essential Technology» (Компьютеризованная запись пациента: основная технология), обновленном в 1997 г. (Dick, R.S. Steen. Е В., and Detmer, D.E. (Editors). National Academy Press: Washington. DC), дано следующее определение системы ведения ЭМК.

-    Набор компонентов, формирующий механизм, по которому создаются, используются, хранятся и извлекаются записи пациентов.

-    Системы записей пациента обычно находятся в организации поставщика медицинской помощи. Она охватывает пюдей. данные, правипа и процедуры, устройства обработки и хранения (например, бумагу и карандаши, аппаратные средства и программные средства), а также средства связи и поддержки.

-    В кратком отчете ЮМ «Letter Report, Key Capabilities of an Electronic Health Record System» от 2003 г, система ведения ЭМК определена следующим образом:

-    Динамическая коллекция электронной медицинской информации о людях и для людей, в которой медицинская информация определена как информация, относящаяся к состоянию здоровья отдельного лица или медицинской помощи, предоставляемой отдельному лицу.

-    Непосредственный электронный доступ к информации уровня отдельных лиц и информации уровня популяции, предоставляемый авторизованным, и только авторизованным, пользователям.

-    Предоставление знаний и поддержки принятия решений, повышающих качество, безопасность и эффективность медицинской помощи пациенту.

-    Поддержка эффективных процессов предоставления медицинской помощи.

В 2003 г. ИСО/ТС 18308 содержала ссылку на определение ЮМ от 1991 г, а также на ИСО 13606:

-    Система для регистрации, извлечения информации электронных медицинских карт и манипулирования этой информацией.

Как определяются и разрабатываются функции?

Чтобы в самом начале достичь консенсуса заинтересованных участников здравоохранения, функции описываются на концептуальном уровне, обеспечивающем надежный фундамент для более детального описания. Функции были включены в модель, если считались важными, по крайней мере, в одних условиях оказания медицинской помощи. Написанный языком, ориентированным на пользователя, документ предназначен для широкого круга читателей.

Глубина детализации функции является термином, используемым для описания уровня общности, на котором функция представлена. Функции, которые обычно группируются на практике или в основных системах, были консолидированы, где это было уместно; функции, для представления которых требуется дополнительный или отдельный язык, или функции, вовлеченные в различные рабочие процессы. описаны отдельно, если это было необходимо. Например, поддержка решений эксплуатируется как отдельный раздел, но отображается на другие ключевые разделы для обозначения «умной» функции, стоящей за действием. Описания всех функций могли быть сделаны с более глубокой детализацией. однако был достигнут баланс между полезным документом и неупорядоченным списком функций. В данном случае задача определения подходящего уровня глубины детализации заключается в таком представлении функций, которые могут быть легко выбраны и использованы читателями этого стандарта, но которые не настолько общие, чтобы читателям пришлось создавать большое количество дополнительных функций в рамках каждой функции.

Хотя определение глубины детализации функции является довольно субъективной задачей, однако систематическая оценка каждой функции разными группами отраслевых специалистов привела к уровню детализации, подходящему для данной функциональной модели СВ ЭМК. Были предприняты все возможные усилия по обеспечению дополнительной информации в описаниях функций для иллюстрации более глубоких аспектов функций, которые могли бы консолидироваться для целей применимости.

В целях сохранения данной функциональной модели СВ ЭМК, не зависящей от стратегии реализации или технологии, описание функций не включает в себя специфичные технологии, но они могут использоваться в примерах, иллюстрирующих функции Включение специфичных технопогий в примеры не означает, что они тем самым получают одобрение или поддержку с точки зрения использования этих технологий в качестве стратегий реализации.

Проекты функциональной модели СВ ЭМК и специфичных функций были всесторонне проанализированы поставщиками медицинской помощи, изготовителями и другими участниками. Предлагаемый стандарт отражает мнения всех указанных аналитиков.

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ИНФОРМАТИЗАЦИЯ ЗДОРОВЬЯ Функциональная модель HL7 системы ведения электронных медицинских карт

Выпуск 2 (ФМ СВ ПЭМК)

Health Informatics HL7 electronic health records-system functional model Release 2 (EHR FM)

Дата введения — 2020—05—01

1 Область применения

Функциональная модель системы ведения ЭМК, разработанная организацией HL7, представляет собой справочный список функций, которые могут присутствовать в системе ведения электронных медицинских карт (СВ ЭМК). Список функций описан с точки зрения пользователя в целях обеспечения согласованного представления функциональности системы. Обеспечивая создание функциональных профилей для условий оказания медицинской помощи и сфер применения, настоящая функциональная модель СВ ЭМК позволяет получить стандартизованное описание и общее представление о функциях, которые желательны, или доступны, в указанных условиях оказания медицинской помощи (например, интенсивная терапия, кардиология, амбулаторная практика в одной стране или первичная медицинская помощь в другой).

Функциональная модель системы ведения ЭМК HL7 определяет стандартизованную модель функций, которые могут присутствовать в системах ведения ЭМК. С самого начала необходимо четко различать ЭМК как отдельную сущность и системы, оперирующие ЭМК. т. е. системы ведения ЭМК. В разделе 1.1.3 описаны базис и основа определения системы ведения ЭМК, предложенного организацией HL7 В частности, функциональная модель СВ ЭМК не рассматривает аспект, представляет ли собой СВ ЭМК систему, состоящую из других систем, либо это одиночная система, предоставляющая функции. необходимые пользователям. В настоящем стандарте не проводятся различия реализаций, и СВ ЭМК. описанная в функциональном профиле, может быть как одиночной системой, так и совокупностью систем. В обязательных разделах функциональной модели термин «система» используется в общем смысле для охвата всего множества вариантов реализации. К ним относится «ключевая» медицинская функциональность, обычно предоставляемая специфичными медицинскими приложениями, управляющими электронной медицинской информацией. К ним также относятся связанные общие возможности прикладного уровня, обычно обеспечиваемые промежуточным программным обеспечением или другими инфраструктурными компонентами. Последние включают в себя средства интероперабельности и интеграции, например, службы локации и средства, обеспечивающие поток работ, распределенный между приложениями. Интероперабельность рассматривается как с семантической точки зрения (четкая. последовательная и согласованная передача смысла), так и технической (формат, синтаксис и физическая связность). Далее, в описаниях функций не приведены никакие утверждения об используемой технологии или содержании электронной медицинской карты. Специфика разработки и реализации систем ЭМК не рассматривается входящей в область применения настоящей модели и не будет рассматриваться в будущем. В настоящей функциональной модели СВ ЭМК не рассматриваются и не одобряются реализации или технологии либо особенности содержания данных электронной медицинской карты.

Наконец, в настоящей функциональной модели СВ ЭМК учтены потребности научных работников, поскольку в ней предусмотрены возможности предоставления им данных с соблюдением требуемых протоколов обеспечения неприкосновенности личной жизни, конфиденциальности и безопасности.

Издание официальное

Разнородность потребностей исследований исключает специфичное перечисление функций, потенциально полезных для научной работы.

Данная функциональная модель не является:

-    спецификацией сообщений:

-    спецификацией реализации;

-    спецификацией соответствия;

-    спецификацией ЭМК;

-    метрикой соответствия или тестирования соответствия;

-    упражнением по созданию определения ЭМК или СВ ЭМК.

Функциональной модели СВ ЭМК недостаточно для описания системы ведения долгосрочной медицинской карты, тем не менее, она вносит свой вклад в его разработку. Обмен информацией, обеспечиваемый СВ ЭМК. поддерживает большое число клинических документов, эпикризов, минимальных наборов данных, приложений к счетам на оплату медицинской помощи, а в будущем позволит сформировать долгосрочную медицинскую карту.

Кроме того, следует помнить, что функциональная модель СВ ЭМК не содержит обсуждение клинических процессов или взаимодействия участников медицинской помощи. Основные принципы и процессы оказания медицинской помощи очерчены в международном стандарте ИСО 13940. Пользователи ФМ СВ ЭМК могут обратиться к ИСО 13940 для получения информации о клинических процессах, поддерживаемых системами ведения ЭМК.

Данная функциональная модель СВ ЭМК включает справочные и обязательные разделы.

Таблица 1 — Типы нормативного статуса

Статус Описание Справочный Содержание пакета функциональной модели СВ ЭМК. представляющее информацию, разъясняющую понятия, или иную дополнительную информацию, способствующую пониманию и осмыслению Справочный материал не ставится на голосование, как часть стандарта. Обязательный Содержание, являющееся частью функциональной модели СВ ЭМК, по которому члены комитета (а также заинтересованные отраслевые участники) HL7 официально проголосовали и проанализировали его в соответствии с процедурой HL7 по голосованию по обязательным документам По этой функциональной модели, разработанной HL7. было успешно проведено голосование в качестве обязательного стандарта организации HL7

Каждый обязательный раздел в настоящем стандарте четко обозначен «обязательный». Например. в разделе 7 «Требования к соответствию» подразделы 7.2 и 7.4 обязательные.

Во внешнем приложении А «Список функций» к настоящей функциональной модели идентификатор функции, имя, объявление и компоненты критериев соответствия являются обязательными.

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты. Для датированных ссылок применяют только указанные издания. Для недатированных ссылок применяют последние издания (включая любые изменения к стандартам).

ISO/TR 12773-1:2009, Business requirements for health summary records. Part 1: Requirements (Документация медико-санитарная. Организационно-коммерческие требования. Часть 1. Требования) ISO/TS 13606-4:2009. Health informatics. Electronic health record communication. Part 4: Security (Информатизация здоровья. Передача электронной медицинской карты. Часть 4. Безопасность)

ISO/TS 17090-1:2002. Health informatics. Public key infrastructure. Part 1: Framework and overview (Информатизация здоровья. Инфраструктура с открытым ключом. Часть 1. Общие свойства и обзор) ISO 18308:2011, Health informatics. Requirements for an electronic health record architecture (Информатизация здоровья. Требования к архитектуре электронной медицинской карты)

ISO/IEC 2382-8:1998, Information technology. Vocabulary. Part 8: Security (Информационные технологии. Словарь. Часть 8. Защита конфиденциальных данных)

ASTM Е 1769:1995, Standard guide for properties of electronic health records and record systems (Стандартное руководство по свойствам электронных медицинских карт и систем электронных медицинских карт)

3    Термины и определения

В настоящем стандарте применены термины с соответствующими определениями:

3.1    контроль доступа (access control): Средства, обеспечивающие возможность доступа к ресурсам системы обработки данных только для авторизованных лиц авторизованным способом.

3.2    базовый функциональный профиль (base functional profile): Существующий функциональный профиль, на основе которого создаются и/или производятся новые функциональные профили.

3.3    соответствие (conformance): Выполнение продуктом, процессом или услугой заданных требований.

3.4    критерий соответствия (conformance criteria): Требования, описывающие поведение, действие. или способность, образующие реализацию функции.

3.5    требования к соответствию (conformance clause): Раздел спецификации, определяющий требования, критерии, или условия, которые необходимо выполнить, чтобы объявить соответствие.

3.6    объявление соответствия (confonnance statement): Описание функции, реализованной в системе ведения ЭМК.

Примечание — Оно отражает степень, в которой система ведения ЭМК выполнила требования функционального профиля, и может включать дополнительные функции и информацию

3.7    производный функциональный профиль (derived functional profile): Функциональный профиль предметной области, или профиль-компаньон, созданный на основе базового функционального профиля (например, профиль предметной области, дочерний для профиля предметной области детской больницы).

3.8    расширение (extension): Способность СВ ЭМК включать в себя дополнительную функциональность. кроме той. что определена в функциональном профиле.

3.9    функциональный профиль (functional profile): Подмножество функциональной модели, обозначающее функции (иногда в разной степени детализации) определенных систем ведения ЭМК. условий оказания медицинской помощи или более узких операционных требований.

3.10    справочный функциональный профиль (informative functional profile): Зарегистрированный функциональный профиль, который успешно завершил тщательное публичное обсуждение в процессе достижения консенсуса, принятого организацией HL7.

3.11    унаследованный критерий (inherited criterion): Критерий соответствия, перечисленный в родительской функции, который будет наследоваться всеми его дочерними функциями.

3.12    зарегистрированный функциональный профиль (registered functional profile): Функциональный профиль, успешно прошедший процесс регистрации и рассмотрения в Рабочей группе HL7 EHR.

3.13    ситуационный критерий (situational criterion): Критерий, который требуется в случае, когда имеют место определенные обстоятельства.

Пример — IFfThen (ЕСЛИ, то) или Dependent SHALL (условно ОБЯЗАТЕЛЬНЫЙ).

4    Общий обзор и определение функциональной модели (обязательный)

Функциональная модель СВ ЭМК включает в себя перечень функций, называемый «списком функций», подразделяемый на семь разделов: комплексный, оказание медицинской помощи, поддержка оказания медицинской помощи, поддержка здоровья населения, поддержка администрирования, инфраструктура записи и инфраструктура доверия.

В этих семи разделах функции группируются под функциями заголовков, каждая из которых имеет одну или несколько подфункций в иерархической структуре.

Комплексный (Overarching - OV)

Оказание медицинской помощи (Care Provision - СР) Поддержка оказания медицинской помощи (Care Provision Support - CPS) Поддержка здоровья населения (Population Health Support - POP) Поддержка администрирования (Administrative Support - AS) Инфраструктура записи (Record Infrastructure - Rl) Инфраструктура доверия (Trust Infrastructure - Tl)

Рисунок 1 — Разделы списка функций

4.1 Разделы списка функций

Семь разделов списка функций отражают содержание модели интероперабельности, которая в настоящее время встроена в функциональную модель, и входные данные от нескольких профилей, если используется выпуск R.1.1 функциональной модели. Ниже дается краткое описание каждого из семи разделов:

-    Комплексный: в разделе «Комплексный» (Overarching) содержатся критерии соответствия, которые применимы ко всем системам ведения ЭМК и поэтому должны включаться во все профили, совместимые с ФМ СВ ЭМК.

-    Оказание медицинской помощи: в разделе «Оказание медицинской помощи» (Care Provision) содержатся функции и поддерживающие критерии соответствия, необходимые при непосредственном предоставлении медицинской помощи конкретному пациенту и способствующие ее практическому оказанию. Функции носят общий характер, не ограничены конкретными условиями оказания медицинской помощи и могут использоваться как часть электронной медицинской карты, оказывающая поддержку врачебным кабинетам, клиникам, больницам и специальным медицинским центрам.

-    Поддержка оказания медицинской помощи: в разделе «Поддержка оказания медицинской помощи» (Care Provision Support) основное внимание уделяется функциям, необходимым для обеспечения оказания медицинской помощи. Этот раздел организован соответственно разделу «Оказание медицинской помощи». Например, функция СР.4 («Управление заказами») непосредственно поддерживается функцией CPS.4 («Поддержка заказов»).

-    Поддержка здоровья населения: в разделе «Поддержка здоровья населения» (Population Health Support) основное внимание уделяется функциям, требуемым в ЭМК для поддержки профилактики и контроля заболеваний среди группы людей (в отличие от медицинской помощи отдельному пациенту). Этот раздел описывает функции, поддерживающие входные данные систем, проводящих медицинские исследования, содействующих здоровью населения и повышающих качество медицинской помощи на уровне групп пациентов.

-    Поддержка администрирования: в разделе «Поддержка администрирования» (Administrative Support) основное внимание уделяется функциям СВ ЭМК, обеспечивающим управление клинической практикой и содействующим административным и финансовым операциям. Сюда относятся управление ресурсами и рабочим процессом, общение с пациентами и поставщиками медицинской помощи, а также управление административной информацией неклинического характера о пациентах и поставщиках.

-    Инфраструктура записи: глава «Инфраструктура записи» (Record Infrastructure) состоит из функций, общих для управления записями системы ведения ЭМК. особенно основополагающих функций управления жизненным циклом записи (формирование, аттестация, внесение изменений, доступ/ис-пользование, перевод, передача/раскрытие, получение, деидентификация, архивирование...) и сроком жизни записи (постоянство, нестираемость, преемственность, аудит, шифрование). Функции раздела RI (инфраструктура записи) являются ключевыми и образующими для всех других функций модели (СР, CPS, POP, AS).

-    Инфраструктура доверия: глава «Инфраструктура доверия» (Trust Infrastructure) состоит из функций, общих для инфраструктуры системы ведения ЭМК. особенно функций, основополагающих 4