Права доступа в клинике и учётная запись break-glass

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

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

Начинать с ролей, а не с людей

Частая ошибка — задавать права каждому сотруднику по отдельности. Это удобно в начале и неподдерживаемо через год: никто не помнит, почему у кого-то есть определённый доступ, и никто не решается его урезать. Правильный подход — определить небольшой набор ролей, задать для каждой роли, что разрешено, и привязать людей к ролям.

Типичная клиника обходится шестью ролями:

Роль	Что да	Что обычно нет
Администратор системы	Настройки, пользователи, права, журнал аудита	Не обязательно просмотр клинической документации
Врач с правом рецепта	Полная карта, визиты, рецепты, назначения и результаты	Изменение настроек системы
Медсестра или средний медперсонал	Клиническая документация, показатели, выполнение назначений	Рецепты, финансовые данные
Передовой коллектив	Журнал, данные пациента, приём, оплата	Полная клиническая документация, результаты лаборатории
Бухгалтерия	Выставление счетов, платежи, финансовые отчёты	Подробное клиническое содержание
Аварийная учётная запись	Временный широкий доступ при условии обоснования и документирования	Повседневное использование

Различие, которое многие упускают

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

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

Что такое учётная запись «разбей стекло»

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

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

Исправный механизм выглядит так:

1. Пользователь запрашивает внеплановый доступ и обязан обосновать его свободным текстом. Нет значения по умолчанию и нет удобного списка для выбора.
2. Доступ даётся немедленно — иначе механизм бесполезен в аварии — и ограничен по времени.
3. Событие ясно фиксируется и появляется в отдельном списке, а не тонет в общем журнале.
4. Назначенный человек регулярно, например раз в неделю, просматривает список и одобряет либо выясняет.

Правило: сдерживание лучше блокировки, когда блокировка может навредить лечению. Человек, знающий, что его доступ появится в списке, который кто-то читает, ведёт себя иначе, чем тот, кто полагает, что никто не проверяет.

Журнал аудита, которым можно пользоваться

Журнал аудита есть почти в каждой системе. Вопрос в том, можно ли задавать ему вопросы. Три вопроса, на которые стоит проверить, что можно ответить за минуты: кто просматривал карту определённого пациента за последние полгода; что просматривал определённый пользователь в определённый день; и какие записи редактировались после того, как были подписаны.

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

Чувствительные случаи внутри клиники

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

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

Рутина проверки на четверть часа

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

1. Список активных пользователей — все ли ещё здесь работают.
2. Список случаев внепланового доступа за последний месяц — каждый ли из них объяснён.
3. Отчёт о просмотрах карт, помеченных как чувствительные.
4. Список прав, изменившихся за месяц, и кто одобрил.

Такая рутина стоит больше любого длинного документа политики, потому что она создаёт ожидание, что кто-то смотрит. А это, в конечном счёте, и есть то, что меняет поведение.

Текущее сопровождение: четыре действия

• Отзыв доступа в день ухода. Звучит само собой разумеющимся, и это самая частая неисправность. Стоит привязать это к процессу увольнения.
• Пересмотр прав дважды в год. Список всех пользователей и их ролей на одной странице. Каждую удивляющую строку — выяснить.
• Никаких общих учётных записей. Общая учётная запись приёма обесценивает весь журнал аудита, потому что нельзя узнать, кто что сделал.
• Временные права по-настоящему истекают. Доступ, выданный заместителю на месяц, должен завершиться сам, а не остаться.

А как быть с руководителем

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

Назад в блог