ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТР НАЦИОНАЛЬНЫЙ 56844— (СсГт) СТАНДАРТ 2015 vUm J РОССИЙСКОЙ /ISO/IEEE ФЕДЕРАЦИИ 11073-20101: 2004

Информатизация здоровья

ИНФОРМАЦИОННОЕ ВЗАИМОДЕЙСТВИЕ С ПЕРСОНАЛЬНЫМИ МЕДИЦИНСКИМИ ПРИБОРАМИ

Часть 20101

Прикладные профили. Базовый стандарт

(ISO/IEEE 11073-20101:2004, ЮТ)

Издание официальное

Москва

Стандартинформ

2016

Предисловие

1    ПОДГОТОВЛЕН Федеральным государственным бюджетным учреждением «Центральный научно-исследовательский институт организации и информатизации здравоохранения Министерства здравоохранения Российской Федерации» (ЦНИИОИЗ Минздрава) и обществом с ограниченной ответственностью «Корпоративные электронные системы» на основе собственного аутентичного перевода на русский язык англоязычной версии международного документа, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 468 «Информатизация здоровья» при ЦНИИОИЗ Минздрава — постоянным представителем ISO ТС 215

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 28 декабря 2015 г. № 2232-ст

4    Настоящий стандарт идентичен международному стандарту ISO/IEEE 11073-20101:2004 «Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 20101. Прикладные профили. Базовый стандарт» (ISO/IEEE 11073-20101:2004 «Health informatics — Point-of-care medical device communication — Part 20101: Application profiles — Base standard», IDT).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов и документов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в справочном приложении ДА

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ, 2016

Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Федерального агентства по техническому регулированию и метрологии

Рисунок 1 - Стек MDC

На рисунке показаны компоненты коммуникационного стека, а именно:

-    ACSE (сервисный элемент управления ассоциацией) является стандартом ИСО/ВОС для управления ассоциациями.

Стандартный механизм ассоциаций обеспечивает гибкость адаптации для возможных будущих требований, например, посредством дополнительных профилей форматов на верхних уровнях (таких форматов, как форматы изображений и простой сетевой протокол синхронизации времени [SNTP]) и различных механизмов кодирования.

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

-    сервисный элемент общей информации о медицинских приборах (CMDISE) - это служба управления объектами и по сути является упрощенной версией ИСО/ВОС сервисного элемента общей управляющей информации (CMISE);

ГОСТ Р 56844-2015/ISO/IEEE 11073-20101:2004

-    сервисный элемент удаленной операции (ROSE) предоставляет основные услуги, используемые сервисным элементом общей информации о медицинских приборах (CMDISE) (вызов операции, возврат результата операции, возврат ошибки, отклонение операции). В соответствии с определением оптимизированных правил кодирования, модифицированная версия сервисного элемента удаленной операции (ROSE) необходима для работы с сервисным элементом общей информации о медицинских приборах (CMDISE);

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

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

Компоненты информационной базы медицинских приборов (MDIB) нормативно определяются в документах элементов информационной модели предметной области (DIM) и базы управляющей информации (MIB) и кратко описываются следующим образом:

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

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

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

-    прикроватный коммуникационный контроллер (ВСС) - специализация, представляющая из себя менеджера коммуникационного контроллера прибора (DCC) (т. е. хост контроллера связи);

-    интерфейс прибора (DIF) - абстрактное представление точки доступа к транспортному сервису;

-    элемент базы управляющей информации (MIB) - абстрактное представление статуса или другой соответствующей информации. Специальные элементы базы управляющей информации (MIB) являются индивидуальными для данной конфигурации или реализации интерфейса прибора (DIF).

Сообщение приложения, например, сообщение с отчетом о событии объекта scanner, как определено в языке данных медицинских приборов (MDDL), проходит через этот коммуникационный стек, как показано на рисунке 2.

Объект scanner извлекает данные из базы данных медицинской информации (MDIB) и преобразует их в поле информации о событии объекта scanner.

После этого каждый уровень (или элемент стека) копирует часть данных и «помещает» их в свое собственное сообщение протокольного блока данных (PDU), обычно, посредством добавления некоторых данных заголовка, зависящих от конкретного уровня.

Принимающая система выполняет обратный процесс. Каждый уровень «извлекает» блок данных, снимая дополнительную информацию и заголовок, и далее передает результат на следующий уровень.

9

Рисунок 2 — Поток данных, проходящий через коммуникационный стек

6.2 Сервисный элемент управления ассоциацией (ACSE)

6.2.1    Общие положения

Для управления ассоциациями предполагается использовать стандартные сервисные элементы управления ассоциацией (ACSE), определенные в ИСО/МЭК 8650-1.

В дополнение к стандартным элементам ACSE необходимо определить набор полей информации пользователя, зависящих от приложения, а также минимальный (и обязательный) набор дополнительных элементов в блоках PDU ACSE.

6.2.2    Службы ACSE

В таблице 1 приведены службы (сервисы), предоставляемые сервисным элементом управления ассоциацией (ACSE).

Таблица 1- Сводка сервисов ACSE

Служба Тип A-ASSOCIATE Подтвержденный A-RELEASE Подтвержденный A-ABORT Не подтвержденный A-P-ABORT Инициируемый поставщиком услуг

Службы отображаются в сообщения, то есть в протокольные блоки данных (PDU) приложения. Для служб A-ASSOCIATE, например, имеются два сообщения: сообщение запроса на ассоциацию (AARQ) и сообщение ответа на ассоциацию (AARE).

Каждая служба (и таким образом полученный APDU) имеет определенное число полей данных или параметров. Таблицы 2 и 3 содержат фактические параметры сообщения запроса ассоциации (AARQ) и ответного сообщения ассоциации (AARE) для вызовов сервисов, которые определены в ACSE. Обозначения полей: М - обязательное, О - дополнительное, U - на усмотрение пользователя.

Таблица 2 - Поля AARQ блока данных APDU

