ГОСТ Р ИСО/HL7 10781-2019 Информатизация здоровья. Функциональная модель HL7 системы ведения электронных медицинских карт. Выпуск 2 (ФМ СВ ПЭМК).
ГОСТ Р ИСО/HL7 10781-2019
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ИНФОРМАТИЗАЦИЯ ЗДОРОВЬЯ
Функциональная модель HL7 системы ведения электронных медицинских карт
Выпуск 2 (ФМ СВ ПЭМК)
Health Informatics. HL7 electronic health records-system functional model. Release 2 (EHR FM)
ОКС 35.240.80
Дата введения 2020-05-01
Предисловие
1 ПОДГОТОВЛЕН Федеральным государственным унитарным предприятием "Российский научно-технический центр информации по стандартизации, метрологии и оценке соответствия" (ФГУП "СТАНДАРТИНФОРМ") на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 468 "Информатизация здоровья"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 29 августа 2019 г. N 577-ст
4 Настоящий стандарт идентичен международному стандарту ИСО/HL7 10781:2015* "Информатизация здоровья. Функциональная модель HL7 системы ведения электронных медицинских карт. Выпуск 2 (ФМ СВ ПЭМК)" (ISO/HL7 10781:2015 "Health Informatics - HL7 Electronic Health Records-System Functional Model, Release 2 (EHR FM)", IDT).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА
5 ВВЕДЕН ВПЕРВЫЕ
Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)
Предисловие к ИСО/HL7 10781
Международная организация по стандартизации, ИСО (the International Organization for Standardization) является международной организацией, которая была создана национальными организациями по стандартизации (члены ИСО). Работу по подготовке международных стандартов обычно выполняют технические комитеты ИСО. Любой член ИСО, заинтересованный в предмете, по которому создан технический комитет, имеет право на представительство в этом комитете. Международные организации, правительственные и неправительственные, совместно с ИСО, также принимают участие в работе организации. ИСО тесно сотрудничает с Международной электротехнической комиссией (МЭК) по всем вопросам стандартизации в электротехнике.
Международные стандарты составляются в соответствии с Директивами ИСО/МЭК, Часть 2.
Основной задачей технических комитетов является подготовка международных стандартов. Проекты международных стандартов принимаются техническими комитетами и передаются членам ИСО для проведения голосования. Для публикации в качестве международного стандарта необходимо одобрение не менее 75% членов ИСО, участвующих в голосовании.
Необходимо обратить внимание на то, что некоторые части настоящего документа могут являться объектами патентных прав. ИСО не обязана определять какие-либо или все части, являющиеся объектами патентных прав.
Настоящий стандарт подготовлен Техническим комитетом ИСО/ТК 215, Информатизация здоровья.
Настоящее второе издание аннулирует и заменяет первое издание (ИСО/HL7 10781:2009), которое было пересмотрено с технической точки зрения.
Введение
Информация для читателей
Функциональная модель системы ведения ЭМК, выпуск 2.0 основана на ряде предшествующих документов, начиная с версии первого согласованного проекта стандарта от 2004 г., за которым в 2007 г. последовал выпуск 1, а затем в 2009 г. Выпуск 1.1, поставленные на совместное голосование с ИСО/ТК 215 и СЕН/ТК 251. Выпуск 2.0 учитывает многочисленные изменения, включая комментарии и предложенные изменения, полученные при предыдущих голосованиях, которые Рабочая группа HL7 ЭМК обязалась учесть в будущем. Этот выпуск также включает комментарии, которые были даны в процессе голосования по проекту стандарта ИСО в 2009 г. для будущего рассмотрения, а также анализ голосования только по комментариям, проведенного в мае 2011 г.
Были сделаны другие изменения, учитывающие несколько функциональных профилей системы ведения ЭМК, включенных в выпуски функциональной модели 1 и 1.1. Был получен серьезный опыт в различных предметных областях, а также в профилях-компаньонах. В модель ФМ СВ ЭМК также были включены два других проекта стандарта для пробного использования: модель жизненного цикла HL7 EHR Lifecycle Model и модель интероперабельности HL7 EHR Interoperability Model.
Изменения по сравнению с предыдущими выпусками
Функциональная модель HL7 системы ЭМК, выпуск 2 была в первый раз поставлена на обязательное голосование в мае 2012 г. По результатам первого обязательного голосования были сделаны следующие основные изменения.
- Обязательные части глоссария перемещены в раздел "Требования к соответствию", поскольку согласованное использование глоссария является ключом к чтению и пониманию модели.
- Улучшена последовательность представления заголовков, функций и критериев соответствия в модели.
- С целью упрощения чтения обновлены требования к соответствию, особенно в той мере, насколько это относится к различным типам профилей: профилей предметных областей и профилей-компаньонов.
- Обеспечена ясность описаний функциональности и соответствующих критериев соответствия.
- Уточнено содержание, чтобы оно было более актуальным.
Комментарии и решения по их учету, принятые при обязательном голосовании 1, можно посмотреть в материалах цикла голосования в мае 2012 г. на веб-сайте HL7 Ballot Website.
История вопроса
Что такое системы ведения электронных медицинских карт?
Эффективное использование информационной технологии является ключевым аспектом улучшения медицинской помощи в терминах безопасности пациента, качества и экономической эффективности. В серии отчетов Института медицины США (US Institute of Medicine, IOM) идентифицирован кризис "системы" и даны рекомендации преобразования "системы" с помощью применения информационной технологии. Такое изменение возможно с помощью "инфраструктуры, обеспечивающей формирование полностью взаимосвязанной, универсальной, защищенной сети систем, способной предоставить информацию о медицинской помощи пациенту в любое время и в любом месте". (Задачи HHS в "Разработке функционального стандарта HL7 ЭМК" в меморандуме в адрес HIMSS от К.Клэнси и В.Рауба, сопредседателей Совета HHS по применению медицинских информационных технологий от 12 ноября 2003 г.) Критичным основополагающим компонентом для решения этих проблемных аспектов системы и инфраструктуры является система ведения электронных медицинских карт (СВ ЭМК).
Существующие определения системы ведения ЭМК
В отчете IOM от 1991 г. "The Computer-Based Patient Record: An Essential Technology" (Компьютеризованная запись пациента: основная технология), обновленном в 1997 г. (Dick, R.S, Steen, E.B., and Detmer, D.E. (Editors), National Academy Press: Washington, DC), дано следующее определение системы ведения ЭМК.
- Набор компонентов, формирующий механизм, по которому создаются, используются, хранятся и извлекаются записи пациентов.
- Системы записей пациента обычно находятся в организации поставщика медицинской помощи. Она охватывает людей, данные, правила и процедуры, устройства обработки и хранения (например, бумагу и карандаши, аппаратные средства и программные средства), а также средства связи и поддержки.
- В кратком отчете IOM "Letter Report, Key Capabilities of an Electronic Health Record System" от 2003 г., система ведения ЭМК определена следующим образом:
- Динамическая коллекция электронной медицинской информации о людях и для людей, в которой медицинская информация определена как информация, относящаяся к состоянию здоровья отдельного лица или медицинской помощи, предоставляемой отдельному лицу.
- Непосредственный электронный доступ к информации уровня отдельных лиц и информации уровня популяции, предоставляемый авторизованным, и только авторизованным, пользователям.
- Предоставление знаний и поддержки принятия решений, повышающих качество, безопасность и эффективность медицинской помощи пациенту.
- Поддержка эффективных процессов предоставления медицинской помощи.
В 2003 г. ИСО/ТС 18308 содержала ссылку на определение IOM от 1991 г., а также на ИСО 13606:
- Система для регистрации, извлечения информации электронных медицинских карт и манипулирования этой информацией.
Как определяются и разрабатываются функции?
Чтобы в самом начале достичь консенсуса заинтересованных участников здравоохранения, функции описываются на концептуальном уровне, обеспечивающем надежный фундамент для более детального описания. Функции были включены в модель, если считались важными, по крайней мере, в одних условиях оказания медицинской помощи. Написанный языком, ориентированным на пользователя, документ предназначен для широкого круга читателей.
Глубина детализации функции является термином, используемым для описания уровня общности, на котором функция представлена. Функции, которые обычно группируются на практике или в основных системах, были консолидированы, где это было уместно; функции, для представления которых требуется дополнительный или отдельный язык, или функции, вовлеченные в различные рабочие процессы, описаны отдельно, если это было необходимо. Например, поддержка решений эксплуатируется как отдельный раздел, но отображается на другие ключевые разделы для обозначения "умной" функции, стоящей за действием. Описания всех функций могли быть сделаны с более глубокой детализацией, однако был достигнут баланс между полезным документом и неупорядоченным списком функций. В данном случае задача определения подходящего уровня глубины детализации заключается в таком представлении функций, которые могут быть легко выбраны и использованы читателями этого стандарта, но которые не настолько общие, чтобы читателям пришлось создавать большое количество дополнительных функций в рамках каждой функции.
Хотя определение глубины детализации функции является довольно субъективной задачей, однако систематическая оценка каждой функции разными группами отраслевых специалистов привела к уровню детализации, подходящему для данной функциональной модели СВ ЭМК. Были предприняты все возможные усилия по обеспечению дополнительной информации в описаниях функций для иллюстрации более глубоких аспектов функций, которые могли бы консолидироваться для целей применимости.
В целях сохранения данной функциональной модели СВ ЭМК, не зависящей от стратегии реализации или технологии, описание функций не включает в себя специфичные технологии, но они могут использоваться в примерах, иллюстрирующих функции. Включение специфичных технологий в примеры не означает, что они тем самым получают одобрение или поддержку с точки зрения использования этих технологий в качестве стратегий реализации.
Проекты функциональной модели СВ ЭМК и специфичных функций были всесторонне проанализированы поставщиками медицинской помощи, изготовителями и другими участниками. Предлагаемый стандарт отражает мнения всех указанных аналитиков.
1 Область применения
Функциональная модель системы ведения ЭМК, разработанная организацией HL7, представляет собой справочный список функций, которые могут присутствовать в системе ведения электронных медицинских карт (СВ ЭМК). Список функций описан с точки зрения пользователя в целях обеспечения согласованного представления функциональности системы. Обеспечивая создание функциональных профилей для условий оказания медицинской помощи и сфер применения, настоящая функциональная модель СВ ЭМК позволяет получить стандартизованное описание и общее представление о функциях, которые желательны, или доступны, в указанных условиях оказания медицинской помощи (например, интенсивная терапия, кардиология, амбулаторная практика в одной стране или первичная медицинская помощь в другой).
Функциональная модель системы ведения ЭМК HL7 определяет стандартизованную модель функций, которые могут присутствовать в системах ведения ЭМК. С самого начала необходимо четко различать ЭМК как отдельную сущность и системы, оперирующие ЭМК, т.e. системы ведения ЭМК. В разделе 1.1.3 описаны базис и основа определения системы ведения ЭМК, предложенного организацией HL7. В частности, функциональная модель СВ ЭМК не рассматривает аспект, представляет ли собой СВ ЭМК систему, состоящую из других систем, либо это одиночная система, предоставляющая функции, необходимые пользователям. В настоящем стандарте не проводятся различия реализаций, и СВ ЭМК, описанная в функциональном профиле, может быть как одиночной системой, так и совокупностью систем. В обязательных разделах функциональной модели термин "система" используется в общем смысле для охвата всего множества вариантов реализации. К ним относится "ключевая" медицинская функциональность, обычно предоставляемая специфичными медицинскими приложениями, управляющими электронной медицинской информацией. К ним также относятся связанные общие возможности прикладного уровня, обычно обеспечиваемые промежуточным программным обеспечением или другими инфраструктурными компонентами. Последние включают в себя средства интероперабельности и интеграции, например, службы локации и средства, обеспечивающие поток работ, распределенный между приложениями. Интероперабельность рассматривается как с семантической точки зрения (четкая, последовательная и согласованная передача смысла), так и технической (формат, синтаксис и физическая связность). Далее, в описаниях функций не приведены никакие утверждения об используемой технологии или содержании электронной медицинской карты. Специфика разработки и реализации систем ЭМК не рассматривается входящей в область применения настоящей модели и не будет рассматриваться в будущем. В настоящей функциональной модели СВ ЭМК не рассматриваются и не одобряются реализации или технологии либо особенности содержания данных электронной медицинской карты.
Наконец, в настоящей функциональной модели СВ ЭМК учтены потребности научных работников, поскольку в ней предусмотрены возможности предоставления им данных с соблюдением требуемых протоколов обеспечения неприкосновенности личной жизни, конфиденциальности и безопасности. Разнородность потребностей исследований исключает специфичное перечисление функций, потенциально полезных для научной работы.
Данная функциональная модель не является:
- спецификацией сообщений;
- спецификацией реализации;
- спецификацией соответствия;
- спецификацией ЭМК;
- метрикой соответствия или тестирования соответствия;
- упражнением по созданию определения ЭМК или СВ ЭМК.
Функциональной модели СВ ЭМК недостаточно для описания системы ведения долгосрочной медицинской карты, тем не менее, она вносит свой вклад в его разработку. Обмен информацией, обеспечиваемый СВ ЭМК, поддерживает большое число клинических документов, эпикризов, минимальных наборов данных, приложений к счетам на оплату медицинской помощи, а в будущем позволит сформировать долгосрочную медицинскую карту.
Кроме того, следует помнить, что функциональная модель СВ ЭМК не содержит обсуждение клинических процессов или взаимодействия участников медицинской помощи. Основные принципы и процессы оказания медицинской помощи очерчены в международном стандарте ИСО 13940. Пользователи ФМ СВ ЭМК могут обратиться к ИСО 13940 для получения информации о клинических процессах, поддерживаемых системами ведения ЭМК.
Данная функциональная модель СВ ЭМК включает справочные и обязательные разделы.
Таблица 1 - Типы нормативного статуса
Статус | Описание |
Справочный | Содержание пакета функциональной модели СВ ЭМК, представляющее информацию, разъясняющую понятия, или иную дополнительную информацию, способствующую пониманию и осмыслению. Справочный материал не ставится на голосование, как часть стандарта. |
Обязательный | Содержание, являющееся частью функциональной модели СВ ЭМК, по которому члены комитета (а также заинтересованные отраслевые участники) HL7 официально проголосовали и проанализировали его в соответствии с процедурой HL7 по голосованию по обязательным документам. По этой функциональной модели, разработанной HL7, было успешно проведено голосование в качестве обязательного стандарта организации HL7 |
Каждый обязательный раздел в настоящем стандарте четко обозначен "обязательный". Например, в разделе 7 "Требования к соответствию" подразделы 7.2 и 7.4 обязательные.
Во внешнем приложении A "Список функций" к настоящей функциональной модели идентификатор функции, имя, объявление и компоненты критериев соответствия являются обязательными.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты. Для датированных ссылок применяют только указанные издания. Для недатированных ссылок применяют последние издания (включая любые изменения к стандартам).
ISO/TR 12773-1:2009, Business requirements for health summary records. Part 1: Requirements (Документация медико-санитарная. Организационно-коммерческие требования. Часть 1. Требования)
ISO/TS 13606-4:2009, Health informatics. Electronic health record communication. Part 4: Security (Информатизация здоровья. Передача электронной медицинской карты. Часть 4. Безопасность)
ISO/TS 17090-1:2002, Health informatics. Public key infrastructure. Part 1: Framework and overview (Информатизация здоровья. Инфраструктура с открытым ключом. Часть 1. Общие свойства и обзор)
ISO 18308:2011, Health informatics. Requirements for an electronic health record architecture (Информатизация здоровья. Требования к архитектуре электронной медицинской карты)
ISO/IEC 2382-8:1998, Information technology. Vocabulary. Part 8: Security (Информационные технологии. Словарь. Часть 8. Защита конфиденциальных данных)
ASTM E 1769:1995, Standard guide for properties of electronic health records and record systems (Стандартное руководство по свойствам электронных медицинских карт и систем электронных медицинских карт)
3 Термины и определения
В настоящем стандарте применены термины с соответствующими определениями:
3.1 контроль доступа (access control): Средства, обеспечивающие возможность доступа к ресурсам системы обработки данных только для авторизованных лиц авторизованным способом.
3.2 базовый функциональный профиль (base functional profile): Существующий функциональный профиль, на основе которого создаются и/или производятся новые функциональные профили.
3.3 соответствие (conformance): Выполнение продуктом, процессом или услугой заданных требований.
3.4 критерий соответствия (conformance criteria): Требования, описывающие поведение, действие, или способность, образующие реализацию функции.
3.5 требования к соответствию (conformance clause): Раздел спецификации, определяющий требования, критерии, или условия, которые необходимо выполнить, чтобы объявить соответствие.
3.6 объявление соответствия (conformance statement): Описание функции, реализованной в системе ведения ЭМК.
Примечание - Оно отражает степень, в которой система ведения ЭМК выполнила требования функционального профиля, и может включать дополнительные функции и информацию.
3.7 производный функциональный профиль (derived functional profile): Функциональный профиль предметной области, или профиль-компаньон, созданный на основе базового функционального профиля (например, профиль предметной области, дочерний для профиля предметной области детской больницы).
3.8 расширение (extension): Способность СВ ЭМК включать в себя дополнительную функциональность, кроме той, что определена в функциональном профиле.
3.9 функциональный профиль (functional profile): Подмножество функциональной модели, обозначающее функции (иногда в разной степени детализации) определенных систем ведения ЭМК, условий оказания медицинской помощи или более узких операционных требований.
3.10 справочный функциональный профиль (informative functional profile): Зарегистрированный функциональный профиль, который успешно завершил тщательное публичное обсуждение в процессе достижения консенсуса, принятого организацией HL7.
3.11 унаследованный критерий (inherited criterion): Критерий соответствия, перечисленный в родительской функции, который будет наследоваться всеми его дочерними функциями.
3.12 зарегистрированный функциональный профиль (registered functional profile): Функциональный профиль, успешно прошедший процесс регистрации и рассмотрения в Рабочей группе HL7 EHR.
3.13 ситуационный критерий (situational criterion): Критерий, который требуется в случае, когда имеют место определенные обстоятельства.
Пример - IF/Then (ЕСЛИ, то) или Dependent SHALL (условно ОБЯЗАТЕЛЬНЫЙ).
4 Общий обзор и определение функциональной модели (обязательный)
Функциональная модель СВ ЭМК включает в себя перечень функций, называемый "списком функций", подразделяемый на семь разделов: комплексный, оказание медицинской помощи, поддержка оказания медицинской помощи, поддержка здоровья населения, поддержка администрирования, инфраструктура записи и инфраструктура доверия.
В этих семи разделах функции группируются под функциями заголовков, каждая из которых имеет одну или несколько подфункций в иерархической структуре.
 |
Рисунок 1 - Разделы списка функций
4.1 Разделы списка функций
Семь разделов списка функций отражают содержание модели интероперабельности, которая в настоящее время встроена в функциональную модель, и входные данные от нескольких профилей, если используется выпуск R.1.1 функциональной модели. Ниже дается краткое описание каждого из семи разделов:
- Комплексный: в разделе "Комплексный" (Overarching) содержатся критерии соответствия, которые применимы ко всем системам ведения ЭМК и поэтому должны включаться во все профили, совместимые с ФМ СВ ЭМК.
- Оказание медицинской помощи: в разделе "Оказание медицинской помощи" (Care Provision) содержатся функции и поддерживающие критерии соответствия, необходимые при непосредственном предоставлении медицинской помощи конкретному пациенту и способствующие ее практическому оказанию. Функции носят общий характер, не ограничены конкретными условиями оказания медицинской помощи и могут использоваться как часть электронной медицинской карты, оказывающая поддержку врачебным кабинетам, клиникам, больницам и специальным медицинским центрам.
- Поддержка оказания медицинской помощи: в разделе "Поддержка оказания медицинской помощи" (Care Provision Support) основное внимание уделяется функциям, необходимым для обеспечения оказания медицинской помощи. Этот раздел организован соответственно разделу "Оказание медицинской помощи". Например, функция CP.4 ("Управление заказами") непосредственно поддерживается функцией CPS.4 ("Поддержка заказов").
- Поддержка здоровья населения: в разделе "Поддержка здоровья населения" (Population Health Support) основное внимание уделяется функциям, требуемым в ЭМК для поддержки профилактики и контроля заболеваний среди группы людей (в отличие от медицинской помощи отдельному пациенту). Этот раздел описывает функции, поддерживающие входные данные систем, проводящих медицинские исследования, содействующих здоровью населения и повышающих качество медицинской помощи на уровне групп пациентов.
- Поддержка администрирования: в разделе "Поддержка администрирования" (Administrative Support) основное внимание уделяется функциям СВ ЭМК, обеспечивающим управление клинической практикой и содействующим административным и финансовым операциям. Сюда относятся управление ресурсами и рабочим процессом, общение с пациентами и поставщиками медицинской помощи, а также управление административной информацией неклинического характера о пациентах и поставщиках.
- Инфраструктура записи: глава "Инфраструктура записи" (Record Infrastructure) состоит из функций, общих для управления записями системы ведения ЭМК, особенно основополагающих функций управления жизненным циклом записи (формирование, аттестация, внесение изменений, доступ/использование, перевод, передача/раскрытие, получение, деидентификация, архивирование...) и сроком жизни записи (постоянство, нестираемость, преемственность, аудит, шифрование). Функции раздела RI (инфраструктура записи) являются ключевыми и образующими для всех других функций модели (CP, CPS, POP, AS).
- Инфраструктура доверия: глава "Инфраструктура доверия" (Trust Infrastructure) состоит из функций, общих для инфраструктуры системы ведения ЭМК, особенно функций, основополагающих для операций системы, ее безопасности, эффективности и обеспечения целостности данных, мер защиты неприкосновенности личной жизни и конфиденциальности, а также интероперабельности с другими системами. Функции раздела TI (инфраструктура доверия) являются ключевыми и образующими для всех других функций модели (CP, CPS, POP, AS и RI).
4.2 Функциональные профили
Хотя функциональная модель должна содержать все обоснованно предполагаемые функции СВ ЭМК, она не предназначена быть списком всех функций, содержащихся в конкретной СВ ЭМК. Для ограничения списка функций предусмотренным применением должен использоваться функциональный профиль. В настоящем документе определена функциональная модель и описано общее использование профилей и приоритетов (см. 1.4 "Предполагаемое использование").
В целом функциональная модель предназначена для описания расширенного набора функций, из которого пользователь может сформировать подмножество. Созданное пользователем подмножество иллюстрирует, что нужно ему в СВ ЭМК. В любом конкретном профиле СВ ЭМК будет содержаться только подмножество расширенного набора функций.
 |
