Приложение Н (справочное). Структура 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) Чрезмерная эксплуатация/нагрузка на СЕТЕВЫЕ/ИНФОРМАЦИОННЫЕ СРЕДСТВА СВЯЗИ со стороны узлов сети.

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

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

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

g) Несоответствующая организация структуры.

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

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

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

Н.7.3 Классификация сетей по последствиям для ПАЦИЕНТА

Н.7.3.1 Последствия для ПАЦИЕНТА

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

Таблица Н.1 содержит пример классификации СЕТЕВЫХ/ИНФОРМАЦИОННЫХ СРЕДСТВ СВЯЗИ, основанных на этих соображениях.

Таблица Н.1 - Классификация СЕТЕВЫХ/ИНФОРМАЦИОННЫХ СРЕДСТВ СВЯЗИ

Последствия выхода из строя	Время реагирования	Класс	Пример(ы)
Смертельная/серьезная травма	Секунда(ы)	С	Вливание (в замкнутом контуре); ошибочное управление хирургическим роботом
	Минута(ы)	С	Блокировка передачи сигналов тревоги
	Час(ы)	С/В	Ошибочные терапевтические данные для аппарата искусственной вентиляции легких
Травма средней тяжести	Секунда(ы)	С	Ошибочная передача сигналов тревоги, ошибочное управление хирургическим роботом
	Минута(ы)	С/В	Ошибочная передача сигналов тревоги, ошибочное управление хирургическим роботом
	Час(ы)	С/В	Искажение изображения; утеря больничной карты
Травма малой тяжести	Секунда(ы)	В	-
	Минута(ы)	В	Утеря рентгеновского снимка
	Час(ы)	В/А	-
Незначительная травма	Секунда(ы)	А	-
	Минута(ы)	А	-
	Час(ы)	А	-

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

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

Необходимо избегать нарушений в работе, продолжительность которых не должна превышать нескольких минут в году. Ответственность за это возлагается исключительно на единственного ИЗГОТОВИТЕЛЯ PEMS/поставщика системы. Узлы сети должны отвечать требованиям, предъявляемым этим ИЗГОТОВИТЕЛЕМ/поставщиком. Пример средств данного класса - непрерывно контролируемая сеть ПАЦИЕНТА.

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

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

- Ответственность при этом возлагается на ОТВЕТСТВЕННУЮ ОРГАНИЗАЦИЮ или на системного интегратора. При наличии нескольких PEMS необходимо установление приоритета данных.

- Узлы сети должны соответствовать выбранному набору критериев/минимально требуемых параметров. Примером этому может служить рентгенологическая сеть.

Н.7.3.4 Класс А СЕТЕВЫХ/ИНФОРМАЦИОННЫХ СРЕДСТВ СВЯЗИ

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

- ответственность возлагается на ОТВЕТСТВЕННУЮ ОРГАНИЗАЦИЮ;

- имеется большое число типов узлов сети.

Н.7.4 Параметры СЕТЕВЫХ/ИНФОРМАЦИОННЫХ СРЕДСТВА СВЯЗИ

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

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

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

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

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

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

Рисунок Н.4 содержит перечень параметров, который в принципе должен задаваться. Из-за быстрого развития технологии СЕТЕВЫХ/ИНФОРМАЦИОННЫХ СРЕДСТВ СВЯЗИ требования в этой таблице должны рассматриваться лишь в качестве отправной точки. Должно быть ясно, как эта таблица должна поддерживаться и кто должен нести ответственность за это.

Рисунок Н.4 - Пример параметров, которые могут потребоваться для определения характеристик СЕТЕВЫХ/ИНФОРМАЦИОННЫХ СРЕДСТВ СВЯЗИ