ГОСТРИСО 27789—2016
отправлены результаты и понимает, что результаты были отправлены 8 офис другого врача. Лаборант пересылает
результаты правильному получателю, и проверяет ARR. чтобы убедиться, что результаты были повторно отправ
лены должным образом (успешный результат события и правильный получатель) и звонит медсестре, чтобы уз
нать. получила ли она их. Медсестра звонит субъекту получения медицинской помощи, чтобы сообщить ему. что
результаты получены.
Некоторые дополнительные уточняющие данные должны быть добавлены в журналы аудита для поддержки
этого сценария, такие как: номера для отслеживания заказа, номера отчетов и т. д. Необходимо будет установить
баланс между добавлением в журналы слишком большого объема уточняющихданных и анализом, который может
устанавливать связь между заказами с запросами в журнале аудита. Возникает вопрос о том. необходимо ли
сде лать это при помощи средств управления потоком работ или же при помощи журнала аудита? Рентгенология
дела ет это подвум направлениям при помощи средств управления потоком работ (подтверждение отправки,
получения и прочтения отчетов, а также номера контейнеров и т. д.). Предоставление отчетов при помощи средств
управле ния потоком работ могут обрабатываться с помощью отдельного аудита — предоставление отчетов
лаборатории и подтверждение БД. Интерфейс может обеспечить возможность согласования журналов отчетности
лаборатории с другими журналами аудита в ходе расследований. Например, сервис сопоставления журналов.
Может существовать отчетность по потоку работ и сервис аудита в рамках информационной системы, будь
то лаборатории назначения или радиология. Также должна учитываться интеграция с логистикой (доставка и т. д.).
Обязательная функциональность. Показывать события, а также отправителя и получателя.
Возможная функциональность. Результаты были отправлены в неправильное место из-за ошибки в реестре
поставщиков и инцидент обнаружил необходимость исправления / обновления реестра поставщиков. Как эта не
обходимость корректирующих действий может автоматически срабатывать и решаться?
Этот сценарий отличается тем. что он не является ни мониторингом в реальном времени, ни управлением, а
использованием системы аудита для проверки потока работ.
В данном сценарии есть некий пользователь, не являющийся администратором, который может использо
вать интерфейс хранилища данных аудита, который должен быть удобным и отличаться от обычного интерфейса.
В этом сценарии возникают следующие вопросы:
- может ли система определить, не потерялось ли сообщение?
- может ли система определить, не произошла ли операция? Так как операции являются событиями, под
лежащими аудиту, эта информация должна быть получена:
- существует ли способ анализа наличия или отсутствия успешно или неуспешно отправленных сообщений?
- если появляется сообщение об ошибке (ошибка отклика), то оно может привязаться к сервису мониторин
га. т. в. если система может это обнаружить, то сообщить о потере;
- для обнаружения несоответствий между полученными уведомлениями и отправленными уведомлениями
существует функция сопоставления/ анализа, которая находится вне сферы действия настоящего стандарта.
Сотрудники службы безопасности также хотели бы знать: если надлежащий специалист не получил сообще
ние из лаборатории в нужное время, то получал ли сообщения кто-нибудь еще в это время?
Отчасти это сценарий потока работ I предоставления отчетов / производительности. Сервис аудита может
передать эту возможность сервису потока работ.
А.7 Случай непредсказуемости операций
Системный администратор больницы замечает необычное количество неудачных операций. После проведе
ния диагностики системы системный администратор может определить, что каждые несколько часов происходит
огромный слад в пропускной способности, но не может определить почему. Администратор проверяет
журналы и понимает, что приложение В посылает каждый заказ в лабораторию по два раза и. как следствие,
происходит перегрузка системы.
Это случай администрирования системы и измерения производительности, такой как сценарий взломанного
сервера. Информация, которая должна быть проверена аудитом, существенно отличается от примеров использо
вания конфиденциальности и защищенности.
Общая система аудита может оставаться последовательной повсеместно и использовать те же возможности
отправлять и хранить журналы. Информация, которая будет зарегистрирована и то. где она будет загружена, будет
определяться местной политикой конфигурации.
Во-первых, это веб-сервис для ARR интерфейса, который говорит «возвращайте мне все. что покажется вам
необычным», где необычное — это, например, «более пяти последовательных неудачных попыток или неудачных
результатов операций».
В современном мире этот вид аудита осуществляется путем предоставления администратору возможности
проанализировать поток необработанных данных при помощи наиболее общих инструментов.
Система гложет не дать аналитические данные для входящего потока аудита, но может дать доступ к необ
работанному потоку аудита через интерфейс в случав, если кто-то захочет осуществить его анализ.
Этот случай может быть расширен, включив такие переменные, как беспроводной мониторинг с использова
нием медицинских приборов и удаленный мониторинг объектами получения медицинской помощи.
30