Имя поля Наличие Версия протокола О Имя прикладного контекста М Наименование вызывающего прикладного процесса (АР) и Классификатор вызывающего прикладного компонента (АЕ) и Идентификатор вызова вызывающего прикладного процесса и Идентификатор вызова вызывающего прикладного компонента и Наименование вызываемого прикладного процесса и Классификатор вызываемого прикладного компонента и Идентификатор вызова вызываемого прикладного процесса и Идентификатор вызова вызываемого прикладного компонента и Информация о реализации О Информация о пользователе и

Таблица 3 - Поля AARQ блока APDU

Имя поля Наличие Версия протокола О Имя прикладного контекста М Наименование отвечающего прикладного процесса (АР) и Классификатор отвечающего прикладного компонента (АЕ) и Идентификатор вызова отвечающего прикладного процесса и Идентификатор вызова отвечающего прикладного компонента и Результат М Источник результата - диагностика М Информация о реализации О Информация о пользователе и

Как можно видеть, большинство полей являются дополнительными. Лишь небольшая часть из них является обязательными полями.

ACSE в профиле функциональной совместимости (интероперабельности) является лишь средством для стандартизированной установки соединения. Дополнительная информация, представляемая в поле «информация о пользователе», определяется в настоящем стандарте, чтобы облегчить взаимодействие медицинских приборов.

6.2.3    Определение сообщения ACSE ASN.1

Для получения более подробной информации см. приложение Е.

Для обеспечения полной интероперабельности сообщения ACSE должны быть закодированы с помощью основных правил кодирования (BER). Кроме того, они должны быть преобразованы в соответствующий уровень представления протокольного блока данных PDU (Блок данных протокола уровня представления (PPDU)) (СР: Подключения уровня представления, СРА: Принятие подключения уровня представления) и блок данных протокола сеансового уровня (SDPU) (CN: сеанс подключения, АС: сеанс принятия), как определено в приложении Е.

6.2.4    Поля информации о пользователе в ACSE

Информационные поля конкретного пользователя (то есть зависящие от определенного приложения) в определении сообщения ACSE для использования в коммуникационном стеке интероперабельности определены в приложении Е.

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

6.3 Протокол сеансового уровня

6.3.1    Общие положения

6.3.2    Службы сеансового уровня

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

-    подключение сеанса (Session connect);

-    принятие сеанса (Session accept);

-    передача данных сеанса (Session data transfer).

Может быть использовано несколько дополнительных услуг и протокольных блоков данных. Этот вопрос требует дальнейшего рассмотрения, особенно в отношении отображений элементов между ACSE, PPDU и SPDU.

6.3.3    Определения сообщений сеансового уровня

Для всех необходимых стандартных служб сеанса (SSs), а также для оптимизированного расширения сеансового уровня будет определена структура PDU (заголовок сеанса).

SPDU блоки построены из простых элементов в форме, указанной на рисунке 3.

Блоки SPDU	SI	LI	Поле параметров	Поле информации
				о пользователе

Модули PGI PGI LI Поле параметров Модули PI PI LI Попе параметров

Условные обозначения: LI — индикатор длины (длина 0-254: один октет; иначе 3 октета, начиная с 255); PGI — идентификатор группы параметров (определяет группу параметров сеансового уровня); PI — идентификатор параметров (определяет отдельный параметр сеансового уровня); SI — идентификатор SPDU (уникальный идентификатор, определяющий тип сообщения сеансового уровня)

Рисунок 3 — Формат протокольного блока данных сеансового уровня (SPDU)

Поля параметров составлены из блоков PGI и PI по определенным правилам (в соответствии с ИСО/МЭК 8327-1).

Пример сообщения сеансового уровня представлен в п. 6.3.3.1.

6.3.3.1 Подключение сеанса (CN) SPDU

Формат и содержание блока SPDU представлен следующим образом:

ГОСТ Р 56844-2015/ISO/IEEE 11073-20101:2004

0D XX SI = 13 (CN), LI = длина в октетах 05 06 PGI = 05 (элемент соединить/принять), LI = 06 13 01 00 PI = 19 (опции), LI = 1, значение = 0 16 01 03 PI = 22 (версия), LI = 1, значение = 3 14 02 00 02 PI = 20 (требования пользователя), LI = 2, значение выберите полнодуплексный функциональный блок Cl YY PGI = 193 (данные пользователя), LI = длина данных пользо

вателя

6.4    Протокол уровня представления

6.4.1    Общие положения

Протокол уровня представления позволяет согласовать абстрактный синтаксис (например, выбрать между MDDL и CMDISE ASN.1) и синтаксис передаваемых данных (т. е. оптимизированные правила кодирования, например, MDER) между системами.

Что касается протокола сеансового уровня, для поддержки ACSE необходимы некоторые ограниченные стандартные службы.

Основной дополнительной возможностью уровня представления является согласование синтаксиса во время ассоциации. Также это позволяет определить точки многоканальной передачи (идентификаторы контекста представления) в приложении, которые в свою очередь позволяют осуществлять передачу данных в различных форматах в рамках одной ассоциации [например, для формирования изображений и обмена ими в медицине (стандарт DICOM)]. В подобной ассоциации можно поддерживать несколько контекстов представления одновременно.

При нормальной связи медицинских приборов (после ассоциации), требований к обработке данных и обмену сообщениями для уровня представления должно быть как можно меньше.

6.4.2    Службы уровня представления

Уровень представления предоставляет, например, следующие службы:

-    Подключение уровня представления (Connect presentation);

-    Принятие подключения уровня представления (Connect presentation accept);

-    Предоставление данных (Presentation data).

6.4.3    Сообщения уровня представления

Определения следующих блоков PDU см. в приложении Е:

-    Подключение уровня представления (CP) PPDU;

-    Принятие подключения уровня представления (CPA) PPDU;

-    Отклонение подключения уровня представления (CPR) PPDU;

-    Протокол аварийного разъединения по инициативе провайдера (ARP) PPDU;

-    Протокол аварийного разъединения по инициативе пользователя (ARU) PPDU;

-    Предоставление данных (TD) PPDU.

6.5    Протокол ROSE

6.5.1    Общие положения