Рисунок 2 - Профилирование на основе ФМ СВ ЭМК
На рисунке 2 показано, что профиль будет включать все семь разделов функциональной модели, однако в него не обязательно включать все функции и критерии каждого раздела. Профиль может содержать дополнительные функции и критерии, удовлетворяющие требованиям профиля.
Требования к соответствию представляют собой высокоуровневое описание того, что требуется от профилей и реализаций. Его детали в свою очередь ссылаются на другие части стандарта. Требования к соответствию описывают понятия, исключительно важные для понимания и реализации функциональной модели, как например: "Что такое профиль? Что такое критерии соответствия? Как узнать, что является обязательным, а что необязательным?". Требования к соответствию могут также обеспечить взаимодействие между реализующими лицами (изготовителями) и пользователями (покупателями) в части того, что требуется, и наполнить смыслом фразы "профиль, который соответствует" и "система ведения ЭМК, которая соответствует". Кроме того, они служат основой для деятельности по тестированию и сертификации, которая может выполняться организациями, внешними по отношению к HL7.
Дополнительную информацию, относящуюся к правилам выбора и добавлению критериев соответствия при разработке функционального профиля, см. в разделе 7 "Критерии соответствия".
4.3 Компоненты списка функций СВ ЭМК
Список функций СВ ЭМК представляет собой расширенный перечень функций, разбитый на отдельные разделы. Функции описывают поведение системы языком, ориентированным на пользователя, чтобы они были опознаваемы основными участниками СВ ЭМК.
Функции СВ ЭМК могут использоваться для следующих целей:
- Способствовать описанию преимуществ конечного пользователя, например, безопасность пациента, качество и эффективность затрат в терминах стандартных функций СВ ЭМК.
- Содействовать общему пониманию функций ЭМК, позволяющему разработчикам, изготовителям, пользователям и другим заинтересованным сторонам планировать и оценивать функции СВ ЭМК.
- Обеспечить инфраструктуру, необходимую для подготовки требований и приложений стандартов следующего уровня, например, описывающих содержание ЭМК, а также кодирование, информационные модели, конструкции и интероперабельность в интересах переносимости информации между подсистемами СВ ЭМК и несколькими СВ ЭМК.
- Создать стандартизованный метод, с помощью которого каждая сфера применения (страна) может использовать эти функции ЭМК для разных условий оказания медицинской помощи, приложений и приоритетов.
- Информировать стороны, заинтересованные в поддержке последующего использования данных, первоначально собранных при оказании медицинской помощи (называемого также "вторичным использованием"), о том, какие функции можно ожидать в системе ведения ЭМК.
- Информировать стороны, заинтересованные в поддержке инфраструктуры медицинской информации, специфичной для сферы применения, о том, какие функции можно ожидать в системе ведения ЭМК.
В функциональной модели HL7 СВ ЭМК каждая функция идентифицирована и описана с помощью указанного ниже набора элементов или компонентов.
Таблица 2 - Пример списка функций
ИД | Тип | Имя | Заявление | Описание | Критерий соответствия |
CP1 | З | Управление клинической историей | Управление компонентами клинической истории пациента, используемыми для представления краткого обзора или подробной информации о здоровье пациента | Компоненты клинической истории пациента используются для представления кратких "моментальных снимков" важной информации о состоянии здоровья, включая анамнез пациента; аллергические и побочные реакции; историю лекарственных назначений; проблем пациента; сильные стороны; иммунизацию; медицинское оборудование/изделия; а также предпочтения пациента и семьи |
|
CP.1.4 | Ф | Управление списком проблем | Создание и поддержание списков проблем конкретного пациента | Список проблем может указывать в том числе хронические заболевания, диагнозы или симптомы, травмы/интоксикации (преднамеренные/ непреднамеренные), побочное действие лечения (например, лекарств, хирургических операций), функциональные ограничения, посещения или специфичные условия пребывания, диагнозы, или симптомы |
|
CP.1.4 | К |
|
|
| 1. Система ДОЛЖНА обеспечить возможность управлять всеми активными проблемами пациента как дискретными данными |
CP.1.4 | К |
|
|
| 2. Система ДОЛЖНА собирать и предоставлять историю всех проблем пациента |
CP.1.4 | К |
|
|
| 3. Система ДОЛЖНА обеспечить возможность управления соответствующими датами, включая дату начала и дату решения проблемы |
4.3.1 ИД функции (обязательный подраздел)
Это уникальный идентификатор функции из списка функций (например, CP.1.1), который следует использовать для уникальной идентификации функции при ссылке на нее. ИД функции также используется для идентификации раздела, в который включена функция (CP=раздел Care Provision ("Оказание медицинской помощи")), и иерархии или отношения между функциями (CP.1.1 находится на том же уровне, что CP.1.2, а CP.1.1 является родителем CP.1.1.1 и потомком CP.1; во многих случаях родитель полностью представлен потомками. Подробное обсуждение и графическое отображение отношения родитель - потомки см. в подразделе 6.6.1 "Иерархическая структура" раздела 6 "Требования к соответствию").
4.3.2 Тип функции (справочный подраздел)
Это обозначение строки как заголовка (H), функции (F) или критерия соответствия (C). Метка (T) используется для идентификации нового раздела таблицы и входящих в него функций. Непосредственно с меткой не связаны ни функции, ни критерии.
4.3.3 Имя функции (обязательный подраздел)
Это имя функции; предполагается, что оно уникально в списке функций, но не рекомендуется использовать его для идентификации функции без соответствующего ИД.
Пример - Управление листом лекарственных назначений.
4.3.4 Объявление функции (обязательный подраздел)
Это короткое объявление о назначении данной функции. Его не требуется представлять на структурированном языке, используемом в критериях соответствия (см. ниже). Объявление должно четко идентифицировать назначение и область применения функции.
Пример - Создать и эксплуатировать списки лекарств, специфичные для пациентов.
4.3.5 Описание (справочный подраздел)
Это более подробное описание функции, при необходимости, включающее примеры.
Пример - Листы лекарственных назначений ведутся в течение определенного времени, будь то обращение за амбулаторной помощью, пребывание в стационаре, жизнь пациента. В них хранятся все уместные даты, включая начало медикаментозного лечения, изменение, а также дату окончания лечения. Можно просматривать всю историю медикаментозного лечения по любому препарату, включая альтернативные добавки и лекарственные растения. Листы лекарственных назначений не ограничены рецептами, выписанными поставщиками медицинской помощи, и могут включать, например, сведения об отпуске/поставке из аптеки, лекарства, о приеме которых сообщают пациенты, а также дополнительную информацию, к примеру, специфичную для возраста дозировку.
4.3.6 Критерий соответствия (обязательный подраздел)
Для каждой функции, включенной в список, указаны один или несколько критериев соответствия. Эти критерии, записанные в настоящем стандарте на нормативном языке, описывают требования соответствия функции. Язык описания критерия соответствия хорошо структурирован с помощью стандартизованных компонентов, имеющих определенные значения. Структурированный язык, используемый для определения критериев соответствия в списке функций, определен в подразделах 2.4 "Критерии соответствия" и 2.9 "Иерархия и использование глоссария глаголов действия" раздела "Соответствие".
5 Предполагаемое использование (справочный раздел)
Организация HL7 является международным сообществом и поддерживает разработку функциональных профилей, которые могут быть специфичными для определенной страны спецификациями в рамках данного стандарта (сфера применения HL7). Предполагается, что организация HL7 зарегистрирует профили, обозначающие подмножества функций, описанных в модели, предназначенные для применения в специфичных условиях оказания медицинской помощи (например, поведенческое здоровье) или в определенных функциональных областях (например, управление записями и ЭМК, поддерживающая доказательную медицину). Примеры функциональных профилей будут включены в качестве справочных документов в Руководство по созданию функциональных профилей HL7 How-to Guide for Creating Functional Profiles.
5.1 Предполагаемый подход к разработке: функциональные профили
"Функциональный профиль" представляет собой набор избранных функций, применимых для определенной цели, пользователя, условий оказания медицинской помощи, предметной области и т.п. Функциональные профили помогают управлять основным списком функций. Полная функциональная модель не предназначена для применения в какой-либо конкретной реализации СВ ЭМК.
Как таковая, система ведения ЭМК соответствует не непосредственно функциональной модели, а скорее одному или нескольким функциональным профилям. Дополнительную информацию по созданию, регистрации и голосованию по функциональным профилям см. в разделах 2 и 6 главы 2 "Критерии соответствия".
Функциональные профили являются представлением применимых подмножеств функций, описанных в функциональной модели СВ ЭМК. В этой модели читатель увидит длинный список имен и объявлений функций, выступающих в роли обоснованных представлений функций, которые могут потребоваться в клинической среде. Этот список функций не предназначен для использования в своем полном варианте. Например, функции, обозначенные в этой модели, применяются по-разному в разных условиях оказания медицинской помощи. Многие функции, описанные в модели, применимы в условиях частных лечебниц, но некоторые, например, CP.1.7.2.3 (Управление заказами на продукты крови и другие биопрепараты), там применяться не будут. Список функций не считается применимым, пока не создан функциональный профиль, или ограничение.
Создание функционального профиля предназначено для поддержки бизнес-сценария использования СВ ЭМК с помощью выбора применимого подмножества функций из списка функций, определенных в функциональной модели СВ ЭМК, которые в действительности ограничивают модель в соответствии со специфичными требованиями. Например, функциональный профиль может быть создан покупателем для описания требований; изготовителем для описания возможностей специфичных продуктов; любым лицом/субъектом, которому требуется оговорить желательное подмножество функций для конкретной цели, включая условия оказания медицинской помощи в специфичной сфере применения. Когда применимое подмножество функций выбрано, лицо/субъект, создающий профиль, назначает каждой функции приоритет, а именно "essential now" (существенна сейчас), "essential future" (существенна в будущем) или "optional" (необязательная). Дополнительную информацию о шагах по созданию функционального профиля см. в Руководстве HL7 по созданию функциональных профилей и соответствующего инструментария (How-to Guide for Creating Functional Profiles and Related Tooling).
Читатели могут пожелать сосредоточиться на специфичном разделе функциональной модели СВ ЭМК, более подходящим для их повседневной деятельности. Например, клиницист может очень внимательно читать разделы "Оказание медицинской помощи" (Care Provision) и "Поддержка оказания медицинской помощи" (Care Provision Support), в то время как технические специалисты могут сконцентрировать внимание на разделе "Инфраструктура доверия" (Trust Infrastructure). В рамках организации может быть полезным делегировать ответственность за внимательное ознакомление с различными разделами разным сотрудникам с разными обязанностями и знаниями.
Ниже приведены три зарисовки, помогающие читателям, занимающим различные должности или работающим в разных организациях, представить, как они могли бы изучать и применять функциональную модель СВ ЭМК.
5.1.1 Сценарий 1 - групповая практика
Д-р Смит является участником групповой практики из 50 человек. Практика в настоящее время располагает клинической информационной системой, обеспечивающей выставление счетов, ведение расписаний и другую административную поддержку. В силу ряда причин ее нужно модифицировать или заменить в течение 2 лет. Электронные медицинские карты в ней отсутствуют. Д-р Смит и заинтересованные коллеги анализируют зарегистрированный профиль Ambulatory Care (амбулаторная помощь), чтобы посмотреть, как условия применения и сценарии иллюстрируют функции ЭМК, релевантные их практике. Они смотрят на приоритеты отдельных функций этого профиля, которые установила группа экспертов, работающая с организацией HL7. Получив хорошее понимание значений функций ЭМК для его практики, д-р Смит и несколько других поставщиков медицинской помощи переходят к разделам "Оказание медицинской помощи" (Care Provision) и "Поддержка оказания медицинской помощи" (Care Provision Support), в то время как административный персонал клиники знакомится с разделом "Административная поддержка" (Administrative Support), а персонал технической поддержки изучает раздел "Инфраструктура доверия" (Trust Infrastructure). Затем все они встречаются для обсуждения своих выводов. Они планируют использовать список функций в ходе обсуждений своей будущей информационной системы с изготовителями, понимая, что некоторые функции еще не будут доступны.
5.1.2 Сценарий 2 - больница
Г-н Джонс занимает должность директора по информационным технологиям в крупной больнице. Два года назад в ней была установлена информационная система, обеспечивающая учет движения пациентов и ввод заказов. Она была модифицирована в целях соответствия закону США HIPAA (Health Insurance Portability and Accountability Act - Закон об ответственности и переносе данных о страховании здоровья). Она не обеспечивает поддержку принятия клинических решений, мониторинг показателей или санитарно-эпидемиологическую отчетность. Г-н Джонс просит главного врача организовать анализ функциональной модели HL7 СВ ЭМК, при этом его персонал также изучает ее. Они оба начинают с профиля Acute Care (лечение острых заболеваний), поставленного на голосование, чтобы посмотреть, как группа экспертов, работающая с организацией HL7, идентифицировала возможное использование СВ ЭМК в больнице. В этом профиле весьма полезны сценарий и определение приоритетов отдельных функций. Главный врач, несколько врачей и старших медсестер анализируют разделы функциональной модели СВ ЭМК "Оказание медицинской помощи" (Care Provision) и "Поддержка оказания медицинской помощи" (Care Provision Support), представленные в профиле Acute Care; директора по информационным технологиям и его персонал концентрируют внимание на разделе "Инфраструктура доверия" (Trust Infrastructure), посвященном инфраструктуре треста, но просматривают и разделы "Оказание медицинской помощи" и "Поддержка оказания медицинской помощи". Небольшая группа поставщиков медицинской помощи и специалистов по информационным технологиям встречаются для обсуждения своих выводов. Они планируют использовать список функций в переговорах с изготовителями на предмет добавления в существующую систему функций поддержки принятия решений, мониторинга показателей и санитарно-эпидемиологической отчетности, признавая, что их бюджет позволит лишь незначительное расширение в ближайшее время.
5.1.3 Сценарий 3 - изготовитель информационных систем
Г-жа Грин возглавляет отдел клинических информационных систем крупной компании, занимающейся информатизацией здравоохранения. Их линия продуктов включает системы, специализирующиеся на ведении ЭМК, и интегрированные системы, обеспечивающие ведение ЭМК. Все эти системы обеспечивают некоторую поддержку принятия решений о лекарственных назначениях, но в них отсутствуют функции отчетности и мониторинга показателей. Хотя большинство их клиентов являются крупными медицинскими организациями и больницами, тем не менее компания планирует распространить свою деятельность на рынки небольших практик и медицинской помощи на дому, предложив простую и более дешевую клиническую информационную систему. В преддверии реализации закона о реформе организации Medicare, осуществляемой HHS (U.S. Department of Health & Human Services - Министерство здравоохранения и социального обеспечения США) и предполагающей финансовые стимулы для поставщиков медицинской помощи, использующих информационные технологии для учета движения пациентов, компания предполагает добавить в свои продукты ряд функций, которые выполняли бы или даже превышали требования системы Medicare. Г-жа Грин просит своих сотрудников проанализировать весь пакет функциональной модели HL7 СВ ЭМК, а также ознакомиться с примерами профилей для условий оказания медицинской помощи, включенных в качестве приложений в Руководство HL7 How-to Guide for Creating Functional Profiles and Related Tooling. На основе примеров функциональных профилей, предназначенных для различных условий оказания медицинской помощи, они смогли определить, что можно добавить к разным продуктам достаточно небольшое количество функций и превратить их в высококачественные продукты, которые можно предлагать нынешним и будущим клиентам. Они понимают ценность функциональной модели СВ ЭМК для переговоров со своими клиентами о модификациях или новых приобретениях.
5.2 Примеры текущего использования
5.2.1 Функциональный профиль для клинического исследования, основанный на ФМ СВ ЭМК
Ниже приведен текст пресс-релиза HL7 от ноября 2009 г., демонстрирующий отраслевое применение:
Энн Арбор, Мичиган, США - 5 ноября 2009 года - Health Level Seven® (HL7®), всемирный орган по интероперабельности и стандартам в области медицинской информационной технологии, объединяющий членов из 57 стран, сегодня объявил о публикации первого стандарта, утвержденного ANSI (American National Standards Institute - Американский национальный институт стандартов), описывающего функциональные требования к системам ведения электронных медицинских карт (СВ ЭМК), используемых при проведении регистрируемых клинических исследований. Функциональный профиль HL7 EHR Clinical Research основан на функциональной модели системы ведения ЭМК, выпуск 1, разработанной Рабочей группой к HL7 EHR и также утвержденной ANSI в качестве американского национального стандарта.
В функциональном профиле EHR Clinical Research описаны высокоуровневые требования, критичные для использования данных электронных медицинских карт при проведении регистрируемых клинических исследований, и представлена дорожная карта интеграции информационной среды, которая должна поддерживать как медицинскую помощь пациенту, так и нижележащие процессы клинических исследований. Согласно Дональду Мону, доктору наук (Donald Mon, PhD), сопредседателю Рабочей группы HL7 EHR и члену совета директоров HL7, "этот профиль является великолепной демонстрацией того, как важные функциональные требования к вторичному использованию данных, например, в клинических исследованиях, могут быть интегрированы в рабочий процесс оказания пациенту медицинской помощи и документироваться в системах ведения ЭМК". Поставщики технологий фармацевтических, биотехнологических, клинических исследований, поставщики технологий медицинской помощи, а также заинтересованные лица из федеральных уполномоченных органов США и Европейского союза сотрудничали в течение двух лет в целях идентификации и анализа широкого списка требований к защите данных, а также регуляторных и этических требований к исследованиям. Функциональный профиль EHR Clinical Research также является ресурсом для комиссии CCHIT (Certification Commission for Healthcare Information Technology - Сертификационная комиссия по медицинским информационным технологиям) Рабочей группы по клиническим исследованиям (Clinical Research Work Group), поскольку он определяет новые критерии сертификации клинических исследований для систем ведения ЭМК. Этот функциональный профиль будет дополнен спецификацией интероперабельности по клиническим исследованиям ЭМК, которая в настоящее время разрабатывается HITSP (Health Information Technology Standards Panel - Совет по стандартам медицинских информационных технологий). Кроме того, д-р Ребекка Куш, президент и генеральный директор CDISC (Clinical Data Interchange Standards Consortium - Консорциума по стандартизации обмена клиническими данными), заявила в своем комментарии, что "CDISC удовлетворен тем, что является компаньоном и вносит свой вклад в стандарты по клиническим исследованиям и понятиям обмена данными eSource навстречу этим инициативам. Конечная цель заключается в ускорении темпа, в котором исследования информируют сферу здравоохранения о преимуществах, получаемых пациентами, и этот функциональный профиль вносит свой вклад в достижение этой цели".
5.2.2 AHRQ объявляет о формате детских электронных медицинских карт
Ниже представлен отрывок из пресс-релиза от февраля 2013 года, демонстрирующего отраслевое применение функционального профиля HL7 Child Health: http://www.ahrq.gov/news/newsroom/press-releases/2013/childЭМКpr.html
Преимущества электронных медицинских карт (ЭМК) могут стать более доступными при лечении детей с помощью внедрения формата ЭМК для педиатрической медицинской помощи, объявленного сегодня AHRQ (US. Department of Health and Human Services’ Agency for Healthcare Research and Quality - Управление по исследованиям и качеству здравоохранения Министерства здравоохранения и социальных служб США) и CMS (Centres for Medicare and Medicaid Services - Центры служб Medicare и Medicaid)... Использование ЭМК продолжает улучшать качество и безопасность медицинского обслуживания в США, однако многие существующие системы ведения ЭМК не приспособлены для сбора или обработки информации о здоровье детей. Объявленный сегодня формат ЭМК для педиатрической медицинской помощи предлагает рекомендации по элементам данных, специфичным для детей, например, прививки, а также функциональность, которая позволит разработчикам ЭМК расширить их продукты и включить модули, адаптированные для детей AAP (American Academy of Pediatrics - Американская академия педиатрии) и American Academy of Family Physicians (Американская академия семейных врачей). Формат построен на основе спецификаций из источников, включающих в себя функциональную модель Health Level Seven International (HL7®) СВ ЭМК, функциональный профиль Child Health Рабочей группы HL7 Child Health, и инструментальное средство Health IT for Children Администрации по здравоохранению и услугам (Health Resources and Services Administration) Министерства здравоохранения и социальных служб США.
См. ссылку ниже для доступа к копии документа "Children’s EHR Format" http://healthit.ahrq.gov/childehrFormat.
5.2.3 Связывание описаний клинического содержания с ФМ СВ ЭМК (справочный подраздел)
Организация HL7 продолжает инициативные работы по связыванию описаний клинического содержания с функциями и критериями в ФМ СВ ЭМК. Эта связь может стать полезной входной информацией для разработчиков систем ведения ЭМК. Примерами таких описаний клинического содержания служат модели DAM (Domain Analysis Model - модель анализа предметной области) и модели DCM (Detailed Clinical Model - детальная клиническая модель). Каждый из этих примеров может быть связан с применимыми разделами ФМ СВ ЭМК. Например, модель DAM Care Plan (план ведения) может быть соединен с функциями планирования медицинской помощи в разделах "Оказание медицинской помощи" (Care Provision) и "Поддержка оказания медицинской помощи" (Care Provision Support) ФМ СВ ЭМК.
На более детальном уровне модели DCM могут быть связаны со специфичными функциями, описанными в ФМ СВ ЭМК или в функциональных профилях СВ ЭМК. Например, модель DCM для шкалы Апгар может быть связана с CP.3.1 "Провести оценку" и CPS 3.1 "Поддержать стандартные оценки". Другим примером является использование модели DCM артериального давления с CP.3.2 "Управлять клиническими измерениями пациента".
На уровне элементов данных, которые могут быть указаны в модели DCM или в таблице данных, связь с ФМ СВ ЭМК обычно осуществляется с помощью отдельного критерия, например, критерия "Система ДОЛЖНА обеспечить возможность сбора жизненно важных показателей здоровья, включая артериальное давление, температуру, пульс и частоту дыхания в качестве дискретных элементов структурированных или неструктурированных данных" в CP.3.2 "Управлять клиническими измерениями пациента".
В заключение, аналогично функции T4 "Стандартная терминология и терминологические службы", функция может быть создана для моделей DCM и служб моделей DCM. Работу этой функции можно было бы рассмотреть в следующей версии ФМ СВ ЭМК.
6 Требования к соответствию
6.1 Введение (справочный подраздел)
Ниже представлены Требования к соответствию, утвержденные Рабочей группой EHR. В качестве важной базовой информации по соответствию необходимо помнить следующее:
1. Настоящие требования к соответствию определяют, что означает "соответствовать функциональной модели СВ ЭМК".
2. Соответствие функциональной модели определяется для функциональных профилей предметной области, а также для функциональных профилей-компаньонов. Система ведения ЭМК соответствует не непосредственно функциональной модели, а скорее одному или нескольким функциональным профилям.
3. Критерии соответствия ассоциированы с функциями, описанными в функциональной модели СВ ЭМК.
4. Настоящие требования к соответствию не указывают процедуры тестирования или валидации для определения, соответствует ли СВ ЭМК функциональному профилю, либо соответствует ли функциональный профиль функциональной модели СВ ЭМК.
6.2 Область действия и сфера применения (обязательный подраздел)
Настоящие требования к соответствию определяют минимальные требования к функциональным профилям, для которых объявлено соответствие ФМ СВ ЭМК. Они также идентифицируют варианты, которыми системы ведения ЭМК достигают соответствия функциональной модели, что возможно через соответствие системы конкретному профилю функциональной предметной области, нескольким функциональным профилям или сочетанию профилей предметной области и профилей-компаньонов. Настоящие требования к соответствию указывают:
5. Назначение, структуру и использование критериев соответствия, которые должны быть включены в функциональную модель и функциональные профили, соответствующие функциональной модели.
6. Правила определения функциональных профилей, соответствующих функциональной модели.
7. Отношения между функциональными профилями и системами ведения ЭМК.
8. Примеры требований к соответствию и сценарии вариантов использования.
9. Рекомендации по требованиям соответствия, которые функциональный профиль может наложить на системы ведения ЭМК.
10. Рекомендации по назначению и использованию объявления соответствия системы ведения ЭМК.
Поскольку требования соответствия функциональных профилей могут быть найдены в данных требованиях к соответствию, то они обязательно дают ссылку на функциональную модель и другие источники.
Настоящие требования к соответствию не указывают процедуры тестирования или валидации для определения, соответствует ли функциональный профиль функциональной модели. Кроме того, они не указывают процедуры тестирования или валидации для определения, соответствует ли система ведения ЭМК функциональному профилю или совпадает с его объявлением соответствия.
6.3 Понятия (обязательный подраздел)
6.3.1 Функциональные профили
Создание функционального профиля представляет собой метод определения подмножеств функциональной модели. Функциональный профиль является спецификацией, использующей функциональную модель для указания, какие функции требуются, желательны или реализуются в определенных системах ведения ЭМК, условиях оказания медицинской помощи либо для других целей (например, профиль для управления записями и доказательной поддержки ЭМК).
Функциональные профили могут быть созданы участниками сообщества здравоохранения, заинтересованными в использовании и/или предоставлении функционального профиля для системы ведения ЭМК. Функциональные профили могут указывать функциональность, которая требуется и желательна для определенных условий оказания медицинской помощи или приложений, либо отражает функциональность, встроенную в систему ведения ЭМК изготовителя.
(Примечание - При создании профиля может быть важным обсуждение клинических процессов и/или взаимодействия участников медицинской помощи. В международном стандарте ИСО 13940 "System of concepts to support continuity of care" (Система понятий по обеспечению непрерывности ухода за больным) представлена схема ключевых принципов и процессов предоставления медицинской помощи. Крайне желательно проанализировать этот стандарт как часть вашей работы.)
После определения функциональный профиль может быть реализован системами ведения ЭМК или послужить основой для создания производных функциональных профилей. Производный функциональный профиль представляет собой функциональный профиль, который создан из существующего функционального профиля, наследуя функции базового (существующего) функционального профиля.
Имеются два типа функциональных профилей. Функциональный профиль предметной области является общим типом профиля, используемого для описания системы ведения ЭМК, ориентированного на использование в одних или нескольких условиях оказания медицинской помощи или на описание систем ведения ЭМК, предназначенных для использования в конкретной сфере в целях выполнения правил, норм и стандартов, применимых к этой сфере. Функциональные профили-компаньоны представляют собой тип профиля, который в обязательном порядке должен быть соединен с одним или несколькими профилями предметной области. Профиль-компаньон должен придать уникальные возможности системе ведения ПЭМК, например, в целях проведения исследований или поддержки доказательной медицины. Например, многим системам ведения ЭМК, используемым в клиниках, не требуется обеспечение поддержки клинических исследований. У клиники, проводящей передовые научные исследования, может существовать потребность в системе ведения ЭМК, имеющей все функции, необходимые при оказании обычной медицинской помощи, но в дополнение к ним обладающей уникальными возможностями для сбора дополнительных данных, требуемых для научных статей и клинических испытаний.
В ФМ СВ ПЭМК имеются два типа обязательного наследования. Все функциональные профили предметных областей наследуют все функции раздела "Комплексный" (Overarching) и связанные с ними критерии "ДОЛЖЕН". Все критерии, перечисленные в родительской функции, будут применимы ко всем потомкам этой родительской функции.
Существует официальный процесс регистрации и голосования по функциональным профилям. Функциональные профили, представленные в Рабочую группу HL7 EHR с аттестацией соответствия разделу 6 "Требования к соответствию" стандарта HL7 ФМ СВ ЭМК, в случае успешного рассмотрения в рабочей группе получают обозначение "Зарегистрированные функциональные профили". Зарегистрированные функциональные профили, которые проходят тщательное публичное обсуждение о придании им статуса справочных на уровне рабочей группы по процедуре достижения консенсуса, принятой организацией HL7, обозначаются как справочные функциональные профили предметной области или профили-компаньоны организации HL7. Затем справочные функциональные профили HL7 проходят процесс голосования полным составом комитета в соответствии с процедурой достижения консенсуса, принятой организацией HL7. Дополнительную справочную информацию о регистрации функциональных профилей или голосовании по ним см. в руководстве How To Guide for Profiles (в стадии разработки).
6.3.2 Модель соответствия
Соответствие функциональной модели определяется для функциональных профилей. Функциональный профиль предметной области соответствует либо (1) непосредственно функциональной модели, либо (2) другому функциональному профилю предметной области, имеющему соответствие. Примечание: Все функциональные профили предметных областей должны содержать все функции раздела "Комплексный" (Overarching) и связанные с ними критерии "ДОЛЖЕН". Система ведения ЭМК не соответствует функциональной модели непосредственно; вместо этого она соответствует функциональному профилю предметной области или сочетанию профиля предметной области и избранного профиля-компаньона. Таким образом, для функциональных профилей объявляется соответствие функциональной модели, а для систем ведения ПЭМК объявляется соответствие одному или нескольким соответствующим функциональным профилям предметных областей. Для системы ведения ПЭМК также может быть объявлено соответствие функциональному профилю предметной области в сочетании с одним или несколькими профилями-компаньонами. Для нее не может быть объявлено соответствие только профилю-компаньону. Эти соотношения показаны на рисунке 3.
6.3.3 Прослеживаемость профиля
Функциональные профили добавляют функциональной модели специфичность и расширяемость с помощью изменений, допускаемых для базовых функций ФМ и критериев. Правила таких изменений определены в разделе 6 настоящей главы. Требуется также прослеживать любые изменения и дополнения. Для этой цели в описание профиля добавлены две графы. В одной графе для каждого элемента нового профиля документируется уникальный номер строки источника, взятого из функциональной модели (или исходного профиля для производного профиля). Во второй графе приведены коды типа изменений по отношению к источнику, взятому из функциональной модели (или исходного профиля). Вместе обе эти графы прослеживания обеспечивают указание источников функций или критериев, а также того факта, были ли выполнены модификации (или нет) по сравнению с функциональной моделью или исходным профилем. Это может быть важным, когда возникают вопросы, например, откуда он появился, почему вы выбрали или модифицировали его, и т.п. Также полезно иметь обратную прослеживаемость к функциям и критериям функциональной модели, если необходимы пересмотры профиля или производного профиля, отражающие условия оказания медицинской помощи, нормативные и технологические изменения, или в связи с предстоящим переходом на новый выпуск функциональной модели.
 |
Рисунок 3 - Отношения соответствия
6.4 Нормативный язык (обязательный подраздел)
Следующие ключевые слова (т.е. нормативные глаголы) ДОЛЖНЫ использоваться при описании требований соответствия.
- ДОЛЖЕН (SHALL) - для обозначения обязательного требования, которое должно быть выполнено (реализовано), чтобы соответствовать. Синоним - "требуется".
- НЕ ДОЛЖЕН (SHALL NOT) - для обозначения запрещенного действия. Синоним - "запрещено".
- ПО ВОЗМОЖНОСТИ ДОЛЖЕН (SHOULD) - для обозначения необязательного рекомендуемого действия, которое пригодно, в частности, без упоминания и исключения других действий. Синоним - "разрешено и рекомендовано".
- МОЖЕТ (MAY) - для обозначения необязательного, допустимого действия. Синоним - "разрешено".
Функциональная модель СВ ЭМК (т.е. все главы) содержит обязательные, справочные и ссылочные разделы. В настоящей главе с требованиями соответствия обязательное содержание определяет, каким образом функциональный профиль достигает соответствия функциональной модели.
6.5 Критерии соответствия (обязательный подраздел)
Каждая функция в функциональной модели ассоциирована с рядом критериев соответствия. Эти критерии соответствия формируют основу для определения того, была ли реализована функция.
6.5.1 Критерии в функциональном профиле
Функциональные профили также имеют критерии соответствия, ассоциированные с каждой функцией функционального профиля. Критерии функционального профиля или (1) адаптированы из критериев функциональной модели, включающих в себя специфичную информацию об условиях оказания медицинской помощи или приложении, либо (2) при отсутствии критериев, специфичных для условий оказания медицинской помощи или приложения, наследуются непосредственно от функциональной модели. Функциональные профили предметных областей или профилей-компаньонов МОГУТ менять критерии функциональной модели, чтобы они соответствовали потребностям и приоритетам, для которых создан функциональный профиль, например, за счет придания им большей специфичности, либо меняя их обязательность с "может" или "по возможности должен" на "должен". Функциональные профили МОГУТ менять критерии функции, чтобы позволить их адаптацию к номенклатуре, специфичной для сферы применения, включая языковые различия и следствия переводов на языки, отличающиеся от английского. В этих случаях коды стран (ISO 3166 Country Codes) Международной организации по стандартизации (ИСО) ДОЛЖНЫ быть приложены к ИД функции в функциональном профиле.
Функциональный профиль НЕ ДОЛЖЕН быть менее ограничивающим, чем функциональная модель, за счет изменения обязательности критерия "должен" на "может" или "по возможности должен". Функциональные профили МОГУТ также добавлять дополнительные критерии.
6.5.2 Критерий "условно ОБЯЗАТЕЛЕН"
Критерии соответствия, которые содержат ключевое слово "должен" и зависят от ситуационных условий, называются "условно обязательными" критериями. Такие критерии ДОЛЖНЫ содержать фразу "в соответствии с областью практики, политикой организации или законодательством" или другие подходящие грамматически присоединенные слова (например, "на основе", а не "в соответствии"). "Условно обязательный" критерий используется для подчеркивания только этих условий (т.е. области практики, политики организации и/или законодательства). "Условно обязательный" критерий является обязательным для функциональных профилей и ситуационным для систем ведения ЭМК. А именно:
- Все функциональные профили предметных областей ДОЛЖНЫ наследовать критерий, если функция появляется в функциональном профиле.
- Система ведения ЭМК ДОЛЖНА реализовывать критерий, только если критерий применим в соответствии с зависимостью, объявленной в функциональной модели. (Если "условно обязательный" критерий не применим к профилю, то разработчик профиля тем не менее может использовать его по своему желанию.)
6.5.3 Ссылка на другие критерии или функции
Часто существует связь функций и их критериев с другими функциями и критериями. Например, конкретная функция может зависеть от другой функции, или от специфичного критерия, ассоциированного с другой функцией.
Критерий функционального профиля, который ссылается на другую функцию функционального профиля, ДОЛЖЕН ссылаться на эту функцию с помощью указания идентификатора ИД и имени своей функции в форме "X.n.n (имя)". Если ссылочная функция должна быть реализована, то применяются все критерии "должен" этой функции. Если ссылочная функция является родителем, то в ссылке должно быть явно указано, включены ли дочерние функции в ссылку, все или избранные. Ниже приведены примеры:
- Система ДОЛЖНА/ ПО ВОЗМОЖНОСТИ ДОЛЖНА/ МОЖЕТ соответствовать TI.1.1 (Авторизация субъекта).
- Система ДОЛЖНА/ПО ВОЗМОЖНОСТИ ДОЛЖНА/МОЖЕТ соответствовать TI.2 (Аудит) и всем дочерним функциям.
- Система ДОЛЖНА соответствовать CPS.4 "Поддержка заказов" и отдельной функции(ям). Системы ДОЛЖНЫ соответствовать CPS.4.3 "Нелекарственные назначения". Системы ДОЛЖНЫ соответствовать CPS.4.6 "Поддержка направлений к врачам" и всем дочерним функциям.
Критерий функционального профиля, который дает ссылку на специфичный критерий другой функции, ДОЛЖЕН указывать эту ссылку с помощью записи этого критерия в качестве собственного, при этом указывая функцию и номер критерия, откуда он появился (например, F#, CC3).
6.6 Структура и расширяемость функциональной модели (обязательный подраздел)
6.6.1 Иерархическая структура
Функции МОГУТ содержаться в других функциях (то есть быть вложенными в них). Вложенная функция является "дочерней" по отношению к ее "родителю" (т.е. функции, которая ее содержит). Дочерняя функция всегда ДОЛЖНА иметь родителя. Функция, не являющаяся родителем другой функции, считается "листовым узлом". Эта иерархическая структура иллюстрируется на рисунке 2.
Функциональная модель представлена как иерархический перечень функций, состоящий из функциональных заголовков и функций. Заголовки содержат идентификатор ИД, имя и "Н" в графе с заголовком "Тип". Родительские и дочерние заголовки МОГУТ содержать критерии соответствия только в том случае, если критерии применяются ко всем функциям-потомкам (детям, внукам и т.п.). Описания родительских, дочерних и листовых функций содержат, как минимум, следующие поля: ИД, имя, объявление, описание и критерии соответствия, и имеют обозначение "F" в графе "Тип". Критерии соответствия, перечисленные в родительской функции, ДОЛЖНЫ наследоваться всеми ее дочерними функциями. Критерии соответствия имеют обозначение "С" в графе "Тип".
 |
Рисунок 4 - Часть иерархической структуры функциональной модели
Примечание - Указанная выше схема нумерации отражает функции раздела "Оказание медицинской помощи". Например, CP4.2 является функцией "Управление назначениями лекарств".
Функциональные профили либо:
- выбирают функции из функциональной модели для включения в функциональный профиль,
- считают функцию из функциональной модели неприменимой, тем самым не выбирают ее для включения в функциональный профиль,
- добавляют новую дочернюю функцию, когда определено, что отсутствует применимая функция в функциональной модели, удовлетворяющая функциональные потребности функционального профиля.
6.6.2 Соглашение об именовании
Функциональные профили НЕ ДОЛЖНЫ менять имя или объявление функции, за исключением случаев адаптации к специфичной номенклатуре сферы применения, включая языковые различия и следствия переводов на языки, отличающиеся от английского. В этих случаях код страны [ИСО 3166 Коды стран)] Международной организации по стандартизации (ИСО) ДОЛЖЕН быть добавлен к ИД функции в функциональном профиле. Рекомендуется, чтобы национальный филиал HL7 конкретной страны координировал процесс разработки профиля в части отображения имени функции и/или ее объявления, приведенного в функциональной модели, на имя и/или объявление, адаптированное для конкретной страны.
6.6.3 Приоритеты
Функциональные профили показывают важность и/или безотлагательность функционального профиля, ассоциируя с функцией приоритет. Были определены три приоритета, а именно: существенна сейчас (Essential Now), существенна в будущем (Essential Future), и необязательная (Optional).
- Essential Now указывает, что реализация функции обязательна с даты выпуска профиля.
- Essential Future указывает, что в настоящее время реализация функции не обязательна, но будет обязательна в какой-то будущий момент, указанный в функциональном профиле.
- Optional указывает, что реализация функции не является обязательной.
Любые них или все приоритеты ДОЛЖНЫ использоваться в функциональном профиле. Если используется приоритет Essential Future, то требуется, чтобы в функциональном профиле были указаны рамки времени реализации функций. Такими рамками МОГУТ быть даты, ограничения времени (например, 2014 г., или четыре месяца после публикации функционального профиля) или событие (например, повторная публикация настоящего функционального профиля). Функциональный профиль МОЖЕТ определять несколько рамок времени для приоритета Essential Future. Если определено несколько рамок времени, то они ДОЛЖНЫ использоваться для квалификации каждого экземпляра приоритета Essential Future (например, EF-2015, EF-2016).
6.6.4 Расширяемость
Чтобы адаптироваться к изменениям технологии и потребностей функциональных профилей, в функциональной модели предусмотрена расширяемость функций и относящихся к ним критериев. Включение в функциональный профиль дополнительных функций помимо тех, что определены в функциональной модели, осуществляется в соответствии с набором правил добавления новых функций, определенных в 6.7.2 "Правила создания новых функций в функциональных профилях".
Включение дополнительного критерия, изменение последовательности критерия и предоставление большей детализации, специфичной для конкретного профиля, сверх того, что определено в функциональной модели, осуществляется в соответствии с набором правил по добавлению нового критерия или изменения существующего критерия, определенных в 6.7.2 "Правила создания новых функций в функциональных профилях".
6.7 Соответствие функционального профиля (обязательный подраздел)
Объявление соответствия функционального профиля функциональной модели ДОЛЖНО отвечать всем требованиям, указанным в 6.7.1 "Правила для функциональных профилей предметной области", или 6.7.5 "Правила для функциональных профилей-компаньонов".
6.7.1 Правила для функциональных профилей предметной области
Функциональные профили предметной области, при разработке которых соблюдаются правила для функциональных профилей, ДОЛЖНЫ объявлять соответствие той версии функциональной модели СВ ПЭМК, из которой они произведены.
Функциональные профили, объявляющие соответствие функциональной модели, ДОЛЖНЫ:
1. Идентифицировать функциональную модель с версией/датой, из которой произведен функциональный профиль.
2. Включать описание, версию и дату издания функционального профиля.
3. Содержать описание соответствия, которое:
a) определяет требования, которым в обязательном порядке должны удовлетворять системы ведения ЭМК, объявляющие соответствие функциональному профилю;
b) определяет требования, которым в обязательном порядке должны соответствовать функциональные профили, произведенные из функционального профиля (т.e. производные функциональные профили) и объявляющие соответствие функциональному профилю;
c) указывает, что функции, имеющие приоритет "Essential Now", ДОЛЖНЫ быть реализованы системами ведения ЭМК, соответствующими профилю;
d) указывает, что функции, имеющие приоритет "Essential Now", ДОЛЖНЫ быть включены в любые производные функциональные профили;
e) если используется приоритет "Essential Future", то должен быть описан смысл этого приоритета, включая указание рамок времени, в которых требуется реализация этих функций;
f) требует, чтобы по меньшей мере одна функция, независимо от ее приоритета, была реализована, чтобы для системы ведения ЭМК можно было объявить соответствие профилю.
4. Включить в себя все функции раздела "Комплексный" (Overarching) с приоритетом "Essential Now" и идентифицировать функции из других разделов функциональной модели, применимые к функциональному профилю предметной области. Для каждой идентифицированной функции указать ее приоритет (т.e. "Essential Now", "Essential Future" или "Optional").
5. Для каждой функции произвести критерии соответствия из критериев соответствия функциональной модели.
a) В функциональном профиле ДОЛЖЕН быть по меньшей мере один обязательный критерий для каждой функции (критерий "должен").
b) Если для функции имеются критерии "должен" (в функциональной модели), то эти критерии ДОЛЖНЫ также присутствовать для этой функции (в функциональном профиле). Кроме того, если функция расщеплена (в функциональном профиле), то родительский критерий "должен" ДОЛЖЕН присутствовать хотя бы у одного потомка этой функции.
c) Если для функции все еще нет критерия "должен" (в функциональной модели), то по меньшей мере один критерий, "по возможности должен" или "может", ДОЛЖЕН быть сделан обязательным, т.e. критерием "должен".
d) Критерий должен следовать правилам ссылок на функции или критерии, описанным в подразделе 6.5.3 "Ссылка на другие критерии или функции".
6. Для любой функции из функциональной модели, где один или несколько критериев относятся к типу "условно обязателен", функциональный профиль ДОЛЖЕН:
a) воспроизвести дословно каждый критерий "условно обязателен" вне зависимости от того, применима ли зависимая ситуация или нет;
b) если применима зависимая ситуация, то создать критерий "должен", применяющий зависимость к критерию "условно обязателен", в результате чего создаются одна или несколько новых, ограниченных версий критерия "условно обязателен";
c) объявлять специфичную область практики, политики организации и/или законодательства, которая применяется, либо объявить, почему эти зависимости не применяются.
7. Следовать правилам создания новых функций в функциональных профилях, описанным в подразделе 6.7.2 "Правила создания новых функций в функциональных профилях".
8. Следовать правилам создания и изменения критериев соответствия, описанным в подразделе 6.5 "Критерии соответствия".
9. Заполнить две графы прослеживаемости (см. 6.3.3 "Прослеживаемость профиля") на предмет каких-либо изменений функций или критериев и использовать следующие коды изменений: N/C - без изменений, A - добавлен, M - модифицирован.
10. Быть структурированным в соответствии с требованиями к структурированию, определенными для функциональной модели в 6.6.1 "Иерархическая структура".
11. Использовать глоссарий глаголов действия для модификации или создания новых критериев соответствия.
Объявление соответствия функциональных профилей предметной области функциональной модели МОЖЕТ:
1. Создать дополнительные функции в соответствии с правилами, указанными в 6.7.2 "Правила создания новых функций в функциональных профилях".
2. Содержать критерии соответствия, более специфичные и ограниченные по области применения, нежели критерии функциональной модели.
3. Заменить текст "основан на стандарте(ах)" (standard(s)-based), содержащийся в некоторых критериях, специфичными стандартами и/или спецификациями, поименованными на наиболее дискретном уровне обозначения.
4. Заменить критерий "по возможности должен" на "должен" или "может".
5. Заменить критерий "может" на "должен" или "по возможности должен".
6. Игнорировать критерий "по возможности должен" или "может", присутствующий в функциональной модели (т.е. не включать его в функциональный профиль).
7. Добавить дополнительный критерий соответствия сверх тех, что имеются в функциональной модели.
8. Сделать порядок критериев соответствия значащим (например, поместить все критерии "должен" в начало).
9. Обеспечить общее разрешение неоднозначной семантики функциональной модели.
10. Сделать функциональные профили общедоступными (например, опубликовать на вебсайте), чтобы заинтересованные стороны могли его видеть/использовать.
11. Предоставить функциональный профиль рабочей группе HL7 EHR для анализа до его регистрации.
Объявление соответствия функциональных профилей предметной области функциональной модели НЕ ДОЛЖНО:
1. Указывать любые требования, противоречащие или вызывающие несоответствие с ФМ СВ ПЭМК.
2. Модифицировать имя или объявление любой функции из функциональной модели, кроме как для адаптации с номенклатурой, специфичной для сферы, как это указано в 6.6.2 "Соглашение об именовании".
3. Изменять для любой функции из функциональной модели обязательные критерии соответствия на необязательные (т.е. заменять "должен" на "по возможности должен" или "может").
4. Модифицировать любые требования функции, не выбранной для функционального профиля (т.е. все функции, не отобранные по умолчанию в критериях функциональной модели. Если профилирующая группа хочет что-то изменить, то она ДОЛЖНА осуществить это в своем функциональном профиле).
6.7.2 Правила создания новых функций в функциональных профилях
Если функция не адекватно специфична для функционального профиля или не существует, то функциональный профиль лишь ДОЛЖЕН создавать нового потомка. На рисунке 5 иллюстрируется добавление новой дочерней функции.
 |
