ГОСТ IEC 62304-2022. Межгосударственный стандарт. Изделия медицинские. Программное обеспечение. Процессы жизненного цикла
4* Общие требования
4.1* Система менеджмента качества
ИЗГОТОВИТЕЛЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ МЕДИЦИНСКОГО ИЗДЕЛИЯ должен быть способен продемонстрировать его соответствие требованиям потребителя и применимым регулирующим требованиям.
Примечание 1 - Демонстрация этой способности может быть осуществлена при помощи СИСТЕМЫ менеджмента качества, которая соответствует следующим требованиям:
- ISO 13485 [8] или
- национальному стандарту на систему менеджмента качества или
- системе менеджмента качества, требуемой национальным регулированием.
Примечание 2 - Руководство по применению требований системы менеджмента качества к ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ можно найти в ISO/IEC 90003 [15].
4.2 * МЕНЕДЖМЕНТ РИСКА
ИЗГОТОВИТЕЛЬ должен применять ПРОЦЕСС МЕНЕДЖМЕНТА РИСКА в соответствии с ISO 14971.
4.3 *Классификация программного обеспечения в отношении безопасности
a) ИЗГОТОВИТЕЛЬ должен присвоить каждой ПРОГРАММНОЙ СИСТЕМЕ класс безопасности программного обеспечения (A, B или C) согласно РИСКУ причинения ВРЕДА пациенту, пользователю или иным лицам, исходя из ОПАСНОЙ СИТУАЦИИ, в которую ПРОГРАММНАЯ СИСТЕМА может внести свой вклад в наихудшем сценарии, как показано на рисунке 3. |
Рисунок 3 - Присвоение класса безопасности программного обеспечения
ПРОГРАММНАЯ СИСТЕМА относится к классу безопасности программного обеспечения A, если: - ПРОГРАММНАЯ СИСТЕМА не может способствовать возникновению ОПАСНОЙ СИТУАЦИИ; - ПРОГРАММНАЯ СИСТЕМА может способствовать возникновению ОПАСНОЙ СИТУАЦИИ, которая не приводит к недопустимому РИСКУ после рассмотрения мер по УПРАВЛЕНИЮ РИСКОМ, внешних по отношению к ПРОГРАММНОЙ СИСТЕМЕ. - ПРОГРАММНАЯ СИСТЕМА относится к классу безопасности программного обеспечения B, если: - ПРОГРАММНАЯ СИСТЕМА может способствовать возникновению ОПАСНОЙ СИТУАЦИИ, которая приводит к недопустимому РИСКУ после рассмотрения мер по УПРАВЛЕНИЮ РИСКОМ, внешних по отношению к ПРОГРАММНОЙ СИСТЕМЕ, и вытекающий из этого возможный ВРЕД не является СЕРЬЕЗНОЙ ТРАВМОЙ. ПРОГРАММНАЯ СИСТЕМА относится к классу безопасности программного обеспечения C, если: - ПРОГРАММНАЯ СИСТЕМА может способствовать возникновению ОПАСНОЙ СИТУАЦИИ, которая приводит к недопустимому РИСКУ, после рассмотрения мер по УПРАВЛЕНИЮ РИСКОМ, внешних по отношению к ПРОГРАММНОЙ СИСТЕМЕ, и в результате возможным ВРЕДОМ является смерть или СЕРЬЕЗНАЯ ТРАВМА. Для ПРОГРАММНОЙ СИСТЕМЫ, первоначально классифицированной как класс безопасности программного обеспечения B или C, ИЗГОТОВИТЕЛЬ может реализовать дополнительные меры по УПРАВЛЕНИЮ РИСКОМ, внешние по отношению к ПРОГРАММНОЙ СИСТЕМЕ (включая пересмотр архитектуры системы, содержащей ПРОГРАММНУЮ СИСТЕМУ), и впоследствии присвоить ПРОГРАММНОЙ СИСТЕМЕ новую классификацию безопасности программного обеспечения. Примечание 1 - Внешними мерами по УПРАВЛЕНИЮ РИСКОМ могут быть аппаратные средства, независимая ПРОГРАММНАЯ СИСТЕМА, медицинские процедуры или другие средства, позволяющие свести к минимуму способность программного обеспечения приводить к возникновению ОПАСНОЙ СИТУАЦИИ. |
Примечание 2 - Определение допустимости риска см. в подразделе 3.2 "Ответственность руководства" ISO 14971:2007.
b) Не используется. |
c) ИЗГОТОВИТЕЛЬ обязан документировать класс безопасности программного обеспечения, присвоенный каждой ПРОГРАММНОЙ СИСТЕМЕ, в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА.
d) Если ПРОГРАММНАЯ СИСТЕМА подразделяется на ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ и в дальнейшем ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ в свою очередь подразделяются на ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ, то такие ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ должны наследовать класс безопасности первоначальной ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ (или ПРОГРАММНОЙ СИСТЕМЫ), если только ИЗГОТОВИТЕЛЬ не обосновывает в документации присвоение другого класса безопасности
программного обеспечения (классы безопасности программного обеспечения, присвоенные в соответствии с подразделом 4.3 a), заменяя "ПРОГРАММНУЮ СИСТЕМУ" на "ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ"). Это обоснование должно объяснять, почему ПРОГРАММНЫЕ СОСТАВНЫЕ ЧАСТИ |
являются изолированными настолько, что могут классифицироваться отдельно.
e) ИЗГОТОВИТЕЛЬ должен документировать класс безопасности программного обеспечения каждой ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ, если этот класс отличается от класса ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ, из которой он был выделен при декомпозиции.
f) Для соответствия настоящему стандарту там, где настоящий стандарт применяется к группе ПРОГРАММНЫХ СОСТАВНЫХ ЧАСТЕЙ, ИЗГОТОВИТЕЛЬ должен использовать ПРОЦЕССЫ и ЗАДАЧИ, |
которые требуются для классификации ПРОГРАММНОЙ СОСТАВНОЙ ЧАСТИ с наивысшей категорией из всей группы, если только ИЗГОТОВИТЕЛЬ в ФАЙЛЕ МЕНЕДЖМЕНТА РИСКА не приводит документированные обоснования для использования более низкой классификации.
g) Каждой ПРОГРАММНОЙ СИСТЕМЕ, если ей не присвоен класс безопасности программного обеспечения, по умолчанию должен присваиваться Класс C.
Примечание - В последующих разделах и подразделах классы безопасности программного обеспечения, к которым применяется конкретное требование, определяются в соответствии с требованием в форме [Класс...]. |
4.4* УСТАРЕВШЕЕ/НАСЛЕДУЕМОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ 4.4.1 Общие сведения В качестве альтернативы применению разделов 5 - 9 настоящего стандарта соответствие УСТАРЕВШЕГО/НАСЛЕДУЕМОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ может быть продемонстрировано, как указано в 4.4.2 - 4.4.5. 4.4.2 Деятельность по МЕНЕДЖМЕНТУ РИСКА В соответствии с 4.2 настоящего стандарта ИЗГОТОВИТЕЛЬ должен: a) оценить любую обратную связь, включая постпроизводственную информацию, об УСТАРЕВШЕМ ПРОГРАММНОМ ОБЕСПЕЧЕНИИ, касающуюся инцидентов и/или близких к ним ситуаций как внутри своей организации, так и/или от пользователей; b) выполнить ДЕЯТЕЛЬНОСТЬ по УПРАВЛЕНИЮ РИСКОМ, связанную с продолжением использования УСТАРЕВШЕГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, с учетом следующих аспектов: - интеграции УСТАРЕВШЕГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ в общую архитектуру МЕДИЦИНСКОГО ИЗДЕЛИЯ; - постоянной пригодности мер по УПРАВЛЕНИЮ РИСКОМ, реализованных в рамках УСТАРЕВШЕГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ; - идентификации ОПАСНЫХ СИТУАЦИЙ, связанных с продолжением использования УСТАРЕВШЕГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ; - идентификации потенциальных причин, по которым УСТАРЕВШЕЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ может привести к возникновению ОПАСНОЙ СИТУАЦИИ; - определения мер по УПРАВЛЕНИЮ РИСКОМ для каждой потенциальной причины, по которой УСТАРЕВШЕЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ способствует возникновению ОПАСНОЙ СИТУАЦИИ. 4.4.3 Анализ несоответствия ожидаемых и реализованных результатов Основываясь на классе безопасности УСТАРЕВШЕГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ (см. 4.3), ИЗГОТОВИТЕЛЬ должен провести анализ несоответствия ожидаемых и реализованных ПОСТАВЛЕННЫХ РЕЗУЛЬТАТОВ по сравнению с теми, которые требуются в соответствии с 5.2, 5.3, 5.7 и разделом 7. |
a) ИЗГОТОВИТЕЛЬ должен оценить непрерывную пригодность полученных РЕЗУЛЬТАТОВ. b) В случае идентификации несоответствий ожидаемых и реализованных результатов ИЗГОТОВИТЕЛЬ должен ОЦЕНИТЬ возможное снижение РИСКА в результате получения отсутствующих РЕЗУЛЬТАТОВ и связанной с ними ДЕЯТЕЛЬНОСТИ. c) На основе этого оценивания ИЗГОТОВИТЕЛЬ должен определить РЕЗУЛЬТАТЫ, которые должны быть получены, а также связанную с ними ДЕЯТЕЛЬНОСТЬ, которая должна быть выполнена. Минимальным ПОСТАВЛЯЕМЫМ РЕЗУЛЬТАТОМ должны быть записи тестирования ПРОГРАММНЫХ СИСТЕМ (см. 5.7.5). Примечание - Анализ несоответствий ожидаемых и реализованных результатов должен обеспечивать включение в требования к программному обеспечению мер по УПРАВЛЕНИЮ РИСКОМ, реализованных в УСТАРЕВШЕМ ПРОГРАММНОМ ОБЕСПЕЧЕНИИ.
4.4.4 Деятельность по устранению несоответствий ожидаемых и реализованных результатов а) ИЗГОТОВИТЕЛЬ должен разработать и выполнить план по созданию идентифицированных ПОСТАВЛЯЕМЫХ РЕЗУЛЬТАТОВ. Там, где это возможно, объективные свидетельства могут быть использованы для формирования требуемых ПОСТАВЛЯЕМЫХ РЕЗУЛЬТАТОВ без выполнения ДЕЯТЕЛЬНОСТИ, установленной в 5.2, 5.3, 5.7 и разделе 7. Примечание - План устранения идентифицированных несоответствий ожидаемых и реализованных результатов может быть включен в план технической поддержки программного обеспечения (см. 6.1).
б) План должен предусматривать использование ПРОЦЕССА решения проблем для обработки проблем, обнаруженных в УСТАРЕВШЕМ ПРОГРАММНОМ ОБЕСПЕЧЕНИИ и ПОСТАВЛЯЕМЫХ РЕЗУЛЬТАТАХ, в соответствии с Разделом 9. в) Изменения в УСТАРЕВШЕМ ПРОГРАММНОМ ОБЕСПЕЧЕНИИ должны быть выполнены в соответствии с разделом 6. |
4.4.5 Обоснование использования УСТАРЕВШЕГО/НАСЛЕДУЕМОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ИЗГОТОВИТЕЛЬ должен задокументировать ВЕРСИЮ УСТАРЕВШЕГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ вместе с обоснованием дальнейшего использования УСТАРЕВШЕГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ на основе результатов 4.4. Примечание - Выполнение 4.4 позволяет в дальнейшем использовать УСТАРЕВШЕЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ в соответствии с IEC 62304. |
