CC BY
21
УДК 004.414, 004.415
DOI: 10.14529/cmse210403
ОРГАНИЗАЦИЯ ОБМЕНА ДАННЫМИ В РАМКАХ ПЛАТФОРМЫ МОБИЛЬНОЙ МЕДИЦИНЫ
(454080 Челябинск, пр. им. В.И. Ленина, д. 76), 2Научно-исследовательский центр Энсенады (22860 Энсенада, Мексика, Carretera Ensenada — Tijuana No. 3918) E-mail: volkovia@susu.ru, gleb.radchenko@susu.ru, chernykh@cicese.mx Поступила в редакцию: 03.11.2021
Мобильная медицина является важной составляющей для реализации постоянного мониторинга здоровья, который открывает для врачей, пациентов и исследователей новые возможности. Экспоненциальный рост сферы привел к увеличению скорости появления новых решений на рынке здравоохранения и, соответственно, к увеличению количества информации о здоровье населения. Однако сегодня практически вся собираемая сервисами мобильной медицины информация изолирована друг от друга, так как распределена по разным сайтам и мобильным приложениям. Отсутствие у пользователя возможности удобно управлять своими медицинскими данными и делиться ими является существенной проблемой на текущий момент. Создание платформы мобильной медицины позволит решить данную проблему, предлагая механизмы на основе которых сторонние разработчики могут размещать свои сервисы и организовывать меж-сервисный обмен данными пользователей. В рамках нашей работы мы провели анализ существующих решений на рынке мобильной медицины, описали варианты использования сервисов в сфере мобильной медицины. Нами предложена концепция платформы мобильной медицины и проведено сравнение способов организации обмена медицинскими данными. На основе проведенного анализа нами был выбран и реализован прототип системы обмена медицинскими данными между мобильными клиентами на основе однорангового (peer-to-peer) соединения.
Ключевые слова: умное здравоохранение, мобильная медицина, мониторинг здоровья, платформа, PaaS, интернет вещей, мобильные приложения.
Волков И.А., Радченко Г.И., Черных А.Н. Организация обмена данными в рамках платформы мобильной медицины // Вестник ЮУрГУ. Серия: Вычислительная математика и информатика. 2021. Т. 10, № 4. С. 37-59. Б01: 10.14529/сш8в210403.
Введение
Современная медицина сталкивается со множеством проблем, связанных с увеличением потребности населения в использовании услуг системы здравоохранения [1]. Данные проблемы вызваны ростом числа населения; повышением средней продолжительности жизни; ростом числа пожилых людей, за которыми требуется уход и наблюдение [2]; ростом стоимости медицинских услуг, что особенно сильно сказывается на больных хроническими заболеваниями [3]; а также урбанизацией городов, что увеличивает шансы на возникновение в них эпидемий, приводящих к резким скачкам количества пациентов, которым требуется медицинская помощь [4].
Считается, что данные проблемы возможно решить, применяя современные технологии и подходы к лечению пациентов. Предоставление пациентам возможности принимать активное участие в отслеживании своего здоровья и управления им, потенциально может
ОБРАЗЕЦ ЦИТИРОВАНИЯ
помочь децентрализовать уход за здоровьем, что позволит снизить нагрузку врачей и увеличить эффективность проводимого лечения [5].
Мобильная медицина сегодня является одним из ключевых подходов, обеспечивающих решение задач в области здравоохранения. В настоящее время ведется большое количество исследований в области мобильной медицины (Mobile health, mHealth), ориентированных на методики использования мобильных технологий для постоянного мониторинга и воздействия на состояние пациента [6]. Решения мобильной медицины генерируют большое количество данных, которые могут быть использованы как самими пациентами, так и их лечащими врачами, родственниками или независимыми исследовательскими группами. Данные, генерируемые одним таким решением могут достигать объема в несколько гигабайт за один день только с одного устройства [1].
Существующие сегодня решения в области мобильной медицины не предоставляют универсальных кросс-платформенных механизмов организации обмена медицинскими данными из различных источников. Большое число приложений и сервисов мобильной медицины сегодня собирают данные в своих проприретарных форматах, без возможности универсального обмена этими данными как с другими приложениями так и с заинтересованными сторонами. Растущее количество медицинских данных и их источников вызывает необходимость в платформе, которая могла бы обеспечить удобную и безопасную обработку и обмен такими данными.
Активный рост рынка информационных технологий в сфере здравоохранения показывает, что исследования в данной сфере являются актуальными. Согласно [7], данный рынок должен был вырасти с 99.6 миллиардов долларов в 2010 году до 162.2 миллиардов долларов к 2015 году. Сейчас, возвращаясь к тому же источнику мы можем видеть, что на 2019 год данный рынок составляет 187.6 миллиардов и ожидает роста до 390.7 миллиардов долларов к 2024 году [8]. Таким образом, мы можем наблюдать экспоненциальный рост данного рынка в предыдущие десять лет, и данный тренд только сохранится в следующем десятилетии.
Авторами данной статьи реализовано и развивается решение в области мобильной медицины, обеспечивающее поддержку пациентов, больных сахарным диабетом: "DiaMeter — Ваш дневник диабета" [9, 10]. Анализ пожеланий пользователей данного решения также дает основания для того, чтобы считать задачу организации обмена и обработки медицинских данных актуальной.
Целью данной работы является исследование методов организации обмена данными в контексте мобильной медицины, с учетом требований к приватности и других ограничений, накладываемых спецификой предметной области. Для реализации цели нам необходимо решить следующие задачи:
- провести анализ существующих решений на рынке мобильной медицины, в том числе в контексте возможных механизмов обмена данными;
- выявить ключевых акторов и варианты использования механизмов обмена данными в мобильной медицине;
- провести анализ возможных вариантов организации обмена данными с учетом функциональных требований;
- спроектировать и реализовать прототип решения обмена медицинскими данными.
Дальнейший текст статьи организован следующим образом. В разделе 1 мы проводим
обзор существующих решений в области мобильной медицины, рассматриваем примеры использования мобильной медицины компаниями и анализируем варианты стандартизации
решений обмена данными мобильной медицины. В разделе 2 мы даем определение платформе мобильной медицины, обсуждаем концепцию работы платформы, приводим анализ вариантов использования решений в области мобильной медицины и выводим из него варианты использования платформы мобильной медицины. В разделе 3 нами представлен анализ подходов по организации обмена данными в рамках платформы мобильной медицины. В разделе 4 мы приводим описание прототипа решения, обеспечивающего обмен медицинскими данными между мобильными клиентами на основе однорангового (peer-to-peer) соединения. В заключении представлены обобщенные результаты работы, а также перспективные направления развития данной темы.
1. Обзор решений в области мобильной медицины
1.1. Мобильная медицина
В настоящее время ведется большое количество научно-исследовательских работ в области мобильной медицины, ориентированных на методики использования мобильных технологий для постоянного мониторинга и воздействия на состояние пациента [6]. В статье [11] мы представили анализ предметной области и пришли к заключению, что мобильная медицина включает в себя не только технологии, связанные с мобильными приложениями, но и технологии интернета вещей, периферийных устройств, компьютерного зрения и телемедицины. Мобильная медицина включает в себя множество областей, среди которых выделяют [12]:
- носимые сенсоры — браслеты, часы, головные повязки, пластыри, наушники и одежда, обеспечивающие пассивный и постоянный мониторинг биометрических показателей человека;
- лаборатории на чипе (микросистемы полного анализа) — это миниатюрные приборы,
позволяющие осуществлять один или несколько многостадийных (био) химических
2 2
процессов на одном чипе площадью от нескольких mm2 до нескольких cm2 и использующие микро- или наноскопические количества образцов для пробоподготовки и проведения реакций;
- интеллектуальный анализ изображений — высокое качество камер смартфонов позволило использовать их для диагностики фотометрических показателей как с использованием дополнительных приборов (например, для распознавания ушной инфекции с помощью отоскопа), так и без них.
1.2. Постоянный мониторинг здоровья
Интернет медицинских вещей (Internet of Medical Things, IoMT) — это отдельная категория Интернета Вещей, отличительной особенностью которой является использование сенсоров с целью мониторинга и контроля здоровья пациентов [13]. Такие сенсоры позволяют собирать и обрабатывать важные биометрические данные о здоровье человека в режиме реального времени.
В статье [14] основной современной технологией, обеспечивающей рост сферы мониторинга состояния здоровья и возможность его массового внедрения выделяют незаметные (или ненавязчивые) сенсорные и носимые устройства (Unobtrusive sensing and wearable systems). Наиболее часто измеряемые с помощью таких устройств жизненные показатели включают в себя: ЭКГ, баллистокардиограмма (БКГ), частота сердечных сокращений, артериальное давление (АД), насыщение крови кислородом (SpO2), уровень глюкозы в крови,
температура тела, осанка и физическая активность. Основное отличие данных медицинских устройств заключается в возможности интегрировать их в повседневную жизнь пользователя так, что данные устройства не только не будут нарушать обычный распорядок дня человека, а наоборот давать ему преимущества в виде отображения детальной информации о разных аспектах его здоровья на экране мобильного устройства. Благодаря этому появляется возможность в автономном и регулярном режиме не только собирать и хранить важные данные о здоровье человека на протяжении длительного промежутка времени, но и анализировать их, сравнивать с данными других пациентов и помогать врачам принимать быстрые решения в зависимости от текущих показателей.
В статье [15] с помощью такого подхода авторы предлагают решение, позволяющее следить за распорядком дня и поведением пожилых людей с целью выявления у них аномального поведения без вмешательства в их жизнь. Такое решение может помочь в уходе за пожилыми людьми с деменцией или болезнью Альцгеймера, которые живут одни.
1.3. Проблемы технологий в сфере мобильной медицины
В настоящий момент уровень внедрения носимых устройств не может предоставить достаточный уровень детализации информации о здоровье человека для получения точных интерпретаций. Хотя уже были зафиксированы случаи, когда собираемая с носимых устройств информация помогала спасти человека [16], для реализации подробного анализа состояния здоровья человека необходим сбор более специфичных данных.
Основной проблемой в данной сфере на текущий момент является отсутствие механизмов согласования разнородной информации, собираемой различными приложениями с различных сенсоров. Пользователи устанавливают на устройство несколько приложений, каждое из которых хранит и обрабатывает данные в своем формате без возможности обмена этой информацией друг с другом.
С помощью приложения Apple Health ("Здоровье") компания Apple частично решает эту проблему, однако это коммерческий продукт, разработанный под экосистему компании Apple, что ограничивает возможность использования данного сервиса сторонними организациями. Сама кампания Apple при этом не обязывает разработчиков медицинских приложений реализовать интерфейсы для обмена данными с HealthKit [17]. Разработчики при этом не получают больших преимуществ от использования Apple Health, так как он не предоставляет пользователю глубокого анализа хранящихся в приложении данных, а разработчики не имеют возможность передавать эти данные куда-либо кроме этого приложения.
Так как сейчас большинство приложений разрабатываются одновременно как под систему iOS, так и под систему Android, отсутствие возможности обмениваться данными между этими платформами ведет к необходимости разработки собственных веб-сервисов, которые будут отвечать за хранение и обработку получаемых данных. К тому же, решение Apple накладывает на пользователей ограничение в выборе используемых ими смартфонов и носимых устройств и не позволяет в реальном времени получать доступ к этим данным лечащим врачам или родственникам.
При этом нужно учитывать, что различные носимые устройства могут генерировать существенные объемы данных, вплоть до нескольких гигабайт за один день только с одного устройства [1]. Конечно, не все полученные данные необходимо передавать по сети в чистом формате, однако увеличение числа носимых устройств и генерируемой ими инфор-
мации ведет к необходимости создания соответствующей сетевой архитектуры, которая бы могла стабильно, надежно и своевременно передавать полученные данные заинтересованным лицам.
Так же, учитывая стремительный рост и появление новых технологий сферы мобильной медицины, важно учитывать и влияние доступности этих технологий на самих пациентов. Так, усиливающееся желание людей делиться своими персональными данными, в том числе и медицинскими, может привести к непредвиденным последствиям и является чрезвычайно рискованным. До появления мобильных технологий невозможно было так легко собирать ежедневную информацию о состоянии пациента. Существуют риски, что тНеа1Л-платформа может быть использована не для тех целей, которые планировались ее создателями [18]. Поэтому к предоставляемой возможности и данным, получаемым с ее помощью, нужно относиться с максимальной осторожностью.
1.4. Стандартизация подхода к реализации решений мобильной медицины
На данный момент существует множество решений в сфере мобильной медицины и большинство разрабатывается с нуля. Такой подход к разработке приводит к отсутствию согласованности разрабатываемых систем и сложности их интеграции друг с другом.
Существуют исследования, которые ориентированы на решение данной проблемы. Авторы статьи [19] предлагают архитектуру для создания систем по мониторингу пациентов посредством внешних устройств с целью получения уведомлений о тревожных состояниях здоровья и составления отчетов о состоянии пациента. Они разделяют компоненты системы на четыре уровня: сенсорный уровень, уровень восприятия, гибридный уровень обработки и уровень уведомлений (см. рис. 1). Авторы данной архитектуры разделяют модули не по функционалу, а по порядку, в котором эти модули должны друг с другом взаимодействовать. Основным преимуществом такой архитектуры выделяют возможность настройки системы под требования для конкретного случая и возможность использования с различным набором правил и сенсоров.
Рис. 1. Архитектура системы мониторинга пациентов
2. Анализ вариантов использования для платформы Мобильной медицины
2.1. Понятие платформы мобильной медицины
В рамках нашей работы мы рассматриваем платформу мобильной медицины как программную инфраструктуру, обеспечивающую взаимодействие между конечными потребителями медицинских услуг (пациентами), поставщиками медицинских услуг (медиками) и исследовательскими коллективами, занимающимися анализом медицинских данных в различных целях (исследователи). Платформа должна обеспечивать возможность следующих вариантов использования
- анонимизированный сбор, хранение и анализ медицинских данных, полученных с использованием средств мобильной медицины и медицинского интернета вещей, как на краевых устройствах конечных пользователей, так и средствами туманных и облачных вычислительных систем;
- поддержку взаимодействия между пациентом и медиком, предоставляя возможности индивидуализации путем предоставления исторической информации о медицинских данных пациента;
- предоставление механизмов сбора анонимизированных медицинских больших данных для проведения различного рода медицинских исследований на большом числе пациентов;
- предоставление API для подключения новых мобильных приложений и средств мобильной медицины и медицинского интернета вещей.
2.2. Концепция маркетплейса
В статье [11] мы рассмотрели существующие технологии и платформы, используемые в области мобильной медицины. На основании проведенного анализа мы пришли к выводу, что на данный момент на рынке не существует решения, предоставляющего универсальные кроссплатформенные возможности по созданию собственного сервиса в сфере мобильной медицины для разработчиков. В качестве модели взаимодействия пользователей с данным сервисом можно выделить принцип двустороннего маркетплейса, где сервис предоставляет пользователям возможности платформы с заранее определенной структурой построения данных и взаимодействия с ними, с которой компании могут интегрироваться для решения своих внутренних задач или для предоставления своих услуг, а пациенты могут получать услуги от компаний, не зависящих друг от друга, но предоставляющих свои услуги в одном месте и в заранее согласованном системой формате. Аналогом данного решения можно привести такие платформы, как:
- Coursera, на которой независимые преподаватели размещают свои курсы, доступные для всех посетителей сайта;
- AppStore, на котором независимые разработчики размещают свои приложения, доступные для всех пользователей iOS;
- Alexa Skills Kit [20], позволяющая независимым разработчикам создавать свои сценарии разговора с голосовым помощником, которыми могут воспользоваться владельцы колонок Amazon Echo.
Платформа мобильной медицины может предлагать аналогичный сценарий использования (см. рис. 2), являясь основой, на которой сторонние разработчики и компании могут раз-
Рис. 2. Концепция работы платформы
мещать свои сервисы, доступные всем посетителям платформы. Для разработки такого сервиса необходимо подробно рассмотреть вопрос безопасной передачи и хранения данных на платформе, так как храниться и передаваться будут медицинские данные пользователей.
2.3. Пользователи мобильной медицины
В концепции мобильной медицины основным выделяется подход, ориентированный на пациентов. В рамках сферы информационных технологий в нем можно выделить такие типы пользователей, как пациенты, доверенные лица, медицинские работники, фармацевтические и клинические исследователи. Так как конечные пользователи могут использовать сервисы на платформе на ежедневной основе, пользователю должно быть удобно манипулировать базовыми задачами на платформе, такими как обмен данными и управление доступом. Для определения функциональных требований к платформе для каждого из перечисленных пользователей мы выявили основные сценарии использования приложений в области мобильной медицины (см. рис. 3).
Рис. 3. Варианты использования платформы мобильной медицины конечными
пользователями
Пациенты рассчитывают получить широкий спектр медицинских услуг по доступной цене с персонализированными рекомендациями. Помимо получения клинического диагноза врача, у них есть возможность получить больше медицинских знаний с помощью цифровых платформ и общаться с похожими людьми для получения информации, например, о симптомах заболевания, побочных эффектах, госпитализации, информации о лекарствах, клинических отчетах и сценариях развития. Пациент является основным поставщиком информации о собственном здоровье с помощью мобильного устройства.
Доверенные лица рассчитывают на возможность получения информации о состоянии здоровья пациента, за которым они наблюдают. Хоть доверенные лица и не участвуют в лечении пациента напрямую, для них важны возможности получения обучающей информации о болезни пациента и коммуникации с пациентом.
Медицинские работники. Данные, полученные на различных этапах диагностики и лечения пациентов, дают медицинским работникам реальное представление о предлагаемом ходе лечения. С помощью результатов лабораторных исследований, клинических заметок и данных с сенсорных устройств врачи могут следить за состоянием здоровья пациента в любой момент времени, что помогает улучшить наблюдение за общественным здравоохранением и обеспечить быстрое реагирование благодаря эффективному анализу закономерностей развития заболеваний.
Фармацевтические и клинические исследователи. Использование клинических данных помогает построить прогностические модели для понимания биологических и медикаментозных процессов, которые способствуют достижению высокого уровня эффективности при разработке лекарственных препаратов. Анализ медицинских данных помогает фармацевтическим компаниям измерять результаты разработки лекарственных средств даже при малочисленных и быстрых испытаниях.
2.4. Акторы платформы мобильной медицины
В нашей платформе мы ориентируемся в первую очередь на разработчиков сторонних приложений в области мобильной медицины, поскольку они будут основными бенефициантами сервисов, предоставляемых платформой. Кроме того, мы должны помнить, что наша архитектура должна быть достаточно гибкой, чтобы предоставить разработчикам возможность создавать новую функциональность из базовых модулей платформы. В связи с этим, в рамках нашей платформы мы выделяем только одного ключевого актора: стороннее приложение для управления медицинскими данными, созданное на базе нашей платформы.
Учитывая, что платформа должна предоставлять функциональные возможности стороннему сервису, а не обычному пользователю, мы разработали диаграмму вариантов использования системы, в которой главным актором является разрабатываемое независимым разработчиком стороннее приложение (см. рис. 4).
Стороннее приложение может взаимодейстовать с платформой следующим образом:
- Получить спецификацию обмена данными с платформой для конфигурации приложения.
- Авторизовать пользователя стороннего приложения для получения пользователем доступа к своим данным через API.
- Обменять данные между устройствами для синхронной передачи медицинских данных.
Рис. 4. Варианты использования платформы мобильной медицины сторонними
приложениями
- Обменять данные между пользователями для асинхронной передачи медицинских данных.
- Собрать общедоступные данные для их дальнейшей обработки и анализа.
- Изменить права доступа для изменения списка пользователей, которые имеют доступ к данным.
- Настроить уведомления, которые будет отправлять пользователям стороннего приложения платформа.
3. Сравнение подходов к обмену данными в рамках платформы мобильной медицины
3.1. Требования к безопасности
При разработке продукта, взаимодействующего с конфиденциальными медицинскими данными, одним из важнейших критериев для анализа является обеспечение безопасности данных, хранящихся на платформе. Чтобы решить проблему безопасности, необходимо учесть следующие важные детали при реализации платформы:
- платформа должна максимально усложнить возможность утечки конфиденциальных данных с платформы в случае ее взлома. В идеале, в принципе не должно быть механизмов централизованной обработки таких данных;
- хранение и обмен данными пользователя должен быть обеспечен в зашифрованном виде, таким образом, чтобы в случае перехвата их злоумышленником, возможность их интерпретации была максимально затруднена;
- платформа должна предоставлять пользователю возможность управлять настройками доступа к своим данным;
- платформа должна предоставлять доступ к данным пользователя только в том случае, если пользователь самостоятельно установил разрешение на доступ.
В то же время, чтобы сделать нашу платформу удобной для конечных пользователей, мы должны реализовать следующие возможности:
- легкое управление своими данными без сторонних сервисов;
- синхронизация данных между устройствами пользователя;
- обмен данными между пациентом и родственниками или пациентом и врачом. 3.2. Подходы к синхронизации данных
Сегодня можно выделить три наиболее распространенных варианта для организации обмена данными в мобильных приложениях.
- Стороннее облачное хранилище. В этом случае платформа обеспечивает возможность хранения и синхронизации данных пользователей через сторонние облачные сервисы хранения данных, такие как Google Drive или Dropbox.
- Собственное облачное хранилище. При таком подходе все данные пользователей хранятся в облачном хранилище, управляемым разработчиками платформы.
- Р2Р-обмен данными. При таком подходе, медицинские данные хранятся на конечных устройствах пользователей и передаются непосредственно между конечными устройствами.
Предложенные подходы имеют свои преимущества и недостатки в вопросах сохранения конфиденциальности, возможностей по обмену данными и затрат на развертывание и поддержку. В рамках нашей работы мы анализируем три основных варианта использования:
- Персональная синхронизация. Может ли пользователь синхронизировать данные между собственными устройствами?
- Совместный доступ к данным. Может ли пользователь обмениваться данными с другими учетными записями?
- Анонимный обмен данными. Может ли пользователь анонимно делиться своими данными в исследовательских целях?
В рамках данного исследования мы не фокусируемся на вопросах реализации алгоритма шифрования данных в хранилищах, генерации, хранения и обмена ключами, а также специфики реализации передачи зашифрованных данных, так как описание данных процессов выходит за рамки данной работы. Все приведенные способы авторизации, шифрования и передачи данных предполагают использование стандартных средств, предоставляемых выбранной технологией для разработки. Передача данных выполняется только по протоколу по HTTPS, а доступ к данным на локальных устройствах требует авторизации пользователя средствами операционной системы.
Далее в качестве типового примера рассмотрим сценарий организации обмена данными между пользователем на платформе iOS и доверенным лицом на платформе Android.
3.2.1. Стороннее облачное хранилище
При использовании сторонних облачных сервисов мы должны руководствоваться методами хранения и обмена данными файловых систем. В этом случае медицинские данные должны находиться в специальной папке внутри стороннего облачного хранилища, которой он может поделиться с другими пользователями. При таком подходе доверенное лицо должно принять приглашение на доступ к папке, подключиться к выбранному облачному хранилищу, после чего оно сможет просматривать данные пользователя.
В случае использования стороннего облачного хранилища процесс синхронизации включает в себя следующие шаги:
- подключить облачное хранилище в приложении iOS;
- отправить приглашение для доверенного лица;
- подключить облачное хранилище в приложении Android;
- обменяться ключами шифрования;
- асинхронно синхронизировать данные.
Важным преимуществом данного подхода является возможность значительно снизить затраты платформы на хранение данных, так как каждый пользователь самостоятельно отвечает за свои учетные записи в сторонних облачных хранилищах. К тому же, с таким подходом снижается ответственность за обеспечение безопасности хранения и передачи данных, так как данные хранятся и передаются только через устройства и сервисы пользователя.
Однако главным недостатком данного подхода являются ограничения, вызванные механизмами совместного использования и функциональностью файловой системы выбранного облачного хранилища. Для общего доступа к платформе, оба пользователя должны иметь учетные записи в одном и том же стороннем облачном хранилище, сама настройка обмена данными довольно трудоемка и может быть недостаточно комфортной, а пользователям придется самостоятельно следить за оставшимся свободным дисковым пространством, что сильно ограничивает доступность платформы.
Для исследовательских целей данный подход не предоставляет никаких возможностей, так как в нем отсутствуют механизмы удобного получения данных от большого количества анонимных пользователей.
3.2.2. Собственное облачное хранилище
В этом случае медицинские данные хранятся в облачном хранилище, которым управляют владельцы платформы мобильной медицины. Для того чтобы использовать платформу, пользователи должны пройти авторизацию, после чего их данные будут передаваться и сохраняться в веб-сервисе.
Чтобы реализовать обмен данными с помощью этого подхода, нам необходим уникальный ключ шифрования для каждого из получателей. Данные, предназначенные для конкретного получателя, шифруются с помощью этого ключа, а затем отправляются в веб-сервис, откуда получатель может их скачать.
В случае организации обмена данными с доверенным лицом посредством собственного облачного хранилища платформы, процесс синхронизации состоит из шести шагов:
- авторизовать пользователя в приложении iOS;
- авторизовать доверенное лицо в приложении Android;
- предоставить доступ к данным для учетной записи доверенного лица;
- принять доступ к учетной записи пользователя;
- обменяться ключами шифрования;
- асинхронно синхронизировать данные.
В случае использования собственного облачного хранилища данных, мы можем предоставить нашим конечным пользователям гораздо больше функциональных возможностей, поскольку все данные хранятся внутри нашей платформы и мы получаем возможность реализации любой необходимой нам функциональности. С таким подходом мы можем легко
интегрировать различные способы синхронизации между любыми типами конечных пользователей, включая возможность организации сбора данных большого числа конечных пользователей для организации анализа медицинских данных для независимых исследовательских групп.
Однако, поскольку все данные хранятся на облачной платформе ответственность за обеспечение их безопасности полностью ложится на платформу. Также в случае выбора данного подхода необходимо рассмотреть возможные способы финансовой поддержки облачного хранилища, так как увеличение числа пользователей резко повысит стоимость хранения данных и обслуживания облачного решения.
3.2.3. Реег-Ьв-реег обмен данными
В случае организации обмена данными посредством однорангового (реег^о-реег) соединения (см. рис. 5), медицниские данные хранятся только на устройствах пользователей и передаются непосредственно между ними.
Рис. 5. Обмен данными с использованием реег^о-реег соединения
При реализации этого подхода мы отказываемся от идеи централизованного хранения медицинских данных пользователей в веб-сервисе нашей платформы, ограничиваясь хранением информации об учетных записях пользователей и их настройками доступа.
Данный подход снижает риски, связанные с возможным раскрытием медицинских пользовательских данных, в связи с децентрализацией их хранения и обмена. Также значитель-
но снижаются затраты на хранение данных, поскольку для этого используются устройства конечных пользователей.
Однако этот подход ограничивает нас в функциональности и гибкости платформы, поскольку у нас нет прямого доступа к данным пользователей и обмен данными происходит напрямую между двумя устройствами а синхронизация возможна только тогда, когда оба устройства находятся в сети, что затрудняет асинхронную синхронизацию данных между устройствами. Также, необходимо учитывать факт, что не у всех пользователей может быть достаточно дискового пространства на конечном устройстве. Еще одной особенностью данного решения является необходимость отдельной настройки резервных копий локальных данных средствами операционной системы либо сторонними сервисами.
3.2.4■ Сравнение подходов обмена данными
Сравнив эти подходы (см. таблицу), можно сделать следующие выводы.
Таблица 1. Сравнение подходов обмена данными
Персональная Совместный Анонимный
синхронизация доступ обмен данными
Стороннее + ± —
облачное хранилище
Собственное + + +
облачное хранилище
Peer-to-peer + + ±
соединение
Стороннее облачное хранилище позволяет уменьшить стоимость реализации решения, но не сможет обеспечить нужную функциональность нашей платформы и не позволит нам ее масштабировать. Кроме того, механизмы синхронизации на основе сторонних сервисов будет сложно поддерживать в долгосрочной перспективе.
Собственное облачное хранилище является наиболее перспективным с точки зрения функциональности, которую мы можем предоставить конечным пользователям. Но вызывает вопрос возможность финансовой поддержки такого подхода, учитывая цену облачных решений.
Обмен с использованием peer-to-peer связи является компромиссным, так как предоставляет возможность создания практически всей необходимой функциональности, а также решает вопрос финансовой стоимости обмена, хотя и обладает некоторыми особенностями, связанными с необходимостью реализации синхронного обмена данными.
4. Реализация прототипа системы для обмена медицинскими данными
Для демонстрации механизмов обмена данными между двумя устройствами с помощью peer-to-peer соединения мы разработали прототип веб-сервиса и мобильного приложения, обеспечивающих эту функциональность. Рассмотрим процесс обмена данными между пациентом и его доверенным лицом с использованием представленного решения (см. рис. 6).
Рис. 6. Диаграмма последовательности процесса обмена данными между пациентом и доверенным лицом в рамках разработанной платформы
Организации обмена данными с доверенным лицом в рамках нашего прототипа состоит из пяти шагов:
- Регистрация Пациента. После запуска приложения Пациент может зарегистрироваться на платформе для создания учетной записи.
- Регистрация доверенного лица. Для получения данных пациента доверенному лицу также необходимо зарегистрироваться на платформе.
- Создание группы записей. На данном этапе пациент может создать для своих медицинских показателей группу записей, настройки которой будет синхронизироваться с веб-сервисом.
- Предоставление доступа. После создания группы записей пользователь может отправить приглашение на доступ к данным внутри группы любому другому пользователю платформы. В данном случае пользователь отправляет приглашение на группу по email доверенного лица. Доступ к данным у доверенного лица появляется только после принятия им прав на доступ. После принятия приглашения на сервис отправляется событие о изменении прав. Хотя в рамках данной диаграммы последовательности
мы не рассматриваем процесс отклонения доступа, стоит отметить, что после принятия прав пользователь может самостоятельно в любой момент отказаться от доступа.
- Обмен данными. Данный этап может повторяться сколько угодно раз после прохождения предыдущих шагов. В случае открытия доверенным лицом приложения устройство отправляет на веб-сервис запрос на получение данных для подключения к устройству пациента. В случае успешного установления прямого соединения данные на устройстве пациента передаются на устройство доверенного лиц посредством peer-to-peer подключения. Перед отправкой на устройстве пациента данные предварительно шифруются публичным ключом доверенного лица. После получения данных доверенное лицо может расшифровать их с помощью своего приватного ключа.
Для разработки веб-сервиса был выбран язык программирования Python с использованием фреймворка Django. Мобильное приложение реализовано для iOS нативными средствами на языке программирования Swift. Нами было принято решение разработать приложение только для операционной системы iOS, так как концептуально в рамках нашей платформы разница между обменом с iOS на iOS и с iOS на Android отсутствует.
4.1. Схема серверной базы данных
Для работы веб-сервиса была разработана схема базы данных (см. рис. 7), содержащая информацию о пользователях системы, сессиях, группах записей и правах доступа. Рассмотрим таблицы и представленные в них атрибуты подробнее.
С User N
id integer(lO) и
Щ email varchar(255) и
V
Session
-I--40-
■ 0< Щ ip varchar(15)
user_id integer(10)
Щ created timestamp (Jf)
j id integer(lO) (J
Г RecordGroup N
t id integer(lO) (J
f^ name varchar(255)
Щ created timestamp
owner id integer (10)
V J
■ <X
f AccessRights N
,_v record_group_id integer(lO)
recipient_public_key integer(lO)
recipient_id integer(lO) И
f^ created timestamp
Щ accepted timestamp
Щ revoked timestamp ю
id V integer(lO) и У
>CH
Рис. 7. Схема серверной базы данных
User — хранит информацию о существующих на плафторме пользователях. В качестве универсального имени пользователя было выбрано использовать поле электронной почты.
Session — хранит все сессии пользователей, взаимодействующих с платформой. Содержит в себе информацию об ip-адресе пользователя на момент создания сессии. У каждого пользователя может быть неограниченное количество сессий.
RecordGroup — хранит информацию о всех имеющихся у пользователя групп данных. Группы представляют собой именованные категории данных, у которых отсутствует связь с самими данными на сервере, но которые стороннее приложение может использовать для управления доступа к данным локально. У каждого пользователя может быть неограниченное количество групп.
AccessRights — хранит информацию о всех правах доступа к группе данных пользователя. В нашем примере права доступа реализованы без детализации конкретных прав на управление данными. Для реализации такой возможности таблица может быть расширена дополнительными параметрами в будущем. Хранит в себе ссылку на группу записей к которой предоставляется доступ и публичный ключ получателя прав. У одной группы данных можно задавать неограниченное число прав доступа.
4.2. API веб-сервиса
Для взаимодействия с веб-сервисом был разработан REST API. Реализованные запросы можно разделить на четыре группы: авторизация, управление данными и управление доступом.
В группе авторизации были реализованы запросы регистрации, входа и обновления токена. При корректно введенных данных сервис возвращает JSON-объект описывающий авторизованного пользователя, его текущую сессию и пару токенов.
Для реализации механизма авторизации нами был выбран подход с использованием пары токенов refresh и access. При предоставлении данных авторизации пользователю будет возвращаться:
- access — токен доступа, в дальнейшем передается клиентом в заголовке запроса и по нему сервер определяет все ли еще активна ли сессия пользователя.
- refresh — токен обновления, используется после окончания срока действия access-токена для получения нового access-токена.
Время жизни access-токена должно быть меньше времени жизни refresh-токена, чтобы клиент мог получить новый access-токен без необходимости повторного ввода логина и пароля. В рамках данной работы время жизни access-токена было установлено в 30 минут, а refresh-токена — в 365 дней.
После получения клиентом access-токена он должен отправляться в заголовке каждого запросе пользователя в формате "Authorization": "Bearer token", где token — значение access-токена.
В группе управления данными реализованы запросы на создание новой группы, удаление группы и получение списка групп пользователя.
После создании пользователя ему по умолчанию создается группа данных с наименованием "Общая", в которой по-умолчанию располагаются все данные пользователя.
В группе управления доступом реализованы запросы на отправку доступа к группе, принятие доступа, отклонение доступа и на получение данных для инициализации обмена. При подтверждении или отклонении доступа, API автоматически записывает в соответствующее поле accepted или revoked текущую дату. При принятии прав доступа пользователь дополнительно отправляет свой публичный ключ шифрования данных, который будет необходим владельцу группы для последующего шифрования данных.
4.3. Прототип мобильного приложения
Для демонстрации процесса обмена данными мы разработали прототип мобильного приложения, позволяющего пользователю зарегистрироваться и войти в систему, управлять своими группами данных, правами доступа к ним, и обмениваться данными с другими пользователями (см. рис. 8).
Рис. 8. Главный экран, добавление группы и просмотр группы
На данном примере мы можем показать процесс обмена данными между пациентом и его доверенным лицом. Мобильное приложение состоит из нескольких разделов, рассмотрим подробнее каждый их них.
4-3.1. Регистрация/вход
При открытии приложения пользователь попадает на экран Входа, с помощью которого может войти в систему или перейти на экран Регистрации. Поля для входа и регистрации совпадают, так как для демонстрационных целей профиль пользователя не содержит в себе дополнительной информации. После успешного входа или регистрации в системе приложение запоминает полученного пользователя и его access и refresh токены.
4-3.2. Главный экран и группы данных
После авторизации в приложении пользователь попадает на главный экран. Все последующие перезапуски приложения будут выводить пользователя на главный экран до момента, пока он не выйдет из своего аккаунта, либо пока не истечет его access и refresh токены.
Сразу после открытия приложения: при открытии данного экрана, приложение отправляет на веб-сервис запрос на создание у пользователя новой сессии, благодаря чему сервер запоминает актуальный IP-адрес устройства пользователя.
На данном экране пользователь может видеть свои группы данных и группы данных, которыми с ним поделились. Распределение групп мобильное приложение выполняет по полю owner email.
При выборе пользователем одной из групп данных открывается экран с ее деталями, на котором отображаются все данные, находящиеся в этой группе и пользователи, которым предоставлен доступ к этой группе. При добавлении пользователем новой записи в группу данных приложение предлагает пользователю поделиться этой записью сразу и с другими группами. По умолчанию все записи также отправляются в основную группу пользователя "Общая".
4.3.3. Наблюдатели
При просмотре группы данных, к которым пользователю был предоставлен доступ, интерфейс приложения отличается. Наблюдатели не могут добавлять новый данные в группы, а могут только просматривать содержащуюся там информацию. До принятие приглашения пользователь не видит содержащиеся в группе данные. После принятия приглашения пользователь может в любой момент самостоятельно отписаться от группы.
Заключение
В рамках данной статьи, нами был проведен анализ существующих проблем, связанных с организацией обмена данных в области мобильной медицины. К сожалению, сегодня отсутствуют единые стандартизованные механизмы организации такого обмена, что приводит к фрагментации и отсутствии синергии между мобильными приложениями, обеспечивающими сбор и обработку данных мобильного интернета вещей. Нами предлагается понятие платформы мобильной медицины, которая позволила бы решить данную задачу. На основе анализа вариантов использования такой платформы, мы определили и проанализировали три возможных способа организации обмена данными с учетом ограничений, накладываемых предметной областью мобильной медицины. По результатам сравнения данных решений, наиболее перспективным был признан вариант организации однорангового обмена данными. Нами был реализован прототип мобильного приложения, обеспечивающий возможность синхронизации, при котором медицинские данные хранятся на конечных устройствах пользователя, а веб-сервис отвечает исключительно за управление авторизацией пользователей и распределением прав доступа.
Для эффективной реализации платформы мобильной медицины в дальнейших работах мы планируем детальнее проработать вопрос безопасности хранения и передачи данных, разработать архитектуру других модулей платформы и определить общую механику подключения сторонних приложений к платформе мобильной медицины.
Секции 1, 3 исследования была выполнена при финансовой поддержке РФФИ и Челябинской области в рамках научного проекта № 20-47-740005, разделы 2, 4 были выполнены при финансовой поддержке Министерства науки и высшего образования РФ (государственное задание FENU-2020-0022).
Литература
1. Farahani B., Firouzi F., Chang V. et al. Towards fog-driven IoT eHealth: Promises and challenges of IoT in medicine and healthcare // Future Generation Computer Systems. 2018. Vol. 78. P. 659-676. DOI: 10.1016/j.future.2017.04.036.
2. United Nations. World population ageing 2013. United Nations, 2014. 114 p. DOI: 10.18356/30d0966c-en.
3. Yang W., Dall T.M., Haider P. et al. Economic costs of diabetes in the U.S. in 2012 // Diabetes Care. 2013. Vol. 36. P. 1033-1046. DOI: 10.2337/dc12-2625.
4. Carozzi F., Provenzano S., Roth S. Urban Density and Covid-19 // SSRN. 2020. DOI: 10.2139/ssrn.3643204.
5. Qudah B., Luetsch K. The influence of mobile health applications on patient - healthcare provider relationships: A systematic, narrative review // Patient Education and Counseling.
2019. Vol. 102, no. 6. P. 1080-1089. DOI: 10.1016/j.pec.2019.01.021.
6. Free C., Phillips G., Watson L. et al. The Effectiveness of Mobile-Health Technologies to Improve Health Care Service Delivery Processes: A Systematic Review and Meta-Analysis // PLoS Medicine. 2013. Vol. 10. P. e1001363. DOI: 10.1371/journal.pmed.1001363.
7. Healthcare IT Market: Healthcare Information Technology Market Trends & Global Forecast (2010-2015) | MarketsandMarkets. URL: https://www.marketsandmarkets.com/ Market-Reports/healthcare-information-technology-market-136.html (дата обращения: 12.01.2021).
8. Healthcare IT Market Size, Share and Trends forecast to 2026 by Products & Services, Components, End User | COVID-19 Impact Analysis | MarketsandMarkets. URL: https: //www.marketsandmarkets.com/Market-Reports/healthcare-it-252.html (дата обращения: 12.01.2021).
9. Волков И.А. Мобильное приложение для ведения сахарного диабета - DiaMeter // Материалы XV Итоговой научно-практической конференции молодых ученых и специалистов, Челябинск, Россия, 26 апреля, 2017. 2017. С. 25-28.
10. Volkov I., Radchenko G. DiaMeter: a Mobile Application and Web Service for Monitoring Diabetes Mellitus // 2020 Ural Symposium on Biomedical Engineering, Radioelectronics and Information Technology (USBEREIT), Yekaterinburg, Russia, May 14-15, 2020. IEEE, 2020. P. 0384-0387. DOI: 10.1109/USBEREIT48449.2020.9117654.
11. Volkov I., Radchenko G., Tchernykh A. Digital Twins, Internet of Things and Mobile Medicine: a Review of Current Platforms to Support Smart Healthcare // CoRR. 2021. Vol. abs/2106.11728. URL: https://arxiv.org/abs/2106.11728.
12. Steinhubl S.R., Muse E.D., Topol E.J. The emerging field of mobile health // Science Trans-lational Medicine. 2015. Vol. 7. P. 283rv3-283rv3. DOI: 10.1126/scitranslmed.aaa3487.
13. Mastoi Q.U.A., Wah T.Y., Raj R.G., Lakhan A. A novel cost-efficient framework for critical heartbeat task scheduling using the internet of medical things in a fog cloud system // Sensors.
2020. Vol. 20, no. 2. P. 441. DOI: 10.3390/s20020441.
14. Zheng Y.L., Ding X.R., Poon C.C.Y. et al. Unobtrusive sensing and wearable devices for health informatics // IEEE Transactions on Biomedical Engineering. 2014. Vol. 61, no. 5. P. 1538-1554. DOI: 10.1109/TBME.2014.2309951.
15. Meng L., Miao C., Leung C. Towards online and personalized daily activity recognition, habit modeling, and anomaly detection for the solitary elderly through unobtrusive sensing // Multimedia Tools and Applications. 2017. Vol. 76, no. 8. P. 10779-10799. DOI: 10.1007/s11042-016-3267-8.
16. Rudner J., McDougall C., Sailam V. et al. Interrogation of Patient Smartphone Activity Tracker to Assist Arrhythmia Management // Annals of Emergency Medicine. 2016. Vol. 68. P. 292-294. DOI: 10.1016/j.annemergmed.2016.02.039.
17. HealthKit | Apple Developer Documentation. URL: https://developer.apple.com/ documentation/healthkit (дата обращения: 12.01.2021).
18. Jardine J., Fisher J., Carrick B. Apple's ResearchKit: smart data collection for the smart-phone era? // Journal of the Royal Society of Medicine. 2015. Vol. 108, no. 8. P. 294-296. DOI: 10.1177/0141076815600673.
19. Esposito M., Minutolo A., Megna R. et al. A smart mobile, self-configuring, context-aware architecture for personal health monitoring // Engineering Applications of Artificial Intelligence. 2018. Vol. 67. P. 136-156. DOI: 10.1016/j.engappai.2017.09.019.
20. Create Alexa Skills Kit | Amazon Alexa Voice Development. URL: https://developer. amazon.com/en-US/alexa/alexa-skills-kit (дата обращения: 12.01.2021).
Волков Иван Алексеевич, аспирант, кафедра электронно-вычислительных машин, Южно-Уральский государственный университет (национальный исследовательский университет) (Челябинск, Российская Федерация)
Радченко Глеб Игоревич, к.ф-м.н., доцент, Южно-Уральский государственный университет (национальный исследовательский университет) (Челябинск, Российская Федерация).
Черных Андрей Николаевич, к.т.н., доцент, заведующий научно-исследовательской лабораторией проблемно-ориентированных облачных сред, Южно-Уральский государственный университет (национальный исследовательский университет) (Челябинск, Российская Федерация), профессор, научно-исследовательский центр Энсенады (Энсенада, Мексика).
DOI: 10.14529/cmse210403 DATA SHARING IN MOBILE HEALTH PLATFORM
© 2021 I.A. Volkov1, G.I. Radchenko1, A.N. Tchernykh12
1 South Ural State University (pr. Lenina 76, Chelyabinsk, 454080 Russia),
2Ensenada Research Center (Carretera Ensenada — Tijuana No. 3918, Ensenada, 22860 Mexico) E-mail: volkovia@susu.ru, gleb.radchenko@susu.ru, chernykh@cicese.mxx
Received: 03.11.2021
Mobile health is an important tool for continuous health monitoring, which opens up new opportunities for physicians, patients, and researchers. The exponential growth of the field resulted in an increase rate of appearance of new solutions in the healthcare market and, consequently, an increase in the amount of information about the health of the population. However, nearly all of the information collected by these services is isolated from each other, as it is distributed across different sites, services and mobile apps. The lack of a user's ability to conveniently manage and share their medical data is the major problem of the sphere at the moment. The creation of the Mobile Medicine platform can be a solution to this problem, offering a framework on which third-party developers and companies can host their services, available to all visitors of the platform. In our work we analyze existing solutions in the mobile medicine market, provide use cases for Mobile medicine services, propose the concept of the platform, develop use cases for Mobile medicine platform, highlight and compare three ways of data exchange variants and based on the comparison select and implement a prototype of data exchange within Mobile Medicine platform.
Keywords: smart healthcare, mobile medicine, health monitoring, platform, PaaS, internet of things, mobile applications.
FOR CITATION
Volkov I.A., Radchenko G.I., Tchernykh A.N. Data Sharing in Mobile Health Platform. Bulletin of the South Ural State University. Series: Computational Mathematics and Software Engineering. 2021. Vol. 10, no. 4. P. 37-59. (in Russian) DOI: 10.14529/cmse210403.
This paper is distributed under the terms of the Creative Commons Attribution-Non Commercial 4.0 License which permits non-commercial use, reproduction and distribution of the work without further permission provided the original work is properly cited.
References
1. Farahani B., Firouzi F., Chang V. et al. Towards fog-driven IoT eHealth: Promises and challenges of IoT in medicine and healthcare. Future Generation Computer Systems. 2018. Vol. 78. P. 659-676. DOI: 10.1016/j.future.2017.04.036.
2. United Nations. World population ageing 2013. United Nations, 2014. 114 p. DOI: 10.18356/30d0966c-en.
3. Yang W., Dall T.M., Halder P. et al. Economic costs of diabetes in the U.S. in 2012. Diabetes Care. 2013. Vol. 36. P. 1033-1046. DOI: 10.2337/dc12-2625.
4. Carozzi F., Provenzano S., Roth S. Urban Density and Covid-19. SSRN. 2020. DOI: 10.2139/ssrn.3643204.
5. Qudah B., Luetsch K. The influence of mobile health applications on patient - healthcare provider relationships: A systematic, narrative review. Patient Education and Counseling.
2019. Vol. 102, no. 6. P. 1080-1089. DOI: 10.1016/j.pec.2019.01.021.
6. Free C., Phillips G., Watson L. et al. The Effectiveness of Mobile-Health Technologies to Improve Health Care Service Delivery Processes: A Systematic Review and Meta-Analysis. PLoS Medicine. 2013. Vol. 10. P. e1001363. DOI: 10.1371/journal.pmed.1001363.
7. Healthcare IT Market: Healthcare Information Technology Market Trends & Global Forecast (2010-2015) | MarketsandMarkets. URL: https://www.marketsandmarkets.com/ Market-Reports/healthcare-information-technology-market-136.html (accessed: 12.01.2021).
8. Healthcare IT Market Size, Share and Trends forecast to 2026 by Products & Services, Components, End User | COVID-19 Impact Analysis | MarketsandMarkets. URL: https://www.marketsandmarkets.com/Market-Reports/healthcare-it-252.html (accessed: 12.01.2021).
9. Volkov I.A. Mobile Application for Monitoring Diabetes Mellitus - DiaMeter. Proceedings of the XV Scientific and Practical Conference of Young Scientists and Specialists, Chelyabinsk, Russia, April 26, 2017. 2017. P. 25-28. (in Russian).
10. Volkov I., Radchenko G. DiaMeter: a Mobile Application and Web Service for Monitoring Diabetes Mellitus. 2020 Ural Symposium on Biomedical Engineering, Radioelectronics and Information Technology (USBEREIT), Yekaterinburg, Russia, May 14-15, 2020. IEEE, 2020. P. 0384-0387. DOI: 10.1109/USBEREIT48449.2020.9117654.
11. Volkov I., Radchenko G., Tchernykh A. Digital Twins, Internet of Things and Mobile Medicine: a Review of Current Platforms to Support Smart Healthcare. CoRR. 2021. Vol. abs/2106.11728. URL: https://arxiv.org/abs/2106.11728.
12. Steinhubl S.R., Muse E.D., Topol E.J. The emerging field of mobile health. Science Trans-lational Medicine. 2015. Vol. 7. P. 283rv3-283rv3. DOI: 10.1126/scitranslmed.aaa3487.
13. Mastoi Q.U.A., Wah T.Y., Raj R.G., Lakhan A. A novel cost-efficient framework for critical heartbeat task scheduling using the internet of medical things in a fog cloud system. Sensors.
2020. Vol. 20, no. 2. P. 441. DOI: 10.3390/s20020441.
14. Zheng Y.L., Ding X.R., Poon C.C.Y. et al. Unobtrusive sensing and wearable devices for health informatics. IEEE Transactions on Biomedical Engineering. 2014. Vol. 61, no. 5. P. 1538-1554. DOI: 10.1109/TBME.2014.2309951.
15. Meng L., Miao C., Leung C. Towards online and personalized daily activity recognition, habit modeling, and anomaly detection for the solitary elderly through unobtrusive sensing. Multimedia Tools and Applications. 2017. Vol. 76, no. 8. P. 10779-10799. DOI: 10.1007/s11042-016-3267-8.
16. Rudner J., McDougall C., Sailam V. et al. Interrogation of Patient Smartphone Activity Tracker to Assist Arrhythmia Management. Annals of Emergency Medicine. 2016. Vol. 68. P. 292-294. DOI: 10.1016/j.annemergmed.2016.02.039.
17. HealthKit | Apple Developer Documentation. URL: https://developer.apple.com/ documentation/healthkit (accessed: 12.01.2021).
18. Jardine J., Fisher J., Carrick B. Apple's ResearchKit: smart data collection for the smart-phone era? Journal of the Royal Society of Medicine. 2015. Vol. 108, no. 8. P. 294-296. DOI: 10.1177/0141076815600673.
19. Esposito M., Minutolo A., Megna R. et al. A smart mobile, self-configuring, context-aware architecture for personal health monitoring. Engineering Applications of Artificial Intelligence. 2018. Vol. 67. P. 136-156. DOI: 10.1016/j.engappai.2017.09.019.
20. Create Alexa Skills Kit | Amazon Alexa Voice Development. URL: https://developer. amazon.com/en-US/alexa/alexa-skills-kit (accessed: 12.01.2021).