Служебный элемент дистанционной операции (ROSE) использует общий протокол обмена информацией между медицинскими приборами (CMDIP). Он обеспечивает связь между сообщениями вызова и сообщениями результата (т. е. между запросами и ответами) с помощью полей идентификаторов вызова. Он также содержит поле, необходимое для отличия различных удаленных операций (в данном случае — сервисов CMDISE).

ROSE использует тот же абстрактный синтаксис, который рассматривается для применения в CMDIP и структур данных из ИСО/ИИЭР 11073-10201. Поэтому для соблюдения ограничений оптимизированных правил кодирования ASN.1 необходимо внести некоторые модификации в ROSE ИСО/ВОС.

6.5.2    Службы ROSE

Протокол ROSE является относительно простым протоколом, определяющим следующие службы (сервисы):

-    Вызов удаленной операции (Remote operation invoke);

-    Результат удаленной операции (Remote operation result);

-    Ошибка удаленной операции (Remote operation error);

-    Отклонение удаленной операции (Remote operation reject).

13

6.5.3 Определения сообщений протокола ROSE

Определения ROSE PDU см. в приложении Е.

6.6 Протокол CMDISE (CMDIP)

6.6.1    Общие положения

6.6.2    Сервисы CMDISE

В зависимости от масштабируемости (профили минимальной, базовой и расширенной масштабируемости имеют разные требования) прикладными профилями медицинских приборов (MDAP) могут предоставляться следующие основные службы:

-    Возвращение значения атрибута объекта (Retrieve object attribute value);

-    Модификация значения атрибута объекта (Modify object attribute value);

-    Вызов заданных функций объекта (Invoke object defined functions);

-    Создание и удаление экземпляров объекта (Create and delete object instances);

-    Создание отчетов о событиях, произошедших внутри объекта (Report events that occurred within an object).

Параметры каждой из служб и соответствующие результаты определены в языке данных медицинских приборов (MDDL). В таблице 4 приведен пример службы event report (отчет о событии).

Таблица 4 — Параметры службы event report

Параметр Описание Invoke identifier Идентификатор вызова. Уникальный идентификатор (например, номер последовательности) назначается для конкретного экземпляра службы так, чтобы его можно было отличить от вызовов других служб, которые может разрабатывать поставщик услуг Mode Режим. Подтвержденный или неподтвержденный; неподтвержденный режим требует ответа Object class Класс объекта. Определяет класс объекта, генерирующего событие (значения определены в номенклатуре или глоссарии) Object instance Экземпляр объекта. Определяет экземпляр объекта, который генерирует событие Event time Время генерации события Event type Определяет тип события (значения определены в номенклатуре или глоссарии) Event information Дополнительная информация о событии согласно типу параметра события; информация о событии определяется объектом, генерирующем событие (опционально)

6.6.3    Определения сообщений CMDIP

Определения типов данных ASN.1 для всех служб CMDIP определены в приложении Е. Необходимо отметить, что некоторые параметры служб CMDISE, определенные в языке MDDL, могут быть отображены на ROSE. В частности, идентификатор вызова и параметры режима в действительности определены в ROSE, как описано в 6.5.

Примеры блоков PDU приведены в приложении Е.

6.6.4    Простой сетевой протокол времени SNTP См. приложение С.

7 Информационная модель

7.1 Модель объекта

Настоящий подраздел содержит определения классов объектов, которые в основном содержат следующие классы:

- коммуникационный контроллер (СС), например коммуникационный контроллер прибора (DCC), прикроватный коммуникационный контроллер (ВСС);

14

ГОСТ Р 56844-2015/ISO/IEEE 11073-20101:2004

- база управляющей информации (MIB).

-Для получения подробной информации об определении см. информационную модель предметной области (DIM).

7.2 Модель формата

7.2.1    Синтаксис

7.2.1.1    Синтаксис передаваемых данных

Синтаксис передаваемых данных определен в приложении А.

Отображения на ИСОАСН.1 приведены в приложении G.

7.2.1.2    Абстрактный синтаксис

Абстрактный синтаксис определен в приложении Е.

7.2.2    Совместимость

Как правило, желательно поддерживать обратную синтаксическую совместимость (совместимость с предыдущими версиями), особенно для синтаксиса передачи данных, хотя такая совместимость не всегда возможна. Настоящий подраздел предназначен для выявления существенных вопросов совместимости и их разрешения в целях содействия реализации. См. таблицу 5.

Таблица 5 - Проблемы совместимости

Случай Вопрос Решение 1 Совместимость версий 1988/90 и 1994 ИСО АСН.1 и смежных правил кодирования (серия ИСО/МЭК 8824, серия ИСО/МЭК 8825) 1.1 Тип ANY DEFINED BY изменен; см. приложение Н для получения дополнительной информации 1    АБСТРАКТНЫЙ СИНТАКСИС. Модули должны соответствовать требованиям ИСО/МЭК 8824-1; см. приложение Н 2    СИНТАКСИС ПЕРЕДАЧИ ДАННЫХ. MDER для ANY DEFINED BY или типа instance-of должны быть идентичными (см. приложение А)

8 Соответствие

Настоящий раздел предназначен для определения критериев соответствия.

8.1    Область применения

Чтобы в наибольшей степени обеспечить гибкость и интероперабельность реализации, область соответствия реализации в настоящем базовом стандарте ограничивается протоколами. Тем не менее профили приложений, в случае необходимости, могут устанавливать определения служб.

8.2    Администрирование идентификатора объекта

Настоящий стандарт выделяет административные полномочия идентификатора объекта для других стандартов, особенно для языка MDDL. Управление полномочиями требует обращения сначала к набору MDAP, а затем к спецификациям расширений, определенных более широким стандартом.

8.3    Соответствие подмножества MDAP

Профили MDAP должны определить степень соответствия с настоящим стандартом с помощью следующих категорий исключения:

а)    отсутствие исключений. Подмножество не принимает никаких исключений к настоящему стандарту;

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

15

8.4 Соответствие реализации

Разработчики устройства могут не указывать соответствие настоящему стандарту, но необходимо указать соответствие профилю, который ссылается на настоящий стандарт. Как было отмечено в 8.1, соответствие реализации должно быть ограничено протоколами, и, хотя определения интерфейсов прикладных программ (API) несут справочный характер, они подходят для задачи облегчения повторного использования компонентов реализации.

