1
Доступно поисковых запросов: 1 из 2
Следующий пробный период начнётся: 02 октября 2022 в 12:18
Снять ограничение

ГОСТ Р ИСО 27789-2016

Информатизация здоровья. Журналы аудита для электронных медицинских карт
Действующий стандарт
Проверено:  24.09.2022

Информация

Название Информатизация здоровья. Журналы аудита для электронных медицинских карт
Дата актуализации текста 01.12.2016
Дата актуализации описания 01.01.2021
Дата издания 27.07.2016
Дата введения в действие 01.07.2017
Область и условия применения Настоящий стандарт определяет общую структуру аудиторских следов для электронных медицинских карт (EHR), в терминах контрольных событий аудита и данных аудита, для поддержки контролируемости всего набора персональной медицинской информации в разных информационных системах и предметных областях. Настоящий стандарт применим к системам обработки персональной медицинской информации, которые, в соответствии с ИСО 27799, создают защищенную запись аудита каждый раз, когда пользователь получает доступ, создает, обновляет или архивирует персональную медицинскую информацию в системе. Настоящий стандарт охватывает только действия, выполняемые с помощью EHR, которые подчиняются политике обеспечения доступа к предметной области, для которой электронная медицинская карта была выпущена. Настоящий стандарт не относится к какой-либо персональной медицинской информации из электронной медицинской карты, кроме идентификаторов, запись аудита содержит только ссылки на разделы EHR, как указано в применяемой политике доступа
Опубликован Официальное издание. М.: Стандартинформ, 2016 год
Утверждён в Росстандарт


ГОСТ Р ИСО 27789-2016

Группа П85

     

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

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

Журналы аудита для электронных медицинских карт

Health informatics. Audit trails for electronic health records



ОКС 35.240.80

ОКСТУ 4002

Дата введения 2017-07-01

     

Предисловие

1 ПОДГОТОВЛЕН Федеральным государственным бюджетным учреждением "Центральный научно-исследовательский институт организации и информатизации здравоохранения Министерства здравоохранения Российской Федерации" (ЦНИИОИЗ Минздрава) и Обществом с ограниченной ответственностью "Корпоративные электронные системы" на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

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

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

4 Настоящий стандарт идентичен международному стандарту ИСО 27789:2013* "Информатизация здоровья. Журналы аудита для электронных медицинских карт" (ISO 27789:2013 "Health informatics - Audit trails for electronic health records", IDT).

________________

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



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

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


Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

0.1 Общие положения

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

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

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

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

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

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

0.2 Преимущества использования настоящего стандарта

Стандартизация следов аудита по доступу к электронным медицинским картам преследует две цели:

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

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

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

0.3 Сравнение со стандартами, связанными с аудиторскими следами электронных медицинских карт

Настоящий стандарт соответствует требованиям ИСО 27799:2008, в той части, в которой они связаны с выполнением аудита и аудиторскими следами.

Некоторые читатели могут быть знакомы с Запросом Комментариев (RFC) Рабочей группы инженеров Интернет (IETF RFC 3881 [13]). (Читатели, еще не знакомые с IETF RFC 3881, не должны ссылаться на данный документ, так как осведомленность в этом вопросе не требуется для понимания настоящего стандарта.) Информационный RFC 3881 от 2004-09, не указанный на сегодняшний день среди действующих запросов в базе данных IETF, был ранней и полезной попыткой определения содержания журналов аудита для здравоохранения. Настоящий стандарт по мере возможности основывается и согласуется с работой, начатой в RFC 3881 по доступу к EHR.

0.4 Примечание по терминологии

В разделе 3 определено несколько близко связанных терминов. Журнал аудита - это хронологическая последовательность записей аудита; каждая запись аудита содержит доказательство того, что она имеет прямое отношение к процессу или системной функции и возникает в результате их выполнения. Так как системы EHR могут быть сложными, может существовать несколько журналов аудита, содержащих информацию о событиях системы, которые изменили EHR субъекта получения медицинской помощи. Хотя термины "аудиторский след" и "журнал аудита" часто используются как взаимозаменяемые понятия, в настоящем стандарте термин "аудиторский след" относится к совокупности всех записей аудита из одного или нескольких журналов аудита, относящихся к определенному субъекту получения медицинской помощи, к определенной электронной медицинской карте или определенному пользователю. Система аудита предоставляет все функции обработки информации, необходимые для обслуживания одного или нескольких журналов аудита.

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


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

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

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


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

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

