ГОСТ Р ИСО/HL7 16527-2019. Национальный стандарт Российской Федерации. Информатизация здоровья. Функциональная модель HL7 системы ведения персональных электронных медицинских карт. Выпуск 1 (ФМ СВ ПЭМК)

(утв. и введен в действие Приказом Росстандарта от 29.08.2019 № 576-ст)

Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 29 августа 2019 г. № 576-ст

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

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

ФУНКЦИОНАЛЬНАЯ МОДЕЛЬ HL7 СИСТЕМЫ ВЕДЕНИЯ ПЕРСОНАЛЬНЫХ ЭЛЕКТРОННЫХ МЕДИЦИНСКИХ КАРТ

ВЫПУСК 1 (ФМ СВ ПЭМК)

ОКС 35.240.80

Дата введения 1 мая 2020 года

Предисловие

4 Настоящий стандарт идентичен международному стандарту ИСО/HL7 16527:2016 «Информатизация здоровья. Функциональная модель HL7 системы ведения персональных электронных медицинских карт, Выпуск 1 (ФМ СВ ПЭМК)» (ISO/HL7 16527:2016 «Health informatics — HL7 Personal Health Record System Functional Model, Release 1 (PHRS FM)», IDT)

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

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

Предисловие к ИСО/HL7 16527

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

Введение

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

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

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

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

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

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

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

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

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

ISO/TR 14292:2012, Health informatics. Personal health records. Definition, scope and context (Информатизация здоровья. Персональные медицинские записи. Определение, область применения и контекст)

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

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

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

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

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

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

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

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

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

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

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

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

4 Функциональная модель

4.1 Общий обзор и определение

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

Рисунок 1 — Разделы списка функций СВ ПЭМК

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

Нумерация описаний функций поддерживает отношения родителей — потомков между разделами и подразделами (например, функция «PH.1.1 Профиль владельца учетной записи (Account Holder Profile)» является родительской по отношению к «PH.1.1.1 Идентификация и поддержание записей о пациенте»). Во многих случаях родительский уровень полностью описывается дочерними элементами (см. рисунок 2). В целом функциональная модель СВ ПЭМК предназначена служить супермножеством функций, из которого заинтересованное сообщество может выбрать подмножество, иллюстрирующее то, что им требуется от СВ ПЭМК в их условиях. Только подмножества этого включающего множества функций (один или несколько функциональных профилей СВ ПЭМК) будут применяться в любой конкретной реализации СВ ПЭМК.

Рисунок 2 — Краткое изложение функций СВ ПЭМК

4.2 Краткое изложение функций СВ ПЭМК

4.2.1 Функции и их использование

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

4.2.2 Функции раздела персонального здоровья

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

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

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

4.2.3 Функции вспомогательного раздела

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

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

4.2.4 Функции раздела информационной инфраструктуры

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

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

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

4.3 Общие основные концепции модели

4.3.1 Иерархия «глаголов действия»

4.3.1.1 Согласованность критериев соответствия

В группе разработки велись работы по согласованию языка в рамках критериев соответствия. Диаграммы иерархии глаголов действия, показанные ниже, используются для создания семантической гармонии в рамках критериев соответствия, при которой, к примеру, в случае наличия в разделе «Персональное здоровье» критерия с глаголом действия «Изменить» («Update») этот термин имел бы то же значение в критерии соответствия раздела «Вспомогательный».

Уровни иерархии имеют разную степень детализации и связаны отношениями «родитель — потомок». Например, на представленной ниже диаграмме показано, что глагол «Собрать» информацию (Capture) охватывает местный ввод данных «Ввести» (Enter), а также перенос данных из внешнего источника «Импортировать» (Import). Аналогичным образом в разделе диаграммы «Эксплуатировать» (Maintain) термин «хранить» (Store) может вызывать глаголы действия, перечисленные под ним. Если родительский термин не используется, то соответствующие глаголы дочернего раздела будут трактоваться в критерии индивидуально. Если используется термин «Управлять» (Manage), то все применимые глаголы действия, включенные в таблицу, объединены в этом критерии. Авторы несут ответственность за определение того, являются ли один или несколько субглаголов подходящими для конкретной функции, и должны написать критерии соответствия, ограничивающие использование иерархии глаголов действия в соответствии с замыслом создаваемого профиля.

4.3.1.2 Категория «Обеспечить безопасность (Системы)»

Категория безопасности системы (Secure System Category) включает в себя глаголы действия для контроля доступа (аутентификация и авторизация пользователей), прослеживания событий (ведение журналов и аудита), а также для контроля доступа (аутентификация и авторизация пользователей), прослеживания событий (ведение журналов и аудита), а также по поддержке операций. Эта категория имеет одного предка, «Обеспечить безопасность (Системы)» (Secure (System)), и три (3) промежуточных потомка: «Управлять доступом» (Control Access), «Прослеживать» (Track) и «Поддерживать (Операции)» (Sustain (Operations)).

Рисунок 3 — Защищенная (система)

4.3.1.3 Категория «Управлять (Данными)»

Категория управления данными обеспечивает глаголы действия для всего спектра действий системы по манипулированию данными. Категория имеет одного предка, «Управлять (Данными)» (Manage (Data)), и шесть (6) потомков с подмножествами: «Собрать» (Capture), «Эксплуатировать» (Maintain), «Предоставить» (Render), «Обмениваться» (Exchange), «Определять» (Determine) и «Управлять видимостью данных» (Manage-Data-Visibility).

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

Рисунок 4 — Управление данными

4.3.1.4 Неприкосновенность частной жизни владельца учетной записи ПЭМК

Тенденция настоящей модели заключается в обеспечении максимально возможной защиты неприкосновенности частной жизни потребителя. Однако, будучи международной моделью, она пытается описать функциональность многих подтипов систем ведения ПЭМК (например, интегрированные системы ПЭМК/ЭМК, автономные системы ведения ПЭМК или системы, предоставляемые поставщиками по сети Интернет), заявления о контроле информации со стороны потребителя часто смягчаются фразой (с некоторыми вариациями) «в соответствии с ролью пользователя, политикой организации или действующим законодательством». Эта фраза не позволяет организациям нарушать права лиц, но признает, что могут существовать законные исключения из общего правила, согласно которому владелец учетной записи ПЭМК контролирует информацию своей ПЭМК. Во всех случаях модель требует, чтобы политика неприкосновенности частной жизни, реализуемая системой ведения ПЭМК, была полностью прозрачной для владельцев учетных записей ПЭМК и чтобы СВ ПЭМК имела возможность получения согласия владельца учетной записи ПЭМК на способы использования и раскрытия его/ее персональных данных (см. функции в IN.3.8, «Неприкосновенность частной жизни и конфиденциальность пациента», для получения подробной информации).