16

ГОСТ Р 56844-2015/ISO/IEEE 11073-20101:2004

Приложение А (обязательное)

Правила кодирования медицинских приборов (MDER)

А.1 Общие положения

Настоящее приложение определяет специализированные правила MDER, связанные с представлением последовательных двоичных строк, таким образом, каким они должны быть представлены в сети в сравнении с соответствующей организацией в памяти компьютера, с представлением в абстрактном синтаксисе, то есть в языке программирования или диаграмм, которые используются в спецификациях. Предполагается, что данная спецификация должна быть согласована с любой и каждой из альтернатив нижнего уровня ИСО/ИИЭР 11073. Таким образом, реализация на верхних уровнях может обеспечивать прозрачность на основе конкретного профиля нижнего уровня.

Основные цели MDER включают в себя возможность оптимизировать выполнение форматирования и синтаксического анализа, а также снижает нагрузку на пропускную способность сети. Оптимизация форматирования основана на возможности процессора передачи данных определять так называемые сообщения с фиксированным форматом (canned), в которые только динамически изменяемые данные должны быть включены для относительно высокочастотных сообщений, в особенности это касается данных осциллограмм.

А.2 Поддерживаемый синтаксис ASN.1

ASN.1 является стандартным обозначением, которое используется для определения типов данных, значений и ограничений значений. Данное обозначение широко используется в стандартах ВОС и в серии стандартов ИСО/ИИЭР 11073 (например, в ИСО/ИИЭР 11073-10201, где все определения данных формируются с помощью ASN.1).

В целях выполнения требований эффективности кодирования и декодирования и поддержки сообщений с фиксированным форматом, MDER определяет методы для преобразования синтаксиса ASN.1 в поток байтов, пригодный для передачи.

В отличие от других стандартов ИСО/ВОС для правил кодирования ASN.1 (например, основные правила кодирования или BER, правила компактного кодирования или PER) правила MDER оптимизированы только для подмножества ASN.1. Правила MDER не поддерживают полный набор типов данных ASN.1, а лишь определенный ограниченный набор конструкций ASN.1.

Стандарты ИСО/ИИЭР 11073 используют этот ограниченный набор ASN.1 для определения типов данных, применяемых только в управляемых медицинских объектах, таким образом, правила MDER подходят и являются достаточными для кодирования структур данных в рамках этих стандартов.

Ограниченный набор ASN.1, используемый для компонентов PDU стандартов ИСО/ИИЭР 11073, является строгим подмножеством допустимых типов данных ASN.1, поэтому другие общие стандартные правила кодирования (например, BER, PER) можно также использовать, как согласованные для конкретного профиля коммуникаций на более высоких уровнях.

Таблица А.1 определяет специализацию ASN.1, подходящую для кодирования MDER. Все компоненты ASN.1 PDU, предназначенные для кодирования MDER, являются предметами этой специализации.

Для каждого типа данных ASN.1 эта специализация сопровождается символом «I» для включенного с ограничением, «R» —для ограничений по использованию и «Е» — для исключения.

Более подробную информацию о специализации типов ASN.1 в MDER см. в приложении Н.

Таблица А.1 —Типы данных, поддерживаемые ASN.1

Тип ASN.1	Статус	Комментарии
INTEGER	R	Целочисленный тип. Размерные ограничения должны быть использованы для всех типов данных INTEGER, для определения диапазона значений целого числа. Краткие имена для поддерживаемых типов ограничений определяются следующим образом: INT-U8 ::= INTEGER(0..255) INT-I8 ::= INTEGER (-127..128) INT-U16 ::= INTEGER (0..65535) INT-116 ::= INTEGER (-32768..32767) INT-U32 ::=INTEGER (0..4294967295) INT-132 ::= INTEGER (-2147483648..2147483647) Только сокращенные, ограниченные по размеру типы данных INTEGER следует использовать с определениями типов данных для кодирования в MDER

ГОСТ Р 56844-2015/ISO/IEEE 11073-20101:2004

Содержание

1    Обзор.............................................................................................................................................................1

1.1    Область применения.............................................................................................................................1

1.2    Назначение............................................................................................................................................2

1.3    Цели........................................................................................................................................................2

1.4    Пользователи стандарта ......................................................................................................................2

2    Нормативные ссылки...................................................................................................................................2

3    Термины, определения и сокращения .......................................................................................................3

3.1    Термины и определения.......................................................................................................................3

3.2    Сокращения...........................................................................................................................................4

4    Условные обозначения.................................................................................................................................6

5    Обоснование.................................................................................................................................................6

5.1    Коммуникационная модель...................................................................................................................6

5.2    Информационная модель.....................................................................................................................7

6    Коммуникационная модель..........................................................................................................................7

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

6.2    Сервисный элемент управления ассоциацией (ACSE)....................................................................10

6.3    Протокол сеансового уровня..............................................................................................................12

6.4    Протокол уровня представления........................................................................................................13

6.5    Протокол ROSE...................................................................................................................................13

6.6    Протокол CMDISE (CMDIP).................................................................................................................14

7    Информационная модель..........................................................................................................................14

7.1    Модель объекта...................................................................................................................................14

7.2    Модель формата..................................................................................................................................15

8    Соответствие...............................................................................................................................................15

8.1    Область применения ..........................................................................................................................15

8.2    Администрирование идентификатора объекта.................................................................................15

8.3    Соответствие подмножества MDAP...................................................................................................15

8.4    Соответствие реализации...................................................................................................................16

Приложение А (обязательное) Правила кодирования медицинских приборов (MDER)..........................17

Приложение В (обязательное) Распределение идентификаторов............................................................26

Приложение С (справочное) Временная синхронизация...........................................................................29

Приложение D (справочное) Динамическая модель..................................................................................30

Приложение Е (обязательное) Абстрактный синтаксис.............................................................................36

Приложение F (справочное) Примеры блоков PDU....................................................................................53

Приложение G (справочное) Специализация ASN.1..................................................................................67

