Взрывной рост технологий, увеличение количества разнообразных носимых устройств и их доступность предоставляют отличные возможности для получения таких данных о здоровье и жизнедеятельности человека, о которых медицина еще 10-20 лет назад могла только мечтать. Емкость рынка программного обеспечения, позволяющего собирать данные на конечном устройстве пользователя, по оценкам экспертов составит от 15 до 20 млрд. долл. к 2023 году, а сами носимые устройства уже сегодня становятся обязательной частью страхования здоровья и планов лечения. Разумеется, не все приложения на рынке одинаково полезны, удобны, надежны и безопасны.
В этой статье мы рассмотрим, с какими проблемами приходится сталкиваться разработчикам, как расставлять приоритеты или от чего отказываться при разработке приложения для слежения за жизненными показателями пациента, на примере создания кроссплатформенного приложения для людей, страдающих хроническими заболеваниями, в частности, болезнью Паркинсона. Приложение собирает различные данные с датчиков мобильного телефона и носимых устройств (акселерометра, гироскопа, микрофона, ЭКГ сенсоров часов Apple Watch) и передает их на сервер для последующего анализа и обработки в системе машинного обучения с целью адекватной диагностики заболевания и правильного лечения.
Архитектура
Любое мобильное приложение, ориентированное на персональное использование, начинается с экрана логина. Для описываемого приложения мы выбрали авторизацию, реализованную на базе сервиса Amazon Cognito. Использование Amazon Cognito продиктовано относительной простотой использования и интуитивностью решения, которое позволяет легко добавлять регистрацию и аутентификацию пользователей в мобильные и интернет-приложения. Удобный внешний менеджмент метода авторизации пользователей с web позволяет быстро, эффективно и безопасно интегрировать механизм авторизации в приложение на серверной стороне.
Со стороны сервера интеграция сервиса даже в существующее приложение делается достаточно быстро и без затруднений. Однако мы заметили странное поведение сервиса в некоторых сетях (особенно имеющих файерволы и фильтрацию контента). Постоянное переключение с сотового Интернета на Wi-Fi иногда приводило к «протуханию» токена и требовало повторной авторизации.
Для клиентов с различными типами хронических заболеваний каждая функция приложения конфигурируется и может быть включена/отключена в зависимости от конкретной задачи. К тому же есть возможность конфигурации сенсоров данных ЭКГ, физической активности (HealthKit) и мониторинга погоды. Возможность конфигурировать функционал приложения для различных клиентов реализуется через файлы конфигурации plist (xml-подобной структуры).
Проблема кроссплатформенности мобильных приложений является весьма актуальной, ей посвящено большое количество публикаций. Существует множество подходов для ее решения, однако мы решили остановиться на не самом популярном способе, который, тем не менее, отчасти решает задачу с общей кодовой базой. Решение было продиктовано необходимостью сквозной интеграции серверных структур данных, написанных на Java, c клиентским кодом для iOS/Android. В рассматриваемом решении Android-код подключается как native, а iOS-код конвертируется утилитой. По сравнению с другими возможными решениями данный способ покрывал максимальное количество проблем, возникающих при разработке кроссплатформенных решений.
Бизнес-логика является наиболее важной и, в то же время, относительно просто конвертируемой частью приложения. Ее выделяют в отдельный модуль, написанный на Java. Для iOS-платформы эффективнее всего использовать утилиту конвертирования j2obc. Это также позволит написать общий код как для сервера, так и для клиентского приложения.
Наиболее логичным решением для интеграции логики приложения будет подключение библиотек, генерируемых после конвертации в виде artificial pods, скомпилированных на сервере ci. Таким образом, все сетевые запросы, а также обработка данных и формирование уведомлений будyт происходить на логическом уровне приложения (LL, Logic Layer), а платформенно-зависимые функции происходят в отдельных классах, написанных в виде клиента с необходимым внешним фасадом.
Вместе с тем остается проблема общей кодовой базы для приложения на часах и телефоне. Из-за ограничений в системном API операционной системы iWatch не все библиотеки могли легко портироваться на часы. Чтобы обойти это препятствие, мы решили создать механизм передачи сообщений на часы с телефона. Это решило проблему частично, но проблема с синхронной передачей данных пока до конца не решена. В случае любого беспроводного устройства вероятность ошибки в передаче данных остается более высокой, чем у проводных.
Пользовательский интерфейс
UI приложения предоставляет пациенту информацию об упражнениях, выполненных им в течении дня, о приеме лекарственных средств, а также о заполнении опросника (для сбора неметрических клинических данных), который реализован в виде списка элементов с назначенным временем действия.
Экраны упражнений, опросника и медикаментов сверстаны как страницы с историей операций. Запуск упражнений может происходить как по расписанию, так и вручную. Все упражнения могут иметь различное время выполнения. После выполнения упражнений автоматически запускается опросник для получения обратной связи от пациента. Напоминание об упражнении или опросники формируются локальными уведомлениями.
Обмен данными
Получение данных с акселерометра 24×7 с учетом возможных проблем с коммуникацией между часами и телефоном оказалось довольно сложной задачей. Для активизации сбора данных в backgrounds использовался механизм workout. Данный способ обычно используется для регистрации упражнений для фитнеса и успешно работает в фоновом режиме.
На чтение любого типа данных с сенсора телефона или часов требуется разрешение пользователя. Запуск приложения на часах осуществляется только после логина и принятия всех необходимых разрешений на телефоне. Иначе приложение на часах падает, что вызвано политиками безопасности Apple, которые требуют перезапуска при любых изменениях пользовательских разрешений на телефоне. Запуск упражнений невозможен, например, без доступа данных к мониторингу фитнеса. Об этом пользователю напомнит уведомление и банеры в приложении.
При разработке приложения для «умных» часов разработчикам нужно помнить, что максимальная загруженность CPU часов самим приложением не должна превышать определенного времени (для каждой модели часов — разного), поэтому необходимо заранее встроить прерывания, чтобы избежать системной ошибки и выгрузки приложения из памяти. Для предотвращения перегрузки процессора в качестве workaround можно запланировать запуск процесса sleep на несколько секунд, иначе пользователь столкнется с перезапуском приложения системой.
В процессе разработки мы также столкнулись с довольно интересным фактом: в WatchOS есть специальное API для получения данных с гироскопа. Тем не менее, данные можно получить только из числового массива для акселерометра.
Для обеспечения непрерывности потока данных в критических случаях разрыва соединения между телефоном и часами нам пришлось организовывать досылку данных при восстановлении соединения. К тому же, получение данных с акселерометра часов сопровождается различными проблемными случаями: тут и блокировка телефона, и телефон на зарядке, и низкий заряд батареи. Для борьбы с каждой проблемой был имплементирован механизм, позволяющий фильтровать поток данных из базы данных и запрашивать только те участки, в которых содержались данные от сенсоров.
Наш совет разработчикам: для организации извлечения данных из БД необходимо оптимизировать размер файлов для отправки с часов на телефон (мы рекомендуем не превышать 1000 записей и точно задавать интервал записи, иначе мы столкнемся с перегрузкой памяти приложения из-за ее переполнения). Передача данных c часов работает не всегда стабильно из-за коммуникационных проблем, поэтому архивация пересылаемых файлов для уменьшения их размера делает передачу более стабильной.
В процессе реализации проекта мы также столкнулись с тем, что чтение любых данных, а также данных HealthKit (сердечного ритма и физической активности пациента) нельзя выполнять в главном потоке приложения, так как объем данных за несколько дней (в зависимости от интервала) может надолго блокировать главный поток и приведет к выгрузке приложения из памяти. Перед чтением необходимо верифицировать, что экран разблокирован, иначе в соответствии с политикой безопасности Apple данные будут блокироваться.
Точность данных HealthKit также вызывает серьезные сомнения и не позволяет с медицинской точностью диагностировать состояние пациента, однако эти данные дают общую картину физической активности и состояния, что является дополнительным параметром в выборе оптимальных методов лечения и дозировки лекарств.
Новый функционал
В Apple Watch 4 уже появились новые многообещающие функции для диагностики болезни Паркинсона, что потребует подключения новых функций сбора данных с носимого устройства — и новых проектов по разработке и обеспечения стабильности ПО. В новой версии приложения планируется использование ResearchKit. Это многообещающая платформа для разработки приложений с открытым исходным кодом, которая позволяет регистрировать участников и проводить исследования.
Заключение
Новые технологии и устройства полностью меняют подход и перспективы клинических испытаний и оценки полученных результатов, а следовательно, существенно повышают качество медицинских препаратов. Все больше фармацевтических компаний понимают, что использование систем машинного обучения позволит им выйти на новый уровень разработки лекарственных препаратов, а также ранней диагностики заболеваний. Для работников отрасли здравоохранения это существенный шаг вперед — к действительно персонифицированной медицине, когда график приема лекарств, а также их воздействия формируется индивидуально для пациента. Объемы обрабатываемых данных и методы их обработки идут все дальше, и при накоплении критического размера данных это несомненно приведет к революционным открытиям в медицине, позволяющим найти лекарства от неизлечимых сейчас болезней.
Автор статьи — инженер-разработчик, «Аурига».