4.3.1.5 Сравнение функциональности и реализации

Важно отметить, что многие функции предлагают объем функциональности (например, предлагают интероперабельность на основе стандартов), но не предоставляют подробной информации по реализации. Функция, будучи реализована, должна быть реализована в контексте всей модели ФМ СВ ПЭМК. Например, предполагается, что реализация многих функций, описанных в модели, соответствует функциям безопасности и аудита, указанным в IN.3 (Безопасность) и IN.4 (Контролируемые записи), а функции, выполняемые «владельцем учетной записи ПЭМК», могут реально выполняться другими, если их делегирует владелец учетной записи (см. IN.3.2, Авторизация сущностей). Примеры контекстов реализации ПЭМК при применении мобильных устройств можно найти в Приложении E «Влияние мобильного устройства и аспекты, относящиеся к ПЭМК».

4.3.2 Релевантные стандарты

Релевантные стандарты:

ИСО/ТР 14292 «Personal health records — definition, scope, context and global variations of use» (Персональные медицинские записи. Определение, область применения, контекст и глобальные вариации использования)

4.3.3 Согласия, авторизации и предпочтения

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

4.3.4 Область вторичного использования данных ПЭМК

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

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

4.4 Типы профилей

Характеристика профиля ПЭМК основана на его атрибутах:

- Область применения и описание содержания

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

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

• Источники информации

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

• Куратор записи

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

• Хранение данных

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

• Степень интероперабельности

Система ведения ПЭМК может быть автономной или интероперабельной с другими системами ведения ЭМК/ПЭМК или чем-то средним.

- Сторона, контролирующая доступ к данным

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

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

5.1 Введение (ссылка)

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

a) Настоящие требования к соответствию определяют, что означает соответствие ФМ СВ ПЭМК.

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

c) Критерии соответствия связаны с каждой функцией ФМ СВ ПЭМК.

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

Технический и управленческий персонал NIST (National Institute of Standards and Technology — Национальный институт стандартов и технологий) США, Information Technology Laboratory (Лаборатории информационных технологий) предоставили данные и оказали поддержку при разработке настоящих критериев соответствия.

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

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

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

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

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

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

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

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

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

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

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

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

5.3.2 Модель соответствия (обязательный раздел)

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

Рисунок 5 — Отношения соответствия

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

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

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

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

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

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

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

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

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

5.5.1 Введение

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

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

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

• Все функциональные профили ДОЛЖНЫ наследовать критерий, если функция появляется в функциональном профиле.
• Система ведения ПЭМК ДОЛЖНА реализовывать критерий, только если критерий применим в соответствии с зависимостью, объявленной в ФМ СВ ПЭМК.

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

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

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

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

5.6 Структура и расширяемость ФМ СВ ПЭМК (обязательный подраздел)

5.6.1 Иерархическая структура

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

Рисунок 6 — Часть иерархической структуры ФМ СВ ПЭМК

ФМ СВ ПЭМК представлена как иерархический перечень функций, состоящий из функциональных заголовков и функций. Заголовки содержат идентификатор ИД, имя и «H» в графе с заголовком «Тип». Заголовки МОГУТ содержать критерии соответствия только в том случае, если критерии применяются ко всем функциям-потомкам (детям, внукам и т.п.). Все родительские функции ДОЛЖНЫ быть обозначены, как функции заголовка («H»). Описания листовых функций содержат, как минимум, следующие поля: ИД, имя, объявление, описание и критерии соответствия, и имеют обозначение «F» в графе «Тип».

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

5.6.2 Соглашение об именовании

5.6.3 Приоритеты

Функциональные профили показывают важность и/или безотлагательность функционального профиля, ассоциируя с функцией приоритет. Были определены три приоритета, а именно: существенна сейчас (Essential Now), существенна в будущем (Essential Future) и необязательная (Optional).

- Essential Now указывает, что реализация функции обязательна с даты выпуска профиля.

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

• Optional указывает, что реализация функции не является обязательной.

Любые из них или все приоритеты ДОЛЖНЫ использоваться в функциональном профиле. Если используется приоритет Essential Future, то требуется, чтобы в функциональном профиле были указаны рамки времени реализации функций. Такими рамками МОГУТ быть даты, ограничения времени (например, 2008 г. или четыре месяца после публикации функционального профиля) или событие (например, последующая публикация настоящего функционального профиля). Функциональный профиль МОЖЕТ определять несколько рамок времени для приоритета Essential Future. Если определено несколько рамок времени, то они ДОЛЖНЫ использоваться для квалификации каждого экземпляра приоритета Essential Future (например, EF-2008, EF-2009).

5.6.4 Расширяемость

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

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

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

5.7.1 Введение

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

5.7.2 Правила для функциональных профилей предметной области

Функциональные профили предметной области, при разработке которых соблюдаются правила для функциональных профилей, МОГУТ объявлять соответствие той версии ФМ СВ ПЭМК, из которой они произведены.

Функциональные профили, объявляющие соответствие ФМ СВ ПЭМК, ДОЛЖНЫ:

1. Идентифицировать ФМ СВ ПЭМК с версией/датой, из которой произведен функциональный профиль,

2. Включать описание, версию и дату издания функционального профиля,

3. Содержать описание соответствия, которое:

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

b. Определяет требования, которым в обязательном порядке должны соответствовать функциональные профили, произведенные из функционального профиля (т.е. производные функциональные профили) и объявляющие соответствие функциональному профилю.

c. Указывает, что функции, имеющие приоритет «Essential Now», ДОЛЖНЫ быть реализованы системами ведения ПЭМК, соответствующими профилю.

d. Указывает, что функции, имеющие приоритет «Essential Now», ДОЛЖНЫ быть включены в любые производные функциональные профили.

e. Если используется приоритет «Essential Future», то должен быть описан смысл этого приоритета, включая указание рамок времени, в которых требуется реализация этих функций.

f. Требует, чтобы по меньшей мере одна функция, независимо от ее приоритета, была реализована, чтобы для системы ведения ПЭМК можно было объявить соответствие профилю.

4. Идентифицировать функции ФМ СВ ПЭМК, применимые к функциональному профилю. Для каждой функции указать ее приоритет (т.е. «Essential Now», «Essential Future» или «Optional»).

5. Для каждой функции произвести критерии соответствия из критериев соответствия ФМ СВ ПЭМК.