Приложение Н (справочное) Вопросы совместимости...............................................................................70

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

и документов национальным стандартам Российской Федерации...............................72

Библиография................................................................................................................................................73

Окончание таблицы А.1

Тип ASN.1 Статус Комментарии BIT STRING R Битовая строка. Размерные ограничения должны быть использованы для всех типов данных BIT STRING, для определения диапазона значений битовой строки. Краткие имена для поддерживаемых типов ограничений определяются следующим образом: BITS-8 :: = BIT STRING (SIZE(8)) BITS-16 :: = BIT STRING (SIZE(16)) BITS-32 :: = BIT STRING (SIZE(32)) Только сокращенные, ограниченные по размеру типы данных BIT STRING следует использовать с определениями типов данных для кодирования в MDER OCTET STRING 1 Строка октет SEQUENCE R Может не использовать следующие типы тегирования: OPTIONAL (опциональный), DEFAULT (по умолчанию), автоматический SEQUENCE OF 1 Последовательность CHOICE R Выбор. Может использоваться явное и неявное тегирование ANY DEFINED BY 1 ANY DEFINED BY должен определять компонент в структуре данных (в основном в SEQUENCE), который определяет структуру этих данных для преобразователя кода/синтаксического анализатора (парсера)

А.З Порядок передачи байтов

На рисунке А.1 показано, как различные двоичные строки сети отображаются в строках памяти. На диаграммах представлен порядок передачи байтов в сети (Network byte order, NBO). Следующие правила пронумерованы для удобства использования ссылок:

-    представление в диаграммах использует формат NBO, показанный на рисунке А.1;

-    в MDER не используется выравнивание. То есть в строки байтов дополнительные байты не добавляются, например для получения длин, которые делятся на два или четыре. Тем не менее переменная длина элементов данных, то есть строк, должна содержать четное число байтов из соображений эффективности. Например, поскольку большинство элементов данных 16-битные, они не будут неправильно выровненными, если строки имеют четную длину;

-    передачи данных в MDAP ограничены использованием соглашения NBO (обратный порядок передачи);

-для обеспечения общей интероперабельности протокол ассоциации должен использовать ИСО BER при

согласовании условных обозначений MDER. Все остальные блоки PDU, которыми обменивается в период своей работы хост-устройство, будут основаны на MDER, например PDU CMIP* и ROSE*. Суффикс звездочка (*) означает, что MDER используется для оптимизации протокола ИСО, который, как правило, базируется на BER.

Многобайтовые структуры отображаются между сетью и компьютерной памятью и упорядочиваются в памяти компьютера двумя основными способами, называемыми big endian (формат с порядком следования байтов, начиная со старшего) и little endian (формат с порядком следования байтов, начиная с младшего). Формат big endian согласуется с NBO, a little endian — не согласуется. Например, в последнем примере на рисунке А.1 структура ABCD была бы упорядочена как DCBA. В этом случае если big endian является согласованным протоколом, то компьютер с little endian должен был бы переставлять компоненты этой структуры при получении их из памяти и передаче их в память, в случае необходимости. Макросы языка программирования и команды компьютера, выполняющие байтовый свопинг, которые, как правило, способствуют нормализации, являются проблемами реализации и могут быть упрощены ненормативными определениями, взятыми из настоящего стандарта или стандартов, связанных с ним.

18

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информатизация здоровья

ИНФОРМАЦИОННОЕ ВЗАИМОДЕЙСТВИЕ С ПЕРСОНАЛЬНЫМИ МЕДИЦИНСКИМИ ПРИБОРАМИ

Часть 20101 Прикладные профили. Базовый стандарт

Health informatics. Point-of-care medical device communication.

Part 20101. Application profiles. Base standard

Дата введения — 2016—11—01

1 Обзор

Настоящий стандарт содержит восемь разделов:

-    в разделе 1 описана область применения настоящего стандарта;

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

-    в разделе 3 приведены определения и сокращения;

-    в разделе 4 представлены условные обозначения;

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

-    в разделе 6 описана модель коммуникаций (т. е. протокол и сервис передачи данных);

-    в разделе 7 описана информационная модель (модель объекта);

-    в разделе 8 представлены требования соответствия.

Настоящий стандарт также содержит девять приложений:

-    в приложении А (обязательное) определены специализированные правила кодирования медицинских приборов (MDER);

-    в приложении В (обязательное) описано как распределены идентификаторы объектов;

-    в приложении С представлены ссылки на протоколы временной синхронизации, используемые в настоящем стандарте;

-    в приложении D представлены диаграммы переходов состояний для динамической модели;

-    в приложении Е (обязательное) описан абстрактный синтаксис, который предлагает расширения к стандартам, на которые опирается настоящий стандарт, такие как минимальные взаимодействия открытых систем (mOSI), которые ориентированы на настоящий стандарт.

-    в приложении F представлены примеры некоторых PDU.

-    в приложении G рассмотрены спецификации языка абстрактного синтаксиса 1 (ASN.1).

-    в приложении Н представлена информация о совместимости версий ASN.1 1988/90 г. и 1994 г.

1.1 Область применения

Область применения настоящего стандарта распространяется на сервисы и протоколы верхнего уровня (т. е. уровень приложения, уровень представления и сеансовый уровень взаимодействия открытых систем по ИСО), используемые для обмена информацией в соответствии со стандартами ИСО/ИИЭР 11073, регламентирующими коммуникации медицинских приборов (MDC).

Настоящий стандарт является базовым стандартом ИСО/ИИЭР 11073-20000 для прикладных профилей медицинских приборов (MDAP), что было согласовано с Европейским комитетом по стандартизации (ЕКС) и ИСО.

Издание официальное

1.2    Назначение

Назначением настоящего стандарта является определение приложения верхнего уровня коммуникаций медицинских приборов (MDC), т. е. профилей A-типа ИСО для обмена данными, которые определяются форматом языка данных медицинских приборов (MDDL), или же профилей F-типа ИСО (серия ИСО/ИИЭР 11073-10000).

1.3    Цели

