ГОСТ Р 58976-2020/ISO/TR 80002-2:2017. Национальный стандарт Российской Федерации. Изделия медицинские. Программное обеспечение. Часть 2. Валидация программного обеспечения, используемого в системах качества медицинских изделий
Приложение C
(справочное)
ПРИМЕРЫ
Настоящий стандарт применим к программному обеспечению, используемому для автоматизации элементов систем качества и производственных процессов, включая генерацию, измерение, оценку или менеджмент данных, которые предназначены для предоставления в регулирующие органы, систему качества, системы управления производством и обработки данных. Другие предполагаемые виды применения могут включать в себя прямой или косвенный сбор данных от устройств, задействованных в эксплуатации и управлении оборудованием, а также в обработке, протоколировании и хранении данных. Для этих различных видов деятельности программное обеспечение может варьироваться от программного обеспечения, содержащегося в программируемом логическом контроллере (ПЛК) или персональном компьютере (ПК), до программного обеспечения, содержащегося в информационной менеджмент-системе лаборатории (ЛИМС) с несколькими функциями. Ниже приведены некоторые примеры предусмотренного применения:
- программное обеспечение, которое принимает решение по сдаче/приемке продукции;
- программное обеспечение, используемое для ведения записей в системе качества;
- программное обеспечение для обработки и анализа данных, используемое для подачи продукции на оценку (регистрацию);
- программное обеспечение для обработки и анализа данных, используемое для отчетности в регулирующие органы;
- любые средства разработки программного обеспечения или компиляторы, используемые для программного обеспечения, задействованного в управляемом процессе;
- любой программный инструмент или вспомогательный программный инструмент, отвечающий за квалификацию и верификацию жизненно важного программного обеспечения;
- любое программное обеспечение, обеспечивающее прослеживаемость компонентов, продукции или пациентов в рамках системы качества;
- любое "программное обеспечение неизвестного происхождения" (т.е. неизвестного качества и надежности), используемое для вышеуказанных целей.
Примеры, приведенные в данном приложении, представляют собой попытку разработчиков настоящего стандарта предложить практические, реалистичные примеры программного обеспечения, с которыми может столкнуться изготовитель медицинских изделий. Рассмотрение примеров является лучшим способом показать подход на основе критического мышления и продемонстрировать различия в типах программного обеспечения, рисках программного обеспечения и предусмотренном применении.
Следует обратить внимание на следующие уточняющие условия:
- приведенные примеры содержат результаты критического мышления, выполненного разработчиками настоящего стандарта, и предусматривают приемлемый уровень масштаба усилий по валидации, которые обеспечивают уверенность в том, что программное обеспечение будет функционировать как предусмотрено. Пользователям настоящего стандарта настоятельно рекомендуется рассмотреть, какая деятельность и масштаб усилий целесообразны с инженерной точки зрения, а также определить требуемый уровень строгости на основе ключевых факторов для программного обеспечения, применяемого в процессах системы менеджмента качества медицинских изделий;
- всегда существует более чем один способ установить уверенность в адекватности масштаба усилий по валидации. Приведенные в настоящем стандарте примеры демонстрируют методический подход, основанный на современном понимании вопроса и опыте разработчиков настоящего стандарта;
- пользователям настоящего стандарта не следует рассматривать мнение его разработчиков как нечто официальное и предписывающее. Схожесть примеров по формату приведена исключительно в целях представления данных, и в них включены важные соображения для демонстрации использования критического мышления. Приведенные схемы действий не предназначены для использования в качестве шаблонов валидации, они не отражают необходимую глубину и детализацию, которая требуется в фактической документации по валидации;
- приведенные примеры предполагают, что обязательные процессы, указанные в разделе 6, в организации установлены и поддерживаются в рабочем состоянии. Несмотря на то что примеры не содержат развернутых ссылок на обязательные процессы, они должны быть внедрены для обеспечения того, что программное обеспечение и все связанные с ним аспекты, такие как документация и остальная инфраструктура, подлежат управлению изменениями;
- каждый пример начинается с четкого определения управляемого процесса. Таким образом, уже установлено, что процесс и программное обеспечение подпадают под область применения настоящего стандарта. Далее идут идентификация и обобщение деятельности на основе критического мышления;
- примеры предназначены для предоставления информации о решениях и факторах принятия решений, используемых в процессе критического мышления. Они не обязательно отражают детальные шаги по валидации рассматриваемого программного обеспечения;
- любые названия компаний, команд или отдельных лиц, использованные в примерах, являются вымышленными и включены только для облегчения обсуждения.
Используемые примеры в основном показывают приведение конкретной системы в валидированное состояние. Установление валидированного состояния системы имеет большое значение, однако его поддержание на этапе обслуживания системы также очень важно для обеспечения правильной работы программного обеспечения и связанных с ним процессов. Деятельность по обслуживанию требует использования критического мышления и применения того же управления, которые требуются для первоначальной деятельности по валидации.
Пример 1: Программируемый логический контроллер (ПЛК)
для производственного оборудования
Вводная информация
Компанией Tubing Supply Company был заключен контракт с крупным изготовителем медицинских изделий на поставку ему комплектующих - полимерных трубок для систем внутривенного вливания. Компания получила спецификации на трубки, среди которых - требования к производству трубок запатентованной формы. Это специальное требование к форме трубок будет выполнено компанией Tubing Supply Company в рамках основного процесса производства сегментов трубок.
Процесс производства трубок специфической формы требует особого внимания поставщика, поскольку является уникальным процессом, для выполнения которого в настоящее время поставщик не имеет оборудования. Было принято решение, что для выполнения этой задачи будет разработано специальное оборудование с программируемым логическим контроллером (ПЛК). Действующие политики компании - изготовителя медицинских изделий требуют проведения валидации процесса применения данного оборудования, включая содержащийся в нем ПЛК, на предмет их предусмотренного применения.
Определение процесса
Поставляющая трубки компания и изготовитель медицинских изделий формируют команду с целью определения процесса, посредством которого будет производиться трубка специфической формы. Установленный командой процесс предусматривает использование определенных температуры и давления для создания необходимой формы полимерной трубки. Процесс состоит из следующих шагов:
a) получить материалы;
b) загрузить материалы в оборудование;
c) сформировать диаметр трубки до нужного с помощью давления и нагрева;
d) охладить трубку;
e) снять трубку с машины;
f) проверить диаметр трубки на соответствие заданным параметрам.
Анализ рисков процесса
Изготовитель медицинских изделий сообщил компании Tubing Supply Company, что в результате анализа риска процесса обнаружены следующие проблемы и связанные с ними опасности:
- отсутствие хорошего соединения с контейнером, содержащим инфузионный раствор, может привести к протеканию. Утечка жидкости не является опасностью, но медработник, осуществляющий уход за пациентом, может поскользнуться. Протекание может также привести к задержке лечения;
- внешние дефекты могут повлиять на приемку заказчиком и привести к задержке лечения;
- существует вероятность получения ожога оператором при термической обработке трубки.
До снижения существует умеренный уровень риска, связанный с отказом продукции из-за опасности падения медработника на скользкой поверхности, задержки лечения и ожогов оператора.
В настоящее время выполняются следующие меры по управлению риском процесса:
- предшествующие операции, такие как входной контроль и уборка производственной линии, проводимые в целях обеспечения пригодности линии для использования;
- последующие проверочные мероприятия, в том числе испытание на герметичность, контроль в рамках процесса и испытания фитингов, которые минимизируют последствия неправильной работы оборудования;
- защитные экраны, автономный датчик температуры и распылитель охлаждающей жидкости, установленные для предотвращения травм оператора.
Используя эту информацию, поставщик и изготовитель медицинского изделия формулируют вывод о том, что в результате рассматриваемого производственного процесса существует низкий остаточный риск несоответствия трубок заданным параметрам.
Определение цели и назначения программного обеспечения
Компания Tubing Supply Company знает, что для валидации применения программного обеспечения сначала нужно определить его предусмотренное применение. Чтобы прийти к общему пониманию о предназначении оборудования, члены команды обсуждают ряд вопросов, способствующих разработке определения цели и назначения системы, которое будет кратким, но приемлемым для использования. Они формулируют цель и назначение системы следующим образом:
- управляемое программным обеспечением оборудование предназначено для автоматизации процесса на этапах 2 - 6. Система предназначена для использования в подразделении B, производственная линия 3, для создания PN 001. Система будет автоматизировать загрузку, формирование, извлечение и измерение трубок для систем внутривенного вливания IV жидких форм лекарственных средств.
Планирование валидации
Первый шаг в планировании валидации включает установление уровней строгости к документации и анализу результатов. Поскольку остаточный риск процесса определен как низкий, был выбран следующий подход:
- строгость документации:
- документация в этом проекте будет иметь средний уровень
строгости, означающий возможность объединения некоторых результатов и
отсутствие необходимости перевода проектов документов в подробные
проектные спецификации до имплементации;
- уровень анализа:
- анализ и одобрение будут проводиться лицами, ответственными за
разработку и внедрение процесса (представитель компании Tubing Supply
Company), а также независимым специалистом по качеству (представитель
компании - изготовителя медицинских изделий);
- код ПЛК и все спецификации будут являться объектами менеджмента
конфигурации, например путем размещения в системе управления
документами или системе управления конфигурацией;
- определение системы:
- будут созданы требования к процессу, включающие спецификацию
требований к системе, детализирующие функциональные возможности
оборудования, в том числе ожидаемые входные и выходные данные
оборудования (например, элементы управления проектированием для всей
функциональной части оборудования);
- команда создаст руководство по эксплуатации для использования
системы оператором. Кроме того, будут созданы требования к программному
обеспечению, включающие в себя логический функциональный поток,
достаточные для нужд проектирования программного обеспечения.
Установление уверенности и управления программным обеспечением
Компания Tubing Supply Company и изготовитель медицинских изделий ранее не использовали этот программный пакет ПЛК. Компания Tubing Supply Company не располагает информацией, которая могла бы помочь укрепить уверенность в способности программного обеспечения работать в соответствии с требованиями. Тем не менее программирование ПЛК будет находиться под управлением посредством анализа требований, управления конфигурацией и проведения испытаний функциональности системы с помощью протоколов тестирования.
Определение границ взаимодействия программного обеспечения с другими системами
ПЛК содержит только одно программное обеспечение в части оборудования. Это программное обеспечение не связано с какой-либо другой системой.
Анализ риска программного обеспечения
Программное обеспечение может отказать и пропустить далее по производственной линии трубку неправильной формы, что приведет к протеканию жидкости и в дальнейшем к тому, что медработник может поскользнуться. Программное обеспечение также может работать неправильно, что может привести к чрезмерному нагреву и в дальнейшем к ожогам оператора. Само по себе программное обеспечение не создает никаких новых рисков для продукции, которые еще не были зафиксированы при анализе риска процесса. Таким образом, команда устанавливает, что существующие меры по управлению риском и последующие процессы должны оставаться без изменений и являются достаточными для уменьшения рисков, связанных с отказом программного обеспечения.
Завершение планирования валидации
Теперь, когда члены команды знают больше о программном обеспечении и его применении, они должны завершить планирование валидации следующим образом:
- инструменты имплементации:
- программируемые встроенные параметры работы оборудования включают
время, температуру и давление. Требуемые настройки и диапазоны для этих
параметров в оборудовании отражены в требованиях к программному
обеспечению. Поэтому спецификация требований к программному обеспечению
является достаточной для нужд и целей проектирования без необходимости
установления дополнительной деятельности по проектированию или
документированию;
- команда установит матрицу прослеживаемости между требованиями к
программному обеспечению и связанными с ними испытаниями, а также
проведет анализ устанавливаемой прослеживаемости для обеспечения ее
целостности;
- инструменты тестирования:
- тестирование системы программного обеспечения будет основано на
требованиях к программному обеспечению и процедурах, изложенных в
руководстве оператора;
- регрессионное тестирование будет проводиться при необходимости;
- инструменты развертывания:
- системные операторы и инженеры проведут анализ рабочих инструкций
на предмет их четкости и удобства использования;
- использование оборудования потребует аттестации оператора;
- после завершения плана валидации и выполнения установленной в нем
деятельности у команды сложилось единое мнение, что система будет
последовательно обеспечивать желаемые и предопределенные результаты.
Вопросы обслуживания
Если планируются изменения в какой-либо части этого процесса или возникают изменения в предусмотренном применении программного обеспечения, следует провести анализ и определить, окажут ли эти изменения влияние на какие-либо существующие меры по уменьшению рисков или приведут к появлению новых рисков. Этот анализ включает обзор программных рисков, связанных с оборудованием для производства трубок.
Использование набора инструментов
Из набора инструментов были использованы следующие:
- стадия разработки - определения:
- определение требований к процессу;
- анализ риска отказа процесса;
- предусмотренное применение;
- планирование валидации;
- определение требований к программному обеспечению;
- идентификация мер по управлению рисками в производственном
процессе;
- стадия разработки - имплементации:
- анализ отказов программного обеспечения;
- анализ прослеживаемости;
- стадия разработки - испытания (тестирования):
- системное тестирование программного обеспечения;
- регрессионное тестирование;
- стадия разработки - развертывания:
- анализ используемых пользователем процедур;
- аттестация оператора.
Пример 2: Система автоматической сварки
Дэйв является частью команды по валидации всех систем на новой производственной линии. Его работа заключается в валидации процесса сварки составных частей конструкции изделия (трубки с корпусом капельницы). В этом проекте он является менеджером проекта.
Описание процесса
Команда Дэйва проводит много времени в обсуждении: кто разрабатывает и какие участки новой производственной линии валидирует. Дэйв получает детали для сварки, которые уже промаркированы, а все материалы проверены и сертифицированы. Детали испытаны в валидированных системах выше по производственной линии, чем участок Дэйва.
Для настройки сварочной установки необходимо выполнить четыре шага:
- включение установки;
- подтверждение наличия штрих-кода в детали для сварки;
- извлечение программы для операции с деталями из системы управления производством;
- подтверждение правильной версии программы относительно Основных записей изделия (DMR).
Сам процесс термической сварки трубки с корпусом капельницы состоит из 10 этапов:
a) открыть дверь;
b) загрузить детали;
c) закрыть дверь;
d) запустить программу;
e) разместить индексы системы обработки данных визуального контроля в начальной точке;
f) включить лазер;
g) обеспечить перемещение сварных соединений детали системой управления движением;
h) выключить лазер;
i) открыть дверь;
j) убрать деталь.
После завершения этого процесса детали перемещаются в системы, которые не входят в сферу ответственности Дэйва. Он знает, что последующие действия включают разрушающий контроль прочности сварного соединения, проверку геометрических размеров и проверку на герметичность.
Определение предусмотренного применения
С целью определения предусмотренного применения программного обеспечения Дэйв собирает информацию. Он знает, что в процессе важны как точность визуализации, движения, силы и скорости, так и защита оператора и обеспечение прочности термической сварки трубки с корпусом капельницы.
Сначала Дэйв определяет предусмотренное применение, излагая цель и назначение программного обеспечения следующим образом:
Программное обеспечение предназначено для выполнения термической сварки частей изделия и защиты оператора установки от прямого контакта с работающим лазером. Указанная деятельность включает в себя шаги e) - h) в описании процесса.
Анализ риска
Дэйв хотел бы исключить из процесса человеческий фактор. Он знает, что управление лазером, сервомеханизмы и автоматическая следящая система визуализации (машинное зрение) являются ключевыми компонентами этого процесса. Программное обеспечение начинает работу с проверки закрытия двери. В целях безопасности программное обеспечение не запустит процесс без сигнала о закрытии двери. Работа программного обеспечения завершается подтверждением выключения лазера и разрешением на открывание двери. Аварийная остановка или неожиданное открытие двери приводит к отключению лазера. Дэйв использует информацию о процессе и деятельности по менеджменту риска, полученную им из документации по проектированию этого процесса, частью которого является термическая сварка. Дэйв ссылается на проведенный анализ видов и последствий отказов (FMEA) и сосредотачивается на трех областях: критические параметры скрепления деталей, герметичность шва и пользовательские интерфейсы. Дэйв идентифицирует множество опасностей, связанных с рассматриваемым процессом. Во-первых, оператор может получить ожог при контакте с лазером. Процесс термической сварки может работать недостаточно хорошо, что приведет к несоответствию продукции на выходе процесса (нарушение герметичности) и может причинить вред конечному пользователю. Дэйв определяет риск этого процесса как высокий.
Планирование валидации
Для этого проекта Дэйв рассматривает инструменты стадии разработки - определения из набора инструментов и решает, что ему нужно определить требования к программному обеспечению и создать документ по техническому обслуживанию. Требования к программному обеспечению должны включать параметры конфигурации для инструментов, а также настройки времени работы и мощности лазера. Ему также необходимо определить программное обеспечение к аппаратным интерфейсам. В частности, Дэйв включает требования к точности системы визуализации, диапазонам времени и мощности лазера, требования к точности управления движением и надежности датчика двери, в том числе интерфейс с аппаратным закрыванием двери, если лазер активирован.
Дэйв также устанавливает, что ему необходимо провести формальный анализ требований к программному обеспечению при участии инженера по автоматизации, инженера по производству и инженера по качеству.
Программное обеспечение для этой системы будет закуплено, но Дэйв знает, что его компании нужно будет вносить пользовательские изменения. Ему нужно добавить интерфейс к заводской системе управления производственными процессами (MES).
Меры по управлению риском
Далее Дэйв сосредотачивается на рисках. Он считает, что тяжесть вреда из-за толщины сварного шва и других критических параметров является низкой. Он уверен, что проверка герметичности на выходе процесса и периодический разрушающий контроль прочности соединения являются достаточными. Аналогично, проверка на герметичность подтвердит, что качество термической сварки соответствует критериям приемки. Остается риск в области пользовательских интерфейсов, и в частности риск запуска лазера программным обеспечением при открытой двери. Дэйву известно, что существуют программные проверки плотности закрытия двери, но, учитывая, что при программном отказе тяжесть риска высока, он добавляет избыточную аппаратную блокировку, предотвращающую активацию лазера при открытой двери.
Задачи валидации
Затем Дэйв переходит к задачам валидации. Выбранный им вендор-поставщик предоставил обширные программные инструменты. Поэтому созданные ранее спецификация и анализ требований к программному обеспечению достаточны для реализации проекта без использования дополнительных инструментов проектирования, разработки и конфигурирования из набора инструментов.
Еще одной задачей является предстоящая деятельность по планированию проведения испытаний, которую Дэйв выбрал из раздела "Разработка - испытания (тестирование)" набора инструментов. Планы испытаний должны включать подробную информацию о программных средах и ожидаемые результаты тестирования. Планы испытаний должны быть рассмотрены и утверждены инженером по автоматизации, инженером-технологом и инженером по качеству, а также Дэйвом. Отчет о тестировании будет включать представление фактических результатов тестирования, их сравнение с ожидаемыми результатами, индикацию принятия/отклонения результатов, идентификацию теста и документацию по решению проблем и регрессионному тестированию по любым отказам. В отношении составленного отчета Дэйв считает нужным получить дополнительное одобрение инженера по автоматизации, инженера по производству, инженера по качеству и спонсора проекта (Дэйв - менеджер проекта).
Развертывание
Для развертывания системы термической сварки Дэйв рассматривает инструменты развертывания из набора инструментов и решает, что необходима процедура для оператора на производстве, которая должна быть рассмотрена инженером по автоматизации, инженером по производству и инженером по качеству. Чтобы обеспечить навыки управления сварочным оборудованием у операторов, Дэйв создает процедуру обучения и аттестации оператора, которая включает в себя сдачу теста. Он знает, что система управления производственными процессами (MES) не допустит к работе неаттестованного оператора. Дэйв приходит к выводу, что риск травмирования оператора был успешно уменьшен.
Обслуживание
Дэйв знает, что в его фирме используется инструмент проверки конфигурации. Следовательно, он не проводит конкретного планирования технического обслуживания во время этой валидации.
Пример 3: Система управления процессом автоматической сварки
Таблицы C.1 - C.14 в этом примере демонстрируют этапы процесса, показанные на рисунке 2.
Таблица C.1
Пример 3 - Требования к процессу
Разработка | Определение | Процесс | Итеративный анализ рисков | Планирование валидации и отчеты | Система ПО |
Требования к процессу (см. 5.3.2.2) Компания Device Corporation является изготовителем медицинских изделий класса C (см. GHTF/SG1/N77:2012). Компания решила внедрить автоматизированную систему управления процессом сварки. Для обеспечения надлежащей сварки деталей конструкции изделия Device Corporation будет использовать метод принятия решения по выпуску продукции на основе данных о значениях параметров, полученных в ходе технологического процесса (параметрический выпуск). Также Device Corporation решила использовать информацию из этого процесса для поддержания записей истории изделия (DHR). Компания Device Corporation назначила нового менеджера проекта для валидации системы управления процессом автоматической сварки. Менеджер проекта знает, что эта система подпадает под требования ИСО 13485 по валидации применения программного обеспечения, и поэтому считает валидацию рассматриваемой системы необходимой. Чтобы лучше понимать требования и риски, связанные с валидацией системы сварки, менеджер проекта определяет процесс: a) Оператор вводит номер партии в систему для загрузки первой части партии. b) Оператор вставляет сборочные компоненты в крепление машины. c) Оператор нажимает кнопку запуска цикла. Крепление перемещается в сопряженное положение механически с помощью гидравлики. | |||||
|
| d) Цикл сварки начинается вместе с фиксированной скоростью вращения закрепленных компонентов. e) Инфракрасный термометр контролирует температуру материала во время процесса сварки. Значения температуры записываются в файл вместе с номером партии и порядковым номером для каждой сваренной детали. f) Машина открывает крепление в конце цикла. g) Оператор вынимает скрепленную сварным швом деталь и помещает ее в нужное место лотка для партии в соответствии с порядковым номером. h) Оператор повторяет шаги с b) по g), пока лоток не будет заполнен. i) Оператор нажимает кнопку "конец партии". j) Интерфейс оператора отображает порядковые номера деталей, температура сварного шва которых выходит за пределы параметров технологического процесса. k) Оператор удаляет соответствующие номера деталей из лотка. l) Оператор распечатывает список отклоненных деталей и отправляет лоток с партией и отчет на следующую технологическую операцию. m) Оператор начинает новую партию, повторив шаг a). Менеджер проекта также понимает, что ключевыми функциями автоматизации являются следующие: - сохранение номера партии; - сохранение информации о температуре сварного шва по порядковому номеру детали; - отображение порядковых номеров деталей, по которым превышены пределы температуры процесса при сварке; - печать отчета об отклонении партии | |||
Таблица C.2
Пример 3 - Анализ рисков отказа процесса
Разработка | Определение | Процесс | Итеративный анализ рисков | Планирование валидации и отчеты | Система ПО |
Анализ рисков отказа процесса (см. 5.3.2.3) Затем менеджер проекта анализирует, что может пойти не так в существующем процессе. Он понимает, что в случае сбоя процесса неправильно скрепленные детали конструкции могут подвергать пациентов риску использования нестерильных изделий. Случайный выпуск некачественной продукции может произойти из-за ошибки в системе управления сварочным процессом или из-за ошибки оператора. Далее менеджер проекта рассматривает, какие меры по управлению риском уже применяются для его снижения. Он узнает, что в Процессной группе есть процедура по проверке правильности отбраковки скрепленных деталей оператором сварки на следующем этапе процесса. Кроме того, менеджер проекта узнает, что сварочная система является коммерческой системой (Off The Shelf) | |||||
Таблица C.3
Пример 3 - Цель и назначение программного обеспечения
Разработка | Определение | Процесс | Итеративный анализ рисков | Планирование валидации и отчеты | Система ПО |
Цель и назначение программного обеспечения (см. 5.3.2.5.2) Обладая базовым пониманием процесса, менеджер проекта готов письменно сформулировать цель и назначение для системы управления процессом сварки: - Приложение управления процессом сварки автоматически принимает решения в отношении качества скрепления сварных деталей конструкции. На основании этих решений оператор сварки вручную отбраковывает несоответствующую продукцию. Менеджер проекта анализирует цель и предназначение на предмет надлежащего охвата границ программного обеспечения в рамках процесса и решает пересмотреть ранее составленную им формулировку: - Приложение управления процессом сварки автоматически принимает решения в отношении приемки или отклонения качества скрепления сварных деталей конструкции. На основании этих решений оператор сварки затем вручную отбраковывает несоответствующую по параметрам продукцию. Сварочная станция является единственной контрольной точкой во всем производственном процессе, которая обеспечивает целостность и герметичность соединений конструкции изделия. Затем менеджер проекта рассматривает, какие другие имеющиеся системы будут взаимодействовать со сварочной системой. Он устанавливает, что программное обеспечение представляет собой отдельное приложение, работающее на персональном компьютере, подключенном к инфракрасному температурному датчику, интерфейсу оператора, принтеру и входу/выходу ПЛК установки. Система сварки не подключается к сети | |||||
Таблица C.4
Пример 3 - Планирование валидации
Разработка | Определение | Процесс | Итеративный анализ рисков | Планирование валидации и отчеты | Система ПО |
Планирование валидации (см. 5.3.2.4) Теперь, когда менеджер проекта понимает процесс и уже установил предусмотренное применение новой системы, он готов разработать первоначальный план валидации. Ранее менеджер проекта установил, что в процессе сварки существует высокий остаточный риск, поскольку процесс должен быть реализован как неверифицируемый. Исходя из этого, он определяет, что необходим тщательный анализ уровня предполагаемых усилий по валидации. Менеджер проекта решает, что ключевые роли по официальному одобрению должны выполнять отделы технологического проектирования и инжиниринга качества, а также инструктор по обучению операционным процессам. Кроме того, менеджер по приемке готовой продукции должен утвердить требования. Менеджер проекта решает начать разработку своего плана валидации, т.к. система качества требует, чтобы для систем с высоким риском план валидации был утвержден до того, как будут одобрены любые другие отчетные документы по валидации или проекту | |||||
Таблица C.5
Пример 3 - Требования к использованию программного
обеспечения и требования к программному обеспечению
Разработка | Определение | Процесс | Итеративный анализ рисков | Планирование валидации и отчеты | Система ПО |
Менеджер проекта считает, что необходимо обеспечить высокий уровень детализации или соблюдения формальностей в процессе валидации. Он знает, что необходимо определить подробные требования к процессу и программному обеспечению. Он письменно формулирует требования к программному обеспечению. Менеджер проекта решает, что программное обеспечение должно включать избыточность в процессы верификации температуры и принятия решения об отклонении некачественных изделий. Также он устанавливает дополнительное требование, чтобы система имела возможность перепечатывать отчет об отклонении в любое время до начала операций по очистке производственной линии. Поскольку эта система функционирует на основе данных о значениях параметров, менеджер проекта также включает требования к ее собственной безопасности наряду с подробным списком значений параметров, которые могут быть изменены в зависимости от уровня доступа к системе | |||||
Таблица C.6
Пример 3 - Анализ рисков отказа программного обеспечения
Разработка | Имплементация, тестирование, развертывание | Процесс | Итеративный анализ рисков | Планирование валидации и отчеты | Система ПО |
Анализ рисков отказа программного обеспечения (см. 5.3.3.2) Теперь менеджеру проекта необходимо решить, какой подход следует использовать для установления полной уверенности в сварочной системе. Менеджер проекта отмечает, что для исполнения проекта требуется готовый коммерческий продукт (COTS), который обычно используется в промышленности. Он выясняет, что прошлые проблемы с этим продуктом были быстро выявлены его изготовителем и доведены до сведения пользователей. Несмотря на то что менеджер проекта уже установил, что процесс сварки имеет высокий риск, он хочет еще провести формальный анализ риска отказа программного обеспечения. Чтобы подтвердить свои предположения, менеджер проекта анализирует вопросы из базы данных рисков компании. a) Существует ли потенциальный риск для безопасности продукции в случае неправильного функционирования программного обеспечения? Да 1) Как? Система не отклоняет плохо скрепленную деталь, основываясь на температурных пределах по умолчанию. Ограничения сбрасываются к настройкам по умолчанию после перебоев энергоснабжения. 2) Что нужно сделать для управления этим риском? Требовать от оператора проверки значений пределов в начале и в конце каждой партии. b) Существует ли потенциальный риск для качества продукции (кроме риска для безопасности), если пользователь допустил ошибку? Да 1) Как? В ручном режиме сварочный лазер может сработать, если оба датчика детали сработают в течение 3 с. 2) Что нужно сделать для управления этим риском? Изменить настройки по умолчанию, чтобы лазер работал только в автоматическом режиме | |||||
Таблица C.7
Пример 3 - Планирование валидации
Разработка | Имплементация, тестирование, развертывание | Процесс | Итеративный анализ рисков | Планирование валидации и отчеты | Система ПО |
Планирование валидации (см. 5.3.3.3) Понимая требования к программному обеспечению, менеджер проекта обладает достаточной информацией для завершения планирования валидации. Менеджер проекта провел анализ риска и определился с подходом к исполнению программного обеспечения. На этом этапе он делает шаг назад и задает следующий вопрос в свете всего, что он узнал об этой системе: "Какие действия по валидации действительно позволят обрести уверенность в том, что сварочная система соответствует ее предусмотренному применению?" Менеджер проекта обдумывает разработку системы третьей стороной и обеспокоен тем, правильно ли разработчик будет толковать требования для настройки отчета. Поскольку система будет зависеть от данных из различных областей, он предусматривает дополнительные действия по верификации в анализе кода, чтобы подтвердить правильность работы разработчика | |||||
Таблица C.8
Пример 3 - Имплементация программного обеспечения
Разработка | Имплементация, тестирование, развертывание | Процесс | Итеративный анализ рисков | Планирование валидации и отчеты | Система ПО |
Имплементация программного обеспечения (дизайн, разработка, сборка и тестирование) (см. 5.3.3.4) Решение о том, что программное обеспечение будет закуплено, а не разработано собственными силами компании, было принято на основе доступности готового коммерческого продукта (COTS). Однако менеджеру проекта необходимо доказать отделу качества Device Corporation, что программное обеспечение для управления сваркой было разработано в рамках корректно установленного жизненного цикла разработки (SDLC), поскольку риск предусмотренного применения был определен как высокий. После обсуждения этого вопроса с поставщиком готового коммерческого продукта менеджер проекта узнает, что процессы жизненного цикла разработки программного обеспечения у поставщиков недавно были оценены независимой аудиторской фирмой. Поэтому он связывается с независимой аудиторской фирмой и приобретает копию отчета об аудите поставщика готового коммерческого продукта. Конечным результатом является то, что отдел качества убежден, что поставщик готового коммерческого продукта разработал программное обеспечение в соответствии с корректной моделью жизненного цикла | |||||
Таблица C.9
Пример 3 - Отчет по валидации
Разработка | Имплементация, тестирование, развертывание | Процесс | Итеративный анализ рисков | Планирование валидации и отчеты | Система ПО |
Отчет по валидации (см. 5.3.3.5) Менеджер проекта завершает отчет по валидации и получает на него официальное одобрение | |||||
Таблица C.10
Пример 3 - Выпуск программного обеспечения
Разработка | Имплементация, тестирование, развертывание | Процесс | Итеративный анализ рисков | Планирование валидации и отчеты | Система ПО |
Выпуск программного обеспечения (см. 5.3.3.6) Менеджер проекта верифицирует соответствие программного обеспечения, переданного в формальную систему управления конфигурацией, программному обеспечению, указанному в отчете по валидации | |||||
Таблица C.11
Пример 3 - Анализ изменений
Обслуживание |
| Процесс | Итеративный анализ рисков | Планирование валидации и отчеты | Система ПО |
Анализ изменений (см. 5.4) Менеджер проекта верифицирует наличие формализованного процесса управления изменениями, который управляет любыми последующими изменениями в валидированной сварочной системе, что соответствует плану валидации, имеющемуся у компании | |||||
Таблица C.12
Пример 3 - Планирование валидации на стадии обслуживания
Обслуживание |
| Процесс | Итеративный анализ рисков | Планирование валидации и отчеты | Система ПО |
Планирование обслуживания (см. 5.4.2) Менеджер проекта заранее обдумывает, какая деятельность будет уместна для обеспечения уверенности в том, что система продолжает соответствовать своему предусмотренному применению. Учитывая высокий риск системы, он решает, что следует проводить ежеквартальную калибровку и подтверждение точности и прецизионности фактического значения измеренной температуры и значений температуры, указанных в отчете по партии. Менеджер проекта включает этот раздел в план валидации для документирования заключения и создает запрос на разработку и внедрение процедуры калибровки и подтверждения, чтобы обеспечить ее ежеквартальное проведение | |||||
Таблица C.13
Пример 3 - Обслуживание программного обеспечения
Обслуживание |
| Процесс | Итеративный анализ рисков | Планирование валидации и отчеты | Система ПО |
Обслуживание программного обеспечения (см. 5.4.6) Менеджер проекта в соответствии с планом валидации верифицирует наличие в компании процесса проведения периодического анализа, обеспечивающего отсутствие расхождений между сварочной системой и процессом от их предусмотренного применения | |||||
Таблица C.14
Пример 3 - Снятие с эксплуатации
Вывод из эксплуатации |
| Процесс | Итеративный анализ рисков | Планирование валидации и отчеты | Система ПО |
Снятие с эксплуатации (см. 5.5) Менеджер проекта в соответствии с планом валидации верифицирует наличие у компании формализованного процесса вывода программного обеспечения из эксплуатации, который регламентирует снятие сварочной системы с эксплуатации | |||||
Выбор инструментов
Инструменты проектирования, разработки и конфигурации:
- определение требований к процессу;
- формализованный анализ требований к программному обеспечению;
- идентификация мер по управлению риском в производственном и бизнес-процессах;
- анализ на стадиях разработки процесса;
- матрица прослеживаемости (характерна для спецификации требований).
Инструменты испытаний (тестирования):
- планирование проведения испытаний;
- системное тестирование программного обеспечения;
- управление конфигурацией программного обеспечения.
Инструменты развертывания:
- анализ используемых пользователем процедур;
- внутреннее обучение по применению;
- установочная квалификация (IQ);
- валидация процесса.
Пример 4: C/C++ языковый компилятор (языка программирования)
Вводная информация
Компании, выпускающей медицинские изделия класса C, необходимо валидировать готовое программное обеспечение - языковой компилятор C/C++ для встроенной системы. Было установлено, что этот компилятор подпадает под регулирующие требования и должен быть валидирован, поскольку он генерирует программное обеспечение для медицинского изделия (исходный код программного обеспечения и исполняемое программное обеспечение), которое помещается в проектные записи медицинского изделия.
Описание процессов системы качества
Для этого примера подходящими являются два процесса системы качества. Первый - это общий процесс системы качества по разработке медицинского изделия, содержащего программное обеспечение класса C (см. рисунок C.1). Вторым является процесс разработки исполняемых программных модулей, которые реализуют программный проект и отвечают всем программным требованиям. Эти программные модули включают в себя языковой компилятор OTSS (off-the-shelf-system/система, готовая к использованию) C/C++ (см. "Имплементация ПО (программного обеспечения)" на рисунке C.1).
Рисунок C.1 - Имплементация программного обеспечения
класса C медицинского изделия
Предшествующие процессы
Процессу имплементации программного обеспечения предшествуют процессы разработки документации системного уровня (например, требований, проекта, анализа опасностей), которая характеризует разрабатываемое медицинское изделие. Часть системы, реализованная в программном обеспечении, затем характеризуется посредством процессов разработки требований к программному обеспечению, разработки проекта программного обеспечения и других программных документов или планов. Параллельно с разработкой программного обеспечения реализуются дополнительные процессы по разработке аппаратной части медицинского изделия.
Процесс имплементации программного обеспечения
Используемый формальный язык программного обеспечения - язык программирования C/C++. Языковой компилятор C/C++ используется для компиляции программных операторов высокого уровня в исполняемый машинный код. Выходными данными процесса имплементации программного обеспечения являются базовые программные модули, которые коллегиально рецензируются на предмет их полноты и правильности. Рецензирование программного модуля проводится в виде экспертной оценки, для которой программный модуль должен быть скомпилирован без ошибок на самом высоком уровне компилятора. Любые предупреждающие сообщения компилятора должны быть объяснены во время экспертной оценки.
Последующие процессы тестирования
Программные модули испытываются или верифицируются в нескольких процессах тестирования:
- модульное тестирование программного обеспечения. Отдельные программные модули проверяются на логическую корректность и предельные условия для каждого модуля. Тестирование может проводиться в системе разработки или целевой системе (аппаратном обеспечении медицинского изделия). Простые программные модули могут не тестироваться, если установлено, что проводимая экспертная оценка кода достаточна для обнаружения логических ошибок модуля;
- тестирование интеграции программных модулей. Программные модули интегрируются и тестируются для обеспечения того, что проект программного обеспечения правильно реализован и что предельные условия верифицированы согласно проекту. Тестирование проводится в целевой системе;
- верификация требований к программному обеспечению. Завершенное программное приложение верифицируется на соответствие всем требованиям к программному обеспечению. Верификация выполняется в целевой системе;
- интеграционное тестирование системы. Программное и аппаратное обеспечение в медицинском изделии тестируется для обеспечения правильной имплементации проекта системы и проверки граничных условий в отношении проекта системы;
- верификация и валидация системы. Медицинское изделие верифицируется на уровне системных требований, а также валидируется на предмет предусмотренного применения.
Анализ риска отказа процесса
Проект осуществлялся в соответствии с процедурой компании по оценке рисков процесса. Общий процесс системы качества по имплементации программного обеспечения для медицинских изделий класса C (который включает в себя все процессы, описанные на рисунке C.1) по своей природе сопряжен с высоким риском, поскольку он генерирует программное обеспечение, которое функционирует в медицинском изделии класса C.
Языковой компилятор C/C++ как часть процесса имплементации программного обеспечения оценивается как малоопасный на основе двух факторов:
- компилятор прямо не причиняет серьезной травмы или смерти пациенту, оператору или людям, находящимся рядом;
- на выходе (исходный код программного обеспечения и исполняемое программное обеспечение) этого инструмента выполняется последующая верификация (например, тестирование программного модуля, тестирование интеграции программных модулей, верификация требований к программному обеспечению, тестирование системной интеграции, верификация и валидация системы).
Определение предусмотренного применения
Цель и назначение языкового компилятора OTSS C/C++ в описанном выше процессе имплементации программного обеспечения состоит в том, чтобы создать исходный код встроенной системы и выполнить процесс компиляции для генерации исполняемого программного обеспечения для медицинского изделия класса C.
Требования к использованию программного обеспечения
a) Инструмент должен выполнять компиляцию в машинный код целевой платформы C и C++ для работы на процессоре компьютера с сокращенным набором команд (RISC) с использованием операционной системы выбранного поставщика.
b) Компилятор должен иметь отладчик исходного кода.
c) Компилятор должен удовлетворять требованиям стандарта C и C++ Американского национального института стандартов (ANSI).
d) Компилятор должен интегрироваться с различными средами разработки, которые соответствуют отраслевым стандартам.
e) Поставщик должен публиковать список известных ошибок, доступный для поиска. Список следует использовать в качестве справочного материала для консультации по мере необходимости.
f) Поставщик должен иметь большую базу пользователей в регулируемой отрасли.
Анализ риска отказа программного обеспечения
Анализ риска языкового компилятора OTSS C/C++ показывает, что в случае ошибки могут произойти следующие события.
- Риск 1. Поставщик не может обеспечить соответствующие бизнес-процессы, методы разработки и возможности поддержки.
- Снижение риска 1. См. раздел "Процесс выбора поставщика" ниже.
- Риск 2. Компилятор выдает некорректные исполняемые операторы.
- Снижение риска 2. См. раздел "План валидации" ниже.
- Риск 3. Пользователь, который не применяет самый строгий уровень проверки ошибок, неправильно использует компилятор.
- Снижение риска 3. Улучшить обучение, процедуры и рабочие
инструкции.
Процесс выбора поставщика
Проект выполнялся в соответствии с процедурой системы качества компании по выбору и одобрению поставщиков, и это зафиксировано в проектных записях. Процедура включала в себя оценку на месте с рассмотрением политик, процедур, задач и деятельности поставщика по разработке жизненного цикла программных систем. Возможности предлагаемого поставщиком языкового компилятора OTSS C/C++ были верифицированы на соответствие требованиям к использованию программного обеспечения, определенным выше.
План валидации
Для языкового компилятора OTSS C/C++ был выбран следующий подход к валидации. Процесс выбора поставщика установил, что поставщик соответствует всем задокументированным требованиям к использованию программного обеспечения. Компилятор достаточное время работал в режиме выполнения у поставщика и будет значительное время работать в режиме выполнения в процессе отладки и тестирования, осуществляемых в проекте. В последующих процессах выходные данные компилятора подвергаются следующим видам динамического тестирования:
- модульное тестирование программного обеспечения;
- тестирование интеграции программных модулей;
- верификация требований к программному обеспечению;
- тестирование системной интеграции;
- верификация и валидация системы.
Отчет по валидации
Содержание отчета по валидации следующее:
- описание OTSS (системы, готовой к использованию) от поставщика;
- требования к использованию программного обеспечения:
- требования к аппаратному обеспечению;
- требования к программному обеспечению;
- патчи;
- оценка риска и анализ опасностей;
- выбор поставщика;
- деятельность по установке;
- валидация:
- сценарии тестирования использования программного обеспечения и
результаты тестирования;
- список известных ошибок;
- управление конфигурацией:
- обучение;
- место установки;
- обслуживание;
- снятие с эксплуатации.
Выбор инструментов
- Стадия определения (идентификации):
- предусмотренное применение;
- планирование валидации;
- планирование менеджмента риска (оценка рисков).
- Стадия имплементации:
- меры по управлению риском;
- аудит поставщиков.
- Стадия имплементации - развертывания:
- установочная квалификация;
- внутреннее обучение при необходимости;
- окончательное приемочное тестирование.
- Стадия обслуживания:
- планирование обслуживания;
- анализ известных проблем.
Пример 5: Система автоматизированного тестирования
программного обеспечения
Вводная информация
В данном примере изготовителем является производитель медицинского изделия класса C. Медицинские изделия этого изготовителя управляются программным обеспечением. Программное обеспечение архитектурно разделено на два основных компонента: консоль оператора и встроенное программное обеспечение управления в режиме реального времени. Консоль оператора является основным пользовательским интерфейсом системы. Встроенное программное обеспечение управления в реальном времени - это программное обеспечение, которое выполняет электромеханическое управление, сбор данных, синхронизацию и тому подобное. Программное обеспечение консоли оператора (находящееся в ПК под управлением стандартной операционной системы и базы данных) и встроенное программное обеспечение в режиме реального времени (находящееся на процессорной карте встроенной платы) взаимодействуют при помощи стандартного аппаратного обеспечения Transmission Control Protocol/Internet Protocol (TCP/IP) и протокольного интерфейса.
Менеджер по программному обеспечению проекта решил, что было бы полезно улучшить процесс разработки и тестирования программного обеспечения путем внедрения автоматизированного тестирования программного обеспечения. Он решил внедрить автоматизированное тестирование программного обеспечения сначала только для консоли оператора. Автоматизированное тестирование программного обеспечения будет проводиться как в точке тестирования интеграции, так и в точке тестирования системы программного обеспечения.
Определение применимости регулирующих требований к программному обеспечению
Рассматриваемое программное обеспечение для автоматизированного тестирования будет использоваться для проведения испытаний, что является обязательным требованием в процедурах разработки программного обеспечения изготовителя. Также оно предоставит свидетельства проведения требуемого регрессионного тестирования в точках интеграционного и системного тестирования. Исходя из этого, было установлено, что программное обеспечение для автоматизированного тестирования предназначено для автоматизации части процесса разработки и поэтому будет подлежать валидации в соответствии с требованиями ИСО 13485.
Определение процесса
Для лучшего понимания требований и рисков, связанных с внедрением программного обеспечения автоматизированного тестирования консоли оператора, менеджер по программному обеспечению определяет использование программного обеспечения автоматизированного тестирования в ходе процесса разработки программного обеспечения следующим образом.
При разработке программного обеспечения изделия планируется интегрировать в системное программное обеспечение различные модули в разное время. Кроме того, уже интегрированные в систему модули будут подвержены изменениям из-за исправления дефектов и изменения требований. Автоматизированную тестовую систему планируется использовать для регрессионного тестирования программного обеспечения интегрированной системы и для окончательного тестирования конкретного модуля в системе. План проекта программного обеспечения предусматривает интеграцию или обновление модулей два-три раза в неделю. Автоматические тесты будут выполняться в каждой из этих точек интеграции, чтобы убедиться, что новые функциональные возможности работают правильно и что ранее работавшие функциональные возможности не пострадали от нового добавленного кода или изменений в коде в конкретной сборке. Автоматизированные тесты будут выполняться на уровне тестирования программных систем для сборок, которые являются кандидатами на окончательный выпуск для валидации и в конечном счете для потребителей. Автоматизированное тестирование будет также использоваться в случае обнаружения дефектов на заключительных этапах разработки, которые необходимо исправить, чтобы обеспечить уровень регрессионного тестирования, который дополняет запланированное ручное тестирование.
Анализ риска
Менеджер программного обеспечения теперь проводит анализ для определения любых возможных последствий неправильного использования или функционирования программного обеспечения автоматизированного тестирования.
В первую очередь менеджер программного обеспечения должен оценить, сможет ли отказ процесса автоматизированного тестирования, отказ программного обеспечения автоматизированного тестирования или ошибка, сделанная кем-либо из пользователей, в конечном итоге привести к дефекту в медицинском изделии, который потенциально может быть источником вреда пациенту, оператору, стороннему лицу, специалисту по обслуживанию или окружающей среде.
- Самое большое беспокойство у менеджера вызывает то, что система автоматизированного тестирования программного обеспечения выдаст ложный результат о правильном функционировании тестируемого программного обеспечения консоли оператора, хотя в программном обеспечении все еще содержатся дефекты.
- Если необнаруженные дефекты находятся в критической области программного обеспечения, они могут вызвать неисправность в медицинском изделии, что может повлечь за собой причинение вреда.
- Менеджер по программному обеспечению понимает, что такой риск может возникнуть в результате неправильного менеджмента, использования автоматизированного тестового программного обеспечения или дефекта в самом автоматизированном тестовом программном обеспечении.
- Менеджер программного обеспечения решает, что чрезвычайно важно установить граничные условия, при которых можно использовать автоматизированную систему тестирования программного обеспечения, и для чего она может быть использована, чтобы группа разработчиков и группа тестирования программного обеспечения не чрезмерно полагались на систему.
- Лица, которые будут участвовать в настройке, программировании и эксплуатации автоматизированного программного обеспечения для тестирования, должны быть обучены для выполнения своих функций.
- Менеджер программного обеспечения считает, что при наличии средств управления указанными факторами потенциальные связанные риски будут снижены до допустимого уровня.
Определение предусмотренного применения программного обеспечения
Проанализировав возможное применение автоматизированного программного обеспечения для тестирования и связанные с ним риски, менеджер программного обеспечения готов сформулировать цель и предназначение автоматизированной системы тестирования программного обеспечения:
- автоматизированная система тестирования будет использоваться для тестирования сборок программного обеспечения в точках интеграции в процессе разработки;
- автоматизированная система тестирования будет использоваться для валидации тестирования и предварительных сборок выпуска в точках тестирования системы программного обеспечения;
- автоматизированная система тестирования будет выполнять регрессионное тестирование системы для обеспечения того, что рабочие процессы не подверглись негативному влиянию недавно введенного или измененного программного обеспечения;
- общая роль автоматизированной системы тестирования будет заключаться в обеспечении дополнительного регрессионного тестирования для проводимого ручного тестирования;
- для несложных и хорошо понятных рабочих процессов автоматизированная система тестирования может использоваться в качестве окончательного фактора, определяющего правильность программного обеспечения, учитывая, что конкретный протокол был верифицирован как соответствующий эквивалентному ручному тестированию;
- автоматизированная система тестирования будет использовать программное обеспечение, которое обеспечивает защитные меры (снижение риска) для системы с программным обеспечением или медицинского изделия в целом.
Планирование валидации
Менеджер программного обеспечения теперь имеет четкое представление об автоматизируемом процессе, о конкретном предусмотренном применении автоматизированной тестовой системы и о возможных связанных рисках. Менеджер программного обеспечения уже установил, что необходимы конкретные средства управления в отношении использования программного обеспечения. Также он установил, что в случае использования системы автоматического тестирования программного обеспечения в соответствии с предусмотренным применением и в сочетании с соответствующими средствами управления она будет иметь допустимый уровень риска.
- В данном случае менеджер программного обеспечения установил, что при правильном использовании автоматизированной системы тестирования программного обеспечения практически отсутствует риск влияния на возникновение дефектов в медицинском изделии. Менеджер определил, что правильное использование означает, что группа разработки и тестирования программного обеспечения не будет чрезмерно полагаться на использование системы для установления правильности программного обеспечения. Принимая во внимание определение риска как низкого, менеджер по программному обеспечению устанавливает, что требования к валидации системы будут характеризоваться низким уровнем усилий и строгости в отношении испытаний автоматизированной системы тестирования программного обеспечения.
Документация по валидации: подход к отчету по валидации
Подход, выбранный менеджером программного обеспечения, заключается в разработке отчета о валидации программного обеспечения для автоматизированной системы тестирования программного обеспечения, который будет включать в себя сводку всей деятельности, связанной с обеспечением необходимого уровня доверия к системе.
Использование критического мышления
Менеджер программного обеспечения далее устанавливает наилучший способ достижения необходимого уровня уверенности в том, что система будет использоваться надлежащим образом, а также не будет способствовать появлению серьезных дефектов в медицинском изделии.
Среди наиболее важных факторов достижения необходимого уровня доверия к системе он выделяет следующие:
- строгое следование определенному предусмотренному применению:
- обеспечение того, что весь персонал, участвующий в разработке и
тестировании программного обеспечения, четко понимает граничные условия
и соответствующее предусмотренное применение системы;
- составление документации: включить в отчет о валидации раздел с
описанием конкретного предусмотренного применения и способы отражения
этой информации в соответствии с планом разработки программного
обеспечения;
- комплексная проверка:
- приобретение стандартной автоматизированной системы тестирования
программного обеспечения у надежного поставщика, чьи системы
тестирования используются для таких же или более критичных приложений;
- анализ предусмотренного применения системы поставщика, чтобы
определить, подходит ли оно для использования по назначению;
- получение информации о том, как поставщик валидировал программное
обеспечение перед выпуском в обращение. Получить подтверждение
валидации коммерческого программного обеспечения у отдела качества
поставщика. Это обеспечит уверенность в том, что система
автоматического тестирования программного обеспечения была должным
образом протестирована поставщиком и создаст базу для дополнительных
действий менеджеру программного обеспечения и группам разработки и
тестирования программного обеспечения;
- установление взаимоотношений с поставщиком с целью обеспечения
уверенности в том, что менеджер программного обеспечения и команда
разработчиков программного обеспечения и тестирования знают об
известных проблемах и дефектах версии программного обеспечения для
тестирования, которое они будут использовать;
- получение представления о планах поставщика по обновлению
программного обеспечения, чтобы предусмотреть собственные планы
перехода на новые версии программного обеспечения и деятельность по
повторной валидации;
- документация: включить в отчет по валидации раздел с описанием
результатов деятельности поставщика по проведению комплексной проверки,
включая информацию о валидации поставщиком автоматизированной системы
тестирования программного обеспечения, о способе доступа к списку
дефектов и об ожидаемом переходе на новые версии программного
обеспечения;
- установочное тестирование:
- убедиться, что компьютерная среда, в которой будет находиться
программное обеспечение, соответствует спецификациям поставщика;
- установить первоначальный протокол высокоуровневого тестирования
с целью обеспечения правильной установки программного обеспечения;
- документация: включить в отчет по валидации раздел с описанием
результатов деятельности по установке;
- менеджмент риска:
- убедиться, что система будет использоваться только в соответствии
с целями и назначением, которые определены менеджером программного
обеспечения;
- включить конкретные допустимые граничные условия в план
разработки программного обеспечения для проекта, в котором будет
использоваться автоматизированная система тестирования;
- провести анализ с целью определения точных зон охвата системы и
убедиться, что ручное тестирование охватывает области, которые не
охватывает автоматизированная система тестирования программного
обеспечения;
- документация: включить в отчет по валидации раздел с описанием
рисков, идентифицированных в ходе первоначального анализа риска, с
указанием того, как каждый из этих рисков будет снижен;
- требования к использованию программного обеспечения:
- разработать перечень функциональных возможностей
автоматизированной системы тестирования, которые будут использоваться.
Разработанный менеджером программного обеспечения и группой разработки
и тестирования программного обеспечения перечень будет поименован как
"Требования к использованию программного обеспечения";
- документация: включить "Требования к использованию программного
обеспечения" в раздел отчета по валидации с описанием каждого из
требований к использованию программного обеспечения;
- валидация автоматизированной системы тестирования:
- использовать "Требования к использованию программного
обеспечения" для установления необходимого уровня доверия. Его можно
установить, взяв три начальных сценария или протокола
автоматизированного тестирования и выполнив параллельный тест для тех
же протоколов, запущенных вручную. Три начальных сценария тестирования
или протоколы реализуют все функциональные возможности, которые будет
использовать команда;
- документация: включить в отчет по валидации раздел с обобщенными
результатами параллельного тестирования, а также доказательства того,
что результаты тестирования были эквивалентны;
- обучение:
- разработать программу обучения для всех пользователей системы,
чтобы убедиться, что они полностью понимают, как использовать систему,
и имеют право на ее использование. Менеджер программного обеспечения
считает, что обучение является одним из наиболее важных элементов,
необходимых для обеспечения безопасного и результативного использования
автоматизированной системы тестирования программного обеспечения;
- документация: включить в отчет по валидации раздел с описанием
необходимого обучения для пользователей системы;
- валидация отдельных автоматизированных протоколов тестирования:
- там, где для тестирования программного обеспечения,
предназначенного для снижения системных, аппаратных или программных
рисков и опасностей, будет использоваться система автоматического
тестирования, убедиться, что каждый протокол верифицирован с помощью
параллельных автоматических и ручных тестов;
- там, где система автоматического тестирования будет
использоваться для окончательного тестирования несложных и хорошо
понятных рабочих процессов, убедиться, что каждый протокол
верифицирован с помощью параллельных автоматических и ручных тестов;
- документация: убедиться, что записи по валидации программного
обеспечения для медицинского изделия содержат доказательства проведения
параллельного тестирования тестовых сценариев или протоколов,
соответствующих данной категории;
- управление конфигурацией:
- убедиться, что установлена и используется только соответствующая
валидированная версия программного обеспечения для автоматического
тестирования;
- по мере того как новые версии программного обеспечения
автоматизированного тестирования становятся доступными от их
поставщика, следует обеспечить своевременное введение новых версий или
изменений посредством управления их имплементацией;
- убедиться, что повторная валидация автоматизированной системы
тестирования учитывает каждую контрольную точку обновления и что каждая
повторная валидация системы проводится и документируется;
- документация: включить в отчет по валидации раздел, описывающий
план управления конфигурацией системы.
Отчет по валидации
В результате предпринятой деятельности по укреплению доверия менеджер программного обеспечения составляет отчет по валидации для окончательного анализа и официального одобрения. В отчете содержатся логические обоснования и соображения по установлению дополнительных действий, которые могут понадобиться, чтобы менеджер программного обеспечения смог сделать вывод о том, что использование автоматизированной системы тестирования программного обеспечения не приведет к сценарию, при котором находящееся в разработке соответствующее медицинское изделие могло бы быть непреднамеренно сочтено несоответствующим. Отчет также содержит доказательства того, что все мероприятия, которые были установлены как важные, были проведены в соответствии с планом.
Отчет по валидации содержит следующее:
- определение процесса;
- анализ риска;
- менеджмент риска;
- предусмотренное применение;
- комплексная проверка поставщика программного обеспечения;
- обучение;
- установочное тестирование;
- валидация предусмотренного применения автоматизированной системы тестирования;
- обслуживание, повторная валидация и управление конфигурацией.
Анализ и официальное одобрение отчета по валидации
Менеджер по программному обеспечению направляет отчет по валидации менеджеру проекта, менеджеру по качеству программного обеспечения и менеджеру по тестированию программного обеспечения для анализа и официального одобрения.
Все рецензенты считают, что менеджер программного обеспечения четко продумал предусмотренное применение системы и понимает все риски, связанные с использованием системы. Рецензенты считают, что была выполнена вся деятельность, необходимая для обеспечения уровня доверия к системе, требуемого для использования системы. Рецензенты официально одобряют план. После этого система считается валидированной и вводится в эксплуатацию.
Пример 6: Простая электронная таблица
История вопроса
Лабораторные аналитики компании ZYX устали извлекать различные спецификации из своей системы управления документами для каждого продукта, который они анализируют, а затем вручную вычислять значение угла, которое им нужно сравнить со спецификацией. Для проведения инспекций в лаборатории используется инструмент. Этот инструмент измеряет три координатных положения, которые аналитики используют для вычисления угла, сравниваемого со спецификацией. Лаборатория недавно столкнулась с тремя случаями, когда аналитик неправильно рассчитал угол (из-за "толстых пальцев", как пояснил аналитик), и аналитики хотели бы предотвратить повторение этой ошибки. Они решают создать электронную таблицу для расчета угла и объединить спецификации для всех 50 продуктов, которые они анализируют, в эту электронную таблицу. Они будут вводить три пары координат, которые измеряются инструментом, выбирать наименование продукта из выпадающего меню и получать результат для приемки/отклонения. Аналитики также рассматривают дополнительный интерфейс для инструмента, чтобы передавать координаты непосредственно в электронную таблицу, но из-за стоимости интерфейса это улучшение откладывается до следующего года.
Определение процесса
Существующий процесс включает в себя следующие шаги:
a) замерить инструментом деталь;
b) записать три пары координат;
c) рассчитать угол;
d) извлечь спецификацию для детали из системы управления документов;
e) сравнить значение угла со спецификацией и установить соответствие или несоответствие;
f) положить лист с отметкой о соответствии или несоответствии на детали и отправить их на склад деталей.
Новый процесс будет включать следующие шаги:
a) получить электронную таблицу из системы управления документами;
b) замерить инструментом деталь;
c) ввести три пары координат в электронную таблицу;
d) визуально сравнить пары координат со значениями инструмента;
e) выбрать номер детали в электронной таблице;
f) выбрать "Рассчитать результат" в электронной таблице;
g) визуально проверить правильность выбора номера детали;
h) в зависимости от результата, положить лист с отметкой о соответствии или несоответствии на детали и отправить их на склад деталей.
Определение предусмотренного применения
Аналитики определяют цель и предназначение электронной таблицы следующим образом: электронная таблица будет принимать три внесенные пары координат, рассчитывать угол и затем сравнивать данный угол со спецификацией для выбранного продукта, выдавая результат о соответствии или несоответствии.
Анализ риска
Аналитики проводят мозговой штурм для идентификации возможных опасностей, связанных с электронной таблицей. Они устанавливают, что неправильный результат может означать, что не соответствующие спецификации детали могут быть использованы в производстве. Для того чтобы такие дефектные детали могли попасть в медицинское изделие и причинить вред конечному пользователю изделия, должно произойти по меньшей мере два других последующих отказа. Тем не менее все же существует незначительный, хотя и маловероятный, риск причинения вреда конечному пользователю. Поэтому существует небольшой риск производства продукта, который не соответствует техническим требованиям. Однако существует больший риск увеличения производственных затрат, поскольку, если дефектные детали используются в производстве, они не будут обнаружены до первой инспекции при сборке. В результате сборочный узел придется демонтировать. Кроме того, при получении ложного результата о несоответствии годные детали могут быть забракованы, что снова приведет к увеличению затрат на брак. Поэтому для решения проблем бизнеса в строгом порядке будут осуществлены дополнительные действия в виде разработки электронных таблиц, процедурного контроля, анализа документов и тестирования.
Планирование валидации
В связи с определением низкого уровня риска производства не соответствующего спецификации продукта, уровень затраченных усилий по проведению данной валидации будет также низким. Аналитики решают объединить требования к электронной таблице и план валидации в единый документ. Аналитики также решают объединить документацию по проекту с высокоуровневым планированием тестирования. Аналитики планируют проведение анализа данных документов всеми членами команды аналитиков (состоящей из четырех человек), а также представителем службы обеспечения качества. В дополнение к этому аналитики планируют проконсультироваться с техническими экспертами для разработки репрезентативного набора тестовых данных для обеспечения уверенности в том, что расчеты осуществляются должным образом. Технические эксперты также должны будут официально одобрить разрабатываемый документ.
Меры по управлению риском
Аналитики рассматривают каждый элемент в электронной таблице, который может привести к ошибке или неправильному результату. Для каждого такого элемента аналитики определяют возможные способы уменьшения риска (см. таблицу C.15).
Таблица C.15
Пример 6 - Риски и способы их уменьшения
Риск | Уменьшение рисков |
Неверные величины могут быть введены | Подтвердить каждую пару величин, введенных с помощью инструмента, через процедурный контроль. Для этого в новый процесс был добавлен шаг d) |
Расчеты могут быть неверны | Удостовериться, что формула является правильной и что она предоставляет точные результаты, как необходимо |
Продукт может быть выбран ошибочно | Подтвердить номер детали через процедурный контроль. Для этого в новый процесс был добавлен шаг g) |
Макрос для обозначения результата может быть неверным | Удостовериться, что макрос верен и функционирует как предназначено |
Спецификации в электронной таблице могут быть неверны | Удостовериться, что спецификации в электронной таблице соответствуют спецификациям на все 50 продуктов. Дополнить процесс внесения изменений в спецификации, чтобы при изменении спецификации требовалось обновление электронной таблицы. (Это никогда не происходило, но возможно.) |
Формула расчета или макрос могут быть изменены после валидации | Валидированная электронная таблица с элементами управления конфигурацией будет помещаться в систему управления документами и извлекаться при необходимости. Элементы управления конфигурацией будут включать защиту паролем и блокировку ячеек для всех ячеек, не связанных с вводом данных |
Задачи валидации
Используемая формула понятна, и разработчик имеет опыт разработки макросов электронных таблиц. Валидация будет подтверждать следующие элементы:
- расчеты;
- макрос;
- функцию блокировки ячеек (заблокированные ячейки не могут быть изменены);
- проверку ввода данных (значения в допустимом диапазоне, соответствующий выбор продукта, информативные сообщения об ошибках).
Поскольку электронная таблица одномоментно выдает только один результат, стресс-тестирование или тестирование производительности не требуется. Для всех тестов будет создан единый план тестирования и отчет. Отчет будет содержать готовую для применения электронную таблицу, а также подтвердит управление этой электронной таблицей в системе управления документами компании.
Развертывание
Перед внедрением новой системы процесс тестирования завершается, и операторы производства проходят аттестацию по эксплуатации новой системы обработки данных визуального контроля.
Инструменты из набора инструментов
- Определение требований (документированы в плане валидации).
- Отказ процесса и анализ рисков (документированы в плане валидации).
- Предполагаемое использование (документированы в плане валидации).
- План валидации.
- Планирование испытаний.
- Аттестация оператора.
- План технического обслуживания (что требуется для регрессионного анализа).
Обслуживание
Обслуживание электронной таблицы будет требоваться каждый раз, когда спецификация продукта изменяется или добавляется новый продукт. План эксплуатационных испытаний будет разработан с репрезентативным подмножеством полных проверочных тестов для обеспечения уверенности в том, что новые элементы не нарушают электронную таблицу. План технического обслуживания потребует регрессионного анализа с целью определения необходимости добавления дополнительных (специфичных для вносимых изменений) тестовых сценариев к имеющемуся набору тестов. Этот план также описывает, как обновить электронную таблицу (например, разблокировать ячейки, изменить, заблокировать повторно).
Пример 7: Электронная таблица (более сложная)
Описание программного обеспечения
Команда разработчиков программного обеспечения использовала электронную таблицу Microsoft Excel в качестве средства разработки. (Microsoft Excel упоминается только в качестве примера широко доступного на рынке и подходящего продукта. Эта информация приведена для удобства пользователей настоящего стандарта и не является одобрением ИСО этого продукта.) В эту электронную таблицу будут записывать проекты переводов сообщений для пользователей медицинских изделий класса C или D. Первоначально эти сообщения от изделия пользователям были написаны на американском английском языке. Последующие выпуски программного обеспечения этих изделий будут поддерживать семь языков. Электронная таблица состоит из семи столбцов. Самый левый столбец - это сообщение изделия на английском языке для каждого сообщения от изделия. Каждый из оставшихся столбцов представляет один из поддерживаемых международных языков, и каждая строка в столбце представляет перевод с английского на международный язык для конкретного англоязычного сообщения в крайнем левом столбце этой строки.
Предусмотренное применение
Электронная таблица удовлетворяет временные потребности по:
- визуальной организации сообщений на английском языке и их перевода,
- созданию электронной таблицы, которая может быть отправлена местным представителям для сбора переведенных сообщений либо непосредственно в виде электронной таблицы, либо в рукописном виде на бумажном носителе электронной таблицы, а также
- предоставлению временного средства хранения данных для переведенных сообщений.
После того как переводы собраны и переведены в программное обеспечение медицинского изделия, нет необходимости хранить или поддерживать электронную таблицу.
Вычисляемые ячейки или макросы не являются частью этой электронной таблицы.
Определение необходимости валидации
Excel используется просто для форматирования информации для распространения и сбора иноязычных переводов сообщений изделия. На первый взгляд, электронная таблица кажется простым приложением Excel, и возникает соблазн решить, что она не нуждается в валидации.
Задается следующий вопрос (5.2): "Могут ли отказ или скрытые недостатки программного обеспечения отрицательно повлиять на безопасность медицинских изделий или качество медицинских изделий?"
Ответ на этот вопрос очевиден - "да". Если программное обеспечение или электронная таблица выходит из строя таким образом, что искажаются переводы хранящихся там сообщений, то отказ может повлиять на безопасность изделия. Хотя команда считает, что вероятность сбоя для этого "простого приложения" является низкой, вероятность все еще находится в рамках требований по валидации ИСО 13485.
Оценка риска
Если сообщения, содержащиеся в программном обеспечении изделия, переведены не должным образом, то пользователь может запутаться или неправильно их интерпретировать. Следовательно, существует возможность косвенного вреда пациенту, использующему изделие. Отказ программного обеспечения может быть обнаружен, и существует множество возможностей для перекрестных проверок в процессе разработки и валидации изделия для обнаружения и исправления любых отказов программного обеспечения.
Ниже приведены возможные виды отказов, которые могут негативно повлиять на программное обеспечение изделия:
- искажение оригиналов англоязычных сообщений, подлежащих переводу, в результате потери входного файла, потери отдельных сообщений, неправильного порядка сообщений, что приводит к потере контекста или искажению отдельных сообщений в результате случайной потери, замены или перестановки символов;
- искажение отдельных переведенных сообщений, подготовленных и собранных из региональных отделений. Повреждение может быть вызвано потерей входного файла, потерей отдельных сообщений, неправильным порядком сообщений, что приводит к потере контекста или повреждению отдельных сообщений путем случайной потери, замены или переноса символов. Существует дополнительная вероятность для повреждений в любом языке, требующем неанглийских шрифтов, если шрифты неправильно установлены в Excel;
- искажение таблицы собранных результатов, которая показывает аккумулированные результаты для каждого перевода. Повреждение может быть вызвано потерей входного файла, потерей отдельных сообщений, искажением сообщений, что приводит к потере контекста или повреждению отдельных сообщений путем случайной потери, замены или перестановки символов. В дополнение к неправильному порядку строк в электронной таблице может также произойти искажение столбцов. Столбцы, которые не отображают переведенные сообщения в собственных шрифтах и наборах символов, будут неправильно интерпретированы программистами при переводе сообщений в код.
Планирование валидации
Разработчики программного обеспечения признают потенциальный риск для пациента, если сообщения для нового изделия окажутся ошибочными. Тяжесть последствий такого отказа программного обеспечения может быть высокой. Необходимо предпринять усилия для создания уверенности в том, что сообщения, организованные в электронной таблице, представляют собой правильные переводы.
Однако Excel используется только для организации информации. Кажется маловероятным, что любой объем тестирования Excel обнаружит какие-либо дефекты, способные повредить сообщения. Когда инженеры рассматривают эту проблему, то обнаруживают, что к этому виду отказа гораздо чаще приводит человеческий фактор, чем простое приложение Excel.
Размышляя о человеческом факторе, инженеры понимают, что не существует настолько четко определенных процессов для сбора переводов или верификации того, что никакая ошибка человека не проникла в процесс.
Инженеры создают письменную процедуру сбора и верификации переведенных сообщений. Затем они рассматривают возможные риски отказа их процесса, как ошибки программного обеспечения (например, электронной таблицы Excel) могут способствовать этому отказу, и, наконец, что можно сделать для валидации процесса, включая электронную таблицу.
Меры по управлению риском
После более точного определения процесса сбора переводов инженеры определяют меры управления риском для защиты процесса от внесения ошибок в переводы сообщений.
Меры по управлению риском, которые защищают процесс сбора переводов, также защитят программное обеспечение от несоответствия его предусмотренному применению.
- Полученные из региональных отделений переводы должны предоставляться либо в бумажном (печатном) формате, либо в электронном формате с сопроводительной печатной копией. Если региональное отделение предоставляет электронную версию, то данные в этой электронной таблице будут сверяться (и документироваться) с печатной копией при ее передаче в сводную электронную таблицу перевода. Эта верификация защитит от любой неправильной интерпретации результатов, вызванной повреждением электронной таблицы во время передачи или различиями в особенностях шрифта между компьютером, поставляющим перевод, и компьютером, получающим переводы.
- После того как все переводы собраны и помещены в сводную электронную таблицу, электронная таблица в печатном виде должна быть направлена в каждое региональное отделение для рассмотрения и официального одобрения. Это официальное одобрение региональными отделениями защитит от любого неправильного толкования результатов, вызванного повреждением электронной таблицы во время передачи или различиями в особенностях шрифта между компьютером, поставляющим перевод, и компьютером, получающим переводы.
- После того как сводная электронная таблица будет принята всеми региональными отделениями, официально разработчиками и ответственными за обеспечение качества, печатная копия сводной электронной таблицы должна стать исходным материалом для процесса разработки программного обеспечения для изделия. Кроме того, печатная копия основной электронной таблицы должна быть источником любых ожидаемых результатов верификации переводов в программном обеспечении изделия.
Задачи по валидации
В дополнение к этим мерам по управлению риском необходимо выполнить другие задачи верификации и валидации для обеспечения того, чтобы программное обеспечение надлежащим образом соответствовало своему временному предусмотренному применению. Эти задачи заключаются в следующем:
- по каждому письменному переводу, полученному от региональных отделений, печатная копия обновленной сводной электронной таблицы должна быть сверена строка за строкой с печатной копией отдельной электронной таблицы перевода. Чтобы исключить любые ошибки перевода, вызванные различиями шрифтов между компьютерными платформами или принтерами, необходимо сверить печатные копии между собой;
- процесс управления версиями должен быть подробно задокументирован. Этот процесс должен конкретно учитывать следующее:
- изменения в требованиях к сообщениям (например, на английском
языке) по мере развития функциональных возможностей изделия;
- изменения в сводном документе по мере того, как региональные
офисы предоставляют переводы, а также анализируют и модифицируют
обновленную сводную электронную таблицу;
- хотя электронная таблица очень проста, с ее использованием связаны некоторые вполне реальные риски управления версиями;
- конфигурация электронной таблицы должна включать номер версии самой электронной таблицы, версию используемого Excel, конфигурацию компьютерной платформы и конфигурацию принтера, используемого для создания печатной копии электронной таблицы. Полная конфигурация важна, поскольку различия шрифтов могут существовать в разных установках Windows или Office и в разных версиях встроенного ПО принтера. Единственный способ убедиться, что переводы не изменяются непреднамеренно, - использовать ту же конфигурацию при использовании электронной таблицы;
- конфигурация электронной таблицы (т.е. операционная среда и управление версиями) должна также управляться, чтобы предотвратить хаотичные, несогласованные изменения. Ответственность за принятие решения о внесении изменений в конфигурацию и документирование истории изменений возлагается на одного человека;
- версия каждой электронной таблицы должна быть отражена в ее печатной версии;
- таблицы перевода в программном обеспечении изделия должны указывать, какая версия основной электронной таблицы на бумажном носителе использовалась в качестве входных данных для программного обеспечения по переводу сообщений;
- индивидуальная задача по верификации перевода должна включать следующее:
- сообщение на английском языке должно быть проверено строка за
строкой путем сравнения сводной версии и версии перевода электронной
таблицы. Это сравнение защищает от любого повреждения (например,
поврежденных или отсутствующих сообщений) файла электронной таблицы,
которое могло произойти, когда файл был передан региональным отделениям
и когда файл был возвращен региональными отделениями;
- после того как переводы вставлены в основную электронную таблицу
(вручную или с помощью функции вырезания/вставки Excel), следует
провести верификацию путем построчного сравнения полученного результата
на бумажном носителе пересмотренной сводной электронной таблицы с
печатной копией электронной таблицы перевода;
- когда программное обеспечение устройства тестируется для
осуществления сообщений, процедуры тестирования должны использовать
печатную копию последней версии сводной электронной таблицы (и должны
ссылаться на номер версии) для сравнения осуществленных сообщений с
предусмотренными сообщениями.
Все эти валидационные задачи должны быть задокументированы и собраны в качестве объективных свидетельств валидации процесса и таблицы Excel.
Этот подход к валидации приводит к 100%-ной верификации полученных результатов в сравнении с исходными данными программного обеспечения. Дальнейшее тестирование электронной таблицы не планируется. Несмотря на отсутствие традиционного тестирования, инженеры чувствуют себя уверенно в процессе своей деятельности и считают, что их обоснование валидации было ценной практикой. Инженеры считают, что любой отказ программного обеспечения будет обнаружен, и у них есть путь восстановления через печатные копии, которые собираются и записываются в соответствующих точках процесса. Печатные копии и документированные построчные проверки предоставляют документальные свидетельства деятельности.
Обслуживание
Электронная таблица предназначена для удовлетворения временных потребностей. Она должна быть удалена после того, как переведенные сообщения были встроены в код. Планы по обслуживанию не создаются.
Обсуждение
Предусмотренное применение и первоначальный анализ рисков, связанных с использованием электронной таблицы, имеют решающее значение для определения того, что электронная таблица требует дополнительного внимания с точки зрения валидации. При другом предусмотренном применении та же самая электронная таблица вполне могла бы привести к выводу, что использование электронной таблицы имеет низкий риск и низкую сложность. Если определение предназначенного применения заключалось бы просто в отслеживании хода сбора переводов (т.е. переводы в электронной таблице не использовались бы в деятельности по проектированию и имплементации), то можно было бы заключить, что практически не существует риска для целостности изделия, электронная таблица является лишь инструментом управления бизнесом и не подпадает под регулирующие требования по валидации.
"Процесс", который это программное обеспечение "автоматизировало", был частью процесса сбора данных, форматирования и хранения переводов сообщений для изделия. Пример интересен с нескольких точек зрения:
- валидация требовала крайне малого, почти незначительного тестирования программного обеспечения для валидации его применения. Важно отметить, что программное обеспечение (Excel) и электронная таблица были валидированы для этого конкретного использования, но не были валидированы в целом для любого использования. Команда сочла, что тестирование вряд ли выявит какие-либо дефекты в программном обеспечении, но существует уязвимость изделия, если в программном обеспечении каким-то непредсказуемым образом произойдет отказ;
- валидация состояла из 100%-ной верификации выходных данных электронной таблицы. Печатные версии использовались как "золотой стандарт". После того как копии были одобрены и учтены в файле проектирования и разработки, любой последующий отказ программного обеспечения был несущественным. Любой отказ до официального одобрения программного обеспечения будет идентифицирован в процессе анализа и одобрения;
- "процесс" был модифицирован, чтобы сделать его невосприимчивым к любому отказу программного обеспечения электронных таблиц;
- инженеры полагали, что вероятность ошибки со стороны человека намного выше вероятности отказа программного обеспечения в этом приложении. Пользователи могут делать опечатки, могут использовать неправильную версию электронной таблицы или совершать другие подобные ошибки. В этом случае "валидация программного обеспечения" также сделала процесс более невосприимчивым к ошибкам со стороны человека;
- этот пример подтверждает важность управления конфигурацией даже для обычных офисных средств повышения производительности.
Примечание - Этот пример был основан на реальном случае, который не был так тщательно обработан. В реальной ситуации возникли пользовательские ошибки, связанные с версиями электронных таблиц. Неожиданно проблемы, относящиеся к версиям шрифтов различных установок Excel на разных компьютерах, дали разные результаты в печатном виде (отличающиеся шрифты принтеров также оказались проблемным моментом). Таким образом, казалось бы, простая электронная таблица, валидация которой чуть было не была отклонена за ненадобностью, на самом деле стала проблематичной в своем искажении переводов сообщений.
Пример 8: Параметрический стерилизатор
Сотруднице Always-Safe Medical Device Company Мэри было поручено возглавить работу по валидации новой автоматизированной стерилизационной системы, которая будет специально разработана для использования в ее компании.
Определение процесса
Мэри начинает первое определение и документирование с обобщения того, что она знает о внедряемом на ее предприятии процессе стерилизации 100%-ным этиленоксидом (ETO):
- медицинские изделия помещаются в стерилизатор вручную. Этот процесс включает оценивание параметров цикла стерилизации для поддержания выпуска продукции по параметрам (параметрический выпуск);
- программное обеспечение автоматизированной системы стерилизации управляет циклом стерилизации;
- медицинские изделия вручную извлекаются после завершения цикла и переносятся в камеру для дегазации.
Анализ риска процесса
Мэри серьезно обеспокоена связанным с этим процессом риском, так как отказ процесса может иметь серьезные последствия, в том числе следующие:
a) неправильная стерилизация медицинских изделий. Отказ процесса может привести к серьезному вреду или смерти вследствие инфицирования при использовании нестерильной продукции;
b) потеря информации по истории изделия и прослеживаемости продукции;
c) выброс токсичных химических веществ в производственные помещения или окружающую среду. Отказ процесса может привести к серьезным травмам или смерти операторов стерилизаторов, а также людей, находящихся поблизости.
Поэтому Мэри рассматривает вопрос о том, какие меры по управлению риском следует принять и верифицировать для снижения этих рисков. Мэри считает, что риском можно управлять с помощью точного соблюдения техники выпуска продукции по параметрам процесса стерилизации с целью обеспечения того, что нужное количество газа используется в течение надлежащего периода времени при правильной температуре и правильной относительной влажности. Кроме того, визуальный контроль правильности параметрических значений от встроенных датчиков стерилизатора независимо подтвердит адекватность хода процесса стерилизации. Наконец, она посчитала, что для борьбы с утечкой химических веществ на объекте необходимы отказоустойчивые аварийные выключатели и защитные герметичные сооружения.
При выполнении данных мер по управлению риском только множественные одновременные отказы системы могут привести к появлению на выходе процесса нестерильного изделия. Однако, в связи с высокой тяжестью последствий отказов, Мэри определяет остаточный риск процесса как высокий. Именно поэтому необходим высокий уровень строгости при проведении валидации.
Определение цели и назначения программного обеспечения
Мэри хочет иметь детальное представление о том, как в данной системе будет использоваться программное обеспечение. В первую очередь она рассматривает, что именно должно делать программное обеспечение. В рассматриваемой системе программное обеспечение управляет процессом стерилизации медицинских изделий 100%-ным этиленоксидом (ETO), а также записывает информацию для включения в файл истории изделия и проводит анализ значений параметров стерилизации для поддержки выпуска продукции по параметрам. Для удовлетворения текущего спроса на продукцию был закуплен новый стерилизатор, камера которого вмещает партии большего размера, чем существующая система. Операторы процесса стерилизации совместно со службой обеспечения качества будут исследовать новую систему для установления критериев приемки выпуска медицинских изделий. Мэри понимает, что основные усилия будут направлены на контроль и мониторинг функционирования стерилизационной камеры в режиме реального времени во время циклов стерилизации, а также на сохранение информации в базе данных. Мэри с удовлетворением узнает о планируемом физическом размещении системы в стерилизационном подразделении и что система, как правило, будет отключаться один раз в неделю для обеспечения любого необходимого обслуживания.
Мэри устанавливает, что программное обеспечение будет автоматизировать все аспекты цикла стерилизации, от укладки вручную изделий в камеру до выгрузки вручную из камеры.
Мэри документирует цель и назначение программного обеспечения следующим образом:
- Программное обеспечение системы стерилизации будет осуществлять управление и мониторинг процесса стерилизации, а также будет оценивать параметры цикла стерилизации для поддержки выпуска продукции по параметрам (параметрический выпуск).
Планирование валидации
Теперь, когда Мэри понимает, для чего предназначено программное обеспечение, она готова разработать план валидации с высоким уровнем строгости. Она знает о необходимости последующей подробной детализации, но хочет начать планирование валидации сейчас, чтобы она могла заранее обнаружить риски отказа программного обеспечения и рассмотреть идентифицированные риски при завершении своего планирования.
Из-за определенного ранее высокого остаточного риска процесса Мэри считает, что она должна обеспечить высокий уровень детализации и соблюдения формальности в процессе валидации. Она рассчитывает использовать высокий уровень строгости и детализации в документации и рассматривает создание большинства документов в качестве самостоятельных, а не объединенных, как это часто делают при меньшем требуемом уровне усилий. Из-за высокого риска рассматриваемой системы она решает относиться к разработке с тем же уровнем строгости, что она будет использовать для разработки программного обеспечения медицинских изделий. Поэтому она решает следовать требованиям МЭК 62304:2006 (включая Изм. 1:2015) в качестве методологии управления жизненным циклом. В качестве руководства по менеджменту риска программного обеспечения она ссылается на МЭК/ТО 80002-1. Кроме того, для обеспечения рассмотрения всех потенциальных источников вреда Мэри решает применить в процессе разработки анализ древа неисправностей программного обеспечения. Она также решает формально определить и документировать требования к бизнес-процессам пользователей и требования к программному обеспечению. Любой функционал, представляющий особое беспокойство, будет специфически идентифицирован. Мэри также планирует проведение официального анализа требований к программному обеспечению. Официальное одобрение должно быть проведено отделом обеспечения качества, инженером по стерилизации и менеджером по стерилизации. Из-за критичности и высокого риска данной системы окончательное одобрение отчета по валидации будет проведено при участии членов высшего руководства.
Определение требований к программному обеспечению
Теперь Мэри составляет в письменном виде определение требований к программному обеспечению. Она решает, что требования к программному обеспечению должны касаться аварийных сигналов, обработки ошибок и сообщений, подтверждения параметрических настроек, интерфейса к системе записей истории изделия, управления и мониторинга датчиков, управления и мониторинга перемещений.
Установление уверенности и управления программным обеспечением
Мэри помещает всю разработку жизненного цикла под управление внутренних процедур управления разработкой Always-Safe. Поскольку все делается внутри организации, никакой деятельности в отношении поставщика осуществлять не требуется.
Определение границ программного обеспечения с другими системами
Затем Мэри рассматривает возможное взаимодействие нового стерилизатора с другими системами. Она устанавливает, что единственное взаимодействие будет происходить с существующей системой баз данных Always-Safe, которая будет хранить данные, сформированные во время циклов стерилизации.
Анализ рисков отказов программного обеспечения
Несмотря на уже установленный Мэри высокий риск автоматизируемого бизнес-процесса, ей все еще необходимо провести анализ риска отказа программного обеспечения. Используя настоящий стандарт в качестве эталонного референтного материала, Мэри выбирает для этой деятельности количественную модель определения риска. Распределение (ранжирование) новой системы по уровням тяжести и вероятности она проводит следующим образом:
- риск по уровню "тяжести" высок (10), потому что отказ системы может привести к смерти или серьезной травме;
- риск по уровню "вероятности" также высок (10), так как отказ самого программного обеспечения может привести к причинению вреда, поскольку именно программное обеспечение принимает решение о приемке в отношении стерилизации.
Она определяет значение риска как 20, что по установленным критериям относит его к недопустимому риску. Такие результаты оценивания риска означают, что должна применяться самая строгая методология валидации. Применяемая методология должна быть столь же строгой и всеобъемлющей, как если бы стерилизатор сам был медицинским изделием.
В результате снижения остаточный риск данной автоматизированной системы должен быть настолько низок, насколько это возможно и практически осуществимо. Из-за высокого уровня тяжести вреда, исходящего от системы, стерилизация по своей сути является процессом с высоким уровнем риска. Следовательно, также будет выполняться дополнительная, связанная с риском деятельность, указанная в МЭК/ТО 80002-1.
Завершение плана валидации
Поскольку Мэри уже завершила определение требований к программному обеспечению, оценила риск и определилась с подходом к имплементации программного обеспечения, то теперь она имеет достаточно информации для завершения детального плана валидации.
Составляя первый проект своего плана валидации, Мэри решила применять строгий подход к менеджменту риска. Она уже запланировала обеспечение высокого уровня детализации и соблюдения формальности в процессе валидации.
Соответственно, она подбирает инструменты менеджмента риска (установленные в МЭК/ТО 80002-1), которые она планирует использовать следующим образом.
- Инструменты менеджмента риска:
- анализ древа неисправностей в программном обеспечении;
- план менеджмента риска;
- идентификация мер по управлению риском в рамках производственного
или бизнес-процесса;
- анализ отказа программного обеспечения (анализ риска).
Затем Мэри размышляет о том, как она обеспечит уверенность в программном обеспечении на этапах проектирования, разработки и компоновки (настройки конфигурации) программного обеспечения. Она уже решила следовать МЭК 62304:2006 (включая Изм. 1:2015) для управления жизненным циклом. Теперь она идентифицирует другие конкретные инструменты, которые будут использованы для обеспечения корректной разработки программного обеспечения на этапах его проектирования, разработки и компоновки (настройки конфигурации).
- Инструменты проектирования, разработки и конфигурации:
- МЭК 62304:2006 (включая Изм. 1:2015) Анализ документации и
архитектуры;
- проектные спецификации программного обеспечения;
- детальное проектирование и анализ программного обеспечения;
- стандарты написания кода программного обеспечения;
- матрица прослеживаемости;
- идентификация мер по управлению риском в рамках разработки
программного обеспечения системы;
- анализ и верификация кода;
- анализ проектирования и разработки.
Мэри не сомневается, что ей придется тщательно протестировать новую разрабатываемую систему. Во-первых, она решает наряду с обычным модульным тестированием, интеграционным тестированием и тестированием интерфейсов предусмотреть еще и формальную деятельность по планированию проведения испытаний. Однако, поскольку эта система будет выпускать готовые изделия в режиме реального времени, она решает расширить границы тестирования системы посредством добавления тестирования устойчивости, тестирования производительности и более обширное тестирование набором входных данных с целью моделирования как можно больших вариантов реальных условий работы.
- Инструменты испытаний (тестирования):
- планирование проведения испытаний (тестирования);
- модульное тестирование (юнит-тесты);
- интеграционное тестирование;
- тестирование программных интерфейсов;
- регрессионное тестирование (при необходимости);
- системное тестирование;
- тестирование устойчивости (стресс-тесты);
- тестирование набором входных данных;
- тестирование производительности.
Мэри знает, что ее работа с системой не будет завершена до полной реализации системы в реальной производственной среде. Поэтому она обращает свое внимание на планирование деятельности по валидации на этапе развертывания. Она хочет быть уверенной в том, что система надлежащим образом документирована и что пользователи хорошо обучены ее правильному использованию. Также она хочет быть уверенной в правильной установке системы. Таким образом, план валидации Мэри на этапе развертывания дополняется следующими пунктами:
- инструменты развертывания:
- анализ пользовательских процедур;
- внутреннее обучение;
- квалификация правильности установки (IQ);
- операционная квалификация (QQ);
- эксплуатационная квалификация (PQ);
- аттестация оператора.
Планирование обслуживания
Мэри внимательно относится к обслуживанию программного обеспечения из-за высокого остаточного риска. Она планирует несколько видов деятельности по обслуживанию для обеспечения качества программного обеспечения после развертывания системы, включая оценку результативности обучения пользователей, методы мониторинга системы, проверку правильности выходных данных системы и отчетность о несоответствиях. Она также проверяет и подтверждает, что калибровка и другая деятельность по обслуживанию оборудования происходят в дополнение к деятельности по обслуживанию программного обеспечения.
Деятельность по снятию с эксплуатации
Мэри испытывала трудности с выводом предыдущей системы из эксплуатации, так как сгенерированные этой системой данные должны были быть архивированы для сохранения записей истории изделия, а старый формат не был совместим с новым форматом данных. Новая система использует универсальный формат данных для обеспечения гибкости при переносе оставшихся от предыдущей системы данных в новую систему.
Пример 9: Система отчетности о несоответствующих
материалах - полное обновление системы
Корпорация Advanced Medical Specialities модернизирует программное обеспечение системы отчетности о несоответствующих материалах (NCMRS), которая является коммерческим программным пакетом. Advanced Medical решила не обновлять систему в прошлые разы, поэтому теперь она отстает на две версии. (Advanced Medical в настоящее время работает под управлением версии 2, а последней версией является версия 4.) Advanced Medical требуется обновление для поддержания текущего соглашения о техническом обслуживании программного обеспечения. Версия 4 программного обеспечения NCMRS-Pro значительно изменилась по сравнению с предыдущими версиями. Помимо прочего, продукт был перенастроен с типичного клиент-серверного приложения на веб-приложение. Новое программное обеспечение также включает в себя значительные новые возможности и функции. Фрэнк, владелец бизнес-процессов и менеджер проектов в Advanced Medical, не имеет новых требований к существующему программному обеспечению и процессу, но он хочет воспользоваться новыми функциями программного обеспечения.
Фрэнк консультируется с группой по регулированию и решает, что нынешний интерфейс между системой ERP и NCMRS может оставаться как есть, без каких-либо модификаций. Фрэнк признает, что новая версия способна записывать данные обратно в систему ERP, а также что ее расширенный интерфейс должен быть тщательно проверен при валидации. Фрэнк и его коллеги, инженер по качеству производства и группа по регулированию, начинают работу по определению масштаба предполагаемых усилий по валидации. Эти сотрудники упоминаются как "команда" в остальной части этого примера.
Определение процесса
Фрэнк начинает с анализа существующего руководства по процессу с целью определения того, какие элементы рабочего процесса будут автоматизированы новым программным обеспечением. Новое программное обеспечение изменит следующие функции:
a) идентификацию потенциальных несоответствующих материалов или продукции (вне области валидации);
b) ввод информации, относящейся к материалу и обстоятельствам, связанным с его обнаружением (входит в область рассмотрения при валидации);
c) направление информации для обеспечения надлежащей идентификации, оценивания, исследования и размещения материала (входит в область рассмотрения при валидации);
d) распространение информации среди заинтересованных сторон и других компьютерных систем, которая необходима для надлежащей обработки финансовых, закупочных, плановых и календарных операций (входит в область рассмотрения при валидации);
e) физическое расположение материалов, хотя соответствующие данные о расположении будут записаны в системе (вне области валидации).
Анализ риска процесса
Фрэнк осознает, что этот процесс и поддерживающее программное обеспечение содержат в себе некоторый риск. Отказ процесса может иметь серьезные последствия, в том числе следующие:
- непреднамеренная поставка в производственную зону несоответствующих материалов;
- непреднамеренный выпуск в обращение несоответствующей продукции;
- увеличение стоимости производства из-за возросших отходов, переработки и тому подобного.
Фрэнк и группа по регулированию рассматривают, какие меры по управлению риском применяются для их снижения, включая следующие:
- средства управления в существующих процедурах по обнаружению, отделению, контролю и исправлению несоответствующих материалов;
- анализ менеджмента и качества данных по статистическому управлению процессами, а также других мер по идентификации развивающихся тенденций, которые могут сигнализировать о том, что процессы не находятся под надлежащим управлением;
- постоянное обучение операторов для обеспечения соблюдения процедур;
- финансовые отчеты, помогающие выявить использование материалов, которые приводят к нехарактерным проблемам с функционированием производственных процессов.
При наличии таких мер по управлению риском только множественные одновременные отказы системы могут привести к неспособности надлежащим образом управлять несоответствующей продукцией или материалами. Однако, учитывая потенциальное влияние последствий таких отказов на качество, соответствие регулирующим требованиям и финансовые показатели, Фрэнк приходит к заключению, что остаточный риск процесса потребует осуществления достаточно строгой деятельности по укреплению доверия, направленной на обеспечение правильного функционирования программного обеспечения и его соответствия предусмотренному применению.
Определение цели и назначения программного обеспечения
Фрэнк хочет иметь подробное представление о том, как обновление программного обеспечения повлияет на его пользователей и его организацию. Фрэнк приходит к выводу, что программное обеспечение по существу является автоматизированным инструментом отслеживания и управления проблемами. Производственный персонал, работающий со стандартными инструментами, оборудованием и прочими инструментами, несет ответственность за идентификацию и изоляцию потенциально несоответствующей продукции и материалов. Как только проблема исследована, сведения о ситуации вводятся в программное обеспечение. Затем программное обеспечение управляет рабочим процессом, назначениями и уведомлениями для решения проблемы и документирует ту или иную деятельность, необходимую для обработки и размещения продукции и материалов. Обновление программного обеспечения должно упростить процесс, сделав его более эффективным, и предоставить группе по обеспечению качества более мощные инструменты для анализа данных и тенденций, а также обеспечить большую наглядность проблем в области качества. Фрэнк понимает, что необходимые для обновления изменения процесса в первую очередь коснутся самого рабочего процесса и процесса распространения информации. Программное обеспечение само по себе не принимает окончательных решений и не определяет какие-либо результаты независимо, но хранит и документирует решения, принятые людьми, взаимодействующими с системой.
Фрэнк устанавливает, что программное обеспечение автоматизирует аспекты рабочего процесса управления несоответствиями. Группой по регулированию было документировано следующее заявление о цели и назначении программного обеспечения.
- Программное обеспечение NCMRS предназначено для поддержки процесса управления несоответствующей продукцией и материалами. Система используется для документирования шагов процесса, которые установлены в соответствующих стандартных операционных процедурах, и для ведения записей, фиксирующих выполненные шаги процесса, время их выполнения и выполняющий их персонал, а также результат каждого шага. Система предоставляет данные для мониторинга деятельности в области качества и улучшения.
Определение границ взаимодействия программного обеспечения с другими системами
Программное обеспечение NCMRS имеет два интерфейса, включая один основной интерфейс с ERP-системой и один вторичный интерфейс с системой управления персоналом (HR) компании. Основной интерфейс представляет собой пакетный процесс и разработан для планомерного обновления системы два раза в день данными о готовой продукции, продукции в процессе производства, ведомости материалов и ведомости операций. Интерфейс также будет поставлять данные для отчета о несоответствующих материалах (NCMR) обратно в ERP с данными о качестве хранения, расположении материалов и другой транзакционной информацией. Вторичный интерфейс однонаправлен от системы HR и предназначен для обновления данных о сотрудниках NCMR для целей планирования и назначения.
Первоначальное планирование валидации
Фрэнк приобрел дополнительную уверенность в том, что функционирование процесса и программного обеспечения NCMR адекватно понято и должным образом документировано. Теперь он готов разработать первоначальный план валидации. Дополнительные детали будут разработаны в процессе планирования.
Группа по регулированию определяет документы, которые будут иметь наибольшую ценность и надлежащим образом конкретизируют, что должно делать программное обеспечение. На эти документы будут ссылаться как на "требования", однако они не будут являться типичным набором требований пользователя как таковых. Вместо этого документы будут представлять собой серию подробных описаний того, как программное обеспечение должно функционировать. Таким образом, анализ автоматизированного и ручного тестирования будет более качественным и удобным для проверки и оценки результатов. Вместо рассмотрения отдельных тестов для определения выполнения конкретных требований пользователей, проводимый анализ будет совокупно рассматривать как предусмотренное функционирование, так и сами результаты функционирования системы.
Набор документов будет включать следующее:
a) документирование рабочих процессов и бизнес-правил. Эту область программного обеспечения можно конфигурировать, поэтому команда запланирует подготовку необходимого набора конфигураций и разработает подробные технологические потоки и логические диаграммы, описывающие операцию;
b) документирование интерфейса. Данные документы будут описывать, какие элементы данных перемещать из систем ERP и HR в NCMRS, какие элементы данных перемещать из NCMRS в систему ERP и когда именно перемещать данные элементы;
c) документация по миграции данных. Этот набор документов будет описывать, какие архивные данные будут перемещены в обновленную систему.
План валидации будет включать результаты анализа и официального одобрения каждого из этих документов. Официальное одобрение потребуется от группы по обеспечению качества, от инженерно-производственного отдела и группы информационных систем. Из-за критической значимости и риска системы все члены высшего руководства должны провести окончательное официальное одобрение отчета по валидации.
Определение требований к использованию программного обеспечения
Фрэнк и члены команды приступают к формированию набора указанной выше документации, ссылаясь при этом на документацию по системе, предоставленную поставщиком, и предыдущую документацию по существующим интерфейсам.
Установление деятельности по укреплению доверия и управлению программным обеспечением
У Фрэнка уже был положительный опыт работы с этим программным обеспечением и этим поставщиком. Теперь Фрэнк определяет следующие пять основных направлений, по которым команда будет прилагать усилия с целью укрепления доверия к программному обеспечению:
a) в соответствии с внутренними политиками и процедурами Advanced Medical поставщик имеет в компании статус официально одобренного поставщика. Предыдущие аудиты показали, что поставщик имеет адекватные систему качества и жизненный цикл продукции (SDLC). Поставщик выпускает коммерчески доступное программное обеспечение, имеющее устоявшуюся историю в регулируемой отрасли, которое имеет предназначенное применение, аналогичное предусмотренному применению Advanced Medical. Поставщик будет периодически подвергаться аудиту для поддержания статуса официально одобренного поставщика;
b) Advanced Medical будет использовать поставляемый поставщиком инструмент автоматизированного тестирования для верификации правильности установки программного обеспечения и его функционирования в рамках комплекта тестов. Этот инструмент может обрабатывать более 8000 различных транзакций за несколько часов. Однако инструмент не проверяет некоторые параметры конфигурации, которые компания планирует включить;
c) команда подготовит дополнительный план испытаний, который включает параллельную обработку статистически значимой выборки фактических отчетов о несоответствиях на бумажном носителе. Результаты будут проанализированы для обеспечения точности, целостности данных и соблюдения процедур;
d) команда будет верифицировать преобразование данных и перенос существующих системных записей с помощью метода выборки, обеспечивающего сохранение целостности архивных записей. Количество записей будет использоваться для верификации 100% преобразований данных;
e) интерфейсы данных будут верифицированы с использованием метода выборки для измерения полноты и точности передачи данных.
Анализ рисков отказа программного обеспечения
С целью установления необходимой степени строгости валидации Фрэнк использует настоящий документ как ссылочный. Отказы программного обеспечения могут привести к неправильной обработке электронных записей, а также к их потере или повреждению. Снижение рисков находится под управлением внутренней системы качества поставщика, установочной квалификации программного обеспечения (инструмент автоматизированного тестирования), а также дополнительными проверками и тестированием вариантов использования. Вследствие наличия управления процессами на последующих этапах, остаточный риск этой системы считается настолько низким, насколько это практически возможно.
Завершение планирования валидации
Проведенный анализ предписывает применение довольно строгой методологии валидации. Применяемая методология в разумной степени обеспечивает, что программное обеспечение будет функционировать в соответствии с предусмотренным применением. Члены команды приходят к выводу, что они надлежащим образом определили требования системы, приняли решение о подходе к имплементации, проанализировали риск программного обеспечения и получили достаточно информации для создания детального плана валидации.
Основная часть тестирования будет выполнена с использованием набора автоматизированных тестов, который команда уже рассмотрела и установила его пригодность в отношении цели и назначения программного обеспечения. Дополнительное вспомогательное тестирование будет проводиться на основе реальных вариантов использования, составленных в производственном подразделении. Целью этих тестов является: а) проверка того, что процесс функционирует так, как предназначено, б) снижение временных затрат на принятие системы пользователями и их обучение и в) верификация того, что изменения конфигурации не оказали отрицательного влияния на программное обеспечение. Дополнительное тестирование не предназначено для замещения внутренней системы тестирования поставщика, которое ранее было верифицировано посредством проведения аудита. Успешное завершение автоматизированного тестирования позволит установить, что программное обеспечение установлено правильно и является функционально приемлемым.
Команда выбирает следующие инструменты из настоящего документа, чтобы выполнить оставшиеся действия по установке, конфигурации, тестированию, верификации и валидации.
- Инструменты проектирования, разработки и конфигурации:
- анализ документированной архитектуры;
- идентификация мер по управлению риском при проектировании
программных систем;
- анализ предлагаемой конфигурации;
- анализ списка "известных проблем" поставщика;
- анализ документации по валидации базовой системы поставщика;
- анализ схем рабочих процессов стандартного программного
обеспечения "в установочной конфигурации";
- анализ стандартной библиотеки отчетов "в установочной
конфигурации";
- анализ пробелов в изменениях конфигурации стандартных рабочих
процессов и рабочих правил.
- Инструменты тестирования:
- планирование тестирования;
- описание и результаты поставляемого поставщиком средства
автоматизированного тестирования для верификации и квалификации
установки;
- тестирование установки и производительности (часть набора
автоматизированных тестов);
- тестирование сценариев использования на основе реальных записей
несоответствий в качестве входных данных, а не искусственно созданных
тестовых сценариев;
- план выборки для верификации перенесенных данных;
- проверки системы для верификации рабочих интерфейсов.
- Средства развертывания:
- анализ пользовательских процедур;
- внутреннее обучение;
- аттестация оператора.
Планирование обслуживания
Фрэнк планирует использовать несколько мероприятий по техническому обслуживанию для обеспечения постоянного качества программного обеспечения после развертывания системы, включая оценку результативности обучения пользователей, методы мониторинга системы, периодический аудит результатов работы системы и отчетности о дефектах как внутри компании, так и у поставщика. Фрэнк договорился с поставщиком о том, чтобы уведомления об ошибках, выпуске обновлений и другие сообщения доводились до сведения соответствующих сотрудников, ответственных за обслуживание программного обеспечения в Advanced Medical.
Деятельность по снятию с эксплуатации
Фрэнк планирует сохранить текущую систему доступной после завершения эксплуатации, чтобы иметь возможность сравнить пропускную способность и результаты, из которых могут быть скомпилированы показатели производительности. После того как модернизированная система будет успешно функционировать в течение 6 месяцев, Фрэнк полностью снимет с эксплуатации предыдущую систему.
Пример 10: Программное обеспечение для планирования
заседаний комиссии по рассмотрению отчетности
о несоответствующих материалах (NCMR)
Компания со штатом в 1000 сотрудников решает опробовать новое программное решение, которое поможет компании в электронном виде планировать совещания для проведения обязательного анализа NCMR. Проектная группа, назначенная для реализации автоматизации, изучает недавно выпущенное на рынок коммерческое программное обеспечение. Поставщик утверждает, что программное обеспечение может планировать совещания посредством использования данных, полученных через другие компьютерные системные интерфейсы. Проектная группа решает, что это программное обеспечение может быть полезным для планирования заседаний комиссии по рассмотрению NCMR, если программное обеспечение будет способно собирать данные NCMR из валидированной NCMR-системы базы данных компании.
Определение процесса
Команда собирается для обсуждения процесса планирования совещаний комиссии по анализу NCMR и рассматривает процедуры обработки NCMR компании. Обсуждение приводит к следующему определенному процессу:
a) как только несоответствие идентифицировано, соответствующий материал маркируется, изолируется и регистрируется в валидированной базе данных NCMR;
b) проводятся еженедельные совещания по анализу результатов всех расследований, связанных с несоответствиями и рекомендуемыми действиями по дальнейшему обращению;
c) для каждого совещания определяется перечень подготовленных к анализу несоответствий NCMR, а также лица, которые должны присутствовать, представлять результаты и участвовать в действиях по одобрению и дальнейшему обращению;
d) за день до совещания комиссии по анализу NCMR ее участникам направляется уведомление о заседании. Данное уведомление включает перечень NCMR для обсуждения.
Анализ риска процесса
Посредством мозгового штурма члены команды оценивают потенциальный вред, который может быть причинен вследствие возможных отказов процесса:
- уведомление о совещании не отправлено;
- уведомление о совещании отправлено не вовремя;
- к участию приглашены не те лица;
- перечень NCMR для анализа составлен некорректно.
Группа отмечает, что выпущенная процедура обработки NCMR требует назначения конкретного лица в качестве менеджера по обработке NCMR. Это лицо отвечает за своевременную обработку всех NCMR и публикацию показателей процесса NCMR на основе данных, содержащихся в валидированной базе данных NCMR. Во всех выявленных группой случаях негативным результатом использования программного обеспечения для планирования совещаний является нарушение эффективности проведения совещаний комиссии по NCMR. Это нарушение накладывает дополнительную временную нагрузку на менеджера по обработке NCMR. Таким образом, риск отказа процесса анализа определяется как низкий с точки зрения риска нарушения регулирующих требований, риска для окружающей среды и риска причинения вреда людям.
Определение предусмотренного применения
Команда определяет цель и назначение применения программного обеспечения, применимые регулирующие требования и разграничения следующим образом.
- Использование программного обеспечения:
- "кто?" - программное обеспечение в первую очередь будет
использоваться менеджером по процессу обработки NCMR;
- "что?" - программное обеспечение автоматически разошлет
электронные приглашения на совещание лицам, которые идентифицированы
как его участники на этой неделе;
- "когда?" - программное обеспечение будет использоваться, когда
необходимо запланировать совещания по анализу NCMR;
- "куда?" - поскольку все участники являются локальными,
программное обеспечение должно использоваться только в локальной сети
(LAN);
- "каким образом?" - программное обеспечение извлекает перечень
NCMR, которые открыты и нуждаются в рассмотрении комиссии по анализу
NCMR. Менеджер по обработке NCMR идентифицирует те NCMR, которые будут
рассмотрены на следующем совещании. Затем программное обеспечение
использует таблицу, настроенную менеджером по обработке NCMR, с целью
идентификации круга лиц, которые должны присутствовать на данном
совещании. Дата предстоящего совещания устанавливается менеджером по
обработке NCMR. За один день до совещания программное обеспечение
отправляет электронное приглашение соответствующим участникам;
- "для чего?" - программное обеспечение будет использоваться для
улучшения своевременного уведомления соответствующих лиц для участия в
еженедельных совещаниях комиссии по анализу NCMR.
- Границы взаимодействия:
- данное программное обеспечение взаимодействует с базой данных
NCMR и графическим интерфейсом пользователя.
- Применимые регулирующие требования:
- программное обеспечение не хранит информацию, используемую для
подтверждения соответствия каким-либо регулирующим требованиям. Вся
информация по записям истории изделия, связанная с NCMR или обработкой
NCMR, записывается либо на бумажном носителе, либо в валидированной
базе данных NCMR.
После создания и анализа данного определения о целях и назначении применения команда устанавливает, что предлагаемое программное обеспечение не автоматизирует деятельность, которая является обязательной для выполнения регулирующих требований и не создает записи по качеству, требуемые существующим регулированием. Хотя оно используется для обеспечения большего удобства проведения совещаний, которые являются частью деятельности, требуемой регулирующими органами (процесс NCMR), само программное обеспечение не автоматизирует требуемую деятельность. В результате группа документирует вышеуказанное предусмотренное применение и четко указывает, что формальная валидация не требуется. Однако команда также признает, что даже небольшое изменение в использовании на стадии обслуживания может существенно повлиять на первоначальное решение команды о необходимости валидации. Например, если программное обеспечение используется для хранения протоколов совещаний или для составления списка присутствовавших на нем лиц для их рассмотрения регулирующим органом, это повлияет на первоначальное решение о необходимости валидации. Поэтому команда обновляет свои процедуры системы качества, чтобы установить требование по оцениванию предусмотренного применения на периодической основе или в результате изменений связанных процессов.
Использование инструментов
Были использованы следующие инструменты.
- Стадия разработки - определения:
- определение требований к процессу;
- анализ риска отказа процесса;
- определение предусмотренного применения.
- Стадия обслуживания:
- планирование обслуживания.
Обсуждение
В результате определения конкретного использования и границ деятельности, автоматизированной данным программным обеспечением, команда может обоснованно заявить, что программное обеспечение не соответствует определению программного обеспечения, используемого в рамках систем качества медицинских изделий и, следовательно, программное обеспечение не нуждается в валидации. При идентификации такого программного обеспечения следует проявлять большую осторожность для обеспечения того, что фактическое использование программного обеспечения полностью охватывается определением предусмотренного применения. Также важно понимать, что предусмотренное применение может легко измениться на стадии обслуживания даже без изменений в самом программном обеспечении. Поэтому планирование технического обслуживания является важной частью обеспечения надлежащего управления программным обеспечением, используемым компанией.
Пример 11: Система управления перечнем
одобренных поставщиков
Корпорация Acme является изготовителем медицинских изделий класса B. Корпорация использует процедуру для ведения перечня официально одобренных поставщиков (AVL), которая выполняется вручную. Корпорация Acme хочет разработать систему AVL для автоматизации процесса проверки, что поставщик официально одобрен для поставки конкретной детали.
- Джек, менеджер проекта компании Acme для новой системы AVL, определяет рассматриваемый процесс AVL как процесс системы качества медицинских изделий, связанный с управлением закупками в ИСО 13485.
Таким образом, предлагаемая система AVL подпадает под требования по валидации применения программного обеспечения.
Определение процесса
Для лучшего понимания требований и рисков, обусловленных разработкой системы AVL, Джек определяет связанные бизнес-процессы следующим образом:
a) когда инженерная группа хочет одобрить нового поставщика, образцы деталей поставщика направляются в группу качества для квалификационной проверки;
b) после квалификации деталей поставщика группа качества направляет группе закупок электронное письмо, разрешающее ввод наименования поставщика, а также утвержденных номеров деталей и описаний в перечень одобренных вендор-поставщиков (AVL). Этот перечень ведется и поддерживается в бумажном виде в группе закупок. Инспекционная группа по приемке имеет доступ к AVL;
c) группа закупок вручную выполняет проверку, направленную на обеспечение правильного ввода наименования поставщика в AVL;
d) когда группа закупок заказывает детали, то она сверяется с AVL для обеспечения того, что поставщик одобрен и уполномочен поставлять запрошенные детали;
e) если поставщик одобрен, группа закупок подписывает заявку с указанием проведенной проверки в системе AVL.
Анализ риска процесса
Джек рассуждает, что может пойти не так в существующем в настоящее время процессе. Если процесс нарушится, то детали могут быть заказаны у неодобренного поставщика. Такое может произойти либо потому, что неодобренный поставщик был добавлен в AVL, либо потому, что группа закупок не проверяет AVL перед заказом деталей.
Затем Джек рассматривает существующие меры по управлению риском для смягчения таких рисков. Джек видит, что группа закупок имеет процедуру проверки вручную того, что наименования поставщиков были правильно добавлены в AVL, а доступ к перечню разрешен только для авторизованных сотрудников. Кроме того, Джек видит, что текущая процедура закупки требует подписи сотрудника группы закупок о проведении проверки нахождения поставщика в AVL до выдачи заказа на покупку. Контроль, обеспечивающий размещение заказов у одобренных поставщиков, осуществляется в инспекционной группе по приемке, где AVL снова проверяется при получении деталей.
На основании анализа этих мер по управлению риском Джек устанавливает, что остаточный риск процесса является низким. Поэтому он предполагает, что новая система AVL, вероятней всего, будет системой с низким риском.
Определение предусмотренного применения
Теперь, когда Джек понимает, что бизнес-процесс должен быть автоматизирован, он составляет в письменном виде документ, содержащий формулировку цели и назначения для предлагаемой новой системы AVL:
- Система AVL автоматизирует проверку поставщиков и деталей по электронному перечню AVL с целью обеспечения того, что детали заказываются только у официально одобренных поставщиков. В новой системе будет использоваться база данных AVL, которая будет связана с существующей системой заказов на закупку. Новая система будет использоваться группой качества корпорации Acme в штаб-квартире при осуществлении процесса квалификационной проверки поставщиков, а также агентами по закупкам в процессе формирования заказов на закупку.
Джек рассматривает другие системы и процессы, с которыми система AVL будет взаимодействовать, а также добавляет некоторые пояснения к составленному им документу для уточнения границ функционирования новой системы:
- Процесс закупок будет находиться во взаимодействии с процессом, автоматизируемым системой AVL. Интерфейс будет состоять из запроса к базе данных AVL о статусе поставщика, указанного в заказе на закупку. Процесс закупок не подтверждает точность данных в AVL и не взаимодействует с процессом оценки поставщика.
Планирование валидации
Теперь, когда Джек осознает, что бизнес-процесс должен быть автоматизирован, цель и назначение новой системы установлены, то можно приступать к разработке первоначального плана валидации. Более подробно он решает изложить этот план несколько позже, однако, с целью определения масштаба необходимой деятельности и усилий по валидации, он хочет начать планирование валидации сейчас.
Ранее Джек определил остаточный риск в существующем процессе AVL как низкий. Поэтому он считает, что в целях валидации ему не нужно поддерживать высокий уровень формализации и детализации масштаба прилагаемых усилий. Он знает, что важно определить требования к бизнес-процессам пользователей и требования к программному обеспечению для новой системы. Но поскольку система имеет низкий риск, Джеку не нужно иметь отдельные документы с отдельными подписями на каждом документе. Он решает объединить требования к бизнес-процессам пользователей, требования к программному обеспечению и план проведения испытаний в один документ, используя формат таблицы.
Поскольку рассматриваемая система имеет весьма низкий риск, Джек обоснованно устанавливает, что отсутствует необходимость в проведении тщательного управленческого анализа планируемого масштаба усилий по валидации. Он решает, что официального одобрения менеджером по работе с поставщиками и представителем руководства по обеспечению качества будет вполне достаточно. Но Джек также считает, что для обеспечения уверенности в правильности определения требований пользователя он должен заручиться отзывом представителя группы закупок.
Джек начинает составлять проект своего плана валидации в соответствии с принятыми решениями. Корпорация Acme использует стандартный формат, которому должны соответствовать все планы валидации. Некоторые разделы плана валидации еще не определены, однако Джек дополнит план после одобрения первоначального проекта системы.
Определение требований к программному обеспечению
Далее Джек в письменном виде составляет требования к программному обеспечению. Он решает, что требования к программному обеспечению должны включать "что" (действия, требуемые процессом или системой AVL), спецификацию интерфейса, устанавливающего взаимодействие системы AVL с системой закупок, словарь данных и примеры допустимых запросов, которые новая система должна быть в состоянии обработать.
Определение границ взаимодействия программного обеспечения с другими системами
Затем Джек рассматривает другие системы, с которыми новая система AVL должна будет взаимодействовать. Он устанавливает, что единственное взаимодействие будет происходить с существующей системой закупок Acme, которая может запрашивать базу данных AVL с помощью простых запросов на языке SQL.
Установление деятельности по обеспечению уверенности и управлению программным обеспечением
Далее Джек должен решить, какой подход и какие технологии он должен использовать для создания новой системы. Поскольку бизнес-требования достаточно просты, то и объем транзакций будет низким. Так как система AVL является системой с низким риском, Джек решает разработать ее с помощью широко доступной и простой в использовании системы баз данных Microsoft Access. (Microsoft Access упоминается только в качестве примера подходящего и широко доступного продукта. Эта информация приведена для удобства пользователей настоящего документа и не является одобрением ИСО этого продукта.)
Поскольку Microsoft является сторонним разработчиком программного обеспечения, Джек должен решить, какие виды деятельности по установлению доверия к Microsoft Access он должен выполнить. Джек отмечает, что Microsoft Access является широко используемым инструментом и что в прошлом любые проблемы или нюансы, связанные с данным продуктом, были быстро выявлены и опубликованы на форумах в Интернете. В сочетании с тем, что система AVL является системой с низким уровнем риска, Джек решает не предусматривать проведение аудита поставщика в отношении Microsoft как разработчика базы данных.
Поскольку новая система содержит электронные записи, Джек решает внедрить стороннее программное обеспечение как "обертку" для Microsoft Access в качестве необходимого средства управления в отношении обеспечения достоверности записей.
Анализ риска отказа программного обеспечения
Хотя Джек уже установил, что автоматизируемый бизнес-процесс имеет низкий риск, ему все еще нужно проанализировать риск отказа программного обеспечения. Для этого он решает использовать количественную модель определения риска (со шкалой от 1 до 10). Ранжирование новой системы по уровням тяжести и вероятности он проводит следующим образом:
- Джек ранжирует "тяжесть" как среднюю (6), поскольку отказ программного обеспечения способен причинить вред лишь косвенно. Он обосновывает присвоенный ранг наличием средств управления на последующих этапах процесса;
- Джек ранжирует "вероятность" как низкую (1), поскольку конструкция базы данных довольно проста, что делает маловероятным необнаружение критических ошибок в процессе тестирования;
- сочетание результатов ранжирования определяет риск как низкий.
Поэтому Джек будет выполнять задачи валидации, исходя из низкого уровня риска.
Завершение плана валидации
Когда Джек определил требования к программному обеспечению, оценил риск и определился с подходом к имплементации программного обеспечения, то он теперь имеет достаточно информации для завершения плана валидации. В этот момент он делает шаг назад и в свете доступной информации о системе, подходе к имплементации и программном риске задает себе следующий вопрос: "Какая деятельность по валидации действительно дала бы мне уверенность в том, что эта система подходит для ее предусмотренного применения?"
Поскольку система является закупленным инструментом базы данных и имеет относительно низкий риск, Джек считает, что запланированная им деятельность по валидации достаточна, однако ему необходимо учесть требования окружающей среды с целью обеспечения должного управления изменениями в операционной системе и версии Access. Он обновляет план валидации, дополняя его требованием официального управления конфигурацией программного обеспечения.
Поскольку система разрабатывается третьей стороной, Джек должен быть уверен, что разработчик правильно интерпретирует требования к настройке, входным данным, интерфейсам, хранению данных и выходным данным. Так как данная система будет зависеть от входных данных от существующих систем, то для подтверждения правильности работы разработчика Джек добавляет интерфейсный и интеграционный тесты системы в качестве важной деятельности в план валидации.
Наконец, Джек хочет убедиться, что разработчик во время разработки поддерживает надлежащее управление версиями, поэтому он добавляет управление версиями программного обеспечения в качестве необходимой деятельности в свой план валидации.
Обобщая и используя принцип критического мышления, Джек добавляет следующие инструменты к остальной части деятельности по разработке и масштабу усилий по валидации.
- Средства проектирования, разработки и конфигурации:
- анализ документирования архитектуры программного обеспечения;
- матрица прослеживаемости (интегрированная в спецификацию
требований);
- меры по управлению риском (документировано в пользовательской
спецификации).
- Средства тестирования:
- интеграционное тестирование (документировано в спецификации
требований);
- тестирование интерфейса (документировано в спецификации
требований);
- системное тестирование (документировано в спецификации
требований).
- Средства развертывания:
- анализ пользовательских процедур;
- внутреннее обучение работы с приложением;
- установочная квалификация.
Планирование поддержки
Джек заранее продумывает, какая деятельность может быть уместна для обеспечения качества программного обеспечения после развертывания системы. Учитывая низкий остаточный риск системы, Джек решает, что следует проводить ежеквартальный обзор точности данных AVL в базе данных. Джек включает в свой план валидации раздел для документирования ежеквартального обзора и составляет запрос на разработку и внедрение процедуры, обеспечивающей проведение ежеквартального обзора после запуска системы.
Пример 12: Программное обеспечение управления калибровкой
Медицинская компания XYZ быстро растет. XYZ приобретает компании в Европе и Азии. Рост компании означает, что потребности в управлении калибровкой в XYZ также растут. В настоящее время менеджер по калибровке XYZ ведет журнал учета всей информации по калибровке и еженедельно проводит анализ реестра откалиброванного оборудования с целью определения потребности в повторной калибровке какого-либо оборудования. По мере роста компании этот реестр становится слишком большим и территориально рассредоточенным, чтобы один человек мог управлять им с помощью системы отображения данных на бумажном носителе. Настало время внедрить компьютеризированную систему.
Определение процесса
XYZ имеет стандартную операционную процедуру (SOP), требующую, чтобы компьютеризированные системы, автоматизирующие часть системы качества, были валидированы для их предусмотренного применения. XYZ сначала определяет процесс управления калибровкой для выявления связанных с процессом рисков и установления того, будет ли программное решение автоматизировать весь текущий процесс или только его часть. Менеджеры XYZ анализируют стандартную операционную процедуру (SOP) управления калибровкой, которая содержит подробные сведения о следующих этапах процесса:
a) закупается новое оборудование;
b) новому оборудованию присваивается уникальный идентификационный номер (ID);
c) устанавливается процедура калибровки;
d) новое оборудование калибруется;
e) статус калибровки указывается на оборудовании посредством маркировки;
f) поддерживаются записи калибровки, включающие требования к калибровке, статус и дату истечения срока действия;
g) записи по калибровке рассматриваются с точки зрения адекватности отчетности и деятельности по управлению калибровкой.
Анализ риска процесса
Процесс управления калибровкой содержит некоторые присущие ему риски независимо от того, является ли он системой с отображением данных на бумажном или электронном носителе. Связанные с этим процессом риски заключаются в следующем:
- при использовании оборудования после истечения срока его калибровки, регистрируются некорректные измерения. Эта проблема может иметь ряд последствий в зависимости от вида оборудования и стадии процесса, в котором оно используется;
- размещенная на оборудовании некорректная маркировка может указывать на то, что оборудование откалибровано, хотя уже истек срок его калибровки. Эта ошибка также имеет ряд последствий в зависимости от вида оборудования и стадии процесса;
- записи калибровки могут быть утеряны, что может повлечь появление некоторого оборудования с истекшим сроком калибровки. Эта проблема может задержать работу;
- если статус калибровки записан некорректно, то может возникнуть ситуация использования оборудования с истекшим сроком калибровки;
- если две единицы оборудования получают один и тот же идентификационный номер, записи не будут уникальными.
Установлено, что данный процесс сопряжен с высоким риском из-за возможных последствий неправильной калибровки. В худшем случае для измерений при окончательной приемке медицинского изделия может быть использовано оборудование, не прошедшее калибровку, в результате чего ему может быть неправомерно присвоен статус соответствующего изделия.
Чтобы устранить эту проблему, менеджеры XYZ должны обновить стандартную операционную процедуру (SOP), чтобы включить инструкции для каждого пользователя оборудования. Каждый пользователь должен перед использованием проверить маркировку окончания срока калибровки на оборудовании. При составлении протоколов, в которых задействовано калиброванное оборудование, каждый пользователь должен записать в него идентификационный номер оборудования и дату его калибровки. Также пользователи должны быть обучены тому, как идентифицировать элементы, которые должны быть откалиброваны, и научены не использовать оборудование с истекшим сроком или без маркировки.
Реализация таких мер позволяет снизить остаточный риск системы до умеренного уровня. Менеджеры XYZ считают, что инструкция пользователя является подходящей, но недостаточно результативной мерой по снижению остаточного риска до минимального.
Определение предусмотренного применения программного обеспечения
Программная система не будет выполнять деятельность по калибровке; она будет представлять собой базу данных, содержащую информацию о калибровке и данные об оборудовании, истории его калибровки и текущем статусе. Программная система будет управлять этапами b), f) и g) процесса калибровки.
Менеджеры XYZ соглашаются, что XYZ будет валидировать систему для следующих целей и назначений.
- Система управления калибровкой используется для предоставления идентификационных номеров требующего калибровки оборудования, печати маркировочных ярлыков для калибруемого оборудования, хранения данных о результатах калибровки и составления отчета о статусе калибровки оборудования. Система управления калибровкой автоматизирует выполнение части требований ИСО 13485, касающихся оборудования для контроля, измерения и испытаний.
Планирование валидации
Чтобы основательно подготовиться к деятельности по валидации, руководители XYZ начинают ее планирование с установления ожидаемых результатов работы процесса калибровки и привлекают к процессу планирования межфункциональную группу. Они документируют следующие шаги:
- определение уровня строгости создаваемой документации для выбранных инструментов;
- строгость документации для системы будет умеренной. Таким образом, ключевые результаты будут формироваться и одобряться по отдельности;
- определение уровня наблюдения и одобрения (вовлечение в работу и анализ результатов команды менеджеров и межфункциональной группы) для выбранных инструментов;
- учитывая, что эта система управления калибровкой будет использоваться в глобальном масштабе, целесообразно выделить, в форме официального одобрения плана валидации и отчета о валидации системы, деятельность по менеджменту информационных технологий и управление операциями на глобальном уровне, которая должна проводиться в процессе валидации системы. Кроме того, к анализу и официальному одобрению всех документов будут привлечены менеджеры по оборудованию новых производственных участков;
- выбор "предопределенных" инструментов из набора инструментов:
- требования к пользовательским и бизнес-процессам;
- требования к программному обеспечению;
- формальный анализ требований к программному обеспечению.
Определение требований к программному обеспечению
Требования к программному обеспечению будут содержать следующие элементы:
- функциональные рабочие диаграммы процесса;
- требования к электронной записи и электронной подписи;
- требования к логической схеме данных;
- требования к отчетности;
- требования к печати маркировочных этикеток для оборудования;
- требования безопасности пользователей и их профилей;
- эксплуатационные требования;
- требования к пропускной способности.
Установление деятельности по обеспечению уверенности и управлению программным обеспечением
Менеджеры XYZ проводят опрос трех поставщиков данного типа продукции и устанавливают, что продукция одного из них наилучшим образом соответствует предусмотренному применению программного обеспечения в XYZ. Выпускаемая этим поставщиком система широко используется в медицинской промышленности, хотя рассматриваемая версия продукта является относительно новой. Некоторая уверенность может быть получена из записей, связанных с предыдущей версией программного обеспечения. Анализ уже известных дефектов будет проводиться на основе новых сообщений о проблемах. Тестированию новых функций, не входивших в ранее выпущенную версию, будет уделено особое внимание со стороны группы по разработке тестов.
Определение границ взаимодействия программного обеспечения с другими системами
Данное программное обеспечение не имеет интерфейсов с другими программными системами.
Анализ риска программного обеспечения
Группа по валидации встречается с глобальными менеджерами по калибровке и совместно использует вопросник, приведенный в таблице C.16, для определения риска программного обеспечения. Сначала они идентифицируют риски, а затем определяют для них меры по управлению риском. В завершение они оценивают допустимость остаточного риска (см. таблицу C.17).
Таблица C.16
Пример 12 - Анализ рисков
| Вопрос по идентификации рисков | Отметьте "да" или "нет". В случае отметки "да" выберите идентификатор риска (риск 1, риск 2, ... риск n) |
1.1 Безопасность продукции (вред) | Существует ли потенциальный риск для безопасности продукции в случае отказа программного обеспечения? Да, во всех случаях. Неоткалиброванное оборудование может быть ошибочно идентифицировано как калиброванное. - Вред для пациента - Да. Несоответствующая спецификации продукция может быть применена к пациенту, если для измерений было использовано неоткалиброванное оборудование. - Вред для оператора - Да. Если измерения температуры или мощности неверны, то оператор может пострадать или получить травму. - Вред для случайного лица, находящегося рядом - Да. Конкретный вред зависит от оборудования. - Вред для обслуживающего персонала - Да. Если измерения температуры или мощности неверны, то обслуживающий персонал может пострадать или получить травму. - Вред для окружающей среды - Да. Если давление измерено неправильно и резервуар содержит экологически вредные материалы, то возможна утечка | Риск 1 - используется неоткалиброванное оборудование |
1.2 Безопасность продукции (вред) | Существует ли потенциальный риск для безопасности продукции, если пользователь делает ошибку? Да, во всех случаях, если пользователь вводит неверные данные калибровки для единицы оборудования (см. 1.1). - Вред для пациента - Да. - Вред для оператора - Да. - Вред для случайного лица - Да. - Вред для обслуживающего персонала - Да. - Вред для окружающей среды - Да | См. риск 1 |
2.1 Качество продукции | Существует ли потенциальный риск для качества продукции (кроме риска безопасности), если программное обеспечение неисправно? Да. Продукция может не соответствовать спецификации, поскольку неоткалиброванное оборудование может быть ошибочно идентифицировано программным обеспечением как откалиброванное. Хотя неправильная идентификация не является проблемой безопасности, она может вызвать неудовлетворенность потребителя | См. риск 1 |
2.2 Качество продукции | Существует ли потенциальный риск для качества продукции (кроме риска безопасности), если пользователь делает ошибку? Да. Если пользователь вводит неверные данные калибровки для единицы оборудования и оборудование используется для измерения продукции, то продукт может не соответствовать спецификации. Хотя неправильная спецификация не является проблемой безопасности, она может вызвать неудовлетворенность потребителя |
|
3.1 Целостность записей | Существует ли потенциальный риск для целостности записи в системе, которая является хранилищем записей? Потеря записей - Да. Записи о калибровке могут быть утеряны. Повреждение записей - Да. Записи о калибровке могут быть повреждены | Риск 2 - записи о калибровке утеряны и вызывают проблему оценки соответствия. Риск 3 - записи о калибровке повреждены и вызывают проблему оценки соответствия |
4.1 Демонстрация соответствия стандарту ИСО | Существует ли потенциальный риск в отношении способности продемонстрировать соответствие регулирующим требованиям? Потеря записей - Да. Данные о калибровке могут быть утеряны. Повреждение записей - Да. Данные о калибровке могут быть повреждены | См. риски 2 и 3 |
Таблица C.17
Пример 12 - Оценивание и управление риском
Идентификатор риска | Описание | Тяжесть | Управление | Остаточный риск |
Риск 1 | Неоткалиброванное оборудование используется для измерения продукции или используется для измерения давления или мощности (риск возникает, так как программное обеспечение ошибочно идентифицирует оборудование или так как пользователь вводит неверные калибровочные данные для оборудования) | Высокая | Система предназначена для печати маркировочных этикеток, содержащих идентификационный номер оборудования, серийный номер, а также статус калибровки и срок действия. По процедуре, сотрудники обучаются проверять эту информацию перед использованием оборудования. Другой процесс требует, чтобы калибровочные данные были верифицированы вторым лицом перед их занесением в отчет по калибровке | Допустимый |
Риск 2 | Записи утеряны, и деятельность по управлению калибровкой не приводит к должному результату | Средняя | Группой по калибровке на бумажном носителе поддерживаются все записи в отношении калибровки | Допустимый |
Риск 3 | Записи повреждены, и деятельность по управлению калибровкой не приводит к должному результату | Средняя | Группой по калибровке на бумажном носителе поддерживаются все записи в отношении калибровки | Допустимый |
По завершении анализа риска менеджеры XYZ удовлетворены тем, что остаточный риск после снижения является допустимым.
Завершение плана валидации
С целью завершения планирования валидации менеджеры изменяют план таким образом, чтобы он содержал следующий набор инструментов.
- Инструменты имплементации:
- матрица прослеживаемости;
- анализ конфигурации системы.
- Инструменты тестирования:
- анализ величин измерения;
- планирование испытаний;
- поставляемый поставщиком комплект тестов с дополнительным
тестированием для запланированной конфигурации и нового функционала, не
входившего в предыдущую версию программного обеспечения.
- Средства развертывания (внедрения):
- внутреннее обучение по применению программного обеспечения;
- установочная квалификация (для сервера и рабочих станций).
Планирование обслуживания
В дополнение к планированию валидации системы менеджеры XYZ решают, что планирование обслуживания системы будет полезно, поскольку оно обязательно потребуется в будущем.
Будут внедрены методы мониторинга системы для анализа всех дефектов, анализа проблем использования системой и анализа изменений в предусмотренном применении.
С целью более эффективной реализации изменений будет разработан план классификации изменений в системе (т.е. аппаратное обеспечение, обновления, исправления, проблемы безопасности).
Пример 13: Система автоматизированного зрения
Инженеры в компании Гэри очень хороши в своей работе. Они знают, что продукция, которая производится в зоне автоматизации Гэри - металлический стержень, длина которого варьируется от 1,27 см до 3,81 см. Эти стержни имеют два применения: одно для размеров длиной 2,54 см или меньше, а другое для длины в 3,18 см (+/- 0,64 см). Все стержни имеют ширину 0,32 см. Оба применения предназначены для медицинских изделий и требуют, чтобы стержень был определенной длины. Гэри поручил инженеру по автоматизации проверить автоматизированную систему зрения, которая сортирует детали. Эта система заменяет ручной процесс измерения/сортировки. Других изменений в процессе нет, поэтому это полная область применения предстоящей валидации системы.
Описание процесса
Спецификация толщины стержня одинакова для обоих применений и отслеживается в сырье, используемом автоматом для резки стержней. Все критерии приемки подтверждаются на предыдущих производственных процессах, за исключением длины стержня, измеряемой автоматизированной системой зрения, за которую и отвечает Гэри.
Машинный процесс довольно прост. Стержни загружаются в приемник, который использует воронку для размещения стержней на конвейерной ленте, по одному за раз. Каждый стержень транспортируется к месту остановки, где камера смотрит на стержень и измеряет его длину. В зависимости от результата, стержни перемещаются в два контейнера: один для стержней длиной 2,54 см или меньше и другой для более длинных стержней.
Далее в процессе нет никаких дополнительных проверок длины стержней. Существует повышенный риск причинения вреда пациенту, если используется стержень неправильного размера, потому что такой стержень может привести к утечкам в изготавливаемых изделиях. Далее в процессе не предусмотрено никакого метода проверки для снижения этого повышенного риска. Если стержень правильной длины и в пределах установленных размеров, то утечки в изделии не произойдет. Изделия изготавливаются в течение многих лет, и рассматриваемый риск хорошо понятен. Автоматизированная система зрения заменяет ручной процесс измерения.
Определение предусмотренного применения
Поскольку Гэри хорошо разбирается в подлежащем автоматизации процессе, он начинает с определения его цели и назначения.
- Программное обеспечение предназначено для подтверждения факта нахождения на конвейере только одного металлического прута, а также для измерения его длины.
Анализ риска
Гэри использует внутренний процесс анализа риска и устанавливает, что риск последствий отказа для системы высокий, потому что нет никакого способа обнаружить несоответствующий размер стержня, кроме как через последующий отказ продукции или посредством разрушающих испытаний. Последствия отказа могут причинить вред пациенту. Критическим параметром для процесса является точный размер длины стержней. Автоматизация не увеличивает и не уменьшает этот риск.
Планирование валидации
При разработке первой итерации плана валидации Гэри предполагает использовать строгий подход к процессу ее проведения (анализ риска определил риск на высоком уровне). После изучения потенциально подходящих инструментов валидации из набора инструментов он планирует формальный документ по определению требований и проведение анализа требований к программному обеспечению. В этот анализ требований к программному обеспечению будут вовлечены инженер-технолог, инженер по автоматизации и инженер по качеству.
Программное обеспечение для этой системы будет разработано собственными силами, но, учитывая предыдущую автоматизацию системы, предстоящая разработка будет относительно простой.
Меры по управлению риском
Идентифицированы две зоны рисков:
a) требуется подтверждение, что только один стержень находится в месте замера. Машина пропускает стержни через узкое отверстие, измеряя 0,64 см в ширину и 0,48 см в высоту. Исходя из этого, стержни могут попасть на конвейер только располагаясь вдоль и не пройдут, если один из стержней находится поверх другого, из-за размера отверстия. Однако две детали могут располагаться на конвейере рядом.
Чтобы уменьшить этот риск, программное обеспечение будет проверять ширину каждого стержня перед проверкой длины. Если ширина бруска превышает 0,32 см (+/- 0,08 см в соответствии с ранее проверенной спецификацией), то стержень отклоняется, поскольку на конвейере находятся два стержня. Для этой цели к конструкции машины добавляется третий контейнер (для брака);
b) стержни могут располагаться слишком близко друг к другу, затрудняя определение того, где именно заканчивается один стержень и начинается другой. Программное обеспечение будет направлять стержни в контейнер для брака, если их длина более 3,81 см.
Задачи валидации
Затем Гэри переходит к задачам валидации. Он определяет необходимость в составлении официальной проектной документации и планирует официальную инспекцию каждого раздела проекта с участием тех же членов команды, которые анализировали требования. Кроме того, как только код будет сгенерирован, он будет рассмотрен с точки зрения соответствия проектной документации другим инженером по автоматизации и инженером-технологом, которые имеют опыт разработки программного обеспечения. Деятельность по управлению поставщиками не выбирается, поскольку программное обеспечение разрабатывается внутри компании. Инженеру по автоматизации, инженеру-технологу и инженеру по качеству будет поручено провести анализ прослеживаемости программного обеспечения и проектной документации до требований. С целью обеспечения охвата всех требований они будут анализировать прослеживаемость только после проведения тестирования.
Выбор Гэри касательно набора инструментов раздела "Испытания (тестирование)" включает планирование проведения испытаний. Планы испытаний должны содержать сведения о программной среде применения и ожидаемых результатах тестирования. Гэри планирует несколько типов тестирования на различных этапах разработки, включая модульное тестирование, интеграционное тестирование и системное тестирование. Будут использованы позитивные и негативные тестовые сценарии, а также эксплуатационное тестирование, связанное со скоростью конвейерной ленты. Помимо Гэри, планы испытаний должны быть проанализированы и одобрены другим инженером по автоматизации, инженером-технологом, инженером по качеству. Отчет по результатам тестирования включает в себя: фактические результаты тестирования; их сравнение с ожидаемыми результатами тестирования; критерии соответствия или несоответствия результатов теста; идентификатор теста (его уникальный номер); документацию по разрешению проблем и регрессионному тестированию для любых отказов. Гэри необходимо официальное одобрение отчета по результатам тестирования от той же группы сотрудников.
Имплементация, тестирование и развертывание
Для развертывания системы автоматизированного зрения Гэри анализирует инструменты развертывания из набора инструментов и решает, что потребуется установочная квалификация. Кроме того, он устанавливает необходимость создания пользовательской процедуры и что для пользователей системы потребуется аттестация.
Обслуживание
Отдел Гэри коллективно планирует обслуживание всех систем в производственном подразделении. Никакого специального планирования действий в этой области не требуется.
Пример 14: Система захвата и размещения
Корпорация Hi-Quality Medical (далее - Hi-Quality) является изготовителем медицинских изделий класса B. Hi-Quality хочет автоматизировать размещение частично готовых деталей с одной станции в картриджи, которые являются частью медицинского изделия, производимого компанией.
Джилл, которая является менеджером проекта для новой системы захвата и размещения (ЗР), устанавливает, что процесс ЗР является процессом системы качества медицинского изделия в соответствии с ИСО 13485, поскольку он является частью производства медицинского изделия. Поэтому предлагаемая система ЗР будет подпадать под требования к валидации программного обеспечения.
Определение существующего процесса
Чтобы лучше понять требования и риски, связанные с разработкой системы ЗР, Джилл определяет соответствующий бизнес-процесс следующим образом:
a) детали, поступающие с участка сборки 11 в процессе производства, помещаются в картриджи для участка сборки 12 (из расчета 20 деталей на картридж). В настоящее время эта операция выполняется вручную оператором;
b) затем оператор вручную помещает картриджи на входную линию участка сборки 12;
c) оператор собственноручно проверяет правильность укладки деталей в картридж. [На выполнение шагов b) и c) для каждого картриджа требуется около 3 мин];
d) картридж переходит на другие участки сборки, которые включают визуальный осмотр, подтверждающий отсутствие деформаций на всех предыдущих этапах процесса.
Анализ риска процесса
Затем Джилл размышляет, что может пойти не так в текущем процессе. Ее анализ показывает, что могут произойти следующие события:
a) оператор может деформировать частично законченную деталь. Деформация будет обнаружена на дальнейших этапах инспекционной станцией;
b) оператор может неправильно поместить деталь в картридж или пропустить слот в картридже. Неправильное размещение или отсутствие гнезда в настоящее время обнаруживается на станции 12 во время ручного осмотра.
Учитывая эти меры по управлению риском, Джилл устанавливает, что остаточный риск процесса является низким. Она предполагает, что новая система ЗР также будет системой с низким уровнем риска.
Определение нового процесса
Оценив риск процесса и используя полученные знания о системе ЗР, Джилл определяет новый процесс следующим образом:
a) в систему ЗР будут загружаться картриджи;
b) система ЗР будет брать детали с участка сборки 11 и помещать их в картриджи (из расчета 20 деталей на картридж);
c) система ЗР будет визуально контролировать картридж для обеспечения правильности укладки и заполнения всех слотов картриджа. Любые несоответствующие картриджи будут автоматически отклонены;
d) система ЗР поместит прошедший приемку картридж на участок сборки 12. [Шаги b) - d) теперь займут 1 мин];
e) картридж направится на другие участки сборки, которые включают визуальный осмотр, подтверждающий отсутствие деформаций на всех предыдущих этапах процесса.
Определение предусмотренного применения программного обеспечения
Теперь Джилл лучше понимает причины автоматизации процесса и готова сформулировать в письменном виде цель и назначение предлагаемой новой системы ЗР:
- Система ЗР будет брать детали с участка сборки 11 и помещать их в картриджи. Она будет подтверждать правильность укладки и заполнения всех слотов картриджа, отклонять все несоответствующие картриджи и затем перемещать картридж на входную линию участка сборки 12 со скоростью один картридж в минуту.
Затем Джилл рассматривает возможное взаимодействие системы ЗР с другими системами. Она приходит к выводу, что других взаимодействий нет. Она устанавливает наличие взаимодействия с пользователями и отсутствие программных интерфейсов.
Планирование валидации
Проанализировав автоматизируемый бизнес-процесс и установив цели и назначение новой системы, Джилл готова разработать первый проект плана валидации. Позже ей нужно будет добавить больше деталей, однако, начав планирование валидации сейчас, она сможет определить уровень необходимых усилий по валидации.
Ранее Джилл установила низкий остаточный риск существующего процесса. Исходя из этого, она считает нецелесообразным установление высокого уровня детализации и формализации в процессе валидации. Джилл знает, что важно определить требования к бизнес-процессам пользователей и требования к программному обеспечению для новой системы. Однако она отмечает, что это система низкого риска и нет необходимости создавать отдельные документы с отдельными подписями на каждом документе. Поэтому Джилл решает объединить требования к бизнес-процессам пользователей, требования к программному обеспечению и план проведения испытаний в один документ.
Поскольку в новой системе такой низкий риск, Джилл решает, что тщательный анализ со стороны руководства по валидации не требуется и что будет достаточно одобрения со стороны руководителя производства и представителя службы по обеспечению качества. Однако с целью обеспечения правильности определения требований пользователя она добавляет проведение анализа оператором процесса.
Джилл начинает составление своего проекта плана валидации на основе стандартного формата плана валидации, установленного в корпорации Hi-Quality. Некоторые разделы плана валидации все еще не заполнены; Джилл заполнит их после официального одобрения первоначального проекта системы.
Определение требований к системе и программному обеспечению
Джилл обращается к рассмотрению требований к системе и требований к программному обеспечению. Она решает, что требования к программному обеспечению будут включать этапы процесса ЗР (или системные шаги) вместе с документированием интерфейса взаимодействия системы ЗР с участками сборки 11 и 12. Требования к системе включают скорость и точность движений системы ЗР. Для уменьшения риска причинения вреда Джилл добавляет требование безопасности по обеспечению физического барьера между оператором и захватывающим манипулятором ЗР.
Установление деятельности по обеспечению уверенности и управлению программным обеспечением
Теперь Джилл должна определиться с подходом и технологией, которые она должна использовать для закупки новой системы. Учитывая простоту бизнес-требований, цена будет низкой. Поскольку новая система имеет низкий риск, Джилл решает закупить систему ЗР у внешнего поставщика. Исходя из соотношения цены и качества, она решает закупить систему ЗР у Controlsys Inc., компании-лидера в области систем ЗР.
Controlsys является внешним поставщиком системы. Следовательно, теперь Джилл должна решить, какие виды деятельности она должна предпринять для достижения уверенности в Controlsys. Она оценивает имеющуюся у нее информацию об этой компании. Джилл отмечает, что Controlsys предлагает широко используемый продукт ЗР с отличной репутацией. Имевшиеся ранее проблемы и нюансы данного продукта были быстро выявлены самой компанией и опубликованы на форумах в Интернете. Обзор этой информации показывает, что существует только несколько известных незначительных проблем. Джилл проводит анализ и подтверждает, что эти проблемы не связаны со спецификой сформулированного ей предусмотренного применения программного обеспечения. Кроме того, Controlsys предлагает автоматизированный набор тестов для установочной, операционной и эксплуатационной квалификации (IQ/OQ/PQ). Учитывая историю компании и низкий уровень риска системы ЗР, Джилл решает не проводить аудит в компании Controlsys. Она официально одобряет компанию Controlsys как вендор-поставщика.
Анализ рисков отказа программного обеспечения
Несмотря на уже установленный Джилл низкий риск автоматизируемого бизнес-процесса, ей все еще необходимо провести анализ риска отказа программного обеспечения. Она решает использовать количественную модель определения риска и проводит ранжирование новой системы по уровням тяжести и вероятности следующим образом:
- Джилл ранжирует "тяжесть" как низкую (3) по шкале от 1 до 10, поскольку последствия отказа программного обеспечения будут обнаружены в последующей деятельности;
- она ранжирует "вероятность" как низкую (1), поскольку конструкция системы довольно проста, что делает маловероятным необнаружение критических ошибок в процессе тестирования;
- она определяет значение риска. Полученное значение равно 4, что классифицирует риск как низкий.
Поэтому Джилл будет выполнять задачи валидации, исходя из низкого уровня риска.
Завершение плана валидации
Поскольку Джилл уже завершила определение требований к программному обеспечению, оценила риск и определилась с подходом к исполнению программного обеспечения, то она теперь имеет достаточно информации для завершения плана валидации.
Так как предлагаемая система имеет низкий остаточный риск, Джилл выбирает следующие инструменты для оставшейся части усилий по разработке и валидации.
- Инструменты проектирования, разработки и компоновки (настройки конфигурации):
- анализ документирования архитектуры программного обеспечения;
- матрица прослеживаемости (интегрированная в спецификацию
требований);
- меры по управлению риском будут документированы в
пользовательской спецификации.
- Инструменты испытаний (тестирования):
- интеграционное тестирование (документировано в спецификации
требований);
- тестирование интерфейса (документировано в спецификации
требований);
- системное тестирование программного обеспечения (документировано
в спецификации требований).
- Инструменты развертывания:
- анализ пользовательских процедур;
- внутреннее обучение операторов;
- автоматизированный набор тестов, поставляемый поставщиком (от
Controlsys).
Планирование обслуживания
Теперь Джилл рассматривает уместную деятельность по обеспечению качества функционирования системы после ее развертывания. Из-за низкого остаточного риска системы она следует рекомендациям изготовителя и добавляет калибровку механизма движения в график калибровки. Джилл устанавливает для этой системы самый продолжительный валидационный цикл, принятый в компании (3 года).
Анализ выполненных действий на основе критического мышления
Наконец, Джилл спрашивает себя, рассмотрела ли она все элементы, необходимые для достижения уверенности в своем подходе к валидации. Она приходит к выводу, что выбранная и завершенная деятельность по валидации обеспечивает допустимый уровень уверенности в том, что программное обеспечение будет работать должным образом.
Подписаться на обновления