Стандарты ISO / IEEE 11073 для персональных медицинских устройств (PHD) представляют собой группу стандартов, касающихся функциональной совместимости персональных медицинских устройств (PHD), таких как весы, мониторы артериального давления, мониторы уровня глюкозы в крови и т.п. Стандарты основаны на более ранней работе стандартов IEEE11073, но отличаются от этой более ранней работы из-за упора на устройства для личного использования (а не для использования в больницах) и более простой модели связи.
Задний план
Демографические изменения (быстрое старение населения во многих промышленно развитых странах) и рост хронических заболеваний (таких как диабет и болезни сердца) заставили многих задаться вопросом, как можно использовать технологии, чтобы облегчить бремя медицинских работников и предоставить полезные инструменты для пожилые и немощные - и, в частности, как технологии могут помочь людям справиться с их условиями в их собственных домах. Это ведет к развитию «личных медицинских устройств», которые позволяют людям контролировать свое состояние в своих собственных домах и предоставлять информацию, которую такие устройства получают медицинским работникам и другим лицам, осуществляющим уход.
Обеспокоенность тем, что несовместимые системы замедлят развертывание полезных устройств для личного здоровья, побудила предпринять шаги по обеспечению совместимости. Continua Alliance - это группа компаний и организаций, стремящихся способствовать росту этого рынка личного здоровья. Они работают с IEEE ассоциацией по стандартизации , и IEEE-EMBS аффилированных 11073 Рабочей группа персональных данных Здоровья разрабатывает стандарты для форматов данных и связи для обеспечения совместимости устройств.
По словам IEEE 11073-20601-2008, этот стандарт:
... удовлетворяет потребность в открыто определенном, независимом стандарте для преобразования информационного профиля [личных медицинских устройств] в совместимый формат передачи, чтобы можно было обмениваться информацией между персональными устройствами телемедицины и вычислительными механизмами (например, сотовыми телефонами, персональные компьютеры, персональные медицинские приборы и телевизионные приставки).
Актуальную информацию о группе IEEE 11073 можно найти на 11073.org .
Предыдущие стандарты
Семейство стандартов IEEE 11073 Personal Health Device [1] основано на едином «рамочном» стандарте:
- IEEE Std 11073-20601 - Профиль приложения - Оптимизированный протокол обмена
- IEEE Std 11073-20601a - Профиль приложения - Оптимизированный протокол обмена (поправка)
и ряд стандартов "специализации устройств" - в настоящее время существуют следующие:
- IEEE Std 11073-10404 - Специализация устройства - Пульсоксиметр
- IEEE Std 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 - Специализация устройства - МНО (свертывание крови)
- IEEE P11073-10419 - Специализация устройства - Инсулиновая помпа
Изменения существующих стандартов:
- IEEE Std 11073-10404 - Специализация устройства - Пульсоксиметр (пересмотренный)
- IEEE Std 11073-10417 - Специализация устройства - Глюкометр (пересмотренный)
- IEEE Std 11073-10441 - Специализация устройства - Сердечно-сосудистое состояние и монитор активности (исправление для добавления данных трехмерного акселерометра / монитора физической активности)
Архитектурный обзор
Архитектурные решения включают:
- Между «агентом» и «менеджером» устанавливается двухточечное соединение.
- Независимость от транспорта (для облегчения перехода на новые каналы связи).
- Объектно-ориентированная философия (для облегчения повторного использования кода и упрощения внедрения новых устройств).
- Агенты описывают себя сами (чтобы менеджеры могли понять характеристики агентов).
- Расширяемый (для охвата новых типов агентов и настраиваемых специализаций уже определенных агентов)
- ASN.1 используется для представления структур данных и сообщений (для упрощения анализа сообщений).
Системная модель
Общая модель системы IEEE 11073 разделена на три основных компонента, каждый из которых рассматривается отдельно в IEEE 11073-20601, и каждый из которых более подробно рассматривается далее в этой статье:
- Информационная модель домена представляет агента как набор объектов. У каждого объекта есть один или несколько атрибутов. Атрибуты описывают данные измерений и статуса, которые передаются менеджеру.
- Модель обслуживания предоставляет такие команды, как Get, Set, Action и Event Report, которые отправляются между агентом и менеджером для обмена данными из DIM.
- Модель связи устанавливает конечный автомат для Агента и Менеджера, включая состояния, связанные с подключением, ассоциацией и работой. Коммуникационная модель также преобразует абстрактное моделирование данных, используемое в информационной модели предметной области, в двоичный формат сообщения для передачи с использованием коммуникационной модели.
Деталь
Агенты и менеджеры
В стандартах IEEE 11073 PHD есть понятия «агенты» и «менеджеры». Агенты и менеджеры могут работать в шахматной архитектуре с несколькими уровнями агентов, а также менеджеров.
- Агенты - это индивидуальные медицинские устройства и, как правило, небольшие недорогие устройства с батарейным питанием, которым не хватает дисплеев и других пользовательских интерфейсов.
- Менеджеры, как правило, представляют собой небольшие компьютеры или смартфоны с большими вычислительными ресурсами и необходимыми возможностями маршрутизации для автономной передачи информации от источника доставки к названному классу приемников.
Все коммуникации между агентами и менеджерами предпочтительно являются мобильными и автономными, поскольку медсестра, несущая пациента, сама является мобильным субъектом. Когда агенты передают свои данные более способным менеджерам, они могут обрабатываться и отображаться на менеджерах, а затем, возможно, передаваться через Интранет лицам, осуществляющим уход за людьми, и специалистам в области здравоохранения. Передача через Интернет технически возможна, но с меньшим уровнем безопасности и защиты конфиденциальности данных.
Стандарты предполагают, что каждый агент общается с одним менеджером одновременно. Менеджер может общаться с более чем одним агентом. Связь является двунаправленной, чтобы обеспечить безопасность транзакций. Менеджер может иметь возможность поддерживать свою собственную копию объектов (данных) переданного агента, однако многоуровневая серверная архитектура обеспечивает юридически безопасное архивирование.
Транспортная независимость
Стандарты IEEE 11073 PHD определяют сообщения, которые перемещаются между агентом и менеджером, но не то, как эти сообщения должны перемещаться.
Были определены три транспорта:
Профиль устройства Bluetooth Health |
Класс USB- персонального медицинского устройства |
Профиль здравоохранения ZigBee |
Другие могут быть определены в будущем.
Объектно-ориентированный
Семейство стандартов 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 Class - это базовый класс для всех объектов, представляющих измерения, статус и данные контекста. Однако сам класс метрики никогда не создается: скорее, он используется как базовый класс для классов Numeric, Real-Time Sample Array и Enumeration.
Для каждого объекта есть ряд атрибутов - некоторые обязательные, а некоторые необязательные. Эти атрибуты включают отметки времени, описательные строки, срок действия и единицы измерения.
- Числовой - представляют собой единичное измерение. Стандарт определяет две формы данных с плавающей запятой, подходящие для реальных измерений: одну, содержащую 32 бита, а другую - 16 бит. Числовой объект может возвращать данные в любом формате и либо как само значение данных (если контекст позволяет вывести тип измерения), либо вместе с единицами измерения и информацией о состоянии. Возможны как массивы, так и одиночные значения.
- Массив выборок в реальном времени - представляет непрерывные выборки или формы сигналов. Объект RTSA содержит информацию об интервале между выборками, количестве выборок, разрешении, а также масштабе и смещении, применяемых к каждому значению данных.
- Перечисление - представляет информацию о состоянии (коды) или аннотации (текст). Например, эти объекты могут использоваться для сообщения информации о падениях, местонахождении людей в доме или условиях дымовой сигнализации.
- Постоянное хранилище показателей - представляет (в иерархическом порядке) большие объемы данных, которые были получены агентом. Каждый объект PM-Store содержит метаданные (данные о данных) и ноль или более PM-сегментов, которые содержат данные.
- PM-Segment - каждый объект PM-Segment содержит метаданные (данные о данных) и ноль или более записей: каждая запись содержит один или несколько элементов, содержащих измерения. Существует значительная гибкость в отношении данных, которые могут быть сохранены.
- Сканер - объекты сканера могут наблюдать за измерениями, которые выполняются в Агенте, и генерировать «события» для сообщения Менеджеру. События могут быть обычными отчетами или отчетами, вызванными аномальными показаниями, которые заслуживают тревоги. Как и в случае с классом Metric, объекты сканера представлены иерархией классов. Сам класс Scanner никогда не создается: скорее, он используется как базовый класс для класса Configurable 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-Segment инструктирует Агента начать отправку данных. Агент может разделить данные PM-сегмента на части управляемого размера и последовательно отправлять их в виде отчетов о событиях.
Когда Менеджер безопасно получил данные от агента, он может очистить PM-сегменты для повторного использования.
Рекомендации
- ^ Для поиска опубликованных стандартов по запросу «11073» в IEEE, http://shop.ieee.org/ieeestore Архивировано 11 июля 2007 г.на Wayback Machine или ISO, http://www.iso.org/iso/search. htm? qt = 11073 & searchSubmit = Search & sort = rel & type = simple & published = true (каталог магазина ISO). Стандарты ISO и CEN можно приобрести в вашей национальной организации по стандартизации или в книжном магазине (например, AFNOR, BSI, DIN, JIS, UNI и т. Д.).
Внешние ссылки
- 11073.org Веб-сайт группы стандартов IEEE 11073
- Разработка стандарта для личных медицинских устройств на основе 11073 Малкольма Кларка (Кларк М., Богиа Д., Хассинг К., Стеубесанд Л., Чан Т., Айягари Д. Conf Proc IEEE Eng Med Biol Soc. 2007 ; 2007: 6175-7.)
- Continua Alliance - организация по торговле интероперабельными персональными медицинскими приборами
- Для совместных (IEEE / ISO / CEN) опубликованных стандартов в различных форматах выполните поиск «11073» по адресу:
- IEEE ; ISO ; или CEN
- Опубликованные стандарты можно приобрести в вашей национальной организации по стандартизации (например, AFNOR, BSI, DIN, JIS, KATS и т. Д.) Или в книжном магазине.
- Испанский "OPENHEALTH PROJECT" предоставляет некоторые инструменты FLOSS (бесплатные бесплатные проекты с открытым исходным кодом).
- Signove предоставляет Antidote , реализацию стека IEEE 11073-20601 с открытым исходным кодом.
- ZigBee обеспечивает поддержку IEEE 1073 через профиль здравоохранения ZigBee (ZHCP).