ISO/IEEE 11073 Стандарты персональных данных о здоровье

Стандарты ISO/IEEE 11073 для персональных медицинских устройств (PHD) представляют собой группу стандартов, касающихся совместимости персональных медицинских устройств (PHD), таких как весы, тонометры, мониторы уровня глюкозы в крови и т.п. Стандарты основаны на более ранней работе над стандартами IEEE11073, но отличаются от этой более ранней работы из-за акцента на устройствах для личного использования (а не для использования в больницах) и более простой модели связи.

Фон

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

Обеспокоенность тем, что несовместимые системы замедлят внедрение полезных персональных медицинских устройств, побудила к шагам по обеспечению функциональной совместимости. Continua Alliance — это группа компаний и организаций, стремящихся способствовать росту рынка личного здоровья. Они работают с IEEE Ассоциацией стандартов , а IEEE-EMBS, по персональным медицинским данным , входящая в рабочая группа 11073 разрабатывает стандарты для форматов данных и коммуникаций для обеспечения совместимости устройств.

По словам IEEE 11073-20601-2008, этот стандарт:

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

Предыдущие стандарты

Стандарты IEEE 11073 для персональных медицинских устройств. семейство основано на едином стандарте «фреймворка»:

• IEEE Std 11073-20601 — Профиль приложения — Оптимизированный протокол обмена
• IEEE Std 11073-20601a — Профиль приложения — Оптимизированный протокол обмена (поправка)

и ряд стандартов «специализации устройств» — в настоящее время существуют следующие:

• IEEE Std 11073-10404 — Специализация устройства — Пульсоксиметр
• Стандарт IEEE 11073-10407 — Специализация устройства — Монитор артериального давления
• IEEE Std 11073-10408 — Специализация устройства — Термометр
• IEEE Std 11073-10415 — Специализация устройства — Весы
• IEEE Std 11073-10417 — Специализация устройства — Глюкометр
• IEEE Std 11073-10420 — Специализация устройства — Анализатор состава тела
• IEEE Std 11073-10421 — Специализация устройства — Пиковый расход
• IEEE Std 11073-10441 — Специализация устройства — Монитор сердечно-сосудистой работоспособности и активности
• IEEE Std 11073-10442 — Специализация устройства — Оборудование для силового фитнеса
• IEEE Std 11073-10471 — Специализация устройства — Центр независимой жизнедеятельности
• IEEE Std 11073-10472 — Специализация устройства — Монитор приема лекарств

IEEE 11073-20601 — это базовый стандарт, определяющий общие типы данных, типы сообщений и модель связи. Это поддерживает любое количество (относительно небольших) стандартов «специализации устройств» (таких как стандарт IEEE 11073-10408 для термометров), которым нужно только определить модель данных для этого конкретного типа персонального медицинского устройства.

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

• IEEE P11073-10406 ​​— Специализация устройства — Базовая ЭКГ (от 1 до 3 отведений)
• IEEE P11073-10413 — Специализация устройства — Монитор частоты дыхания
• IEEE P11073-10418 — Специализация устройства — INR (свертывание крови)
• IEEE P11073-10419 — Специализация устройства — Инсулиновая помпа

Изменения в существующих стандартах:

• Стандарт IEEE 11073-10404 — Специализация устройства — Пульсоксиметр (редакция)
• Стандарт IEEE 11073-10417 — Специализация устройства — Глюкометр (редакция)
• IEEE Std 11073-10441 — Специализация устройства — Монитор сердечно-сосудистой работоспособности и активности (редакция для добавления данных 3D-акселерометра/монитора физической активности)

Архитектурный обзор

К архитектурным решениям относятся:

• Между «агентом» и «менеджером» устанавливается соединение «точка-точка».
• Независимость от транспорта (для облегчения перехода на новые каналы связи).
• Объектно-ориентированная философия (для облегчения повторного использования кода и упрощения внедрения новых устройств).
• Агенты имеют самоописание (поэтому менеджеры могут понять характеристики агентов).
• Расширяемый (для включения новых типов агентов и специализаций уже определенных агентов)
• ASN.1 используется для представления структур данных и сообщений (для упрощения анализа сообщений).

Модель системы

Общая модель системы IEEE 11073 разделена на три основных компонента, каждый из которых рассматривается отдельно в IEEE 11073-20601 и каждый из которых рассматривается более подробно далее в этой статье:

