agosty.ru35. ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ. МАШИНЫ КОНТОРСКИЕ35.240. Применение информационных технологий

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

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

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

ФЕДЕРАЛЬНОЕ АГЕНТСТВО

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ


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


ГОСТР

HCO/HL716527— 2019


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

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

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

{ISO/HL7 16527:2016, IDT)

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

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


Предисловие

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

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

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

  • 4 Настоящий стандарт идентичен международному стандарту HCO/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)

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

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

Содержание

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приложение В (справочное) Глоссарий

Приложение С (справочное) Источники ПЭМК

Приложение О (справочное) Предполагаемое использование

Приложение Е (справочное) Влияние мобильного устройства и аспекты, относящиеся к ПЭМК

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

Приложение G (справочное) Благодарности

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

Предисловие к HCO/HL7 16527

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

Процедуры, использованные для разработки настоящего документа, и процедуры, предусмотрен* ные для его дальнейшего ведения, описаны в Директивах ИСО/МЭК. Часть 1. В частности, следует отметить различные критерии утверждения, требуемые для различных типов документов ИСО. Проект данного документа был разработан в соответствии с редакционными правилами Директив ИСО/МЭК. Часть 2 (см. www.iso.org/directives).

Необходимо обратить внимание на возможность того, что ряд элементов данного документа могут быть предметом патентных прав. Международная организация ИСО не должна нести ответственность за идентификацию таких прав, частично или полностью. Сведения о патентных правах, идентифициро* ванных при разработке документа, будут указаны во Введении и/или в перечне полученных ИСО объявлений о латентном праве (см. www.iso.org/patents).

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

Для разъяснения значения специальных терминов и выражений ИСО, относящихся к оценке соответствия. а также информации, относящейся к приверженности ИСО принципам ВТО по техническим барьерам в торговле (ТВТ) см. следующий URL: Foreword-Supplementary information.

За данный документ несет ответственность Технический комитет ИСО/ТК 215 «Информатизация здоровья».

Введение

Примечания для читателей

Функциональная модель системы ведения персональных медицинских карт HL7 (ФМ СВ ПЭМК) была утверждена в качестве проекта стандарта для пробного использования (DSTU) в июле 2008 г. В сентябре 2010 г. ФМ СВ ПЭМК была представлена в Технический комитет ИСО/ТК215 на голосование в качестве новой рабочей темы (NWIP). и были получены комментарии от международного сообщества. Полученные комментарии были использованы для уточнения и совершенствования проекта стандарта. В сентябре 2013 г. стандарт был уточнен и повторно поставлен на голосование, а комментарии были выверены, и это отражено в нынешней версии.

Информация об организации HL7 приведена в Приложении F.

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

Не применимо для Версии 1.

Предыстория

Персональная электронная медицинская карта (ПЭМК) по сравнению с системой ведения персональных электронных медицинских карт (СВ ПЭМК)

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

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

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

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

ГОСТ Р HCO/HL7 16527—2019

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

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

Health informatics. HL7 personal health record system functional model. Release 1 (PHRS FM)

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

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

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

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

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

  • • спецификацией сообщений;

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

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

  • • спецификацией базовой ПЭМК (т. е. самой записи);

■ упражнением по созданию определения ПЭМК;

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

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

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

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

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

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

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

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

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

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

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

  • 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). Поскольку рекомендуется, чтобы ФМ СВ ПЭМК содержала все обоснованно предполагаемые функции С8 ПЭМК, то она не претендует на описание всех функций, которые можно обнаружить в любой конкретной СВ ПЭМК. Кроме того, будут разработаны функциональные профили, ограничивающие функции предусмотренным применением [см. 5.1 «Введение (ссылка)»]. В настоящем документе определена функциональная модель СВ ПЭМК и описано общее использование профилей и приоритетов (см. примеры заинтересованных сторон, которые могут создавать профили, в Приложении С «Источники ПЭМК).

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

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

Профили

Персональное здоровье

Вспомогательный

Информационная инфраструктура

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

2

X

5

с

РН.1 Л Профиль владельца учетной жал оси

PHЛЛ Управлять историей тиничеоэм дджьос и данными о пиушемакпмнии

РН.3.0 Благополучна, профилактика и самолечение

РНЛЛУ^ивлятьсаиктарньы просвещением

РН.5.С Поддержка решений владельца учетной зелием

РН.6.0 Управлять посешенияым поставщиков медшинсяэй помощи

«

а

й

S.1.0 Управление поетавимком медицинской помощи

8.20 Управление финансами

8,3.0 Лдмжистрвтивжта утраяленее

3.4.0Управление другими ресурсами

У

S «

IN.1.0 Угфешинио информацией медицинской мпмеи

IN2Я ИктеролереЛльность на основе стандартов

1N49.O Бкопвонмпь

IN.4.0 Прослеживаем»» шмсм

Рисунок 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)).

