Уведомления
Очистить все

Контрольный (аудиторский) след (audit trail)

   RSS

0
Автор темы

Уважаемые коллеги, часто и на данном форуме и на других площадках возникает вопрос о том, как реализовать требование Приложение 11 GMP в части аудиторского следа.

Немного наводит "тень на плетень" кажущаяся "нестрогость" формулировки:

Т.е. с одной стороны нужно основываться на анализе рисков, с другой стороны понятно, что лаконичной "отмазки" вида "рисков не выявлено" не достаточно ни в каком приближении. Немного более детально эти же требования изложены в рамках документа OECD GLP (даром, что для лабораторной деятельности, но тезисы могут быть полезны и производственникам, и дистрибьюторам):

2021 01 22 09 49 51

Интересны мнения коллег на эту, уверен, перманентно актуальную тему. В частности нашёл в одной из швейцарских FS-ок такое обоснование (вполне разумное), мол, если первичные данные в системе SCADA не могут быть удалены и/или модифицированы - аудиторский след не нужен. Резонно, если речь идёт о данных мониторинга параметров микроклимата, например. А как быть с параметрами рецептур паровых стерилизаторов? Разграничение прав доступа читается (и даже такое, в целом логичное, требование сформулировано в п. 12 Приложения 11 GMP) - а вот в той части, что например, супервайзер взял, да поменял параметры рецептуры стерилизации - нужно ли это пеленговать? Или если предусмотрен контроль распечатки в составе досье серии, мол, точно ли было 121-15 и если да - "хоть трава не расти"?

Другой вопрос - хроматографы. Важно понимать, что не реализуется ситуация, когда из 7 общих испытаний выбирают "нужные" 3 или не выполняют их до тех пор, пока не получится "нужный результат". Там audit trail для таких целей must have.

Тут широкое поле для обсуждений.

2 ответа(-ов)
2

Здравствуйте, Александр.

Тема действительно актуальна, хотя и не новая.

Многие ответы на ваши вопроси есть в приложении М4 в ISPE Data Integrity

image

А в частности в разделе 9.3 Application and Use of Audit Trails.

ISPE пошли дальше, и в новом гайде от них, Data integrity by design, есть много разных рассуждений касательно контрольного следа. Но, там нет единого раздела про контрольный след, он гармонично вплетен в весь документ. Книжечка получилась весьма достойная и наталкивает на многие идеи и размышления, посмотрите и там ответы на ваши вопросы.

Опубликовано: @messer

В частности нашёл в одной из швейцарских FS-ок такое обоснование (вполне разумное), мол, если первичные данные в системе SCADA не могут быть удалены и/или модифицированы - аудиторский след не нужен. Резонно, если речь идёт о данных мониторинга параметров микроклимата, например. А как быть с параметрами рецептур паровых стерилизаторов? Разграничение прав доступа читается (и даже такое, в целом логичное, требование сформулировано в п. 12 Приложения 11 GMP)

Вот это кстати и есть часть того анализа рисков где и когда контрольный след обязателен, а когда нет.

Что касается как это реализовано где я работаю, так мы пошли другим путем, если система GxP critical или Business critical (controlled system), то там в URS обязательно включены требований по комплаенсу и там же есть часть требований к контрольному следу.

В остальных системах, не критичных, рассматриваем индивидуально, исходя что система будет делать и нужен ли там контрольный след и что он должен ловить.

Это в последствии и приводит к разному объёму валидации для разных категорий систем.

Так же, в случаи с GxP critical или Business critical в пакет документации входит оценка рисков (FRA functional risk assessment) и там уже детально разбирается по полочкам какие данные нужно просматривать и как в системе реализован контрольный след, что он отлавливает, что выдает и в какой форме и так далее. Аналогично и с уровнями доступа.

Опубликовано: @messer

Другой вопрос - хроматографы. Важно понимать, что не реализуется ситуация, когда из 7 общих испытаний выбирают "нужные" 3 или не выполняют их до тех пор, пока не получится "нужный результат". Там audit trail для таких целей must have.

Касательно хроматографов, в ISPE Data Integrity даже есть кусок раздела посвященный этой теме (testing into compliance), точнее они говорят что так нельзя и как такое отслеживать.

Надеюсь я сказал хоть что то новое для вас 😊

0

Добрый день, коллеги! Все, действительно, идет от правильной разработки КС.

Есть разные случаи и со SCADA. К примеру, глубина хранения суточных архивов у системы такого типа была 1 год (асептический розлив, инъекции). Резервное копирование отсутствовало.

Пример со стерилизатором требует дополнительной информации. Не сталкивался в практике с такими объектами.

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

Мы, как и Владимир, имеем собственную практику разработки КС. И, действительно, шли по пути от регуляторных требований к их практическому воплощению (т.к. наша система GMP-критичная).

И, т.к. вы упомянули такой хороший инструмент, как FRA, просим поделиться деталями))).

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

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

Ну и собственно вот и весь секрет, как и везде, ничего нового, кусок из GAMP 5 🙂 

 

Благодарю, Владимир. Емко и по делу.

Поделиться: