Приложение H (справочное). Структура ПЭМС, жизненный цикл разработки ПЭМС и документирование

Приложение H
(справочное)

Структура ПЭМС, ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ ПЭМС и документирование

H.1 Примеры структур ПЭМС/ПЭПС

ПЭМС может быть очень простой частью МЭ ИЗДЕЛИЯ или сложной частью МЭ СИСТЕМЫ (или какое-либо промежуточное сочетание).

На рисунке H.1 приведены некоторые возможные варианты ПЭМС.

На рисунке H.1 a) изображена сложная система, распадающаяся на ряд основных подсистем, которые, в свою очередь, состоят из подсистем, включающих ПЭПС.

На рисунке H.1 b) изображена менее сложная система, в которой отсутствует промежуточный основной уровень подсистемы, а ПЭПС является непосредственно подсистемой ПЭМС.

На рисунке H.1 c) изображена ПЭМС самого простого исполнения, при котором ПЭМС и ПЭПС идентичны.

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

- разделение ПЭМС на компоненты, особенно реализованные в каждой из ПЭПС и включающие компоненты программного обеспечения;

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

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

- интерфейсы между компонентами программного обеспечения и компонентами, внешними по отношению к нему.

H.2 Модель ЖИЗНЕННОГО ЦИКЛА РАЗРАБОТКИ ПЭМС

Соответствие ПЭМС требованиям пункта 14 настоящего стандарта требуется для определения ее ЦИКЛА РАЗРАБОТКИ и последующего отслеживания. При этом не требуется использование какого-либо специфического ЦИКЛА РАЗРАБОТКИ, однако необходимо, чтобы он имел некоторые признаки (атрибуты), см. требования в 14.4.

ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ ПЭМС является частью полного жизненного цикла изделия.

Рисунок H.2 иллюстрирует модель ЖИЗНЕННОГО ЦИКЛА РАЗРАБОТКИ ПЭМС, где показаны операции, сгруппированные по двум основным ПРОЦЕССАМ. Слева показан ПРОЦЕСС декомпозиции, справа - ПРОЦЕСС интеграции.

Рисунок H.2 иллюстрирует:

- многоуровневые операции разработки;

- для каждого уровня разработки - соответствующий уровень интеграции и ПРОВЕРКИ;

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

- ПРОЦЕСС взаимодействия при разрешении разногласий.

a) Пример сложной системы

Рисунок H.1. Лист 1

b) Пример более простого исполнения

c) Пример самого простого исполнения

Рисунок H.1 - Примеры структур ПЭМС/ПЭПС. Лист 2

Рисунок H.2 - МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА РАЗРАБОТКИ ПЭМС

Поскольку разработка разделена по требованиям, то выбираются стандартные функциональные блоки, структура и технология ПЭМС. ПРОЦЕСС декомпозиции заканчивается тогда, когда проектные данные позволят сформировать компоненты ПЭМС (пример проектных данных: принципиальные схемы и программный код). Компоненты после декомпозиции интегрируются вместе. ВЕРИФИКАЦИЮ проводят после интеграции компонентов для определения того, действительно ли реализация отвечает предъявляемым требованиям. При завершении ПРОЦЕССА интеграции выполняют ПРОВЕРКУ СООТВЕТСТВИЯ ПЭМС для определения того, действительно ли ПЭМС функционирует согласно своему назначению.

H.3 ПРОЦЕССЫ программного обеспечения

МЭК 62304 описывает процессы, которые должны быть включены в жизненный цикл разработки программного обеспечения для создания безопасного программного обеспечения для медицинского изделия.

H.4 Проектирование и реализация

В процессе применения модели ЖИЗНЕННОГО ЦИКЛА РАЗРАБОТКИ ПЭМС проектирование и реализация будут включать выбор:

a) проектной среды, например:

- методов разработки программного обеспечения;

- средств для системы автоматизированного проектирования ();

- языка программирования;

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

- способов моделирования;

- стандартов на проектирование и программирование;

b) электронных компонентов;

c) зарезервированных аппаратных средств;

d) интерфейса "человек - ПЭМС";

e) источников питания;

f) экологических условий;

g) стороннего программного обеспечения;

h) вариантов организации сети.

Эти элементы среды проектирования могут быть охарактеризованы в общем случае и при определенном способе их использования: при проектировании и в ПРОЦЕССЕ реализации.

H.5 Документирование

Не применяется.

H.6 ПЭМС, предназначенная для включения в ИТ-СЕТЬ

H.6.1 Общие положения

В контексте настоящего стандарта информация, передаваемая по ИТ-СЕТИ, является информацией, предусмотренной ИЗГОТОВИТЕЛЕМ для передачи (т.е. не посредством незаконных действий неуполномоченных лиц).

H.6.2 Ответственность за системную интеграцию