Рисунок 5 - Создание новой функции
Следующие правила описывают метод создания новых функций.
1. ПО ВОЗМОЖНОСТИ ДОЛЖНЫ использоваться критерии соответствия, чтобы избежать создания новой функции. Это может быть сделано, например, в случаях, если исходные критерии соответствия функции слишком широки, а именно, разделить в функциональном профиле унаследованные критерии соответствия ФМ СВ ЭМК или базового функционального профиля на два критерия, один из которых является обязательным, а другой необязательным.
2. Если "листовая" функция существует (потомок, не являющийся родителем), но она слишком широко описана в функциональной модели или базовом функциональном профиле, чтобы критерий соответствия мог адекватно ограничить ее, то функция МОЖЕТ быть расщеплена следующим образом:
3. Исходная "листовая" функция оставляется в качестве родительской по отношению к вновь созданным дочерним функциям.
4. Критерии соответствия "должен" этой функции ДОЛЖНЫ быть распределены среди его дочерних функций.
5. Если функции - кандидата на отражение требований функционального профиля не существует, то МОЖЕТ быть создана новая дочерняя функция (например, с помощью добавления нового вида сводного списка под сводным списком родителя).
6. Родительские функции НЕ ДОЛЖНЫ расщепляться. Это сохраняет структуру исходной функциональной модели в функциональных профилях.
 |
Рисунок 6 - Расщепление функции
Если в функциональном профиле (поставленном на голосование или зарегистрированном) создаются новые дочерние функции, то эти новые функции будут выделены Рабочей группой HL7 EHR и отслежены с целью анализа. Рабочая группа HL7 EHR БУДЕТ использовать эти новые функции и соответствующие критерии в качестве входных данных и кандидатов на изменения функциональной модели (например, добавление, ослабление критериев соответствия). Рабочая группа HL7 EHR МОЖЕТ поддерживать файл рассмотренных функций и критериев, которые было решено не включать в будущую версию функциональной модели.
 |