Основная цель стандартов по прикладным профилям медицинских приборов (MDAP) — поддержать верхний уровень обмена данными между медицинскими приборами (MDC), осуществляемого на языке данных MDDL, между различными по типу и масштабу, будущими и применяемыми приборами, предназначенными для использования в местах оказания медицинской помощи (РОС) в медицинских отделениях интенсивной терапии.

1.4    Пользователи стандарта

Стандарты MDAP в первую очередь предназначены для разработчиков программного обеспечения, создающих системы коммуникаций медицинских приборов (MDC) или пытающихся создать интерфейс для взаимодействия сними.

Так как настоящая серия стандартов в основном основывается на профилях международной стандартизации, то ознакомление с соответствующими стандартами является желательным, если не обязательным условием. Рекомендуется ознакомиться, как минимум, со следующими стандартами:

a)    комплекс ИСО/ИИЭР 11073, особенно стандарт ИИЭР Стд. 1073¹), ИСО/ИИЭР 11073-10201 и стандарты нижнего уровня (например, ИСО/ИИЭР 11073-30200);

b)    по архитектуре уровней взаимодействия открытых систем ИСО, прежде всего для верхних уровней, т. е. уровней приложения, представления и сеансового;

c)    по управлению системами;

d)    по объектно-ориентированному анализу и проектированию;

e)    по теории машинных языков.

2 Нормативные ссылки

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

ИИЭР 1073 Стандарт для обмена данными между медицинскими приборами. Обзор и основы (IEEE Std 1073, IEEE Standard for Medical Device Communications — Overview and Framework²))

ИСО/МЭК 8327-1 Информационные технологии. Взаимодействие открытых систем. Протокол сеансового уровня в режиме с установлением соединения. Часть 1. Спецификация протокола (то же, что и Рекомендации сектора электросвязи МСЭ Х.225) (ISO/IEC 8327-1, Information technology — Open systems interconnection — Connection-oriented session protocol — Part 1: Protocol specification³) (same as ITU-T Recommendation X.225))

ИСО/МЭК 8650-1 Информационная технология. Взаимосвязь открытых систем. Сетевой протокол передачи с установлением соединения для протокола прикладного уровня, используемого в OSI для организации связи между двумя приложениями. Часть 1. Протокол (то же, что и Рекомендации сектора электросвязи МСЭ Х.227) (ISO/IEC 8650-1, Information technology — Open systems interconnection — Connection-oriented protocol for the association control service element — Part 1: Protocol, (same as ITU-T Recommendation X.227))

ИСО/МЭК 8824-1 Информационные технологии. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 1. Спецификация основной нотации (то же, что и Рекомендации сектора электро-

¹)    Информацию по ссылкам можно найти в разделе 2.

²)    Публикации ИИЭР доступны в Институте инженеров по электротехнике и радиоэлектронике, Хос Лэйн, Пискатавэй, NJ 08854, США (http://standards.ieee.org/).

³)    Публикации ИСО/МЭК доступны в Центральном Секретариате ИСО (Case Postale 56, 1 rue de Varembe, CH-1211, Geneve 20, Switzerland/Suisse (http://www.iso.ch/)). Также публикации ИСО/МЭК доступны в США в Global Engineering Documents (Всемирная инженерная документация), 15 Inverness Way East, Englewood, СО 80112, USA (http://global.ihs.com/).. Электронные копии доступны в США в Американском национальном институте стандартов, 25 West 43rd Street, 4th Floor, New York, NY 10036, USA (http://www.ansi.org/).

2

ГОСТ Р 56844-2015/ISO/IEEE 11073-20101:2004

связи МСЭ Х.680) (ISO/IEC 8824-1, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation (same as ITU-T Recommendation X.680))

ИСО/МЭК 8824-2 Информационные технологии. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 2: Спецификация информационных объектов (то же, что и Рекомендации сектора электросвязи МСЭ Х.681) (ISO/IEC 8824-2, Information technology — Abstract Syntax Notation One (ASN.1) — Part 2: Information object specification, (same as ITU-T Recommendation X.681))

ИСО/МЭК 8825-1 Информационные технологии. Правила кодирования языка ASN.1. Часть 1. Спецификация основных правил кодирования (BER), канонических правил кодирования (CER) и особых правил кодирования (DER) (то же, что и Рекомендации сектора электросвязи МСЭ Х.690) (ISO/IEC 8825-1, Information technology — ASN.1 encoding rules — Part 1: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). (same as ITU-T Recommendation X.690))

ИСО/МЭК) 9072-2 Системы обработки информации. Передача текста. Удаленные операции. Часть 2. Спецификация протокола (ISO/IEC 9072-2, Information processing systems — Text communication — Remote operations — Part 2: Protocol specification)

ИСО/МЭК 9595 Информационная технология. Взаимосвязь открытых систем. Определение общих услуг информации административного управления (ISO/IEC 9595, Information technology — Open systems interconnection — Common management information service definition)

ИСО/МЭК 9596-1 Информационная технология. Взаимосвязь открытых систем. Протокол общей управляющей информации. Часть 1. Спецификация (ISO/IEC 9596-1, Information technology — Open systems interconnecton — Common Management Information Protocol — Part 1: Specification)

ИСО/МЭК 9899 Языки программирования — C (ISO/IEC 9899, Programming languages — C) ИСО/МЭК 11188-3 Информационные технологии. Профиль международной стандартизации. Распространенные требования для верхнего уровня. Часть 3. Минимальные возможности верхнего уровня взаимодействия открытых систем (OSI) (ISO/IEC ISP 11188-3, Information technology — International standardization profile — Common upper layer requirements — Part 3: Minimal OSI upper layer facilities)

ИСО/ИИЭР 11073-10101 Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 10101. Номенклатура (ISO/IEEE 11073-10101 Health informatics — Point-of-care medical device communication — Part 10101: Nomenclature¹))

ИСО/ИИЭР 11073-10201 Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 10201: Информационная модель предметной области (DIM) (Health informatics — Point-of-care medical device communication — Part 10201: Domain information model (DIM))

ИСО/ИИЭР 11073-30200 Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 30200. Транспортный профиль. Приборы, подключенные кабелем (ISO/IEEE 11073-30200, Health informatics — Point-of-care medical device communication — Part 30200: Transport profile — Cable connected)

