ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

Производство лекарственных средств

РУКОВОДСТВО ПО ИСПОЛЬЗОВАНИЮ КОМПЬЮТЕРИЗОВАННЫХ СИСТЕМ В СИСТЕМАХ КАЧЕСТВА GxP

(PIC/S Guidance PI 011-3, NEQ)

Издание официальное

Москва Стандарт нформ 2017

Предисловие

1    РАЗРАБОТАН Государственным образовательным учреждением высшего образования Первым Московским государственным медицинским университетом имени И М Сеченова Министерства здравоохранения Российской Федерации (Первым МГМУ имени И М. Сеченова)

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 458 «Разработка, производство и контроль качества лекарственных средств»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 19 сентября 2017 г. № 1166-ст

4    Настоящий стандарт разработан с учетом основных нормативных положений международного документа «Руководство PIC/S PI 011-3 «Использование компьютеризованных систем в системах качества GxP» («Good practices for computerized systems in regulated ‘GxP^r environments», NEQ) Конвенции no фармацевтическим инспекторатам/Схемы взаимодействия фармацевтических инспекторатов (Pharmaceutical inspection convention/pharmaceutical inspection co-operation scheme; PIC/PIC/S)

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты» В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

О Стандартинформ. 2017

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

ГОСТ P 57680—2017

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

4.1.3    В организациях используется большое количество различных КС. начиная от небольших несетевых и заканчивая сложными и интегрированными. Часть из них (существенная доля производственного. лабораторного и клинического оборудования) имеет встроенное ПО. серийное ПО. стандартные операционные системы. Также в КС могут использоваться специализированные приложения. Организация должна вести перечень (реестр) всех применяемых КС с указанием владельца, поставщика (разработчика), функциональности, связей и валидационного статуса. Также в наличии должен быть основной валидационный план и порядок проведения валидации КС .

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

4.2 Управление рисками

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

4.2.2    Оценку потенциальных рисков для качества продукта/материала или целостности данных либо обеспечения качества проводят для каждого элемента КС или их совокупности (см. рисунок 1) на предмет оценки пригодности системы дпя ее предназначения. Все работы по оценке рисков регистрируют.

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

4.3    Персонал

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

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

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

4.3.4    При разработке процедур и документации подраздепения по управлению и администрированию информационными технологиям рекомендуется учитывать положения ГОСТ Р ИСО/МЭК 27002.

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

4.3.6    До начала перевода процесса с ручного управпения на автоматическое (или перед внедрением новой автоматизированной операции) следует осуществить оценку рисков данного шага в

7

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

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

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

4.3.9    При обучении должны быть подробно объяснены и обсуждаться концепции GxP и жизненного цикла КС, а также предприняты все меры для понимания и применения персоналом этих концепций. Организация обязана хранить документацию о проведении обучения как часть документации жизненного цикла системы (записи об обучении могут хранить в соответствии с процедурами пользователя).

4.4 Поставщики и провайдеры услуг

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

4.4.2    Компетентность и надежность поставщиков являются ключевыми условиями выбора поставщика программного продукта или услуг. Выбор КС и ее поставщика должен основываться на предварительно разработанной спецификации требований пользователя, соответствующим образом задокументированной оценки поставщика и оценки рисков для различных опций системы. Информация для этой оценки может быть получена по результатам аудита поставщика и исследования использования различных версий продукта, по данным сообщества и литературы. Для получения гарантий надежности продукта организация оценивает применяемые поставщиком подходы к обеспечению качества при проектировании, разработке, поставке и техническом обслуживании КС. Необходимость аудита поставщика должна быть основана на оценке рисков¹). Решение о покупке должно быть основано на задокументированных результатах приемочного тестирования.

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

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

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

4,4 6 Для критических КС проверки наличия признанной сертификации системы менеджмента поставщика. как правило, недостаточно (сертификация может быть несоответствующей или нелодходя- ^{1 2}

ГОСТ P 57680—2017

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

4.4.7 При привлечении поставщиков к оценке и валидации КС организацией должна быть проведена оценка критических аспектов поставщика, включая его квалификацию и качество выполняемых работ. Принципы, изложенные в руководстве надлежащей автоматизированной производственной практики (GAMP) [4], применимы и для сложных проектов и оборудования с использованием работ по контракту.

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

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

4.5    Документация

4.5.1    В организации должна быть в наличии полная и актуализированная регламентирующая документация по КС и записи и/или отчеты, охватывающая все аспекты проектирования, внедрения и валидации КС.

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

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

4.5.3    Организация должна разработать и применять политику и процедуры, касающиеся спецификаций. закупки, разработки и внедрения КС. подпадающих под требования надлежащих практик (GxP). В принципе, рекомендуется распространить данные процедуры на все подобные системы, имеющиеся в организации.

Следует отметить, что область применения и уровень документации и записей, необходимых для выполнения установленных требований для критических систем, будет зависеть:

-    от сложности КС и переменных, влияющих на качество и производительность;

-    необходимости обеспечения целостности данных;

-    степени риска, сопряженного с работой системы;

-    распространения требований надлежащих практик GxP на области работы системы.

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

4.5.5    Документация может существовать в различных формах, в том числе на бумажном, электронном или ином носителе.

ГОСТ P 57680—2017

5 Стадия проекта

5.1    Менеджмент качества

5.1.1    К разработке ПО применимы три основные составляющие обеспечения качества:

-    качество, безопасность и эффективность должны быть запроектированы и встроены в ПО;

-    качество готового продукта не может быть обеспечено посредством многочисленных испытаний или проверок;

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

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

5.1.3    Пользователи и поставщики должны гарантировать, что ПО и компьютерное оборудование, и системы:

-    обладают гарантированным качеством;

-    пригодны для предполагаемого использования;

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

5.1.4    Существует ряд общепризнанных моделей для процесса разработки ПО. например спиральная модель, каскадная модель (модель «Водопад») и модель жизненного цикла. Каждой из моделей присущи определенные особенности, например: в руководстве по надлежащей практике автоматизированного производства использована V-образная модель (см. рисунок 2). однако она не является обязательной для применения¹^.

Рисунок 2 — Примерная схема взаимосвязи между ключевыми спецификациями и этапами квалификации в процессе проектирования, построения и тестирования системы2)

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

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

¹¹В рамках небольших проектов спецификации требований пользователя и функциональные спецификации могут быть объединены Они будут связаны с квалификацией функционирования

Схема на рисунке 2 приведена лишь в качестве примера Ожидается, что организация разработает свою модель, учитывающую индивидуальные особенности взаимосвязи между элементами жизненного цикла для данной организации 10

ГОСТ P 57680—2017

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

5.1.7    Для гарантий качества и надежности КС разработчик ПО должен применять формальный плановой подход, основанный на принципах обеспечения качества при проектировании, разработке, производстве, внедрении и обслуживании, описанных, например, в ГОСТ Р ИСО 9001. Рекомендации по менеджменту качества и элементам системы, включая планы по качеству и управление конфигурацией. приведены в ГОСТ Р ИСО 9004, ГОСТ Р ИСО 10005 и ГОСТ Р ИСО 10007 В [5] приведены конкретные и обязательные требования в отношении планирования. ГОСТ Р ИСО/МЭК 25010 описывает качество ПО и определяет параметры качества для критических приложений. Руководство по надлежащей автоматизированной производственной практике (GAMP) также содержит релевантные для фармацевтической отрасли указания.

В ГОСТ Р ИСО 9001. ИСО/МЭК 25010 и (5)⁵ > представлено несколько положений, критических для обеспечения качества КС:

-    КС структурированы исходя из применения системы менеджмента качества к разработке, документирования процессов проектирования, производства и установки продукта:

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