a. В функциональном профиле ДОЛЖЕН быть по меньшей мере один обязательный критерий для каждой функции (критерий «должен»).

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

c. Если для функции в ФМ СВ ПЭМК все еще нет критерия «должен», то по меньшей мере один критерий «по возможности должен» или «может» ДОЛЖЕН быть сделан обязательным, т.е. критерием «должен».

d. Производный критерий должен следовать правилам ссылок на функции или критерии, описанным в подразделе 5.5.4 «Ссылка на другие критерии или функции».

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

a. Воспроизвести дословно каждый критерий «условно обязателен» вне зависимости от того, применима ли зависимая ситуация или нет.

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

c. Объявлять специфичную область практики, политики организации и/или законодательства, которая применяется, либо объявить, почему эти зависимости не применяются.

7. Следовать правилам создания новых функций в функциональных профилях, описанным в подразделе 5.7.3 «Правила создания новых функций в функциональных профилях».

8. Быть структурированным в соответствии с требованиями к структурированию, определенными для ФМ СВ ПЭМК в подразделе 5.6 «Структура и расширяемость ФМ СВ ПЭМК».

9. Заполнить две графы прослеживаемости (см. 5.3.3 «Прослеживаемость профиля») на предмет каких-либо изменений функций или критериев и использовать следующие коды изменений: 1 — последовательность, 2 — необязательность, 3 — содержание, 4 — новый. Для документирования типа изменений допускается использовать несколько кодов. Например, для критерия № 3, который переместился и стал № 1, изменился с «по возможности должен» на «должен» и приведен в соответствии со спецификой обязательных стандартов сферы, строка кодов изменений будет «1, 2, 3».

1. Создать дополнительные функции в соответствии с правилами, указанными в 5.7.3 «Правила создания новых функций в функциональных профилях».

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

3. Заменить текст «основан на стандарте(ах)» (standard(s)-based), содержащийся в некоторых критериях, специфичными стандартами и/или спецификациями, поименованными на наиболее дискретном уровне обозначения.

7. Добавить дополнительный критерий соответствия сверх тех, что имеются в ФМ СВ ПЭМК.

8. Сделать порядок критериев соответствия значащим (например, поместить все критерии «должен» в начало).

9. Обеспечить общее разрешение неоднозначной семантики ФМ СВ ПЭМК.

10. Сделать функциональные профили общедоступными (например, опубликовать на веб-сайте), чтобы заинтересованные стороны могли его видеть/использовать.

11. Предоставить функциональный профиль рабочей группе HL7 EHR для анализа до его регистрации.

Объявление соответствия функциональных профилей предметной области ФМ СВ ПЭМК НЕ ДОЛЖНО:

1. Указывать любые требования, противоречащие или вызывающие несоответствие с ФМ СВ ПЭМК.

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

5.7.3 Правила создания новых функций в функциональных профилях

Если функция не адекватно специфична для функционального профиля или не существует, то функциональный профиль ДОЛЖЕН лишь создать нового потомка. На рисунке 7 иллюстрируется добавление новой дочерней функции.

Рисунок 7 — Создание новой функции

a. Исходная «листовая» функция оставляется в качестве родительской по отношению к вновь созданным дочерним функциям,

b. Критерии соответствия «должен» этой функции ДОЛЖНЫ быть распределены среди его дочерних функций.

3. Если функции-кандидата на отражение требований функционального профиля не существует, то МОЖЕТ быть создана новая дочерняя функция (например, с помощью добавления нового вида сводного списка под сводным списком родителя).

4. Родительские функции НЕ ДОЛЖНЫ расщепляться. Это сохраняет структуру исходной ФМ СВ ПЭМК в функциональных профилях.

Если в функциональном профиле (поставленном на голосование или зарегистрированном) создаются новые дочерние функции, то эти новые функции будут выделены Рабочей группой HL7 EHR и отслежены с целью анализа. Рабочая группа HL7 EHR БУДЕТ использовать эти новые функции и соответствующие критерии в качестве входных данных и кандидатов на изменения функциональной модели (например, добавление, ослабление критериев соответствия). Рабочая группа HL7 EHR МОЖЕТ поддерживать файл рассмотренных функций и критериев, которые было решено не включать в будущую версию функциональной модели.

5.7.4 Правила для производных функциональных профилей

Производные функциональные профили, объявляющие соответствие одному или нескольким базовым функциональным профилям, ДОЛЖНЫ:

1. Следовать всем правилам для функциональных профилей, описанным в 5.7.2 «Правила для функциональных профилей предметной области».

2. Следовать всем правилам создания новых функций, описанным в 5.7.3 «Правила создания новых функций в функциональных профилях», если это не запрещено базовым функциональным профилем.

3. Идентифицировать базовые функциональные профили, из которых произведен данный профиль.

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

5.7.5 Объявление соответствия

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

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

Функциональные профили МОГУТ включить в себя Бланк объявления соответствия, наличие которого содействует согласованности заполненных объявлений соответствия. Объявления соответствия могут быть полезны для оценки шансов интероперабельности двух систем ведения ПЭМК с помощью сравнения функций, поддерживаемых каждой системой. Кроме того, объявление соответствия может использоваться для целей тестирования соответствия, упрощая выбор тестов, применимых к конкретной тестируемой системе ведения ПЭМК. Например, если в системе ведения ПЭМК не реализованы функции с обозначением «Essential Future», это будет очевидно вытекать из объявления соответствия и тестирование этих функций (которые не реализованы) не будет выполняться.

5.7.6 Правила для функциональных профилей-компаньонов

Функциональные профили-компаньоны, следующие Правилам для функциональных профилей, ДОЛЖНЫ объявлять соответствие той версии ФМ СВ ПЭМК, из которой они были произведены. Функциональные профили-компаньоны будут следовать положениям подразделов 5.7.2 «Правила для функциональных профилей предметной области» и 5.7.4 «Правила для производных функциональных профилей», за исключением изъятий и дополнений, описанных ниже:

Функциональный профиль-компаньон, объявляющий соответствие функциональной модели, ДОЛЖЕН:

1. При добавлении новых функций следовать положениям подраздела 5.7.3 «Правила создания новых функций в функциональных профилях».

2. Содержать описание соответствия, которое:

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

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

3. Включать только модифицируемые функции из раздела «Общий» Приложения A с приоритетом Essential Now и идентифицировать функции из другого раздела Приложения A функциональной модели, применимые к функциональному профилю-компаньону. Для каждой идентифицированной функции следует указать ее приоритет (т.е. Essential Now, Essential Future или Optional).

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