В приложении А представлены примеры сценариев аудита. Приложение В содержит обзор сервисов журнала аудита.

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


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

_______________

     * Таблицу соответствия национальных стандартов международным см. по ссылке. - Примечание изготовителя базы данных.



ИСО 8601:2004 Элементы данных и форматы для обмена информацией. Обмен информацией. Представление дат и времени (ISO 8601:2004, Data elements and interchange formats - Information interchange - Representation of dates and times)

ИСО 27799:2008 Информатизация здоровья. Менеджмент безопасности информации по стандарту ИСО/МЭК 27002 (ISO 27799:2008, Health informatics - Information security management in health using ISO/МЭК 27002)

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


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

3.1

контроль доступа (access control): Обеспечение того, чтобы доступ к активам был санкционирован и ограничен в соответствии с требованиями коммерческой тайны и безопасности.

[ИСО/МЭК 27000:2012, определение 2.1]


     3.2 политика доступа (access policy): Определение обязанностей по санкционированию доступа к ресурсу.

3.3

     

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

[ИСО 15489-1:2001, определение 3.2]

     

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

3.5 архив аудита (audit archive): Архивная коллекция одного или нескольких журналов аудита.

3.6 данные аудита (audit data): Данные, полученные из одного или нескольких журналов аудита.

3.7 журнал аудита (audit log): Хронологическая последовательность записей аудита, каждая из которых содержит данные об определенном событии.

3.8 запись аудита (audit record): Запись одного определенного события в жизненном цикле электронной медицинской карты.

3.9 система аудита (audit system): Система обработки информации, которая поддерживает работу одного или нескольких журналов аудита.

3.10 аудиторский след (audit trail): Коллекция записей аудита от одного или нескольких журналов аудита, связанных с определенным субъектом получения медицинской помощи или определенной электронной медицинской картой.

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

3.12 авторизация (authorization): Предоставление полномочий, включая полномочия по данным и функциям доступа.

Примечание - Основано на ИСО 7498-2. Предоставление прав, включая предоставление доступа на основании прав доступа.

3.13 орган (authority): Субъект, ответственный за выдачу сертификатов.

3.14

          

доступность (availability): Свойство быть доступным и готовым к использованию по запросу авторизованного субъекта.

[ИСО/МЭК 27000:2012, определение 2.10]


3.15

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

[ИСО/МЭК 27000:2012, определение 2.13]


3.16

     

всемирное скоординированное время (Coordinated Universal Time; UTC): Шкала времени, составляющая основу для скоординированной передачи по радио стандартных частот и сигналов времени; она точно соответствует по частоте Международному Атомному Времени, но отличается от него целым числом секунд.

[МЭК 60050-713:1998]


3.17

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

[ИСО 7498-2:1989, определение 3.3.21]


3.18

электронная медицинская карта (Electronic health record; EHR): Всесторонний структурированный комплекс клинических, демографических данных, данных об окружающей среде, социальных и финансовых данных в электронной форме, документирующий оказание медицинских услуг отдельному человеку.

[ASTM E 1769:1995]

     

     3.19 сегмент EHR (EHR segment): Часть EHR, которая составляет определенный источник для политики доступа.

3.20

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