-    эти стандарты, а также указанный документ описывают подходы и требования, предъявляемые к производству (изготовлению) ПО согласно модели жизненного цикла, делая упор на важности процедуры контроля за изменениями;

-    в стандартах установлена необходимость и важность тестирования ПО. проводимого на нескольких уровнях (фазах):

-    тестирование интеграции (интеграционное тестирование);

-    тестирование системы;

-    приемочное тестирование заказчиком.

5.2    Планирование и управление жизненным циклом

5.2.1    Рекомендации по управлению жизненным циклом КС приведены в ГОСТ Р ИСО/МЭК 12207. Применение принципов, рекомендаций, концепции «жизненного цикла» и надлежащей практики документирования будет способствовать разработке оптимальных систем качества, соблюдению и подтверждению выполнения установленных требований надлежащих практик.

5.3    Спецификации требований пользователя

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

5.3.2    Спецификации должны быть разработаны в соответствии с общими требованиями надлежащих практик к документации, а также:

-    каждый документ, содержащий требования, должен быть проверен, утвержден и внесен в реестр документации с уникальной идентификацией;

-    устанавливаемые требования к системе не должны противоречить друг другу;

-    формулировка камщого требования, в частности необходимого для соответствия надлежащим практикам GxP, должна позволять проведение объективной проверки его выполнения с помощью общепринятого метода, например инспекции, анализа или испытания (теста);

-    несмотря на независимость спецификаций требований пользователя от поставщика, они должны быть согласованы пользователем и поставщиком⁶*;

-    обязательные регуляторные требования и опциональные параметры должны быть четко разделены;

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

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

5.3.4    Функционал спецификаций требований пользователя и функциональных спецификаций должен гарантировать выполнение соответствующих требований надлежащих практик GxP. а также содержать информацию о наличии критических интерфейсов меэду системой и ручными операциями.

5.3.5    Спецификации составляют основу для оценки рисков системы в отношении соблюдения надлежащих практик GxP, а также других рисков, например, безопасности. Анализ рисков может быть основан на функциональной спецификации, связанной со спецификациями требований пользователей (например, в случае КС, изготовленных по индивидуальному заказу). Оценка рисков, а также ее результаты, включая критерии ранжирования рисков на критические или некритические, должны быть задокументированы. Источники любых рисков, связанных с соблюдением надлежащих практик GxP, должны быть определены.

5.3.6    Спецификации требований пользователя или ссылка на них могут быть включены в документ. описывающий КС (см. 4.5.1), вместе с результатами оценки рисков на стадии разработки спецификации.

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

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

5.4    Функциональная спецификация FS

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

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

5 4 3 Для определенных типов и уровней системы могут быть разработаны комбинированные спецификации, включающие требования пользователи и функциональные требования (см. 5.6.7 для определения подходов к валидации различных типов КС).

5.4.4    Организация должна иметь в наличии документацию, описывающую компьютерную систему с приложением, если возможно, диаграмм потока или блоков, показывающих раскладку оборудования, сети и взаимодействия. Эти схемы должны быть совместимыми с функциональной спецификацией и прослеживаемыми до спецификации требований пользователя. Данная документация является частью описания КС (см. 4.5.1).

ГОСТ P 57680—2017

Содержание

1    Область применения.................................................................1

2    Нормативные ссылки.................................................................1

3    Термины и определения...............................................................2

4    Общие положения...................................................................6

4.1    Структура и функции компьютеризованных систем.....................................6

4.2    Управление рисками..............................................................7

4.3    Персонал.......................................................................7

4.4    Поставщики и провайдеры услуг....................................................8

4.5    Документация....................................................................9

5    Стадия проекта.....................................................................10

5.1    Менеджмент качества............................................................10

5.2    Планирование и управление жизненным циклом......................................11

5.3    Спецификации требований пользователя............................................11

5.4    Функциональная спецификация FS.................................................12

