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

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

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

Н.1 Примеры структур PEMS/PESS

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

На рисунке Н.1 приведены некоторые возможные варианты PEMS.

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

На рисунке Н.1 b) изображена менее сложная система, в которой отсутствует промежуточный основной уровень подсистемы, a PESS является непосредственно подсистемой PEMS.

На рисунке Н.1 с) изображена PEMS самого простого исполнения, при котором PEMS и PESS идентичны.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Н.3.1 ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ PEMS

ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ PEMS, аналогичный изображенному на рисунке Н.2, состоит из ряда ПРОЦЕССОВ, которые состоят из операций, каждая из которых выполняется для реализации определенных задач. Для применения процедуры МЕНЕДЖМЕНТА РИСКА необходима уверенность в технических операциях, на которых она базируется. В частности, это относится к жизненному циклу программного обеспечения.

В МЭК 62304 [26] (находящемся на стадии разработки) описываются процессы, которые должны быть включены в жизненный цикл разработки программного обеспечения с целью разработки безопасного программного обеспечения для медицинских устройств.

Рисунок Н.1 - Примеры структур PEMS/PESS

Рисунок Н.2 - Модель ЖИЗНЕННОГО ЦИКЛА РАЗРАБОТКИ PEMS

Н.3.2 Требования к характеристикам

Для определения того, какие функции создают РИСКИ или управляют ими, необходимо полностью идентифицировать требования к PEMS/PESS. Адекватную ОЦЕНКУ РИСКА невозможно выполнить без создания полной спецификации требований и разработки структуры, отвечающей этой спецификации.

Эти требования к программному обеспечению PEMS должны включать в себя (в зависимости от конкретного случая):

- функциональные требования и требования к техническим возможностям, включая ОСНОВНЫЕ ФУНКЦИОНАЛЬНЫЕ ХАРАКТЕРИСТИКИ, физические характеристики и факторы внешней среды, при которых программное обеспечение должно работать;

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

- требования к безопасности, включая средства УПРАВЛЕНИЯ РИСКОМ при неисправности аппаратных средств ЭВМ и наличии возможных дефектов программного обеспечения и технических требований, связанных с методами работы и технического обслуживания, действием факторов внешней среды и УПРАВЛЕНИЕМ РИСКОМ;

- программно формируемые предупреждающие сигналы, сигналы тревоги и сообщения для ОПЕРАТОРА;

- требования безопасности в случае, когда недостаточная защита ставит под угрозу безопасность;

- технические требования, учитывающие человеческий фактор и связанные с использованием PEMS, включая требования, связанные с ручными операциями, взаимодействиями типа "человек - машина", ограничениями при выборе персонала и областями, требующими повышенного внимания ОПЕРАТОРА и особо чувствительными к его ошибкам и уровню обучения;

- определение данных и требований к базе данных;

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

- требования к разрабатываемой документации;

- требования к работе и функционированию;

- требования к техническому обслуживанию.

Для определения области, на которую будет распространяться разработка структуры, предназначенная для снижения РИСКОВ, должна использоваться процедура ОЦЕНКА РИСКА.

Н.3.3 Стороннее и стандартное программное обеспечение (OTS)

Для того чтобы иметь возможность идентификации известных или прогнозируемых ОПАСНОСТЕЙ, необходимо также знать характеристики любого стороннего и стандартного программного обеспечения (OTS), используемого в PEMS. Разработчик должен установить требования к стороннему и стандартному программному обеспечению, которые должны включать в себя:

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

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

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

- основные меры безопасности и УПРАВЛЕНИЯ РИСКОМ, зависящие от компонентов программного обеспечения.

Н.3.4 Интеграция

Разработчик должен установить план интеграции компонентов каждых PESS и PEMS, который должен включать в себя метод интеграции, распределение ответственностей и последовательность операций, а также все компоненты программного обеспечения. Если программное обеспечение PESS разработано с использованием методов поэлементной компоновки, то должны быть проведены достаточные декомпоновочные испытания, гарантирующие достаточность предыдущей ВЕРИФИКАЦИИ. Компоновочные испытания должны включать в себя совокупность тестовых данных, которые позволяют исследовать поведение программного обеспечения не только в нормальном случае, но и как реакции на исключительные случаи, случаи перегрузки или наименее благоприятные случаи.

Н.3.5 Управление конфигурацией

Поскольку АНАЛИЗ РИСКА основывается на требованиях к программному обеспечению, управление конфигурацией PEMS и контроль ее изменений должны гарантировать сохранение функциональных возможностей программного обеспечения в процессе разработки без учета дополнительных возможностей в ПРОЦЕССЕ МЕНЕДЖМЕНТА РИСКА. Должен быть установлен план управления конфигурацией, содержащий:

- изделия, которые подлежат управлению;

- работы по управлению конфигурацией;

- ПРОЦЕДУРЫ и график выполнения этих работ;

- распределение обязанностей при выполнении этих работ;

- ПРОЦЕДУРЫ, необходимые для управления процедурами получения, инсталляции и приемки каждого компонента программного обеспечения.

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

Н.3.6 Управление модификацией/изменениями

Для управления модификацией/изменениями необходимо выполнять следующее:

- идентификацию и регистрацию запросов на внесение изменений;

- анализ и оценку внесенных изменений;

- прием или отклонение запросов;

- внедрение, ВЕРИФИКАЦИЮ и выпуск измененного программного обеспечения.

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

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

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

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

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

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

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

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

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

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

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

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

d) интерфейса "человек - PEMS";

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

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

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

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

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

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

На рисунке Н.3 указана вся документация, необходимая в соответствии с пунктом 14 ИСО 14971, однако он только иллюстрирует структуру документации.

Частные ссылки на документы могут быть сконцентрированы в одном документе или распределены по нескольким документам. Номера пунктов, перед которыми стоит значок "#", являются ссылками на номера пунктов ИСО 14971. Другие номера относятся к подпунктам настоящего стандарта.

Н.6 СЕТЕВЫЕ/ИНФОРМАЦИОННЫЕ СРЕДСТВА СВЯЗИ

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

В контексте настоящего стандарта информация, передаваемая как часть СЕТЕВЫХ/ИНФОРМАЦИОННЫХ СРЕДСТВ СВЯЗИ, является информацией, предусмотренной ИЗГОТОВИТЕЛЕМ для передачи (т.е. не посредством незаконных действий неуполномоченных лиц).

СЕТЕВЫЕ/ИНФОРМАЦИОННЫЕ СРЕДСТВА СВЯЗИ в том виде, в котором они упоминаются в данном стандарте, не должны включать в себя информацию, передаваемую через пользовательские интерфейсы. ИЗГОТОВИТЕЛЬ должен в техническом описании оговаривать возможные типы информации и протоколы их передачи (см. 14.13).

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

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

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

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

- назначении объединенной системы, по которому она будет использоваться;

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

- требуемой конфигурации системы;

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

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

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

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

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

Рисунок Н.3 - Требования к документации на PEMS согласно пункту 14 ИСО 14971

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

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

Обычно системный интегратор должен:

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

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

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

Н.7 Анализ СЕТЕВЫХ/ИНФОРМАЦИОННЫХ СРЕДСТВ СВЯЗИ при проектировании PEMS

Н.7.1 Введение

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

Н.7.2 Причины возникновения ОПАСНОСТЕЙ, исходящих от СЕТЕВЫХ/ИНФОРМАЦИОННЫХ СРЕДСТВ СВЯЗИ

В системах с СЕТЕВЫМИ/ИНФОРМАЦИОННЫМИ СРЕДСТВАМИ СВЯЗИ вероятны следующие причины возникновения ОПАСНОСТЕЙ:

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

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

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

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

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

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

При идентификации причин возникновения ОПАСНОСТЕЙ, связанных с СЕТЕВЫМИ/ИНФОРМАЦИОННЫМИ СРЕДСТВАМИ СВЯЗИ, дополнительно см. приложение А к ИСО 14971:2000. По крайней мере, необходимо рассматривать следующее:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При анализе возможных причин возникновения вышеуказанных ОПАСНОСТЕЙ, связанных с СЕТЕВЫМИ/ИНФОРМАЦИОННЫМИ СРЕДСТВАМИ СВЯЗИ, дополнительно см. приложение D к ИСО 14971. По крайней мере необходимо принимать во внимание следующее.

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

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

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

Какие данные передаются по сети и с какими задачами они связаны? Каковы последствия отказа СЕТЕВЫХ/ИНФОРМАЦИОННЫХ СРЕДСТВ СВЯЗИ?

с) Отклонение от установленных функциональных характеристик любого PEMS.

Каковы функциональные характеристики PEMS и до какой степени они затрагивают СЕТЕВЫЕ/ИНФОРМАЦИОННЫЕ СРЕДСТВА СВЯЗИ?

d) Неполное определение характеристик СЕТЕВЫХ/ИНФОРМАЦИОННЫХ СРЕДСТВ СВЯЗИ.

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

e) Чрезме