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

Информатизация здоровья

ЖУРНАЛЫ АУДИТА ДЛЯ ЭЛЕКТРОННЫХ МЕДИЦИНСКИХ КАРТ

ISO 27789:2013

Health informatics —Audit trails for electronic health records

(IDT)

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

Москва

Стандартинформ

2016

Предисловие

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

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

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 5 июля 2016 г. № 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)

© Стандартинформ, 2016

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ГОСТ Р ИСО 27789-2016

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

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

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

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

Тип Имя поля Важ ность Описание Дополнительная информация Связанное с событием (1) EventID M Идентификатор события, проверяемого аудитом См. п. 7.2 EventActionCode M Тип действия, выполненного во время события, проверяемого аудитом EventDateTime M Дата/время наступления события, проверяемого аудитом EventOutcomelndicator и Успех или неудача события EventTypeCode и Категория события Связанное с пользователем (1-2) UserlD м Идентификатор пользователя или процесса См. п. 7.3 AlternateUserlD и Альтернативный идентификатор пользователя или процесса UserName и Имя пользователя или процесса UserlsRequestor и Индикатор того, что пользователь является или не является инициатором запроса RolelDCode и Спецификация роли, которую играет пользователь в исполнении события PurposeOfUse и Код цели использования данных, к которым осуществлен доступ NetworkAccessPoint TypeCode и Тип точки доступа к сети См. п. 7.4 NetworkAccessPointID и Идентификатор точки доступа к сети Связанное с системой аудита (1) AuditEnterpriseSitelD и Идентификатор участка предприятия аудита См. п. 7.5 AuditSourcelD м Уникальный идентификатор источника аудита AuditSourceTypeCode и Код типа источника аудита Связанное с объектом-участником (0..N) ParticipantObject TypeCode м Код типа объекта-участника См. п. 7.6 ParticipantObject TypeCodeRole м Тип кода объекта роли ParticipantObjectData LifeCycle и Идентификатор этапа жизненного цикла данных для объекта-участника ParticipantObjectID TypeCode м Код типа идентификатора объекта-участника ParticipantObject PolicySet и Комплекс политик доступа для идентификатора объекта-участника

7

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

Тип Имя поля Важ ность Описание Дополнительная информация Связанное с объектом-участником (0..N) ParticipantObject Sensitivity и Чувствительность, определенная политикой для Идентификатора объекта-участника См. п. 7.6 ParticipantObjectl D м Определяет частный случай объекта-участника ParticipantObjectName и Имя объекта-участника, например имя человека ParticipantObjectQuery м/и Содержание запроса для объекта-участника ParticipantObjectDetail и Информация по объекту-участнику Множественность Степень важности (1) М Обязательное (0..1) существует 0 или 1 МС Условно-обязательное (1-2) существует 1 или 2 и Необязательное (0..N) существует от 0 до N м/и Обязательное или необязательное в зависимости от события

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 — Ссылочные атрибуты Ю события

Атрибут Значение CodeSystem (СистемаКода) Ссылка на OID CodeSystemname (ИмяСистемыКодирования) Имя системы кодирования; настоятельно рекомендуется учитывать для локально определенных кодовых наборов CodeValue (ЗначениеКода) Определенный код в пределах системы кодирования DisplayName (ОтображаемоеИмя) Значение, которое должно быть использовано при демонстрации и в отчетах OriginalText (ИсходныйТекст) Входное значение, которое было переведено в код

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

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

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

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

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

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

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

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

Значение Значение Примеры С Создать Создать новый объект базы данных, например размещение заказа R Прочитать/ Показать/ Распечатать/ Запрос Отобразить или распечатать данные, например диагноз и Обновить Обновить данные, например внесение изменений в персональную медицинскую информацию D Удалить Сделать объекты недоступными Е Выполнить Выполнить функцию системы или приложения, например поиск, извлечение или использование метода объекта

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

Примечания

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

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)

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

9

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

Формат/Значения. Перечисление закодированных значений, либо определенные разработчиками системы, либо упоминаемое в словаре стандарта. Схема 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)

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

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

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

ГОСТ Р ИСО 27789-2016

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

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

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

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

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

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

7.3.5    Идентификационный код роли (Role ID code)

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

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

Формат/Значения. Закодированное значение с атрибутом «code», которому присвоено значение кода роли или текст от системы авторизации. Может быть указано несколько значений, так как может использоваться несколько систем ролевого доступа и/или классификаций. Обратите внимание, что и в ИСО 27799:2008, п. 7.8.2.2 (Управление полномочиями), и в ИСО/ТС 22600 [6] указывается, что пользователь системы медицинской информации, содержащей персональную медицинскую информацию, имеет доступ к сервисам в единственной роли (т. е. пользователям, зарегистрированным с несколькими ролями, приписывается единственная роль во время каждого сеанса доступа к системе медицинской информации).

Рекомендуется использовать систему кодирования, совместимую с функциональными ролями, определенными в ИСО/ТС 21298 [4] и перечисленными в таблице 7.