ОСмпечитъ <ewnMiiocn. (СистмМ

Управлять доступом

Проопвжявяп»

Паддврвжшлъ (Операдои)

Аугвнтмфа цм реветь

Аятормаовать

Вести журнал

Веетмавдмт

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

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

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

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

Упрампъ (ДмшмЮ

Сьбрся.

9квпувт*|ямвяь

Прин г.....'и-

«—.

Оцмпмип.

У1ЮТПЪ мнмваоыь МННЫК

Ъч*»

Иицммсь

-

УЯРМГЪ

Мт*

*л*п*«мь

лмлаааасъ

Ляп

У----

<Имг» •аыМшчм*

■егш,

.Barnau— П|« — I ги

HWWBffV

Омвтк

Лаиппъ

от*

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

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

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

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

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

  • 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 Область вторичного использования данных ПЭМК

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

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

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

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

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

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

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

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

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

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

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


Рмлнмцив


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


Функционмыны модель СВ ПЭЖ


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

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

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

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

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

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

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

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

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

    • 5.5.1 Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

РН1

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

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

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

  • * добавляют новую дочернюю функцию, когда определено, что отсутствует применимая функция в PHR-S FM. удовлетворяющая функциональные потребности функционального профиля.

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

Функциональные профили НЕ ДОЛЖНЫ менять имя или объявление функции, за исключением случаев адаптации к специфичной номенклатуре сферы применения. 8 этих случаях код страны [ИСО 3166 (все части)] Международной организации по стандартизации (ИСО) ДОЛЖЕН быть добавлен к идентификатору функции в функциональном профиле. Специфичное обозначение кода страны ISO оставляется на усмотрение разработчиков профиля. Рекомендуется, чтобы профиль содержал отображение имени функции и/или ее объявления в ФМ СВ ПЭМК на имя и/или объявление, адаптированные к конкретной стране. Также рекомендуется, чтобы филиал организации HL7. действующий в конкретной сфере, координировал бы использование кодов стран ИСО для всех профилей в этой сфере.

  • 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 «Правила создания новых функций в функциональных профилях».

Включение дополнительного критерия, изменение последовательности критерия и предоставление большей детализации, специфичной для конкретного профиля, сверх того, что определено в функциональной модели, осуществляется в соответствии с набором правил по добавлению нового критерия или изменения существующего критерия, определенных в S.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. Если применима зависимая ситуация, то создать критерий «должен», применяющий зависимость к критерию «условно обязателен», в результате чего создаются одна или несколько новых, ограниченных версий критерия «условно обязателен».

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

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

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

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

  • 10. Быть структурированным в соответствии с требованиями к структурированию, определенными для функциональной модели в 5.6.1 «Иерархическая структура».

  • 11. Использовать глоссарий глаголов действия для модификации или создания новых критериев соответствия.

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

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

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

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

  • 4. Заменить критерий «по возможности должен» на «должен» или «может».

  • 5. Заменить критерий «может» на «должен» или «по возможности должен».

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

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

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

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

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

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

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

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

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

  • 3. Изменять для любой функции ФМ СВ ПЭМК обязательные критерии соответствия на необязательные (т. е. заменять «должен» на «по возможности должен» или «может»).

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

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

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

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

  • 1. ПО ВОЗМОЖНОСТИ ДОЛЖНЫ использоваться критерии соответствия, чтобы избежать создания новой функции. Это может быть сделано, например, в случаях, если исходные критерии соответствия функции слишком широки, а именно: разделить в функциональном профиле унаследованные критерии соответствия ФМ СВ ПЭМК или базового функционального профиля на два критерия, один из которых является обязательным, а другой необязательным.

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

  • 2. Если «листовая» функция существует, но она слишком широко описана в ФМ СВ ПЭМК или ба-зовом функциональном профиле, чтобы критерий соответствия мог адекватно ограничить ее. то функ* ция МОЖЕТ быть расщеплена следующим образом:

  • 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. Включать только модифицируемые функции из раздела «Общий» Приложения А с приоритетом Essential Now и идентифицировать функции из другого раздела Приложения А функциональной модели, применимые к функциональному профилю-компаньону. Для каждой идентифицированной функции следует указать ее приоритет (т. е. 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» и/или дополнительной функциональности. В заключение изготовитель добавляет критерии соответствия для каждой функции, наследующей их (без изменения) непосредственно из ФМ СВ ПЭМК. Тем самым изготовитель имеет возможность перечислить текущую функциональность и при желании указать планы на будущее. В сущности, это аналогично объявлению о соответствии изготовителя (концепция, с которой большинство изготовителей уже знакомы). Изготовитель может создать несколько функциональных профилей.

К1^Ш^Г . Урьмнь4-йнт»рог»13вй*львы1

^^•**перопе₽еШш»С»*«гп»Ш)С1 oqwqmiumi J няомдартаж

|^кЯ * Пршлмхг enswfnw мнтчх*чмйапмст« ЭМК

' Увеемь Э * ОйядиеюьА

J - »hftMMW>*eyaKwiiitWi44Mtiwi.4»»№Р»ииi wiihmi -С^ЖИЛМ>0<МС*Ж*ЯМИ1111МИ1»ИМ1И1«1 r>ww■»

-(ЬМвММГвНИМРШФМХде МЯМ)ЯГХЯИ1 РШ « HAMtM яшймшмм

оаань 1 - Пврвспи мнр<юш»й ^p-mwtnawMiw—nniwww»p»a*—.wwww—Hnty—ичм Urp»6<twnM м цидпсиг—win wriwiimif нчи»н

—ГГИ11ДКП114 WtrW!JHWIIllllP)HHBMHTHWHnr<—»H|t

г Mhw www» ммш*АМм*^«пм*. ЭК мммц «нгоа * «w>y

- а*м«к*м аммж аик«м ммлм мм ямиганы» мвд*чх

Ркяатм рынш


Д«пу»« , |

сайчк у


MAMfina


Рисунок 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 Как применять «условную обязательность»

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

  • - Скопировать критерий в функциональный профиль.

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

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

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

Для новых критериев добавить объяснение и/или цитирование зависимости. Например. «Нормативные требования к этому функциональному профилю определяются федеральным законодательством США в Правилах конфиденциальности HIPAA(45 CFR, части 160,162 и 164)». Объяснение, или цитирование, может быть дано в приложении. Вполне вероятно, что несколько критериев будут давать ссылку на те же самые объяснения или цитирование.

Примеры:

Критерии функционального профиля

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

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

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

Таблица 2 — Сводка действий при существовании зависимости

ФМ св ПЭМК

Применяется ли зависимость?

Применимость

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

Условно обязательный

Да

Обязательная

Скопировать критерий из ФМ СВ ПЭМК и описать его как «должен»

Обязательная

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

Обязательная

Добавить объяснение или цитирование

Необязательная

Добавить дополнитегъный критерий, произведенный от «условно обязательного» критерия. Использовать «должен». «по возможности должен» или «может»

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

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

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

ФМ се ПЭМК

Применяется ли зависимость?

Применимость

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

Условно обязательный

Нет

Обязательная

Скопировать критерий из ФМ СВ ПЭМК и описать его как «должен»

Обязательная

Добавить объяснение

Необязательная

Добавить дополнитегъный критерий, произведенный от «условно обязатегъного» критерия. Использовать «должен». «по возможности должен» или «может»

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

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

Примеры:

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

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

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

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

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

Список функций

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

В

Тив

йк

тгтгпг И

Отеешм1

Кртяряя

Критеуыя

фуипут

фуниря

функции

*

ампяйтетмв

СтрмМ

Сфммыб

НфметямыА

НВрненанлй

СарякмыЛ

Сирвяюш1

НфШПШКМЙ

Сирт2»

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

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

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

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

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

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

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

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

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

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

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

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

Глоссарий

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

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

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

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

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

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

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

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

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

В.З Известные вопросы

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

  • • Этот глоссарий был пересмотрен только в отношении глаголов действия. Группа глоссария (GT) намерена повторно изучить другие термины глоссария в будущем.

  • • Было уделено серьезное внимание согласованию определений с признанными словарями. Были испогъзо-ваны два (2) основных словаря:

  • • //dictionafy.reference.comfindex.html и

  • • Канадский Оксфордский словарь.

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

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

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

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

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

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

  • • Категория «Управление данными».

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

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

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

Таблица В.1 — Обеспечить безопасность (Системы)

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

Управлять доступом

Прослеживать

Поддерживать (Операции)

Аутентифицировать

Авторизовать

Вести журнал

Вести аудит

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

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

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

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

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

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

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

  • • Эксплуатировать: хранить, изменить и устранить данные:

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

  • • Изменить: редактировать данные путем модификации, аннотировать данные примечаниями, пометить данные метками, гармонизировать данные с другими источниками, интегрировать данные, связать с другими данными:

  • • Устранить: удалить данные из индекса или каталога, очистить данные, хранящиеся на накопителе.

  • - Предоставлять; извлечь данные на основе определенных критериев, представить данные на подсоединенном устройстве, передать данные внешним системам или устройствам.

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

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

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

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

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

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

Таблица В.2 — Управлять (Данными)

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

Собрать

Эксплуатировать

Предоставить

Обмениваться

Определить

Управлять ВИДИМОСТЬЮ данных

Хранить (Store)

Изменить (Update)

хранить (Remove)

Извлечь (Extract)

Представить (Present)

Передать (Transmit)

Экспортировать (Export) Импортировать (Import) Получить (Reoewe) Передать (Transmit)

Анализировать (Analyze)

Решить (Decide)

Деидентифи-цировать (De-Ide ntify) Скрыть (l-bde) Маскировать (Mask) Восстановить идентификацию (Re-Ide ntify) Раскрыть (Unhide) Демаскировать (Unmask)

Автоматически заполнять (Auto-Рори late) Ввести (Enter) Импортировать (Import) Получить (Receive)

Архивировать (Archive) Резервировать (Backup) Дешифровать (Decrypt) Шифровать (Encrypt) Восстановить (Recover) Возвратить (Restore) Сохранить (Save)

Аннотировать (Annotate) Аттестовать (Attest) Редактировать (Edit) Гармонизировать (Harmonize) Интегрировать (Integrate) Связать (Link) Пометить (Тад)

ЭДалить (Delete) Очистить (Purge)

м UI


ГОСТ Р HCO/HL7 16527—2019


  • • Обратить эти действия: восстановить идентификацию, раскрыть данные, демаскировать данные.

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

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

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

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

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

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

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

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

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

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

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

В.5.1 Введение

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

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

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

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

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

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

В.6 Построение строгих критериев соответствия

При конструировании КС огромное значение имеют точность, ясность и согласованность. По возможности необходимо соблюдать следующие правила:

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

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

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

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

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

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

При построении строгих КС должна использоваться следующая общая грамматическая структура:

Система (ДОЛЖНА | ПО ВОЗМОЖНОСТИ ДОЛЖНА | МОЖЕТ] (обеспечить способность] (глагол действия] (обьект(ы)] (участники)] (квалификаторы)] («в соответствии с областью практики, политикой организации или действующим законодательством»].

  • • Система является субъектом всех критериев соответствия (КС). Поэтому (субьвкт(ы)] не является параметром и был заменен на «систему».

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

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

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

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

  • • Конструкция [обеспечить способность] является необязательной и используется, когда действие будет зависеть от вмешательства пользователя:

  • • Конструкция (глагол действия] обязательная. Глагол действия должен быть взят из стандартизованного списка, содержащегося 8 глоссарии, и его значение должно соответствовать тому, что описано в глоссарии. Если другой глагол представляется более предпочтительным, то предлагается найти этот глагол в глоссарии в разделе определений, зде он может быть дан с предложениями по глаголу, который его заменяет, а также составу. В этом руководстве даны многочисленные примеры.

  • • Конструкция (объект (ы)] обязательная. Идентифицирует обьект(ы) действия.

  • • Конструкция (учэстмик(и)] необязательная. Включает пользователей (или внешние систем), участвующие или подвергающиеся воздействию указанного действия.