[ИСО/МЭК 2382-8:1998, определение 08.04.12 [как аутентификация личности (identity authentication), проверка личности (identity validation)]


3.21 идентификатор (identifier): Информация, используемая для утверждения личности перед возможным ее подтверждением соответствующим аутентификатором.

3.22

защищенность информации (information security): Сохранение конфиденциальности, целостности и доступности информации.

[ИСО/МЭК 27000:2012, определение 2.30]


3.23

целостность (integrity): Свойство сохранения правильности и полноты активов.

[ИСО/МЭК 27000:2012, определение 2.36]


     3.24 идентификатор объекта (object identifier; OID): Глобальный уникальный идентификатор для информационного объекта.

Примечание - Идентификаторы объекта, использованные в настоящем стандарте, относятся к кодовым системам. Эти кодовые системы могут быть определены в стандарте или локально определены при внедрении. Идентификатор объекта устанавливается с использованием языка ASN.1 для описания абстрактного синтаксиса (ASN.1), определенного в ИСО/МЭК 8824-1 и ИСО/МЭК 8824-2.

3.25

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

[ИСО/ТС 22600]


3.26 полномочие (privilege): Возможность, закрепленная органом за субъектом.

3.27

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

[ИСО 15489-1, определение 3.16]


3.28 роль (role): Комплекс умений и/или действий, связанных с задачей.

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

3.30 политика защищенности (security policy): План или образ действий, принятый для предоставления компьютерной защищенности.

3.31

субъект медицинской помощи (subject of care): Лицо, которому запланирована медицинская помощь, получающее или получившее медицинскую помощь.

[ИСО 18308:2011, определение 3.47]

     

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


     4 Сокращения

EHR -

Электронная медицинская карта (Electronic Health Record);

HL7 -

Международная организация - разработчик стандартов по информатизации здоровья (Health Level Seven International);

OID -

Идентификатор объекта (Object Identifier);

UTC -

Всемирное Скоординированное Время (Coordinated Universal Time).

     

     5 Требования и использование данных аудита

     5.1 Этические и формальные требования

5.1.1 Общие положения

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

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

5.1.2 Политика доступа

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

Политика доступа должна соответствовать ИСО 27799:2008, 7.8.1.2, Политика контроля доступа.

Примечания

1 Считается, что политика доступа должна определять структуру сегмента EHR.

2 В записи аудита политика доступа идентифицируется источником журнала аудита.


Руководство по определению и применению политик доступа можно найти в ИСО/ТС 22600 [6]. Поле "Participant object Permission Policy Set" определено в п.7.6.6 для поддержки ссылок на действующие политики в записи аудита.

5.1.3 Однозначная идентификация пользователей информационной системы

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

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

5.1.4 Роли пользователей

Аудиторский след должен показывать роль пользователя при осуществления записанного действия по отношению к персональной медицинской информации.

Информационные системы, занимающиеся обработкой персональной медицинской информации, должны поддерживать ролевой доступ, способный связывать каждого пользователя с одной или несколькими ролями, а каждую роль к одной или нескольким системным функциям, как рекомендовано в ИСО 27799:2008, 7.8.2.2, Управление полномочиями.

Функциональные и структурные роли задокументированы в ИСО/ТС 21298 [4]. Дополнительные руководства по управлению полномочиями в здравоохранении представлены в ИСО/ТС 22600 [6]

5.1.5 Защищенные записи аудита

Защищенные записи аудита должны создаваться каждый раз, когда к персональной медицинской информации осуществляется доступ или когда она создается, обновляется или архивируется в соответствии с ИСО 27799:2008, 7.7.10.2, Ведение журнала аудита. Записи аудита должны поддерживаться управлением защищенными записями.

     5.2 Пользователи данных аудита

5.2.1 Управление и контроль

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

Под этим подразумевается:

- обнаружение несанкционированного доступа к медицинским картам,

- оценка экстренного доступа,

- обнаружение злоупотребления полномочиями

и поддерживается:

- документально оформленный доступ к предметным областям и

- оценка политик доступа.

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


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

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

5.2.2 Осуществление прав субъектов получения медицинской помощи

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

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

- оценивать учетность для содержания карты,

- определять соответствие с директивами согласия субъекта получения медицинской помощи на доступ или разглашение данных субъекта получения медицинской помощи и

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

5.2.3 Этические и юридические доказательства деятельности поставщика медицинской помощи

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

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

См. Управление документами и подтверждение доказательствами (RM-ES) для EHR в HL7.

     6 События срабатывания

     6.1 Общие положения


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

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

a) события доступа к персональной медицинской информации;

b) события запроса персональной медицинской информации.

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

- события запуска и остановки программы приложения;

- события аутентификации, включающие аутентификацию пользователей;

- события ввода и вывода из/во внешнюю среду;

- события доступа к информации, отличной от персональной медицинской информации;

- события сигналов тревоги защиты, связанные с программой приложения;

- события доступа к журналу аудита, сохраненному в программе приложения;

- события, созданные операционной системой, промежуточным программным обеспечением и т.д.;

- события доступа, созданные посредством использования системных утилит;

- события физического подключения/отключения оборудования от сети;

- события запуска/остановки систем защиты, таких как системы антивирусной защиты;

- события обновления программного обеспечения, включая модификацию программного обеспечения или патчи.

     6.2 Типы событий и их содержание

6.2.1 События доступа к персональной медицинской информации

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


Таблица 1 - События доступа

События

Содержание

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

Когда

Кто

Доступ к чьей информации

6.2.2 События запроса персональной медицинской информации

Запрос в базу данных EHR с целью получения информации рассматривается как событие, подвергаемое аудиту. Событие запроса - это сам запрос, ссылка на персональную медицинскую информацию, возникающая в результате запроса, считается событием доступа. Содержание записи аудита предоставляет информацию о запросе ("когда", "кто", "какие условия запроса"). См. таблицу 2.


