Уважаемые коллеги, часто и на данном форуме и на других площадках возникает вопрос о том, как реализовать требование Приложение 11 GMP в части аудиторского следа.
Немного наводит "тень на плетень" кажущаяся "нестрогость" формулировки:
Т.е. с одной стороны нужно основываться на анализе рисков, с другой стороны понятно, что лаконичной "отмазки" вида "рисков не выявлено" не достаточно ни в каком приближении. Немного более детально эти же требования изложены в рамках документа OECD GLP (даром, что для лабораторной деятельности, но тезисы могут быть полезны и производственникам, и дистрибьюторам):
Интересны мнения коллег на эту, уверен, перманентно актуальную тему. В частности нашёл в одной из швейцарских FS-ок такое обоснование (вполне разумное), мол, если первичные данные в системе SCADA не могут быть удалены и/или модифицированы - аудиторский след не нужен. Резонно, если речь идёт о данных мониторинга параметров микроклимата, например. А как быть с параметрами рецептур паровых стерилизаторов? Разграничение прав доступа читается (и даже такое, в целом логичное, требование сформулировано в п. 12 Приложения 11 GMP) - а вот в той части, что например, супервайзер взял, да поменял параметры рецептуры стерилизации - нужно ли это пеленговать? Или если предусмотрен контроль распечатки в составе досье серии, мол, точно ли было 121-15 и если да - "хоть трава не расти"?
Другой вопрос - хроматографы. Важно понимать, что не реализуется ситуация, когда из 7 общих испытаний выбирают "нужные" 3 или не выполняют их до тех пор, пока не получится "нужный результат". Там audit trail для таких целей must have.
Тут широкое поле для обсуждений.
Здравствуйте, Александр.
Тема действительно актуальна, хотя и не новая.
Многие ответы на ваши вопроси есть в приложении М4 в ISPE Data Integrity
А в частности в разделе 9.3 Application and Use of Audit Trails.
ISPE пошли дальше, и в новом гайде от них, Data integrity by design, есть много разных рассуждений касательно контрольного следа. Но, там нет единого раздела про контрольный след, он гармонично вплетен в весь документ. Книжечка получилась весьма достойная и наталкивает на многие идеи и размышления, посмотрите и там ответы на ваши вопросы.
В частности нашёл в одной из швейцарских FS-ок такое обоснование (вполне разумное), мол, если первичные данные в системе SCADA не могут быть удалены и/или модифицированы - аудиторский след не нужен. Резонно, если речь идёт о данных мониторинга параметров микроклимата, например. А как быть с параметрами рецептур паровых стерилизаторов? Разграничение прав доступа читается (и даже такое, в целом логичное, требование сформулировано в п. 12 Приложения 11 GMP)
Вот это кстати и есть часть того анализа рисков где и когда контрольный след обязателен, а когда нет.
Что касается как это реализовано где я работаю, так мы пошли другим путем, если система GxP critical или Business critical (controlled system), то там в URS обязательно включены требований по комплаенсу и там же есть часть требований к контрольному следу.
В остальных системах, не критичных, рассматриваем индивидуально, исходя что система будет делать и нужен ли там контрольный след и что он должен ловить.
Это в последствии и приводит к разному объёму валидации для разных категорий систем.
Так же, в случаи с GxP critical или Business critical в пакет документации входит оценка рисков (FRA – functional risk assessment) и там уже детально разбирается по полочкам какие данные нужно просматривать и как в системе реализован контрольный след, что он отлавливает, что выдает и в какой форме и так далее. Аналогично и с уровнями доступа.
Другой вопрос - хроматографы. Важно понимать, что не реализуется ситуация, когда из 7 общих испытаний выбирают "нужные" 3 или не выполняют их до тех пор, пока не получится "нужный результат". Там audit trail для таких целей must have.
Касательно хроматографов, в ISPE Data Integrity даже есть кусок раздела посвященный этой теме (testing into compliance), точнее они говорят что так нельзя и как такое отслеживать.
Надеюсь я сказал хоть что то новое для вас ?
Добрый день, коллеги! Все, действительно, идет от правильной разработки КС.
Есть разные случаи и со SCADA. К примеру, глубина хранения суточных архивов у системы такого типа была 1 год (асептический розлив, инъекции). Резервное копирование отсутствовало.
Пример со стерилизатором требует дополнительной информации. Не сталкивался в практике с такими объектами.
Хроматографы разные нужны). Понятно (но неприемлемо), когда используемый хроматограф для целей разработки имеет установленное ПО на рабочую станцию, а не на сервер. Пользователь имеет весь пул паролей, меняет системное время и отправляет прибор в прошлое, даже дальше времени его установки в лаборатории.
Мы, как и Владимир, имеем собственную практику разработки КС. И, действительно, шли по пути от регуляторных требований к их практическому воплощению (т.к. наша система GMP-критичная).
И, т.к. вы упомянули такой хороший инструмент, как FRA, просим поделиться деталями))).
Володимир Коваль 23.01.2021 12:01 @microb, представьте ексель файл по оценке рисков подходом FMEA, где на одной странице есть три больших части: изначальная оценка рисков и их классификация, возможные последствия отказа функций, дальше коректирущие действия, чтобы снизить риск (здесь может быть все что угодно: от дополнительных доработок системи до тестирования на разных этапах) и оценка после этих действий, и сразу же указываем в каком типе документа это будет отражено и третья часть: остаточная оценка рисков, если коректирущие действия не дали желаемого результата.
В конце получается что часть функционала нам не так интересна как другая часть, и вот на то что не критично, времени уделяется совсем мало если уделяется вообще. Но вот то, что важно, покрывается тестами вдоль и поперёк.
Ну и собственно вот и весь секрет, как и везде, ничего нового, кусок из GAMP 5 🙂