•Конструкция (квалификатор(ы)]: необязательная. Она может относиться ко времени, интервалу, условию (ям). Может включать (например) такие термины, как «автоматически», «вручную», «в реальном времени», «в соответствии с биэнес-правилами».

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

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

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

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

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

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

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

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

Термин

Определение

Цитирование

местоположение термина в функционалыюй модели

Принимать (Accept) (УСТАРЕВШИЙ ГЛАГОЛ)

Вместо него используйте «ПРЕДСТАВИТЬ (PRESENT) или ПРЕДОСТАВИТЬ (RENDER) сообщение о приемлемости, основанное на установлении факта (АНАЛИЗИРОВАТЬ (ANALYZE) или РЕШИТЬ (DECIDE)), что данные валидны». Адаптировать к контексту

Предоставить доступ (Aooess)

ПРЕДОСТАВИТЬ ДОСТУП (ACCESS) —устаревший оборот. Вместо него используйте УПРАВЛЯТЬ ДОСТУПОМ (CONTROL-ACCESS), если контекст предаолага-ет управление доступом к системе.

Используйте ПРЕДОСТАВИТЬ (RENDER), или ПРЕДСТАВИТЬ (PRESENT), или другой уместный глагол действия, если контекст предполагает доступ к данным

Глоссарий ФМ С В ПЭМК

«...в соответствии с ролью пользователя, политикой организаши игм законодательством»

(..according to user rote, organizational pokey. andtor junsckcbonai taw)