• Информационная модель предметной области представляет агента как набор объектов. Каждый объект имеет один или несколько атрибутов. Атрибуты описывают данные измерений и состояния, которые передаются менеджеру.
• Модель обслуживания предоставляет такие команды, как «Получить», «Установить», «Действие» и «Отчет о событии», которые передаются между агентом и менеджером для обмена данными из DIM.
• Модель связи устанавливает конечный автомат для Агента и Менеджера, включая состояния, связанные с соединением, ассоциацией и работой. Модель связи также преобразует абстрактное моделирование данных, используемое в информационной модели предметной области, в формат двоичного сообщения для передачи с использованием модели связи.

Деталь

Агенты и менеджеры

В стандартах IEEE 11073 PHD есть понятия «агенты» и «менеджеры». Агенты и менеджеры могут работать в шахматных архитектурах с несколькими уровнями агентов и менеджеров.

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

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

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

Транспортная независимость

Стандарты IEEE 11073 PHD определяют сообщения, которые передаются между агентом и менеджером, но не определяют, как эти сообщения должны перемещаться.

Были определены три транспорта:

Bluetooth Профиль устройства Health

USB Класс персонального медицинского устройства

Зигби Профиль здравоохранения

Другие могут быть определены в будущем.

Объектно-ориентированный

Семейство стандартов IEEE 11073 использует парадигму объектно-ориентированного управления системами. Данные (измерение, состояние и т. д.) моделируются в виде информационных объектов, доступ к которым и манипулирование ими осуществляется с использованием протокола службы доступа к объектам. Обратите внимание: это не означает, что агенты или менеджеры должны быть реализованы с использованием объектно-ориентированных языков программирования.

Такой подход обеспечивает гибкость и позволяет легко добавлять новые стандарты специализации устройств: все агенты являются экземплярами объекта «Система медицинских устройств» и содержат соответствующее сочетание других объектов, предварительно определенных стандартом структуры IEEE 11073-20601.

Самоописываемый и расширяемый

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

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

Представление данных ASN.1

Каждый объект и все его атрибуты формально определены с использованием абстрактной синтаксической нотации номер один ( ASN.1 ). ASN.1 предоставляет набор формальных правил для описания структуры объектов, которые не зависят от машинно-специфичных методов кодирования.

Объекты ASN.1 преобразуются в потоки двоичных данных с использованием правил кодирования медицинских устройств (MDER), которые являются подмножеством базовых правил кодирования (BER).Использование MDER позволяет агентам хранить предопределенные шаблоны передачи («стандартные сообщения») и изменять только фиксированное местоположение, изменяя части перед отправкой.

Модель системы более подробно

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

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

Стандарты IEEE 11073 представляют агента как набор объектов (в смысле этого слова объектно-ориентированного программирования).

Каждый объект имеет один или несколько атрибутов. Атрибуты описывают данные измерений, которые передаются менеджеру, а также элементы, которые контролируют поведение и сообщают о состоянии агента. Помимо атрибутов, объекты могут обладать методами (такими как GET и SET), с помощью которых Менеджер может взаимодействовать с Агентом. Агент может генерировать события — обычно для того, чтобы сообщить менеджеру об изменении некоторых данных.

IEEE 11073-20601 определяет эти классы (которые создаются как объекты):

• Система медицинского оборудования (MDS) – каждый агент имеет один объект MDS, который идентифицирует его и сообщает о его статусе. Атрибуты объекта MDS идентифицируют его для менеджера, представляют время и статус и предоставляют другую информацию. Тогда MDS содержит ноль или более некоторых объектов, представленных приведенными ниже классами.
• Класс метрики — это базовый класс для всех объектов, представляющих данные измерений, состояния и контекста. Однако сам класс Metric никогда не создается: скорее, он используется в качестве базового класса для классов Numeric, Real-Time Sample Array и Enumeration.

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