ИСО/ИИЭР 11073-30300 Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами 30300. Транспортный профиль. Инфракрасная беспроводная связь (ISO/IEEE 11073-30300, Health informatics — Point-of-care medical device communication — Part 30300: Transport profile — Infrared Wireless)

Рекомендации сектора электросвязи МСЭ Х.681. Информационные технологии. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 2: Спецификация информационных объектов (то же, что и ИСО/МЭК 8824-2) (ITU-T Recommendation Х.681, Information Technology—Abstract Syntax Notation One (ASN.1) — Information Object Specification (same as ISO/IEC 8824-2)^{2 3})

3 Термины, определения и сокращения 3.1 Термины и определения

В настоящем стандарте применяются следующие термины и определения. Для получения информации о терминах, не указанных в данном разделе, см. [3].

3.1.1    абстрактный синтаксис (abstract syntax): Спецификация структуры элемента данных, которая не ссылается или не содержит требования к конкретной технологии реализации.

3.1.2    обратный порядок байтов (big endian): Последовательность передачи байтов, при которой наиболее старший байт передается первым. Например, при передаче 32-битового целого числа первым передается наиболее старший байт (24-31 бит), а последним — самый младший байт (0-7 бит).

3.1.3    порядок следования байтов (byte order): Последовательность, в которой многобайтные простейшие элементы данных передаются в блоке данных протокола (PDU). Например, 32-битовое целое число содержит 4 байта. См. также 3.1.2.

3.1.4    объединение (coalescing): Функция объединения нескольких блоков данных протокола на уровне представлений (PPDU блоки) в один блок данных протокола на уровне сеанса (SPDU), который затем передается по коммуникационной сети.

3.1.5    правила кодирования (encoding rules): Спецификация преобразования простейших элементов данных, используемых в абстрактном синтаксисе, в формат реализации. В основном повторяет синтаксис передаваемых данных.

3.1.6    связанный ответ (linked reply): Ответ на команду, для передачи данных которого требуется более одного блока данных протокола (PDU). Например, отдельная команда выборки всего системного журнала может привести к получению нескольких, связанных между собой ответов от блоков данных протоколов, которые предоставляют запрашиваемую информацию¹).

3.1.7    значения данных уровня представления (presentation data value — PDV): Объединение множеств значений во всех возможных абстрактных синтаксисах.

3.1.8    синтаксис передачи (transfer syntax): Спецификация структуры данных, во время их передачи в коммуникационной или физической среде.

3.2 Сокращения

В дополнении к сокращениям стандарта ИИЭР 1073 в настоящем стандарте используются следующие сокращения:

АА    —    преждевременное прекращение (сеанса) принято (SPDU);

AARE    —    сообщение ответа на ассоциацию;

AARQ    — сообщение запроса ассоциации;

АВ    — преждевременное прекращение (сеанса) (SPDU);

ABRT    — преждевременное прекращение (APDU);

АС    — (сеанс) принят (SPDU);

ACSE    —    сервисный элемент управления ассоциацией (связью);

АЕ    — прикладная сущность;

АР    — прикладной процесс;

APDU    —    блок данных протокола прикладного уровня;

API    —    прикладной программный интерфейс;

ARP    — аварийное разъединение по инициативе поставщика услуг (PPDU);

ARU    — аварийное разъединение по инициативе пользователя (PPDU);

ASN.1    —    абстрактная синтаксическая нотация версии    1;

ВСС    —    прикроватный коммуникационный контроллер;

BER    — основные правила кодирования;

СС    — коммуникационный контроллер;

CMDIP — общий протокол обмена информацией между медицинскими приборами;

CMIP    —    протокол общей управляющей информации;

CMISE — сервисный элемент общей управляющей информации;

¹¹ Определение «связанной команды» (linked command) и описание ее поддержки в настоящем стандарте не рассматриваются. Данная команда требует, чтобы несколько блоков данных протокола передавали необходимую информацию. Например, команда передачи перечня наименований лекарственных средств в медицинский прибор может потребовать передачи нескольких связанных блоков данных протокола. Данная команда может быть добавлена в следующие редакции стандарта, если это потребуется другому профилю и стандартам на вспомогательный пакет услуг.

4

ГОСТ Р 56844-2015/ISO/IEEE 11073-20101:2004

—    сервисный элемент общей информации о медицинских приборах;

—    соединение на уровне (сеанса) (SPDU);

—    соединение на уровне представления (PPDU);

—    принятие соединения на уровне представления (PPDU);

—    отказ соединения на уровне представления (PPDU);

—    коммуникационный контроллер прибора;

—    формирование цифровых изображений и обмен ими в медицине;

—    интерфейс прибора;

—    информационная модель предметной области (см. ИСО/ИИЭР 11073-10201);

—    отключение (сеанса) (SPDU);

—    передача данных (сеанса) (SPDU);

—    завершение (сеанса) (SPDU);

—    модель или машина конечного автомата;

—    указатель длины;

—    наименее значимый бит;

—    прикладные профили медицинских приборов (сокращение MDAP может быть заменено другим сокращением из серии стандартов ИСО/ИИЭР 11073-20000);

—    нормальная передача данных прикладных профилей медицинских приборов (SPDU);

—    передаваемые данные прикладных профилей медицинских приборов (PPDU);

—    передача сервисных данных прикладных профилей медицинских приборов (SPDU);

—    коммуникации медицинских приборов или номенклатура для такого рода коммуникаций (ИСО/ИИЭР 11073-10101);

—    коммуникационный контроллер медицинского прибора;

—    язык данных медицинских приборов (сокращение MDDL может быть заменено другим сокращением из серии стандартов ИСО/ИИЭР 11073-10000);

—    правила кодирования медицинских приборов;

—    база данных медицинской информации;

—    цифровой формат медицинских приборов;

—    система медицинского прибора;

—    сервисный элемент медицинского прибора;

—    база управляющей информации;

—    минимальное взаимодействие открытых систем;

—    наиболее значимый бит;

