Заметки на просторах. Валидация КС

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

Одним из обязательных элементов платформы любой системы является журнал регистрации событий (или еще встречается словосочетание “лог системы”). В английском варианте также употребляется “Audit trail”.  Всем известно, что его задача — запись в хронологическом порядке без возможности изменения все значимые действия пользователя в системе.

В приложении 11 Правил надлежащей производственной практики видим такую фразу:

31. (12.3) Создание, изменение и аннулирование прав доступа должно быть зарегистрировано.

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

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

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

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

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

Другой интересной особенностью является хранение данного журнала в отдельно расположенном файле. Это решение было весьма распространенным у производителей софта для управления хроматографами лет цать назад. В данный момент это решение применяет самая распространенная во всех отраслях платформа в странах СНГ. И предлагается управлять этим файлом используя отдельное ПО для баз данных (отдельное от основной БД). Весьма сомнительно, что системный администратор будет рад такому “бесплатному приложению” к основной базе. Установить инспектору, что журнал хранится отдельно от основной БД, фактически невозможно, если этого не отражают спецификации. Хотя, если он прочитал этот текст…

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

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

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

Подписывайтесь на каналы PHARM COMMUNITY:

   
Просмотров: 528
Поделитесь с коллегами:

7 комментариев к “Заметки на просторах. Валидация КС”

  1. А такой простой вариант как запись всех ключевых параметров каждую секунду в файл на каждую дату в носитель информации — флешку, которая устанавливается в сенсорную панель, которая управляет определенной установкой?
    Данный метод применяем с некоторого времени в наших установках.
    Что тут не так? Возможность кодировки сомнительна, файл получается аналогичен экселевскому, но возможность подлога тогда надо исключать другими мероприятиями 🙂

  2. Гложет меня этот термин audit trail.

    Ранее предлагался вариант контрольный журнал, но потом я пересматривал определения разных похожих объектов и пришел к выводу, что такой перевод слишком сильно перекликается с переводами system log, log file и event log, и приводит к путанице. В базе Microsoft по локализации софта есть следующие два варианта. Чисто для себя больше склоняюсь к варианту журнал аудита, как более благозвучному и лучше отражающему определение этого объекта. Аудиторский след для меня звучит как оставленное аудитором что-либо в системе.

    • Полностью согласен, Антон! Аудиторский след — это то, что оставлено пользователем, валидатором или администратором при выполнении действия в системе. То есть является доказательством того, что действие было произведено в реальности. Это уже отмечал Александр Белинский.

  3. По поводу п. 12.3 — очень простой пример — создание, модификация или удаление учетных записей, например, для систем HMI/SCADA капсулятора или системы водоподготовки. Можем рассмотреть и заведомо простые HMI машин наполнения или этикетировки. Учетные записи там создаются, права нарезаются. Никакими аудит-трейлами там часто даже и не пахнет. Вопрос — есть ли у коллег опыт регуляторного диалога на этот счет? Например с зарубежными инспекциями. Ведь на примере той же этикетировки — мы просматриваем качество нанесения этикетки автоматизированно для 100 % продукции, так же для 100 % продукции считывается штрих-код. Счетчики машины проверены, устройства отбраковки функционируют и ежесменно проверяются. В этом случае нам важно понимать, когда была создана и модифицирована учетная запись, нажавшего кнопку старт на машине?

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

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

  4. Другой интересной особенностью является хранение данного журнала в отдельно расположенном файле. Это решение было весьма распространенным у производителей софта для управления хроматографами…

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

    По audit trail напишу позже отдельный комментарий.

    • Да, вполне вероятно, что в какой-то момент платформа получила данную доработку по этой причине. И далее не развивалась в этом месте. Конечно, разграничением доступа на уровне политик Windows можно решить вопрос с несанкционированным доступом. Но если этот файл не подвергать бэкапированию, то провести нормальное восстановление будет проблематично. Ведь журнал регистрации событий это журнал транкзакций для основной базы данных. Не будет журнала транкзакций — все даты в основной БД будут потеряны. Наверное, администратор БД (совместно с пользователями) может восстановить их, но это ручной процесс и всегда гарантирован положительный исход.

Оставьте комментарий