Организация аудита компьютеризированных систем

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

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

Как показывает практика, самыми животрепещущими аспектами Заказчика являются:

— выбор аудиторской команды,

— определиться с выбором стандарта и рекомендаций по оценке объекта,

— определиться с планом аудита.

Выбор аудиторской команды

Именно команды, считают авторы, т.к. еще не встречали центры компетенций в ИТ, GxP и автоматизируемом процессе в одном лице.

Стандартная практика в виде оценки компетенций команды поможет вам определиться с данным вопросом. Имеет значение и специальность по диплому, общий стаж работы, стаж в фарм. отрасли (для ИТ-специалиста) / стаж работы на предприятии/складе/лаборатории, наличие дополнительного образования (например, по правилам GxP/ по наилучшим практикам управления качеством в ИТ), участие в профессиональных сообществах (к примеру, ISPE, PDA).

Решающими компетенциями могут являться работа в команде по валидации компьютеризированных систем (список объектов должен прилагаться), а также построение СМК в ИТ отделе или компании.

Выбор стандарта и рекомендаций

Да-да, бывает и такое. К примеру, это ERP-система, работающая на фармскладе в России. Какой национальный нормативный документ регулирует складское хранение ЛС? Приказ Минздрава РФ от 31.08.2016 N 646н «Об утверждении правил надлежащей практики хранения и перевозки лекарственных препаратов для медицинского применения» не содержит требований к компьютеризированным системам, следовательно, не может быть применен напрямую в данном случае. Существует проект Приказа Министерства здравоохранения РФ «Об утверждении правил надлежащей дистрибьюторской практики лекарственных препаратов для медицинского применения», но его статус на настоящий момент не известен. Текст его неплохо соответствует оригиналу EU GDP. Пункт 3.3.1 содержит краткий, емкий, но не всеобъемлющий перечень требований, который рационально применять к данному объекту. Можно дополнить его требованиями приложения 11 EU GMP, как вариант минимум.

В случае, если в объект вносятся изменения, то необходимо определиться с порядком кодирования, тестирования и выпуска релизов. Это могут быть рекомендации GAMP. Плюс не забываем по управление качеством в ИТ — ITSM.

План аудита

Что и как смотреть аудиторам? На этот вопрос отвечает (насколько это возможно) план аудита. Как его получить? Для начала наметим основные части КС (см. рис. ниже. Перевод и дизайн – Александр Белинский).

Структура КС согласно PIC/S

Авторство визуализации принадлежит PIC/S (глубже не было резона прослеживать). И это хорошо для первичного понимания проблематики. В свою очередь, мы решили выделить из приложения 11 правил GMP некоторые позиции, сдобрить их рекомендациями GAMP и ITSM.

Т.к. каждая КС имеет в своем составе некоторые неспецифические (более или менее) элементы, которые имеет смысл объединить в условную группу “Платформа”. В нее могут войти такие элементы, процессы и вопросы, как:

  • Конфигурация ПО (архитектура);
  • Конфигурация инфраструктуры (серверы, рабочие станции, ЛВС);
  • Аутентификация (тип);
  • Управление учетными записями и правами доступа (наличие функционала);
  • Резервное копирование (процесс);
  • Способ хранения данных в БД (см. ниже);
  • Журнал регистрации событий (наличие, нередактируемость, фиксация критических событий);
  • Сервер резервных копий.

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

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

  • Требований GxP к реализации основного процесса;
  • Требования по целостности данных.

В случае складской ERP, к примеру, интересны два аспекта: реализация механизма разрешения серии (партии) к реализации и редактирование данных проводок.

Наличие дистрибутивов ПО:

  • специализированное ПО (например, клиентская и серверная части);
  • серверная и клиентская ОС;
  • ПО для СУБД (при необходимости).

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

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

Общая документация:

  • руководство пользователя (от интегратора/разработчика);
  • инструкции по выполнению операций.

Политика безопасности:

  • настройки безопасности сервера;
  • настройки безопасности рабочей станции.

Процедуры локального управления данной КС:

  • управление резервным копированием и восстановлением;
  • управление пользователями и правами доступа.

Процедуры глобального управления КС (элементы ITSM):

  • Валидация КС
  • Периодическая оценка;
  • Управление изменениями в КС;
  • Управление инцидентами и отклонениями в КС;
  • Управление кодированием;
  • Управление релизами;
  • Управление конфигурациями.

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

  • URS;
  • FS;
  • DS;
  • протокол оценки рисков соответствия системы требованиям GxP.

А также в случае последующего внесения изменений — их описание в виде спецификаций.

И, наконец, Валидационная документация. Здесь могут быть:

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

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

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

  1. Оценка документации.
  2. Осмотр и оценка оборудования входящего в состав КС.
  3. Интервьюирование сотрудников.
  4. Демонстрация работы КС.

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

Вместо заключения

Планируется несколько статей, посвященных проблематике валидации КС и управлению ИТ в целом. Конструктивные предложения приветствуются.

Соавтор — Дмитрий Владимирович Парепко. ИТ-эксперт с большим опытом внедрения и администрирования систем различной сложности.

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

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

5 комментариев к “Организация аудита компьютеризированных систем”

  1. Большое спасибо за статью!

    Подскажите, пожалуйста, в каких случаях можно и можно ли объединять URS, FS и DS?

    Спасибо.

    • Благодарю за отзыв!

      Я считаю (не являюсь законодателем мод), что спецификации объединить возможно, если:

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

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

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

    • Я тоже думаю, что это непринципиально сколько будет документов 1 или 3. Собственно, не встречал жесткой регламентации, что URS, FS, DS должны быть отдельными документами и точка. Например, если вам надо отвалидировать какую-то простую маленькую программу, например, WinMD5, то нет никакого смысла на 3 кнопки и одну операцию делать 3 отдельных документа. Мало того, все 5 (DS тут не нужна) можно представить в виде одного документ и закрыть вопрос. Главное руководствоваться здравым смыслом и удобством использования документации в организации.