По данным на 2024 год, количество активных IoT-устройств в мире достигло 18 млрд. По прогнозам, к 2030 году эта цифра превысит 40 млрд устройств во всем мире. С учетом общих тенденций свою долю рынка получат и медицинские IoT-устройства, которые уже сейчас меняют подход к медицине, смещая фокус с лечения заболевания на его профилактику.
В этой статье расскажем о медицинских IoT-устройствах медицинской компании СберЗдоровье, особенностях их разработки и способах обеспечения кибербезопасности.
Материал подготовлен по мотивам доклада CISO и CIO компании СберЗдоровье — Дмитрия Тараненко и Андрея Руднева соответственно.
Начнем с контекста
СберЗдоровье — MedTech-компания №1 в России, которая предоставляет пользователям разные цифровые медицинские сервисы и услуги, включая онлайн-консультации, запись к врачу, на анализы и инструментальные обследования, а также дистанционный мониторинг пациентов с хроническими неинфекционными заболеваниями, корпоративное медицинское обслуживание. Компания выпускает и медицинские устройства для удаленного осмотра пациента врачом в рамках онлайн-приёмов:
На каждом из них остановимся подробнее.
Умный тонометр
Умный тонометр — девайс, который автоматически передает результаты измерений давления врачу-кардиологу в режиме реального времени через мобильное приложение. В случае отклонения показателей от нормы врач сам связывается с пациентом и принимает ряд мер, чтобы нормализовать его состояние – корректирует терапию или рекомендует предпринять экстренные меры.
От обычных тонометров его отличает ряд особенностей, среди которых:
сопровождение врачом-кардиологом с возможностью отслеживать динамику результатов измерений;
возможность обнаружения аритмии и отклонений, а также распознавания показаний с помощью алгоритмов компьютерного зрения / ML-моделей;
русскоязычная озвучка голосом Сергея Бурунова для улучшения пользовательского опыта.
Умный стетоскоп
Умный электронный стетоскоп — девайс, с помощью которого можно сделать аудиозапись дыхания, сердечных тонов и поделиться ею с врачом в мобильном приложении в рамках онлайн-консультации. То есть устройство позволяет врачу уже сегодня удаленно послушать сердце и легкие пациента.
Примечательно, что в устройстве применены алгоритмы ИИ, которые позволяют оперативно выявлять потенциальные отклонения и аномалии результатов от нормы.
Умные камеры здоровья
Умная камера здоровья предназначена для удаленного осмотра пациента врачом в ходе онлайн-консультаций. При помощи этого гаджета можно сделать фотографии или видеозапись внутренних полостей горла и носа, ушей и передать их врачу для оценки состояния и дальнейших рекомендаций.
Камеры представлены в двух версиях: для взрослых и детей.
Среди особенностей девайсов — поддержка Wi-Fi 2.4 для передачи данных на смартфон и наличие встроенных ИИ-ассистентов, которые помогают провести осмотр (сделать фото и видео) более качественно и информативно для лечащего врача.
ИИ «под капотом»
Для реализации умных функций как на уровне девайсов, так и мобильных приложений мы применяем искусственный интеллект для решения разных задач. Остановимся на основных сценариях их применения.
Распознавание значений. В нашем приложении доступен умный ИИ-ассистент, который способен распознавать значения, например, тонометра, с помощью камеры или голосового ввода. То есть достаточно навести камеру телефона на тонометр или произнести результаты вслух, и показания будут занесены в приложение, а после, если необходимо, — отправлены врачу. Это значительно упрощает пользовательские сценарии, что особенно актуально для пользователей старших возрастных групп.
Повышение информативности собираемых данных. При работе с умными камерами здоровья крайне важно делать качественные фотографии и четко выполнять конкретные инструкции — например, последовательно фотографировать разные зоны слухового прохода с разных ракурсов. Поэтому мы внедрили ИИ-помощника, который в формате простой навигации помогает пользователям делать нужные снимки и сразу проверяет их качество и информативность. Благодаря этому мы исключаем ситуации, при которых к врачу попадают изображения, на основании которых нельзя провести дистанционный осмотр, и пациент вынужден переделывать фотографии.
Быстрая поддержка пациентов. Для удобства пациентов мы внедрили в приложение цифровой помощник на базе LLM GigaChat, который может ответить на медицинские вопросы в разрезе информационной поддержки и без постановки диагноза, а также помочь с интерпретацией показаний устройств. Важно, что помощник учитывает контекст — он работает с историческими данными каждого пациента, чтобы выявлять отклонения от типичных значений и упростить сбор анамнеза для лечащего врача.
Примечание: Помимо прочего, мы сейчас тестируем и другие сценарии использования ИИ в связке со своими продуктами.
Почему это сложнее, чем кажется: специфика медицины
На первый взгляд, описанные сценарии использования IoT и ИИ могут показаться типовыми: сбор данных, их передача и анализ. Однако в медицинском контуре подобные решения существенно сложнее, чем в большинстве других отраслей.
Во-первых, ключевое отличие — уровень ответственности. Если в немедицинских IoT-сценариях (например, умный дом) ошибка может привести к снижению пользовательского опыта, то в медицине некорректная интерпретация данных может повлиять на здоровье пользователя. Это накладывает ограничения на использование ИИ: модели не могут выступать как источник окончательных медицинских решений и должны работать в формате поддержки врача и пациента.
Во-вторых, важна валидность и воспроизводимость данных. Любые измерения — давление, звуки дыхания или визуальные данные — должны быть получены в контролируемых условиях. Поэтому значительная часть логики системы направлена не на анализ данных, а на обеспечение их качества (через подсказки, проверки и ограничения сценариев).
В-третьих, медицинские решения работают с чувствительными персональными данными, что требует строгого соблюдения требований безопасности. Это влияет на архитектуру: от выбора каналов передачи данных до размещения ИИ-моделей и логирования и других аспектов кибербезопасности.
В-четвертых, существует регуляторная специфика. Даже если продукт не является медицинским изделием, он работает в сфере здравоохранения, где к цифровым сервисам предъявляются повышенные требования к качеству, безопасности и способам представления медицинской информации. Поэтому при разработке необходимо тщательно прорабатывать формулировки, функциональность и пользовательские сценарии, а также проводить дополнительные медицинские и юридические проверки, что увеличивает объем работ и влияет на сроки вывода продукта.
Наконец, важным фактором является интеграция с медицинским контуром. Медицинские IoT-устройства должны не просто собирать данные, а встраиваться в процесс оказания медицинской помощи: передавать информацию врачу, помогать в сборе анамнеза и снижать нагрузку на систему здравоохранения.
Снижение количества очных визитов
Одним из ключевых эффектов внедрения медицинских IoT-устройств является снижение необходимости в очных визитах к врачу.
За счет регулярного дистанционного мониторинга показателей (давление, дыхание, визуальные осмотры с помощью умной камеры) врач получает возможность наблюдать динамику состояния пациента без необходимости его физического присутствия. Это особенно важно для пациентов с хроническими заболеваниями, где критична не разовая консультация, а постоянный контроль.
Использование ИИ-помощника дополнительно снижает нагрузку на медицинскую систему:
помогает пользователю корректно собрать данные;
предварительно структурирует информацию;
позволяет отфильтровать типовые вопросы и ситуации, не требующие немедленного вмешательства врача.
В результате очные визиты смещаются из категории «регулярных и профилактических» в категорию «обоснованных и необходимых», что:
повышает эффективность работы врачей;
снижает нагрузку на клиники;
улучшает пользовательский опыт за счет сокращения времени на получение помощи, снижения тревожности.
При этом важно отметить, что такие решения не заменяют врача, а выступают как инструмент повышения доступности и качества медицинской помощи
Интеграция с приложением
Архитектурно решение строится как связка edge-устройств, мобильного приложения и backend-платформы. В этой архитектуре мобильное приложение выступает связующим звеном, обеспечивая взаимодействие устройств с backend и ИИ-сервисами, а также первичную обработку и контроль качества данных на стороне клиента.
Все IoT-устройства СберЗдоровья интегрированы с мобильными приложениями под Android и iOS для реализации основных пользовательских сценариев. При этом добавление медицинских IoT-гаджетов в мобильные приложения — довольно нетривиальная задача. Так, мы на своем опыте столкнулись с несколькими вызовами.
OS Permissions
Чтобы иметь возможность работать с медицинскими данными, передаваемыми с наших устройств, нам нужно получать от Android и iOS много разрешений (permissions), а после — донести их до пользователей. Но запрос большого количества разрешений — не всегда оптимальный сценарий, поскольку необходимо объяснять Apple и Google зачем нужны разрешения, особенно при работе с медицинскими данными.
Поэтому основной задачей для нас было найти баланс, при котором:
запрашиваются все разрешения;
нагрузка на пользователя минимальна;
приложение успешно проходит проверки и релизится в магазины Android и iOS.
Тестирование
Наши устройства используют либо Bluetooth, либо Wi-Fi. Соответственно, нам было важно протестировать корректность работы девайсов с технологиями беспроводной передачи данных на разных платформах.
С iOS проблем не возникло — благодаря унификации операционной системы на устройствах разной версии, тестирование не требует больших ресурсов и более прогнозируемое.
С Android всё несколько сложнее, поскольку могут значительно отличаться не только используемые версии операционной системы, но и аппаратные конфигурации устройств, на которых она установлена. Это требовало от нас более сложной, комплексной подготовки к тестированию, чтобы обеспечить корректность работы приложения на всех смартфонах.
SDK
При обеспечении интеграции мы также сталкивались со сложностями. Так, в наших девайсах частично использовался самописный SDK, частично — SDK, поставляемый с устройствами.
Во-первых, это осложняло выбор SDK и требовало внимания к качеству и безопасности.
Во-вторых, добавление SDK в приложение увеличивало его размер и замедляло загрузку, что для нас недопустимо.
Поэтому нам пришлось разработать и внедрить архитектурные решения, которые позволили реализовать сложный функционал, сохранив компактный размер приложения, его производительность и высокий уровень безопасности. Благодаря этому пользователи получили современный ИИ-функционал без ухудшения пользовательского опыта и без компромиссов в вопросах защиты данных.
BLE vs WIFI
При разработке устройств нам пришлось выбирать между Bluetooth и Wi-Fi.
Например, умная камера для здоровья передает видео- и фотоизображения. При этом фото можно отправить по Bluetooth, но для видео нужна потоковая передача для записи и отправки данных врачу.
Потоковая передача видео возможна, но сильно ограничена с Bluetooth версии 5.0 и на практике мало используется, но мы не можем гарантировать, что на всех пользовательских устройствах будет поддержка Bluetooth 5.0.
Поэтому для качественной передачи видео мы использовали Wi-Fi и построение точек доступа. Это заняло много времени, но обеспечило надежное соединение для передачи медицинских данных.
Другие «подводные камни» на нашем пути
Помимо сложностей интеграции и выбора стека, в процессе мы решали и сопутствующие задачи.
Блокировка Wi-Fi. Сценарии использования наших устройств предполагают, что воспользоваться ими можно в любых условиях, в том числе в офисах. Поэтому на этапе тестирования мы старались проверить большинство вариантов и потенциальных локаций. Во время тестов в офисе оказалось, что устройство не подключается к Wi-Fi. Так, у каждого девайса есть свой SSID (Service Set Identifier), который выступает точкой доступа. И эту точку доступа начала глушить общая офисная сеть. Причина оказалась в конфликте названия сети SSID — после перехода на другой формат названия проблема была решена.
Предотвращение ошибок в SDK. Чтобы после интеграции SDK не сталкиваться с инверсиями (например, когда при попытке выключить фонарик, он включается, камера делает зеркальные снимки и не только), нам пришлось погружаться на уровень SDK и вносить некоторые коррективы.
Динамика развития прошивок. Разработка медицинского IoT-устройства предполагает длительные циклы создания продукта и его тестирования. В связи с этим, по мере развития устройств и расширения их возможностей, нам требовалось несколько раз кардинально менять прошивку.
Настройка чувствительности и калибровка измерений. В медицинских IoT-устройствах важно минимизировать любые погрешности. Например, от точности настройки нашего тонометра зависит корректность измерений, а от калибровки стетоскопа — наличие посторонних шумов. Это не стало для нас проблемой или неожиданностью, но потребовало значительных усилий и затрат времени.
Оптимизация пользовательского пути. Изначально для подключения устройств надо было выполнить немало действий. Например, в случае умной камеры это: найти нужную точку доступа, получить разрешение, вернуться в приложение и только после сделать фотографии.
Такой путь мог создавать трудности для пользователей. Поэтому мы оптимизировали процесс и сократили пайплайн первого подключения до трех экранов внутри приложения, а для последующих подключений — до двух.
Обеспеспечение безопасности IoT-устройств
Поскольку наши устройства предполагают работу с медицинскими данными, особо важной задачей для нас было обеспечить высокий уровень защиты от киберугроз на всех уровнях. Нюанс в том, что действующих общепринятых регламентов в части безопасности IoT крайне мало. Так, есть:
первый международный стандарт промышленного интернета вещей, на базе технического комитета (ТК) по стандартизации 194 «Киберфизические системы» Росстандарта при поддержке Минпромторга России;
стандарт от Европейского института телекоммуникационных стандартов (European Telecommunications Standards Institute, ETSI);
стандарт от Национального института стандартов и технологий США (National Institute of Standards and Technology, NIST) и Международной организации по стандартизации (International Organization for Standardization, ISO).
Вместе с тем, вышеперечисленные стандарты недостаточно информативны в части описания возможных рисков и эффективных алгоритмов защиты от них. Поэтому при обеспечении безопасности во время использовании своих устройств мы решили опираться на специализированный OWASP Internet of Things Project.
Примечание: Проект OWASP IoT призван помочь производителям, разработчикам и потребителям лучше понять проблемы безопасности, связанные с Интернетом вещей, и дать возможность принимать более взвешенные решения в области безопасности при создании, развертывании или оценке технологий IoT.
Так, OWASP TOP 10 относит к основным следующие угрозы безопасности IoT.
Слабые, предсказуемые и жестко закодированные пароли. Использование уязвимых к брутфорсу, публично доступных (например, из инструкции) или неизменяемых паролей, включая бэкдоры в прошивке или клиентский софт, который дает возможность неавторизованного доступа к системе.
Небезопасные сетевые подключения. Избыточные или небезопасные подключения (особенно с доступом к Интернету) могут компрометировать конфиденциальность, целостность/аутентичность или доступность информации или предоставить возможность неавторизованного удаленного контроля над устройством.
Небезопасные интерфейсы экосистем. IoT-устройства подключаются к приложениям, а приложения, в свою очередь, — к облачному серверу. Таким образом, недостаточная защита интерфейсов может привести значительному увеличению периметра для кибератак.
Отсутствие безопасного механизма обновлений. Наличие уязвимостей в пайплайнах обновления. Но здесь важно понимать, что многие IoT-устройства, в том числе медицинские, могут иметь ограничения в обновлениях или иметь очень сложные механизмы обновления.
Использование небезопасных или устаревших компонентов. Использование стоковых прошивок и компонентов внешних поставщиков, при котором компетенции и инструменты для обновления и поддержки остаются на стороне внешней команды.
Недостаточная защита приватности. Персональные данные пользователей хранятся на устройстве или в экосистеме, которые используются небезопасным или ненадлежащим образом, или без соответствующих на то прав.
Небезопасная передача и хранение данных. Отсутствие шифрования или контроля доступа к чувствительной информации внутри экосистемы – при хранении, передаче или обработке.
Отсутствие возможности настройки устройства. Отсутствие поддержки безопасности устройств, выпущенных в производство, включая управление обновлениями, безопасное снятие с эксплуатации, системный мониторинг, средства реагирования.
Небезопасные настройки по умолчанию. Устройства или системы, которые поставляются с небезопасными заводскими настройками или без возможности ограничить изменения конфигурации пользователями, чтобы повысить защищенность системы.
Отсутствие физической защиты. Отсутствие физической защиты позволяет потенциальному злоумышленнику получить доступ к чувствительной информации, которая может быть полезна при удаленной атаке или для получения контроля над устройством.
Фреймворк для защиты IoT-устройств
На основе выделенного перечня основных угроз безопасности IoT мы смогли сформулировать фреймворк проверки защищенности IoT-устройств на всех уровнях, которым, в том числе, пользуемся при тестах устройств СберЗдоровья.
Проверка защиты аппаратной части
Защищенность аппаратной части устройств можно оценивать с помощью комплекса проверок, среди которых:
тест уязвимости портов UART, JTAG и SWD;
оценка возможности использования протоколов шины SPI и I2C для атаки на встроенные устройства IoT;
проверка возможности взлома прошивки.
Проверка безопасности радиоканалов
Также проверяется защищенность радиоканалов. Так, важно убедиться, что выстроена защита на случай:
атаки на системы RFID, такие как чтение и клонирование карт доступа;
атаки на протокол Bluetooth Low Energy;
злоупотребления Wi-Fi Direct и распространенных атак на точки доступа Wi-Fi;
захвата и декодирования LoRa и LoRaWAN пакетов.
Проверка защиты на уровне сети
Работа устройств в сети предполагает проведение проверок и на этом уровне. Здесь, в зависимости от специфики самого IoT-девайса, могут понадобиться:
оценка сети, в том числе корректность переключения VLAN в сетях IoT, идентификации IoT-устройств в сети, работы MQTT-брокеров;
анализ сетевых протоколов, в том числе тестирование незнакомых сетевых протоколов, например, DICOM (используется в медицине для отправки изображений) на наличие уязвимостей, бэкдоров и других рисков;
проверка конфигурации сети и возможности атак на UPnP, mDNS, DNS-SD и WS-Discovery.
Проверка защиты на уровне экосистемы IoT
Как правило, экосистемы IoT имеют довольно большую поверхность атаки. Поэтому подход к проверке безопасности на этом уровне должен быть комплексным. Например, надо проверять возможность:
взлома приложений с учетом текущих угроз, проблем безопасности SDK на двух мобильных платформах;
взлома серверной части с учетом текущих угроз, проблем безопасности API, облачной инфраструктуры, серверов и ИИ.
Проверка защиты на уровне Android и iOS-приложений
Помимо прочего, важной задачей является контроль защищенности самих Android и iOS-приложений. Для этого рационально опираться на три стандарта:
OWASP MASVS (Mobile Application Security Verification Standard) — стандарт проверки безопасности мобильных приложений, который определяет требования и критерии безопасности, которым должно соответствовать мобильное приложение.
OWASP MASWE (Mobile Application Security Whole-Enteredprise) (теперь MAS Mobile Application Security) — дорожная карта безопасности мобильных приложений. Предоставляет практические руководства и рекомендации по реализации требований MASVS и организации процессов безопасной разработки (SDLC).
OWASP MASTG (Mobile Application Security Testing Guide) — руководство по тестированию безопасности мобильных приложений. Содержит подробные методики, инструкции и примеры для ручного и автоматизированного тестирования безопасности мобильных приложений (iOS/Android) на соответствие требованиям MASVS.
Проверка защиты на уровне веба и API
Аналогичный чек-лист есть и для проверки веб-версий ресурсов. Так, в своей практике при выстраивании безопасности на уровне веба и API, мы учитываем два фундаментальных документа:
OWASP Top 10 - 2021 — базовый стандарт веб-безопасности, охватывающий универсальные угрозы для приложений.
OWASP Top 10 API Security Risks – 2023 — специализированный стандарт для безопасности API, выделяющий критические угрозы, характерные именно для API.
Перспективы развития медицинских IoT-устройств
Медицинские IoT-устройства способны сделать качественный контроль состояния здоровья простым и доступным в любой момент без лишних походов в медицинское учреждение и сложных манипуляций.
Причем потенциал развития у медицинских IoT-устройств значительный. Например, уже появляются устройства, способные в домашних условиях проводить анализ мочи, неинвазивно измерять уровень сахара в крови, оценивать комплексное состояние здоровья на основе ИИ-анализа и не только.
Более того, уже сейчас активно применяется подход medicine in the pocket, который предполагает, что все базовые медицинские обследования можно пройти с помощью одного девайса. В качестве базы для реализации такого подхода используется технология rPPG (remote photoplethysmography, бесконтактная фотоплетизмография), которая может определять ряд показателей здоровья на основе анализа пульсации вен на лице.
Например, у СберЗдоровья уже есть партнерское решение, которое способно справиться с подобными задачами – с его помощью для комплексной оценки состояния здоровья достаточно одного взгляда в камеру.
Примечание: В приложении СберЗдоровья каждый пользователь может пройти бесплатную экспресс-оценку здоровья с помощью медицинского ассистента GigaDoc, используя камеру мобильного телефона.
Всего за 15 секунд сканирования лица система оценивает 9 ключевых показателей здоровья. Среди них — уровень стресса, средний уровень глюкозы, пульс, давление, холестерин. В случае отклонения показателей от нормы приложение подскажет план дальнейших действий, который включает дополнительную диагностику и консультацию врача, чтобы как можно скорее предпринять необходимые меры по сохранению здоровья.
Инструмент также позволяет узнать об индивидуальных рисках развития таких социально-значимых заболеваний, как сердечно-сосудистые, атеросклероз, артериальная гипертензия и сахарный диабет II типа и вовремя предотвратить их развитие.
Ключевые выводы
Исходя из динамики подключения IoT-устройств можно сделать вывод, что умные девайсы вполне успешно справляются с большим пулом поставленных задач в разных сферах – например, в производстве, логистике, ритейле, строительстве. Свою нишу они заняли и в сфере цифровой медицины, причем с большим потенциалом роста возможностей и сценариев применения.
При этом ключевым условием успешного развития IoT в медицине является не только развитие умных технологий, но и учет всей специфики в части обрабатываемой чувствительной информации, потенциальных рисков, пользовательских паттернов.
Медицинские IoT-устройства в связке с ИИ формируют новый слой цифровой медицины — continuous healthcare, где взаимодействие с системой происходит не эпизодически, а постоянно.
Именно поэтому основным вызовом становится не разработка отдельных функций, а построение устойчивой, безопасной и масштабируемой платформы, способной работать с медицинскими данными в реальном времени.
Вместе с тем, опыт СберЗдоровья показывает, что при основательном подходе реально создать действительно полезный, прогрессивный, безопасный продукт, который позволит не только лечить, но и предварительно оценивать состояние организма, чтобы помочь человеку как можно раньше выявить заболевание и снизить риски развития осложнений.