В функциональном профиле ДОЛЖЕН быть по меньшей мере один обязательный критерий для каждой функции (критерий «должен»).

Если критерии «должен» (для функции в функциональной модели) имеются, то эти критерии МОГУТ также иметься для функции (в функциональном профиле-компаньоне), если она меняется. Кроме того, если функция расщеплена (в функциональном профиле), то родительский критерий «должен» МОЖЕТ возникнуть по меньшей мере в одном потомке этой функции.

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

Функциональные профили-компаньоны, объявляющие соответствие функциональной модели, МОГУТ:

1. Игнорировать критерий «должен», «по возможности должен» или «может», указанный в функциональной модели (т.е. не включать его в функциональный профиль).

Для функциональных производных профилей-компаньонов отсутствуют исключения из положений подраздела 5.7.4 «Правила для производных функциональных профилей».

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

5.8.1 Варианты использования функциональных профилей

5.8.1.1 Пример 1: Источник ПЭМК (на основе куратора)

Установлено, что для учета специфичных ожидания и требований, предъявляемых к системе со стороны конкретного участника-источника (например, больница, медицинская группа, плательщик или банк медицинских карт), требуется новый функциональный профиль на основе источника. Чтобы помочь обеспечить широкое использование и единообразие, авторы функционального профиля выбирают прохождение анализа перед регистрацией, за которым последует процесс достижения консенсуса, принятый организацией HL7 (т.е. подача зарегистрированного функционального профиля для голосования в качестве «справочного» на уровне комитета). При положительном исходе этот результат будет обозначаться как справочный функциональный профиль HL7.

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

5.8.1.2 Пример 2: Уровень функциональности производного функционального профиля

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

Заинтересованное сообщество или участник не хотят создавать новый функциональный профиль с нуля. При просмотре списка зарегистрированных функциональных профилей ПЭМК HL7 они находят существующий функциональный профиль, который очень близок к тому, что они хотят. Используя данный функциональный профиль в качестве основы, они принимают все функции с приоритетом «Essential Now», отказываются от функций с приоритетом «Essential Future» и добавляют еще несколько функций. Для каждой функции они анализируют критерии соответствия и адаптируют их, чтобы они отражали их ситуационную информацию.

5.8.1.3 Пример 3: Функциональный профиль изготовителя

Изготовитель системы ведения ПЭМК хочет объявить соответствие ФМ СВ ПЭМК.

Изготовитель идентифицирует и перечисляет все функции своего продукта. Изготовитель добавляет описание системы и описания соответствия (см. образцы в 5.8.2 «Образец описания соответствия функциональному профилю предметной области»). Это функциональный профиль изготовителя. Если изготовитель действительно реализовал все перечисленные функции, то это эквивалентно приоритету «Essential Now», и эти функции являются обязательными. Свойства, реализованные изготовителем, которых нет в ФМ СВ ПЭМК, могут быть добавлены в качестве дополнительных функций или дополнительных критериев в соответствии с положениями приведенных выше подразделов 5.7.2 «Правила для функциональных профилей предметной области» и 5.7.3 «Правила создания новых функций в функциональных профилях». Если перечисляются функции, которые в настоящее время реализованы, а также те, которые будут реализованы в будущем, то функциональный профиль состоит из функций с приоритетами «Essential Now» и «Essential Future» и/или дополнительной функциональности. В заключение изготовитель добавляет критерии соответствия для каждой функции, наследующей их (без изменения) непосредственно из ФМ СВ ПЭМК. Тем самым изготовитель имеет возможность перечислить текущую функциональность и при желании указать планы на будущее. В сущности, это аналогично объявлению о соответствии изготовителя (концепция, с которой большинство изготовителей уже знакомы). Изготовитель может создать несколько функциональных профилей.

Рисунок 8 — Примеры возможностей и/или уровней функциональности функционального профиля «Модель»

5.8.2 Образец описания соответствия функциональному профилю предметной области

5.8.2.1 Разработка описания соответствия

Для помощи разработчикам функциональных профилей в составлении требований к соответствию для их функционального профиля предметной области согласно правилу № 3, указанному в 5.7.2 «Правила для функциональных профилей предметной области», предлагаются следующие фиктивные примеры. Обратите внимание, что в этих примерах ключевые слова ДОЛЖЕН, ПО ВОЗМОЖНОСТИ ДОЛЖЕН или МОЖЕТ пишутся прописными буквами и жирным шрифтом. Это соглашение по привлечению внимания к ключевым словам.

5.8.2.2 Образец 1: Требования к соответствию функциональному профилю ПЭМК, связанному с поставщиком медицинской помощи

Настоящий функциональный профиль предметной области определяет требования соответствия для систем ведения ПЭМК и производных функциональных профилей. Для соответствия этому функциональному профилю ДОЛЖНЫ быть реализованы все функции с приоритетом «Essential Now». Такие функции считаются обязательными. Система ведения ПЭМК соответствует профилю, если в ней реализованы все функции с приоритетом «Essential Now», а также обязательные критерии соответствия, ассоциированные с этими функциями. Производный функциональный профиль соответствует, если он следует Правилам для функциональных профилей.

Обязательные критерии соответствия обозначены ключевым словом «должен». Дополнительные критерии соответствия обозначаются ключевыми словами «по возможности должен» или «может».

Системы ведения ПЭМК ДОЛЖНЫ предоставлять объявление соответствия, которое структурировано в соответствии с правилами и политиками, определенными в этом функциональном профиле.

5.8.2.3 Образец 2: Требования к соответствию функциональному профилю изготовителя системы

Соответствие определено для системы My-PHRsystem. Все функции в этом функциональном профиле являются обязательными, имеют приоритет «Essential Now» и ДОЛЖНЫ быть реализованы, чтобы соответствовать этому функциональному профилю.

5.8.2.4 Образец 3: Требования к соответствию функциональному профилю заинтересованного сообщества

Соответствие определено для системы BuyMyDiabetesPHR. Для соответствия этому функциональному профилю все функции с приоритетом «Essential Now» ДОЛЖНЫ быть доступны и реализованы. Функции с приоритетом «Essential Future» являются необязательными, присутствуют только для информации и МОГУТ быть реализованы в будущих функциональных профилях.

5.9 Интерпретация и применение «условной обязательности» (справочный подраздел)

5.9.1 Обзор конструирования «условно обязательных» критериев соответствия