—    максимальный передаваемый блок данных;

—    порядок передачи байтов в сети;

—    взаимодействие открытых систем;

—    блок данных протокола (также именуется как сообщение, однако PDU означает передачу через транспортный профиль, ИСО/ИИЭР 11073-30200);

—    значение данных уровня представления;

—    правила компактного кодирования;

—    идентификатор группы параметров;

—    идентификатор параметра;

—    место оказания медицинской помощи;

—    блок данных протокола уровня представления;

—    качество обслуживания;

—    отказ (сеанса) (SPDU); ⁴

4    Условные обозначения

Для обозначения специальных или оптимизированных свойств в различных определениях используются префиксные или суффиксные символы. Для указания специализованности понятия в некоторых определениях ставится звездочка (*). Например, BER* означает версию основных правил кодирования (BER), которые были специально оптимизированы для эффективности обработки данных.

5    Обоснование

Основная задача настоящего стандарта — обеспечить набор абстрактных синтаксических структур и синтаксических структур передачи данных (т. е. правил кодирования), оптимизированных для использования прикладными профилями и реализациями информационной модели предметной области (DIM).

5.1 Коммуникационная модель

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

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

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

Использование обязательных элементов или элементов постоянного формата в определениях типа данных блока данных протокола (блока PDU) позволит устройствам передачи использовать сообщения с фиксированным форматом (то есть в памяти можно заполнять шаблонное сообщение, в котором необходимо будет менять только обновляемые значения). Это также значительно снизит сложность анализа сообщения получающим устройством.

Данное требование также строго связано с требованием к оптимизированным правилам кодирования;

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

Стек протокола определяется только определениями типа (данных) PDU и динамическим поведением. Нормативное определение интерфейсов прикладных программ (API) не входит в область применения настоящего стандарта, однако для упрощения реализации и повторного использования могут быть приведены ненормативные примеры.

Желательно определить транспортно-независимый интерфейс, хотя конкретные отображения блоков PDU верхнего уровня на сервисы транспортного профиля ИСО/ИИЭР 11073-30000, при необходимости, адресуются через подуровни, зависящие от транспортного протокола.

ГОСТ Р 56844-2015/ISO/IEEE 11073-20101:2004

Могут быть рассмотрены основные механизмы уровня транспортного интерфейса для обеспечения информации и поведения, связанных с качеством обслуживания (QoS).

Подразумевается, что сложные протоколы сеансового уровня не требуются для коммуникации между медицинскими приборами, тем более что некоторые механизмы восстановления работоспособности системы после ошибки уже определены прикладными объектами, указанными в языке данных медицинских приборов (MDDL) (например, объектами scanner, т. е. «сканер»).

Однако, для поддержания стандартного сервисного элемента управления ассоциацией (ACSE) требуется минимальный набор стандартных служб сеансов (SS) ИСО/ВОС, как минимум на время ассоциации.

Кроме того, требуется определить конкретные расширения сеансового уровня для оптимизации его процессов во время нормальной передачи данных (после ассоциации), которые будут совместно выполняться с протоколом сеансового уровня, определенным в ИСО/МЭК 8327-1.

Данная оптимизация касается, например:

-    упрощения нормальных PDU уровня сеанса;

-    объединения прикладных данных в единые PDU сеансового уровня для сокращения скорости передачи сообщений на уровне транспортного интерфейса и ниже.

5.2 Информационная модель

Существуют следующие предположения и требования связанные с объектной моделью коммуникационного контроллера (СС):

-    как и объекты, определенные в языке данных медицинских приборов (MDDL), объекты, определенные в данной модели, представляют информацию, которой приборы обмениваются через коммуникационный канал. Определенные здесь объекты являются частью информационной базы медицинских данных (MDIB) (доступные прямо или косвенно), по сути, являющиеся информационными контейнерами;

-    объектная модель фокусируется на обобщенных концептах для представления возможностей коммуникационного интерфейса (варьирующихся от, например, скорости связи до общих параметров качества обслуживания (QoS)), вопросах конфигурации интерфейса и статистических данных (например, для выявления и устранения ошибок). Модель должна быть независимой от конкретных реализаций нижнего уровня, но может содержать адаптации, характерные для более низких уровней ИИЭР;

-    коммуникационный контроллер медицинского прибора (MDCC) наследует от коммуникационного контроллера (СС) язык данных медицинских приборов (MDDL), как определено в MDDL.1 (IEEE Std 1073.3.1™ [5]); для внесения ясности и удобства использования ссылок настоящий стандарт может повторять определения из этого стандарта;

-    в качестве нотации используется унифицированный язык моделирования (UML).

Атрибуты объектов и поведение будут определены в нотации, которая согласуется со стандартом языка данных медицинских приборов (MDDL), в частности в вопросах:

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

-    форм динамического представления в виде:

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

-    динамического поведения конкретных объектов, например, объектов scanner, определенных в языке данных MDDL.

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

Кроме того, для упрощения поддержки необходимо определить информационные объекты, относящиеся к управляющей информации, например, объекты конфигурации, доступа, характеристик работы и информации, связанной с отказоустойчивостью, как указано в ИСО/ИИЭР 11073-30200.

6 Коммуникационная модель

Настоящий раздел предназначен для определения служб (сервисов) и протоколов.

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

На рисунке 1 показан верхний уровень коммуникационного стека, т. е. многоуровневый набор компонентов протокола и сервиса.

7

1

^ Публикации ИСО/МЭК доступны в Центральном секретариате ИСО (Case Postale 56, 1 rue de Varembe, CH-1211, Geneve 20, Switzerland/Suisse (http://www.iso.ch/h. в США в отделе продаж Американского национального института стандартов (25 West 43rd Street, 4th Floor, New York, NY 10036, USA (http://www.ansi.ora/h и в Институте инженеров по электротехнике и радиоэлектронике (445 Hoes Lane, Piscataway, NJ 08854, USA (http://standards.ieee.org/)).

2

) Публикации ITU-T доступны в Международном союзе электросвязи (Place des Nations, CH-1211, Geneva 20, Switzerland/Suisse (http://www.itu.int/)).

3

4