На идентификацию словаря для данного списка закодированных значений может ссылаться следующий OID, обозначенный с использованием Языка ASN.1 для описания абстрактного синтаксиса (ASN.1), определенного в ИСО/МЭК 8824-1 [7] и ИСО/МЭК 8824-2 [8].

Идентификация словаря. ИСО (1) стандарт (0) функциональные и структурные роли (21298) словарь функциональных ролей (4).

Таблица 7 — Идентификационные коды функциональных ролей

rolejdentifier role_name Описание 01 Субъект получения медицинской помощи Основной субъект данных электронной медицинской карты 02 Агент субъекта получения медицинской помощи Например, родитель, опекун, лицо, осуществляющее уход, или другой законный представитель 03 Персональный работник здравоохранения Работник или работники здравоохранения, находящиеся в тесной связи с пациентом, часто семейный врач пациента 04 Уполномоченный работник здравоохранения Назначается субъектом получения медицинской помощи ИЛИ назначается медицинским учреждением (при назначении руководством, практикой и т. д., например, функция аварийного обхода) 05 Работник здравоохранения Сторона, вовлеченная в предоставление прямой медицинской помощи пациенту 06 Работник лечебно-оздоровительных учреждений Сторона, косвенно вовлеченная в уход за пациентом, обучение, исследование и т. д. 07 Администратор Любые другие стороны, поддерживающие оказание услуг пациенту

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

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

Таблица 8 — Ссылочные атрибуты кода идентификатора роли

Атрибут Значение CodeSystem Ссылка на ОЮ CodeSystemname Имя системы кодирования; настоятельно рекомендуется учитывать для локально определенных кодовых наборов DisplayName Значение, которое должно быть использовано при демонстрации и в отчетах OriginalText Входное значение, которое было переведено в код

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

Дополнительную информацию можно найти в ИСО/ТС 22600 [6] и ИСО/ТС 21298 [4].

7.3.6 Цель использования (Purpose of use)

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

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

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

Рекомендуется использовать систему кодирования, совместимую со схемой классификации целей для обработки персональной медицинской информации, определенных в ИСО/ТС14265 [2] и перечисленных в таблице 9.

На идентификацию словаря для данного списка закодированных значений может ссылаться следующий OID, обозначенный с использованием языка ASN.1 для описания абстрактного синтаксиса (ASN.1), определенного в ИСО/МЭК 8824-1 [7] и ИСО/МЭК 8824-2 [8].

Идентификация словаря. ИСО (1) стандарт (0) Классификация целей для обработки персональной медицинской информации (14265) Терминология для классификации целей для обработки персональной медицинской информации (1).

Таблица 9 — Классификация целей

Код Термин классификации Описание (информативное) 1 Оказание клинической помощи отдельному субъекту получения медицинской помощи Для информирования лиц или процессов, ответственных за предоставление медицинских услуг субъекту получения медицинской помощи 2 Оказание неотложной помощи отдельному субъекту получения медицинской помощи Для информирования лиц, которые должны незамедлительно предоставить медицинские услуги субъекту получения медицинской помощи, возможно, требуя политик соглашения и замещения, отличных от относящихся к цели 1, указанной выше 3 Поддержка действий по уходу в пределах организации поставщика услуг для отдельного субъекта получения медицинской помощи Для информирования лиц или процессов, позволяющих другим предоставлять медицинские услуги субъекту получения медицинской помощи, посредством управления действиями и/или средствами

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

Код Термин классификации Описание (информативное) 4 Обеспечение возможности оплаты предоставления помощи отдельному субъекту получения медицинской помощи Для информирования лиц или процессов, обеспечивающих доступность фондов и/или разрешений со стороны плательщика для предоставления медицинских услуг субъекту получения медицинской помощи 5 Управление и обеспечение качества медицинского обслуживания Для информирования лиц или процессов, ответственных за определение доступности, качества, безопасности, справедливости и рентабельности медицинских услуг 6 Образование Для поддержки образовательного и профессионального развития работника здравоохранения 7 Наблюдение за здоровьем населения Для информирования лиц или процессов, курирующих вопросы мониторинга населения и групп населения на предмет крупных событий в сфере здравоохранения и последующего вмешательства с целью предоставления услуг здравоохранения или профилактических услуг для соответствующих лиц 8 Чрезвычайные ситуации, являющиеся угрозой для общественной безопасности Для информирования лиц, ответственных за защиту общества, в ситуациях, когда считается, что имеет место значительный риск для членов общества, возможно, требуя политик соглашения и замещения, отличных от относящихся к Цели 7, указанной выше 9 Управление здоровьем населения Для информирования лиц или процессов, ответственных за мониторинг населения и групп населения на предмет событий в сфере здравоохранения, тенденций и результатов с целью информирования по значимым стратегиям и политикам 10 Исследование Для поддержки получения обобщенных знаний 11 Исследования рынка Для поддержки получения знаний, характерных для продукта или организации 12 Судебные процедуры Для информирования лиц или процессов, ответственных за обеспечение соответствия законодательству или законно уполномоченное ведение расследований по уголовным, гражданским и нормативным правонарушениям 13 Назначения субъекта получения медицинской помощи Для информирования субъекта получения медицинской помощи или его/ее законно уполномоченного агента по поддержке интересов субъекта получения медицинской помощи или в случае смерти для поддержки ухода за членом семьи 14 Точно не установленное Раскрытие на основе авторизаций, не требующих указания цели или целей, для которых не применимы другие категории в данном разделе

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

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