5.5    Тестирование...................................................................13

5.6    Вапидация.....................................................................13

6    Стадия эксплуатации................................................................17

6.1    Данные........................................................................17

6.2    Контроль правильности ввода данных..............................................18

6.3    Хранение данных................................................................18

6.4    Распечатки.....................................................................19

6.5    Контрольные следы (autotrail)......................................................19

6.6    Управление изменениями и конфигурацией..........................................19

6.7    Периодическая оценка...........................................................21

6.8    Защита........................................................................21

6.9    Управление инцидентами.........................................................22

6.10    Электронная подпись...........................................................22

6.11    Выпуск серии..................................................................23

6.12    Непрерывность работы..........................................................23

6.13    Архивирование................................................................23

Приложение А (справочное) Рекомендации по аудиту/инспектированию использования

компьютеризированных систем в организации................................24

Библиография.......................................................................31

Введение

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

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

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

Настоящий стандарт разработан на основе Руководства PIC/S PI011-3 по использованию компьютеризованных систем в системах качества GxP (PIC/S PI 011-3 «Good practices for computerized systems in regulated “GxP" environments») Конвенции no фармацевтическим инспекторатам/Схемы взаимодействия фармацевтических инслекторатов (Pharmaceutical inspection convention/Pharmaceutical inspection co-operation scheme; PIC/PIC/S). в разработке которого приняли участие международные регуляторные органы.

IV

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Производство лекарственных средств

РУКОВОДСТВО ПО ИСПОЛЬЗОВАНИЮ КОМПЬЮТЕРИЗОВАННЫХ СИСТЕМ В СИСТЕМАХ КАЧЕСТВА GxP

Manufacturing of medicinal product Guidance for using computerized systems in quality systems regulated GxP

Дата введения — 2018—08—01

1    Область применения

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

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

Также настоящий стандарт описывает основные этапы и документацию в отношении внедрения и валидации КС в организации, включая различные подходы к разным типам систем и различные виды валидации.

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

2    Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ Р ИСО/МЭК 27002 Информационная технология. Методы и средства обеспечения безопасности. Свод норм и правил менеджмента информационной безопасности

ГОСТ Р ИСО/МЭК 12207 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств

ГОСТ Р ИСО 9001 Системы менеджмента качества. Требования

ГОСТ Р ИСО 9004 Менеджмент для достижения устойчивого успеха организации. Подход на основе менеджмента качества

ГОСТ Р ИСО 10005 Менеджмент организации. Руководящие указания по планированию качества

ГОСТ Р ИСО 10007 Менеджмент организации. Руководящие указания по управлению конфигурацией

ГОСТ Р ИСО/МЭК 25010 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов

Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты*, который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесяч-

Издание официальное

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

3 Термины и определения

В настоящем стандарте применены термины no (1), (2). руководству GAMP, техническим руководствам по КС, а также следующие термины с соответствующими определениями:

3.1    автоматизированные системы (Automated System): Широкий спектр систем, включая автоматизированное производственное оборудование, контрольные системы, автоматизированные лабораторные системы, производственные исполнительные системы и компьютеры, управляющие лабораторными или производственными базами данных.

Примечание —Автоматизированные системы состоят из оборудования, компонентов программного обеспечения (ПО) и компьютерной сети, включая контролируемые функции и связанную документацию Автоматизированные системы иногда также называют КС В настоящем стандарте данные термины являются синонимами

3.2    безопасность (Security): Защита компьютерного оборудования и программных приложений от случайного или преднамеренного доступа, применения, изменения, разрушения или раскрытия.

Примечание — Безопасность также касается персонала, данных, коммуникаций и физической защиты компьютерной инфраструктуры

3.3    валидация компьютеризированных систем (Validation of Computerised Systems): Документально оформленные действия, дающие высокую степень уверенности в том, что система соответствует заданным требованиям и ее использование будет постоянно приводить к результатам, соответствующим заранее установленным критериям приемлемости.

3 4 владелец процесса (Process owner): Лицо, ответственное за рабочий процесс.

3.5    владелец системы (System owner): Лицо, ответственное за доступность и техническое обслуживание КС и безопасность данных, находящихся в этой системе.

3.6    встроенная система (Embedded System): Система, обычно микропроцесс или программируемый контроллер, единственное назначение которой контролировать определенный элемент автоматизированного оборудования.

Примечание — Она не является отдельной компьютерной системой

3.7    встроенное программное обеспечение (Fimiware): ПО, записанное в компьютерное оборудование без возможности удаления, например EPROM

3.8    гибридные системы (Hybrid Systems): Гибридная система — система, в которой используется комбинация ручного управления и автоматизированных функций.

3.9    жизненный цикл (Life Cycle Concept): Все стадии существования КС от формирования первоначальных требований до прекращения эксплуатации, включая проектирование, определение технических требований, программирование, тестирование, установку, эксплуатацию и обслуживание.

3.10    интеграционное тестирование (Integration testing): Поэтапное проведение тестирования элементов ПО. элементов компьютерного оборудования или и того, и другого, продолжающееся до полной интеграции всей системы.

3.11    интерфейс (Interface): Общая граница двух отдельно существующих составных частей для взаимодействия или обмена информацией с другим элементом системы.

3.12    информационно-технологическая инфраструктура (IT Infrastructure): Компьютерное оборудование и ПО. такое как сетевое ПО и операционные системы, которые позволяют их применить для выполнения определенных функций.

3.13    инфраструктура открытых ключей; ИОК (Public Key Infrastructure (PKI): ИОК предоставляет структуру для безопасного обмена информацией путем использования криптографической системы с открытым ключом и электронных сертификатов.

Примечание — ИОК может состоять из многочисленных доменов, но наиболее важны два типа

2

ГОСТ P 57680—2017

-    частную ИОК используют компания для целей своего бизнеса и связанные с ней стороны (например. потребители, поставщики);

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

3.14    исполнительная программа (Executive Program): Программа, представляющая собой часть операционной системы, которая контролирует выполнение других программ и регулирует поток работ в системе обработки данных.

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

3.16    компьютеризированная система (Computerised System): Система, подразумевающая: процесс или операцию, объединенную в одно целое с компьютерной системой, включающих ввод данных, их электронную обработку и выдачу информации, используемой для документального оформления и (или) для автоматического управления; компьютерную систему и контролируемые функции, которыми она управляет.

Примечание — Приводимое определение достаточно ограничено В эту систему входят также асе внешние эффекты, которые взаимодействуют с системой в ее операционном окружении Это могут быть мониторинговые и сетевые связи (в/из других систем или оборудования), ручные (ввод с клавиатуры), связи с различными средами, ручными процедурами и автоматикой Данный термин также охватывает автоматизированное оборудование и системы (см также термин «автоматизированные системы») В настоящем стандарте они являются аналогами.

3.17    компьютеризированная система, изготовленная по индивидуальному заказу (Bespoke): Индивидуально спроектированная КС для обеспечения конкретного рабочего процесса.

3.18    компьютерная сеть (Network): Соединенная или взаимосвязанная группа узлов: объединенные коммуникационные мощности.

3.19    локальная сеть (LAN): Широкополосная компьютерная сеть (обеспечивающая высокую скорость передачи данных), функционирующая на небольшом пространстве, например офис или группа офисов

3.20    компьютерная система (Computer System): Компоненты компьютерного оборудования, собранные для функционирования вместе с приложениями, которые коллективно спроектированы для выполнения определенной функции или группы функций (см. рисунок 1).

3.21    компьютерное оборудование (Computer Hardware): Различные виды оборудования в компьютерной системе, включая центральный процессор, принтер, модем, монитор и другие присоединенные устройства (см. рисунок 1).

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

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

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

Примечание — Изменение превращает одну конфигурацию в другую

3.24    конфигурируемые серийные программы (Commercial off-the-shelf; COTS): Коммерческие серийные программы, которые могут быть сконфигурированы для определенных приложений пользователя путем «заполнения бланков», без изменения базовой программы.

3.25    незапланированные (экстренные) изменения Unplanned (Emergency) Change: Непредвиденные (экстренные) изменения в валидированной системе, требующие быстрого внедрения (хотфиксы).

3.26    операционная система (Operating System): Набор программ, предоставляемых вместе с компьютером в качестве интерфейса между компьютерным оборудованием и программами-приложениями.

3

3.27    операционное окружение (Operating Environment): Условия и деятельность, взаимодействующие непосредственно или косвенно с анализируемой системой, контроль которых может влиять на валидированное состояние системы.

3.28    организация (Regulated User): Регулируемая надлежащей практикой структура, ответственная за эксплуатацию КС и приложений, файлов и содержащихся в них данных (см. также термин «пользователь»).

3.29    отдельная система (Standalone System): Автономная компьютерная система, которая позволяет проводить обработку данных, предоставляет функции управления и мониторинга, однако не совмещенная с автоматизированным оборудованием Это отличает ее от встроенной системы, чьим единственным предназначением является управление конкретным экземпляром автоматизированного оборудования.

3.30    отладка (Debugging): Процесс нахождения, анализа и исправления предполагаемых ошибок (в приложении).

3.31    ошибка в программе или системе (Bug): Ошибка в программе или системе, из-за которой программа выдает неожиданное поведение и. как следствие, результат.

3.32    первичные/исходные данные (Raw Data): Любые таблицы, записи, заметки или их точные копии, представляющие собой результаты исходных наблюдений и действий и необходимые для восстановления и оценки рабочего проекта, процесса ипи отчета исследования и т. л.

Примечание — Первичные данные могут существовать в бумажном или электронном виде, их вид должен быть определен и описан в основных процедурах

3.33    повторная валидация (Revalidation): Повторение процесса валидации или его части.

3.34    пользователь (User): Компания или группа лиц. ответственная за функционирование системы.

Примечание — См также термин «организация» В контексте настоящего стандарта — синоним термина «потребитель»

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

3.36    проверка цикла/тестирование цикла (Loop Testing): Проверка установленной комбинации элементов, характеризующих каждый тип входа/выхода цикла.

3.37    проектная спецификация оборудования (Hardware Design Specification): Описание компьютерного оборудования, в котором будет использоваться ПО. и его соединение с другой системой или оборудованием.

3.38    ранее установленные системы (Legacy Computerised Systems): Системы, которые созданы достаточно давно и используются в течение длительного промежутка времени.

Примечание — По ряду причин для подобных систем может отсутствовать GMP-документация и записи, относящиеся к этапам разработки системы и ее ввода в эксплуатацию Кроме того, могут отсутствовать записи относительно формализованного подхода к валидации системы, что связано с ее возрастом

3.39    серийное программное обеспечение (Commercial of the shelf software): Коммерчески доступное ПО. пригодность которого для использования продемонстрирована большим количеством пользователей.

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

Примечание — Системное ПО, как правило, не зависит от конкретного применения системы.

3 41 служебное программное обеспечение (Utility Software): Компьютерные программы или последовательности. предназначенные для выполнения общих вспомогательных функицй. необходимых для иного ПО. операционной системы или пользователя системы.

3 42 специализированное приложение (Application-Specific Software): ПО. разработанное или адаптированное для определенных требований приложения.

3 43 спецификации приемочных испытаний системы (System Acceptance Test Specification [3)): Описание испытаний, проведение которых является необходимым для приемки системы пользователем.

4

ГОСТ P 57680—2017

Примечания

1    Обычно испытания охватывают функциональность системы; производительность системы, критические параметры, операционные процедуры

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

2    Испытания, как правило, включают в себя тестирование в предельных условиях, в аварийном состоянии и граничные испытания

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

3.44    спецификации системы (System Specifications): Описание выполнения системой функциональных требований.

3.45    спецификация на приемочные испытания оборудования (Hardware Acceptance Test Specification): Требования по проверке всех ключевых аспектов установки компьютерного оборудования с целью соблюдения соответствующих требований и одобренных характеристик при проектировании и учет основных рекомендаций организации.

3.46    структурная верификация (Structural Verification): Действия, направленные на получение документального свидетельства того, что ПО имеет надлежащую структурную целостность.

3.47    структурная целостность (программного обеспечения) (Structural Integrity (Software)): Свойства ПО, отражающие степень, в которой исходный код соответствует специфицированным требованиям и современным практикам разработки ПО.

3.48    структурное тестирование (Structural Testing): Изучение внутренней структуры исходного кода, включающее в себя низкоуровневый и высокоуровневый анализ кода, анализ пути, аудит методов программирования и использованных стандартов, инспектирование на наличие внешнего «неиспользуемого кода», анализ граничных значений и прочие методы.

Примечание —Для проведения структурного тестирования требуются конкретные навыки программирования и знание компьютерных технологий

3.49    управление конфигурацией (Configuration Management): Процесс идентификации и определения элементов системы, контроля запуска и изменения этих элементов на протяжении жизненного цикла системы, ведение записей и отчетов о статусе конфигурации и запросов на изменения, а также подтверждение полноты и корректности элементов конфигурации.

3.50    усиленная электронная подпись (Advanced Electronic Signature): Электронная подпись, которая:

-    получена в результате криптографического преобразования информации с использованием ключа электронной подписи;

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

-    создана с использованием средств электронной подписи.

3.51    функциональное тестирование (Functional Testing): Процесс подтверждения того, что приложение. система или элемент системы выполняют свои назначенные функции.

3.52    функциональные спецификации (Functional Specifications): Требования, которые описывают. каким образом КС должна удовлетворять функциональные требования связанной с компьютером системы.

3.53    функциональные требования (Functional Requirements): Требования, описывающие функции, которые должна выполнять связанная с компьютером система.

3    54 электронная подпись (Electronic Signature): Электронная, цифровая подпись, эквивалентная обычной подписи.

3.54.1    Информация в электронной форме, которая присоединена к другой информации в электронной форме (подписываемой информации) или иным образом связана с такой информацией и использована для определения лица, подписывающего информацию (2).

3.54.2    Электронное средство, которым можно заменить рукописную подпись или инициалы для целей согласования, разрешения или подтверждения ввода определенных даннах (PIC/S).

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

3.54.4    Данные в электронной форме, которые присоединены или логически связаны с другими электронными данными и использованы в качестве идентификации лица (EU).

5

1

’) Аудиты, проводимые организацией или 3-й стороной, вместе с маркетинговым анализом могут помочь при оценке надежности и структурной целостности сложных настраиваемых коммерческих систем При аудитах проверяют систему менеджмента качества и часть, касающуюся закупаемого продукта

2

3

¹¹ Руководство GAMP и PDA содержат подробные рекомендации по видам и процедурам аудита поставщиков критических КС.

4

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

9

5

’* Руководство GAMP также широко применяется поставщиками и провайдерами, связанными по роду своей деятельности с фармацевтической промышленностью

6

Данное требование обязательно для КС, изготавливаемых по индивидуальному заказу Также при приобретении коммерческих настраиваемых и конфигурируемых систем будущие пользователи, интеграторы и поставщики должны обсудить и рассмотреть разработанные требования пользователя и степень их удовлетворения предполагаемым программным обеспечением Необходимо определить «степень удовлетворения» и контролировать ее соблюдение при проведении необходимых работ по конфигурации, модификации, кодировании и тестировании. валидации

11