Ключевая фраза в ФМ СВ ПЭМК. позволяющая адаптировать определенную функциональность в зависимости от различающиеся потребностейЛребований различных участников. (См. «Roль пользователя» (User Role). «Полпика организации» (Organizational Pokey) и «Законодатегъство» (Jurisdictional Law). Три элемента ключевой фразы могут влиять друг на друга, из-за чего может потребоваться разрешение конфликтов. Например, участник владельца учетной записи ПЭМК я оппи пользователя может потоебовать. чтобы опоеоеленный элемент дачных ПЭМК хранился сто лет; а у соответствующей организации может быть политика огизнизапни лоеатсматоиваюшая хоанение элемента не палее Злет: а лоименимый ноомативно-поаеовой акт законолагтегъства может поелусматои-вать хранение элемента не долее 7 лет

Действующее лицо (Actor)

Физическое лицо, организация или действующее лицо системы

Подать тревожный сигнал (Alert)

Тип уведомления, предусматривающий действие получателя

Глоссарий ФМ СВ ЭМК

Внести изменения (Amend) (УСТАРЕВШИЙ ГЛАГОЛ)

Вместо него используйте РЕДАКТИРОВАТЬ (EDIT)

Анализировать (Analyze)

ОПРЕДЕЛИТЬ (DETERMINE) действия процесса обработки данных с помощью сравнения, корреляции, или взэештеания определенных дашых и применения клиничесюгх правил, или бизнесюрааил. 8 результате чего прийти к решению (см. РЕШИТЬ). Например, система монет АНАЛИЗИРОВАТЬ (ANALYZE) информацию о пациенте, используя базу данных межлекарственного взаимодействия и набор клинических правил. Другим примером является возможность системы АНАЛИЗИРОВАТЬ (ANALYZE) различные протоколы, связанные с состоянием пациента. Еще один пример: лицо может АНАЛИЗИРОВАТЬ (ANALYZE) гфвдла-гаемые уточнения домашнего адреса пациента и РЕШИТЬ (DECIDE) отклонить предлагаемые уто*ыения


ГОСТ Р HCO/HL7 16527—2019


т«рмии

Определение

цитирование

Местоположение термина е функциональной модели

Аннотировать (Annotate)

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

ИЗМЕНИТЬ (UPDATE) данные, добавляя комментарии или примечания к данным без редактирования собственно данных. Например, перед подписанием протокола лечащий ерам может АННОТИРОВАТЬ (ANNOTATE) информацию, введенную ер эн ом-интерном

Анонимизировать (Anonymize)

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

Архивировать (Arcrtve)

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

ХРАНИТЬ (STORE) данные путем перемещения на носитель длительного хранения данных с удалением или очистхой данных в исходном оперативном хранилище данных 8 соответствии с областью практики, политикой организации или действующим законодательством. Например, система больницы «Oak Street» ав-томатичеоси АРХИВИРУЕТ (ARCHIVE) данные пациентов, которые старше 6 лет. а именно шифрует и сжимает их. перемещает на носитель длительного хранежя данных, очищает их. идентифидоруя данные по году и месяцу, и создает ссылку на архивированные данные. Другой пример: система мажет автоматически АРХИВИРОВАТЬ (ARCHIVE) заменяемые расписания амбулаторного приема

ISO 18308

Глоссарий ФМ СВ ЭМК

Ассоциировать (Associate)

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

Аттестовать (Attest)

Владелец учетной записи ПЭМК мажет «аттестовать» информацию в ПЭМК. Такая аттестация может быть полезной поставщику медицинской помощи и другим за-интересованньш лицам для определения степши доверия к жформации ПЭМК. ИЗМЕНИТЬ (UPDATE) информацию. АТТЕСТУЯ (ATTEST) запись ЭМК (или часть записи ЭМК) как подлинную. Например, врач-интерн может АТТЕСТОВАТЬ (ATTEST) созданную информацию в записи ЭМК. Другой пример: лечащий ерам мажет аннотировать версию записи, сдельную врачом-интерном, а затем АТТЕСТОВАТЬ (ATT EST) эти изменения.


ГОСТ Р HCO/HL7 16527—2019


Термин

Определение

Цитирование

Местололож*ие термина офункционалшой модели

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

Вести ауди (ЛисЫ)

ПРОСЛЕЖИВАТЬ (TRACK) деятельность, инициированную системой или пользователем, анализируя журналы на основе политик и правил. Например, система может автоматически ВЕСТИ АУДИТ (AUDIT) деевного журнала на наличие множественных неуда^ых попыток входа в систему. Другим примером может служить ВЕДЕНИЕ АУДОТА (AUDIT) администратором чрезмерных экстренных превышений полномо'мй (т.е. «разбейте стекло аварийной кнопки») для доступа к определенной информации пациента а отделении экстренной помощи

Пр и бе вить

(Augment) (УСТАРЕВШИЙ ГЛАГОЛ)

Вместо него используйте РЕДАКТИРОВАТЬ (EDIT). АННОТИРОВАТЬ (ANNOTATE) или СВЯЗАТЬ (LINK) с соответствующими квалификатора**. Прибавление (Augmentation)—это добавление информации к имеющимся медицинами данным

Аутентифицировать (Authenticate)

УПРАВЛЯТЬ ДОСТУПОМ (CONTROL ACCESS) к системе, проверяя действительность идентификатора пользователя, другой системы или устройства перед авторизацией доступа. Например, система может АУТЕНТИФИЦИРОВАТЬ (AUTHENTICATE) д-ра Джонса, проверяя его идентичность, используя идентификатор пользователя UserID и биометр**«есжое устройство. Другой пример: система отклоняет попытки Сары Смит АУТЕНТИФИЦИРОВАТЬСЯ (AUTHENTICATE) после трех неудачных вводов пароля

Автор из ация(/Щ1Ьопга bon)

(См. «Авторизация ПЭМК»)

Авторизовать (Authorize)

УПРАВЛЯТЬ ДОСТУПОМ (CONTROL ACCESS) к системе, применяя разрешения на использование определенной функциональности или просмотра определенных дажых. Например, система может АВТОРИЗОВАТЬ (AUTHORIZE) д-ру Джонсу, врачу отделения неотложной помощи, просмотр записей пациентов этого отделения. (Примечание: Предполагается, что администратор ввел набор разрешений для воех врачей отделения неотложной помощи.) Другой пример: система не АВТОРИЗУЕТ (AUTHORIZE) удаление Сарой Смит уже подписанной записи пациента

Авторизованный пользователь ПЭМК (Authorized PHR User)

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

Ниже едиведены примеры потенциальных авторизованныхполъзователей ПЭМК: •доверенное лицо владельца учетной записи ПЭМК (включая уполномоченного плательщика);

- школьная медсестра;

• администраторы летнего лагеря;


ГОСТ Р HCO/HL7 16527—2019


т«рмии

Определение

Цитирование

Мвстололож»«ив термина в функциональной модели

  • • судебные должностные лица;

  • • страховые компании;

  • • поставщики медицинской помощи;

  • • работодатели (недиональные или международные):

  • • администраторь^консультанты программы управления здоровьем; •VISA.

  • • другие пользователи ПЭМК. включая:

  • - организации здравоохранения,

• научно-исследовательаме организации.

  • - организации, проводящие клинические испытания

Автоматически заполнять (Auto-populate)

СОБРАТЬ (CAPTURE) данные с помощью автоматического ввода на основе су* шествующих данных, предоставляя значение по умолчанию, или производя от других данных, или выполняя различные биэнес-лравила ввода данных. Напри-мер.система может АВТОМАТИЧЕСКИ ЗАПОЛНЯТЬ (АитО-РОР1ЛАТЕ)полясна-званиями города, штата'провинции и страны, когда пользователь вводит почтовый индекс. Другой пример: система может АВТОМАТИЧЕСКИ ЗАПОЛНЯТЬ (AUTO-РОР ULATE) домашний адрес новорожденного по домашнему адресу матери

Резервировать (Васкод)

Эксплуатировать данные, сохраняя их копии на случай утраты, разрушения или повреждения оригинала. ХРАНИТЬ (STORE) данные, поместив копию данных в устройство с электронным доступом для сохранения на случай утраты, разрушения или повреждения оригинала. Например, система может РЕЗЕРВИРОВАТЬ (BACKUP) последоватетьные изменения в записи пациента, ежедневно обеспечивая их местное хранение. Другой пример: администратор может РЕЗЕРВИРОВАТЬ (BACKUP) полную копию определенных данных, сохраняя их за пределами оргаютэации

Собрать (Capture)

Эксплуатировать данные, помещая их в систему иш в результате вмешательства человека, или механическим способом. Например, владелец учетной записи ПЭМК может поместить данные ПЭМК в систему ведения PHRc помощью клавиатурного ввода или включить в нее данные исследовздий. собранные в Интернете. Средства ввода или записи данных в систему или в результате вмешательства человека, или механичесшм способом. (Например, импорт файла, ввод в СВ ПЭМК данных сустройства. вставка данных, полученных в сообщении.) УПРАВЛЯТЬ (MANAGE) данными с помощью автоматического заполнения, ввода. импорта или получения данных в результате вмешательства человека или автоматических средств. Например, система может СОБРАТЬ (CAPTURE) данные пациента, введенные врачом с клавиатуры или переданные врачом с мобильного устройства. Другой пример: система может СОБРАТЬ (CAPTURE) результаты лабораторных анализов с помощью автоматического получения лабораторных данных или клавиатурного ввода результатов местных тестов

httpVAvww. mernamwebster. сопУбкйюпагу/ captire

Глоосарий ФМ СВ ЭМК


ГОСТ Р HCO/HL7 16527—2019


Термин

Определение

Цитирование

Местоположение термина вфункционалшой модели

Клинический документ (С*пюа1 Document)

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

  • 1. Постоянство — клинический документ существует в неизменном виде в течение времени, определенного местшми или нормативными документами;

  • 2. Управление — клинический документ управляется лицом или органиэаедей, которой доверено оказание ему медиеднсхой помощи;

  • 3. Потенциал аутентификации — клиничеомй документ представляет собой совокупность информаеди, которую предполагается юридически аутентифицировать;

  • 4. Целостность — аутентификация клинического документа относится ко асему. а не к частям документа в отрыве от полного контекста документа;

  • 5. Удобочитаемость для человека —клинический документ читается человеком. Примечание: Учтите, что указанное выше определение не имеет в виду потенциал документа CDA, чтобы также требовать структурированиеГкодироеание данных. Таким образом, если элементу ПЭМК нужна явная поддержка структу-рирования/кодирования данных, то эту потребность лучше aceto заявить в виде функционального требования. (Ключевой аспект в том. что любое требование поддержки структурированитУкедирования данных всегда идет в дополнение к требованию поддержим читаемости единых человеком)

Комментировать (Comment)

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

Сжать (Compact)

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

Вычислить

(Compute) (УСТАРЕВШИЙ ГЛАГОЛ)

Используйте вместо него ОПРЕДЕЛИТЬ (DETERMINE) и ХРАНИТЬ (STORE) или ОПРЕДЕЛИТЬ (DETERMINE)h nPEACTABMTb(PRESENT) вэависимостиот контекста

Согласие (Consent)

Соглашение, одобрение или разрешение на некоторое действие, или намерение. которое дано добровольно компетентным лицом

IS018308. (Black's Law Dictionary. 2008]

Контекстно-зависимый доступ (Context-based access)

Примеры «Контекстно-зависимого доступа»:

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


ГОСТ Р HCO/HL7 16527—2019


Термин

Определение

Цитирование

Местололожмие термина а функциональной модели

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

  • • доступ, ограниченный ао времени (например, разрешение доверенному соседу на доступ в течение отпуска основного доверенного тмца)

Управлять доступом (Central Access)

АУТЕНТ ИФИ ЦИРОВАТЬ (AUTHENTICATE) пользователей тУили систему и АВТОРИЗОВАТЬ (AUTHORIZE) доступ к функциональности и^или данным. Например, система может УПРАВЛЯТЬ ДОСТУПОМ (CONTROL ACCESS) к данным пациента. аутентифитвтруя идентификацию д-ра Джонса и авторизуя ему обновление записей его пациентов. Другой пример: система мажет УПРАВЛЯТЬ ДОСТУПОМ (CONTROL ACCESS) к себе, отказываясь аутентифицировать посетителя больницы в системе.

Примечание: Набор глаголов действия УПРАВЛЯТЬ ДОСТУПОМ (CONTROL ACCESS) требует наличия разрешений на доступ к данным. Эти разрешения управляются набором глаголов действия УПРАВЛЯТЬ (MANAGE) данными

Контролируемый метод (Controled Method)

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

Корректировать (Correct)

Эксплуатировать данные, исправляя неправильный элемент. Например, владелец учетной записи ПЭМК макет изменить свой адресе 366 на 636 Oak Street

Создать (Create) (УСТАРЕВШИЙ ГЛАГОЛ)

Вэависимостиот контекста используйте вместо него ОПРЕДЕЛИТЬ (DET ERMINE) и ХРАНИТЬ (STORE), или ОПРЕДЕЛИТЬ (DETERMINE) и ПРЕДОСТАВИТЬ (RENDER), или ОПРЕДЕЛИТЬ (DETERMINE) и ПРЕДСТАВИТЬ (PRESENT)

Куратор (Custodian)

Куратор — лицо, управляющее полномочиями правом собственности, ответственностью и контролем над ктмничеешми данными

Решить (Decide)

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


ГОСТ Р HCO/HL7 16527—2019


Термин

Определение

Цитирование

Местоположение термина к функциональной модели

Дешифровать (Decrypt)

ХРАНИТЬ (STORE) данные, преобразуя зашифрованные данные обратно в исходную форму, чтобы их можно было понять. Например, система может ДЕ ШИФРОВАТЬ (DECRYPT) клинтческие данные, полученные от аутентифицированной системы внешней лаборатории

Деидентифицировать (De->denlfy)

УПРАВЛЯТЬ ВИДИМОСТЬЮ ДАННЫХ (MANAGE-DATA-VISIBILITY), таким образом удаляя идентификаторы из данных, чтобы риск идентификации лица был очень незначительным в обстоятельствах, указанных вобласти практики, политике организации или действующем законодательстве. Например, системе может ДЕ-ИДЕНТИФИЦИРОВАГЬ (DE-IDENTIFY) данные для научюго работника, которым хочет выполнить анализ эффективности лекарственного препарата для пациентов. больных диабетом. Другой пример: больница может ДЕИДЕНТИФИЦИРОВАТЬ (DE-IDENTIFY) данные ряда пациентов для передами профессору университета. которому для учебных целей нужны показательные случаи

Удалить (Ddele)

УДАЛИТЬ (DELETE) данные, делая их недоступными для применения. Например. пользователь может УДАЛИТЬ (DELETE) существующую запись на прием по просьбе пациента.

Примечание: Если данные становятся недействитегъными. но должны оставаться е системе, термин ПОМЕТИТЬ (TAG) более предпочтителен, нежели слово УДАЛИТЬ (DELETE) или «ажулировать» (NuSfy). Этот тип действия считается процессом «помет»м» дажых. а не процессом удаления данных. Например, специалист по управлению медицинскими данными может пожелать ПОМЕТИТЬ (TAG) определенный клинический термин как устаревший, но термин должен оставаться в системе в целях обратной совместимости

Демографические данные (Demograptuc Data)

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

http:/Avww. skmtgtossary. org/_

Разрушить (Destroy) (УСТАРЕВШИЙ ГЛАГОЛ)

Используйте вместо него ОЧИСТИТЬ (PURGE).

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


ГОСТ Р HCO/HL7 16527—2019


т«рмии

Определение

Цитирование

Мвстололож»«ие термина в функциональной модели

Определить (Determine)

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

Отобразить (Display) (УСТАРЕВШИЙ ГЛАГОЛ)

Используйте вместо него ПРЕДСТАВИТЬ (PRESENT)

Глоссарий ФМ СВ ЭМК

Загрузить (Dowrioad)

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

Редактировать (Edit)

Управлять данными с помощью изменений, усиливающих элемент. Например, владелец учетной записи ПЭМЕ может изменить свои фамилию, имя. отчество с “Джон Джеймс Смит' на “Джон Джеймс (прозвище: JJ’) Смит".

ИЗМЕНИТЬ (UPDATE) данные, корректируя, изменяя, дополняя или приращивая их. Например. вр»4 может РЕДАКТИРОВАТЬ (EDIT) домашний адрес пациента, исправляя номер дома на улице Oak Street с 368 на 638. Другой пример: врач может РЕДАКТИРОВАТЬ (EDIT) существующие сведения о травме, добавляя рентгеновский снимок сломанной кости

Шифровать (Encrypt)

Эксплуатировать данные, сохраняя их преобразованными в такую форму (шиф-ротекст), которую нелегко понять неаеторизоеанным людям или системам. ХРАНИТЬ (STORE) данные, трансформируя их в форму, которая трудна для понимания не авторизованными людьми или системами. Например, система мажет ШИФРОВАТЬ (ENCRYPT) чувствительную информацию, к примеру, финансовую *ыформа1ыю пациента

htto// searchsecurilv.

Глоссарий ФМ СВ ЭМК

techtaroet conV

sDefinition/0..

SKI14 «>212062.

OO.htrri

Ввести (Enter)

СОБРАТЬ (CAPTURE) данные локальной систе>ы, вручную описывая определенные данные. Например, владелец учетной записи ПЭМК может вручную ввести с клавиатуры наименование улицы своего адреса.

СОБРАТЬ (CAPTURE) данные, вводя их вручную (например, с клавиатуры) или с помощью других устройств ввода. Например, пользователь мажет вручную ВВЕСТИ (ENTER) с клавиатуры наименование улицы в адресе пациента.

Другой пример: пользователь может ВВЕСТИ (ENTER) вес тела пациента с помощью электронных весов


ГОСТ Р HCO/HL7 16527—2019


Термин

Определение

Цитирование

Местололоже<ие термина вфункционалшой модели

Обмениваться (Exchange)

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

Экспортировать (Export)

ОБМЕНИВАТЬСЯ (EXCHANGE) данными, отправляя данные из одной системы в другую (внешнюю) систему или сущность. Например, владелец учетной записи ПЭМК может экспортировать данные в систему поставщика медицинской помощи для включения в медицинскую карту владельца учетной записи ПЭ МК. Примечание: Термин «экспорт» имеет ограниченное применение ефункци-онагъной модели СВ ПЭМК. Рассмотрите возможность его замены на ПРЕДОСТАВИТЬ (RENDER)

Извлечь (Extract)

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

Фильтровать (Filer)

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

Гармонизировать (Harmonize)

ИЗМЕНИТЬ (EDIT) дздше. согласовывая и сверяя их с другой информацией в системе или с данными другой системы (или систем). Например, система может ГАРМОНИЗИРОВАТЬ (HARMONIZE) новым домашний адрес патента с данными систем других членов грунты лечения

Поставщик медицинской помощи

(Healthcare Provider)

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

HL7 Glossary, January 2002


ГОСТ Р HCO/HL7 16527—2019


термин

Определение

Цитирование

Местоположение термина в функциональной модели

Страховщик, осуществляющий медицинское страхование

(Hearth Insurance Carrier) ллатегъщик (Payer)

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

HL7 Glossary. January 2002

Скрыть (Hrie)

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

См. «маскировать» (mask).

УПРАВЛЯТЬ ВИДИМОСТЬЮ ДАННЫХ (MANAGE-DATA-VISIBILITY). делая специфичную информацию неводимой, чтобы ее существование обнаруживалось только авторизованными пользователями. Обозреватели записей пациентов не получают признаки существования или отсутствия скрытой информации. Например. система может СКРЫТЬ (HIDE) существование психиатрической записи пациента от всех обозревателей, кроме психиатра пациента

Прибор домашнего мониторинга (Home Monitoring Device)

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

Импортировать (Import)

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

СОБРАТЬ (CAPTURE) данные в локальную систему с помощью предварительного доступа к данным из внешнего источника и последующей загрузки и интеграцют этих данных в локальной системе. Например, система мажет ИМПОРТИРОВАТЬ (IMPORT) самые последние данные по испытанию препарата каждую пятницу вечером. Другой пример: пользователь может ИМПОРТИРОВАТЬ (IMPORT) различные наборы хороших практик, относящихся к ювенильному диабету


ГОСТ Р HCO/HL7 16527—2019


Термин

Определение

Цитирование

Местололожыие термина вфункционалшой модели

Деактивировать (Inactivate)

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

Осуществлять ввод (Input) (УСТАРЕВШИЙ ГЛАГОЛ)

Используйте вместо него СОБРАТЬ (CAPTURE). ВВОДИТЬ (ENTER). ПОЛУЧАТЬ (RECEIVE). ИМПОРТИРОВАТЬ (IMPORT) или АВТОМАТИЧЕСКИ ЗАПОЛНЯТЬ (AUTO-POPULATE) в зависимости от контекста и области применения описываемых действий

Интегрировать (Integrate)

ИЗМЕНИТЬ (UPDATE) данные, объединяя их с существующими данными контролируемым способом. Например, пользователь может ИНТЕГРИРОВАТЬ (INTEGRATE) в местную запись пациента сводки медицинской помощи, предоставленной в другой юрисдикции. Другой пример: система может ИНТЕГРИРОВАТЬ (INTEGRATE) приложение едоного входа в систему в сервисы аутентификации пользователя, существующие в системе. Еще один пример: система может ИНТЕГРИРОВАТЬ (INTEGRATE) несколько модулей третьих сторон для усиления своих возможностей

Глоссарий ФМ СВ ЭМК

Законодательство Jurisdictional Law

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

Связать Link(rnaron)

ИЗМЕНИТЬ (UPDATE) данные, ассоциируя один элемент данных с другим элементом данных. Например, система мажет СВЯЗАТЬ (LINK) запись о посещении пациента с результатами лабораторных иоследований пациента. Другой пример: система может СВЯЗАТЬ (LINK) аттестованные изменения в записи пациента с информацией, идентифицирующей автора

вести журнал Log (глагол)

ПРОСЛЕЖИВАТЬ (TRACE) мероприятия, инициированные системой или пользователем (включая доступ к дажым и^иш функциональность, попытки доступа к данным иАши функциональности, действия. выполненные с данными и/или функциональностью. а также изменения характеристик системы или версии), с помощью хранения хронологического следа этих действий. Наедимер. система может ВЕСТИ ЖУРНАЛ (LOG) фактов выполнения модификаций записи пациента. сохраняя дату, время, идентификатор погъзователя. модифишровавшего запись, а также сведения об изменениях, сделанных в записи. Другой пример: система может ВЕСТИ ЖУРНАЛ (LOG) фактов обновлений базы данных по межлекарственному взаимодействию, сохраняя дату и время обновления


ГОСТ Р HCO/HL7 16527—2019


и> «О

т«рмии

Определение

Цитирование

Мвстололоже«ие термина в функциональной модели

Эксплуатировать Mantan

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

УПРАВЛЯТЬ (MANAGE) данными с помощью хранения, изменения и^или удаления данных всистеме. Например, система мохвт предоставить возможность клиницисту ЭКСПЛУАТИРОВАТЬ (MAINTAIN) данные, сохраняя или удатя их. Другой пример: система может предоставить еоэможностьклиницисту ЭКСПЛУАТИРОВАТЬ (MAINTAIN) дажые с помощью коррек^и или аннотаций

ISO/IEC 20926:2009. 3.40

Глоссарий ФМ СВ Э МК

Управлять (Manage)

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

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

Random House Colege Dictionary

Глоссарий ФМ СВ ЭМК

Управлять видимостью данных (Manage-Data-\As4>*ty)

УПРАВЛЯТЬ (MANAGE) данными с помощью деидентификации^восстаноеления идентификации, маскированияГдемаскирования или скрытия/раскрытия данных. Например, система может предоставить администратору возможность УПРАВЛЯТЬ ВИДИМОСТЬЮ ДАННЫХ (MANAGE-DATA-VISIBILITY) в терминах, кому разрешено просматривать специфичные данные пациента

Мэск»фовггть (Mask)

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

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

ISO 15143-1:2010. 3.1.21

Глоосарий ФМ СВ ЭМК


ГОСТ Р HCO/HL7 16527—2019


Термин

Определение

Цитирование

Местололоже«ие термина афункционалшой модели

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

УПРАВЛЯТЬ ВИДИМОСТЬЮ ДАННЫХ (MANAGE-DATA-VISIBILITY) путем затенения (маскировки) специфичных элементов данных, чтобы эта информация была доступна только авторизованным пользователям. Обозреватели записи о пациенте могут видеть, что данные существуют, но не могут видеть их содержание. Например, администратор может МАСКИРОВАТЬ (MASK) статус беременности всех пациентов младше 18 лет. за исключением персонала акушерского отделения

Объединить (Merge) (УСТАРЕВШИЙ ГЛАГОЛ)

Используйте вместо него ИНТЕГРИРОВАТЬ (INTEGRATE)

Глоссарий ФМ СВ ЭМК

Уведомление (существительное) (Notice)

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

Глоосарий ФМ СВ ЭМК

Извещение (Notification)

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

Глоссарий ФМ СВ ЭМК

Ажулировать Nidify (УСТАРЕВШИЙ ГЛАГОЛ)

Используйте вместо него «ПОМЕТИТЬ как аннулированное» (TAG as nidified)

Устареть (Obsolete) (УСТАРЕВШИЙ ГЛАГОЛ)

Используйте вместо него «ПОМЕТИТЬ как устаревшее» (TAG as obsolete)

Политика организации (Organizational Роксу)

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


ГОСТ Р HCO/HL7 16527—2019


т«рмии

Определение

цитирование

Мвстолвложо«ие термина в функциональной модели

Создать выгодные данные (Output)

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

Учетная запись ПЭМК (PHRAooount)

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

Учетная запись ПЭМК обеспечивает владельцу учетной записи ПЭМК (1) доступ к его персональным медицинским данным и (2) доступ к функциям системы ведения ПЭМК.

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

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

Владелец учетной записи ПЭМК

Р HR Account Holder

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

Доведенное лицо владельца учетной записи ПЭМК PHR Account Holder Proxy

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

Приложение ПЭМК PHR Application

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


ГОСТ Р HCO/HL7 16527—2019


кэ

Термин

Определение

Цитирование

Местололожыие термина а фуняционалыюй модели

Авторизация ПЭМ К PHR Authorization

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

Авторизации ПЭМК могут быть предоставлены определенным лицам ида специфичным удаленным комгъютерным системам.

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

Авторизации ПЭМК могут предусматривать разные уровни доступа, например, «только для чтения», «только для записи», «чтениа^запись» итл.

Конкретные разрешения и уровни авторизации ПЭМК могут варьироваться у разных спонсоров ПЭМК и сервис-провайдеров ПЭМК; приведенные здесь описания не предполагают предписания конкретного подхода.

Авторизация — это процесс выдачи кому-либо разрешения на какие-либо действия или на что-дабо. 8 многопользовательской компьютерной системе системный администратор определяет для системы, каким пользователям разрешен дост/i к системе и каковы привилегии доступа (например, доступ к конкретным папкам файлов, доступ в определенные часы, величина места, выделенного для хранения данных, и т.д). Кода скоро кто-то авторизовался в компьютерной опера-даонной системе или приложении, системе или приложению мажет понадобиться идентификация ресурсов, которые могут быть выделены пользователю во время сеанса доступа. Таким образом, авторизадая иногда выглядит как предварительная настройка разрешений системным администратором и реальная проверка разрешенных параметров, которая происходит, когда погьзователь получает доступ

Определение рабочей группы ПЭМК Wo (tang Group definition, и

Mitt// searohaoosecu-Mv.tecMaraol.

conVsDefimton/

0 sd92

aci211622.00. hlmi

Сервис-провайдер ПЭМК PHR Service Provider

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

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

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

Спонсор ПЭМК PHR Sponsor

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

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


ГОСТ Р HCO/HL7 16527—2019


т«рмии

Определение

Цитирование

Мвстололож»«ив термина в функциональной модели

Представить {Present)

УПРАВЛЯТЬ (MANAGE) данными системы, предоставляя указатели на данные, но не сами данные. Например, владелец учетной записи ПЭМК мажет предоставить поставщику медицинской помощи список изображений лучевой диагностики, но не сами изображеедя.

Предложить просмотреть, привлечь чье-либо внимание, передать или представить кому-либо; показать или отобразить.

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

Примечание: Разумно предположить, что любые представлению данные должны быть соответствующим образом отформатированы, отфигьтрованы, переведены. преобразованы. отображены иАгли нормализованы и т.п.

EHR-S FM Glossary

Псеадонимизедоеать (Pseudonymize)

ЭКСПЛУАТИРОВАТЬ данные, создавая псевдоним для их субъекта. Например, фамилия, имя и инициал «Роберт К Джеймисон» могут быть заменены в медицинском документе на псевдоним, скажем. «Джон Смит», перед тем, как знэсо-мить с ним других лед

Очистить {Purge)

ЭКСПЛУАТИРОВАТЬ (MAINTAIN) контрогъ данных, удаляя доступ к ним с помощью функций удаления (deletion или removal) таким образом, чтобы они более не существовали. Например, владелец учетной записи ПЭМК может выбрать удаление всех записей, относящихся к клинике Elm Street Cfenic. поскольку он никогда не посещал эту клинику и переезжает в другую страну.

УСТРАНИТЬ (REMOVE) данные, делая их невосстанавливаемыми в хранилище *Уили на носителе данных. Например, система может ОЧИСТИТЬ (PURGE) запись пациента Джона Смита в соответствии с правилом. выделяющим все записи старше семи лет, (Примечание: Destroy и Purge— синонимы, предпочтительный английский термин — PURGE)

Читать (Read)

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


ГОСТ Р HCO/HL7 16527—2019


Термин

Определение

Цитирование

Местоположение термина афункиионалыюй модели

Получить (Receive)

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

СОБРАТЬ (CAPTURE) данные из внешнего источника, получая их без ручногоАзпе-дативного вмешательства пользователя. Например, система мажет ПОЛУЧИТЬ (RECEIVE) различные электронные письма, адресованные клиницисту, который просмотрит их позже. Другой пример: система мажет ПОЛУЧИТЬ (RECEIVE) ат аутентифицированных и авторизованных внешних систем результаты лабораторных исследований определенного пациента. Еще один пример: система может ПОЛУЧИТЬ (ЛЕСЕ1УЕ)факсимильное сообщение от внешнего устройства

Рекомендация Reoommendaton

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

Запись (существительное) (Record)

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

Глоссарий ФМ СВ ЭМК

Записать Record (УСТАРЕВШИЙ ГЛАГОЛ)

Используйте вместо него ХРАНИТЬ (STORE) (или его дочерние глаголы действия)

Глоссарий ФМ СВ ЭМК

Восстановить Recover

ХРАНИТЬ (STORE) данные, восстанавливая их исходные значения из резервных копий. Например, после поломси жесткого диска система мажет ВОССТАНОВИТЬ (RECOVER) данные за последнюю неделю, используя резервную внешнюю копию (см. РЕЗЕРВИРОВАТЬ)

Повторно идентифицировать Reidentify

УПРАВЛЯТЬ ВИДИМОСТЬЮ ДАННЫХ (MANAGE-OATA-VISIBILfTY). объединяя д&«ные ташм образом, чтобы идентичность пациента был восстановлена в соответствии с областью практики, политикой организации и/или действующим законодательством. Например, система может ПОВТОРНО ИДЕНТИФИЦИРОВАТЬ (RE-IDENTIFY) деидентифищфованные данные, предоставляя ключ, позволяющий авториэованшм пользователям повторно установить связь между данным пациентом и реидентифицированными данными этого пациента


ГОСТ Р HCO/HL7 16527—2019


т«рмии

Определение

Цитирование

Мвстололож»«ие термина в функциональной модели

Напоминание Reminder

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

Глоссарий ФМ СВ ЭМК

Устранить (Remove)

ЭКСПЛУАТИРОВАТЬ (MAINTAIN) данные, делая их недоступными или невос-станавливаемыми в соответствии с областью практики, погмтикой организации иГили действующим законодательством. Например, по запросу врэ^а система может путем очистки УСТРАНИТЬ (REMOVE) ошибочно полученную информацию о пациенте. Другой гример: система мажет по запросу адмжистратора УСТРАНИТЬ (REMOVE) путем удаления расписание часов амбулаторного приема пациентов в клинике.

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

Примечание 2: В случае, если данные стали недействительными, но должны оставаться в системе, слово ПОМЕТИТЬ (TAG) является предпочтительным по сравнению со словами УСТРАНИТЬ (REMOVE) или «аннулировать». Этот тип действия рассматривается как процесс «пометки данных», а не «удаления данных». Например, специалист по управлению медецинской информацией может пожелать ПОМЕТИТЬ (TAG) определенный клинический термин как устаревший, но оставить его в системе в целях обратной совместимости

Устранить доступ (Remove Access)

ЭКСПЛУАТИРОВАТЬ (MAINTAIN) данные, таюгм образом закрывая доступ к ним. чтобы их нельзя было извлек

Предоставить (Render)

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

Выдать отчет Report (УСТАРЕВШИЙ ГЛАГОЛ)

Используйте вместо него «ПРЕДОСТАВИТЬ отчет» или «ПРЕДСТАВИТЬ отчет»

Глоссарий ФМ СВ ЭМК

Возвратить (Restore)

ХРАНИТЬ (STORE) данше в производственной системе, используя архивированные перед этим данные. Например, система может ВОЗВРАТИТЬ (RESTORE) дантъю об обращении пациента для вернувшегося пациента, чьи данные были архив»фованы из-за неактивност и. Другой пример: система может ВОЗВРАТИТЬ (RESTORE) для расследования данные пациента, архивированные после его смерти (см. АРХИВИРОВАТЬ)


ГОСТ Р HCO/HL7 16527—2019


Термин

Определение

котирование

Местололожмие термина афункиионйлы«ой модели

Ограничить доступ (Restrict Aooess)

ЭКСПЛУАТИРОВАТЬ (MAINTAIN) данные, таким образом закрывая доступ к ним, чтобы факт их существования не стал известен запрашивающей стороне

Сохранить (Save)

ЭКСПЛУАТИРОВАТЬ (МАМТАМ)данные, помечая их вручную с целью уцержи-вания иш для запрета автоматического удаления либо копируя данные. ХРАНИТЬ (STORE) данные, помещая их в устройство с электронным доступом. Например, клиницист может СОХРАНИТЬ (SAVE) демографические данные определенного пациента или сведения о вновь назначенном лекарстве. Другой пример: администратор может СОХРАНИТЬ (SAVE) измененный список врачей, наделеншх правом практики в местной больнице

Послать (Send)

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

Хранить (Store)

ЭКСПЛУАТИРОВАТЬ (MAINTAIN) дачные е таком месте, как хранилище, библиотека или память компьютера, для хранения, будущего использования или утилизации.

ЭКСПЛУАТИРОВАТЬ (MAINTAIN) данные, резервируя их. дешифруя, шифруя, восстанавливая или сохраняя в устройстве с электронным доступом. Например, клиницист может ХРАНИТЬ (STORE) домографичесше донные определенного пациента или сведения о вновь назначенном лекарстве. Другой пример: администратор может сконфигурировать систему таким образом, чтобы она ХРАНИЛА (STORE) копии последовательных изменений определенных данных по расписанию в целях резервирования.

Примечание: Данные могут храниться в виде простого текста, а также в зашифрованной или сжатой форме

htto:/Avwwjn-

wconVOOi-Ью/

d>ct>onarv?boak=

DictK)na<vSva=

store

Поддерживать (операции) Sustan

(operations)

ОБЕСПЕЧИТЬ БЕЗОПАСНОСТЬ системы, вьтолняя действия, позволяющие системе работать предсказуемо и по предназначению. Например, система может ПОДДЕРЖИВАТЬ (ОПЕРАЦИИ), применяя бизнес-правила. обеспечивающие доступ на основе ролей к управлению авторизацией системы, тем самым защищая данные владельца учетной записи PHR в соответствии с предварительно определенными правилами безопасности и неприкосновенности личной жизни

Синхронизировать Synchronize

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


ГОСТ Р HCO/HL7 16527—2019


т«рмии

Определение

Цитирование

М«стололож»«ив термина в функциональной модели

Пометить (Тад)

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

ИЗМЕНИТЬ (UPDATE) данные, помечая их для специального применения. Например. медсестра может ПОМЕТИТЬ (TAG) записи пациентов с сильным кашлем и лихорадкой, сделанные на прошлой неделе. Другой пример: врач общей практиш может ПОМЕТИТЬ (TAG) определенные данные для просмотра онкологом. Еще один пример: адкмнистратор может ПОМЕТИТЬ (TAG) версию стандарта обмена данными как устаревшую.

Примечание: см. «флаг» (flag), если значением является сигнализация о ситуации

Задача (Task)

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

Глоссарий ФМ СВ ЭМК

Прослеживать (глагол) Track (verb)

ЗАЩИТИТЬ (SECURE) систему, ведя журнал и аудит действий, инициированных системой или пользователем. Например, система может ПРОСЛЕЖИВАТЬ (TRACK) количество времени, в течение которого система была недоступна в прошлом месяце. Другой пример: система может обеспв'епь администратору возможность ПРОСЛЕЖИВАТЬ (TRACK) число активных пользователей вновь установленного компласса функциональности системы

Передать (Transmit)

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


ГОСТ Р HCO/HL7 16527—2019


Термин

Определение

Цитирование

Мвстололожмие термина афункционалшой модели

Раскрыть (Unhide)

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

Демаскировать (Unmask)

УПРАВЛЯТЬ ВИДИМОСТЬЮ ДАННЫХ (MANAGE-DATA-VISIBILITY). делая зама-скированную информацию видимой. Например, администратор может пожелать ДЕМАСКИРОВАТЬ (UNMASK) финансовую информаций конкретного пациента для приемного отделения. К примеру, система может предоставить врачу отделения неотложной помощи возможность ДЕМАСКИРОВАТЬ (UNMASK)CTBTyc беременности пациент «1, который был представлен системой как"”’*’*-, и раорыть статус «беременная»

Изменить (Update)

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

ЭКСПЛУАТИРОВАТЬ (MAINTAIN) данные, аннотируя, редактируя. гармонизируя, интегрируя, связывая и помечая их. Нагример, клиницист макет ИЗМЕНИТЬ (UPDATE) дозировку лекарственного препарата пациента. Другой пример: система может ИЗМЕНИТЬ (UPDATE) запись пациента

ISO 22000:2005, 3.17

Глоссарий ФМ СВ ЭМК

Загрузить Upload

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

Роль пользователя (User Rote)

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

Представление (существ.) View

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

Специфичная информация, отображаемая на экране комгъютера после того, кек она была отфильтрована системой. Сравните с «отобразить» (Display)

Глоссарий ФМ СВ ЭМК


ГОСТ Р HCO/HL7 16527—2019


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

Источники ПЭМК

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

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

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

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

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

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

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

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

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

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

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

СЛ Банк медицинских записей

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

С.4 Имеющая гибридную связь с плательщиком и поставщиком медицинской помощи

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

С.5 Клиент-ориентированная модель на основе приложений в сети Интернет

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



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


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

Предполагаемое использование

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

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

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

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

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

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

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

Целью создания функционального профиля является поддержка бизнес-мсщели испогъзоваиия СВ ПЭМК с помощью выбора применимого подмножества функций из ФМ ПЭМК. Например, функциональный профиль может быть создан производителем, разрабатывающим уникальный продукт для специфичной популяции, или любым лицом^сущностью. желающим предусмотреть подмножество функций, необходимое для конкретной цели или конкретной сферы применения (см. Приложение С «Источники ПЭМК»). Когда применимое подмножество функций выбрано, то пицо/сущность. создающее профигъ. присваивает каждой функции приоритет Essential Now. Essential Future или Optional. Дополнительная информация о шагах по созданию функционального профиля содержится s руководстве «How-to Guide for Creating Functional Profiles», выпущенном отдельно Рабочей группой EHR.

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

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

Влияние мобильного устройства и аспекты, относящиеся к ПЭМК

Е.1 Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • • Управление по контролю за продуктами и лекарствами США (FDA) регистрирует медицинские устройства и мобильные приложения, влияющие на безопасность пациентов. Например. FDA регулирует небольшое подмножество мобильных медицинских приложений, которые могут представлять потенциальный риск для пациентов, если эти устройства не работают надлежащим образом.

  • • Федеральная комиссия по связи США (FCC) регулирует внутреннюю и международную связь, а именно; проводную, спутниковую и кабельную, используемую мобильными устройствами. Например. FCC регистрирует определенные радиочастотные медицинские устройства, включая имплантируемые устройства (например, кардиостимуляторы) и устройства мониторинга пациентов (например, беспроводные телеметрические устройства).

  • • Федеральная торговая комиссия (FTC) защищает потребителей от недобросовестных деловых практик. Например. FT С применяет норму, требующую, чтобы определенные организации уведомляли потребителей об утечке их электронных данных о состоянии здоровья,

  • • Национальный институт стандартов и технологий США (NIST) обеспечивает инновации и конкуренцию в промышленности, продвигая метрологию и стандарты. Например. Лаборатория информационных технологий (information Technology Lab) отвечает за помощь в обеспечении безопасности технологии, используемой в федеральных информационных системах.

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

  • • Штаты США также имеют различные юрисдикционные приоритеты и процессы по безопасности и конфиденциальности информации о состоянии здоровья.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Созданная в 1987 г.. Health Level Seven (HL7) представляет собой некоммерческую организацию, занимающуюся разработкой стандартов и аккредитованную Американским национальным институтом стандартов (American National Standards Institute. ANSI). В ее задачи входит разработка стандартов обмена, интеграции, совместного использования и извлечения электронной медицинской информации: поддержка клиничесхой практики, а также поддержка управления, предоставления и оценки медицинской помощи. Аккредитация ANSI в сочетании с собственными процедурами HL7 предусматривает, что любой стандарт, опубликованный HL7 и представленный на утверждение ANSI, должен быть разработан и утвержден в результате осуществления процесса, который следует процедурам ANSI по достижению открытого консенсуса и отвечает требованиям баланса интересов за счет примерно равного участия в процессе голосования различных постоянных групп, испытывающих материальное воздействие стандарта (например, производители, поставщики медицинской помощи, государственные органы, консультанты, некоммерческие организации). Этот баланс интересов обеспечивает ситуацию, при которой конкретные группы никогда не отказываются от участия, но при этом не доминируют в разработке и утверждении предлагаемого стандарта. Дополнительную информацию и историю создания ANSI можно найти на веб-сайте //wwwANSI.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 (Национального института онкологии США) и друтие источники. Рабочая группа полу-мла большое количество информации от своих добровольных членов, имевших непосредственные знания о функциональности рыночных систем ведения ПЭМК. экспертные знания по защите конфиденциальности медицинской информации и неприкосновенности личной жизни, а также знания о функциональности систем ведения ЭМК.

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

Благодарности

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

Имя

Функция

Организация

Гари Дикинсон (Gary Dickinson)

Координатор Рабочей группы

CentrifyHeallh. Inc.

Майлс Хохштайн (Miles Hochstetn)

Координатор Рабочей группы

Omnimed ix

Джош Лемье (Josh Lemieux)

Координатор Рабочей группы

Omnimed ix

Донагъд Т.Мон (Donald Т. Mon. PhD)

Координатор Рабочей группы

Research Triangle Institute International

Джон Риттер (John Ritter)

Координатор Рабочей группы

Лоррены Тунис-Ду (Lorraine Tunis-Doo)

Координатор Рабочей группы

Centers for Medicare & Medicaid Servioes (CMS)

Ленел Джеймс (Lenel James)

Координатор; требования к соответствюо

Blue Cross Blue Shield Association

Линн Розенталь (Lynne Rosenthal)

Координатор: требования к соответствию

National Institute of Standards and Technology

Джемми Фергюсон (Jamie Ferguson)

Координатор: раздел персонального здоровья

Kaiser Permanents

Дональд Т.Мон (Donald Т. Mon, PhD)

Координатор: раздел персонального здоровья

Research Triangle Institute International

Ленел Джеймс (Lenel James)

Координатор: вспомогательный раздел

Blue Cross Blue Shield Association

Пэт Ван Дайк (Pat Van Dyke)

Координатор: вспомогательный раздел

The OOS Companies. Delta Dental Plans Association

Тим Маккей (Ten McKay)

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

Kaiser Permanents

Джон Риттер (John Ritter)

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

Ленел Джеймс (Lenel James)

Координатор: Рабочая группа по публикациям

Blue Cross Blue Shield Association

Сью Митчелл (Sue Mitchell)

Координатор: Рабочая группа по публикациям

Джон Риттер (John Ritter)

Координатор: Рабочая группа по публикациям

Пэт Ван Дайк (Pat Van Dyke)

Координатор; Рабочая группа по публикациям

The ODS Companies. Delta Dental Plans Association

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

  • [1] ISO 3166 (все части). Codes (or the representation of names of countries (Коды для представления названий стран)

  • [2] ISO 18306. Health informatics — Requirements for an electronic health record architecture (Информатизация здоровья. Требования к архитектуре электронной медицинской карты)

  • [3] ISO/HL7 10781, Electronic Health Record-System Functional Model. Release 1.1 (Функциональная модель электронной системы ведения электронных медицинских карт, выпуск 1.1)

  • [4] ISO 15143 1:2010. Earth-moving machinery and mobile road construction machinery — Worksite data exchange — Part 1: System architecture (Машины землеройные и мобильные дорожные. Обмен данными с рабочей площадки. Часть 1. Архитектура системы)

  • [5] ISO 22000:2005. Food safety management systems — Requirements for any organization in the food chain (Системы менеджмента безопасности пищевых продуктов. Требования ко всем организациям в цепи производства и потребления пищевых продуктов)

  • [6] ISO/1EC 20926:2009. Software and systems engineering — Software measurement — IFPUG functional size measurement method 2009 (Разработка программного обеспечения и систем. Измерения в программном обеспечении. Метод измерения функционального размера IFPUG 2009)

УДК 004:61:006.354 ОКС 35.240.80

Ключевые слова: здравоохранение, информатизация здоровья, электронная медицинская карта, система ведения персональных электронных медицинских карт

БЗ 10—2019/134

Редактор П.К. Одинцов Технический редактор В.Н. Прусакова Корректор Л.С. Лысенко Компьютерная верстка Л.А. Круговой

Сдано в набор 11.09.2019 Подписано о печать 23.09.2019. Формат 60,в41/в. Гарнитура Ариал. Усл. печ. л. 7.44 Уч.-им. л. 6,73.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Создано в единичном исполнении во . 117416 Москва. Нахимовский пр-т. д. 31. к. 2.

1

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

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

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

2

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

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

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

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