• Числовые – представляют собой одно измерение. Стандарт определяет две формы данных с плавающей запятой, подходящие для реальных измерений: одна содержится в 32 битах, а другая — в 16 битах. Числовой объект может возвращать данные в любом формате: либо в виде самого значения данных (если контекст позволяет определить тип измерения), либо вместе с единицами измерения и информацией о состоянии. Возможны как массивы, так и отдельные значения.
• Массив выборок в реальном времени – представляет собой непрерывные выборки или сигналы. Объект RTSA содержит информацию об интервале между выборками, количестве выборок, разрешении, а также масштабе и смещении, применяемых к каждому значению данных.
• Перечисление – представляет информацию о состоянии (коды) или аннотации (текст). Например, эти объекты можно использовать для сообщения информации о падениях, местонахождении людей в доме или условиях срабатывания сигнализации дыма.
• Постоянное хранилище метрик – представляет (в иерархическом порядке) большие объемы данных, полученных агентом. Каждый объект PM-Store содержит метаданные (данные о данных) и ноль или более PM-сегментов, содержащих данные.
• PM-Segment – ​​каждый объект PM-Segment содержит метаданные (данные о данных) и ноль или более записей: каждая запись содержит один или несколько элементов, содержащих измерения. Существует значительная гибкость в отношении данных, которые можно хранить.
• Сканер – объекты сканера могут наблюдать за измерениями, выполняемыми в Агенте, и генерировать «события» для отчета Менеджеру. События могут представлять собой регулярные отчеты или отчеты, вызванные аномальными показаниями, требующими сигнализации. Как и в случае с классом Metric, объекты сканера представлены иерархией классов. Класс Scanner никогда не создается сам по себе: скорее, он используется в качестве базового класса для класса Configuration Scanner, который, в свою очередь, является базовым классом для двух классов, экземпляры которых фактически создаются:
  • Настраиваемый сканер – никогда не создает свой экземпляр – базовый класс для:
    • Эпизодический настраиваемый сканер – эти объекты используются для отправки отчетов о данных или событиях, которые не разделены фиксированными интервалами времени.
    • Периодический настраиваемый сканер — эти объекты используются для отправки отчетов о данных или событиях, разделенных фиксированными интервалами времени.

На рисунке ниже (на основе стандарта IEEE 11073-20601) показана информационная модель домена персональных медицинских устройств IEEE 11073, выраженная в виде диаграммы классов UML. Объект MDS (и объекты, которые он содержит) принадлежат Агенту, но Менеджер может построить свое собственное представление, опрашивая Агента.

Таким образом, агент представлен как объект MDS, содержащий один или несколько объектов Metric или PM-Store (представляющих данные) и способный генерировать события через объекты Scanner.

На рисунке ниже показан практический пример: информационная модель весов, определенная стандартом IEEE 11073-10415. Это показывает, что каждые весы имеют объект MDS и числовой объект «Вес тела». Он имеет дополнительные числовые объекты массы тела и индекса массы тела.

Каждый объект и все его атрибуты формально определены с использованием абстрактной синтаксической нотации номер один ( ASN.1 ).

Модель обслуживания

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

Типы сообщений:

• Сообщения, относящиеся к установлению и разрыву «ассоциации» между Агентом и Менеджером.
• Сообщения, посредством которых Менеджер может получить доступ к информации в информационной модели домена (DIM) Агента – либо для чтения некоторых атрибутов Агента, либо для управления некоторыми аспектами его поведения.
• Сообщения, отправляемые Агентом Менеджеру, содержащие данные. Они называются «События». Сообщения о событиях могут быть инициированы Менеджером или Агентом и используются как для сообщения информации о конфигурации, так и для передачи измерений.

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

Важно отметить, что агенты могут описывать себя на этапе ассоциации (или «обнаружения»). Агент объявляет, что у него есть стандартная конфигурация, которая, вероятно, будет известна Менеджеру, или нестандартная конфигурация. В любом случае Менеджер может попросить Агента описать все его объекты (и, следовательно, его возможности) во время процесса настройки. Агенты могут быть настолько простыми или сложными, насколько того требует приложение. Таким образом Менеджер строит карту всех объектов Агента. Это обеспечивает возможность Plug and Play.

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

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

Модель связи поддерживает топологию одного или нескольких агентов, обменивающихся данными через соединения «точка-точка» с одним менеджером. Стандарты IEEE 11073 не зависят от транспорта и предполагают, что транспортный уровень (например, Bluetooth или Zigbee) может быть установлен между агентом и менеджером с помощью какого-либо механизма, выходящего за рамки стандартов.

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

Другая функция модели связи заключается в преобразовании абстрактного моделирования данных (представления объектов ASN.1), используемого в DIM, в «синтаксис передачи». Процесс преобразования, известный как Правила кодирования медицинского оборудования (MDER), берет данные, содержащиеся в объекте, и кодирует их в двоичное сообщение для отправки с использованием модели связи. (Дополнительно можно использовать другие правила кодирования.) После передачи сообщения могут быть однозначно декодированы и извлечены объекты и их данные.