Критерий соответствия в функциональной модели и вновь создаваемые критерии могут структурироваться в простом формате, когда за действующим лицом следует нормативный глагол, за которым следует действие или свойство. Например, система ДОЛЖНА собирать демографическую информацию как часть записи пациента.

Однако имеются две условные формы, для которых, если условие верно, может применяться следующий за ним текст. Одной из них является «если/то» (If/Then). Если есть условие, то за ним следует действующее лицо, затем нормативный глагол, за которым следует действие. Если условие не выполнено (т.е. неверно), то следует игнорировать остальную часть предложения. Например, ЕСЛИ данные обмениваются с внутренними или внешними системами, ТО система ДОЛЖНА соответствовать функции IN 5.1 (Стандарты взаимодействия).

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

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

Критерий ФМ СВ ПЭМК: СВ ПЭМК ДОЛЖНА обеспечить администраторам информационной безопасности СВ ПЭМК возможность осуществлять авторизацию принципалов в соответствии с ролью пользователя, политикой организации или действующим законодательством.

5.9.2 Общие концепции

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

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

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

Критерий ФМ СВ ПЭМК: СВ ПЭМК ДОЛЖНА обеспечить администраторам информационной безопасности СВ ПЭМК возможность осуществлять авторизацию принципалов в соответствии с Законом США «U.S. Health Insurance Portability and Accountability Act» от 1996 г.

Различие между критерием «должен» и «условно обязательным» критерием показано в таблице 1.

Таблица 1

Различия между критерием «должен» и «условно обязательным» критерием

5.9.3 Обоснование «условно обязательного» критерия

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

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

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

5.9.4 Как применять «условную обязательность»

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

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

1. СВ ПЭМК ДОЛЖНА обеспечить администраторам информационной безопасности СВ ПЭМК возможность осуществлять авторизацию принципалов в соответствии с HIPAA <*>.

2. СВ ПЭМК ДОЛЖНА обеспечить администраторам информационной безопасности СВ ПЭМК осуществлять авторизацию ролей в соответствии с 42 CFR Часть 2 <*>.

<*> Объяснение зависимости: на территории США в «условно-обязательных» критериях, определенных в функциональном профиле, следует применять положения Федерального закона от 1996 года Health Insurance Portability and Accountability Act (HIPAA), а также другие требования законодательства или иные более строгие требования.

Таблица 2

Сводка действий при существовании зависимости

• Если зависимость отсутствует:

Если никакая зависимость не применима в данном функциональном профиле (например, отсутствуют роли пользователя, политики организации или применимые требования законодательства), то следует документировать обоснование решения о неприменимости зависимостей. Такое объяснение может даваться в приложении. Вполне вероятно, что оно будет применимо к нескольким «условно обязательным» критериям.

Таблица 3

Сводка действий, если никакая зависимость не применима

- Добавление дополнительных критериев — независимо от существования зависимости.

Всегда допускается добавлять новые критерии в функциональный профиль. Добавьте новые критерии, произведенные из «условно обязательного» критерия. В этих критериях используйте любое ключевое слово: «должен», «по возможности должен» или «может» (см. 5.4 «Нормативный язык»).

Примеры:

1. СВ ПЭМК ПО ВОЗМОЖНОСТИ ДОЛЖНА обеспечить администраторам информационной безопасности СВ ПЭМК возможность осуществлять авторизацию принципалов.

2. СВ ПЭМК МОЖЕТ обеспечить администраторам информационной безопасности СВ ПЭМК возможность осуществлять авторизацию ролей.

3. СВ ПЭМК ПО ВОЗМОЖНОСТИ ДОЛЖНА обеспечить администраторам информационной безопасности СВ ПЭМК возможность осуществлять контекстно-зависимую авторизацию.

4. СВ ПЭМК ДОЛЖНА обеспечить администраторам информационной безопасности СВ ПЭМК возможность осуществлять авторизацию ролей в организациях с численностью персонала, составляющей десять сотрудников или более.

Приложение A (обязательное)

СПИСОК ФУНКЦИЙ

В Списке функций ПЭМК каждая функция в HL7 ФМ СВ ПЭМК идентифицируется и описывается с использованием набора элементов или компонентов, как это подробно показано на рисунке A.1 и объясняется ниже.

Рисунок A.1 — Функции в списке функций ФМ СВ ПЭМК

• ИД функции (справочный)

ИД функции представляет собой уникальный идентификатор указанной функции. Функции раздела персонального здоровья идентифицируются символами «PH», за которыми следует номер (например, PH.1.1.3.1; PH.1.1.3.2). Функции вспомогательного раздела идентифицируются символом 'S', за которым следует номер (например, S.2.1; S.2.1.1). Функции раздела «Информационная инфраструктура» идентифицируются символами 'IN', за которыми следует номер (например, IN.1.1; IN.1.2). Нумерация всех разделов начинается с 1.

• Тип функции (справочный)

Тип функции показывает, является ли указанная функция заголовком (H) или функцией (F).

• Имя функции (обязательное)

Имя функции дает краткое описание указанной функции.

Пример - Профиль владельца учетной записи.

• Объявление функции (обязательное)

Объявление функции содержит краткое описание назначения функции.

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

• Описание (справочное)

Описание передает все значения и нюансы объявления функции и часто сопровождается разъясняющими примерами.

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

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

Критерий соответствия разъясняет, каким образом может рассматриваться соответствие данной функции. Дальнейшую информацию о критериях соответствия и их использовании см. в подразделах 5.5 и 5.6 раздела «Требования к соответствию».

Полный список функций ФМ СВ ПЭМК см. в приложенном файле EHR_PHRSFM_R1_2014AUG_FunctionList.html.

Приложение B (справочное)

ГЛОССАРИЙ

B.1 Введение и краткий обзор

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

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

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

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

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

• Глоссарий ФМ СВ ПЭМК Рабочей группы HL7 EHR определяет лишь те термины, которые уникальны для ФМ СВ ПЭМК.
• Термины Глоссария ФМ СВ ПЭМК Рабочей группы HL7 EHR будут представлены для включения в издание глоссария HL7 Версии 3.0.
• Предполагается, что создание учетной записи пользователя ПЭМК входит в область применения ФМ СВ ПЭМК.

B.3 Известные вопросы

Ниже представлены аспекты, которые были известны применительно к этой версии глоссария:

