Проблема совместимости медицинских устройств
Современный мир трудно представить без отраслевых стандартов, позволяющим интегрировать решения различных производителей в единую систему. Такие технологические системы могут взаимодействовать и обмениваться данным, многократно повышая производительность и удобство пользования. Примеров можно привести множество – начиная от стандартизованных информационных протоколов до международного стандарта стыковочной системы применяемой на Международной космической станции.
К сожалению отрасль здравоохранения отстает от других отраслей в обеспечении совместимых и безопасных систем и компонентов. В этой статье мы рассмотрим проблему совместимости PoC медицинских устройств и возможные пути решения.
PoC медицинские устройства
Концепция проведения диагностических тестов рядом с пациентом также известна как Point-Of-Care диагностика. Пример PoC медицинских устройств:
Глюкометр
Мониторы пациента
Аппарат ИВЛ
Мобильный рентгеновский аппарат
Аппарат гемодиализа
Совместимость медицинских устройств со сложившиейся информационной инфраструктурой медицинского учреждения
До эры открытых стандартов каждый производитель PoC медицинских устройств разрабатывал собственные проприетарные коммуникационные протоколы. Таким образом только медицинские устройства одного бренда могли беспроблемно взаимодействовать внутри больничной инфраструктуры, что ставило руководство клиник в условия сложного выбора производителя. Невозможность обеспечить безопасное и устойчивое взаимодействие устройств различных производителей привело к необходимости разработки открытых протоколов взаимодействия медицинских устройств.
Медицинская отрасль во многом консервативна, и, в отличии от, например, рынка смартфонов, где срок жизни новой модели от вывода на рынок до устаревания очень короток, медицинские устройства находятся в реальном использовани много лет, некоторые модели могут производится и использоваться десятилетиями.
На текущий момент в реальных клиниках используется большой зоопарк проприетарных устройств, которые по различным причинам невозможно быстро заменить на аналогичные по функционалу устройства с открытыми протоколами.
Идеальным решением является создание новых PoC медицинских устройств, изначально спроектированных для использования с открытыми протоколами. И хотя многие производители медицинского оборудования уже сейчас разрабатывают подобные устройства, тем не менее пройдет не мало времени пока они появятся на рынке. Так же остается открытой проблема дальнейшего использования медицинских устройств старого образца, весьма дорогих и вполне еще работоспособных.
Интегрировать же новые протоколы в уже существующие легаси устройства потребует значительных усилий, сравнимых с разработкой нового устройства с нуля. Необходимо будет заново протестировать, сертифицировать, поменять прошивку на каждом из устройств, частично парализовав работу клинику.
Разумным компромисом является разработка отдельного сервиса - конвертера протоколов позволяющего в разумные сроки обеспечить совместимость протоколов. Использование конвертеров позволит использовать старое «железо» без серьезных вмешательств в работу клиники.
Совместимость протоколов (Interoperability)
Способность двух или более устройств (разного типа, модели или производителя) обмениваться информацией (независимо от того, подключены ли они друг к другу напрямую или через систему связи) и эффективно использовать информацию, которой обменивались.
Конвертер протоколов или виртуальный мост
Промежуточным звеном между легаси PoC устройствами и новыми PoC SDC-совместимым устройствами является конвертер проприетарных протоколов, который будет связывать вместе устройства нового поколения и устаревшие в ИТ-инфраструктуре больницы.
В этой статье Аурига делится своим опытом разработки решения и проблемами, которые могут возникнуть при преобразовании проприетарных протоколов в открытый стандарт IEEE 11073 Service-oriented Device Connectivity (SDC)
Что такое SDC?
SDC был задуман и разработан OR.NET, некоммерческой организацией, объединяющей производителей медицинских устройств, клиницистов и исследователей.
SDC определяет протокол связи для PoC медицинских устройств, основная цель которого - обеспечить надежный обмен данными между медицинскими устройствами в рамках открытой IP-системы, ориентированной на безопасное и надежное взаимодействие для обеспечения безопасности пациентов.
SDC основывается на сервисно-ориентированной архитектуре (service-oriented architecture -SOA). Что такое сервисно-ориентированной архитектура? Процесс предоставления медицинских услуг можно объединить в логические единицы, например Рентген Сервис, ИВЛ Сервис и т.д.
Что такое MDIB?
В SDC широко используется понятие как MDIB – Medical Device Information Base. MDIB является описанием PoC медицинского устройства как абстрактной модели возможостей медицинскго устройства в статической описательной части и текущего состония устройства в динамической части. Для такого описания используется формат XML.
Процесс создания MDIB как модели медицинского устройства весьма сложен.
MDIB должен содержать описание всех измеряемых устройством метрик, медицинских тревог и поддерживаемых операций по удаленному изменению настроек.
Например PoC медицинское устройство измеряет частоту сердечных сокращений (Heart Rate или сокращенно HR), результатом будет numeric metric со значением текущего пульса. Так же на экране будет видна кривая каридогрммы, она же вейформа и будет представлена в MDIB соответствующей метрикой.
Метрики могут объединяться в каналы, а каналы объединяются в VMD – Virtual Medical Device. Таким образом реальное медицинское устройство делится на логические сущности, VMD, например если медицинское устройство измеряет температуру, ЭКГ и уровень сатурации, то в MDIB будет три соответствующих VMD – Temperature Monitor, ECG Monitor и SpO2 Monitor.
Если значения измеренного HR будет превышать установленный min или max, медицинское утройство сгенерирует медицинскую тревогу, medical alert. В MDIB этому соответствует Alert System.
Соответственно медцинское устройство предоставляет сервис по изменению настроек min/max, и в MDIB этому соответсвуют операции из Control Service.
Каждый объект MDIB содержит множество аттрибутов, которые необходимо корректно установить и тонко настроить.
Пример MDIB:
BodySites и PhysicalConnectors
Одним из аттрибутов метрики является bodysite, а именно часть тела пациента являющаяся источником метрики. Например температуру можно измерять подмышкой или во рту, это будет немного разная температура.
И если bodysite можно грубо представить как координату на теле пациента, то за координаты на медицинском устройстве отвечают PhysicalConnectors, например устройство может иметь несколько портов для температурных датчиков, и за каждому порту будет соответсвовать свой PhysicalConnector.
Установка аттрибутов легаси медицинского устройства в MDIB
Для корректной работы SDC протокола необходимо предварительно разработать описание легаси медицинского устройства как совокупность метрик, медицинских тревог и других аттрибутов MDIB.
PoC медицинское устройство может быть транслировано в MDIB множеством способов из-за гибкой структуры MDIB. Процесс создания MDIB может быть упрощен путем разделения на итерации, а именно необходимо:
Составить список сигналов мединского устройства на основе анализа проприетарного протокола
Составить прототип MDIB содержащим только метрки и вейформы на основе списка сигналов
Расширить описание метрик используя технические особенности мединского устройства используя такие SDC объекты как bodysites и physical connectors
Исследовать работу мединцинское устройство на различных сценариях, на основании полученных данных расширить MDIB алертами
Исследовать различные сценарии удаленного измения настроек медицинского устройства, на основании полученных данных расширить MDIB операциями контроля на основе SDC сервисов
Реализовать сложные сценарии, выявив список не покрытых SDC требования, и составив список исключений
Автогенерация зависимостей в статической части MDIB
Статическая часть MDIB содержит описание абстрактной модели медицинского устройства.
Такая модель для реальных устройств может содержать тысячи узлов, поэтому довольно сложно и дорого каждый раз искать в MDIB какие-либо зависимости во время работы конвертера протоколов. Целесообразно в целях опитимизации минизировать такие обращения к MDIB. Одним из самых удобных инструментов такой оптимизации является использование автогенеренных таблиц зависимостей.
На этапе компиляции проекта производится парсинг XML файла как описательной части MDIB, формируются таблицы зависимостей в наиболее удобном формате. Из минусов такого подхода является снижение гибкости и не возможности горячей замены MDIB, конкретная версия контвертера будет связана с конкретной версией MDIB.
Мапинг параметров легаси медицинского устройства
Довольно часто невозможен прямой маппинг 1 в 1 из легаси протокола в SDC протокол из-за особенностей легаси протокола. В таких случаях приходится прибегать к машинам состояний (конечным автоматам), где конвертер протокола хранит историю состояний легаси устройства для корректного маппинга в SDC формате.
Синхронизация времени
Проблема синхронизации стоит довольно остро, т.к. практически любое PoC медицинское устройство предоставляет метки времни (timestamps) для метрик, вейформ, мединцинских тревог в собственном проприетарном формате, а некоторые необходимые для SDC timestamp может и вовсе не предоставлять, приходится их вычислять внутри конвертера.
Пропускная способность больничной сети
В SDC сети одно PoC медицинское устройство генерирует траффика около 80 Кб/сек из-за использования XML файлов. Типичная клиника может использовать сотни PoC устройств одновременно для диагностики пациентов, так же существует не SDC траффик вроде видео звонков и т.п. Все это необходимо учитывать на этапе построения больничной сети, необходимо оптимизировать маршрутизацию SDC траффика или даже выделять отдельное оборудование для сегмента SDC сети для избежания перегрузки больничной сети.
Кибербезопаность
В больничной инфраструктуре может использоваться два типа сетей – SDC и легаси медицинского устройства. Часто легаси сети разрабатывались очень давно и не отвечают современным нормам кибербезопаности:
Отсутствие peer-to-peer аутентификации
Сообщения проприетарного протокола не зашифрованы
Отсутствие зарезервированных TCP/UDP портов и трудности в настройке Firewall
Решением проблем является изоляция легаси сегмента сети или использование бюджетного аппаратного ключа донгла во избежание пересечения с другими сетями.
Скрытые медицинские тревоги и самостоятельная генерация медицинских данных
Некоторая критически важная информация, например факт медицинской тревоги SDC формата, может отсутствовать в легаси протоколе в явном виде зарегистрированного события, но может быть установлен по косвенным признакам в результате анализа исходящего трафика медицинского устройства. Таким образом конвертер не только обеспечивает трансфер медицинских данных из одного протокола в другой, но и самостоятельно может генерировать такие данные, устанавливать факт медицинской тревоги или вычислять какие-то метрики, что может повысить класс безопасности конвертера до медицинского устройства.
Хороший пример это вычисление данных waveform усиленных отведений от конечностей aVL, aVR, aVF как линейную комбинацию стандартных отведений I, II, III:
В случае если легаси медицинское устройство измеряет и передает только основные параметры кардиограммы, конвертер протоколов может самостоятельно вычислять дополнительные параметры.
Требования к конвертеру протоколов
Конвертер протоколов должен работать автоматически и автономно без какого-либо взаимодействия с пользователем. Для всех поддерживаемых протоколов он должен выглядеть как собственное устройство, действующее как прокси (виртуальный мост).
Конвертер должен:
Определять тип устройства, версию протокола и другие важные настройки для правильной работы
Автоматически восстановливаться в случае сбоя программного или аппаратного обеспечения
Поддерживать автоматическое обнаружения устройств и hot-plug сценарии
Учитывать требования кибербезопасности, такие как шифрование, разделение сетей, white lists
Общие проблемы проприетарных протоколов
Хотя проприетарные протоколы и отличаются у различных производителей медицинских устройств, вызовы и сложности при разработке конвертеров будут в той или иной степени общими. Рассмотрим основные подводные камни конвертеров проприетарных протоколов и методы их преодоления.
Проблема №1 – Отсутствие документации
Подробное описание проприетарного протокола может отсутствовать в силу различных причин, от бюрократических проволочек и юридических запретов до банального разгильдяйства разработчиков. Как следствие возможные артефакты незадокументированного поведения медицинского устройства придется исследовать методом реверс-инжиниринга.
Проблема №2 – Сложные сценарии поведения медицинского устройства
Для разработки и тестирования медицинских устройства на рынке представлены симуляторы пациента, позволяющие прорабатывать основные состояния параметров пациента в широких диапазонах. Однако такие симуляторы пациента не позволят воспроизвести сложные сценарии поведения медицинского устройства, например такие симуляторы не позволят вопроизвести техническую неисправность самого PoC устройства, например неисправность какого-либо сенсора, клапана и мотора помпы.
Медицинское устройство как правило имеет возможности самодиагностики и предоставляет информации о технических проблемах через проприетарный протокол, и, конечно же, представляется невозможным физически разрушать устройство для таких сценариев.
Для решения этой проблемы Аурига использует симулятор медицинского устройства собственной разработки, позволяющие протестировать конвертер протокола для таких сложных технических сценариев. Симулятор устройства представляет собой сетевое приложение, моделирующие поведение медицинского устройства в проприетарном коммуникационном протоколе. Такой симулятор позволяет работать без реального медицинского устройства, что так же полезно для автоматического тестирования.
Резюме
Можно с уверенностью утверждать что область телемедицины, совместимых PoC медицинских устройств и удаленной диагностики будет иметь большой спрос в ближайшем будущем, а значит с проблемами interoperability и вызовами разработки совместимых коммуникационных протоколов столкнутся многие участники рынка.
Опыт разработки конвертеров протоколов показывает что идеи заложенные в проприетарные коммуникационные протоколы 80х-90х годов уже значительно устарели и не позволяют реализовать простой маппинг 1 в 1 в совместимые SDC протоколы. В этой статье мы рассмотрели некоторые проблемы конвертации и способы их преодоления.