Рисунок 7 - Добавление новой дочерней функции
Функция IN 4.4 добавлена в качестве новой дочерней функции, находящейся на одном уровне родства с IN 4.1, IN 4.2 и IN 4.3.
6.7.3 Правила для производных функциональных профилей
Производные функциональные профили, объявляющие соответствие одному или нескольким базовым функциональным профилям, ДОЛЖНЫ:
1. Следовать всем правилам для функциональных профилей, описанным в 6.7.1 "Правила для функциональных профилей предметной области".
2. Следовать всем правилам создания новых функций, описанным в 6.7.2 "Правила создания новых функций в функциональных профилях", если это не запрещено базовым функциональным профилем.
3. Идентифицировать базовые функциональные профили, из которых произведен данный профиль.
4. Для каждой функции, унаследованной от базового функционального профиля, сохранить обязательные критерии соответствия и не менять их на необязательные.
6.7.4 Объявление соответствия
В функциональных профилях МОЖЕТ требоваться, чтобы для систем, объявляющих соответствие профилю, было выпущено объявление соответствия. В объявлении соответствия предоставляется информация о системе ведения ЭМК в форме единообразного представления функций, реализованных в этой системе. Бланк объявления о соответствии (подлежащий заполнению), как правило, похож на вопросник или контрольный перечень, заполняемый для каждой системы ведения ЭМК.
Объявление соответствия представляет собой краткое изложение содержания функционального профиля. Оно имеет стандартный формат и тем самым предоставляет изготовителям и пользователям системы ведения ЭМК возможность быстрого просмотра функций функционального профиля. Более того, оно также может использоваться для выделения дополнительных функций и возможностей, поддерживаемых системами ведения ЭМК, а также для документирования любых расширений (т.е. дополнительной функциональности сверх той, что описана в функциональном профиле) или выполненных специализаций. Объявление соответствия системы ведения ЭМК предоставляет информацию, которая может быть использована при оценке соответствия этой системы конкретному функциональному профилю. Кроме того, организации, желающие приобрести систему ведения ЭМК, МОГУТ создать объявление соответствия для указания функций, требуемых и/или желательных в системе ведения ЭМК.
Функциональные профили МОГУТ включить в себя бланк объявления соответствия, наличие которого содействует согласованности заполненных объявлений соответствия. Объявления соответствия могут быть полезны для оценки шансов интероперабельности двух систем ведения ЭМК с помощью сравнения функций, поддерживаемых каждой системой. Кроме того, объявление соответствия может использоваться для целей тестирования соответствия, упрощая выбор тестов, применимых к конкретной тестируемой системе ведения ЭМК. Например, если в системе ведения ЭМК не реализованы функции с обозначением "Essential Future", это будет очевидно вытекать из объявления соответствия и тестирование этих функций (которые не реализованы) не будет выполняться.
6.7.5 Правила для функциональных профилей-компаньонов
Функциональные профили-компаньоны, следующие Правилам для функциональных профилей, ДОЛЖНЫ объявлять соответствие той версии функциональной модели СВ ЭМК, из которой они были произведены. Функциональные профили-компаньоны будут следовать положениям подразделов 6.7.1 "Правила для функциональных профилей предметной области" и 6.7.3 "Правила для производных функциональных профилей", за исключением изъятий и дополнений, описанных ниже.
Функциональный профиль-компаньон, объявляющий соответствие функциональной модели, ДОЛЖЕН:
1. При добавлении новых функций следовать положениям подраздела 6.7.2 "Правила создания новых функций в функциональных профилях".
2. Содержать описание соответствия, которое:
a) определяет по меньшей мере один функциональный профиль предметной области, с которым может быть связан профиль-компаньон и которому системы ведения ЭМК обязательно должны удовлетворять, чтобы объявить соответствие, или указать любые специфичные профили предметной области, которые могут/не могут быть связаны с профилем-компаньоном,
b) определяет требования, которым должны удовлетворять профили-компаньоны, произведенные из базового функционального профиля-компаньона (т.е. производные функциональные профили), чтобы объявлять соответствие функциональному профилю-компаньону.
3. Включать только модифицируемые функции из раздела списка функций "Комплексный" (Overarching) с приоритетом Essential Now и идентифицировать функции из других разделов списка функций функциональной модели, применимые к функциональному профилю-компаньону. Для каждой идентифицированной функции следует указать ее приоритет (т.e. Essential Now, Essential Future или Optional).
4. Для каждой функции произвести критерии соответствия, основанные на критериях соответствия, описанных в функциональной модели.
a) В функциональном профиле ДОЛЖЕН быть по меньшей мере один обязательный критерий для каждой функции (критерий "должен").
b) Если критерии "должен" (для функции в функциональной модели) имеются, то эти критерии МОГУТ также иметься для функции (в функциональном профиле-компаньоне), если она меняется. Кроме того, если функция расщеплена (в функциональном профиле), то родительский критерий "должен" МОЖЕТ возникнуть по меньшей мере в одном потомке этой функции.
5. Для любой функции в функциональной модели, у которой один или несколько критериев являются "условно обязательными", функциональный профиль-компаньон может выбрать игнорирование критерия, однако если он выбран для этой функции, то ДОЛЖЕН выполнять требования подраздела 6.7.1 "Правила для функциональных профилей предметной области".
Функциональные профили-компаньоны, объявляющие соответствие функциональной модели, МОГУТ:
6. Игнорировать критерии "должен", "по возможности должен" или "может", указанные в функциональной модели (т.e. не включать их в функциональный профиль).
Для функциональных производных профилей-компаньонов отсутствуют исключения из положений подраздела 6.7.5 "Правила для производных функциональных профилей".
6.8 Варианты использования и примеры (справочный подраздел)
6.8.1 Варианты использования функциональных профилей
Условия оказания медицинской помощи
Установлено, что для отражения специфичных требований, предъявляемых в определенных условиях оказания медицинской помощи, требуется новый функциональный профиль предметной области условий оказания медицинской помощи. Чтобы помочь обеспечить широкое использование и единообразие, авторы функционального профиля выбирают прохождение анализа перед регистрацией, за которым последует процесс достижения консенсуса, принятый организацией HL7 (т.е. подача зарегистрированного функционального профиля для голосования в качестве "справочного" на уровне комитета). При положительном исходе этот результат будет обозначаться как справочный функциональный профиль HL7.
После просмотра текущего перечня справочных функциональных профилей HL7 принимается решение создать новый функциональный профиль. Каждая функция из функциональной модели СВ ЭМК исследуется, и выбираются те, которые соответствуют выбранным условиям оказания медицинской помощи. Из этих функций выбирается небольшой набор ключевых (core) функций в качестве существенных и обязательных. Для каждой функции разрабатывают критерии соответствия, либо адаптируя критерии соответствия, содержащиеся в функциональной модели, либо в некоторых случаях используя такие критерии без изменения. В заключение составляется описание функционального профиля, включающее его назначение и аудиторию, а также описание соответствия. Функциональный профиль делается общедоступным с помощью публикации на разных веб-сайтах. Кроме того, функциональный профиль представляется в Рабочую группу HL7 EHR для анализа перед регистрацией, комментирования и голосования.
Производный функциональный профиль предметной области и профиль-компаньон заинтересованного сообщества
Заинтересованному сообществу (например, региональной сети обмена медицинской информацией) может понадобиться функциональный профиль предметной области, отражающий их специфичные потребности, а также потребности одного из их членов для поддержки научных клинических исследований.
Заинтересованное сообщество не хочет создавать новый функциональный профиль с нуля. При просмотре списка зарегистрированных функциональных профилей они находят существующий функциональный профиль, который очень близок к тому, что они хотят. Используя данный функциональный профиль в качестве основы, они принимают все функции с приоритетом "Essential Now", отказываются от функций с приоритетом "Essential Future" и добавляют еще несколько функций. Для каждой функции они анализируют критерии соответствия и адаптируют их, чтобы они отражали их ситуационную информацию.
Для одного члена сообщества, которому необходима поддержка научных исследований, создается функциональный профиль-компаньон. Функциональный профиль требуется лишь для анализа узких областей деятельности, специфичных для научного исследования. Поэтому группа находит существующий профиль-компаньон для научных клинических исследований и модифицирует его, чтобы он отражал функции, необходимые для научных исследований члена их сообщества, посвященных последствиям специфичного заболевания. Теперь справочное сообщество может искать изготовителя, способного удовлетворить потребности профиля предметной области для группы и профиля-компаньона для одного члена сообщества.
Функциональный профиль предметной области изготовителя и комплексное соответствие
Изготовитель системы ведения ЭМК хочет заявить соответствие функциональной модели СВ ЭМК.
Изготовитель идентифицирует и перечисляет все функции своего продукта. Изготовитель добавляет описание системы и описания соответствия (см. образцы в 7.2 "Введение"). Это функциональный профиль предметной области изготовителя. Если изготовитель действительно реализовал все перечисленные функции, то это эквивалентно приоритету "Essential Now", и эти функции являются обязательными. В заключение изготовитель добавляет критерии соответствия для каждой функции, наследующей некоторые из них (без изменения) непосредственно из функциональной модели. Но он также может добавить новые критерии, отражающие добавленные возможности системы. Если все непосредственные потомки функции имеют один и тот же новый критерий, то его можно переместить на уровень родительской функции как комплексный и применить ко всем непосредственным потомкам. Тем самым изготовитель имеет возможность перечислить текущую функциональность и при желании указать планы на будущее. В сущности, это аналогично объявлению о соответствии изготовителя (концепция, с которой большинство изготовителей уже знакомы). Изготовитель может создать несколько функциональных профилей.
6.8.2 Образцы требований к соответствию функциональному профилю предметной области
Для помощи разработчикам функциональных профилей в составлении требований к соответствию для их функционального профиля согласно правилу N 3, указанному в 6.1 "Введение", предлагаются следующие фиктивные примеры. Обратите внимание, что в этих примерах ключевые слова ДОЛЖЕН, ПО ВОЗМОЖНОСТИ ДОЛЖЕН или МОЖЕТ пишутся прописными буквами и жирным шрифтом. Это соглашение по привлечению внимания к ключевым словам.
Требования к соответствию функциональному профилю предметной области условий оказания медицинской помощи
Настоящий функциональный профиль предметной области определяет требования соответствия для систем ведения ЭМК и производных функциональных профилей. Для соответствия этому функциональному профилю ДОЛЖНЫ быть реализованы все функции с приоритетом "Essential Now". Такие функции считаются обязательными. Система ведения ЭМК соответствует профилю, если в ней реализованы все функции с приоритетом "Essential Now", а также обязательные критерии соответствия, ассоциированные с этими функциями. Производный функциональный профиль соответствует, если он следует Правилам для функциональных профилей.
Обязательные критерии соответствия обозначены ключевым словом "должен". Дополнительные критерии соответствия обозначаются ключевыми словами "по возможности должен" или "может".
Системы ведения ЭМК ДОЛЖНЫ предоставлять объявление соответствия, которое структурировано в соответствии с правилами и политиками, определенными в этом функциональном профиле.
Требования к соответствию приложению
E-Application представляет собой приложение, которое при включении в систему, специфичную для конкретных условий оказания медицинской помощи, ДОЛЖНО соответствовать данному функциональному профилю. E-Application - это приложение, у которого имеется определенный набор атрибутов с минимальным набором функций, который требуется для любой системы, объявляющей реализацию приложения e-Application. Назначены два уровня соответствия:
Система МОЖЕТ объявить соответствие на базовом или расширенном уровне, если в ней реализованы все обязательные критерии для функций, принадлежащих уровню соответствия, на котором сделано объявление.
Функции с приоритетом "Essential Now" означают основную функциональность. Эти функции должны быть реализованы, чтобы объявить соответствие приложению E-Application вне зависимости от уровня соответствия (т.e. базовое или расширенное), на котором сделано заявление.
Функции с приоритетом "Essential Future" означают расширенную функциональность. Эти функции должны быть реализованы, чтобы объявить соответствие на расширенном уровне. Функции с приоритетом "Essential Future" становятся обязательными через 18 месяцев после публикации настоящего функционального профиля и потребуются для безотлагательной реализации, чтобы объявить соответствие на базовом или на расширенном уровне.
Требования к соответствию функциональному профилю-компаньону заинтересованного сообщества
Соответствие определено для системы BuyMyDiabetesEHR. Для соответствия этому функциональному профилю-компаньону ДОЛЖНЫ быть доступны и реализованы все функции с приоритетом "Essential Now", а также функции с приоритетом "Essential Now", входящие в профили предметных областей Long Term Care (долгосрочное лечение) и Ambulatory (амбулаторная помощь). Функции с приоритетом "Essential Future" являются необязательными, присутствуют только для информации и МОГУТ быть реализованы в будущих функциональных профилях-компаньонах.
6.8.3 Интерпретация и применение "условной обязательности" (справочный подраздел)
Критерий соответствия в функциональной модели и вновь создаваемые критерии могут структурироваться в простом формате, когда за действующим лицом следует нормативный глагол, за которым следует действие или свойство. Например, система ДОЛЖНА собирать демографическую информацию как часть записи пациента.
Однако имеются две условные формы, для которых, если условие верно, может применяться следующий за ним текст. Одной из них является "если/то" (If/Then). Если есть условие, то за ним следует действующее лицо, затем нормативный глагол, за которым следует действие. Если условие не выполнено (т.е. неверно), то следует игнорировать остальную часть предложения. Например, ЕСЛИ данные обмениваются с внутренними или внешними системами, ТО система ДОЛЖНА соответствовать функции IN 5.1 (Стандарты взаимодействия).
Другой формой является формат "условно обязательный". За действующим лицом следует нормативный глагол, за которым следует действие/взаимодействие, за которым следует оговорка "в соответствии с областью практики, политикой организации или действующим законодательством". Например, "Система ДОЛЖНА обеспечить администраторам информационной безопасности системы ведения ЭМК возможность авторизации принципалов в соответствии с областью практики, политикой организации или действующим законодательством".
Следующий пример "условно обязательного" критерия функциональной модели будет использоваться для иллюстрации понятий в этой формулировке.
Критерий функциональной модели: система ДОЛЖНА обеспечить администраторам информационной безопасности СВ ЭМК возможность осуществлять авторизацию принципалов в соответствии с областью практики, политикой организации или действующим законодательством.
6.8.4 Общие концепции
"Условно обязательный" критерий предназначен для разрешения функциональным профилям ограничивать критерии функциональной модели "должен" ситуационными условиями, например политикой и правовыми последствиями. А именно "условно обязательные" критерии в функциональной модели являются критериями "должен" плюс зависимость, где зависимость определяется с помощью:
- области практики, относящейся к профессиональной деятельности пользователя ЭМК и обозначающей хорошие практики в области его специализации, которые могут быть специфичны или не специфичны для конкретных условий оказания медицинской помощи;
- политики организации, означающей план или способ действий по принятию (воздействию на принятие) решений, выполнению деятельности и других аспектов группы лиц, организованной с конкретной целью в форме ассоциации и структуры, позволяющей отдельным лицам систематически сотрудничать для ведения бизнеса;
- законодательства, означающего полномочия или контроль на определенной территории с правом интерпретации, применения и декларирования свода норм и принципов управления делами сообщества, приводимого в исполнение политическим руководством и являющегося юридической системой;
Структура "условно обязательного" критерия в функциональной модели та же, как у критерия "должен", но с добавлением фразы "в соответствии с областью практики, политикой организации или действующим законодательством" или других подходящих грамматически присоединенных слов (например, "на основе", а не "в соответствии"). Следует учесть, что в "условно обязательных" критериях, описанных в функциональной модели, присутствуют все три зависимости. Именно функциональный профиль ограничивает их до одной зависимости или любого сочетания из трех. Более того, в функциональном профиле специальная область практики, политика организации и/или законодательство, которые делают необходимым применение "условной обязательности", явно идентифицированы.
Например (произведен из приведенного выше критерия, указанного в функциональной модели),
критерий функциональной модели: система ДОЛЖНА обеспечить администраторам информационной безопасности СВ ПЭМК возможность осуществлять авторизацию принципалов в соответствии с HIPAA (U.S. Health Insurance Portability and Accountability Act - Закон об ответственности и переносе данных о страховании здоровья).
Различия между критерием "должен" и "условно обязательным" критерием показаны в таблице 3.
Таблица 3 - Различия между критерием "должен" и "условно обязательным" критерием
| Критерий "ДОЛЖЕН" | Критерий "Условно ОБЯЗАТЕЛЕН" |
Должен присутствовать в функциональном профиле | Да, либо дословный, или модифицированный (например, ограниченный или уточненный) | Да, дословно.
Если существует зависимость, то добавить дополнительные критерии, отражающие зависимость |
Реализован системами ведения ЭМК | Да | Ситуационно - реализовать только, если существует зависимость.
А именно система ведения ЭМК реализует не "условно обязательный" критерий (скопированный из ФМ), а дополнительный критерий "должен", созданный для учета зависимости |
6.8.5 Обоснование "условно обязательного" критерия
"Условно обязательный" критерий используется в функциональной модели для выделения определенных критериев и привлечения к ним внимания читателей - разработчиков функциональных профилей, а также других пользователей. "Условно обязательные" критерии рассматриваются как специальные случаи, в которых для разных условий оказания медицинской помощи существуют одна или несколько зависимостей, влияющих на эти критерии. Использование условной зависимости позволяет разработчикам всех функциональных профилей рассматривать критерии и осознанно принимать решение, применим ли такой критерий на основе описанной зависимости.
Каждый "условно обязательный" критерий дословно воспроизводится в функциональный профиль, невзирая на существование или отсутствие зависимости. Это обусловлено следующими причинами:
- Следование правилу, что критерий "должен" всегда наследуется функциональным профилем.
- Согласованность обработки "условной обязательности" при всех условиях (т.е. когда зависимость существует и когда ее нет).
- Сохранение "условной обязательности", чтобы она могла быть представлена в производных профилях.
- Сохранение "условной обязательности", чтобы она осталась действительной для данного профиля на случай будущего изменения требований (например, зависимость может не быть применима в настоящее время, но может оказаться применимой в будущем из-за изменения области практики, политики организации или законодательства).
6.8.6 Как применять "условную обязательность"
"Условно обязательный" критерий интерпретируется и применяется в функциональном профиле следующим образом:
- Скопировать критерий в функциональный профиль.
- Проанализировать критерий и определить, являются ли какие-либо зависимости применимыми в данном функциональном профиле.
- Если зависимость существует:
Если одна или несколько зависимостей применимы в функциональном профиле (например, в данной юрисдикции существуют нормативные требования), то следует добавить один или несколько критериев "должен", которые уточнят и дополнительно ограничат "условную обязательность" в соответствии с зависимостями.
Для новых критериев добавить объяснение и/или цитирование зависимости. Например, "Нормативные требования к этому функциональному профилю определяются федеральным законодательством США в Правилах конфиденциальности HIPAA (45 CFR, части 160, 162 и 164)". Объяснение, или цитирование, может быть дано в приложении. Вполне вероятно, что несколько критериев будут давать ссылку на те же самые объяснения или цитирование.
Примеры:
Критерии функционального профиля
1. Система ДОЛЖНА обеспечить администраторам информационной безопасности СВ ЭМК возможность осуществлять авторизацию принципалов в соответствии с HIPAA*.
2. Система ДОЛЖНА обеспечить администраторам информационной безопасности СВ ПЭМК осуществлять авторизацию ролей в соответствии с 42 CFR, часть 2*.
Объяснение зависимости:
Примечание - На территории США в "условно-обязательных" критериях, определенных в функциональном профиле, следует применять положения Федерального закона от 1996 года Health Insurance Portability and Accountability Act (HIPAA), а также другие требования законодательства или иные более строгие требования.
Таблица 4 - Сводка действий при существовании зависимости
ФМ | Применяется ли зависимость? | Применимость | Функциональный профиль |
Условно обя зательный | Да | Обязательная | Скопировать критерий "должен" из ФМ |
|
| Обязательная | Добавить дополнительный критерий для отражения зависимости. Использовать "должен" |
|
| Обязательная | Добавить объяснение или цитирование |
|
| Необязательная | Добавить дополнительный критерий, произведенный от "условно обязательного" критерия. Использовать "должен", "по возможности должен" или "может" |
Зависимость отсутствует
Если никакая зависимость не применима в данном функциональном профиле (например, отсутствуют область практики, политики организации или применимые требования законодательства), то следует документировать обоснование решения о неприменимости зависимостей. Такое объяснение может даваться в приложении. Вполне вероятно, что оно будет применимо к нескольким "условно обязательным" критериям.
Таблица 5 - Сводка действий, если никакая зависимость не применима
ФМ | Применяется ли зависимость? | Применимость | Функциональный профиль |
Условно обязаельный | Нет | Обязательная | Скопировать критерий "должен" из ФМ |
|
| Обязательная | Добавить объяснение |
|
| Необязательная | Добавить дополнительный критерий, произведенный от "условно обязательного" критерия. Использовать "должен", "по возможности должен" или "может" |
- Добавление дополнительных критериев - независимо от существования зависимости.
Всегда допускается добавлять новые критерии в функциональный профиль. Добавьте новые критерии, произведенные из "условно обязательного" критерия. В этих критериях используйте любое ключевое слово, "должен", "по возможности должен" или "может" (см. раздел 3).
Примеры:
1. Система ПО ВОЗМОЖНОСТИ ДОЛЖНА обеспечить администраторам информационной безопасности СВ ЭМК возможность осуществлять авторизацию принципалов.
2. Система МОЖЕТ обеспечить администраторам информационной безопасности СВ ЭМК возможность осуществлять авторизацию ролей.
3. Система ПО ВОЗМОЖНОСТИ ДОЛЖНА обеспечить администраторам информационной безопасности СВ ЭМК возможность осуществлять контекстно-зависимую авторизацию.
4. Система ДОЛЖНА обеспечить администраторам информационной безопасности СВ ЭМК возможность осуществлять авторизацию ролей в организациях с численностью персонала, составляющую десять сотрудников или более.
7 Глоссарий
7.1 Предисловие (справочный подраздел)
Большая часть этого глоссария классифицируется как СПРАВОЧНАЯ. Раздел "Структура глаголов действия" является ОБЯЗАТЕЛЬНЫМ. Настоящий глоссарий предоставлен в качестве руководства по подготовке и интерпретации спецификаций функционального профиля системы ведения электронных медицинских карт HL7, а также объявлений соответствия. Его цель состоит в обеспечении ясности и согласованности при интерпретации и применении текста функциональной модели системы ведения электронных медицинских карт HL7 (ФМ СВ ЭМК).
Данный глоссарий рассматривается как международный с точки зрения применения. Тем не менее каждая сфера применения может пожелать адаптировать термины на собственном языке.
7.2 Введение (обязательный подраздел)
Глоссарий функциональной модели системы ведения электронной медицинской карты (ФМ СВ ЭМК), разработанной организацией HL7, является справочным документом организации HL7, содержащим набор определений и рекомендаций, предназначенных для обеспечения ясности и согласованности терминов, используемых в описании функциональной модели. Глоссарий содержит определения важных терминов, используемых в представлении функциональности систем ведения ЭМК, и охватывает согласованный на основе консенсуса список глаголов действия, а также специфичные рекомендации по конструированию критериев соответствия (КС).
Глаголы действия играют ключевую роль в формулировании критериев соответствия (КС). Была выполнена большая работа по категоризации и нормализации глаголов действия и по разработке рекомендаций по созданию понятных и согласованных КС во всей ФМ СВ ЭМК. Преемственность с предыдущими версиями ФМ СВ ЭМК обеспечивается за счет включения в глоссарий устаревших терминов, дополненных предложениями предпочтительных заменяющих терминов. Активные действия были предприняты для снижения неоднозначности, свойственной использованию человеческого языка; были приняты меры по использованию фундаментального значения слов и исключению использования терминов, специфичных для предметной области.
7.3 Краткий обзор (справочный подраздел)
Рабочая группа HL7 EHR намерена постоянно унифицировать глоссарии, которые поддерживают функциональные модели систем ведения ЭМК и систем ведения персональных электронных медицинских карт (ПЭМК), поскольку обе модели пересекаются по охвату информации о медицинской помощи и функциональности системы и поскольку читателями нередко являются те же самые люди. Ожидается, что функциональные профили (ФП), созданные в контексте ФМ СВ ЭМК, будут признавать этот глоссарий и будут согласованы с ним. Однако этот глоссарий не предоставит определения всех терминов, используемых в функциональных профилях. В этих профилях обычно используются термины, специфичные для контекста и сферы применения, а также специальные термины, ассоциированные с конкретной областью применения, поэтому для таких терминов потребуется дополнительный глоссарий.
При объединении ФП необходимо уделять особое внимание тому, чтобы одинаковые глаголы действия использовались с одинаковым смысловым значением и чтобы идентичные смысловые значения передавались одним и тем же глаголом действия. Для лучшего согласования с настоящим глоссарием рекомендуется повторно пересмотреть и уточнить существующие ФП.
Некоторые общие термины и глаголы действия не были включены в этот глоссарий. Например, термины типа "компьютер", "клавиатура", "архив" и "компактный" считаются общими компьютерными терминами, определение которых не стоит давать здесь. Некоторые другие термины отражают функциональность, присущую любой компьютерной системе, и не определены здесь, например "вычислять". Читатели, которым нужны определения терминов, не представленные в глоссарии, могут обратиться к признанным словарям или энциклопедиям. Там, где определения терминов взяты из известных источников, даются специфичные ссылки.
В исторических целях приведено приложение, в котором описаны предыдущие иерархии глаголов действия, использованные в ФМ СВ ЭМК и ФМ СВ ПЭМК, и общая логика, которой придерживалась группа составителей текущей модели.
7.3.1 Известные вопросы (справочный подраздел)
Ниже представлены аспекты, которые были известны применительно к этой версии глоссария:
- Этот глоссарий был пересмотрен только в отношении глаголов действия. Группа глоссария (GT) намерена повторно изучить другие термины глоссария в будущем.
- Было уделено серьезное внимание согласованию определений с признанными словарями. Были использованы два (2) основных словаря:
- http://dictionary.reference.com/index.html, и
- Канадский Оксфордский словарь (только для определений).
- Там, где определения были получены из других признанных источников, источники помечены в графе таблицы "Ссылки". Заинтересованным сторонам предлагается по возможности заполнить графу "Ссылки".
- Не предполагается, что предлагаемые определения будут согласованы с различными определениями, включенными в другие стандарты, законы и нормативные акты, или в глоссарии конкретных предметных областей. Цель настоящего глоссария - быть универсальным и независимым от предметной области здравоохранения.
7.4 Структура глаголов действия (обязательный подраздел)
Глаголы действия, используемые для написания критериев соответствия (КС) в ФМ СВ ЭМК и ФМ СВ ПЭМК, разделены на три (3) категории, каждая с собственным набором глаголов действия:
- категория безопасности системы,
- категория управления данными,
- категория прослеживаемости.
Каждая категория состоит из глаголов действия, которые вместе представляют собой логический набор действий, отличающийся от двух других категорий. Все глаголы действия на всех уровнях определены в разделе глоссария (Раздел 4 "Глоссарий") настоящего документа; даны иллюстративные примеры.
7.4.1 Категория "Обеспечить безопасность (Системы)" (Secure (System))
Категория "Обеспечить безопасность (Системы)" содержит глаголы действия для контроля доступа (аутентификация и авторизация пользователей), прослеживания событий (ведение журналов и аудита), а также по поддержке операций. Эта категория имеет одного предка, "Обеспечить безопасность (Системы)" (Secure (System)), и три (3) промежуточных потомка: "Управлять доступом" (Control Access), "Прослеживать" (Track) и "Поддерживать (Операции)" (Sustain (Operations)).
Таблица 6 - Глаголы действий в категории "Обеспечить безопасность (Системы)"
Обеспечить безопасность (Системы) | ||||
Управлять доступом | Прослеживать | Поддерживать (Операции) | ||
Аутентифицировать | Авторизовать | Вести журнал | Вести аудит |
|
- Прослеживать (организовать; контролировать; администрировать; следить; инспектировать; изучить; оценить; наблюдать; вести мониторинг; управлять на основе политик; осуществить; проверить).
- Поддерживать (Операции): обеспечить надлежащую работу системы (например, поддерживать операции; качество; целостность; пропускную способность; зеркалирование; надежность; восстановление после отказа; отказоустойчивость; версионность; защиту от вирусов; предотвращение утечки; поддержку в актуальном состоянии; меры защиты).
7.4.2 Категория "Управлять данными" (Data Management)
Категория управления данными предоставляет глаголы действия для всего спектра действий системы по манипулированию данными. Категория имеет одного предка, "Управлять (Данными)" (Manage (Data)), и пять (5) потомков с подмножествами: "Собрать" (Capture), "Эксплуатировать" (Maintain), "Предоставить" (Render), "Обмениваться" (Exchange), "Определить" (Determine) и "Управлять видимостью данных".
Таблица 7 - Глаголы действия, представляющие категорию управления данными
Управлять (Данными) (Manage (Data)) | |||
Собрать | Эксплуатировать | ||
| Хранить (Store) | Изменить (Update) | Устранить (Remove) |
Автоматически заполнять | Архивировать | Аннотировать | Удалить |
(Auto-Populate) | (Archive) | (Annotate) | (Delete) |
Вводить | Резервировать | Аттестовать | Очистить |
(Enter) | (Backup) | (Attest) | (Purge) |
Импортировать | Дешифровать | Редактировать |
|
(Import) | (Decrypt) | (Edit) |
|
Получить | Шифровать | Гармонизировать |
|
(Receive) | (Encrypt) | (Harmonize) |
|
| Восстановить | Интегрировать |
|
| (Recover) | (Integrate) |
|
| Возвратить | Связать |
|
| (Restore) | (Link) |
|
| Сохранить | Пометить |
|
| (Save) | (Tag) |
|
|
| Снять пометку |
|
|
| (Untag) |
|
Окончание таблицы 7
Управлять (Данными) (Manage (Data)) | ||||||
Предоставить | Обмениваться | Определить | Управлять видимостью данных | |||
|
|
|
|
|
|
|
Извлечь
(Extract) | Представить
(Present) | Передать
(Transmit) | Экспортировать
(Export)
Импортировать
(Import)
Получить
(Receive)
Передать
(Transmit) | Анализировать
(Analyze) | Решить
(Decide) | Деидентифицировать
(De-Identify)
Скрыть
(Hide)
Маскировать
(Mask)
Восстановить идентификацию
(Re-Identify)
Раскрыть
(Unhide)
Демаскировать
(Unmask) |
Первые три подмножества следующим образом охватывают сбор, эксплуатацию и предоставление данных:
- собрать: автоматически заполнять поля данных на основе частично заполненной информации, вводить данные вручную, импортировать данные из внешнего источника (которым может быть прибор), получить данные от другой системы (которая может быть встроена в прибор);
- эксплуатировать: хранить, изменить и устранить данные;
- хранить: хранить данные на локальном носителе, резервировать данные в хранилище резервных копий и шифровать данные с целью защиты данных и обеспечения неприкосновенности частной жизни;
- изменить: редактировать данные путем модификации, аннотировать данные примечаниями, пометить данные метками, гармонизировать данные с другими источниками, интегрировать данные, связать с другими данными;
- устранить: удалить данные из индекса или каталога, очистить данные, хранящиеся на накопителе.
- предоставить: извлечь данные на основе определенных критериев, представить данные на подсоединенном устройстве, передать данные внешним системам или устройствам.
Следующее подмножество предоставляет глаголы для определения действий по обработке данных:
- определить: анализировать данные, используя правила и аналитические шаги, и затем решить, какие действия следует выполнить по результатам этого анализа.
Последнее подмножество позволяет создавать объявления, ограничивающие видимость данных, и обращать эти действия:
- управлять видимостью данных: деидентифицировать данные, чтобы скрыть их отношение к конкретному лицу, скрыть данные, чтобы только авторизованные пользователи могли видеть, что данные существуют, и маскировать данные, чтобы пользователи могли видеть, что данные существуют, но только авторизованные пользователи действительно могли наблюдать реальные данные;
- обратить эти действия: восстановить идентификацию, раскрыть данные, демаскировать данные.
7.4.3 Как определяются глаголы действия
В настоящем глоссарии глаголы действия определены следующим образом.
Если глагол действия имеет родителя, то определение глагола начнется с глагола непосредственного родителя, а затем приводится повторное описание значения глагола действия, за которым следует по меньшей мере один (1) пример, соответственно маркированный. В примерах будут использоваться глаголы действия, определенные с помощью разъяснений, где это уместно. Ниже приведен иллюстративный пример:
- ПРЕДСТАВИТЬ (PRESENT) (глагол действия): ПРЕДОСТАВИТЬ (RENDER) (родительский глагол действия) данные путем отправки данных локальным пользователям содержательным и подходящим способом. Например, система может ПРЕДСТАВИТЬ (PRESENT) сигнал тревоги автоматически, если получен вновь поступивший результат лабораторного анализа, выходящий за пределы нормы.
Для глаголов действия верхнего уровня определение будет включать следующий уровень непосредственных потомков, за которым следует по меньшей мере один (1) пример, соответственно маркированный. В примерах будут использоваться глаголы действия, определенные с помощью разъяснений, где это уместно. Ниже приведен иллюстративный пример:
- УПРАВЛЯТЬ (ДАННЫМИ) (MANAGE (DATA)) (глагол действия): обработать данные с помощью сбора, эксплуатации, предоставления данных и визуализации данных, определения действий по обработке данных и управления видимостью данных. Например, система должна предоставить возможность для пользователя УПРАВЛЯТЬ (MANAGE) предпочтениями пациента и семьи, относящихся к текущим планам ведения.
7.4.4 Устаревшие глаголы действия
Глоссарий включает устаревшие глаголы действия и предложения о представлении их значения с помощью стандартизованного списка глаголов действия и квалификаторов в соответствии с разъяснениями, приведенными в 7.4.3 "Как определяются глаголы действия".
В настоящем глоссарии термин "устаревший" используется с целью квалификации глаголов действия, которые использовались прежде в критериях соответствия, но не являются частью обновленной иерархии глаголов действия; поэтому устаревшие глаголы действия не следует использовать. Эти устаревшие глаголы действия соответствующим образом маркированы. Примеры устаревших глаголов действия: ALERT (подать тревожный сигнал), QUERY (запросить) и SEARCH (искать).
При описании соответствия использование глаголов, имеющих специфичные определения и использование, обеспечивает лучшее понимание и согласованность критериев соответствия в модели.
7.5 Рекомендации по применению (справочный подраздел)
Лица, представляющие предложения по изменению содержания ФМ СВ ЭМК, должны тщательно ознакомиться с данным разделом, "Рекомендации по применению". Для целостности ФМ СВ ЭМК важно, чтобы ключевые термины имели согласованное значение во всей спецификации ФМ СВ ЭМК.
7.5.1 Общее руководство
Во всей ФМ СВ ЭМК термины, использованные для описания критериев соответствия (КС), в обязательном порядке должны придерживаться значений, представленных в определениях настоящего глоссария. Строгое использование глаголов действия позволит составить ясные критерии соответствия (КС) и поможет обеспечить согласованную передачу функциональных требований. Далее, объединение различных функциональных моделей и функциональных профилей упрощается, если контролируемый набор терминов используется согласованно. Поэтому следует избегать синонимов или местного жаргона.
В ФМ СВ ЭМК объявления и описания следует писать "деловым стилем", определяя возможности системы, поддерживающие потребности пользователей, в пользовательских и деловых терминах. КС следует составлять с системной точки зрения, придерживаясь строгости и согласованности между функциональными областями и используя глаголы действия и руководства; КС не должны дублировать объявления и описания. Однако в пределах области применения и объявление/описание, и соответствующие КС должны адресовать те же самые функциональности.
КС представляет собой фундаментальный компонент ФМ СВ ЭМК, определяя ее функциональность в точных терминах. Существенные усилия были затрачены на разработку набора глаголов действия с точными определениями, которые должны быть использованы при конструировании КС. В следующем подразделе приведены специфичные указания по компоновке КС.
Поскольку в различных сферах применения может требоваться использование определенных терминов (например, терминов, принятых в национальном законодательстве), ведение настоящего глоссария ФМ СВ ЭМК нейтрально по отношению к таким сферам. В долгосрочной перспективе предполагается конструировать КС, машинно-обрабатываемые и простые для валидации грамматики и содержания, коль скоро они релевантны (например, используют утвержденные глаголы действия).
7.5.2 Построение строгих критериев соответствия
При конструировании КС огромное значение имеют точность, ясность и согласованность. По возможности необходимо соблюдать следующие правила:
- Обычно предпочтительнее использовать несколько отдельных КС вместо одного, описывающего несколько действий, кроме случаев, когда такое объединение экономит объявления и является однозначным.
- Если действие может быть выполнено как автоматически системой, так и вручную, инициированное пользователем, то должны составляться отдельные КС.
Выбранные глаголы в критериях соответствия должны быть на соответствующем уровне детализации. Если используется родительский глагол из иерархии, то это означает, что действия всех его потомков уместны и применимы.
- Например, если удаление данных не было разрешено, то вместо "ЭКСПЛУАТИРОВАТЬ клинические данные", что означает хранение, изменение и удаление данных, можно сказать "ХРАНИТЬ и ИЗМЕНИТЬ данные".
- Например, если в данном КС предполагается, что обоснованными применениями функции будут РЕДАКТИРОВАТЬ и ПОМЕТИТЬ, а АННОТИРОВАТЬ, ГАРМОНИЗИРОВАТЬ, ИНТЕГРИРОВАТЬ, СВЯЗАТЬ будут необоснованными, то вместо слова ЭКСПЛУАТИРОВАТЬ следует использовать более точные РЕДАКТИРОВАТЬ и ПОМЕТИТЬ.
- Пример нескольких глаголов действия: Система ДОЛЖНА обеспечить возможность СОБРАТЬ, ХРАНИТЬ, РЕДАКТИРОВАТЬ и ПОМЕТИТЬ устаревшие записи реестра или каталога, чтобы он был актуальным.
При построении строгих КС должна использоваться следующая общая грамматическая структура:
Система [ДОЛЖНА |ПО ВОЗМОЖНОСТИ ДОЛЖНА| МОЖЕТ] [обеспечить способность] [глагол действия] [объект(ы)] [участник(и)] [квалификатор(ы)] ["в соответствии с областью практики, политикой организации или действующим законодательством"].
- Система является субъектом всех критериев соответствия (КС). Поэтому [субъект(ы)] не является параметром и был заменен на "систему".
- Конструкция [ДОЛЖНА |ПО ВОЗМОЖНОСТИ ДОЛЖНА| МОЖЕТ] обязательная. Должен использоваться один и только один из этих трех вспомогательных глаголов. Их значения определены в разделе "Требования к соответствию ФМ СВ ЭМК" и повторяются здесь для удобства:
ДОЛЖЕН (SHALL) - для обозначения обязательного требования, которое должно быть выполнено (реализовано), чтобы соответствовать. Синоним - "требуется".
ПО ВОЗМОЖНОСТИ ДОЛЖЕН (SHOULD) - для обозначения необязательного рекомендуемого действия, которое пригодно, в частности, без упоминания и исключения других действий. Синоним - "разрешено и рекомендовано".
МОЖЕТ (MAY) - для обозначения необязательного, допустимого действия. Синоним - "разрешено".
- Конструкция [обеспечить способность] является необязательной и используется, когда действие будет зависеть от вмешательства пользователя;
- Конструкция [глагол действия] обязательная. Глагол действия должен быть взят из стандартизованного списка, содержащегося в глоссарии, и его значение должно соответствовать тому, что описано в глоссарии. Если другой глагол представляется более предпочтительным, то предлагается найти этот глагол в глоссарии в разделе определений, где он может быть дан с предложениями по глаголу, который его заменяет, а также составу. В этом руководстве даны многочисленные примеры.
- Конструкция [объект(ы)] обязательная. Идентифицирует объект(ы) действия.
- Конструкция [участник(и)] необязательная. Включает пользователей (или внешние системы), участвующие или подвергающиеся воздействию указанного действия.
- Конструкция [квалификатор(ы)]: необязательная. Она может относиться ко времени, интервалу, условию(ям). Может включать (например) такие термины, как "автоматически", "вручную", "в реальном времени", "в соответствии с бизнес-правилами".
- Конструкция ["в соответствии с областью практики, политикой организации или действующим законодательством"] необязательная, если действие должно управляться конкретными областями практики, политиками организации или конкретным законодательством.
Учтите, что конструкция "[обеспечить способность]" является ключевой фразой, которая означает, что предполагается ручное вмешательство. Учтите также, что конструкция "Система ДОЛЖНА" означает, что система должна выполнить соответствующую функцию, если соблюдены и учтены все условия и факторы.
Ниже приведены некоторые примеры строгих КС:
- Система ДОЛЖНА обеспечить способность ПРЕДСТАВИТЬ список пациентов, которым запланирован прием, в соответствии с выбранными критериями, например фамилия, имя, отчество поставщика медицинской помощи, даты, время дня, характер посещения, и т.п., используя выбранный язык.
- ЕСЛИ поставщик медицинской помощи пытается назначить лекарство с помощью системы, ТО система ДОЛЖНА ОПРЕДЕЛИТЬ, существует ли взаимодействие между вновь назначенными лекарствами и лекарственными средствами из текущего списка лекарственных назначений, и ПРЕДОСТАВИТЬ поставщику подходящее уведомление в соответствии с областью практики, политикой организации или действующим законодательством.
Глагол "соответствовать" (Conform) используется в функциональной модели с особым значением и не является частью модели глаголов действия. Это специальная инструкция по включению функциональных требований одной функции в другую функцию.
- Например, "Система ДОЛЖНА соответствовать функции IN.1.1 (Аутентификация сущности)".
7.5.3 Примеры перефразирования критериев соответствия с помощью надлежащих глаголов действия
Примеры взяты из ФМ СВ ЭМК, версия R1.1. Эти примеры предоставлены в качестве иллюстрации улучшения состава КС и не подразумевают, что КС останутся такими же в более поздних выпусках ФМ СВ ЭМК.
- Система ПО ВОЗМОЖНОСТИ ДОЛЖНА обеспечить способность доступа к (access) ПРЕДСТАВИТЬ (PRESENT) обобщенную информацию с помощью пользовательских представлений на основе определения приоритетов хронологии, проблем или других уместных клинических параметров.
- Система ДОЛЖНА обеспечить способность закончить (finalize) ПОМЕТИТЬ (TAG) документ или примечание после того, как оно закончено (as finalized).
- Система ПО ВОЗМОЖНОСТИ ДОЛЖНА обеспечить способность произвести наборы назначений из планов ведения (derive order sets from care plans) ОПРЕДЕЛИТЬ и ПРЕДСТАВИТЬ соответствующие наборы назначений на основе анализа (based on an analysis) планов ведения.
- ЕСЛИ система используется для ввода, модификации или обмена (enter, modify or exchange) СБОРА, ИЗМЕНЕНИЯ или ПРЕДСТАВЛЕНИЯ данных, ТО система ДОЛЖНА соответствовать функции IN.1.5 (неоспоримость) для обеспечения необходимой прослеживаемости, чтобы источники и получатели данных не могли отрицать, что они ввели/отослали/получили данные.
- Система ПО ВОЗМОЖНОСТИ ДОЛЖНА обеспечить способность коммуницировать (communicate) ПЕРЕДАТЬ назначение нужному получателю(ям) для его выполнения.
- Система ДОЛЖНА обеспечить способность деактивировать (deactivate) ПОМЕТИТЬ проблему пациента как деактивированную (deactivated).
- Система ДОЛЖНА обеспечить способность группировать тесты, сделанные в тот же день (group tests done on the same day) АНАЛИЗИРОВАТЬ и ПРЕДСТАВЛЯТЬ тесты таким способом, чтобы те, что сделаны в тот же день, были бы сгруппированы вместе.
- Система МОЖЕТ обеспечить способность создать (create) СОБРАТЬ отображение терминологии.
- Система МОЖЕТ уведомить (notify) ПРЕДОСТАВИТЬ уведомление (RENDER a notification) клиницисту, если должны использоваться специфичные дозировки.
Другие примеры старых глаголов или фраз, проанализированных в контексте и затем записанных повторно новейшими глаголами действия, представлены в таблице 8.
Таблица 8 - Различие между глаголами/фразами в Выпуске 1.1 и Выпуске 2
Выпуск 1.1 | Выпуск 2 |
Создать (Create) | ЭКСПЛУАТИРОВАТЬ (MAINTAIN) и ПРЕДОСТАВИТЬ (RENDER) |
Добавить (Add), вводить (input) | СОБРАТЬ (CAPTURE) |
Дать определение ((Define), подогнать ((Tailor), специфицировать (Specify), устанавливать (Set) | СОБРАТЬ (CAPTURE) и ЭКСПЛУАТИРОВАТЬ (MAINTAIN) |
Генерировать (Generate) | ПРЕДОСТАВИТЬ (RENDER) |
Цитировать (Cite), включить (Include) | СОБРАТЬ (CAPTURE) и ПРЕДОСТАВИТЬ (RENDER) |
Экспортировать (Export) | ИЗВЛЕЧЬ (EXTRACT) И ПЕРЕДАТЬ (TRANSMIT) |
Обнаруживать (Find), идентифицировать (Identify) | ИЗВЛЕЧЬ информацию, необходимую для ... (EXTRACT the information needed to…) |
Специфицировать (Specify) | ПОМЕТИТЬ (TAG) |
Напомнить (Prompt) | ПРЕДОСТАВИТЬ уведомление (RENDER a notification) |
Пояснение терминов
"Различия" ("Distinctions"); "Важные различия" ("Important Distinctions"); "Уточненные термины" ("Nuanced Terms"); "Особые пометки" ("Special Notes"); "Проблемные термины" ("Troublesome Terms")
7.5.3.1 "Лекарственное назначение" (Medication Order) по сравнению с "рецептом" (Prescription Order)
7.5.3.1.1 Мотивация
ФМ СВ ЭМК содержит функциональность, поддерживающую управление назначениями лекарств, изделий, терапии и т.п. Рабочая группа обнаружила необходимость разъяснить различия между "лекарственными назначениями" (medication orders) и "рецептами" (prescription orders).
7.5.3.1.2 Подробная информация о различиях
Рецептурное лекарственное средство (Prescription Medication) - это зарегистрированное лекарство, обращение которого регулируется законодательством и для получения которого необходим рецепт уполномоченного медицинского специалиста. Термин используется, чтобы отличать его от безрецептурного лекарственного средства, которое можно получить без рецепта. В различных юрисдикциях используются разные определения "рецептурных лекарственных средств". [Адаптировано из Википедии: "Prescription Medication".]
"Лекарственное назначение" (Medication Order) представляет собой указание уполномоченного медицинского специалиста (или назначающего лица) (например, врача, ассистента, стоматолога или фельдшера) на отпуск рецептурных или безрецептурных лекарств. Это действие документируется в системе ведения ЭМК. "Рецепт" - это документ, передаваемый (например, в аптеку) в результате создания лекарственного назначения.
7.5.3.1.3 Рекомендации
Термин "Рецепт" (Prescription) должен использоваться только в случае, когда относится к сущности, требуемой законодательством.
Термин "Лекарственное назначение" (Medication Order) является предпочтительным в функциональной модели СВ ЭМК.
Приложение А
(обязательное)
Список функций
Список функций ФМ СВ ЭМК см. во вложенных файлах EHR_FM_R2_FunctionList.html и EHR-S_FM_R2_FunctionList.pdf. Два формата предоставлены для удобства читателей.
Приложение В
(справочное)
Глоссарий терминов ФМ СВ ЭМК
Таблица B.1 - Глоссарий терминов ФМ СВ ЭМК
Термин | Определение | Ссылка |
Принимать
(Accept) | Используйте вместо него ПРЕДСТАВИТЬ (PRESENT) или ПРЕДОСТАВИТЬ (RENDER) сообщение о приемлемости, основанное на установлении факта (АНАЛИЗИРОВАТЬ (ANALYZE) или РЕШИТЬ (DECIDE)), что данные валидны. Адаптировать к контексту | Этот глагол устарел в качестве термина иерархии глаголов |
Предоставить доступ
(Access) | Используйте вместо него УПРАВЛЯТЬ ДОСТУПОМ (CONTROL-ACCESS), если контекст предполагает управление доступом к системе.
Используйте ПРЕДОСТАВИТЬ (RENDER) или ПРЕДСТАВИТЬ (PRESENT), или другой уместный глагол действия, если контекст предполагает доступ к данным | Этот глагол устарел в качестве термина иерархии глаголов |
Контроль доступа
(Access control) | Средство обеспечения доступа к ресурсам системы обработки данных только для авторизованных лиц авторизованным способом | (ИСО/МЭК 2382-8, 1998) |
Учетность
(Accountability) | Свойство, обеспечивающее возможность прослеживаемости действий именно конкретного субъекта | (ИСО/МЭК 2382-8, 1998) Цитируется в ИСО/ТС 18308 |
Активное назначение
(Active order) | Активное (Active) - в состоянии действия. Назначение (Order) - требование выполнения определенной процедуры | America Heritage Dictionary, Second College Edition, Houghton Mifflin Company, Boston, 1991 |
Деятельность
(Activity) | См. "деятельность по оказанию медицинской помощи" (health care activity) |
|
Участник (Actor) (в системе медицинской помощи) | Медицинский специалист, медицинский работник, па- циент/потребитель, спонсируемый поставщик медицинской помощи, медицинская организация, прибор или приложение, участвующее в обмене медицинской информацией, или служба | (ИСО/ТС 17090-2001 модифицировано) цитируется в ИСО/ТС 18308 |
Административное ускорение регистрации
(Administrative acceleration of registration) | Метод отложенного рабочего процесса регистрации пациента. Очень полезен при оказании медицинской помощи в экстренных ситуациях, когда действия по спасению жизни стоят выше требований по регистрации пациента |
|
Упреждающее распоряжение
(Advanced Directive) | Упреждающие распоряжения - это юридические документы, позволяющие лицу передавать его пожелания по оказанию медицинской помощи в терминальной стадии, включая использование антибиотиков, парентеральное питание и реанимацию. Этот документ не является доверенностью, выданной медицинской организации, или завещанием |
|
Нежелательная реакция
(Adverse reaction) | Непреднамеренный результат или эффект, нежелательный и/или неблагоприятный |
|
Повышенная чувствительность
(Adverse sensitivity) | Состояние, которое, вероятно, приведет к нежелательной физиологической реакции на количество субстанции, не вызывающее реакции у большинства лиц |
|
Подтверждать
(Affirm) | Используйте вместо него ПОМЕТИТЬ (TAG) (с соответствующим квалификатором). Синонимы: Affirm, Assert, Declare, Indicate и State | Этот глагол устарел в качестве термина иерархии глаголов |
Постфактумный
(After Action) | Прилагательное, используемое вместе со словами "доклад", "краткое изложение" или другими средствами распространения информации. "Постфактумный анализ - это структурированный анализ или процесс дебрифинга того, что случилось, почему случилось и как можно это улучшить, осуществляемый участниками и ответственными за проект или событие. Его применение расширилось и охватило бизнес как инструмент управления знаниями и способ формирования культуры учетности".
"Постфактумный анализ представляет собой любую форму ретроспективного анализа определенной последовательности предпринятых ранее целеориентированных действий, осуществленных, как правило, самим автором". | 1. http://en.wikipedia.org/wiki/After_ action_review
2. http://en.wikipedia.org/wiki/After_ action_report |
Агрегат
(Aggregate)
(в контексте здоровья населения) | Совокупность отдельных лиц, семей или других групп, связанных похожими социальными, личными, медицинскими потребностями либо интересами. Группировка осуществляется с целью обеспечения отдельного измерения или наблюдения для статистического анализа. Например, "с 10%-ным правдоподобием в прошлом году в клинике на Мэйн Стрит пациентам-левшам чаще делали прививки от гриппа, чем правшам". (Примечание: в контексте здоровья населения агрегируемые данные часто деидентифицируются) | Miller-Keane Encyclopedia and Dictionary of Medicine, Nursing, and Allied Health, Seventh Edition. © 2003, выходные данные Elsevier, Inc. |
Агрегат данных (в контексте информационных технологий) Aggregate data | Данные, собранные от двух или более источников. | Computer Desktop Encyclopedia copyright © 1981-2012, издатель "The Computer Language Company Inc." |
Тревожный сигнал (Alert - существительное) | Тип уведомления, предусматривающий действия со стороны получателя |
|
Подать тревожный сигнал
(Alert) | Используйте вместо него "ПРЕДОСТАВИТЬ (RENDER), ПРЕДСТАВИТЬ (PRESENT) или ПЕРЕДАТЬ (TRANSMIT) тревожный сигнал лицу или другой системе (включая прибор)". Тревожный сигнал обычно формируется после анализа определенных данных и принятия решения об экстренном сообщении определенному лицу. См. ОПРЕДЕЛИТЬ (DETERMINE) в части примеров | Этот глагол устарел в качестве термина иерархии глаголов |
Аллергия
(Allergy) | Усиленный иммунный отклик или реакция на вещество, которое в общем случае не является вредным (См. MedLine Plus, Национальная библиотека медицины США, NIH). Проявление аллергии включает различные физиологические отклики (например, сыпь, зуд, гипотензию, анафилаксию) и может зависеть от путей воздействия (вдыхание, контакт с кожей, глотание) |
|
Внести изменения
(Amend) | Используйте вместо него РЕДАКТИРОВАТЬ (EDIT) | Этот глагол устарел в качестве термина иерархии глаголов |
Анализировать
(Analyse) | ОПРЕДЕЛИТЬ (DETERMINE) действия процесса обработки данных с помощью сравнения, корреляции или взвешивания определенных данных и применения клинических правил или бизнес-правил, в результате чего прийти к решению (см. РЕШИТЬ (DECIDE)). Например, система может АНАЛИЗИРОВАТЬ (ANALYZE) информацию о пациенте, используя базу данных межлекарственного взаимодействия и набор клинических правил. Другим примером является возможность системы АНАЛИЗИРОВАТЬ (ANALYZE) различные протоколы, связанные с состоянием пациента. Еще один пример: лицо может АНАЛИЗИРОВАТЬ (ANALYZE) предлагаемые уточнения домашнего адреса пациента и РЕШИТЬ (DECIDE) отклонить предлагаемые уточнения |
|
Аннотировать
(Annotate) | ИЗМЕНИТЬ (UPDATE) данные, добавляя комментарии или примечания к данным без редактирования собственно данных. Например, перед подписанием протокола лечащий врач может АННОТИРОВАТЬ (ANNOTATE) информацию, введенную врачом-интерном |
|
Прилагать
(Append) | Используйте вместо него термин РЕДАКТИРОВАТЬ (EDIT). Это означает редактирование данных с помощью добавления новых данных к существующим | Этот глагол устарел в качестве термина иерархии глаголов |
Соответствующий
(Appropriate) | Подходящие, надлежащие или зависящие от контекста идентификация, обозначение или квалификация. Термин "соответствующий" используется в настоящем документе, чтобы систематизировать потребности в гибкости охвата условий, которые лучше всего разрешаются динамически. Значение термина "соответствующий" разъясняется в настоящем документе на подходящих примерах |
|
Архитектура
(Architecture) | Структура компонентов, их взаимоотношений, а также принципов и указаний, управляющих их конструкцией и развитием во времени | ИСО 18308 |
Архивировать (глагол)
(Archive) | ХРАНИТЬ (STORE) данные путем перемещения на носитель длительного хранения данных с удалением или очисткой данных в исходном оперативном хранилище данных в соответствии с областью практики, политикой организации или действующим законодательством. Например, система больницы "Oak Street" автоматически АРХИВИРУЕТ (ARCHIVE) данные пациентов, которые старше 8 лет, а именно шифрует и сжимает их, перемещает на носитель длительного хранения данных, очищает их, идентифицируя данные по году и месяцу, и создает ссылку на архивированные данные. Другой пример: система может автоматически АРХИВИРОВАТЬ (ARCHIVE) заменяемые расписания амбулаторного приема |
|
Архивирование
(Archive - существительное) | Процесс перемещения одного или нескольких извлечений из ЭМК во внешнее хранилище, при необходимости обеспечивающий возможность их восстановления в оперативном хранилище без потери значения. По возможности архивированные данные должны быть технологически нейтральными, чтобы будущие пользователи не зависели от устаревших технологий | |
Санкция (пациента)
(Assent) | Санкция - "это согласие на что-либо, особенно после тщательного рассмотрения".1 Однако при клинической помощи это, как правило, относится к пациентам с ограниченной способностью принятия решений, например к детям и лицам с определенной формой психического расстройства (к примеру, легкое слабоумие).1 В контексте медицинских исследований это может быть "утвердительным ответом ребенка на участие в исследовании".2 "Санкция в отличие от информированного согласия относится к принятию решения пациентами с необратимыми нарушениями способности принятия решений, но не в полной мере ее утратившими". Кроме того, "некоторые дети являются достаточно зрелыми в своей способности принятия решений, так что решения нужно принимать с ними, несмотря на то, что с юридической точки зрения решения принимаются за них их родителями".3 Для детей "цель процесса получения санкции состоит не в предоставлении второго согласия, а в том, чтобы предоставить детям соответствующий уровень участия в процессе принятия решений, которые имеют к ним непосредственное отношение"4 | http://www.merriam-webster. com/dictionary/assent (по состоянию на 6 февраля 2013 г.)
US Federal Regulation, 45 CFR 46.402, Department of Health and Human Services, http://www.hhs.gov/ohrp/sachrp/ 20061109sachrpappendixa.pdf (по состоянию на 6 февраля 2013 г.)
"Informed Consent, Assisted Consent, and Assent in Geriatric Health Care", Laurence B. McCullough, Ph.D., Professor of Medicine and Medical Ethics, Associate Director for Education, Center for Medical Ethics and Health Policy, Baylor College of Medicine, http://www.google.com/url?sa=t&rct= j&q=&esrc=s&-source=web&cd= 6&cad=rja&ved=0CFYQFjAF&url= http%3A%2F%2Fwww.bioethics. union.edu%2Fbio%2Fmccullough%2F1.ppt&ei= T3ASUcXqPKvD0AHT6YGoDg&usg=AFQjCNGmVxijttj KsbDQ3ixt5prKK3iXQ&bvm=bv41934586.d.dmQ (по состоянию на 6 февраля 2013 г.)
"Assent is Not Consent", Journal of Medical Ethics, 2012; 38:3, http://jme.bmj.com/content/38/1/3.full (по состоянию на 6 февраля 2013 г.) |
Утверждать
(Assert) | Используйте вместо него ПОМЕТИТЬ (TAG) (с соответствующим квалификатором). Синонимы: Affirm, Assert, Declare, Indicate и State | Этот глагол устарел в качестве термина иерархии глаголов |
Оценка
(Assessment) | 1 (в медицине и сестринской помощи) оценка или аттестация состояния.
2 процесс выполнения такой оценки.
3 (в проблемно-ориентированной медицинской карте) оценка заболевания или состояния, сделанная медицинским специалистом на основе субъективного сообщения пациента о симптомах и течении заболевания или состояния, или объективные выводы медицинского специалиста, сделанные по результатам лабораторных исследований, физикального обследования, анализа истории болезни и информации, полученной от членов семьи и других медицинских работников. См. также сестринская оценка, проблемно-ориентированная медицинская карта | Mosby’s Medical Dictionary, 8th edition. © 2009, Elsevier |
Атомарные элементы
(Atomic elements) | Атомарные элементы являются базовыми численными клиническими измерениями, которые могут использоваться для вычисления более полезных клинических характеристик, например рост и вес (атомарные измерения) для вычисления индекса массы тела (дискретный элемент более высокого уровня) |
|
Аттестовать
(Attest) | ИЗМЕНИТЬ (UPDATE) информацию, АТТЕСТУЯ (ATTEST) запись ЭМК (или часть записи ЭМК) как подлинную.
Например, врач-интерн может АТТЕСТОВАТЬ (ATTEST) созданную им информацию в записи ЭМК. Другой пример: лечащий врач может аннотировать версию записи, сделанную врачом-интерном, а затем АТТЕСТОВАТЬ (ATTEST) эти изменения.
Примечание - Аттестации могут быть применены, прикреплены или привязаны к записи ЭМК, например, с помощью цифровой подписи, сертификации или иной подтверждающей метки
|
|
Аттестация
(Attestation) | Процесс сертификации и регистрации юридической ответственности за конкретную единицу информации | |
Вести аудит
(Audit) | ПРОСЛЕЖИВАТЬ (TRACK) деятельность, инициированную системой или пользователем, анализируя журналы на основе политик и правил. Например, система может автоматически ВЕСТИ АУДИТ (AUDIT) дневного журнала на наличие множественных неудачных попыток входа в систему. Другим примером может служить ВЕДЕНИЕ АУДИТА (AUDIT) администратором чрезмерных экстренных превышений полномочий (т.e. "разбейте стекло аварийной кнопки") для доступа к определенной информации пациента в отделении экстренной помощи |
|
Прибавить
(Augment) | Используйте вместо него РЕДАКТИРОВАТЬ (EDIT), АННОТИРОВАТЬ (ANNOTATE) или СВЯЗАТЬ (LINK) с соответствующими квалификаторами. Прибавление (Augmentation) - это добавление информации к имеющимся медицинским данным | Этот глагол устарел в качестве термина иерархии глаголов |
Аутентифицировать
(Authenticate) | УПРАВЛЯТЬ ДОСТУПОМ (CONTROL ACCESS) к системе, проверяя действительность идентификатора пользователя, другой системы или устройства перед авторизацией доступа. Например, система может АУТЕНТИФИЦИРОВАТЬ (AUTHENTICATE) д-ра Джонса, проверяя его идентичность, используя идентификатор пользователя UserID и биометрическое устройство. Другой пример: система отклоняет попытки Сары Смит АУТЕНТИФИЦИРОВАТЬСЯ (AUTHENTICATE) после трех неудачных вводов пароля |
|
Уполномоченный орган
(Authority) | Орган, наделенный полномочиями и правами | (ИСО/МЭК 2382-8, 1998), как цитируется в ИСО/ТС 18308 |
Авторизация
(Authorization) | Процесс разрешения или отказа в доступе к сетевым ресурсам. Большинство компьютерных систем безопасности используют двухфазный процесс, иногда фаз больше. Первая фаза - аутентификация, которая удостоверяет, что пользователь тот, кем себя заявляет, а в некоторых случаях - что пользователя еще нет в системе. Вторая фаза - авторизация, разрешающая пользователю доступ разного уровня к разным ресурсам на основе предварительно назначенных привилегий, ассоциированных с идентичностью пользователя | http://www.csgnetwork.com/ glossarya.html#authorization |
Авторизовать
(Authorize) | УПРАВЛЯТЬ ДОСТУПОМ к (CONTROL ACCESS) системе, применяя разрешения на использование определенной функциональности или просмотра определенных данных. Например, система может АВТОРИЗОВАТЬ (AUTHORIZE) д-ру Джонсу, врачу отделения неотложной помощи, просмотр записей пациентов этого отделения. (Примечание: предполагается, что администратор ввел набор разрешений для всех врачей отделения неотложной помощи.) Другой пример: система не АВТОРИЗУЕТ (AUTHORIZE) удаление Сарой Смит уже подписанной записи пациента |
|
Автоматически
(Automatically) | Квалификатор, используемый для указания, что действие будет выполнено системой вне зависимости от какого-либо вмешательства пользователя. Например, система должна автоматически определить, что пользователь имеет привилегии по использованию запрошенной функциональности |
|
Автоматически заполнять
(Auto-populate) | СОБРАТЬ (CAPTURE) данные с помощью автоматического ввода на основе существующих данных, предоставляя значение по умолчанию, или производя от других данных, или выполняя различные бизнес-правила ввода данных. Например, система может АВТОМАТИЧЕСКИ ЗАПОЛНЯТЬ (AUTO-POPULATE) поля с названиями города, штата/провинции и страны, когда пользователь вводит почтовый индекс. Другой пример - система может АВТОМАТИЧЕСКИ ЗАПОЛНЯТЬ (AUTO-POPULATE) домашний адрес новорожденного по домашнему адресу матери |
|
Фоновый процесс
(Background process) | Фоновые процессы - это процессы, протекающие скрытно, без вмешательства человека или иного вмешательства. Иногда используются для выполнения некоторых эксплуатационных действий или для обработки нештатных ситуаций, возникающих в течение жизненного цикла экземпляра | http://www.dbasupport.com/oracle/ ora9i/background_process01.shtml |
Резервировать
(Backup - глагол) | ХРАНИТЬ (STORE) данные, поместив копию данных в устройство с электронным доступом для сохранения на случай утраты, разрушения или повреждения оригинала. Например, система может РЕЗЕРВИРОВАТЬ (BACKUP) последовательные изменения в записи пациента, ежедневно обеспечивая их местное хранение. Другой пример: администратор может РЕЗЕРВИРОВАТЬ (BACKUP) полную копию определенных данных, сохраняя их за пределами организации |
|
Резервная копия
(Backup - существительное) | Копия данных, специально созданная для обеспечения их сохранности и возможного восстановления в случае утраты, разрушения или повреждения оригинала |
|
Лечение расстройств поведения
(Behavioural healthcare) | Комплекс услуг, предоставляемых лицам с повышенным риском или наличием нарушений психики, наркозависимости либо других нарушений поведения | www.mentalhealth.samhsa.gov/ publications/allpubs/MC98-70/default.asp |
Передовая практика
(Best practice) | Передовые практики - это практики, характеризуемые наиболее объективной информацией об эффективности и приемлемости, имеющейся в настоящее время | www.samhsa.gov/grants/2005/ nofa/sm65011_jail_appenAtol.pdf |
Связать
(Bind) | Обеспечить устойчивую связь между двумя (или более) элементами данных. Например, можно связать (электронную) подпись автора с соответствующим содержанием медицинской карты, созданным автором. Другой пример: связать определенные метаданные с электронным документом. Еще один пример: связать определенный результат лабораторных исследований (протокол) с назначением этих исследований |
|
Границы
(Boundaries) | Нечто, указывающее границу или предел. Граница или предел, указанные таким образом | http://dictionary.reference.com/ search?q=boundaries&r=66 |
Бизнес-правила
(Business Rule) | С точки зрения информационной системы "бизнес-правило представляет собой утверждение, определяющее или ограничивающее определенный аспект деятельности. Оно предназначено для декларирования структуры деятельности или контроля либо влияния на выполнение деятельности".1 В сфере здравоохранения есть много видов деятельности, для которых могут разрабатываться и применяться бизнес-правила. Примеры включают в том числе кодирование, выставление счетов, предъявление претензий и возмещения затрат, управление ресурсами (персоналом, койками, запасами, оборудованием), оптимизацию рабочего процесса и поддержку принятия клинических решений. Последняя является особым видом деятельности, предоставляемой клиницистам, для выполнения которой может требоваться очень развитый комплекс сложных алгоритмов, реализующих специфичные правила | 1. The Business Rules Group, http://www.businessrulesgroup.org/ defnbrg.shtml (по состоянию на 5 июня 2013 г.) |
Вычислять
(Calculate) | В зависимости от контекста вместо него используйте ОПРЕДЕЛИТЬ (DETERMINE) и ХРАНИТЬ (STORE) или ОПРЕДЕЛИТЬ (DETERMINE) и ПРЕДСТАВИТЬ (PRESENT) | Этот глагол устарел в качестве термина иерархии глаголов |
Собрать
(Capture) | УПРАВЛЯТЬ (MANAGE) данными с помощью автоматического заполнения, ввода, импорта или получения данных в результате вмешательства человека или автоматических средств. Например, система может СОБРАТЬ (CAPTURE) данные пациента, введенные врачом с клавиатуры или переданные врачом с мобильного устройства. Другой пример: система может СОБРАТЬ (CAPTURE) результаты лабораторных анализов с помощью автоматического получения лабораторных данных или клавиатурного ввода результатов местных тестов |
|
Руководства по медицинской помощи
(Care Guidelines) (синоним Health Care Guidelines) | Рекомендации пациенту, предлагаемые лечащим медицинским работником, либо рекомендации, признаваемые поставщиками медицинской помощи как заслуживающие выполнения. В целом руководства по медицинской помощи основаны на экспертных знаниях по оценке, лечению и/или управлению конкретным состоянием здоровья. Руководства для поставщиков медицинской помощи включают в себя важное подмножество клинических руководств. Согласно AHRQ (US Agency for Healthcare Research and Quality - Агентство исследований и оценки качества медицинской помощи США), клинические руководства могут быть разбиты на ряд категорий: оценка эффективности терапии, консультирование, диагностика, анализ, управление, профилактика, реабилитация, оценка риска, скрининг, оценка технологии и лечение | http://guideline.gov/about/glossary.aspx |
План ведения
(Care Plan) | План ведения представляет собой упорядоченный комплекс предполагаемых или планируемых мероприятий, включая исследования, цели, услуги, посещения и процедуры, как правило, организованный по фазам или сеансам, который имеет задачу организации и управления мероприятиями по медицинской помощи пациенту и нередко фокусируется на одной или нескольких проблемах со здоровьем пациента. В качестве исполняемых действий планы ведения могут включать в себя комплексы назначений, обычно поддерживающих один сеанс или фазу. Может также именоваться "планом лечения" | HL7 Clinical Decision Support team, Jim McClay, SAGE guideline consortium, University of Nebraska Medical Center |
План ведения (альтернативный вариант)
Care Plan | Персонифицированный перечень планируемых мероприятий по оказанию медицинской помощи, относящийся к одной или нескольким указанным проблемам со здоровьем | ИСО 18308, [ЕН 13940-1:2007, модифицированный] |
Лечебный процесс
(Care Process) | Клинически ориентированное задание (или ряд заданий). Лечебный процесс включает в себя планирование лечения, его предоставление и последующее наблюдение |
|
Медицинская бригада
(Care Team) | Группа лиц, предоставляющих медицинскую помощь лицу в течение случая медицинской помощи, в определенных условиях медицинской помощи или при определенном состоянии здоровья |
|
Каскад
(Cascade - существительное) | Что-либо организованное или возникающее в виде ряда или последовательности стадий, где каждая следующая стадия основана на результате выполнения предыдущей стадии | http://www.m-w.com/cgi-bin/dictionary? book=Dictionary&va=cascade |
Соглашение о цепочке доверия
(Chain-of-Trust Agreement) | Требование по реализации определенных административных процедур, обеспечивающих целостность, конфиденциальность и доступность чувствительных данных. Соглашение о цепочке доверия является такой процедурой. По существу, это соглашение о неразглашении, управляющее передачей данных в электронной среде. Отправитель и получатель соглашаются защищать данные, передаваемые электронным способом между ними | http://www.hipaadvisory.com/ action/legalqa/advisor/HIPAAdvisor5.htm |
История изменений
(Change history) | Регистрация изменений, произошедших с течением времени в документе или других контролируемых элементах. Журнал может служить в качестве регистрации аудита мероприятия в системе файлов | http://en.wikipedia.org/wiki/File_change_log |
Журнал изменений
(Change log) | Запись произошедших со временем изменений в документе или его пунктах. Для ведения аудита файловой системы может использоваться журнал | http://en.wikipedia.org/wiki/File_change_log |
Хроническое состояние
(Chronicity) | Атрибуты или аспекты, которые могут быть ассоциированы с хроническим состоянием. Атрибуты, относящиеся к хроническому состоянию, могут включать: период времени (например, детство, период полового созревания, константа), продолжительность состояния (например, кратковременное, длительное, устойчивое, привычное), продолжительность эпизода (например, во сне, самостоятельно завершающееся, стабильное), уровень (например, легкое, умеренное или тяжелое состояние либо боль), и/или периодичность либо частоту (например, сезонная аллергия) |
|
Медицинские данные/информация
Clinical Data/ linformation | Данные - информация, относящаяся к состоянию здоровья отдельного лица и оказанной ему медицинской помощи, собранная об отдельном лице (или полученная от него), получающем медицинскую помощь. Включает в себя объективную или субъективную оценку физического или психического состояния пациента, сделанную лечащим медицинским работником; анамнез заболевания и семейный анамнез; диагностические исследования; обоснование решений; описания выполненных процедур; исследования; терапевтические вмешательства; назначенные лекарства; описание реакции на лечение; прогностические заявления; описание социально-экономических факторов и состояния окружающей среды, относящихся к состоянию здоровья пациента | СПРИ, 1996b; АСТМ 1769 |
Поддержка принятия клинических решений
(Clinical decision support) | В широком смысле поддержка принятия клинических решений относится к предоставлению клиницистам или пациентам клинических знаний и информации о пациенте, разумно отфильтрованные или представленные в соответствующие моменты времени в целях улучшения медицинской помощи пациенту. Предоставляемые клинические знания могут варьироваться от простых фактов и отношений до лучших практик управления пациентами со специфичными заболеваниями, новых клинических знаний, полученных в результате клинических исследований, и других видов информации | http://www.himss.org/ASP/topics_clinicalDecision.asp |
Медицинская документация
(Clinical documentation) | Документация по клиническим наблюдениям, медицинской помощи или общению. Клиническая документация может быть собрана в форме структурированных или неструктурированных данных. Клиническая документация может быть предварительной, окончательной, заверенной или еще не заверенной |
|
Медицинские документы
(Clinical documents) | Документы, созданные в процессе оказания медицинской помощи и используемые для поддержки клинических решений. См. также "клиническая информация" |
|
Медицинское изображение
(Clinical image) | Медицинское изображение является нетекстовой, графической формой медицинской информации (например, рентгенограмма, снимок, видео, или форма биосигнала). Имеются различные типы медицинских изображений, включая фотографический снимок, которые например, заключаются в том, что изображения, как правило, требуют более высокой степени сложности обработки (например, программный код) для надлежащей интерпретации и "машинной обработки", если таковая необходима. (Примечание: большинство словарей, включая медицинские и по информационным технологиям, рассматривают снимок только как изображение. Но для целей HL7 ФМ СВ ЭМК в определение медицинского изображения включены все эти категории "мультимедийных цифровых объектов") |
|
Медицинская информация
(Clinical information) | Информация о пациенте, относящаяся к состоянию здоровья или лечению пациента, которая регистрируется медицинским специалистом или по его поручению.
Примечание - Медицинская информация о пациенте может содержать информацию об окружающей пациента среде, связанных с ним людях или животных, если таковая необходима
|
|
Клиническое руководство
Clinical Practice Guideline (CPG) | Положение, включающее рекомендации по оптимизации лечения пациента. Оно формируется за счет систематического анализа фактических данных и оценки преимуществ и вреда альтернативных вариантов медицинской помощи | ’’Clinical Practice Guidelines We Can Trust", Committee on Standards for Developing Trustworthy Clinical Practice Guidelines
Board on Health Care Services, Institute of Medicine (IOM) of the US National Academies of Science, May 17, 2011, http://www.iom.edu/~/media/Files/Activity%20Files/ Quality/System-ReviewCER/Workshop%20 Presentations/Shelly%20Greenfield.pptx (по состоянию на 21 февраля 2013 г.) |
Клинический процесс
(Clinical process) | Комплекс связанных или взаимодействующих мероприятий по оказанию медицинской помощи, выполняемый одним или несколькими медицинскими специалистами | ИСО 18308 |
Клиницист
(Clinician) | Медицинский специалист, непосредственно оказывающий медицинскую помощь пациенту/клиенту | ИСО/ТР 12773-1 |
Клинические действия
(Clinical tasks) | Действия, результаты выполнения которых регистрируются в медицинских документах |
|
Набор(ы) кодов
(Code set(s)) | В терминах HIPAA набором кодов считается любое множество кодов, используемых для кодирования элементов данных, например таблицы терминов, медицинских понятий, кодов медицинских диагнозов или медицинских процедур. Набор кодов содержит коды и их описания. HIPAA требует, чтобы все поставщики медицинской помощи, ведущие учет в электронной форме, использовали одни и те же транзакции передачи информации о медицинской помощи, наборы кодов и идентификаторы. Наборы кодов содержат коды, используемые для идентификации специфичных диагнозов и медицинских процедур в формах счетов на оплату медицинской помощи и формах учета обращения пациентов | http://aspe.hhs.gov/admnsimp/faqcode.htm
www.cms.hhs.gov/TransactionCodeSetStands/ |
Система кодирования
(Coding system) | Сочетание наборов кодов и их смысловых значений, построенное в соответствии со схемой кодирования.
Примечание - Смысловые значения кодов, как правило, представлены терминами или рубриками, но могут иметь и другое представление. Значения кодов, как правило, числовые или алфавитно-цифровые
| ИСО 18308, [ЕН 1068:2005] |
Схема кодирования
(Coding Scheme) | Набор правил отображения элементов одного набора в элементы другого набора.
Примечание - Здесь рассматриваются два набора: (1) набор "смысловых значений кодов" (или "кодированный набор"), и (2) набор "значений кодов" (или "набор кодов"). Сами по себе эти наборы не являются частью схемы кодирования
| ИСО 18308, [ИСО/МЭК 2382-4:1999] [ЕН 1068:2005] |
Кодированный
(Coded) | Означает ссылку на словарь, набор кодов или базу данных, например SNOMED, MEDCIN и т.п. |
|
Когорта
(Cohort) | Группа лиц, имеющих общую характеристику в некоторый конкретный момент времени, которая затем прослеживается в будущем с помощью сбора данных в одном или нескольких подходящих интервалах времени. Наиболее распространенным использованием термина является описание когорты новорожденных, в которую включаются все члены группы, рожденные в указанный период времени, однако когорту могут определять и другие общие характеристики, например дата вступления в брак, воздействие инфекционного агента, дата постановки диагноза или лечения заболевания | Miller-Keane Encyclopedia and Dictionary of Medicine, Nursing, and Allied Health, Seventh Edition. © 2003, выходные данные издательства Elsevier, Inc. |
Общее содержание (в контексте назначений)
Common Content | Информация, идентичная для отдельных назначений (например, лекарственных [к примеру, дозировка, частота, указания пациенту, идентификатор пациента, назначивший поставщик медицинской помощи], лабораторных, нелекарственных) тому же самому пациенту, для того же класса назначений или для события назначений |
|
Взаимодействие с медицинскими устройствами
Communication with medical devices | Взаимодействие и интеграция, начиная от уровня устройства до уровня базы данных, осуществляемые для обеспечения создания медицинских документов. Примеры включают автоматический импорт показаний артериального давления и просмотр ЭКГ |
|
Справочник
(Compendium) | В контексте лекарственных средств справочник представляет собой сборник информации, детализирующий стандарты активности, чистоты и качества лекарств | http://medical-dictionary.thefreedictionary. com/compendium |
Вычислить
(Compute) | В зависимости от контекста используйте вместо него ОПРЕДЕЛИТЬ (DETERMINE) и ХРАНИТЬ (STORE), или ОПРЕДЕЛИТЬ (DETERMINE) и ПРЕДСТАВИТЬ (PRESENT) | Этот глагол устарел в качестве термина иерархии глаголов |
Понятие
(Concept) | Единица знаний, образованная уникальным сочетанием характеристик | ИСО 18308, [ИСО 1087-1:2000] |
Служба подтверждения
(Confirmation service, BAA) | Служба, выполняющая идентификацию, контроль, учет и документирование всех изменений в аппаратном обеспечении, программном обеспечении, прошивке системы, эксплуатационной документации и результатах испытаний на протяжении срока жизни системы | All In One CISSP Certification Exam Guide, Shon Harris, CISSP, MCSE, CCNA, 2002, McGraw Hill, Osborne, Berkley, CA |
Конфиденциальность
(Confidentiality) | Свойство недоступности/неразглашения информации не авторизованным лицам, субъектам или процессам | [ИСО/ТС/ЕН 13606-4:2007, модифицированный] |
Конфигурировать
(Configure) | Используйте вместо него "УПРАВЛЯТЬ параметрами конфигурации для ..." (MANAGE configuration parameters for ...). Например, пользователю может потребоваться ХРАНИТЬ (STORE) параметры конфигурации по предпочтительному типу человеческого языка. Другой пример: администратор может ИЗМЕНИТЬ (UPDATE) параметры конфигурации, контролирующие внешний доступ к системе, ограничив его по выходным дням |
|
Соответствовать
(Conform) | Удовлетворять чему-либо.
Примечание - Глагол "соответствовать" (Conform) используется в функциональной модели с особым значением и не является частью модели глаголов действия. Это специальная инструкция по включению функциональных требований одной функции в другую функцию. Например, "Система ДОЛЖНА соответствовать функции IN.1.1 (Аутентификация сущности)"
|
|
Соответствие
(Conformance) | Выполнение заданных требований к продукту, процессу или услуге | Функциональная модель HL7 СВ ЭМК, глава 2 "Требования к соответствию" |
Критерии соответствия
(Conformance criteria) | Объявление требований, указывающих поведение, действие, возможность, составляющую реализацию функции | Функциональная модель HL7 СВ ЭМК, глава 2 "Требования к соответствию" |
Требования к соответствию
(Conformance clause) | Раздел спецификации, определяющий требования, критерии или условия, которые нужно выполнить, чтобы объявить соответствие | Функциональная модель HL7 СВ ЭМК, глава 2 "Требования к соответствию" |
Объявление соответствия
(Conformance statement) | Утверждение, ассоциированное со специфичной реализацией профиля функциональной модели СВ ЭМК | Функциональная модель HL7 СВ ЭМК, глава 2 "Требования к соответствию" |
Согласие
(Consent - существительное) | Соглашение, одобрение или разрешение на некоторое действие или намерение, которое дано добровольно компетентным лицом | ИСО 18308, [Black’s Law Dictionary, 2008] |
Согласие (информированное)
[Consent (informed)] | "Согласие пациента на хирургическую или медицинскую процедуру, либо на участие в клиническом исследовании, предоставленное после достижения понимания соответствующих медицинских фактов и рисков". Основное различие между информированным согласием и санкцией заключается в том, что при информированном согласии дающее его лицо считается в полной мере способным принимать решения по действиям, представленным ему, в то время как санкция (Assent) не подразумевает, что лицо в полной мере способно принимать решения. См. "Assent" | http://medical-dictionary.thefreedictionary. com/informed+consent (по состоянию на 6 февраля 2013 г.) |
Потребитель (по отношению к медицинской помощи)
(Consumer) | Лицо, которое может стать субъектом медицинской помощи | ИСО/ТР 12773-1 |
Управлять доступом
(Control Access) | АУТЕНТИФИЦИРОВАТЬ (AUTHENTICATE) пользователей и/или систему и АВТОРИЗОВАТЬ (AUTHORIZE) доступ к функциональности и/или данным. Например, система может УПРАВЛЯТЬ ДОСТУПОМ (CONTROL ACCESS) к данным пациента, аутентифицируя идентификацию д-ра Джонса и авторизуя ему обновление записей его пациентов. Другой пример: система может УПРАВЛЯТЬ ДОСТУПОМ (CONTROL ACCESS) к себе, отказываясь аутентифицировать посетителя больницы в системе. |
|
| Примечание - Набор глаголов действия УПРАВЛЯТЬ ДОСТУПОМ (CONTROL ACCESS) требует наличия разрешений на доступ к данным. Эти разрешения управляются набором глаголов действия УПРАВЛЯТЬ (MANAGE) данными
|
|
Корректировать
(Correct) | Используйте вместо него РЕДАКТИРОВАТЬ (EDIT) | Этот глагол устарел в качестве термина иерархии глаголов |
Создать
(Create) | В зависимости от контекста используйте вместо него ОПРЕДЕЛИТЬ (DETERMINE) и ХРАНИТЬ (STORE), или ОПРЕДЕЛИТЬ (DETERMINE) и ПРЕДОСТАВИТЬ (RENDER) или ОПРЕДЕЛИТЬ (DETERMINE) и ПРЕДСТАВИТЬ (PRESENT) | Этот глагол устарел в качестве термина иерархии глаголов |
Критичное значение
Critical value (также Panic value) | Результат исследования пациента (например, лабораторный, радиологический, патологический), о котором должно быть незамедлительно доложено поставщику медицинской помощи и который может потребовать срочного терапевтического воздействия 1. Использование критичных или тревожных значений является частью понятия "уровней решений" в лабораторной медицине; когда значение полученного результата лабораторного исследования превышает уровень решения, требуется реакция лечащего врача 2 | http://medical-dictionary.thefreedictionary. com/critical+value
http://medicaldictionary.thefreedictionary. com/decision+levels |
Текущее лекарственное назначение
(Current medication) | Лекарственное средство, используемое в настоящее время пациентом на регулярной основе или по ситуации (например, "две таблетки при возникновении боли"). Лекарственное средство, отпущенное пациенту, чье применение не завершено и не прекращено в соответствии с продолжительностью курса медикаментозной терапии, дозировкой, частотой и количеством |
|
Контрольная панель
(Dashboard) | Контрольная панель является средством представления данных, которое регулярно запрашивает информацию из систем(ы) и предоставляет ее пользователю, чтобы он мог принять решение и выполнить действия, и которое своевременно отражает влияние этих действий, чтобы пользователю было легче продолжить динамическое изменение своего поведения |
|
Агрегирование данных
(Data aggregation) | Процесс сбора информации, ее обработки и представления в краткой форме. Агрегирование данных в основном выполняется с целью предоставления отчета, разработки политик, управления медицинской помощью, проведения научных исследований, статистического анализа и исследования здоровья населения | |
Лицо, вводящее данные
(Data Enterer) | Лицо, передавшее в клинический документ содержание, написанное или надиктованное кем-то другим. Эмпирическое правило заключается в том, что автор представляет содержание заголовка или текста документа в соответствии с собственным толкованием, а лицо, вводящее данные, добавляет эту информацию в электронную систему. Другими словами, лицо, вводящее данные, передает информацию из одного источника в другой (например, осуществляет перезапись с бумажного носителя в электронную систему) | CDAR2_IG_IHE_CONSOL_DSTU_ R1.1_2012JUL, HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, DSTU Выпуск 1.1 (США)
Июль 2012 |
Валидация данных
(Data validation) | Процесс определения точности, полноты или соответствия данных указанным критериям.
Примечание - Валидация данных может включать проверки формата, полноты, ключей, достоверности и ограничений
| (ИСО/МЭК 2382-8, 1998)
Как цитируется в ИСО/ТС 18308 |
Решить
(Decide) | ОПРЕДЕЛИТЬ (DETERMINE) действия по обработке данных, выбирая на основе анализа определенную альтернативу и действуя соответственно. Например, система может РЕШИТЬ (DECIDE) предоставить свободным от дежурств медсестрам уведомление об отчете о дежурстве на основе правил клиники и о получении штормового предупреждения. Другой пример: система может РЕШИТЬ (DECIDE) ПРЕДОСТАВИТЬ (RENDER) клиницисту сигнал тревоги о том, что на основе проведенного анализа установлена противо- показанность прописанного лекарства в связи с аллергиями пациента, перечисленными в медицинской карте |
|
Подсказки поддержки принятия решений
(Decision support prompts) | Любая автоматизированная поддержка медицинских, управленческих, административных и финансовых решений в сфере здравоохранения на основе базы знаний и/или справочных материалов. [В этом смысле термин по существу синонимичен системам баз знаний, и некоторые пользователи предпочитают использовать его вместо терминов "экспертная система" или "система базы знаний"; например, система, использующая статистическую выборку с целью обеспечения пользователям поддержки в принятии решений, может считаться системой поддержки принятия решений, поэтому нужно осторожно выбирать тот или иной термин] | http://www.centc251.org/Ginfo/Glossary/tcglosd.htm |
Система поддержки принятия решений
(Decision support system) | Любая автоматизированная поддержка медицинских, управленческих, административных и финансовых решений в сфере здравоохранения, использующая некоторую логику обработки базы знаний и/или справочных материалов |
|
Объявить
(Declare) | Вместо него используйте ПОМЕТИТЬ (TAG) (с соответствующим квалификатором). Синонимы: Affirm, Assert, Declare, Indicate и State | Этот глагол устарел в качестве термина иерархии глаголов |
Дешифровать
(Decrypt) | ХРАНИТЬ (STORE) данные, преобразуя зашифрованные данные обратно в исходную форму, чтобы их можно было понять. Например, система может ДЕШИФРОВАТЬ (DECRYPT) клинические данные, полученные от аутентифицированной системы внешней лаборатории |
|
Дешифрование
Decryption | Процесс преобразования зашифрованных данных обратно в исходную форму, чтобы их можно было понять | http://searchsecurity.techtarget.com/ sDefinition/0,,sid14_gci212062,00.html |
Деидентификация
(De-identification) | Процесс удаления ассоциации между набором идентифицирующих данных и субъектом данных | ИСО 18308, [ИСО/ТС 25237:2008] |
Деидентифицировать
(De-identify) | УПРАВЛЯТЬ ВИДИМОСТЬЮ ДАННЫХ (MANAGE-DATA-VISIBILITY), таким образом удаляя идентификаторы из данных, чтобы риск идентификации лица был очень незначительным в обстоятельствах, указанных в области практики, политике организации или действующем законодательстве. Например, система может ДЕИДЕНТИФИЦИРОВАТЬ (DE-IDENTIFY) данные для научного работника, который хочет выполнить анализ эффективности лекарственного препарата для пациентов, больных диабетом. Другой пример: больница может ДЕ-ИДЕНТИФИЦИРОВАТЬ DE-IDENTIFY) данные ряда пациентов для передачи профессору университета, которому для учебных целей нужны показательные случаи |
|
Удалить
(Delete) | УДАЛИТЬ данные, делая их недоступными для применения. Например, пользователь может УДАЛИТЬ существующую запись на прием по просьбе пациента. |
|
| Примечание - Если данные становятся недействительными, но должны оставаться в системе, термин ПОМЕТИТЬ (TAG) более предпочтителен, нежели слово УДАЛИТЬ (DELETE) или "аннулировать" (Nullify). Этот тип действия считается процессом "пометки" данных, а не процессом удаления данных. Например, специалист по управлению медицинскими данными может пожелать ПОМЕТИТЬ (TAG) определенный клинический термин как устаревший, но термин должен оставаться в системе в целях обратной совместимости
|
|
Устареть
(Deprecate) | Используйте вместо него ПОМЕТИТЬ (TAG) (с соответствующим квалификатором).
Устаревание определенной информации может потребоваться, когда данные становятся недействительными, но должны оставаться в системе. Например, специалист по управлению медицинскими данными может пожелать ПОМЕТИТЬ (TAG) определенный клинический термин как устаревший, но термин должен оставаться в системе в целях обратной совместимости |
|
Устаревший глагол
(Deprecated-Verb) | В этом глоссарии термин "устаревший" используется для квалификации глаголов действия, которые ранее использовались в критериях соответствия и не являются частью текущего набора иерархии глаголов действия; следовательно, устаревшие глаголы действия по возможности не должны использоваться. Эти устаревшие глаголы помечены соответствующим образом. Примерами устаревших глаголов действия являются ALERT (подать тревожный сигнал), QUERY (запросить) и SEARCH (искать) |
|
Производный профиль
(Derived profile) | Профиль, созданный на основе существующего профиля | Функциональная модель HL7 СВ ЭМК, Глава 2 "Требования к соответствию" |
Определить
(Determine) | УПРАВЛЯТЬ (MANAGE) данными, анализируя их и принимая решение на основе анализа. Например, система может ОПРЕДЕЛИТЬ (DETERMINE) возможную серьезность аллергической реакции пациента на предлагаемое лекарство, анализируя профиль пациента в сравнении с базой данных по лекарствам и решая, следует ли представить тревожный сигнал клиницисту или нет. Другой пример: система может ОПРЕДЕЛИТЬ (DETERMINE) следующие шаги рабочего процесса на основе анализа результатов лабораторных исследований пациента, профиля пациента, а также клинических правил больницы. Такой анализ приводит к решению по целесообразным последующим шагам клинического процесса |
|
Электронная подпись
(Digital signature) | Электронная подпись (или электронная подпись в инфраструктуре открытых ключей) является разновидностью метода аутентификации цифровой информации, аналогичной обычным физическим подписям на бумаге, но реализованной способами криптографии открытых ключей. В общем случае метод электронной подписи определяет два дополняющих друг друга алгоритма, один для подписания, а другой для верификации, и результат процесса подписи также называется "электронной подписью" | http://en.wikipedia.org/wiki/Digitalsig-nature |
Электронная подпись (альт.)
(Digital signature) | Любое представление подписи в цифровой форме, включая изображение подписи, сделанной от руки. Аутентификация ввода данных в медицинскую карту, сделанного лицом, осуществляющим ввод | AHIMA, Health Information Management and Technology: Pocket Glossary. Page 74. 2006 |
Распоряжение
(Directive) | Указания по выполнению или действию | ИСО 18308, [Oxford English Dictionary, 2008] |
Каталог
(Directory) | В вычислительной сфере директория, каталог или папка являются сущностью файловой системы, содержащей группу файлов и других каталогов. Стандартная файловая система содержит тысячи файлов, и каталоги помогают организовать их, сохраняя вместе связанные файлы | http://en.wikipedia.org/wiki/Directory |
Запретить доступ
(Disable-Access) | Вместо него используйте "УПРАВЛЯТЬ ДОСТУПОМ для удаления разрешений на использование специальной функциональности и/или управление специальными данными" | Этот глагол устарел в качестве термина иерархии глаголов |
Раскрыть
(Disclose) | Вместо этого использовать ПРЕДСТАВИТЬ (RENDER) и ПОМЕТИТЬ (TAG) предназначение данных "только для раскрытия" | Этот глагол устарел в качестве термина иерархии глаголов |
Управление заболеванием
(Disease management) | Широкий подход к соответствующей координации всего процесса лечения заболевания, который часто предусматривает переход от более дорогой стационарной помощи для лечения острых заболеваний к таким формам, как профилактическая медицина, консультирование и санитарное просвещение пациентов, амбулаторная помощь. Эта концепция включает влияние надлежащей терапии по сравнению с ненадлежащей на общую стоимость и результат лечения конкретного заболевания | http://cancerweb.ncl.ac.uk/cgi-bin/ omd?disease+management |
Дискретный сбор
(Discrete capture) | Сбор отдельной единицы данных | http://www.m-w.com/dictionary/capture |
Дискретные данные
(Discrete data) | Данные, часто группируемые по аналогичным типам значений и подразделяемые на отдельные поля. (По контрасту со свободным текстом.)
Примечание - Поле дискретных данных может содержать свободный текст
|
|
Отпустить (лекарство)
Dispense | Процесс отпуска лекарства начинается после того, как заполнен рецепт/назначение и лекарство становится доступным для применения. Отпуск включает транспортировку лекарств и документальное оформление факта транспортировки.
Примечание - Для отпуска лекарств необходимо, чтобы сначала были заполнены рецепт или назначение.
Примечание - В ФМ СВ ЭМК термин "подобрать и отпустить" (fill) означает сочетание подбора и отпуска лекарства
|
|
Отобразить
(Display) | Вместо него используйте ПРЕДСТАВИТЬ (PRESENT) | Этот глагол устарел в качестве термина иерархии глаголов |
Документ
(Document - существительное) | (существительное): см. "медицинский документ"; (существительное) - запись, передающая информацию | http://www.m-w.com/dictionary/document |
Документировать
(Document - глагол) | Используйте вместо него ВВЕСТИ (ENTER) или ПОМЕТИТЬ (TAG with) с соответствующими ссылками, или СВЯЗАТЬ С (LINK to) источниками | Этот глагол устарел в качестве термина иерархии глаголов |
Документация
(Documentation) | Все "примечания" являются "документацией", но не вся "документация" является "примечаниями". Поэтому должен использоваться более широкий термин "документация", если только "примечания" не используются как подмножество со специальным предназначением. См. "Примечания" |
|
Редактировать
(Edit) | Управлять данными с помощью изменений, усиливающих элемент. Например, владелец учетной записи ПЭМЕ может изменить свои фамилию, имя, отчество с "Джон Джеймс Смит" на "Джон Джеймс (прозвище: ’JJ’) Смит".
ИЗМЕНИТЬ (UPDATE) данные, корректируя, изменяя, дополняя или приращивая их. Например, врач может РЕДАКТИРОВАТЬ (EDIT) домашний адрес пациента, исправляя номер дома на улице Oak Street с 368 на 638. Другой пример: врач может РЕДАКТИРОВАТЬ (EDIT) существующие сведения о травме, добавляя рентгеновский снимок сломанной кости |
|
e.g. (например) | exempli gratia (лат.) Например, включая, не ограничиваясь перечисленным |
|
ЭМК | Электронная медицинская карта (ЭМК) является комплексным, структурированным набором клинических, демографических, экологических, социальных и финансовых данных и информации в электронной форме, документирующим медицинскую помощь, оказанную отдельному лицу | (АСТМ Е 1769, 1995) |
Электронная медицинская карта
(Electronic Health Record) | Информация, относящаяся к благополучию, здоровью отдельного лица и оказанной ему медицинской помощи в машинно-обрабатываемой форме, представленной в соответствии со стандартизованной информационной моделью | ИСО 18308 |
Архитектура электронной медицинской карты
(Electronic Health Record Architecture) | Формальное описание системы компонентов и служб, предназначенной для записи, извлечения и обработки информации, содержащейся в электронных медицинских картах | ИСО 18308 |
Система ведения электронной медицинской карты
Electronic Health Record System | Система компонентов и служб, предназначенная для записи, извлечения и обработки информации в электронных медицинских картах | ИСО 18308, [ИСО/ЕН 13606-1:2008] |
Системы электронных сообщений
(Electronic messaging systems) | Сообщения с определенным источником и одним или несколькими получателями, которые можно просмотреть на компьютере или другом электронном устройстве. Общие примеры включают в себя текстовые сообщения, передаваемые сотовыми телефонами, а также сообщения электронной почты |
|
Электронная консультация (телемедицинская консультация)
Electronic Consult (e-Consult, Teleconsultation) | Организационная практика поставщика медицинской помощи (часто первичной), связанная с запросом совета, толкования и/или рекомендации по решению (о лечении, лекарственных назначениях и т.п.) у другого поставщика (консультанта), часто специалиста, с помощью электронных средств, не требующая личной встречи пациента и специалиста. Она включает передачу демографической и медицинской информации о пациенте, необходимой медицинским специалистам для получения или предоставления экспертного заключения и/или совета в отношении пациента и в идеальном случае сохраняемой в электронной медицинской карте пациента. Консультант (специалист) оценивает и/или интерпретирует информацию и может дать рекомендации по диагностике и лечению. По итогам консультации запрашивающий поставщик медицинской помощи назначает и документально оформляет лекарственные назначения, лабораторные заказы и/или другие услуги. С медицинской и правовой точки зрения запрашивающий поставщик по-прежнему несет ответственность за медицинскую помощь, поэтому ответ этому поставщику является необходимой составляющей процесса телемедицинской консультации, способствующего также профессиональному росту запрашивающего поставщика. Примером может служить семейный врач, запрашивающий телемедицинскую консультацию у дерматолога для получения помощи при оценке и по рекомендованному лечению трудноизлечимого кожного заболевания.
Примечание - Телемедицинская консультация отличается от электронного направления к врачу тем, что при электронной консультации ответственность за пациента несет запрашивающий поставщик.
|
|
Электронное направление (телемедицинское направление)
Electronic Referral (e-Referral, Telereferral) | Организационная практика поставщика медицинской помощи, связанная с запросом совета, толкования и/или рекомендации по решению (о лечении, лекарственных назначениях и т.п.) у другого поставщика ("принимающего" поставщика), обычно специалиста, с помощью электронных средств, не требующая личной встречи пациента и специалиста. Она включает передачу демографической и медицинской информации о пациенте, необходимой медицинским специалистам для получения или предоставления экспертного заключения и/или совета в отношении пациента и в идеальном случае сохраняемой в электронной медицинской карте пациента. Принимающий поставщик медицинской помощи (специалист) оценивает и/или интерпретирует информацию, может дать рекомендации по диагностике и лечению, а также сделать и документально оформить лекарственные назначения, лабораторные заказы и/или другие услуги. Ответственность за медицинскую помощь пациенту переходит к принимающему поставщику, к которому направили пациента. Примером может служить семейный врач, делающий электронное направление (e-referring) пациента к нефрологу для управления (ренальной) медицинской помощью, связанной с проблемами почек пациента. |
|
| Примечание - Электронное направление отличается от телемедицинской консультации тем, что направляющий поставщик уступает управление и ответственность за конкретное состояние пациента принимающему поставщику (но может оставаться ответственным за другие аспекты здоровья пациента)
|
|
Цифровая подпись
Electronic Signature (e-Signature) | Электронный звук, символ или процесс, приложенный или ассоциированный с контрактом или другой записью и используемый в качестве юридического эквивалента письменной подписи.
Электронный звук, символ или процесс, приложенный или логически ассоциированный с контрактом или другой записью и исполненный или принятый лицом с намерением подписать запись.
Подпись, состоящая из одной или нескольких букв, знаков, цифр или других символов в цифровой форме, включенная в электронный документ либо приложенная к нему или ассоциированная с ним | The American Heritage® Dictionary of the English Language, Fourth Edition copyright © 2000 by Houghton Mifflin Company. Updated in 2009. Published by Houghton Mifflin Company.
US "Electronic Signatures In Global and National Commerce Act of 2000", Public Law 106-229, 15 USC 7006, Sec. 106, page 10 at: http://www.gpo.gov/fdsys/pkg/PLAW-106publ229/pdf/ PLAW-106publ229.pdf (по состоянию на 21.02.2013)
Канада: "Personal Information Protection and Electronic Documents Act - S.C. 2000, c.5 (Section 31)", на http://laws-lois.justice.gc.ca/ eng/acts/P-8.6/page-14.html#docCont (по состоянию на 21.02.2013).
См. также:
"European Legislation on eSignature", http://ec.europa.eu/information_society/ policy/esignature/eu_legislation/index_en.htm
"The European Electronic Signature Directive", http://ec.europa.eu/information_society/eeurope/2005/ all_about/security/electronic_sig_report.pdf, страницы 27-30 |
Исключить
(Eliminate) | В зависимости от обстоятельств используйте вместо него УДАЛИТЬ (DELETE) или ОЧИСТИТЬ (PURGE) | Этот глагол устарел в качестве термина иерархии глаголов |
Обращение
(Encounter) | Обращение за медицинской помощью служит основным событием, связывающим клиническую, административную и финансовую информацию. Обращение происходит во многих условиях оказания медицинской помощи - амбулаторная помощь, стационарное лечение, скорая и неотложная помощь, помощь на дому, полевая и виртуальная (телемедицина) | http://www.ncvhs.hhs.gov/040127p1.htm |
Шифровать
(Encrypt) | ХРАНИТЬ (STORE) данные, трансформируя их в форму, которая трудна для понимания неавторизованными людьми или системами. Например, система может ШИФРОВАТЬ (ENCRYPT) чувствительную информацию, к примеру, финансовую информацию пациента |
|
Шифрование
(Encryption) | Эксплуатация данных, сохраняющая их преобразованными в такую форму (шифротекст), которую нелегко понять неавторизованным людям или системам | http://searchsecurity.techtarget.com/ sDefinition/0,,sid14_gci212062,00.html |
Ввести
(Enter) | СОБРАТЬ (CAPTURE) данные, вводя их вручную (например, с клавиатуры), или с помощью других устройств ввода. Например, пользователь может вручную ВВЕСТИ с клавиатуры наименование улицы в адресе пациента. Другой пример: пользователь может ВВЕСТИ вес тела пациента с помощью электронных весов |
|
Корпоративная сеть
(Enterprise) | Общий термин, описывающий очень крупную сеть. Обычно используется в качестве определения сети, состоящей из 500 станций или более | http://www.csgnetwork.com/glossarye.html#enterprise |
Сущность
(Entity) | Нечто существующее отдельно и определенно, в объективной или концептуальной реальности. Нечто существующее в виде конкретной и дискретной единицы.
Организация (коммерческая или государственная), имеющая идентичность, отдельную от ее членов | http://www.m-w.com/cgi-bin/dictionary? book=Dictionary&va=entity |
Сущность
Entity (альт.) | Конкретный или абстрактный предмет интереса, включая ассоциации между предметами | ИСО 18308, [ИСО/МЭК 2382] |
Запись
Entry | Документирование дискретного элемента информации о состоянии здоровья.
Примечание - Запись может представлять собой документацию клинических наблюдений, умозаключений, намерений, плана или действия
| ИСО 18308 |
Событие
(Event) | Что-либо происходящее, или случающееся с пациентом, либо имеющее отношение к пациенту, особенно что-то важное, как, например, инцидент (неблагоприятное событие), процедура или диагноз.
Из модели HL7 RIM: стимул, вызывающий заметные изменения в состоянии объекта, или сигнал, приводящий к изменению поведения объекта |
|
Доказательные ресурсы
Evidence based resources | Доказательная практика - это "добросовестное, точное и продуманное использование наилучшего текущего доказательства при принятии решения о медицинской помощи отдельным пациентам. Практика доказательной медицины означает интеграцию отдельного клинического опыта с наилучшими внешними клиническими доказательствами, полученными в результате систематических исследований" | http://www.fhs.mcmaster.ca/rehab/research/ebr.html |
Обмениваться
(Exchange) |
|
|
Явное согласие
(Explicit consent) | Разрешение, выданное добровольно и явно, выраженное устно или письменно | ИСО 18308 |
Экспортировать
(Export) | Используйте вместо него ПРЕДОСТАВИТЬ (RENDER) | Этот глагол устарел в качестве термина иерархии глаголов |
Предоставляемый внешним источником
(Externally-sourced) | Относится к объекту, собранному вне системы ЭМК пользователя. Примерами объектов, предоставляемых внешними источниками, могут служить: факсимильные сообщения, авторизации направлений, заключения консультантов, результаты лабораторных исследований и эпикризы другой медицинской организации, а также переписка клинического характера между пациентом и ординатором |
|
Извлечь
(Extract) | ПРЕДОСТАВИТЬ (RENDER) данные с помощью позиционирования, извлечения и возможной компоновки данных на основе определенных критериев и определенных целей. Например, система может ИЗВЛЕЧЬ (EXTRACT) для клинициста все результаты рентгеноскопии грудной клетки пациента. Другой пример - система может автоматически ИЗВЛЕЧЬ (EXTRACT) список аллергий, когда врач вводит рецепт. Третий пример: система может ИЗВЛЕЧЬ (EXTRACT) для научного работника ряд случаев, похожих на пневмонию, которые лечили в отделении неотложной помощи в течение определенного периода времени. Еще один пример: система может ИЗВЛЕЧЬ (EXTRACT) и объединять информацию, используя когорту пациентов с пневмококковыми заболеваниями, и разбить ее на категории по специфичным диапазонам возраста |
|
Семейный анамнез
(Family History) | Запись, содержащая информацию о здоровье лица и его ближайших родственниках. Полная запись включает информацию о трех поколениях родственников, включая детей, братьев и сестер, родителей, дядей и теть, племянниц и племянников, бабушек/дедушек, а также двоюродных братьев/сестер. Семьи имеют много общих факторов, включая генетику, окружающую среду и образ жизни. Вместе эти факторы могут внести ясность в медицинские события, которые могут происходить в семье. Выяснив особенности нарушений здоровья родственников, медицинские специалисты могут определить наличие повышенного риска развития конкретного состояния у лица, других членов его семьи или будущих поколений.
Важной частью семейного анамнеза пациента, в ходе которого его спрашивают о состоянии здоровья ближайших родственников, являются ответы на специфичные вопросы, заданные с целью обнаружения любых расстройств, которым пациент может быть подвержен, например: "Болел ли кто-нибудь в вашей семье туберкулезом? Сахарным диабетом? Раком молочной железы?" Наследственным и семейным заболеваниям уделяется особое внимание. Записываются возраст и состояние здоровья каждого лица, возраст на момент смерти и причины смерти. Часто для графического документирования создается генограмма. Семейный анамнез составляется на основе бесед с пациентом или членами семьи при первичном осмотре и становится частью постоянной записи. Другие вопросы, например, относящиеся к возрасту, полу, отношениям совместно проживающих родственников, история супружеской жизни пациента, могут задаваться, если эта информация еще не является защищенной | http://ghr.nlm.nih.gov/handbook/inheritance/familyhistory |
Ускоренная регистрация
(Fast Track) | Процесс ускоренной регистрации пациента. Очень полезен при оказании экстренной помощи и быстрой выписке пациентов с острыми заболеваниями |
|
Внутриутробная смерть
(Foetal Death) | Смерть перед полным отделением или извлечением плода из утробы матери вне зависимости от продолжительности беременности, не вызванная искусственным прерыванием беременности. Свидетельством смерти является тот факт, что после отделения или извлечения плода он не дышит и не показывает иных признаков жизни, например биение сердца, пульсация пуповины или явное движение произвольных мышц. Биения сердца необходимо отличать от транзиторных сокращений сердца; дыхательные движения необходимо отличать от кратковременных дыхательных усилий или удушья |
|
Подобрать и отпустить (лекарственное назначение или рецепт)
Fill | Процесс подбора и отпуска лекарственного назначения начинается после валидации назначения. Процесс включает проверку, постоянную проверку, наличия лекарственных ингредиентов и последующие подготовку, сверку и анализ конечного лекарственного средства. Процесс заканчивается, когда принято решение о том, должно ли быть отпущено лекарство.
Примечание - Лекарственное назначение может быть/не быть отпущено (например, пациент может отказаться от приобретения лекарства).
Примечание - В ФМ СВ ЭМК термин "подобрать и отпустить" (fill) означает сочетание подбора и отпуска лекарства
|
|
Фильтруемый
(Filterable) | Способность программным путем разделить и ограничить данные в виде наборов со специфичными значениями |
|
Сигнализировать
(Flag) | Используйте вместо него "ПРЕДОСТАВИТЬ тревожный сигнал" (RENDER an alert) или ПРЕДСТАВИТЬ тревожный сигнал" (PRESENT an alert) или "ПЕРЕДАТЬ уведомление" (TRANSMIT a notice), если есть намерение предупредить о ситуации (т.е. сигнализировать) | Этот глагол устарел в качестве термина иерархии глаголов |
Временная диаграмма процесса
(Flow sheets) | Сводная информация в табличной форме, организованная для отображения значений переменных по мере их изменения со временем | http://www.centc251.org/Ginfo/Glossary/tcglosf.htm |
Формуляр
(Formulary) | Предпочтительный список лекарственных средств, который обычно ограничивает номенклатуру лекарств, доступных в рамках фармакотерапевтической группы, с целью закупки лекарств, отпуска и/или возмещения затрат. Формуляр может составляться государственным органом, сторонним страховщиком или программой медицинского страхования, организацией. Некоторые организации или программы медицинского страхования предусматривают закрытый (т.e. ограниченный) формуляр, при котором только указанные в нем лекарственные средства могут отпускаться в данной организации или возмещаться по программе медицинского страхования | http://www.hrsa.gov/opa/glossary.htm |
Функция
(Function) | Вычисление, которое берет некоторые аргументы (входные параметры) и возвращает результат. Любая конкретная входная информация обеспечивает тот же самый конечный результат каждый раз. Более строго - отображение каждого элемента предметной области на элемент в определенном диапазоне. Подпрограмма, возвращающая значение |
|
Генерировать
(Generate) | В зависимости от контекста вместо него используйте "ОПРЕДЕЛИТЬ и ХРАНИТЬ" ((DETERMINE and STORE), или "ОПРЕДЕЛИТЬ и ПРЕДСТАВИТЬ" (DETERMINE and PRESENT), или "ОПРЕДЕЛИТЬ и ПРЕДОСТАВИТЬ" (DETERMINE and RENDER) | Этот глагол устарел в качестве термина иерархии глаголов |
Общие назначения
(Generic orders) | Общие назначения лечения |
|
Генотип
(Genotype) | 1. Генетическое строение организма или группы организмов в отличие от внешнего вида.
2. Сочетание аллелей, локализованных в гомологичных хромосомах, определяющее специфичную характеристику или признак | The American Heritage®Science Dictionary, copyright © 2005 издатель - Houghton Mifflin Company. Опубликован Houghton Mifflin Company |
Генетическое нарушение
Genetic Disorder (также Genetic Illness, Inherited Disorder) | Заболевание или состояние, вызванное отсутствием или дефектом гена или хромосомной аберрацией, как в синдроме Дауна | The American Heritage® Science Dictionary, copyright © 2005 издатель - "Houghton Mifflin Company". Опубликован Houghton Mifflin Company |
Предоставить доступ
(Grant-Access) | Используйте вместо него УПРАВЛЯТЬ ДОСТУПОМ (CONTROL ACCESS) | Этот глагол устарел в качестве термина иерархии глаголов |
Руководства
(Guidelines) | Указание или общие сведения по политике или образу действий | http://www.merriamwebster.com/dictionary/guideline |
Гармонизировать
(Harmonize) | ИЗМЕНИТЬ (UPDATE) данные, синхронизируя и согласуя их с другой информацией в системе или с данными другой системы (или систем). Например, система может ГАРМОНИЗИРОВАТЬ (HARMONIZE) новый домашний адрес пациента с данными, хранящимися в системах других медицинских работников или организаций |
|
Медицинская помощь
(Health care) | Мероприятия, услуги или запасы, имеющие отношение к здоровью отдельного лица | ИСО 18308, [ЕН 13940-1:2007] |
Медицинское мероприятие
(Health care activity) | Деятельность (оценки, вмешательство), составляющая медицинскую услугу | ИСО/ТР 12773-1 |
Медицинская услуга
(Health care service) | Услуга, предоставленная с намерением прямо или косвенно улучшить здоровье лица или популяции, которым она предоставлена | ИСО/ТР 12773-1 |
Медицинская информация
(Health information) | Информация о состоянии здоровья лица | ИСО 18308 |
Проблема со здоровьем
(Health issue) | Проблема со здоровьем субъекта медицинской помощи, идентифицированная или названная специфичным участником медицинской помощи | ИСО 18308 |
Участник медицинской помощи
(Health care party) | Организация или лицо, вовлеченные в процесс медицинской помощи | ИСО 18308, [ЕН 13940-1:2007] |
Медицинский специалист
(Health Care Professional) | См. (Health Professional) |
|
Поставщик медицинской помощи
(Health Care Provider) | См. Provider |
|
Нарушение здоровья
(Health Condition) | Аспект здоровья лица или группы, требующий определенного вмешательства.
Примечание - Эти вмешательства могут быть заблаговременными или упреждающими, например укрепление здоровья, оздоровление или профилактика (например, вакцинация).
b) симптомы, проблемы со здоровьем (не диагностированные), диагнозы (известные или предполагаемые), например диабет или физиологические изменения, влияющие на весь организм или на одну или несколько его частей, например доброкачественное позиционное головокружение, и/или влияющие на самочувствие лица, например психоз, и/или на обычное физиологическое состояние лица, например беременность, лактация | ИСО/ТР 12773-1 |
Медицинская информация
(Health Information) | Для целей настоящего стандарта термин "медицинская информация" означает информацию о состоянии здоровья лица (или группы лиц) или информацию о медицинской помощи, оказанной лицу (или группе лиц). Медицинская информация включает в том числе электронную медицинскую карту (ЭМК), утверждение, запись, документ, отчет, примечания, диаграмму, выдержку или метаданные. Вторичная медицинская информация включает в том числе административную, финансовую, клиническую информацию, а также информацию по рабочим процессам и качеству измерений |
|
Мандат на медицинскую помощь
(Health mandate) | Положение, авторизованное субъектом медицинской помощи, уполномоченным представителем субъекта медицинской помощи или уполномоченным органом, определяющее объем и ограничения конкретной роли, назначенной участнику медицинской помощи, и описывающее его обязанности по отношению к этому субъекту при выполнении этой роли | ИСО 18308, [ЕН 13940-1:2007] |
Медицинский специалист
Health Professional | Лицо, которому уполномоченный орган разрешил непосредственное оказание определенных видов медицинской помощи | ИСО/ТР 12773-1 |
Факторы, относящиеся к здоровью
(Health-Related-factors) | Обстоятельства, воздействия, причины или аспекты, влияющие или описывающие способность пациента получать лечение или реагировать на него, либо поддерживать здоровье (включая физические, умственные, социальные, духовные, общественные и/или экономические характеристики). Сильные стороны пациента (положительные факторы) или слабости (отрицательные факторы) могут влиять на медицинскую помощь или выздоровление пациента и могут регистрироваться в ЭМК для поддержки разработки программ медицинского страхования и вариантов лечения (например, страховое покрытие, как правило, положительный фактор) по сравнению с отсутствием работы (как правило, отрицательный фактор). Примеры факторов включают: поддержку со стороны семьи, финансовую поддержку, уровни медицинского страхования, хорошее общее здоровье, статус/тип занятости, доступ к медицинской помощи и уровень образования. Факторы, относящиеся к здоровью, могут быть включены в список проблем пациента (например, амбулаторный статус или зависимости). Примером активной сильной стороны пациента может служить уход студента за старым родителем на каникулах |
|
Скрыть
(Hide) | УПРАВЛЯТЬ ВИДИМОСТЬЮ ДАННЫХ (MANAGE-DATA-VISIBILITY), делая специфичную информацию невидимой, чтобы ее существование обнаруживалось только авторизованными пользователями. Обозреватели записей пациентов не получают признаки существования или отсутствия скрытой информации. Например, система может СКРЫТЬ (HIDE) существование психиатрической записи пациента от всех обозревателей, кроме психиатра пациента.
Примечание - Глагол "раскрыть" (unhide) приемлем для обозначения обратного действия
|
|
Идентификатор
(Identifier) | Информация, используемая для объявления идентичности до потенциального подтверждения соответствующим аутентификатором | ИСО 18308, [ЕНВ 13608-1] |
Идентифицировать
(Identify) | Вместо этого использовать глаголы действия, адаптированные к контексту.
Например, вместо "...уникально идентифицировать пациента..." следовало бы сказать "... ЭКСПЛУАТИРОВАТЬ уникальный идентификатор пациента...". Другой пример: вместо "…помочь идентифицировать пациента..." используйте "…помочь ОПРЕДЕЛИТЬ (DETERMINE) идентичность пациента" | Этот глагол устарел в качестве термина иерархии глаголов |
то есть - i.e. | id est (лат.); другими словами; например |
|
История иммунизации
(Immunization History) | Полный, неполный или частичный список иммунизаций данного пациента.
Примечание - При передаче определенной истории иммунизаций важно указать ее систему отсчета.
Атрибуты времени и организационного охвата необходимы для точного указания протяженности истории. Если эта протяженность указана, то становится довольно просто понять и объединить/согласовать данные об иммунизации; если она не указана, то значение "истории" нельзя определить. Например, получение набора записей об иммунизации, сопровождаемое идентификатором организации и диапазоном дат, укажет лишь то, что предоставлены записи, сделанные этой организацией/предприятием в этом диапазоне дат. Если пациенту делались иммунизации только в этом учреждении или учреждение, хранящее записи об иммунизации, подтверждает, что они содержат полную историю иммунизации пациента, то атрибуты могут быть подняты на уровень "все учреждения" и диапазона "в течение жизни". |
|
| Нужно различать "выполненные иммунизации" (history of immunizations) и "историю иммунизаций" (immunization history). Первое означает/подразумевает хронологическое представление *известных* иммунизаций и по определению является известным и полным. Последнее относится к полному представлению набора всех возможных иммунизаций |
|
Подразумеваемое согласие
(Implied Consent) | Согласие, подразумеваемое на основе знаков, действий или фактов либо бездействия и молчания | ИСО 18308 |
Импортировать
(Import) | СОБРАТЬ (CAPTURE) данные в локальную систему с помощью предварительного доступа к данным из внешнего источника и последующей загрузки и интеграции этих данных в локальной системе. Например, система может ИМПОРТИРОВАТЬ (IMPORT) самые последние данные по испытанию препарата каждую пятницу вечером. Другой пример: пользователь может ИМПОРТИРОВАТЬ (IMPORT) различные наборы хороших практик, относящихся к ювенильному диабету |
|
Включая
(Including) | Указывает минимальный набор значений. Система может поддерживать дополнительные значения, но должна поддерживать те, перечисленные как "включенные" |
|
Указать
(Indicate) | Используйте вместо него ПОМЕТИТЬ (TAG) с соответствующим квалификатором. Синонимы: Affirm, Assert, Declare, Indicate и State | Этот глагол устарел в качестве термина иерархии глаголов |
Справочный функциональный профиль
(Informative functional profile) | Функциональный профиль, для которого успешно завершено тщательное публичное обсуждение в процессе достижения консенсуса, принятого организацией HL7 | Функциональная модель HL7 СВ ЭМК, глава 2 "Требования к соответствию" |
Семантика информации
(Information Semantics) | Семантика информации определяется моделью информации и терминологической моделью. Терминологическая модель может быть ограничена наборами стандартных значений и/или наборами кодов. Например, термины вакцинации могут быть ограничены федеральным правительством. Другой пример: список лекарств может быть ограничен формуляром |
|
Вводить
(Input) | Используйте вместо него СОБРАТЬ (CAPTURE), ВВОДИТЬ (ENTER), ПОЛУЧАТЬ (RECEIVE), ИМПОРТИРОВАТЬ (IMPORT) или АВТОМАТИЧЕСКИ ЗАПОЛНЯТЬ (AUTO-POPULATE) в зависимости от контекста и области применения описываемых действий | Этот глагол устарел в качестве термина иерархии глаголов |
Интегрировать
(Integrate) | ИЗМЕНИТЬ (UPDATE) данные, объединяя их с существующими данными контролируемым способом. Например, пользователь может ИНТЕГРИРОВАТЬ (INTEGRATE) в местную запись пациента сводки медицинской помощи, предоставленной в другой юрисдикции. Другой пример - система может ИНТЕГРИРОВАТЬ (INTEGRATE) приложение единого входа в систему в сервисы аутентификации пользователя, существующие в системе. Еще один пример: система может ИНТЕГРИРОВАТЬ (INTEGRATE) несколько модулей третьих сторон для усиления своих возможностей |
|
Целостность
(Integrity) | Гарантия того, что данные, к которым осуществляется доступ или которые читаются, не были нарушены, изменены или повреждены из-за системной ошибки с момента последнего авторизованного доступа к ним. Состояние программного компонента, который не был намеренно или случайно изменен | ИСО 18308 |
Стандарты обмена данными
(Interchange standards) | Стандарты, по которым совершается обмен информацией, обычно электронными данными. Примером служит Архитектура клинических документов HL7 (Clinical Document Architecture) |
|
RFC 3881 Инженерной рабочей группы Интернета (IETF)
(Internet Engineering Task Force (IETF) RFC 3881) | "Инженерная рабочая группа Интернета является крупным открытым международным сообществом разработчиков сетей, операторов, изготовителей и исследователей, заинтересованных в эволюции архитектуры Интернета и его беспроблемной работе... Она разрабатывает стандарты Интернета в форме запросов комментариев RFC (Request for Comment). RFC 3881 определяет "формат данных и минимальный набор атрибутов, которые должны быть собраны для аудита безопасности в системах медицинских приложений. Формат определяется XML-схемой, предназначенной в качестве справочной для разработчиков стандартов информатизации здоровья и разработчиков приложений. RFC 3881 объединяет несколько предыдущих документов по аудиту безопасности медицинских данных" | http://www.ietf.org/about/
http://tools.ietf.org/html/rfc3881 |
Взаимодействовать
(Interoperate) | Координировать информацию, сервисы и/или функциональность между системами |
|
Интерпретация
(Interpretation) | Понимать в свете личного мнения, суждения или обстоятельств | http://www.merriamwebster.com/dictionary/interpreting |
Вмешательство
(Intervention) | Действие, или факт вмешательства с целью модификации.
А именно любая мера с целью улучшить здоровье или изменить течение заболевания | http://www.mercksource.com/pp/us/ cns/cns_hl_dorlands. jspzQzpgzEzz SzppdocszSzuszSzcommonzSzdor landszSzdorlandzSzdmd_i_10zPzh tm#12456410 |
Механизм ввода
(Input mechanism) | Подход, в котором, как правило, используется устройство взаимодействия с пользователем, предназначенное для ввода данных. Примерами служат клавиатура и мышь |
|
Непереносимость
(Intolerance) | Не иммунологическая нежелательная физиологическая чувствительность к субстанции. Она может проявляться неспособностью выносить, выдерживать, усваивать или метаболизировать субстанцию (например, лактозу) |
|
Проблема
(Issue) | См. "Problem" |
|
Маркировать Label (глагол) | Использовать ПОМЕТИТЬ (TAG) | Этот глагол устарел в качестве термина иерархии глаголов |
Юридически признаваемый
(Legal-Hold) | Примечание - Система не может хранить различные юридические признаваемые факты. Скорее, система может предоставить возможность пометить определенные данные, которые могут понадобиться в судебном разбирательстве
|
|
Связать
(Link) | ИЗМЕНИТЬ (UPDATE) данные, ассоциируя один элемент данных с другим элементом данных. Например, система может СВЯЗАТЬ (LINK) запись о посещении пациента с результатами лабораторных исследований пациента. Другой пример: система может СВЯЗАТЬ (LINK) аттестованные изменения в записи пациента с информацией, идентифицирующей автора |
|
Вести журнал
Log (глагол) | ПРОСЛЕЖИВАТЬ (TRACE) мероприятия, инициированные системой или пользователем (включая доступ к данным и/или функциональность, попытки доступа к данным и/или функциональности, действия, выполненные с данными и/или функциональностью, а также изменения характеристик системы или версии), с помощью хранения хронологического следа этих действий. Например, система может ВЕСТИ ЖУРНАЛ (LOG) фактов выполнения модификаций записи пациента, сохраняя дату, время, идентификатор пользователя, модифицировавшего запись, а также сведения об изменениях, сделанных в записи. Другой пример: система может ВЕСТИ ЖУРНАЛ (LOG) фактов обновлений базы данных по межлекарственному взаимодействию, сохраняя дату и время обновления |
|
Логическая запись
(Logical Record) | Ссылка на запись данных, не зависящая от их физического местонахождения. Логическая запись может физически храниться в двух и более местах |
|
Эксплуатировать
(Maintain) | УПРАВЛЯТЬ (MANAGE) данными с помощью хранения, изменения и/или удаления данных в системе. Например, система может предоставить возможность клиницисту ЭКСПЛУАТИРОВАТЬ (MAINTAIN) данные, сохраняя или удаляя их. Другой пример: система может предоставить возможность клиницисту ЭКСПЛУАТИРОВАТЬ (MAINTAIN) данные с помощью коррекции или аннотаций |
|
Эксплуатация
(Maintenance) | Действие, связанное с эксплуатацией, либо эксплуатируемое состояние.
Усилия по поддержанию чего-либо в надлежащем состоянии; содержание в исправности | http://www.bartleby.com/61/56/M0045600.html |
Эксплуатация и контроль версий (используется как фраза)
(Maintenance and versioning) | Управление многочисленными пересмотрами одной и той же единицы информации | http://en.wikipedia.org/wiki/Versioning |
Управлять (данными)
Manage (Data) | Обрабатывать данные, собирая, эксплуатируя и предоставляя их, определяя действия с данными и управляя их видимостью. Например, система может обеспечить пользователю возможность УПРАВЛЯТЬ (MANAGE) предпочтениями пациента и семьи, относящимися к текущим планам ведения. Другой пример: система клинициста может предоставить ему возможность УПРАВЛЯТЬ (MANAGE) данными пациента, создавая запись пациента, изменяя клинические комментарии, используя инструменты поддержки принятия клинических решений, передавая информацию о счетах пациента на оплату лечения |
|
Управлять видимостью данных
(Manage-Data-Visibility) | УПРАВЛЯТЬ (MANAGE) данными с помощью деидентификации/восстановления идентификации, маскирования/демаскирования или скрытия/раскрытия данных. Например, система может предоставить администратору возможность УПРАВЛЯТЬ ВИДИМОСТЬЮ ДАННЫХ (MANAGE-DATA-VISIBILITY) в терминах, кому разрешено просматривать специфичные данные пациента |
|
Управление
(Management) | Действие, или искусство управления. Проведение чего-либо или руководство чем-либо | http://www.merriamwebster.com/dictionary/management |
Маскировать
(Mask - глагол) | УПРАВЛЯТЬ (MANAGE) данными с помощью деидентификации/восстановления идентификации, маскирования/демаскирования или скрытия/раскрытия данных. Например, система может предоставить администратору возможность УПРАВЛЯТЬ ВИДИМОСТЬЮ ДАННЫХ (MANAGE-DATA-VISIBILITY) в терминах, кому разрешено просматривать специфичные данные пациента.
Примечание - Глагол "демаскировать" является приемлемым для обозначения действия, обратного маскировке
|
|
Маскировка
(Masking) | Маскировка данных представляет собой процесс затушевывания (маскирования) определенных элементов данных в хранилищах данных. Оно обеспечивает замену чувствительных данных реалистичными, но не реальными данными. Цель состоит в том, чтобы чувствительная информация потребителя не стала доступной вне авторизованного окружения. Эффективное маскирование данных предусматривает изменение данных таким образом, чтобы действительные значения не могли быть определены или восстановлены, при этом функциональное представление сохраняется, так что возможно эффективное тестирование | Википедия |
МОЖЕТ
(MAY) | Указывает на необязательное, допустимое действие. Синоним "is permitted" (разрешено) | Функциональная модель HL7 СВ ЭМК, глава 2 "Требования к соответствию" |
Медицинский
(Medical) | Относится к обучению или практике в области медицины; "медицинская профессия"; "студент-медик"; "медицинская школа" | http://wordnet.princeton.edu/perl/webwn?s=medical |
Согласование лекарственных назначений
(Medication reconciliation) | Согласование лекарственных назначений представляет собой комплексную оценку режимов приема лекарств пациентом, осуществляемую при каждом изменении терапии, чтобы исключить ошибки применения лекарств (например, пропуски назначений, дублирование, неправильная дозировка или взаимодействие лекарств) и контролировать соблюдение приема лекарств пациентом и его соответствие принятым нормам. По возможности процесс согласования лекарственных назначений должен включать в себя сопоставление текущих и предшествующих режимов приема лекарств и выполняться при каждом изменении медицинской помощи, при котором назначаются новые лекарства, изменяются или корректируются действующие назначения, а также в тех случаях, когда пациент добавил безрецептурные лекарства для самолечения | ImprovingCareTransitions:Optimizing MedicationReconciliation.March2012. AmericanPharmacistsAssociationandthe AmericanSocietyofHealthSystemsPharmacists.See: http://www.ashp.org/DocLibrary/Policy/PatientSafety/ Optimizing-Med-Reconciliation.aspx |
Объединить
(Merge) | Используйте вместо него ИНТЕГРИРОВАТЬ (INTEGRATE) | Этот глагол устарел в качестве термина иерархии глаголов |
Стандарт передачи сообщений
(Messaging standard) | В контексте медицинских информационных технологий стандарт передачи сообщений определяет структуру или формат электронного обмена данными, позволяющего разнородным медицинским приложениям обмениваться ключевыми наборами клинических и административных данных.
"Стандарт передачи сообщений HL7 Version 2.x (V2) является рабочей "лошадкой" электронного обмена данными в предметной области медицинских информационных систем и, вероятно, наиболее распространенным реализованным стандартом в мировом здравоохранении. Он позволяет системам обмениваться медицинскими данными. Этот стандарт рассчитан на поддержку центральной медицинской информационной системы, а также на более распределенную среду, в которой данные хранятся в системах отдельных подразделений" | 1. http://www.hl7.org/implement/ standards/product_brief.cfm?product_ id=146 (по состоянию на 5 июня 2013 г.) |
Метаданные
(Metadata) | Данные о данных; более конкретно, данные, предоставляющие больше информации об элементе или наборе данных | US Department of Health and Human Services, Office of the Secretary, 45CFR Part 170, Metadata Standards to Support Nationwide Health Information Exchange, page 1, August 9, 2011 |
Изменить доступ
(Modify Access) | Вместо этого используйте "УПРАВЛЯТЬ данными о разрешениях" | Этот глагол устарел в качестве термина иерархии глаголов |
Неоспоримость
(Non-repudiation) | Гарантия того, что входные данные или сообщение пришли от конкретного лица. Стороне будет трудно отказаться от содержания записи или факта его создания | http://www.ahima.org/infocenter/ guidelines/ltcs/5.1.asp |
Записи
(Notes) | Правила именования в настоящем документе применимы лишь к "клиническим записям". В настоящем документе термин "клинические записи" имеет специальное значение. Для целей настоящего документа клиническая запись является клиническим документом (определенным в стандарте HL7 CDA), созданным медицинскими специалистами и обучающимися либо спонтанно (например, "я пишу мою запись о поступлении пациента"), или в ответ на запрос о консультации... Их надо отличать от таких документов, как результаты лучевых исследований, гистологических исследований, лабораторных тестов, протоколов катетеризации сердца и т.п., которые составляются в ответ на назначение конкретной процедуры. Имена большинства этих документов хорошо адаптированы со структурами именования клинических документов в системе кодов LOINC и уже хорошо охвачены терминами, содержащимися в базе данных LOINC | http://www.regenstrief.org/loinc/ discussion/Clinical/ontology.doc |
Уведомление
(Notice) | Уведомление, тревожное сообщение или напоминание. Информация, представленная или переданная заинтересованной стороне. Например, тревожное сообщение, напоминание, извещение или сообщение может нести объявление, предупреждение, описание проблемы или нового состояния/условия.
Примечание - Использование указанных терминов может иметь разное юридическое значение в разных сферах применения
|
|
Извещение
(Notification) | Тип уведомления (Notice), которое не обязательно требует от получателя каких-либо действий |
|
Уведомить
(Notify) | Используйте вместо него ПРЕДОСТАВИТЬ (RENDER), ПРЕДСТАВИТЬ (PRESENT) или ПЕРЕДАТЬ (TRANSMIT) уведомление лицу или в другую систему (включая устройство) | Этот глагол устарел в качестве термина иерархии глаголов |
Аннулировать
(Nullify) | Используйте вместо него "ПОМЕТИТЬ как аннулированное" (TAG as nullified) | Этот глагол устарел в качестве термина иерархии глаголов |
Запутывание кода
(Obfuscation) | В программировании нередко практикуется процесс запутывания кода, чтобы он стал непонятным кому-либо еще. Это делается намеренно, чтобы ввести в заблуждение или запутать. Термин "запутывание кода" часто используется в проблемах с вирусами | http://www.csgnetwork.com/glossaryo.html |
Устареть (глагол)
Obsolete | Используйте вместо него "ПОМЕТИТЬ как устаревшее" (TAG as obsolete) | Этот глагол устарел в качестве термина иерархии глаголов |
По требованию
(On-demand) | Ручной вызов функциональности определенной системы. Например, проверка межлекарственного взаимодействия может произойти автоматически в тот момент, когда клиницист назначает определенное лекарство. Однако клиницисту может также потребоваться исследование взаимодействия с лекарством, ранее назначенным другим врачом; в этом случае он вызовет функцию проверки межлекарственного взаимодействия "по требованию". Другой пример: клиницисту может потребоваться просмотр тревожных сообщений и уведомлений, выдаваемых для определенного набора лекарств (не подразумевая конкретного пациента) |
|
Назначить
(Order - глагол) | Используйте вместо него "ВВЕСТИ параметры назначения" | Этот глагол устарел в качестве термина иерархии глаголов |
Комплексы назначений
(Order sets) | Комплексы назначений готовятся для этапов (назначений) как междисциплинарные шаблоны, в состав которых включаются сестринский уход, медицинские, аптечные и вспомогательные мероприятия. Комплексы назначений согласуются профессиональными сервисными организациями и организуются в форме проблемно-ориентированных планов лечения, в которых каждый комплекс назначений служит для организации одного этапа/фазы общего плана лечения. Кодирование проблем и этапов в комплексах назначений гарантирует применение комплексов в релевантных клинических контекстах и планах лечения и обеспечивает возможность объединения этапов назначений, если к одному пациенту применимы несколько клинических руководств | HL7 Clinical Decision Support team, Jim McClay, SAGE guideline consortium, University of Nebraska Medical Center |
Организация
(Organization) | Уникальная система полномочий, в рамках которой лицо или лица действуют или назначены действовать с какой-либо целью | ИСО 18308, [ИСО/МЭК 6523-1:1998] |
Другая система
(Other system) | Отдельная система, которая является подчиненной, федеративной, интегрированной или партнерской системой |
|
Пациент
(Patient) | Лицо, страдающее заболеванием или нарушением поведения и проходящее соответствующее лечение | http://216.251.232.159/semdweb/ internetsomd/ASP/1549985.asp |
Предпочтения пациента и его семьи
(Patient and family preferences) | Выбор вариантов медицинской помощи, на который в том числе влияют язык, религиозные или культурные предпочтения пациента и его семьи |
|
Идентификатор пациента
(Patient identifier) | Набор данных, используемый, чтобы однозначно отличить одного пациента от другого |
|
Запись пациента
(Patient record) | Бумажное или электронное средство сбора и хранения информации о медицинской помощи, оказываемой пациенту | Health Information Management Technology: An Applied Approach. Merida L. Johns, PhD, RHIA, Editor, AHIMA, Chicago, IL, 2007 |
Представитель пациента
(Patient representative) | Лицо, назначенное для осуществления полномочий пациента; действующее в интересах пациента, например опекун, юридический представитель, заместитель или адвокат | http://cancerweb.ncl.ac.uk/cgi-bin/omd?representative |
Данные уровня пациента
(Patient-level data) | В контексте здоровья населения термин "данные уровня пациента" относится к данным, собираемым (и анализируемым) об одном пациенте. Например, "Лицо 123 - левша". (Примечание - В контексте здоровья населения данные уровня пациента часто деидентифицируются.) Далее, данные об одном пациенте могут иногда агрегироваться в пределах сведений об этом пациенте. Например, "Лицо 123 было беременным 6 раз". Сравните с "данными агрегированного уровня" |
|
Данные, исходящие от пациента
(Patient-originated data) | Данные, предоставленные и/или введенные пациентом. Например, конкретный пациент (или его представитель) может предоставить/ввести информацию о состоянии здоровья по памяти и/или используя информацию, записанную на листке бумаги. Например, пациент может ввести "1970-12-29" в поле даты рождения |
|
Разрешение (родительское)
Permission (Parental) | Разрешение родителей является подтверждением или согласием родителя или опекуна пациента на проведение медицинского мероприятия. "Американская академия педиатрии полагает, что в большинстве случаев врачи несут этические (и юридические) обязательства по получению разрешения от родителей на выполнение рекомендуемых медицинских вмешательств. Во многих случаях, если возраст позволяет, врачи должны также запрашивать санкцию пациента (см. Санкция [пациента]). В случаях совершеннолетних или зрелых несовершеннолетних детей с адекватной способностью принятия решений или когда иное разрешено законом, врачам следует запрашивать информированное согласие (см. Согласие [информированное]) непосредственно у пациентов" | "Informed Consent, Parental Permission, and Assent in Pediatric Practice", Paediatrics Vol. 95 No. 2 February 1, 1995 (re-affirmed May 2011), pp.314-317, American Academy of Paediatrics, Committee on Bioethics, at: http://pediatrics.aappublications.org/content/95/2/314.abstract (доступ 06.02.2013) |
Разрешать доступ (устаревшее словосочетание)
Permit Access | Используйте вместо него "АУТЕНТИФИЦИРОВАТЬ пользователя и АВТОРИЗОВАТЬ доступ на основе разрешений, предоставленных пользователю" | Этот глагол устарел в качестве термина иерархии глаголов |
Сохраняться
(Persist) | Используйте вместо него ХРАНИТЬ (STORE) | Этот глагол устарел в качестве термина иерархии глаголов |
Персональная медицинская карта
(Personal health record) | Медицинская карта, или часть медицинской карты, которую контролирует субъект медицинской помощи или его законный представитель | ИСО 18308 |
Фенотип
(Phenotype) | Внешний вид организма в отличие от генетического строения. Фенотип организма зависит от доминантных генов и взаимодействия генов с окружающей средой | The American Heritage® Science Dictionary Copyright © 2005 by Houghton Mifflin Company |
Политика (управление привилегиями и контроль доступа)
(Policy) | Совокупность юридических, политических, организационных, функциональных и технических обязательств по общению и сотрудничеству | ИСО 18308, [ИСО 22600-1:2014] |
Здоровье населения
(Population Health) | Набор понятий, относящихся к здоровью (например, показатели здоровья), которые более присущи группам, а не отдельным лицам. Группы здоровья населения часто различаются в зависимости от интересов анализирующих организаций, например по географическим признакам, занятости, социальным и экономическим аспектам, возрасту или родству |
|
Практическое руководство
(Practice guidelines) | Систематически разрабатываемые положения по стандартизации медицинской помощи и содействию принятия решений врачом и пациентом о медицинской помощи, подходящей для конкретных обстоятельств. Практические руководства, как правило, разрабатываются с помощью процесса, объединяющего научные доказательства эффективности и экспертное мнение. Практические руководства также называются клиническими критериями, протоколами, алгоритмами, критериями анализа и руководствами | www.mentalhealth.samhsa.gov/ publications/allpubs/MC98-70/default.asp |
Представить
(Present) | ПРЕДОСТАВИТЬ (RENDER) данные, доставляя их местным пользователям содержательным и надлежащим образом. Например, система может ПРЕДСТАВИТЬ (PRESENT) врачу (по ручному запросу) список пациентов, которым сегодня назначен прием, упорядоченный по времени дня, с известными диагнозами пациентов в предпочтительных врачу терминах на выбранном языке. Другой пример: система может автоматически ПРЕДСТАВИТЬ (PRESENT) сигнал тревоги после получения нового результата лабораторного анализа, выходящего за пределы нормы. Другой пример: система может ПРЕДСТАВИТЬ (PRESENT) врачу звуки легочного дыхания пациента. Еще один пример: система может ПРЕДСТАВИТЬ (PRESENT) пациенту указания с использованием аудио- и видеосистемы. |
|
| Примечание - Разумно предположить, что любые представленные данные должны быть соответствующим образом отформатированы, отфильтрованы, переведены, преобразованы, отображены и/или нормализованы и т.п.
|
|
Профилактика
(Prevention) | Действия, предпринятые для снижения восприимчивости или подверженности проблемам со здоровьем (первичная профилактика) обнаружение и лечение заболеваний на ранних стадиях (вторичная профилактика) или смягчение последствий заболевания и травмы (третичная профилактика) | http://depts.washington.edu/hsic/ resource/glossary.html |
Главный
(Principal - прилагательное) | Высший по рангу, полномочиям, характеру, важности, или степени; наиболее значительный или важный; главный; как высшие государственные чиновники; главные люди государства; основная продукция государства; основные аргументы в случае заболевания (например, основной диагноз) | http://cancerweb.ncl.ac.uk/cgibin/omd?principal |
Принципал
(Principal - существительное) | Пользователь, организация, устройство, приложение, компонент или объект. Лицо, юридически ответственное в первую очередь или в конечном итоге | http://www.meriam-webster.com/ cgibin/dictionary/principal |
Основной поставщик медицинской помощи
(Principal provider) | Лицо, которое несет наибольшую ответственность за управление или координацию действий медицинской бригады, оказывающей медицинскую помощь отдельному лицу |
|
Принцип
(Principle) | Принятое или открыто признаваемое правило поведения, принятое правило или метод применения действия | Dictionary.com |
Печатать
(Print) | В зависимости от контекста используйте вместо него ПРЕДОСТАВИТЬ (RENDER), ПРЕДСТАВИТЬ (PRESENT) или ПЕРЕДАТЬ (TRANSMIT) | Этот глагол устарел в качестве термина иерархии глаголов |
Определить приоритет
(Prioritize) | Используйте вместо него "ПОМЕТИТЬ уровнем приоритетности" или "ОПРЕДЕЛИТЬ приоритеты" | Этот глагол устарел в качестве термина иерархии глаголов |
Неприкосновенность личной жизни
(Privacy) | Качество или состояние, скрываемое либо не затрагиваемое наблюдениями или действиями других лиц, или свобода от неразрешенного вторжения. В контексте медобслуживания право пациента контролировать раскрытие защищенной информации о состоянии здоровья | AHIMA Master Glossary, 3  Edition |
Проблема
(Problem) | Сущность, для которой выполнена оценка или инициирован план вмешательства.
Примечание - Во многих связанных со здоровьем профессиях, особенно в социальных и психологических дисциплинах, вместо термина "problem" часто используется термин "issue". Кроме того, при описании состояния беременности и других, не являющихся болезнью, состояний здоровья, которые тем не менее требуют обращения к системе здравоохранения, иногда используется термин "condition" (состояние) | ИСО/ТР 12773-1 |
Список проблем
(Problem list) | Список проблем указанного лица может быть описан, используя формализованные системы кодирования диагнозов (например, DRG, NANDA Nursing Diagnosis, ICD9, DSM и т.п.) или другие профессиональные описания вопросов медицинской помощи, затрагивающих отдельное лицо. Проблемы могут быть кратковременными/длительными, хроническими или острыми и иметь статус. В долговременной медицинской карте все проблемы могут быть важными с точки зрения всей длительной медицинской помощи отдельному лицу и могут регулярно менять статус. Проблемы выявляются в ходе посещений пациента и могут охватывать несколько посещений, обращений или эпизодов медицинской помощи | HL7 Version 3.0 Edition 2006 Glossary |
Профиль
(Profile) | Подмножество функциональной модели, в котором обозначены функции (иногда в разной степени детализаций) для определенных реализаций СВ ЭМК или условий оказания медицинской помощи | Функциональная модель HL7 СВ ЭМК, глава 2 "Требования к соответствию" |
Протокол
(Protocol) | Набор инструкций, описывающих процедуру, применяемую при исследовании конкретного комплекса обследований пациента, или метод, применяемый для управления течением конкретного заболевания. См. алгоритм, план ведения, параметр практики | http://www.coiera.com/glossary.htm |
Обеспечить кому-либо возможность ...
(Provide the ability to ...) | Термин "…обеспечить кому-либо возможность..." означает, что соответствующая функциональность системы даст пользователю возможность выполнить определенную задачу, а не сама ее выполнит (т.e. без вмешательства пользователя).
Дополнительный аспект: система ведения ЭМК не всегда может быть в состоянии правильно выполнить конкретное действие автоматически. Рассмотрите различия между следующими критериями: "Система ДОЛЖНА СВЯЗАТЬ запись с одним пациентом" и "система ДОЛЖНА ОБЕСПЕЧИТЬ ВОЗМОЖНОСТЬ СВЯЗАТЬ запись с одним пациентом".
Первый критерий требует, чтобы система выполнила задачу идентификации пациента и связывания определенной записи с этим пациентом. В этом случае система может оказаться не способной выполнить задачу на приемлемом уровне гарантий (например, если пациентка использует два разных написания своего имени - Liz и Elizabeth).
Второй критерий требует, чтобы система обеспечила пользователю возможность однозначно идентифицировать пациента и связать определенную запись с этим пациентом (например, с помощью представления на экране списка потенциально совпадающих пациентов, из которого пользователь может вручную выбрать правильного пациента для связи с записью) |
|
Предоставить доступ
(Provide access to) | В зависимости от контекста используйте вместо него КОНТРОЛИРОВАТЬ ДОСТУП (CONTROL ACCESS) или ПРЕДСТАВИТЬ (PRESENT) | Этот глагол устарел в качестве термина иерархии глаголов |
Поставщик медицинской помощи
(Provider) | Лицо или организация, участвующие в оказании медицинской помощи субъекту либо ассоциируемые с ней | ИСО/ТР 12773-1 |
Псевдонимизировать
(Pseudonymize) | Присвоить альтернативный идентификатор содержанию записи ЭМК или ее данным. Псевдонимизация позволяет источнику или авторизованному субъекту восстановить прежнюю идентификацию данных. Согласно Википедии: "псевдонимизация" - это процедура, с помощью которой наиболее идентифицирующие поля записи данных заменяются одним или несколькими искусственными идентификаторами. Можно заменить коллекцию полей одним псевдонимом или же использовать отдельные псевдонимы для каждого ее поля. Цель псевдонимизации - сделать запись данных менее идентифицируемой и смягчить возражения потребителя или пациента на ее использование. Данные в этой форме пригодны для масштабного анализа и обработки |
|
Общественное здоровье
(Public Health) | 1. Сфера здравоохранения, имеющая дело со здоровьем населения в геополитических образованиях, например штаты и страны.
2. Область медицины, относящаяся к охране и улучшению здоровья общества в целом | 1. Pocket Glossary for Health Information Management and Technology, Second Edition, 2010
2. Dorland’s Medical Dictionary |
Очистить
(Purge) | УСТРАНИТЬ (REMOVE) данные, делая их невосстанавливаемыми в хранилище и/или на носителе данных. Например, система может ОЧИСТИТЬ (PURGE) запись пациента Джона Смита в соответствии с правилом, выделяющим все записи старше семи лет. (Примечание - Destroy и Purge - синонимы, предпочтительней английский термин - PURGE) |
|
Запросить
(Query) | Используйте вместо него АНАЛИЗИРОВАТЬ (ANALYSE) или ПРЕДОСТАВИТЬ (RENDER) (либо его дочерние глаголы действия), поскольку запросы или поиски подразумевают предоставление или анализ данных | Этот глагол устарел в качестве термина иерархии глаголов |
Активировать заново
(Reactivate) | Используйте вместо него ПОМЕТИТЬ (TAG) с соответствующим квалификатором.
Потребность заново активировать конкретную информацию возникает, если ее данные устарели или были деактивированы, а затем стали действительными снова. Например, специалист по управлению медицинской информацией может захотеть ПОМЕТИТЬ (TAG) определенный клинический термин как "активированный заново" |
|
В реальном времени
(Real-time) | Поскольку понятие "в реальном времени" неоднозначное, опишите фактическое событие. Например: "Представить уведомление о взаимодействии лекарств в реальном времени" лучше заменить на "Представить уведомление о взаимодействии лекарств в момент назначения лекарства" |
|
Получить
(Receive) | СОБРАТЬ (CAPTURE) данные из внешнего источника, получая их без ручного/оперативного вмешательства пользователя. Например, система может ПОЛУЧИТЬ (RECEIVE) различные электронные письма, адресованные клиницисту, который просмотрит их позже. Другой пример: система может ПОЛУЧИТЬ (RECEIVE) от аутентифицированных и авторизованных внешних систем результаты лабораторных исследований определенного пациента. Еще один пример: система может ПОЛУЧИТЬ (RECEIVE) факсимильное сообщение от внешнего устройства |
|
Согласовать
(Reconcile) | В зависимости от контекста и смысла используйте вместо него АНАЛИЗИРОВАТЬ (ANALYSE) и РЕШИТЬ (DECIDE), или ОПРЕДЕЛИТЬ (DETERMINE), или ГАРМОНИЗИРОВАТЬ (HARMONIZE) | Этот глагол устарел в качестве термина иерархии глаголов |
Запись
(Record - существительное) | Информация, созданная, полученная и эксплуатируемая в качестве доказательства, а также информация об организации или лице во исполнение юридических обязательств или деловой транзакции | ИСО/ТР 12773-1 |
Записать
(Record - глагол) | Используйте вместо него ХРАНИТЬ (STORE) (или его дочерние глаголы действия) | Этот глагол устарел в качестве термина иерархии глаголов |
Регистрационная запись
(Record entry) | Данные, собранные системой. Создание регистрационной записи выполняется с помощью ввода или автоматического заполнения данных, импорта или получения данных системой. Система ведения ЭМК собирает информацию о предпринятых действиях и создает соответствующие регистрационные записи. Такие записи обеспечивают неизменные доказательства состоявшегося действия, контекста, распоряжений, фактов, заключений и наблюдений. От момента появления регистрационной записи до конца ее жизни система ведения ЭМК управляет ею в соответствии с областью практики, политикой организации или законодательством. Действующие лица и выполняемые ими действия, обеспечивающие здоровье отдельных лиц и оказание им медицинской помощи, регистрируются соответствующим образом в ЭМК, (т.e. экземпляры действий документально оформляются в виде экземпляров регистрационных записей). | ИСО/ТР 21089, раздел 12 |
| Регистрационные записи могут быть созданы в процессе действия или позже. Действующее лицо (автор/источник) регистрационной записи может совпадать или не совпадать с действующим лицом, выполняющим действие. Функциональная модель системы ведения ЭМК не указывает конкретные отношения между действиями и соответствующими регистрационными записями. Они могут иметь кратность "один к одному", "многие к одному" или даже "один ко многим" |
|
Восстановить
(Recover) | ХРАНИТЬ (STORE) данные, восстанавливая их исходные значения из резервных копий. Например, после поломки жесткого диска система может ВОССТАНОВИТЬ (RECOVER) данные за последнюю неделю, используя резервную внешнюю копию (см. РЕЗЕРВИРОВАТЬ) |
|
Реестр
(Registry) | Письменная, официальная или формальная запись информации либо место хранения этих записей | http://en.wikipedia.org/wiki/Registry |
Повторно идентифицировать
(Re-identify) | УПРАВЛЯТЬ ВИДИМОСТЬЮ ДАННЫХ (MANAGE-DATA-VISIBILITY), объединяя данные таким образом, чтобы идентичность пациента была восстановлена в соответствии с областью практики, политикой организации и/или действующим законодательством. Например, система может ПОВТОРНО ИДЕНТИФИЦИРОВАТЬ (RE-IDENTIFY) деидентифицированные данные, предоставляя ключ, позволяющий авторизованным пользователям повторно установить связь между данным пациентом и деидентифицированными данными этого пациента |
|
Отклонить
(Reject) | Используйте вместо него "ПРЕДСТАВИТЬ или ПРЕДОСТАВИТЬ сообщение об отклонении" или "ПОМЕТИТЬ как отклоненное" | Этот глагол устарел в качестве термина иерархии глаголов |
Напоминание
(Reminder) | Тип извещения, предназначенный для напоминания получателю информации, которую он мог получить ранее (например, напоминание о назначенном посещении). Отличается от тревожного сообщения, требующего немедленные действия или сообщающего, что действие противопоказано (например, применение антибиотиков) |
|
Устранить
(Remove) | ЭКСПЛУАТИРОВАТЬ (MAINTAIN) данные, делая их недоступными, или невосстанавливаемыми в соответствии с областью практики, политикой организации и/или действующим законодательством. Например, по запросу врача система может путем очистки УСТРАНИТЬ (REMOVE) ошибочно полученную информацию о пациенте. Другой пример: система может по запросу администратора УСТРАНИТЬ (REMOVE) путем удаления расписание часов амбулаторного приема пациентов в клинике.
|
|
| Примечание 1 - Данные могут быть удалены с помощью удаления из каталога указателя на эти данные или с помощью перезаписи, после которой исходные данные становятся невосстанавливаемыми.
|
|
| Примечание 2 - В случае, если данные стали недействительными, но должны оставаться в системе, слово ПОМЕТИТЬ (TAG) является предпочтительным по сравнению со словами УСТРАНИТЬ (REMOVE) или "аннулировать". Этот тип действия рассматривается как процесс "пометки данных", а не "удаления данных". Например, специалист по управлению медицинской информацией может пожелать ПОМЕТИТЬ (TAG) определенный клинический термин как устаревший, но оставить его в системе в целях обратной совместимости
|
|
Предоставить
(Render) | УПРАВЛЯТЬ (MANAGE) данными, извлекая, представляя и/или передавая данные пользователям или системам. Например, система может ПРЕДОСТАВИТЬ (RENDER) результаты лабораторных исследований, представляя их на экране компьютера. Другой пример: система может ПРЕДОСТАВИТЬ (RENDER) данные, передав аптеке рецепт на лекарство |
|
Заменить
(Replace) | В зависимости от контекста используйте вместо него РЕДАКТИРОВАТЬ (EDIT), или "УДАЛИТЬ старый и СОХРАНИТЬ новый", или "ПОМЕТИТЬ как устаревший и СОХРАНИТЬ новый" | Этот глагол устарел в качестве термина иерархии глаголов |
Отчет
(Report - существительное) | Набор фактов и рисунки, которые могут быть напечатаны, подробно описывающие событие, ситуацию или что-либо подобное, как правило, результат наблюдений, запросов и т.п.; например, медицинская информация о пациенте, которая может быть напечатана |
|
Выдать отчет
(Report - глагол) | Используйте вместо него "ПРЕДОСТАВИТЬ отчет" или "ПРЕДСТАВИТЬ отчет" | Этот глагол устарел в качестве термина иерархии глаголов |
Оспорить
(Repudiate) | Используйте вместо него "ПОМЕТИТЬ как оспоренный или отклоненный" | Этот глагол устарел в качестве термина иерархии глаголов |
Оспаривание
(Repudiation) | Оспаривание пользователем или системой того факта, что они были источником определенной информации, либо отправителем или получателем сообщения, либо автором действия, запрошенного от системы.
Примечание в отношении неоспоримости: как правило, системы помогают предотвратить факт отрицания пользователем действий, собирая электронную подпись, активируя сервис подтверждения и добавляя метки времени |
|
Использование ресурсов
(Resource utilization) | Измерение эффективности использования ресурсов |
|
Восстановить
(Restore) | ХРАНИТЬ (STORE) данные в производственной системе, используя архивированные перед этим данные. Например, система может ВОЗВРАТИТЬ (RESTORE) данные об обращении пациента для вернувшегося пациента, чьи данные были архивированы из-за неактивности. Другой пример: система может ВОЗВРАТИТЬ (RESTORE) для расследования данные пациента, архивированные после его смерти (см. АРХИВИРОВАТЬ) |
|
Результат
(Result - существительное) | Вывод или заключение, которыми завершаются любой процесс или состояние дел или которые получаются с помощью какого-либо процесса или операции, выходные данные. Действие или процесс применения общих принципов или формул для объяснения результатов, полученных в специальных случаях |
|
Удержать
(Retain) | Используйте вместо него ХРАНИТЬ (STORE) (с возможным добавлением формулировки, упоминающей, что управление удерживанием может потребоваться в соответствии с областью практики, политикой организации или законодательством). Например, система может обеспечить возможность ХРАНИТЬ (STORE) персональную медицинскую информацию и УДАЛИТЬ (DELETE) эти данные только в том случае, если это разрешено политикой удерживания данных, принятой в организации | Этот глагол устарел в качестве термина иерархии глаголов |
Отменить доступ
(Revoke-Access) | Используйте вместо него "КОНТРОЛИРОВАТЬ ДОСТУП, аннулируя разрешения на использование функциональности системы или управление данными" | Этот глагол устарел в качестве термина иерархии глаголов |
Роль
(Role) | Набор компетенций и/или характеристик, ассоциированных с работой | ИСО 18308, [ИСО 22600-1:2014] |
Код роли
(Role Code) | Специфичные классификационные коды для дальнейшей квалификации кодов класса RoleClass | Normative Edition HL7 V3 2012 |
Сохранить
(Save) | ЭКСПЛУАТИРОВАТЬ (MAINTAIN) данные, помечая их вручную с целью удерживания или для запрета автоматического удаления либо копируя данные. ХРАНИТЬ (STORE) данные, помещая их в устройство с электронным доступом. Например, клиницист может СОХРАНИТЬ (SAVE) демографические данные определенного пациента или сведения о вновь назначенном лекарстве. Другой пример: администратор может СОХРАНИТЬ (SAVE) измененный список врачей, наделенных правом практики в местной больнице |
|
Область практики
(Scope of Practice) | Терминология, используемая органами лицензирования для различных сфер деятельности, относящихся к медицине, определяющая процедуры, действия и процессы, разрешенные лицензированному лицу | http://www.answers.com/topic/report |
Бесшовный
(Seamless) | Стандарты интероперабельности позволяют системе ведения электронных историй болезни (СВ ЭМК) работать как совокупность приложений. Это приводит к единообразному представлению системы, которая в действительности представляет собой несколько различных взаимодействующих систем. Стандарты интероперабельности также позволяют совместно использовать информацию несколькими системами ведения ЭМК, включая участие в региональных, национальных или международных обменах информацией. Своевременный и эффективный доступ к информации и ее сбор обеспечиваются при минимальном влиянии на пользователя |
|
Искать (глагол)
(Search) | Используйте вместо него АНАЛИЗИРОВАТЬ (ANALYSE) или ПРЕДОСТАВИТЬ (RENDER) (или его дочерние глаголы действия), поскольку запросы или поиски подразумевают предоставление или анализ данных.
Например, вместо "Система ДОЛЖНА обеспечить возможность искать записи пациента на основе его предыдущих фамилий" можно сказать "Система ДОЛЖНА обеспечить возможность ПРЕДСТАВИТЬ список записей, в которых фамилия пациента совпадает с его предыдущими фамилиями" | Этот глагол устарел в качестве термина иерархии глаголов |
Защитить (систему)
(Secure (System) - глагол) | Обеспечить надежность и целостность системы с помощью контроля доступа к ее функциональности и/или данным, действиям прослеживания и операциям по поддержке системы. Например, система может предоставить возможность администратору ЗАЩИТИТЬ (SECURE) систему, управляя параметрами конфигурации контроля доступа, прослеживания и поддержки операций системы. Другой пример: система может ЗАЩИТИТЬ (SECURE) доступ к записи пациента, контролируя доступ к ее содержанию, прослеживая пользователей, изменивших запись пациента, и поддерживая непрерывную доступность записи |
|
Уровень критичности
(Severity Level) | Предупреждения, тревожные сигналы, уведомления и другие типы сообщений могут формироваться с указанием отличающихся состояний срочности различных условий |
|
Выбрать
(Select) | Используйте вместо него "ВВЕСТИ выбор" | Этот глагол устарел в качестве термина иерархии глаголов |
Семантическая интероперабельность
(Semantic interoperability) | Способность данных, совместно используемых системами, быть понятыми на уровне полностью определенных понятий предметной области | ИСО 18308 |
ДОЛЖЕН
(SHALL) | Указывает обязательное требование, которое должно быть выполнено (реализовано), чтобы обеспечить соответствие. Синоним "is required to" (требуется для) | Функциональная модель HL7 СВ ЭМК, глава 2 "Требования к соответствию" |
ПО ВОЗМОЖНОСТИ ДОЛЖЕН
(SHOULD) | Указывает необязательное рекомендуемое действие, которое пригодно, в частности, без упоминания и исключения других действий. Синоним - "разрешено и рекомендовано" | Функциональная модель HL7 СВ ЭМК, глава 2 "Требования к соответствию" |
SIG | (Латинская аббревиатура для Signetur - "пусть будет обозначено") - указания пациенту по рекомендуемому применению лекарства |
|
Подписать
(Sign - глагол) | Используйте вместо него "ПОМЕТИТЬ аутентифицированной подписью". Например, система может ПОМЕТИТЬ (TAG) запись пациента аутентифицированной подписью, когда врач завершает запись информации о пациенте | Этот глагол устарел в качестве термина иерархии глаголов |
Тип подписи (Signature Type) | Также известен как "метод подписи" или "метод аттестации". Нередко требуется, чтобы электронный документ (или сообщение), содержащий медицинскую информацию, был заверен одной или несколькими подписями автора (авторов) медицинской информации. (Примечание - Медицинская информация может быть создана человеком или устройством.) Чтобы конкретный тип подписи правильно интерпретировался электронной системой, должны существовать метаданные, указывающие метод, с помощью которого подпись может быть интерпретирована; если к подписи данного типа применен правильный метод, то ее можно правильно представить и проверить |
|
Единая логическая медицинская карта пациента
(Single logical patient record) | Интеграция информации и знаний о состоянии здоровья из различных источников СВ ЭМК, обеспечивающая создание единой организованной и доступной медицинской карты пациента, которая может управляться из единой логической точки; будет позволять давать ссылки на всю имеющуюся медицинскую информацию о конкретном лице, поддерживаемую интегрированной сетью медицинской информации. Индексированная система, обеспечивающая доступ ко всем хранящимся данным конкретного пациента | http://www.ercim.org/publication/ Ercim_News/enw29/tsiknakis.html "An Integrated Architecture for the Provision of Health Telematic Services in a Regional Network." By Monolis Tsiknakis and Stelios Orphanoudakis, Information Technology in Medicine and Health Care, ERCIM News, No. 29 - April 1997 |
Ситуационный критерий
(Situational criterion) | Критерий, требуемый при определенных обстоятельствах | Функциональная модель HL7 СВ ЭМК, глава 2 "Требования к соответствию" |
Специализированные представления
(Specialized views) | Компьютерное настраиваемое представление, основанное на специфичных сведениях об обращении, клинических протоколах и бизнес-правилах |
|
Стандартный (утвержденный)
(Standard) | Прилагательное, применяемое к дополнению-существительному (например, оценка, шаблон, руководство) для указания, что оно исходит от некоторого регионального, национального или международного органа, который обычно считается авторитетным источником такого стандарта | Mosby’s Medical Dictionary, 8th edition. © 2009, Elsevier |
Стандартный (местный)
Standard | Прилагательное, применяемое к дополнению-существительному (например, оценка, шаблон, руководство) для указания, что оно исходит от некоторого местного источника (например, медицинская организация, учреждение), который обычно считается авторитетным источником такого стандарта |
|
Стандарты практики
(Standards of practice) | Это зонтичный термин, охватывающий основные документы, описывающие обязательства и определяющие безопасную практику. К ним относятся профессиональные стандарты, руководства по этике, профессиональные знания начального уровня, региональные руководства, стандарты медицинской помощи и практические руководства | http://www.dietitians.ca/career/i5.htm |
Излагать
(State - глагол) | Используйте вместо него ПОМЕТИТЬ (TAG) с соответствующим квалификатором. Синонимы: Affirm, Assert, Declare, Indicate и State | Этот глагол устарел в качестве термина иерархии глаголов |
Хранить
(Store - глагол) | ЭКСПЛУАТИРОВАТЬ (MAINTAIN) данные, резервируя их, дешифруя, шифруя, восстанавливая или сохраняя в устройстве с электронным доступом. Например, клиницист может ХРАНИТЬ (STORE) демографические данные определенного пациента или сведения о вновь назначенном лекарстве. Другой пример: администратор может сконфигурировать систему таким образом, чтобы она ХРАНИЛА (STORE) копии последовательных изменений определенных данных по расписанию в целях резервирования.
Примечание - Данные могут храниться в виде простого текста, а также в зашифрованной или сжатой форме
|
|
Структурированные данные
(Structured data) | Структурированная информация медицинской карты подразделяется на дискретные поля и может быть перечислимой, числовой или кодированной.
Примеры структурированной медицинской информации включают в себя:
адрес пациента (не кодированное, но дискретное поле),
диастолическое артериальное давление (числовое), кодированный результат исследования, кодированный диагноз,
вопросник по оценке рисков пациента с вариантами ответов.
По контексту можно определить, являются ли данные структурированными; например, в некоторых СВ ЭМК дневниковая запись может быть стандартизованной и структурированной (а именно представленной в парадигме "субъективная/объективная/ оценка/план), а в других - неструктурированной |
|
Структурированный текст
(Structured text) | Компьютерные функции, возвращающие единственное значение |
|
Субъект медицинской помощи
(Subject of care) | Одно или несколько лиц, которым запланировано получение медицинской помощи, получающих или получивших ее.
Примечание - В контексте электронной медицинской карты термины "пациент" и "клиент" синонимичны субъекту медицинской помощи и, как правило, используются вместо более формального термина "субъект медицинской помощи"
| ИСО/ТР 12773-1
Примечание 1 адаптировано из ИСО 13606-1:2008 |
Сводный список
(Summary list) | Сокращенная версия чего-либо сказанного, или написанного, содержащая только основные моменты | http://encarta.msn.com/encnet/features/dictionary/ DictionaryResults.aspx?refid=1861716863 |
Поддерживать
(Support) | В зависимости от контекста и требуемой функциональности используйте вместо него "ПРЕДСТАВИТЬ шаблоны для выполнения ЧЕГО-ЛИБО" или ОПРЕДЕЛИТЬ (DETERMINE) или другие глаголы действия | Этот глагол устарел в качестве термина иерархии глаголов |
Вспомогательные функции
(Supportive functions) | Вспомогательные функции СВ ЭМК являются подмножеством функций СВ ЭМК, которые содействуют выполнению административных и финансовых требований, связанных с предоставлением медицинской помощи. Вспомогательные функции СВ ЭМК также предоставляют входные данные системам, поддерживающим научные медицинские исследования, содействующим общественному здоровью, предназначенным для повышения качества оказываемой медицинской помощи |
|
Приостановить доступ
(Suspend-Access) | Используйте вместо него "КОНТРОЛИРОВАТЬ ДОСТУП, временно приостановив разрешения на использование функциональности системы или управление данными" | Этот глагол устарел в качестве термина иерархии глаголов |
Синтаксическая интероперабельность
(Syntactic interoperability) | Возможность двух или более систем связываться и обмениваться данными с помощью специальных форматов данных и коммуникационных протоколов | ИСО 18308 |
Синтезировать
(Synthesize) | Используйте вместо него "АНАЛИЗИРОВАТЬ и ХРАНИТЬ" или "АНАЛИЗИРОВАТЬ и ПРЕДСТАВИТЬ" | Этот глагол устарел в качестве термина иерархии глаголов |
Пометить
(Tag) | ИЗМЕНИТЬ (UPDATE) данные, помечая их для специального применения. Например, медсестра может ПОМЕТИТЬ (TAG) записи пациентов с сильным кашлем и лихорадкой, сделанные на прошлой неделе. Другой пример: врач общей практики может ПОМЕТИТЬ (TAG) определенные данные для просмотра онкологом. Еще один пример: администратор может ПОМЕТИТЬ (TAG) версию стандарта обмена данными как устаревшую.
Примечание - См. "флаг" (flag), если значением является сигнализация о ситуации.
Примечание - Глагол "снять метку" (untag) является приемлемым для действия, обратного пометке
|
|
Задача
(Task) | Единица работы. Задача (применительно к электронной медицинской карте) может быть клинической (т.e. задачей, выполняемой как часть процесса оказания медицинской помощи пациенту), или неклинической задачей (например, административная задача, такая как обновление списка поставщиков медицинской помощи, имеющих право на оформление поступления в местную больницу). Задача может возникнуть ситуативно или по расписанию. Задача может быть помещена в список и назначена лицу, группе лиц или автоматизированному механизму. Задачи могут решаться совместно, переназначаться, распределяться (или перераспределяться) по приоритетам, маршрутизироваться, корректироваться, уточняться, отменяться или приостанавливаться |
|
Термин
(Term) | Словесное обозначение общего понятия специфичной предметной области | ИСО 18308, [ИСО 1087-1:2000] |
Терминологическая система
(Terminological system) | Набор понятий, структурированный в соответствии с отношениями между ними, каждое понятие представляется знаком, обозначающим его.
Примечание - В работах по терминологии указываются три типа таких знаков (обозначений): символы, обозначения и термины
| ИСО 18308, [слияние определений ИСО/МЭК 11179-1:2004 и ИСО 1087-1:2000] |
Терминологические службы
(Terminology Services) | Терминологические службы (ТС) являются набором сервисов, представляющих и применяющих словари, контролируемые и неконтролируемые, включая входящие в них термины, понятия и отношения. Это делается для поиска, просмотра, обнаружения, перевода, отображения, семантического вывода, индексирования и классификации предметов, сбора, оповещения и т.п. |
|
Текст
(Text) | В информационной технологии текст представляет собой человеко-читаемую последовательность символов и слов, которые из них образуются, которые могут кодироваться в машиночитаемые форматы, например ASCII. Текст, как правило, отличается от не символьных кодируемых данных, например графических образов в форме растровых изображений или программных кодов, которые иногда называются "бинарными" (но в действительности имеют собственный машиночитаемый формат) | http://searchsmb.techtarget.com/ sDefinition/0,,sid44_gci213853,00.html |
Штамп времени
(Timestamp - существительное) | Метка времени - это текущее время события, зарегистрированное компьютером. С помощью механизмов наподобие NTP (Network Time Protocol - протокол сетевого времени) компьютер поддерживает точное текущее время, калиброванное до сотых долей секунды | http://whatis.techtarget.com/wsearch/ 1,290214,sid9,00.html?query=timestamp |
Поставить штамп времени
(Timestamp - глагол) | Используйте вместо него "ПОМЕТИТЬ штампом времени" | Этот глагол устарел в качестве термина иерархии глаголов |
Прослеживать
(Track - глагол) | ЗАЩИТИТЬ (SECURE) систему, ведя журнал и аудит действий, инициированных системой или пользователем. Например, система может ПРОСЛЕЖИВАТЬ (TRACK) количество времени, в течение которого система была недоступна в прошлом месяце. Другой пример: система может обеспечить администратору возможность ПРОСЛЕЖИВАТЬ (TRACK) число активных пользователей вновь установленного комплекса функциональности системы |
|
Поддержка транзакций данных
(Transact data) | Акт обработки логической единицы информации. Например, данные, полученные из внешней системы, могут быть зафиксированы ("подтверждена транзакция") в локальной базе данных.
Примечание - Транзакция указанной логической единицы информации может реально включать одну/несколько передач или приемов данных между системами.
Другой пример: система может осуществить транзакцию передачи локальных данных внешней системе длительного хранения данных |
|
Передать
(Transmit) | ПРЕДОСТАВИТЬ (RENDER) данные, доставляя их устройствам или системам содержательным и надлежащим способом. Например, система может (без вмешательства человека) ПЕРЕДАТЬ (TRANSMIT) тревожный сигнал на устройство звуковой сигнализации врача. Другой пример: система может (после вмешательства человека) ПЕРЕДАТЬ (TRANSMIT) внешней организации эпикриз посещения пациента. Еще один пример: система может ПЕРЕДАТЬ (TRANSMIT) данные внешней системе, преобразовав местные коды в национальные. |
|
| Примечание - Разумно предположить, что любые передаваемые данные должны быть соответствующим образом отформатированы, отфильтрованы, переведены, преобразованы, отображены и/или нормализованы и т.п.
|
|
Вариант лечения
(Treatment option) | Один из нескольких способов эффективного лечения | The American Heritage Dictionary of the English Language |
План лечения
(Treatment plan) | См. "План ведения" (Care Plan). | HL7 Clinical Decision Support team, Jim McClay, SAGE guideline consortium, University of Nebraska Medical Center |
Протокол лечения
(Treatment protocol) | План применения способов эффективного лечения | The American Heritage Dictionary of the English Language |
Запустить
(Trigger - глагол) | Вместо него в зависимости от контекста используйте "РЕШИТЬ инициировать действие на основе анализа определенных данных и правил" или "РЕШИТЬ и ПРЕДОСТАВИТЬ некоторую информацию (например, тревожный сигнал или уведомление) на основе анализа определенных данных и правил" | Этот глагол устарел в качестве термина иерархии глаголов. |
Доверенная среда обмена информацией
(Trusted Information Exchange environment) | Доверенная среда обмена информацией обеспечивает целостность, конфиденциальность и доступность чувствительных данных в процессе обмена информацией между участвующими сторонами. Участвующие стороны соглашаются защищать передаваемую и получаемую информацию, реализуя определенные административные и управленческие процедуры в соответствии с областью практики, политикой организации или законодательством. [Например, в США доверенная среда обмена информацией известна под названием Chain-of-Trust Agreement (соглашение по цепочке доверия)] |
|
Раскрыть
(Unhide) | УПРАВЛЯТЬ ВИДИМОСТЬЮ ДАННЫХ (MANAGE-DATA-VISIBILITY), делая видимым существование ранее скрытой информации (см. СКРЫТЬ). Например, система может предоставить пациенту возможность РАСКРЫТЬ (UNHIDE) его психиатрическую запись и тем самым сделать существование этой части записи видимым для всех авторизованных клиницистов |
|
Демаскировать
(Unmask) | УПРАВЛЯТЬ ВИДИМОСТЬЮ ДАННЫХ (MANAGE-DATA-VISIBILITY), делая замаскированную информацию видимой. Например, администратор может пожелать ДЕМАСКИРОВАТЬ (UNMASK) финансовую информацию конкретного пациента для приемного отделения. К примеру, система может предоставить врачу отделения неотложной помощи возможность ДЕМАСКИРОВАТЬ (UNMASK) статус беременности пациентки, который был представлен системой как "******", и раскрыть статус "беременная" |
|
Удалить метку
(Untag) | ИЗМЕНИТЬ (UPDATE) данные, удаляя маркировку специального использования. Например, медсестра может УДАЛИТЬ МЕТКУ (UNTAG) с ранее помеченных записей пациентов за предыдущую неделю, у которых наблюдались сильный кашель и лихорадка. Другой пример: врач общей практики может УДАЛИТЬ МЕТКУ (UNTAG) с определенных данных после того, как другой поставщик медицинской помощи завершил их анализ |
|
Уникальная идентификация
(Uniquely identifying) | Метод, позволяющий идентификацию единого объекта (например, пациента, поставщика медицинской помощи или тест), произведенного из одного или нескольких элементов данных |
|
Неструктурированные данные
(Unstructured data) | Неструктурированная информация медицинской карты - это информация, не подразделяемая на дискретные поля и не представленная в виде численных, перечислимых или кодированных данных.
Общие примеры неструктурированных данных о состоянии здоровья включают:
текст;
документ, созданный процессором обработки текстов;
изображение;
мультимедийную информацию.
Специфичные примеры включают:
текстовое сообщение врачу;
фотографию пациента;
письмо от семьи;
сканированное изображение страхового полиса;
надиктованный отчет (голосовое сообщение) |
|
Неструктурированный текст
(Unstructured text) | Текст, не имеющий определенной структуры или организации; формально не организованный или не систематизированный | http://www.answers.com/library/Dictionary;jsessionid= 2nn5846ql7gmh-cid-1992345752-sbid-lc07a |
Изменить
Update (verb) | ЭКСПЛУАТИРОВАТЬ (MAINTAIN) данные, аннотируя, редактируя, гармонизируя, интегрируя, связывая и помечая их. Например, клиницист может ИЗМЕНИТЬ (UPDATE) дозировку лекарственного препарата пациента. Другой пример: система может ИЗМЕНИТЬ (UPDATE) запись пациента |
|
Управление версиями
(Versioning) | Управление несколькими редакциями одной и той же единицы информации | http://en.wikipedia.org/wiki/Versioning |
Вид
(View - существительное) | Специфичная информация, отображаемая на дисплее компьютера, после ее фильтрации системой. См. "Отобразить" |
|
Просмотреть
(View - глагол) | Используйте вместо него ПРЕДСТАВЛЯТЬ (PRESENT) | ИСО 18308, [ИСО/ЕН 13606-1:2008]
Этот глагол устарел в качестве термина иерархии глаголов |
Приложение С
(справочное)
История иерархии глаголов действия
Настоящий глоссарий был составлен в результате большой работы по улучшению строгости, точности и согласованности набора терминов, используемых в ФМ СВ ЭМК, а также функциональной модели системы ведения персональных электронных медицинских карт (ФМ СВ ПЭМК).
C.1 Начальный импульс
ФМ СВ ЭМК начиналась как набор функций, основанный на материале, предложенном институтом IOM (Institute of Medicine - Институт медицины) отрасли здравоохранения в 2003 г. Этот материал не включал глоссарий, однако основывался на общем понимании терминов, связанных с медицинской помощью и информационными системами. Эти функции были проверены и расширены группой HL7 EHR Special Interest Group (которая в конечном итоге стала Рабочей группой HL7 EHR). Отдельными авторскими группами были разработаны различные функции в главах "Лечебный процесс", "Вспомогательные" и "Информационная инфраструктура". По мере роста числа функций необходимость сведения к минимуму избыточности функций стала более острой. Например, одна группа создала функциональность, которая предусматривала "access" (доступ) к демографическим данным пациента; другая группа предусмотрела чтение, изменение и запись демографических данных пациента. Были эти два подхода дублирующими? Если нет, то в чем разница? Рабочая группа HL7 EHR в конечном итоге начала работу по уточнению значения глаголов действия.
С.2 Как была разработана первая версия глоссария
Был выполнен анализ всех функций ФМ СВ ЭМК и была создана рудиментарная иерархия, в которой различные глаголы действия были подразделены на категории. Тем не менее была создана новая функциональность; другая функциональность была объединена или была по-иному распределена по категориям, что привело к перемещению цели.
С.3 Вторая версия глоссария
Когда была создана ФМ СВ ПЭМК, то опыт и преимущества ФМ СВ ЭМК были использованы для создания нового, более обширного набора глаголов действия, на которых была основана ФМ СВ ПЭМК. Эта работа выявила потребность согласования глоссариев ФМ СВ ПЭМК и ФМ СВ ЭМК, в процессе разработки второго выпуска ФМ СВ ЭМК.
С.4 Текущая версия глоссария
Начиная с мая 2010 г. и далее в течение пяти месяцев небольшая группа добровольцев проанализировала оба глоссария (см. ниже две соответствующие версии иерархий глаголов действия), гармонизировала различные термины, исследовала существующие определения и другие стандарты, учла, каким образом термины могли бы использоваться в разных международных сферах применения и переводиться на другие языки, и сформировала более полноценный набор глаголов действия (это привело к созданию текущей версии глоссария).
Приведенные ниже две (2) иерархии глаголов действия, взятые из ФМ СВ ЭМК и ФМ СВ ПЭМК, были отправной точкой для разработки текущей версии глоссария.
Таблица C.1 - Иерархия глаголов функциональной модели СВ ЭМК
Функциональная модель СВ ЭМК |
|
Иерархия глаголов ФМ СВ ЭМК:
Всего 21 термин (включая "Manage")
Все термины иерархии глаголов ФМ СВ ЭМК включены в иерархию глаголов ФМ СВ ПЭМК (примечание: "input device" заменено на "input" в иерархии глаголов ФМ СВ ПЭМК) |
MANAGE (управлять)
Capture (собрать) Maintain (эксплуатировать)
Input Device (вводить с устройств, внешний) Create (создать, внутренний) Read (читать)
Update (изменить) Remove Access (устранить доступ)
View (просмотреть)
Report (выдать отчет)
Display (отобразить)
Access (предоставить доступ) Edit (редактировать)
Correct (корректировать)
Amend (внести изменения)
Augment (прибавить) Obsolete (устареть)
Inactivate (деактивировать)
Destroy (разрушить)
Nullify (аннулировать)
Purge (очистить) |
Таблица C.2 - Иерархия глаголов функциональной модели СВ ПЭМК
Функциональная модель СВ ПЭМК |
|
Иерархия глаголов ФМ СВ ПЭМК:
Всего 49 терминов (включая "Manage")
Глагол "Capture" расширен специфичными терминами под глаголами "Input" и "Create"
Глагол "Render" добавлен как подкатегория с понятиями "read" и "output"
К глаголу "Maintain" добавлены понятия "store" и "Restrict Access" |
MANAGE (управлять)
Capture (собрать) Maintain (эксплуатировать) Render (предоставить)
Input (осуществить ввод)
(Внешний) Create (создать)
(Внутренний) Store (хранить) Update (изменить) Restrict Access (ограничить доступ)
Remove (устранить)
Access (предоставить доступ) Read (читать)
(Внутренний) Output (создать выходные данные)
(Внешний) |
Receive (получить)
Accept (принимать)
Download (загрузить) |
Import (импортировать) Enter (ввести)
Compute (вычислить)
Record (записать) Save (сохранить) |
Backup (резервировать)
Compact (сжать)
Encrypt (шифровать)
|
Archive (архивировать) Edit (редактировать)
Correct (корректировать)
Amend (внести изменения) |
Augment (прибавить)
Annotate (аннотировать)
Comment (комментировать)
|
Associate (ассоциировать)
Tag (пометить) Hide (скрыть)
Mask (маскировать)
|
Filter (фильтровать) Obsolete (устареть)
Inactivate (деактивировать)
Destroy (разрушить)
|
Nullify (аннулировать)
Purge (очистить) View (просмотреть)
Report (выдать отчет)
|
Display (отобразить)
Access (предоставить доступ)
Present (представить) Send (послать)
|
Upload (загрузить)
Export (экспортировать)
Synchronize (синхронизировать)
|
Приложение D
(справочное)
Организации, оказавшие содействие
Несколько организаций по стандартизации были приглашены для анализа и комментирования при голосовании. Это следующие организации:
- CDISC (Clinical Data Interchange Standards Consortium - Консорциум по стандартизации обмена клиническими данными)
- IHTSDO (International Health Terminology Standards Development Organisation - Международная организация по разработке стандартов медицинской терминологии)
- HL7 (Health Level 7)
- ISO (International Organization for Standardization - Международная организация по стандартизации)
- GS1.
Приложение Е
(справочное)
История вопроса
Е.1 Что представляет собой организация HL7?
Созданная в 1987 г., Health Level Seven (HL7) представляет собой некоммерческую организацию, занимающуюся разработкой стандартов и аккредитованную Американским национальным институтом стандартов (American National Standards Institute, ANSI). В ее задачи входит разработка стандартов обмена, интеграции, совместного использования и извлечения электронной медицинской информации; поддержка клинической практики, а также поддержка управления, предоставления и оценки медицинской помощи. Аккредитация ANSI в сочетании с собственными процедурами HL7 предусматривает, что любой стандарт, опубликованный HL7 и представленный на утверждение ANSI, должен быть разработан и утвержден в результате осуществления процесса, который следует процедурам ANSI по достижению открытого консенсуса и отвечает требованиям баланса интересов за счет примерно равного участия в процессе голосования различных постоянных групп, испытывающих материальное воздействие стандарта (например, производители, поставщики медицинской помощи, государственные органы, консультанты, некоммерческие организации). Этот баланс интересов обеспечивает ситуацию, при которой конкретные группы никогда не отказываются от участия, но при этом не доминируют в разработке и утверждении предлагаемого стандарта. Дополнительную информацию и историю создания ANSI можно найти на веб-сайте http://www.ANSI.org.
Е.2 Рабочая группа по электронным медицинским картам HL7
Группа специальных интересов по электронным медицинским картам HL7 (EHR SIG) была создана весной 2002 года. Весной 2003 года группа HL7 начала разработку стандартизованной функциональной спецификации для систем ведения электронных медицинских карт (СВ ЭМК). В мае 2004 года группа EHR SIG была преобразована в полноценный Технический комитет HL7 и стала EHR TC. Комитет EHR TC прежде всего предназначен быть органом, содействующим реализации электронных историй болезни (ЭМК), стандартизуя функции, которые в зависимости от выбора пользователя могут выполняться СВ ЭМК.
Государственно-частное партнерство в составе Министерства здравоохранения и социальных служб (Department of Health and Human Services), Управления по вопросам здравоохранения ветеранов (Veterans Health Administration), Общества систем управления медицинской информацией (Health Information Management Systems Society), а также Фонда Роберта Вуда Джонсона (Robert Wood Johnson Foundation) обратилось в HL7 с просьбой ускорить разработку на основе консенсуса стандарта, определяющего функции СВ ЭМК. HL7 в лице рабочей группы EHR SIG откликнулась и разработала функциональную модель СВ ЭМК, которая прошла голосование в качестве проекта стандарта для пробного использования (Draft Standard for Trial Use, DSTU) в апреле 2004 года. Функциональная модель DSTU была опубликована и официально зарегистрирована Американским национальным институтом стандартов (ANSI) в июле 2004 года. Затем было проведено голосование по функциональной модели, которая в январе 2007 года была утверждена в качестве стандарта на совещании Рабочей группы HL7 и в настоящее время зарегистрирована в ANSI как утвержденный стандарт.
С учетом полезного опыта процесса голосования была создана функциональная модель с более четким и простым списком функций. Функциональная модель HL7 системы ведения ЭМК предоставляет справочный список функций, которые могут выполняться системами ведения электронных медицинских карт (СВ ЭМК). В целях согласованного представления функциональности системы список функций описан с пользовательской точки зрения. С помощью создания функциональных профилей эта модель СВ ЭМК обеспечивает стандартизованное описание и общее понимание функций, предполагаемых или имеющихся в указанных условиях оказания медицинской помощи (например, интенсивная терапия, кардиология, амбулаторная практика в одной стране или первичная медицинская помощь - в другой).
Е.3 Что такое пакет функциональной модели СВ ЭМК?
Документы этого пакета охватывают Выпуск 2.0 функциональной модели СВ ЭМК и редакции содержания свойств, основанные на Выпуске 1. Текущая версия объединяет отдельные главы предыдущей версии в два документа (с целью соответствия требованиям публикации, предъявляемым ИСО). Пакет содержит артефакты, перечисленные в таблице E.1.
Таблица E.1 - Пакет функциональной модели
Разделы документа | Имя файла |
Общий обзор
Соответствие
Глоссарий
Руководство "Read Me" (прочти меня) | EHRS_FM_R2_N2_Overview.PDF |
Список функций функциональной модели СВ ЭМКt | EHRS_FM_R2_FunctionList.XLSX |
Учтите, что сопутствующий документ "How-To Guide for Creating Functional Profiles" (Руководство по созданию функциональных профилей) публикуется отдельно.
Приложение F
(справочное)
Выражения признательности
F.1 Общие благодарности
Комитет выражает признательность следующим бывшим сопредседателям Технического комитета и координаторам за их вклад в разработку всех частей данной модели и представленный здесь материал. Мы благодарны всем людям, сумевшим внести свой вклад, независимо от того, был ли это короткий период времени или работа в режиме неделя работы/неделя отдыха, с раннего утра до позднего вечера, а также в выходные дни. Мы не в состоянии выразить всю нашу благодарность. Прямых и косвенных участников процесса разработки модели, включая тех, кто внес вклад в деятельность рабочей группы, и других участников можно найти в списке "Contributor Listing", находящемся в разделе "documents" на сайте http://www.hl7.org/EHR.
Таблица F.1 - Благодарности
Имя | Функция | Организация |
Gary Dickinson (Гэри Дикинсон) | Сопредседатель ТК ЭМК | CentrifyHealth, Inc. |
Mark Janczewski MD, MPH (Марк Янчевский) | Сопредседатель ТК ЭМК | Medical Networks, LLC |
Don Mon (Дон Мон) | Сопредседатель ТК ЭМК | Research Triangle Institute (RTI) International |
John Ritter (Джон Риттер) | Сопредседатель ТК ЭМК |
|
Helen Stevens (Элен Стивенс) | Сопредседатель ТК ЭМК | Stevens Healthcare Integration |
Patricia Van Dyke (Патриция ван Дайк) | Сопредседатель ТК ЭМК | Delta Dental Plans Association |
Peter DeVault (Питер Девольт) | Бывший сопредседатель ТК | Epic Systems Corporation |
Linda Fischetti (Линда Фишетти) | Бывший сопредседатель ТК | US. Department of Veterans Affairs |
Sam Heard (Сэм Херд) | Бывший сопредседатель ТК | Ocean Informatics |
David Rowlands (Дэвид Роулэндс) | Бывший сопредседатель ТК | Standards Australia |
Corey Spears (Кори Спирс) | Бывший сопредседатель ТК | McKesson Corporation |
Lenel James (Ленел Джеймс) | Сокоординатор | Blue Cross Blue Shield Association |
Sue Mitchell (Сью Митчел) | Сокоординатор
Рабочая группа публикации | Independent Consultant |
Corey Spears (Кори Спирс) | Руководитель публикации и инструментария | McKesson Corporation |
Andre Boudreau (Андре Будро) | Руководитель секции | Independent Consultant |
Gora Data (Гора Дэйта) | Руководитель секции | Cal2Cal |
Michelle Dougherty (Мишель Дагерти) | Руководитель секции | AHIMA |
Steve Hufnagel (Стив Хафнэйджел) | Руководитель секции | DOD/MHS |
Hetty Khan (Хэтти Хан) | Руководитель секции | CDC |
Wes Knox (Вес Нокс) | Руководитель секции | Independent Consultant |
Don LaVigne (Дон Лавин) | Руководитель секции | Xifin |
Jim McClay (Джим Маклэй) | Руководитель секции | University of Nebraska Medical Center |
Nancy Orvis (Нэнси Орвис) | Руководитель секции | MHS/DOD |
Peter Park (Питер Парк) | Руководитель секции | DOD/MHS |
F.2 Благодарности за участие в создании глоссария
Таблица F.2 - Благодарности за участие в создании глоссария
Имя | Функция | Организация |
Andre Boudreau (Андре Будро) | Член целевой группы по глоссарию | Boroan Inc. |
Mark N.Brueckl (Марк Н.Брукл) | Член целевой группы по глоссарию | Academy of Managed Care Pharmacy |
Mark Janczewski, MD, MPH (Марк Янчевский) | Соруководитель целевой группы по глоссарию | Medical Networks, LLC |
Wes Knox (Вес Нокс) | Член целевой группы по глоссарию | G4 Consulting, LLC |
John Ritter (Джон Риттер) | Соруководитель целевой группы по глоссарию | Сопредседатель Рабочей группы HL7 EHR, Член ИСО/ТК 215 Technical Advisory Group от США |
Приложение G
(справочное)
Другие предложения и запросы от Рабочей группы EHR
Руководство по разработке функциональных профилей (How-to-Guide for Developing Functional Profiles) является сопутствующим документом, публикуемым отдельно.
Функциональная модель системы персональных электронных медицинских карт ИСО/HL7 ДИС 16527 является версией функциональной модели СВ ЭМК, ориентированной на потребителя. С ней можно ознакомиться на вебсайте HL7.
Обучение по ФМ СВ ЭМК, ФМ СВ ПЭМК и критериям соответствия доступно с помощью учебных материалов, предлагаемых на совещаниях Рабочей группы HL7 и на образовательных саммитах HL7.
Представители HL7 могут предложить краткие презентации представителей HL7 по различным аспектам, включая ФМ СВ ЭМК и ФМ СВ ПЭМК. Обращайтесь в Комитет по маркетингу HL7.
Если вы разрабатываете (или собираетесь разрабатывать) функциональные профили или другие рабочие продукты, относящиеся к ФМ СВ ЭМК или ФМ СВ ПЭМК, то просим проинформировать об этом сопредседателей Рабочей группы EHR, чтобы они могли иметь возможность поддержки и содействия вашей работе. Вы можете связаться с ними, используя следующую контактную информацию:
Gary Dickinson (Гари Дикинсон), CentriHealth
Тел.: +1-951-536-7010
Email: gary.dickinson@СВ ЭМКtandards.com
Mark G.Janczewski (Марк Г.Янчевский), MD, MPH, Medical Networks, LLC
Тел.: +1-703-994-7637
Email: mark.janczewski@verizon.net
Don Mon (Дон Мон), Research Triangle Institute (RTI) International
Тел.: +1-708-250-4374
Email: donmon@rti.org
John Ritter (Джон Риттер),
Тел.: +1-412-372-5783
Email: johnritter1@verizon.net
Helen Stevens (Элен Стивенс), Stevens Healthcare Integration
Тел.: +1-250-818-0312
Email: helen.stevens@shaw.ca
Patricia Van Dyke (Патриция Ван Дайк), Moda Health, Delta Dental Plans Association
Тел.: +1-503-243-4492
Email: patricia.vandyke@modahealth.com
Приложение ДА
(справочное)
Сведения о соответствии ссылочных международных стандартов национальным стандартам
Таблица ДА.1
Обозначение ссылочного международного стандарта | Степень соответствия | Обозначение и наименование соответствующего национального стандарта |
ISO/TR 12773-1:2009 | - | * |
ISO/TS 13606-4:2009 | - | * |
ISO/TS 17090-1:2002 | IDT | ГОСТ Р ИСО/ТС 17090-1-2009 "Информатизация здоровья. Инфраструктура с открытым ключом. Часть 1. Структура и общие сведения" |
ISO 18308:2011 | IDT | ГОСТ Р ИСО/ТС 18308-2008 "Информатизация здоровья. Требования и архитектура электронного учета здоровья" |
ISO/IEC 2382-8:1998 | - | * |
ASTM Е 1769:1995 | - | * |
* Соответствующий национальный стандарт отсутствует. До его принятия рекомендуется использовать перевод на русский язык данного международного стандарта.
Примечание - В настоящей таблице использовано следующее условное обозначение степени соответствия стандартов:
- IDT - идентичные стандарты. | ||
Библиография
[1] | Dick R.S. et al. The Computer-Based Patient Record: An Essential Technology. National Academy Press, Washington, D.C., 1997 |
[2] | Johns M.L. PhD, RHIA Health Information Management Technology: An Applied Approach. AHIMA, Chicago, IL, Third Edition, 2010 |
[3] | ISO 13606-1, Health informatics - Electronic health record communication - Part 1: Reference model (Информатизация здоровья. Передача электронных медицинских карт. Часть 1. Базовая модель) |
[4] | ISO 13606-2, Health informatics - Electronic health record communication - Part 2: Archetype interchange specification (Информатизация здоровья. Передача электронных медицинских карт. Часть 2. Спецификация передачи архетипов) |
[5] | ISO 13606-3, Health informatics - Electronic health record communication - Part 3: Reference archetypes and term lists (Информатизация здоровья. Передача электронных медицинских карт. Часть 3. Справочные архетипы и списки терминов) |
[6] | ISO 13606-5, Health informatics - Electronic health record communication - Part 5: Interface specification (Информатизация здоровья. Передача электронных медицинских карт. Часть 5. Спецификация интерфейса) |
[7] | ISO 13940  , Health informatics - System of concepts to support continuity of care ( Информатизация здоровья. Системы понятий для обеспечения непрерывности ухода за больным ) |
________________ Будет опубликован. | |
[8] | ISO/TR 21089, Health informatics - Trusted end-to-end information flows (Информатизация здоровья. Потоки конфиденциальной сквозной информации) |
[9] | CPRI, 1996b, Guidelines for managing information security programs at Organizations using computer-based patient record systems |
УДК 004:61:006.354 |
| ОКС 35.240.80 |
| ||
Ключевые слова: информатизация здоровья, электронная медицинская карта, система ведения электронных медицинских карт, функциональная модель | ||