• Этот глоссарий был пересмотрен только в отношении глаголов действия. Группа глоссария (GT) намерена повторно изучить другие термины глоссария в будущем.
• Было уделено серьезное внимание согласованию определений с признанными словарями. Были использованы два (2) основных словаря:
• http://dictionary.reference.com/index.html и
• Канадский Оксфордский словарь.
• Там, где определения были получены из других признанных источников, источники помечены в графе таблицы «Ссылки». Заинтересованным сторонам предлагается по возможности заполнить графу «Ссылки».
• Не предполагается, что предлагаемые определения будут согласованы с различными определениями, включенными в другие стандарты, законы и нормативные акты или в глоссарии конкретных предметных областей. Цель настоящего глоссария — быть универсальным и независимым от предметной области здравоохранения.

B.4 Глаголы действия

B.4.1 Структура глаголов действия

Глаголы действия, используемые для написания критериев соответствия (КС) в ФМ СВ ПЭМК, подразделены на две (2) категории, каждая с собственным набором глаголов действия:

• Категория «Обеспечить безопасность (Системы)»;
• Категория «Управление данными».

Каждая категория состоит из глаголов действия, которые вместе представляют собой логический набор действий, отличающийся от другой категории. Все глаголы действия на всех уровнях определены в разделе «Глоссарий» настоящего документа; даны иллюстративные примеры.

B.4.2 Категория «Обеспечить безопасность (Системы)»

Категория «Обеспечить безопасность (Системы)» содержит глаголы действия для контроля доступа (аутентификация и авторизация пользователей), прослеживания событий (ведение журналов и аудита), а также для контроля доступа (аутентификация и авторизация пользователей), прослеживания событий (ведение журналов и аудита), а также по поддержке операций. Эта категория имеет одного предка, «Обеспечить безопасность (Системы)» (Secure (System)), и три (3) промежуточных потомка: «Управлять доступом» (Control Access), «Прослеживать» (Track) и «Поддерживать (Операции)» (Sustain (Operations)).

Таблица B.1

Обеспечить безопасность (Системы)

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

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

B.4.3 Категория управления данными (Data Management Category)

Категория управления данными предоставляет глаголы действия для всего спектра действий системы по манипулированию данными. Категория имеет одного предка, «Управлять (Данными)» (Manage (Data)), и шесть (6) потомков с подмножествами: «Собрать» (Capture), «Поддерживать» (Maintain), «Предоставить» (Render), «Обмениваться» (Exchange), «Определить» (Determine) и «Управлять видимостью данных».

Первые три подмножества следующим образом охватывают сбор, эксплуатацию и предоставление данных:

• Собрать: автоматически заполнять поля данных на основе частично заполненной информации, вводить данные вручную, импортировать данные из внешнего источника (которым может быть прибор), получить данные от другой системы (которая может быть встроена в прибор).
• Эксплуатировать: хранить, изменить и устранить данные:
• Хранить: хранить данные на локальном носителе, резервировать данные в хранилище резервных копий и шифровать данные с целью защиты данных и обеспечения неприкосновенности частной жизни;
• Изменить: редактировать данные путем модификации, аннотировать данные примечаниями, пометить данные метками, гармонизировать данные с другими источниками, интегрировать данные, связать с другими данными;
• Устранить: удалить данные из индекса или каталога, очистить данные, хранящиеся на накопителе.
• Предоставлять: извлечь данные на основе определенных критериев, представить данные на подсоединенном устройстве, передать данные внешним системам или устройствам.

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

• Обмениваться: передача данных внешним системам или получение от них данных.

Следующее подмножество предоставляет глаголы для определения действий по обработке данных:

• Определить: анализировать данные, используя правила и аналитические шаги, и затем решить, какие действия следует выполнить по результатам этого анализа.

Последнее подмножество позволяет создавать объявления, ограничивающие видимость данных, и обращать эти действия:

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

Таблица B.2

Управлять (Данными)

B.4.4 Как определяются глаголы действия

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

Если глагол действия имеет родителя, то определение глагола начнется с глагола непосредственного родителя, а затем приводится повторное описание значения глагола действия, за которым следует по меньшей мере один (1) пример, соответственно маркированный. В примерах будут использоваться глаголы действия, определенные с помощью разъяснений, где это уместно. Ниже приведен иллюстративный пример:

• ПРЕДСТАВИТЬ (PRESENT) (глагол действия): ПРЕДОСТАВИТЬ (RENDER) (родительский глагол действия) данные путем отправки данных локальным пользователям содержательным и подходящим способом. Например, система может ПРЕДСТАВИТЬ (PRESENT) сигнал тревоги автоматически, если получен вновь поступивший результат лабораторного анализа, выходящий за пределы нормы.

Для глаголов действия верхнего уровня определение будет включать следующий уровень непосредственных потомков, за которым следует по меньшей мере один (1) пример, соответственно маркированный. В примерах будут использоваться глаголы действия, определенные с помощью разъяснений, где это уместно. Ниже приведен иллюстративный пример:

• УПРАВЛЯТЬ (ДАННЫМИ) (MANAGE (DATA)) (глагол действия): обработать данные с помощью сбора, эксплуатации, предоставления данных и визуализации данных, определения действий по обработке данных и управления видимостью данных. Например, система должна предоставить возможность для пользователя УПРАВЛЯТЬ (MANAGE) предпочтениями пациента и семьи, относящихся к текущим планам ведения.

B.4.5 Устаревшие глаголы действия

Глоссарий включает устаревшие глаголы действия и предложения о представлении их значения с помощью стандартизованного списка глаголов действия и квалификаторов в соответствии с разъяснениями, приведенными в B.5.2 «Общее руководство».

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

Эти устаревшие глаголы действия соответствующим образом маркированы. Примеры устаревших глаголов действия: ALERT (подать тревожный сигнал), QUERY (запросить) и SEARCH (искать).

B.5 Рекомендации по применению

B.5.1 Введение

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

B.5.2 Общее руководство

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

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

• Например, если удаление данных не было разрешено, то вместо «ЭКСПЛУАТИРОВАТЬ клинические данные», что означает хранение, изменение и удаление данных, можно сказать «ХРАНИТЬ и ИЗМЕНИТЬ данные».
• Например, если в данном КС предполагается, что обоснованными применениями функции будут РЕДАКТИРОВАТЬ и ПОМЕТИТЬ, а АННОТИРОВАТЬ, ГАРМОНИЗИРОВАТЬ, ИНТЕГРИРОВАТЬ, СВЯЗАТЬ будут необоснованными, то вместо слова ЭКСПЛУАТИРОВАТЬ следует использовать более точные РЕДАКТИРОВАТЬ и ПОМЕТИТЬ.
• Пример нескольких глаголов действия: Система ДОЛЖНА обеспечить возможность СОБРАТЬ, ХРАНИТЬ, РЕДАКТИРОВАТЬ и ПОМЕТИТЬ устаревшие записи реестра или каталога, чтобы он был актуальным.