Таблица 2 - События запроса

События

Содержание

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

Когда

Кто

Какие условия запроса

     

     7 Содержание записи аудита

     7.1 Общий формат записи


Таблица 3 описывает общий формат записей аудита. О содержании записи по каждому событию см. 8. Формат записи определяется в соответствии с RFC 3881 [13] и DICOM [11] с добавлением дополнительных полей PurposeOfUse (ЦельИспользования) и "ParticipantObjectPolicySet" (КомплексПолитик ОбъектовУчастников).


Таблица 3 - Общий формат записей аудита

Тип

Имя поля

Важность

Описание

Дополнительная информация

Связанное с событием (1)

EventID

M

Идентификатор события, проверяемого аудитом

См. п.7.2


EventActionCode

M

Тип действия, выполненного во время события, проверяемого аудитом



EventDateTime

M

Дата/время наступления события, проверяемого аудитом



EventOutcomeIndicator

U

Успех или неудача события



EventTypeCode

U

Категория события


Связанное с пользователем (1..2)

UserlD

M

Идентификатор пользователя или процесса

См. п.7.3


AlternateUserlD

U

Альтернативный идентификатор пользователя или процесса



UserName

U

Имя пользователя или процесса



UserlsRequestor

U

Индикатор того, что пользователь является или не является инициатором запроса



RolelDCode

U

Спецификация роли, которую играет пользователь в исполнении события



PurposeOfUse

U

Код цели использования данных, к которым осуществлен доступ



NetworkAccessPoint TypeCode

U

Тип точки доступа к сети

См. п.7.4


NetworkAccessPointID

U

Идентификатор точки доступа к сети


Связанное с системой аудита (1)

AuditEnterpriseSitelD

U

Идентификатор участка предприятия аудита

См. п.7.5


AuditSourcelD

M

Уникальный идентификатор источника аудита



AuditSourceTypeCode

U

Код типа источника аудита


Связанное с объектом-участником (0..N)

ParticipantObject TypeCode

M

Код типа объекта-участника

См. п.7.6


ParticipantObject TypeCodeRole

M

Тип кода объекта роли



ParticipantObjectData LifeCycle

U

Идентификатор этапа жизненного цикла данных для объекта-участника



ParticipantObjectlD TypeCode

M

Код типа идентификатора объекта-участника



ParticipantObject PolicySet

U

Комплекс политик доступа для идентификатора объекта-участника


Связанное с объектом-участником (0..N)

ParticipantObject Sensitivity

U

Чувствительность, определенная политикой для Идентификатора объекта-участника

См. п.7.6


ParticipantObjectID

M

Определяет частный случай объекта- участника



ParticipantObjectName

U

Имя объекта-участника, например имя человека



ParticipantObjectQuery

M/U

Содержание запроса для объекта-участника



ParticipantObjectDetail

U

Информация по объекту-участнику


Множественность

Степень важности

(1)


M

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

(0..1)

существует 0 или 1

MC

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

(1..2)

существует 1 или 2

U

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

(0..N)

существует от 0 до N

M/U

Обязательное или необязательное в зависимости от события

     

     7.2 Идентификация события срабатывания

7.2.1 Идентификатор события (Event ID)

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

Степень важности. Обязательное.

Формат/Значения. Закодированное значение, либо определенное разработчиками системы, либо упоминаемое в словаре стандарта. Атрибут "code" ("атрибут") должен быть недвусмысленным и уникальным, по крайней мере, в пределах ID (Идентификатора) источника аудита (см. п.7.5). Примерами ID событий являются имя программы, имя метода или имя функции.

Примечание - Кодирование выстраивается по образцу IHEITITF-1 и TF-1 [12] и ИСО 12052 [1], дополнение 95 к DICOM [11].


Схема XML в RFC 3881 определяет дополнительные атрибуты для определенных реализацией закодированных значений или ссылок на стандарты (см. таблицу 4).


Таблица 4 - Ссылочные атрибуты ID события

Атрибут

Значение

CodeSystem (СистемаКода)

Ссылка на OID

CodeSystemname (ИмяСистемыКодирования)

Имя системы кодирования; настоятельно рекомендуется учитывать для локально определенных кодовых наборов

CodeValue (ЗначениеКода)

Определенный код в пределах системы кодирования

DisplayName (ОтображаемоеИмя)

Значение, которое должно быть использовано при демонстрации и в отчетах

OriginalText (ИсходныйТекст)

Входное значение, которое было переведено в код


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

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

