Кроссплатформенные SDK: мобильная разработка для здравоохранения

Kotlin Multiplatform и BLE ускоряют разработку приложений для iOS и Android и интеграцию медицинских устройств

Кроссплатформенные SDK — Источник изображения: Freepik.com

Задача и причина

Задача:

Создать SDK для интеграции мобильных приложений с медицинскими устройствами, которые передают данные по Bluetooth Low Energy (BLE). Необходимо было обеспечить:

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

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

Причина:

Клиент — компания из сферы цифрового здравоохранения, развивающая сервисы для врачей и пациентов. Для нее было критично:

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

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

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

Кроссплатформенные SDK: мобильная разработка для здравоохранения

Почему именно Kotlin Multiplatform

Главный вызов заключался в том, что Android и iOS по-разному реализуют работу с Bluetooth Low Energy. На Android есть своя библиотека и особенности API, на iOS — абсолютно другая логика взаимодействия. Если писать код раздельно, то придется вести две независимые кодовые базы, а это означает больше времени на поддержку, тестирование и развитие.

Мы сразу поняли, что такой вариант не подойдет: проект задумывался как долгосрочный, а значит, каждая новая доработка или интеграция будет множить трудозатраты вдвое. Поэтому мы выбрали Kotlin Multiplatform (KMP). Эта технология позволяет вынести бизнес-логику в общий слой и переиспользовать ее как на Android, так и на iOS. По сути, мы создаем единый центр принятия решений, а платформа отвечает только за нативное взаимодействие с железом.

Архитектура SDK

SDK мы построили по слоям.

Слой бизнес-логики (общий для Android и iOS).
Он отвечает за авторизацию пользователя, проверку прав на проведение измерений, выбор стратегии подключения и интерпретацию полученных данных. Здесь мы реализовали сетевые запросы через KTOR, хранение данных в Room и всю прикладную логику.
Слой работы с Bluetooth (разделенный на expect/actual).
Здесь мы использовали подход «expect/actual»: общий код «ожидает», что метод будет реализован, а каждая платформа дает свою «фактическую» реализацию. Так, iOS-разработчики написали модуль на Swift, Android-разработчики — на Kotlin. Для общего кода это прозрачно: он вызывает одну и ту же функцию, а дальше включается нужная реализация.
Слой парсинга данных.
Сами медицинские устройства передают информацию в виде байтовых массивов. Для Android нам удалось использовать готовый open-source парсер, а для iOS реализацию пришлось писать с нуля на Swift. Мы снова применили expect/actual, чтобы скрыть различия и сделать единый интерфейс доступа.
Слой интеграции с приложением.
Этот слой отвечает за передачу данных наружу. SDK получает байты, преобразует их в значения и передает в приложение только после того, как бизнес-логика разрешает это сделать. Таким образом, мы избежали ситуации, когда в систему попадают «сырые» или некорректные данные.

Как мы решали проблему нестандартных UUID

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

Каждый новый прибор описывается конфигурацией: какие UUID он использует, какие характеристики нужно читать и как интерпретировать байты. Конфигурация подключается к SDK как расширение. Таким образом, при появлении нового устройства нам не нужно переписывать весь код — достаточно добавить описание для конкретного производителя.

Масштабируемость решения

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

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

Результаты

В итоге мы получили SDK, который:

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

Значение для индустрии

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

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

Результат

В итоге нам удалось создать SDK, который действительно решает поставленные задачи и снимает большинство барьеров при интеграции медицинских устройств.

Созданное SDK позволило кардинально улучшить процесс интеграции медицинских устройств в цифровые продукты.

Сокращение сроков внедрения.
Если раньше интеграция одного устройства занимала от 2 до 3 месяцев, то теперь этот процесс занимает 2-3 недели. За счет унифицированной архитектуры и повторного использования компонентов SDK время ввода продукта на рынок значительно сократилось.
Снижение затрат на поддержку.
Единая кодовая база для Android и iOS позволила уменьшить дублирование кода почти наполовину. Это снизило расходы на поддержку и тестирование примерно на 40-50%.
Быстрое подключение новых устройств.
Поддержка нового прибора теперь требует всего несколько дней работы, а не недель. Достаточно описать парсер и конфигурацию UUID — и устройство готово к интеграции.
Стандартизация работы с BLE.
Весь низкоуровневый код скрыт за единым интерфейсом, что упростило интеграцию для разработчиков. Теперь прикладные команды работают с готовыми значениями, не погружаясь в детали GATT.
Экономия ресурсов клиента.
За счет снижения времени на разработку и поддержку расходы клиента уменьшились почти в два раза, а команда смогла быстрее запускать новые продукты.
Ускорение вывода продуктов на рынок.
Компания-клиент получила возможность запускать пилотные проекты в сжатые сроки, что критично для отрасли здравоохранения, где скорость внедрения напрямую влияет на доступность инноваций для пациентов.
Рост доверия и удобства.
Надежная интеграция медицинских приборов повысила качество пользовательского опыта и доверие врачей и пациентов к цифровым сервисам.