• Конструкция [ДОЛЖНА | ПО ВОЗМОЖНОСТИ ДОЛЖНА | МОЖЕТ] обязательная. Должен использоваться один и только один из этих трех вспомогательных глаголов. Их значения определены в разделе «Требования к соответствию ФМ СВ ПЭМК» и повторяются здесь для удобства:

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

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

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

• Конструкция [обеспечить способность] является необязательной и используется, когда действие будет зависеть от вмешательства пользователя;
• Конструкция [глагол действия] обязательная. Глагол действия должен быть взят из стандартизованного списка, содержащегося в глоссарии, и его значение должно соответствовать тому, что описано в глоссарии. Если другой глагол представляется более предпочтительным, то предлагается найти этот глагол в глоссарии в разделе определений, где он может быть дан с предложениями по глаголу, который его заменяет, а также составу. В этом руководстве даны многочисленные примеры.
• Конструкция [объект(ы)] обязательная. Идентифицирует объект(ы) действия.
• Конструкция [участник(и)] необязательная. Включает пользователей (или внешние системы), участвующие или подвергающиеся воздействию указанного действия.
• Конструкция [квалификатор(ы)]: необязательная. Она может относиться ко времени, интервалу, условию(ям). Может включать (например) такие термины, как «автоматически», «вручную», «в реальном времени», «в соответствии с бизнес-правилами».
• Конструкция [«в соответствии с областью практики, политикой организации или действующим законодательством»] необязательная, если действие должно управляться конкретными областями практики, политиками организации или конкретным законодательством.

Учтите, что конструкция «[обеспечить способность]» является ключевой фразой, которая означает, что предполагается ручное вмешательство. Учтите также, что конструкция «Система ДОЛЖНА» означает, что система должна выполнить соответствующую функцию, если соблюдены и учтены все условия и факторы.

Ниже приведены некоторые примеры строгих КС:

• Система ДОЛЖНА обеспечить способность ПРЕДСТАВИТЬ список пациентов, которым запланирован прием, в соответствии с выбранными критериями, например фамилия, имя, отчество поставщика медицинской помощи, даты, время дня, характер посещения и т.п., используя выбранный язык.
• Если поставщик медицинской помощи пытается назначить лекарство с помощью системы, то система ДОЛЖНА ОПРЕДЕЛИТЬ, существует ли взаимодействие между вновь назначенными лекарствами и лекарственными средствами из текущего списка лекарственных назначений, и ПРЕДОСТАВИТЬ поставщику подходящее уведомление в соответствии с областью практики, политикой организации или действующим законодательством.

Глагол «соответствовать» ('Conform') используется в функциональной модели с особым значением и не является частью модели глаголов действия. Это специальная инструкция по включению функциональных требований одной функции в другую функцию.

• Например, «Система ДОЛЖНА соответствовать функции IN.1.1 (Аутентификация сущности)».

B.7 Глоссарий терминов ФМ СВ ПЭМК

Приложение C (справочное)

ИСТОЧНИКИ ПЭМК

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

Как подробно описано в разделе 5 «Требования к соответствию», ФМ СВ ПЭМК представляет собой модель с широкой базой. Ожидается, что ее профили будут определены для разных заинтересованных сторон и целей использования системы ведения ПЭМК. Например, функциональный профиль системы может быть пригоден для отражения специфичных требований и ожиданий конкретной заинтересованной стороны, например больницы, медицинской группы, плательщика или банка медицинских записей. Ниже представлены примеры, а образцы незавершенных профилей включены в качестве справочных документов, представляющих варианты профилей, которые могут быть зарегистрированы или официально поставлены на голосование в будущем. (См. ниже C.1 и соответствующее описание в 5.8 «Варианты использования и примеры».)

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

C.1 Связанная с поставщиком медицинской помощи

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

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

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

C.2 Связанная с плательщиком

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

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

Многие коммерческие схемы лечения смещаются в этом направлении и могут скоро предъявить данные, демонстрирующие улучшение результатов оказания медицинской помощи. Недавно система государственного медицинского страхования США (Центры служб Medicare и Medicaid (CMS)) инициировала ряд пилотных программ по изучению применения ПЭМК лицами, застрахованными по программе Medicare. CMS, являясь самым крупным плательщиком США, хочет стимулировать лиц, застрахованных по программе Medicare, к использованию ПЭМК для прослеживания оказанной им медицинской помощи, а также в качестве ресурса для улучшения общения с их поставщиками медицинской помощи, надеясь, что эти инструменты действительно повысят качество и результаты медицинской помощи.

C.3 Банк медицинских записей

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

Рисунок C.1 — Примеры возможностей и/или уровней функциональности профиля «Модель»

Приложение D (справочное)

ПРЕДПОЛАГАЕМОЕ ИСПОЛЬЗОВАНИЕ

D.1 Международное сообщество и спецификации сфер применения

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

D.2 Предполагаемый подход к развитию: функциональные профили

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

Подобно СВ ЭМК (EHR-S), описанной в ИСО/HL7 10781 (Функциональная модель системы ведения ЭМК), СВ ПЭМК не соответствует непосредственно функциональной модели; скорее, она соответствует одному или нескольким функциональным профилям. Дополнительная информация о создании, регистрации и утверждении функциональных профилей изложена в подразделах раздела 5 «Требования к соответствию» - 5.3 «Понятия» (обязательный подраздел) и 5.7 «Соответствие функционального профиля» (обязательный подраздел).

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

Примечание — См. примеры функциональных профилей СВ ПЭМК в Приложении C «Источники ПЭМК».

Приложение E (справочное)

ВЛИЯНИЕ МОБИЛЬНОГО УСТРОЙСТВА И АСПЕКТЫ, ОТНОСЯЩИЕСЯ К ПЭМК

E.1 Введение

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

E.2 Взаимодействие ПЭМК с мобильными устройствами

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

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

E.3 Доверие к источникам информации мобильных устройств

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

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

E.4 Возможность изменения потребителем данных, полученных от профессиональных источников

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

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

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

E.6 Возможность недостаточного/неожиданного регулирования или управления данными, полученными от профессиональных источников

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

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

E.7 Стандартизация интероперабельности в рамках среды обмена медицинской информацией

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

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

E.8 Различные типы мобильных устройств

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

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

Пример - Потребитель (источник) вводит измерения показаний глюкозы с помощью устройства мониторинга диабета (модема).