МЭ ИЗДЕЛИЯ и МЭ СИСТЕМЫ должны иногда работать в составе ИТ-СЕТИ, что, вероятно, станет более частым в связи с ростом применения компьютеров для анализа клинических данных и контроля за лечением.

Иногда ИЗГОТОВИТЕЛЬ МЭ ИЗДЕЛИЯ будет разрабатывать его для работы по ИТ-СЕТИ с другим МЭ ИЗДЕЛИЕМ, однако нередко МЭ ИЗДЕЛИЯ не предназначены для работы со всеми другими МЭ ИЗДЕЛИЯМИ по ИТ-СЕТИ. Кто-то должен нести ответственность за то, чтобы отдельные МЭ ИЗДЕЛИЯ в ИТ-СЕТИ вместе работали удовлетворительно; другими словами, кто-то должен отвечать за разработку ИТ-СЕТИ.

Признано, что интегратор ИТ-СЕТИ должен соответствовать специфическим нормативным требованиям, для чего он должен иметь информацию о (об):

- назначении ИТ-СЕТИ, по которому она будет использоваться;

- требуемых функциональных характеристиках объединенной ИТ-СЕТИ;

- требуемой конфигурации ИТ-СЕТИ;

- ограничениях на допустимую степень расширения ИТ-СЕТИ;

- технических требованиях ко всем МЭ ИЗДЕЛИЯМ и другим изделиям, которые будут объединяться;

- функциональных характеристиках каждого МЭ ИЗДЕЛИЯ и другого изделия;

- информационных потоках в ИТ-СЕТИ и вокруг нее.

Эта информация не будет доступна отдельным ИЗГОТОВИТЕЛЯМ. По этой причине каждый ИЗГОТОВИТЕЛЬ не сможет исполнять роль интегратора ИТ-СЕТИ, который в любом случае должен быть единственным лицом или организацией, которое(ая) будет нести полную ответственность, неразделимую между несколькими ИЗГОТОВИТЕЛЯМИ. При этом ответственность ИЗГОТОВИТЕЛЯ будет ограничена лишь предоставлением требуемой информации относительно его изделия (см. 14.13).

Очевидно, что ОТВЕТСТВЕННАЯ ОРГАНИЗАЦИЯ может привлекать ИЗГОТОВИТЕЛЯ к объединению их МЭ ИЗДЕЛИЙ в свою ИТ-СЕТЬ. В этом случае ИТ-СЕТЬ в целом может стать МЭ СИСТЕМОЙ, ответственность за правильность объединения в систему будет нести ИЗГОТОВИТЕЛЬ. При этом система может регулироваться отдельно.

Интегратор ИТ-СЕТИ должен обладать компетентностью при оценке и анализе ОПАСНОСТЕЙ, которые могут возникать в результате объединения ИТ-СЕТИ и гарантировать сохранение ОСТАТОЧНЫХ РИСКОВ для отдельных ПЭМС.

Обычно интегратор ИТ-СЕТИ должен:

- планировать интеграцию любого МЭ ИЗДЕЛИЯ (или МЭ СИСТЕМЫ) и немедицинского изделия в соответствии с инструкциями, предоставляемыми различными ИЗГОТОВИТЕЛЯМИ;

- выполнять МЕНЕДЖМЕНТ РИСКА в объединенной ИТ-СЕТИ;

- передавать любые инструкции ИЗГОТОВИТЕЛЯ ОТВЕТСТВЕННОЙ ОРГАНИЗАЦИИ, где они требуются для безопасной работы объединенной ИТ-СЕТИ. Эти инструкции должны включать предупреждения относительно всех ОПАСНОСТЕЙ, возникающих при любом изменении конфигурации.

H.7 Анализ ИТ-СЕТЕЙ при проектировании ПЭМС

H.7.1 Обзор

С точки зрения ИЗГОТОВИТЕЛЯ ПЭМС, любой тип ИТ-СЕТИ является источником дополнительных ОПАСНЫХ СИТУАЦИЙ. В принципе любая ИТ-СЕТЬ, которая находится вне контроля ИЗГОТОВИТЕЛЯ ПЭМС, никогда не должна считаться на 100 % надежной.

H.7.2 Причины возникновения ОПАСНЫХ СИТУАЦИЙ, исходящих от ИТ-СЕТЕЙ

В ИТ-СЕТЯХ вероятны следующие причины возникновения ОПАСНЫХ СИТУАЦИЙ:

- потеря данных;

- несоответствующий обмен данными;

- искажение данных;

- несоответствующая временная последовательность данных;

- непредвиденное получение данных;

- неправомочный доступ к данным.

В дополнение к приложению C стандарта ИСО 14971:2019 следует учитывать, что, по меньшей мере, следующие инициирующие события или обстоятельства могут привести к ОПАСНЫМ СИТУАЦИЯМ, связанным с ИТ-СЕТЯМИ:

- дистанционное обслуживание (внешний доступ к сети);

- операционная система (совместимость операционных систем);

- модификация/модернизация программного обеспечения (операционные системы, области применения и т.д.);

- совместимость интерфейсов (конфликт на уровне данных, форматы данных):

- по соединениям (модификации аппаратных средств, соединителям сети),

- по сетевым интерфейсным платам (совместимость),

- по сетевым протоколам (DICOM, HL7 и т.д.);

- структура/временная последовательность пакетных адресов;

- стандартная нагрузка/полоса частот сети;

- максимальная нагрузка сети;

- носитель данных (их долговечность и возможность перезаписи);

- безопасность (защита от вирусов, "червей", несанкционированного изменения или обновления программного обеспечения);

- максимально допустимое время отклика;

- допустимая частота отказов в сети;

- эксплуатационная готовность (плановое и внеплановое техническое обслуживание);

- несоответствие интерфейсов/форматов, приводящее к потере точности воспроизведения при передаче данных;

- разнородность структуры сети.

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

a) разумно прогнозируемое непредусмотренное применение.

Совместимо ли присоединение к сети с ПРЕДУСМОТРЕННЫМ ПРИМЕНЕНИЕМ каждого ПЭМС?

b) Поток неправильных данных к каждому ПЭМС или от него.

Какие данные передаются по сети и с какими задачами они связаны? Каковы последствия отказа ИТ-СЕТЕЙ?

c) Отклонение от установленных функциональных характеристик любого ПЭМС.

Каковы функциональные характеристики ПЭМС и до какой степени они затрагивают ИТ-СЕТИ?

d) Неполное определение характеристик ИТ-СЕТЕЙ.

Полностью ли определены структура сети, ее конфигурация и параметры (например, открытая или закрытая конфигурация, полоса пропускания сети, протокол передачи)? Имеются ли какие-либо аварийные характеристики/понятия и каковы они?

e) Чрезмерная эксплуатация/нагрузка на ИТ-СЕТИ со стороны узлов сети.

Каковы запланированное число узлов сети и предполагаемая степень их загрузки? Достаточны ли ресурсы, чтобы удовлетворить потребности как самих ИТ-СЕТЕЙ, так и устройств, связанных с ними?

f) Ошибки при эксплуатации.

Какие навыки ОПЕРАТОРА необходимы для эффективной работы системы?

g) Несоответствующая организация управления

Изменяют ли периодически задания на обслуживание характеристики ИТ-СЕТЕЙ (например, после дистанционного доступа, модернизации или модификации)? Гарантирует ли ОТВЕТСТВЕННАЯ ОРГАНИЗАЦИЯ рассмотрение и утверждение модификации каждой ПЭМС?

h) Информация в ненадлежащем месте.

Достигают ли данные удобного и прогнозируемого пункта назначения? Будет ли это сопровождаться неправильными данными, которые могут вводить в заблуждение ОПЕРАТОРА или исказить требуемые данные? Указывается ли должным образом источник поступивших данных?

H.7.3 Не используется

H.7.4 Параметры ИТ-СЕТЕЙ

Использование ИТ-СЕТЕЙ для обмена данными между ПЭМС или между ПЭМС и другим информационным оборудованием требует знаний как относительно структуры ИТ-СЕТЕЙ, так и о ПРОЦЕССАХ/функциях, выполняемых в них. Это важно, поскольку ИЗГОТОВИТЕЛИ ПЭМС или ИТ-СЕТЕЙ должны выбрать конфигурацию своей продукции такой, чтобы они:

- отвечали всемирно признанным стандартам сети (Ethernet, Fast Ethernet, GigaBitEthernet, FDDI и т.д.) и эффективно использовали доступную полосу пропускания в соответствии со своим ПРЕДУСМОТРЕННЫМ ПРИМЕНЕНИЕМ;

- достигали своих оптимальных функциональных характеристик в области их применения.

В ряде случаев могут появляться такие сочетания различных установок конфигураций/параметров ИТ-СЕТЕЙ, которые оказываются не всегда совместимыми для различных узлов ИТ-СЕТЕЙ, даже несмотря на то, что они отвечают действующим международным стандартам.

Во избежание появляющейся при этом возможности нарушения работы ИТ-СЕТЕЙ (или, по крайней мере, сведения ее к минимуму) необходимо согласование минимального набора параметров, получаемых из соответствующих стандартов.

Рисунок H.4 содержит перечень параметров, который должен задаваться. Из-за быстрого развития технологии ИТ-СЕТЕЙ требования в этой таблице должны рассматриваться лишь в качестве отправной точки. Должно быть ясно, как эта таблица должна поддерживаться и кто должен нести ответственность за это.

Рисунок H.4. Лист 1

Рисунок H.4 - Пример параметров, которые могут потребоваться для определения характеристик ИТ-СЕТЕЙ. Лист 2