7.4.1 Код типа точки доступа к сети (Network access point type code)

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

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

Формат/Значения. Перечисление, как показано в таблице 10.

13

Таблица 10 — Коды типа точки доступа

Значение Содержание 1 Имя машины, включая имя DNS 2 IP-адрес 3 Номер телефона

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

7.4.2 Идентификатор точки доступа к сети (Network access point ID)

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

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

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

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

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

Примеры

1    Идентификатор точки доступа к сети: 192.0.2.2.

Код типа точки доступа к сети: 2 = 1Р-адрес.

2    Идентификатор точки доступа к сети: 610-555-1212.

Код типа точки доступа к сети: 3 = Номер телефона.

7.5 Идентификация источника аудита

7.5.1 Общие сведения

Данные следов аудита могут быть собраны из различных источников, таких как:

-    данные защиты информационных систем;

-    службы каталогов;

-    сервисы определения политик доступа;

-    данные доступа на уровне приложения.

Защищенные сервисы должны получать эти данные.

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

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

14

ГОСТ Р ИСО 27789-2016

7.5.2    Идентификатор объекта предприятия аудита (Audit enterprise site ID)

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

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

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

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

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

7.5.3    Идентификатор источника аудита (Audit source ID)

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

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

Формат/Значения. Текстовая строка уникального идентификатора, по крайней мере, в пределах Идентификатора объекта предприятия аудита.

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

7.5.4    Код типа источника аудита (Audit source type code)

Описание. Код, определяющий тип источника создания события.

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

Формат/Значения. Перечисление закодированных значений, либо определенных разработчиками системы, либо упоминаемое в словаре стандарта. Если значение не определено или не упоминается в стандарте, то значения по умолчанию для атрибута «code» соответствуют указанным в таблице 11.

Таблица 11 — Коды типа источника аудита

Значение Содержание 1 Интерфейс конечного пользователя 2 Прибор или инструмент для получения данных 3 Уровень процесса веб-сервера в многоуровневой системе 4 Уровень процесса сервера приложения в многоуровневой системе 5 Уровень процесса сервера базы данных в многоуровневой системе 6 Сервер безопасности, например контроллер доменов 7 Компонент сети 1—3 уровней по ИСО 8 Системное программное обеспечение уровней 4—6 по ИСО 9 Внешний источник, другой или неизвестный

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

Таблица 12 — Ссылочные атрибуты Кода идентификатора роли

Атрибут Значение CodeSystem Ссылка на OID CodeSystemName Имя системы кодирования; настоятельно рекомендуется учитывать для локально определенных кодовых наборов

ГОСТ Р ИСО 27789-2016

Содержание

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

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

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

4    Сокращения........................................................................4

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

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

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

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

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

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

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

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

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

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

7.4    Идентификация точки доступа ....................................................13

7.5    Идентификация источника аудита .................................................14

7.6    Идентификация объекта-участника ................................................16

8    Записи аудита для отдельных событий.................................................20

8.1    События доступа ...............................................................20

8.2    События запроса ...............................................................25

9    Защищенное управление данными аудита..............................................25

9.1    Меры предосторожности .........................................................25

9.2    Обеспечение доступности системы аудита ..........................................25

9.3    Требования к хранению..........................................................25

9.4    Обеспечение конфиденциальности и целостности следов аудита .......................25

9.5    Доступ к данным аудита..........................................................26

Приложение А (справочное) Сценарии аудита ............................................27

Приложение В (справочное) Сервисы журнала аудита......................................32

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

и документов национальным стандартам Российской Федерации ..............38

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

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

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

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

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

7.6 Идентификация объекта-участника

7.6.1    Общие сведения

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

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

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

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

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

-    лечащий врач и консультирующие направленные лица могут быть определены одновременно;

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

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

7.6.2    Код типа объекта-участника (Participant object type code)

Описание. Код для типа объекта-участника, проверяемого аудитом. Данное значение отличается от роли пользователя или отношения любого пользователя с объектом-участником.

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

Формат/Значения. Перечисление, как показано в таблице 13.

Таблица 13 — Коды типа объекта-участника

Значение Содержание 1 Лицо 2 Объект системы 3 Организация 4 Другое

Введение

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

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

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

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

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

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

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

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

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

цели:

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

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

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

IV

ГОСТ Р ИСО 27789-2016

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

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

V

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

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

Health informatics. Audit trails for electronic health records

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

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 Е 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 саге): Лицо, которому запланирована медицинская помощь, получающее или получившее медицинскую помощь.

[ИСО 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    Роли пользователей

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

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

ГОСТ Р ИСО 27789-2016

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5