Добрый вечер, для кого-то день, а может ночь... уважаемые форумчане.
Столкнулся с такой вот "проблемой" как квалификация в эксплуатации компьютеризированной системы мониторинга частиц. А именно интересует, что по сути мы должны проверить (подтвердить) в PQ? Начинаю отталкиваться от того, что в первую очередь должны проверить точность показаний (измерений)! А каким методом? В ГОСТах Р ИСО про проверку точности мониторинга мало что говорится (в основном везде подтверждаем класс чистоты)!
Приходит мысль, что к точкам мониторинга концентрации мы ставим проверенные портативные счетчики и потом спустя время (?) сравниваем результаты и смотрим не выходят ли они за пределы погрешности (делаем три измерения, добавляем испытание с распылителем частиц), ну и на основании результатов делаем вывод, что система адекватно работает. Если мысли идут в неправильном направлении, прошу поправить или подсказать...
На тему PQ - тестов систем мониторинга аэрозольных частиц, можно пообщаться и узнать у сотрудников компании АКВААНАЛИТИК. https://aquaanalytic.com/
Они проектируют, монтируют и проводят валидацию систем мониторинга, в том числе и PQ-тесты.
Если вы именно про компьютеризированную систему для системы мониторинга, то на PQ1 проверяется вообще документация по процессам эксплуатации (СОПы по резервному копированию, доступам, проверке журналов, инцидентам и т.д.) и проверяются некоторые процессы эксплуатации, не являются функциями самого ПО (типа резервного копирования или предоставления доступа, если это не является встроенными функциями).
А если вы про квалификацию оборудования, то да, можно методом сравнения. Параметры счетчиков для мониторинга должны быть, по идее, такие же как у счетчиков, которыми устанавливается класс. Как минимум старый iso 14644-3:2005 предлагал такие характеристики (во вложенном скрине). Можно провести одновременно в одном месте по ряду замеров (обычным счетчиком и счетчиком из системы мониторинга) и определить статистическое равенство значений по методу Стьюдента.
Но если у вас датчики мониторинга стоят в классе А, где они постоянно по нулям, то можно сделать просто тест на обнаружение, т.е. просто распылить частицы и показать, что система их, в принципе, фиксирует. А количественные измерения в данном случае особо не имеют смысла.
Если вы именно про компьютеризированную систему для системы мониторинга, то на PQ1 проверяется вообще документация по процессам эксплуатации (СОПы по резервному копированию, доступам, проверке журналов, инцидентам и т.д.) и проверяются некоторые процессы эксплуатации, не являются функциями самого ПО (типа резервного копирования или предоставления доступа, если это не является встроенными функциями).
Предоставление доступа и резервное копирование включил в OQ. Это будет ошибочно?
такие же как у счетчиков, которыми устанавливается класс. Как минимум старый iso 14644-3:2005 предлагал такие характеристики (во вложенном скрине). Можно провести одновременно в одном месте по ряду замеров (обычным счетчиком и счетчиком из системы мониторинга) и определить статистическое равенство значений по методу Стьюдента.
Но если у вас датчики мониторинга стоят в классе А, где они постоянно по нулям, то можно сделать просто тест на обнаружение, т.е. просто распылить частицы и показать, что система их, в принципе, фиксирует. А количественные измерения в данном случае особо не имеют смысла.
Да у нас стоят датчики мониторинга в классе А и Б. А разве мы не должны подтверждать, что перерасчет в компьютеризированной системе правильный?
Предоставление доступа и резервное копирование включил в OQ. Это будет ошибочно?
Это не смертельно. Главное, чтобы было проверено.
А разве мы не должны подтверждать, что перерасчет в компьютеризированной системе правильный?
Если есть пересчет, то должны, но ведь пересчет ничего общего не имеет с точностью датчиков.
На самом деле вопрос задан в отрыве от контекста. А общий контекст - это валидация КС в целом. Как можно ответить на вопрос, что нужно сделать в рамках PQ, если не вполне понятно, что было сделано на предыдущих этапах. В очередной раз выскажу крамолу - разбивать валидацию КС на традиционные IQ, OQ, PQ можно, ошибкой это не будет, более того, значится в ряде руководств. Но очень часто выделение этапов бессмысленно и вот почему. Это не только моё мнение, но и позиция ряда разработчиков программных продуктов, которые поставляются не только в фарма - СЭД, ERP etc. У них немного другая терминология и чуть другое построение этапов - функциональное тестирование, интеграционное тестирование, регрессионное тестирование и т.п. Впрочем, эти особенности характерны для случаев, когда валидация сопровождает разработку. Система мониторинга в этом смысле проще, как правило. КС - это в принципе своеобразный "костыль для мозга" - без неё вы "пешком" определяете, вышли ли ваши параметры за установленные пределы, вручную "коллекционируете" чеки и ведёте по необходимости их хранение и статобработку. Поэтому говоря широко - валидация КС - это проверка всего этого функционала. В частности проверка того, что софт не искажает показания калиброванного счетчика - это один из компонентов. Вам важно понимать, срабатывают ли установленные пределы (уровни предупреждения и действия), как накапливаются данные в системе, доступны ли они по истечению определенного времени, если система осуществляет определенные калькуляции - правильны ли они (в сравнении с ручными). Без КС представьте, что вы это всё проделываете сами, имя в своём распоряжении обычный портативный или ручной счетчик частиц. В обычном счетчике, впрочем, тоже своя прошитая КС, но, как правило, менее кучерявая и её по касательной всё же метрологический контроль затрагивает, хотя и не указывает на это прямо. Чтобы это понять, достаточно взглянуть на содержание протокола калибровки либо, если у вас это имеется, на первичные данные поверки. Там каналы частиц по размерам сопоставляются с пороговыми значениями напряжения в мВ (как правило, могут быть вариации). В любом случае это сопоставление выполняет программа, встроенная в счетчик. И, строго говоря, производители счетчиков предлагают валидацию при продаже своих продуктов (правда, далеко не все в наших широтах её приобретают - почему - это отдельная тема). В КС эти самые мВ высылаются на АЦП, после чего вы их видите не на экране счетчика (которого в системах мониторинга чаще всего и нет), а на экране десктопного приложения. Важно, чтобы это приложение не вносило некорректных поправок. На вскидку это можно оценить путем параллельных измерений. Метрологически это будет не вполне корректно, но для целей квалификации - вполне приемлемо. Можно просто установить рядом два пробоотборника и сопоставить распечатки за определенный интервал работы контрольного и проверяемого счетчиков. Как вариант.
Возможно для общего представления для вас полезным окажутся следующие материалы:
Руководство ГИЛС и НП по целостности данных и валидации комп. систем;
Есть и ещё одна тема, которая частично пересекается с данной. Частично, потому, что там рассматривается валидация отдельного счетчика частиц - я в предыдущем посте написал, что часто производители предлагают такую валидацию, но в наших широтах она часто игнорируются. И частично даже могу пояснить, почему. Отдельный счетчик внесен в реестр СИ РФ, вот на примере, рассмотренном в соседней теме: AEROTRACK 9310 (там сразу несколько модификаций), по ссылке есть в открытом доступе файл с описанием типа. Внимательно читаем, что там значится:
Отчасти именно такая безапелляционность, законодательно закрепленная при утверждении типа СИ, позволяет заключить, что как минимум для отдельной единицы СИ нет поводов для беспокойства о том, что данные встроенного ПО будут искажены. Это подтверждается в ходе поверки (хотя свидетельство о поверке не демонстрирует, насколько мне известно, прослеживаемости до эталона - впрочем, можно заказывать и калибровку или запрашивать внутренний протокол поверки, где эта информация дана без расчета расширенной неопределенности). Таким образом, снимается вопрос в отношении встроенного ПО. Хотя есть попытка, вполне законодательно выверенная, распространить это и на ПО мониторинга - в рассматриваемом случае это FMS Monitoring Software (версия 5.0). Причем тут каждый вправе сыграть в "ролевую игру". Внутренний софт, равно как и ПО мониторинга обладает богатым функционалом - как минимум установка и срабатывание аварийных пределов, доступность данных и т.п. Если вы заявляете - что всё делаете "пешком", а счетчик вам дает только чек/индикацию на экране - то поверитель вам гарантирует то, что what you see is what you get - и ваша валидация с контрольным счетчиком - это танцы "с бубном", пардон, с генератором и дилютором - это ненаказуемая прихоть и, по сути, дублирование деятельности. В противовес можете не поверять счетчик, заявив, что используете его вне сферы государственного регулирования / законодательной метрологии - но это будет "ещё более тонкий лёд" (хотя законодательно в настоящий момент - это пробел! - GMP требует калибровок и поверок, но о сферах по понятным причинам ничего не говорит) - тогда будете обязаны его валидировать, т.е. иным способом оценивать, что он вам показывает. Если вы используете функционал ПО шире, причем результат влияет на принятие управленческих решений (выпуск/невыпуск серии, приостановка асептического розлива и т.п.) - то всё, что стоит выше подтвержденной правильности показаний измерительных каналов подлежит валидации.
Такие крамольные суждения я бы повременил (или постеснялся бы) делать ранее, но проработка "калибровочных статей" (часть 1 и часть 2) натолкнула на такие выводы. Возможно, шире их рассмотрим в третьей части метрологической повести. Возникают такие крамолы из противоречивой законодательной базы. Фарма требует от вас валидации компьютеризированных систем, государство - метрологический контроль (поверка, калибровка или иной способ вне сферы госрегулирования/законодательной метрологии). Можно сделать и то, и другое и, вроде бы полностью закрыть вопрос. Хотя это будет самый дорогой и затратный вариант. Но ни то, ни другое не является безусловным. Вопрос, как эти два вида деятельности, диктуемые различными регуляторами, можно взаимодополнить (мотивированно избежав дублирования) - открыт.