E.9 Функциональность (или возможность) — нюансы различных систем обмена информацией

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

E.10 Маркировка мобильных устройств (и соответствующего программного обеспечения) как «регистрируемых» Управлением по контролю за продуктами питания и лекарственными средствами (FDA)

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

E.11 Количество или тип данных

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

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

E.12 Картина будущего

Будущая мощь систем ведения ПЭМК — использование мобильных устройств для поддержки принятия клинических решений:

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

Например, в США различные уполномоченные органы регулируют применение мобильных приложений и безопасность:

• Управление по контролю за продуктами и лекарствами США (FDA) регистрирует медицинские устройства и мобильные приложения, влияющие на безопасность пациентов. Например, FDA регулирует небольшое подмножество мобильных медицинских приложений, которые могут представлять потенциальный риск для пациентов, если эти устройства не работают надлежащим образом.
• Федеральная комиссия по связи США (FCC) регулирует внутреннюю и международную связь, а именно: проводную, спутниковую и кабельную, используемую мобильными устройствами. Например, FCC регистрирует определенные радиочастотные медицинские устройства, включая имплантируемые устройства (например, кардиостимуляторы) и устройства мониторинга пациентов (например, беспроводные телеметрические устройства).
• Федеральная торговая комиссия (FTC) защищает потребителей от недобросовестных деловых практик. Например, FTC применяет норму, требующую, чтобы определенные организации уведомляли потребителей об утечке их электронных данных о состоянии здоровья.
• Национальный институт стандартов и технологий США (NIST) обеспечивает инновации и конкуренцию в промышленности, продвигая метрологию и стандарты. Например, Лаборатория информационных технологий (Information Technology Lab) отвечает за помощь в обеспечении безопасности технологии, используемой в федеральных информационных системах.
• Управление по гражданским правам (OCR) министерства здравоохранения и социального обеспечения (DHHS) отвечает за реализацию и поддержку HIPAA («обеспечивает конфиденциальность, целостность, а также доступность электронной защищенной информации о состоянии здоровья посредством стандартов по административным, физическим и техническим мерам безопасности»).
• Штаты США также имеют различные юрисдикционные приоритеты и процессы по безопасности и конфиденциальности информации о состоянии здоровья.

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

E.13 Местоположение неактивных данных

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

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

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

E.14 Управление утраченными, украденными или пропавшими мобильными устройствами

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

E.15 Согласия, авторизации и другие организационные вопросы

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

E.16 Службы локации

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

E.17 Использование нескольких мобильных устройств

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

E.18 Применение эвристик

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

E.19 Отличие данных, «введенных пациентом» и «предоставляемых пациентом»

Отличаются ли данные, «введенные пациентом» и «предоставляемые пациентом»? Если да, то как могут влиять эти два типа данных на их пользователей (а именно на поставщиков медицинской помощи, просматривающих такую информацию на мобильных устройствах)? Например, что означают «введенные пациентом данные», когда в качестве веса пациента в последний вторник появляется число 165? Это показания ванных весов, на которых он стоял или его оценка «глядя на себя в зеркало»? Были ли весы недавно откалиброваны? Была ли пружина весов холодной (что повышает результат)? Лгал ли пациент (или был излишне оптимистичен к своему весу), а весы показывали 185, но пациент отказался верить в такие показания? Были ли на пациенте надеты тяжелые сапоги и пальто? Не переставил ли пациент цифры при вводе числа 156? Был ли у батареи низкий заряд, приводящий к неточным показаниям?

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

Таким образом, возникают вопросы: кто (или что) ввел данные? Кто (или что) является источником данных? Могут ли эти данные по каким-либо причинам быть «плохими» (например, ошибочными, неправильными или неточными)?

Далее, если мобильное устройство пациента получает результат лабораторных исследований от службы лаборатории «Direct-To-Consumer», а затем отправляет его в свою ПЭМК, то эти данные можно считать полученными от профессионального источника или от пациента?

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

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

E.20 Отличие «автора данных» от «источника данных»

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

E.21 Связь между ПЭМК, ЭМК и мобильными устройствами

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

E.22 Отклики на запросы машин обработки правил

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

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

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

Приложение F (справочное)

ИСТОРИЯ ВОПРОСА

F.1 Что представляет собой организация HL7?

Созданная в 1987 г., Health Level Seven (HL7) представляет собой некоммерческую организацию, занимающуюся разработкой стандартов и аккредитованную Американским национальным институтом стандартов (American National Standards Institute, ANSI). В ее задачи входит разработка стандартов обмена, интеграции, совместного использования и извлечения электронной медицинской информации; поддержка клинической практики, а также поддержка управления, предоставления и оценки медицинской помощи. Аккредитация ANSI в сочетании с собственными процедурами HL7 предусматривает, что любой стандарт, опубликованный HL7 и представленный на утверждение ANSI, должен быть разработан и утвержден в результате осуществления процесса, который следует процедурам ANSI по достижению открытого консенсуса и отвечает требованиям баланса интересов за счет примерно равного участия в процессе голосования различных постоянных групп, испытывающих материальное воздействие стандарта (например, производители, поставщики медицинской помощи, государственные органы, консультанты, некоммерческие организации). Этот баланс интересов обеспечивает ситуацию, при которой конкретные группы никогда не отказываются от участия, но при этом не доминируют в разработке и утверждении предлагаемого стандарта. Дополнительную информацию и историю создания ANSI можно найти на веб-сайте http://www.ANSI.org.

F.2 История и ответственность Рабочей группы PHR

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

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

Рабочая группа PHR проанализировала определения PHR, функциональные описания и другой полезный материал U.S. Department of Health and Human Services (Министерство здравоохранения и социальных служб США), проект фонда Markle/Connecting for Health Initiative, American Health Information Management Association (Американской ассоциации управления медицинской информацией), U.S. National Cancer Institute (Национального института онкологии США) и другие источники. Рабочая группа получила большое количество информации от своих добровольных членов, имевших непосредственные знания о функциональности рыночных систем ведения ПЭМК, экспертные знания по защите конфиденциальности медицинской информации и неприкосновенности личной жизни, а также знания о функциональности систем ведения ЭМК.

Рабочая группа HL7 EHR (EHR WG) признательна следующим координаторам Рабочей группы персональных электронных медицинских карт (PHR WG) за их неоценимый вклад в формирование представленного здесь материала. Ряд других членов Рабочей группы PHR, чьи имена не могут быть указаны здесь из-за краткости, также внесли огромный вклад в разработку PHR-S FM.

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