По крайней мере, один из атрибутов, CodeSystem (OID) или CodeSystemName, является обязательным.

7.2.2 Код действия события (EventID)

Описание. Идентификатор типа действия, выполненного в событии аудита.

Степень важности. Обязательное.

Формат/Значения. Перечислены в таблице 5.


Таблица 5 - Коды действия события

Значение

Значение

Примеры

C

Создать

Создать новый объект базы данных, например размещение заказа

R

Прочитать/ Показать/ Распечатать/ Запрос

Отобразить или распечатать данные, например диагноз

U

Обновить

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

D

Удалить

Сделать объекты недоступными

E

Выполнить

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


Логическое обоснование. Данное поле в широком смысле обозначает, какой вид действия был выполнен над объектом-участником.

Примечания

1 Действия, не перечисленные выше, рассматриваются как Выполнить определенную функцию или метод интерфейса объекта или рассматриваются как два или более отдельных событий. Действие приложения, такое как авторизация или использование цифровой подписи, является функцией Выполнить, a ID события ее идентифицирует.

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

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

7.2.3 Дата и время события (Event date and time)

Описание. Определение даты/времени, являющееся однозначным по отношению к местным часовым поясам.

Степень важности. Обязательное.

Формат/Значения. Представление даты/времени, являющееся однозначным при передаче всемирного скоординированного времени (UTC). Время должно быть в формате UTC, как в ИСО 8601:2004, и иметь расхождение с UTC не более 250 мс.

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

Примечание - В распределенной системе хорошей тактикой внедрения является использование своего рода общей временной оси, например, NTP сервера [RFC1305].

7.2.4 Индикатор результата события (Event outcome indicator)

Описание. Обозначает, было ли событие успешным или неуспешным.

Степень важности. Необязательное.

Формат/Значения. Закодированное значение. Код ноль (0) обозначает успех события. Значения неуспеха события не имеют значимости в пределах области применения настоящего стандарта.

Логическое обоснование. Данное поле предназначено для сохранения совместимости со следами аудита согласно IETFRFC 3881 [13].

7.2.5 Код типа события (Event type code)

Описание. Идентификатор категории события.

Степень важности. Необязательное.

Формат/Значения. Перечисление закодированных значений, либо определенные разработчиками системы, либо упоминаемое в словаре стандарта. Схема XML в RFC 3881 определяет дополнительные атрибуты для определенных реализацией закодированных значений или значений, упоминаемых в стандарте, показанных в таблице 6.


Таблица 6 - Ссылочные атрибуты кода типа события

Атрибут

Значение

CodeSystem

Ссылка на OID

CodeSystemname

Имя системы кодирования; настоятельно рекомендуется учитывать для локально определенных кодовых наборов

DisplayName

Значение, которое должно быть использовано при демонстрации и в отчетах

OriginalText

Входное значение, которое было переведено в код


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

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

     7.3 Идентификация пользователя

7.3.1 Идентификатор пользователя (User ID)

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

Степень важности. Обязательное.

Формат/Значения. Текстовая строка идентификатора пользователя из системы аутентификации. Уникальное значение в пределах Идентификатора Источника события (см. п.7.4).

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

Примечания

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

2 Для узловой аутентификации, где идентифицируется только оборудование или процессы системы, а не пользователь-человек, Идентификатор пользователя считается именем узла.

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

7.3.2 Альтернативный идентификатор пользователя (Alternative user ID)

Описание. Альтернативный уникальный идентификатор для пользователя.

Степень важности. Необязательное.

Формат/Значения. Текстовая строка идентификатора пользователя из системы аутентификации. Данный идентификатор, при его наличии, будет известен общей системе аутентификации.

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

7.3.3 Имя пользователя (User name)

Описание. Значимое для человека имя пользователя.

Степень важности. Необязательное.

Формат/Значения. Текстовая строка.

Логическое обоснование. Идентификатор пользователя и Альтернативный идентификатор пользователя могут быть внутренними или же скрытыми значениями. Данное поле помогает аудитору при идентификации реального пользователя.

7.3.4 Пользователь - инициатор запроса (User is requestor)

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

Степень важности. Необязательное.

Формат/Значения. Булевское значение, стандартное/принятое значение - "true" ("истина").

Закупки не найдены
Свободные
Р
Заблокированные
Р
Роль в компании Пользователь

Для продолжения необходимо войти в систему

После входа Вам также будет доступно:
  • Автоматическая проверка недействующих стандартов в закупке
  • Создание шаблона поиска
  • Добавление закупок в Избранное