Обратите внимание, что правила MDER являются подмножеством правил BER. Это представление объектов ASN.1, закодированное в MDER, по своей концепции похоже на использование XML как машинно-независимый метод обмена данными (действительно, синтаксис передачи XER передает объекты ASN.1 в XML). Однако различия заключаются в том, что сообщения MDER намного меньше, чем эквивалентные сообщения XML, и их гораздо проще конвертировать машинам во внутренние структуры данных и из них.

Примеры обмена сообщениями

В этом разделе показаны некоторые обмены данными между агентом и менеджером. Обмены, проиллюстрированные диаграммами последовательности UML, следующие:

• Агент впервые связывается с Менеджером, который не распознает его конфигурацию.
• Агент, связывающийся с Менеджером, который уже понимает его конфигурацию.
• Менеджер инициализирует объект Сканер в агенте. Агент отправляет данные по мере возникновения событий.
• Доступ к постоянному хранилищу метрик для чтения данных, которые были сохранены ранее.

Запрос на ассоциацию — агент не распознан

На приведенной ниже диаграмме последовательности UML показаны сообщения, которые обычно передаются между агентом PHD весов и менеджером IEEE 11073 (например, мобильным телефоном или ПК). Весы включаются в первый раз, и Агент (весы) отправляет запрос на ассоциацию (идентифицируя устройство как устройство IEEE 11073 PHD), но в этом примере Менеджер не распознает Агента.

Таким образом, агент отправляет отчет о конфигурации, содержащий подробную информацию обо всех содержащихся в нем объектах и ​​их статических атрибутах (в данном случае объектов «Вес тела», «Рост тела» и «Индекс массы тела»). Менеджер также запрашивает подробную информацию об объекте MDS (верхнего уровня). Все эти данные обычно сохраняются для дальнейшего использования.

Затем агент отправляет данные измерений (в отчете о подтвержденном событии), а затем отключается от диспетчера.

Запрос на ассоциацию — агент распознан

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

Затем агент отправляет данные измерений (в отчете о подтвержденном событии), а затем отключается от диспетчера.

Отчет сканера

Класс объектов Scanner — это мощная конструкция, позволяющая эффективно группировать несколькометрики в одно сообщение. Думайте о сканерах как об объектах PHD, которыеконтролировать параметры и отправлять уведомления менеджеру по мере необходимости. Сканер можетсообщать об измерениях нескольких других объектов в одном сообщении. Есть два типасканера: эпизодический (отправляет уведомление при возникновении какого-либо события) и периодический(которые отправляют уведомления через регулярные промежутки времени).

Не у всех агентов есть объекты-сканеры: у весов их нет, но можно использовать пульсоксиметры.

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

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

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

Диаграммы последовательности для эпизодических и периодических сканеров выглядят одинаково.

Доступ к постоянному хранилищу метрик

Следующая диаграмма последовательности UML описывает работу постоянного хранилища метрик (PM-Store).

PM-Store предоставляет гибкий способ реализации простых файловых систем. Не все агенты имеют объекты постоянного хранилища показателей: у весов их нет, а у пульсоксиметров — есть.

В этом случае один (или несколько) объектов PM-Store используются для хранения измерений SpO2 и частоты пульса с отметкой времени. Фактические данные содержатся в одном или нескольких объектах PM-Segment – ​​в этом случае каждый объект PM-Segment содержит данные из одного сеанса непрерывного мониторинга. Объекты PM-Store достаточно просты, чтобы данные можно было хранить очень эффективно, но при этом достаточно гибкие, чтобы их можно было использовать для хранения практически любого типа данных, которые могут измерять устройства. Как и в случае со всеми объектами IEEE 11073, агент сообщает о конфигурации объектов PM-Store и PM-Segment на этапе настройки, поэтому менеджеру не требуется предварительное знание форматов данных.

Агент заполняет элементы PM-Segment данными измерений. Менеджер опрашивает агента, чтобы выяснить, какие данные хранятся, а затем для каждого интересующего объекта PM-сегмента инструктирует агента начать отправку данных. Агент может разделить данные PM-сегмента на фрагменты управляемого размера и последовательно отправлять их в виде отчетов о событиях.

Когда менеджер благополучно получил данные от агента, он может очистить PM-сегменты для повторного использования.

Внешние ссылки

• 11073.org Веб-сайт группы стандартов IEEE 11073.
• Signove предоставляет Antidote, заархивированное 26 сентября 2011 г. на Wayback Machine , реализацию стека IEEE 11073-20601 с открытым исходным кодом.
• Continua Alliance - организация по торговле совместимыми устройствами индивидуального медицинского назначения