Прототип клиент-серверного приложения для получения медицинских онлайн-консультаций "e-Doctor"edicinskih-onlayn-konsultaciy-e-doctor_105863

Размещено на http://www.allbest.ru/

ПРАВИТЕЛЬСТВО РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ «ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»

Факультет компьютерных наук

Департамент программной инженерии

Выпускная квалификационная работа

на тему: «Прототип клиент-серверного приложения для получения медицинских онлайн-консультаций "e-Doctor"».

по направлению подготовки 09.03.04 «Программная инженерия»

Москва 2019



Реферат

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

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

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

Работа содержит 44 страницы, 3 главы, 29 рисунков, 13 схем, 35 источников и 4 приложения.

Ключевые слова: телемедицина, медицинская консультация,Android приложение, архитектура



Abstract

Nowadays, against the background of the explosive growth in mobile technologies remote medical consultations have the potential to change medical services forever as they allow a patient to receive medical consultation in a few minutes. That can be convenient for both the patient and the doctor.

This paper describes the prototype of client-server application «e-Doctor» designed for tracking private medical information and receiving medical consultations through chatting, audio and video calls with a doctor of the desired speciality. The product allows a patient to create and edit his private medical events and health parameters, send them to a doctor and receive recommendations from doctor. The key functionality of the software product is ability to edit all private medical information without the Internet connection with subsequent synchronization with the server.

This paper contains a brief market analysis, the description of the architecture of the software product, his main functions and technologies used in the process of development.

The paper contains 44 pages, 3 chapters, 29 illustrations, 13 schemes, 35 bibliography items and 4 appendices.

Key words: telemedicine, medical consultation, Android application, architecture



Оглавление

Введение

Глава 1. Обзор существующих решений

1.1 Приложения для проведения удаленных медицинских консультаций

1.2 Приложения для отслеживания персональной медицинской информации

1.3 Приложения с совмещенными функциями

1.4 Обоснование необходимости разработки нового приложения

Глава 2. Архитектура приложения

2.1 Архитектура приложения в целом

2.2 Архитектура клиентской части приложения

2.2.1 Общее устройство мобильного приложения

2.2.2 Использование MVVM в качестве слоя представления

2.3 Архитектура серверной части приложения

Глава 3. Детали реализации приложения

3.1 Детали реализации клиентской части приложения

3.1.1 Использование RxJava

3.1.2 База данных

3.1.3 Подключение к серверу

3.2 Детали реализации серверной части приложения

3.2.1 База данных

3.2.2 Использование SpringData

3.3 Деталиреализацииприложениявцелом

3.3.1 Регистрация пользователей

3.3.2 Обмен сообщениями между пользователями

3.3.3 Аудио- ивидеосвязь

3.3.4 Синхронизация записей медкарты

3.3.5 Система обмена медицинскими данными

3.3.6 Работа с изображениями

Заключение

Список использованных источников



Основные определения, термины, сокращения

Телемедицина - использование компьютерных и телекоммуникационных технологий для обмена медицинской информацией.

Медкарта - набор персональных медицинских записей.

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

Android - мобильная операционная система, разрабатываемая компанией Google.

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

Реактивное программирование-парадигма программирования, ориентированная на потоки данных и распространение изменений.

Фреймворк - программное обеспечение, облегчающее объединение разных модулей программного проекта и его разработку.

API-описание способов, которыми одна компьютерная программа может взаимодействовать с другой программой.

WebSocket - протокол связи, предназначенный для обмена сообщениями в режиме реального времени.

Offline-first-принцип, согласно которому максимальное количество функциональности приложения должно быть доступно в условиях отсутствия интернет-соединения.

СУБД - комплекс программ, позволяющих создать базу данных и манипулировать данными. Система обеспечивает безопасность, надёжность хранения и целостность данных, а также предоставляет средства для администрирования базы данных.

Введение

Рынок мобильных технологий растет очень быстро. Несколько лет назад дневной объем интернет-трафика с мобильных устройств превысил аналогичный показатель для компьютеров[1]. Четко прослеживается тенденция на постепенную мобилизацию многих сфер жизни человека. Мобильные приложения меняют привычки людей и предлагают новые удобные способы решения каждодневных задач, таких как вызов такси, ведение списка дел, общение с друзьями, чтение книг.

Удаленные медицинские консультации обладают потенциалом навсегда изменить рынок оказания медицинских услуг, ведь они позволяют пациенту получить консультацию с врачом в течение нескольких минут, что может быть удобно как для врача, так и для пациента. Стоит отметить, что использование телемедицины особенно актуально в Российской Федерации, которая, будучи самой большой страной в мире, содержит населенные пункты, в которых очное посещение врача может быть сложным из-за отсутствия необходимого персонала и удаленности от крупных городов.

Клиент-серверное Android приложение «e-Doctor» позволяет пациентам отслеживать персональную медицинскую информацию и получать удаленные медицинские консультации через чат, видео- и аудиосвязьсо врачом желаемой специализации. Операционная система Android уверенно лидирует в списке мобильных платформ и занимает более 70% рынка [2]. Разработанное клиентское приложение доступно на версиях операционной системы начиная с 5.0 и выше, которые установлены на не менее чем 80% Android устройств [3]. Таким образом, разработанное приложение будет доступно большой части целевой аудитории.

У разработанного программного продукта есть некоторое количество конкурентов на российском рынке мобильных Android приложений; их можно разделить на три группы. Первая группа приложений позволяет пользователю общаться с врачом, а функции редактирования медкарты недоступны. Вторая группа предоставляет лишь функциональность отслеживания персональной медицинской информации, такой как посещения врачей или уровень сахара в крови. Приложения третьей группы совмещают в себе функции ведения медкарты и телемедицины, однако единственным подобным приложением на рынке является ONDOC [4].

В свою очередь, разработанный программный продукт обладает набором функций, на данный момент не доступным ни в одном Android приложении на рынке. Приложение «e-Doctor» предоставляет наиболее полный по сравнению с конкурентами список типов записей медкарты. Помимо этого, пациент имеет возможность создавать свои типы медицинских показателей, что повышает качество пользовательского опыта. Создание, редактирование и удаление всех записей медкарты доступно в условиях отсутствия интернет-соединения с последующей синхронизацией изменений с сервером. Пациент также может отправить любую запись медкарты в виде текста в одно из установленных на его телефоне приложений.

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

Цель данной выпускной квалификационной работы была сформулирована так: разработать клиент-серверное Android приложение для отслеживания пациентами персональной медицинской информации и проведения удаленных медицинских консультаций между врачом и пациентом. Для достижение этой цели необходимо выполнить следующий список задач:

Проанализировать существующие решения;

Разработать алгоритм работы и определить функциональность приложения;

Разработать серверное API, определить основные сущности бизнес-логики сервера;

Определить архитектуру и используемые библиотек на клиентской и серверной частях;

Создать прототипы дизайна и навигации;

Разработать клиентскую часть приложения;

Разработать серверную часть приложения;

Протестировать и отладить приложение;

Написать техническую документацию.

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



Глава 1. Обзор существующих решений

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

Приложения для проведения удаленных медицинских консультаций

Рисунок 1.1 - «Яндекс.Здоровье»

Рисунок 1.2 - «Doc+»



Рисунок 1.3 - «DocDoc»

Такие популярные программные продукты, как «Яндекс.Здоровье» [5] (рис. 1.1), «Doc+» [6] (рис. 1.2)или «DocDoc» [7] (рис. 1.3)позволяют пациенту получить консультацию со врачом желаемой специализации через чат, видео- и аудиосвязь. Как только общение заканчивается, пациент получает доступ к списку рекомендаций и заключению от медицинского сотрудника.

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

Приложения для отслеживания персональной медицинской информации

Рисунок 1.4 - «Финтехклаб Медкарта»

Рисунок 1.5 - «MedicalNote»



«Финтехклаб Медкарта» [8] (рис. 1.4)и «MedicalNote» [9] (рис. 1.5) это самые популярные приложения для ведения медкарты в телефоне.Главная проблема этих сервисов в том, что они не поддерживают экспорт данных медкарты ни в каком виде. Пользователь может отслеживать свою медкарту, но не может использовать ее для консультаций с врачом, так как перечисленные сервисы не обладают функцией проведения удаленных консультаций.

Более того, перечисленные программные продукты имеют ряд недостатков в сценарии редактирования медицинских данных. Например, «Финтехклаб Медкарта» поддерживает добавление записей лишь в виде комментариев и просмотр их всех разом на одном экране, что означает полное отсутствие структурирования записей по типам. Также, это приложение не поддерживает синхронизацию между устройствами. Так, при смене мобильного телефона пользователю придется заново вводить все записи. «MedicalNote», в свою очередь, не позволяет вводить данные о своей группе крови, создавать свои типы медицинских показателей, отслеживать изменение показателей здоровья с течением времени на графике.

Приложения с совмещенными функциями

Рисунок 1.6 - «ONDOC»



Единственным программным продуктом, совмещающим в себе обе рассмотренные выше функциональности, является «ONDOC» (рис. 1.6). Однако, он имеет ряд недостатков. Приложение не поддерживает такие типы событий, как проведение процедуры или период болезни, не дает возможность добавлять комментарии к событиям и отправлять записи в виде текста в другие установленные на телефоне приложения.

Из медицинских показателей доступны лишь два - давление и вес. Редактирование медкарты без интернет-соединения недоступно. Наконец, «ONDOC» не обладает функцией гибкой настройки доступа врача к медицинским записям пациента.

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

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

Обоснование необходимости разработки нового приложения

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

Разработанный программный продукт «e-Doctor» обладает набором функций, на момент разработки программы не доступным ни в одном приложении на рынке. Дополнительно стоит отметить, что клиентская часть приложения полностью локализована на русский и английский языки, а ее интерфейс спроектирован с учетом Meterial Design.

Сравнение разработанного приложения с конкурентами представлено на рис. 1.7.



	Яндекс. Здоровье	DOCDOC	DOC+	ONDOC	Финтехклаб Медкарта	MedicalNote	e-Doctor
Базовая информация о пациенте	-	-	-	+	+	-	+
События в медкарте	-	-	-	+/-	-	+	+
Отслеживание показателей в медкарте	-	-	-	+/-	-	+/-	+
Настройки доступа врача к медкарте	-	-	-	+/-	-	-	+
Offline-first редактирование медкарты	-	-	-	-	-	+	+
Экспорт записей медкарты в виде текста в другие приложения	-	-	-	-	+	-	+
Получение записей в медкарту от врача	+	+	+	+	-	-	+
Поиск врачей по имени и специальности	-	+	-	+	-	-	+
Общение с врачом	+	+	+	+	-	-	+
Просмотр истории чатов без интернета	+	+	+	-	-	-	+

Рисунок 1.7 - Сравнение разработанного приложения с аналогами



Глава 2. Архитектура приложения

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

2.1 Архитектура приложения в целом

Рисунок 2.1 - Архитектура приложения в целом

В качестве клиентской части приложения выступает нативное мобильное Android приложение. Серверная часть приложения, в свою очередь, написана с помощью Spring [11], фреймворка для разработки надежных серверных приложений. Программный продукт полностью написан на языках Kotlin[12] и Java [13], при этом Kotlin, как более современный и гибкий язык, использовался в большинстве случаев. Использование одного набора языков для реализации обеих частей приложения позволяет в некоторых случаях писать код один раз вместо двух, использовать одни и те же библиотеки и IDE.

Серверное Spring приложение хранит информацию в базе данных и файловом хранилище, таким образом, пользователи могут взаимодействовать друг с другом и использовать сразу несколько устройств для доступа к своим данным. Для передачи данных между клиентом и сервером используется протокол HTTPS вместе с архитектурным стилем REST [14].Однако, некоторые функции приложения, такие как чат или аудиозвонки, требуют установления длительного соединения между клиентом и сервером, не поддерживаемого протоколом HTTPS самим по себе: для этих целей был использован протокол WebSocket над протоколом HTTPS. Передаваемые данные представляются в виде форматов JSONи multipart/form-data.

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

2.2 Архитектура клиентской части приложения

2.2.1 Общее устройство мобильного приложения

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



Рисунок 2.2 - Схема Чистой Архитектуры[15]

В среде Android разработчиков большой популярностью пользуется так называемая Чистая Архитектура [15], схема которой представлена на рис. 2.2. Следуя этой архитектуре, приложение должно делиться на 3 слоя: данные (data), бизнес-логика (domain), представление (presentation). У каждого из слоев своя зона ответственности. Первый слой отвечает за получение данных из различных источников, таких как сервер или база данных, и последующий перевод данных в структуры, понятные слою бизнес-логики. Слой бизнес-логики отвечает за основную логику приложения, такую как, например, определение того, истекла ли у пользователя подписка или вычисление суммы платежа, которую пользователь будет должен заплатить за желаемую транзакцию. Наконец, слой представления ответственен за отображение данных.

Рисунок 2.3 - Архитектура клиента на примере некоторых классов

Однако, во многих приложениях бизнес-логика хранится на сервере для использования ее на многих клиентах и из соображений безопасности. В разработанном приложении бизнес-логика также хранится на сервере, таким образом, поддержка слоя domain была бы излишней и не оправдывала бы себя, ведь этот слой бы просто передавал объекты от Данных к Представлению. Поэтому архитектура разработанного мобильного приложения состоит из двух слоев: данные и представление (рис. 2.3). Слой данных реализует паттерн Repository: в зависимости от параметров запроса, текущего состояния сети и многих других параметров, Repository сам решает, откуда получать данные - из локального хранилища или сервера, инкапсулируя в себе все взаимодействие с источниками данных. Mapper ответственен за преобразования объектов одного типа в другой: например, из типа MessageEntity, которым оперирует локальное хранилище, в тип Message, о котором знает слой представления. Примененная архитектура делает приложение тестируемым и расширяемым за счет использования принципов единственной ответственности и инверсии зависимости, входящими в список принципов SOLID[16]. Так как классы выполняют ровно одну задачу и не зависят напрямую от реализаций других классов, приложение будет легко покрыть unit-тестами. Архитектура разработанного приложения позволяет ему быть независимым от источников данных и интерфейса, таким образом, изменения, вносимые в приложение при изменении способа хранения данных или их отображения, затронут минимальное количество классов, что положительно сказывается на простоте поддержки разработанного программного продукта.

2.2.2 Использование MVVM в качестве слоя представления

Фреймворк Android содержит 4 основных компонента, используемых при разработке приложений [17]. Один из них, Activity, используется для работы с пользовательским интерфейсом. У этого компонента достаточно сложный жизненный цикл[18], включающий в себя последовательный вызов более 15 методов, таких как «onStart», «onStop», «onRequestPermissionResult», «onDestroy»и другие. Во многих случаях, от разработчика требуется переопределение как минимум нескольких из этих методов. Более того, некоторые действия, такие, как открытие диалога, получение разрешений на действия в системе, старт фонового действия, доступны только из контекста Activity. Это часто приводит к увеличению количества строк в классе, наследующемся от Activity. Другой проблемой компонента является то, что он по умолчанию не сохраняет свое состояние при изменении конфигурации, например, повороте экрана.

Рисунок 2.4 - Сравнение MVPи MVVM

Для решения вышеперечисленных проблем можно использовать такой паттерн, как MVP [19] (рис. 2.4). Этот паттерн предполагает, что слой представления разделяется на две части: Viewи Presenter.Modelв MVP-часть, не связанная с отображением, в нашей архитектуре это слой данных. View ответственна за работу с системой, описанную выше. Presenter же ответственен за логику, которая не имеет отношения к системе, например, сортировку записей перед их показом, получение записей от Model, а также за хранение состояния экрана. Таким образом, связанность кода уменьшается, ведь View ничего не знает про Model, Modelпро View, между собой их связывает Presenter.

Однако, к недостаткам приведенного выше паттерна можно отнести то, что после многократного вызова Presenter'ом методов View может быть сложно отследить итоговое состояние системы, а также восстановить его после изменения конфигурации.

Это делает связь двух перечисленных классов менее надежной, а Presenter менее тестируемым. Поэтому в последнее время паттерн MVVM [19] (рис. 2.4) пользуется все большей популярностью. Этот паттерн отличается от MVP введением новой сущности ViewState, которая представляет из себя буквально «состояние отображения» и используется для передачи данных из Presenterво View.

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

Архитектура MVVM в мобильном приложении была реализована самостоятельно с помощью системных компонентов и библиотеки для реактивного программирования RxJava [20], так как на этапе разработки ни одна из библиотек, реализующих MVVM на Android, не показалась надежной.

2.3 Архитектура серверной части приложения

Рисунок 2.5 - Архитектура сервера на примере некоторых классов



Как говорилось ранее, в задачи сервера входит заимодействие с клиентом через протоколы HTTPS и WebSocket. В контексте сервера классы, принимающие запросы от клиентской части приложения, играют роль слоя представления, ответственного за взаимодействие с внешним миром. Такие классы именуются в фреймворке Spring как Controllers. Эти классы хранят логику обмена информацией с клиентом, работы с FileStorage, предоставляющим доступ к файлам, а также Repository, который является оберткой для упрощенной работы с базой данных (рис. 2.5). Перед отправкой данных на клиент, сервер должен преобразовать их в понятную клиенту форму, поэтому, для преобразования объектов одного типа в объекты другого, типа используются Mappers.



Глава 3. Детали реализации приложения

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

3.1 Детали реализации клиентской части приложения

3.1.1 Использование RxJava

При разработке приложения был использован фреймворк RxJava [20], реализующий принципы реактивного программирования [21], в основе которого лежит паттерн Observer [22].Реактивное программирование позволяет оперировать потоками данных, используя многочисленные операторы обработки, фильтрации и изменения данных. Также, RxJava из коробки поддерживает переключение потоков выполнения кода по мере прохождения данных по потоку, что может быть использовано для работы с сервером и базой данных.Реактивное программирование используется на всех слоях мобильного приложения. Например, в виде потоков представлены: сообщения, получаемые через WebSocketот сервера; записи, получаемые из базы данных; действия с элементами пользовательского интерфейса; изменения состояния интернет-соединения; изменения ViewState в паттерне MVVM.

3.1.2 База данных

Для хранения данных на устройстве была выбрана СУБД SQLite [23]. Она является компактной, полностью покрыта тестами и встроена в фреймворк Android, поэтому для подключения СУБД не нужно будет добавлять в зависимости приложения дополнительную библиотеку. Однако, работа с SQLite напрямую требует написания большого количества однотипного кода, поэтому в качестве обертки над SQLite была использована легковесная библиотека StorIO[24].

StorIO позволяет описывать таблицы базы данных в виде data классов, доступных в языке Kotlin, с помощью аннотаций. Таким образом, в одном классе можно описать создаваемую таблицу в базе данных, а также тип, объектами которого другие классы будут оперировать для работы с базой данных. Например, на схеме 3.1. приведено описание таблицы сообщений в виде класса MessageEntity.

Схема 3.1 - Класс MessageEntity

Схема 3.2 - Метод get Conversation Message Query

Одной из удобных функций библиотеки StorIO, ради которых ее и стоит использовать, является возможность создания запросов к базе данных с помощью паттерна Builder [25].Например, можно описать запрос на получения всех сообщений в чате, отправленных после определенного момента (схема 3.2).

Всего в локальной базе данных мобильного приложения хранятся 3 не связанные между собой таблицы: сообщения, показатели здоровья, медицинские события. Таблица сообщений используется для хранения всей истории переписки, две другие таблицы - для обеспечения подхода Offline-first[10] при работе пациента с медицинской картой. Для каждой таблицы в приложении создается отдельный класс хранилища, наследуемый от BaseLocalStore, содержащего в себе удобные методы для работы с StorIO. Один из таких методов принимает на вход запрос к базе данных, а возвращает список объектов, полученных по запросу, в виде потока RxJava (cхема 3.3).

Схема 3.3 - Метод getAllByQuery

3.1.3 Подключение к серверу

Для отправки REST-запросов использовалась библиотека Retrofit [26]позволяющая описывать запросы к серверу в виде интерфейсов, реализация которых создается с помощью кодогенерации. Для примера, рассмотрим интерфейс Account RestApi для работы с аккаунтом, в котором описаны методы получения текущего аккаунта с сервера и обновления аккаунта на сервере (cхема 3.4).



Схема 3.4 - Интерфейс AccountRestApi

Как видно на схеме 3.4, Retrofit позволяет отправлять запросы на сервер буквально в несколько строк. Для создания запросов используются специальные аннотации, применяемые к методам и их параметрам. Возможность использования в качестве возвращаемого значения методов потоков данных RxJava и автоматическое преобразование Kotlin объектов в формат JSONи обратно делают использование этой библиотеки еще более удобным.

Однако, Retrofit не поддерживает протокол WebSocket, поэтому дополнительно была использована библиотека Scarlet [27], позволяющая описывать взаимодействие с сервером в похожем стиле с использованием протокола WebSocket. На схеме 3.5. представлен интерфейс, ответственный за получение от сервера и отправку на сервер сообщений.

Схема 3.5 - Интерфейс ChatSocketApi



3.2 Детали реализации серверной части приложения

3.2.1 База данных

Для хранения данных на сервере была выбрана СУБД MySQL [28]. Она широко распространена и поддерживается фреймворком Spring. Всего в базе данных на сервере хранится 9 таблиц (рис. 3.1).

За хранение данных аккаунтов пользователей отвечают таблицы «patients» и «doctors». Было принято решение разделить пользователей на два типа: пациент и врач, так как пользовательские сценарии для пациентов и врачей кардинально отличаются, и в будущем не предполагается создание регистрации аккаунтов, имеющих права на действия для обоих типов.

Пациенты в приложении могут инициировать общение со врачами через чат, для чего в базе данных сервера были созданы две таблицы: «conversations» и «messages». Таблица «conversations» связанас «patients», «doctors» и «messages» связямиone-to-many. Тоесть, у любого пользователя может быть сколь угодно большое число переписок, состоящих из сколь угодно большого числа сообщений.

Двумя другими таблицами в базе данных являются «body_parameters» и «medical_events». Они представляют собой записи пациента о показателях здоровья и медицинских событиях, и связаны с таблицей «patients» связями one-to-many. Таким образом, пациент может добавлять в приложение неограниченное число записей. Важной функцией приложения является возможность предоставления пациентом врачу доступа к медицинским записям:таблица «medical_accesses» хранит для пары пациент-врач доступные для предоставленные для просмотра типы записей.

Наконец, таблицы «oauth_access_tokens» и «oauth_refresh_tokens» используются для хранения токенов сессий пользователей, используемых для аутентификации по протоколу OAuth2.



Рисунок 3.1 - Схема таблиц базы данных на сервере

3.2.2 Использование SpringData

Механизм SpringData существенно облегчает взаимодействие с базой данных. Например, вместо описания таблица базы данных может быть описана в виде data классов, доступных в языке Kotlin. Для этого, класс должен быть унаследован от класса Persistable, являющегося частью SpringData, и содержать аннотации из пакета «javax.persistence», примененные к самому классу и его полям. Например на схеме 3.6. приведено описание таблицы сообщений в виде класса MessageEntity.



Cхема 3.6 - КлассMessageEntity

Схема 3.7 - ИнтерфейсDoctorRepository

Как видно на схеме 3.7, интерфейсDoctor Repository наследуется от интерфейса JpaRepository, являющегося частьюSpringData. За реализацию описанного интерфейса отвечает SpringData, создающий для каждого метода реализацию на чистом SQLв соответствии с названием метода. Если для названия метода невозможно сформировать SQL запрос, SpringData скажет об этом на этапе компиляции еще до запуска программы. Более того, многие методы, такие как получение или удаление записи из таблицы, предоставляются JpaRepository по умолчанию, что еще больше сокращает количество однотипного кода в проекте.

3.3 Детали реализации приложения в целом

3.3.1 Регистрация пользователей

Интерфейс регистрации и входа в аккаунт

Рисунок 3.2 - Экран «Приветствие»



Рисунок 3.3 - Экран «Приветствие» после изменения текущего действия

После успешного запуска программы откроется экран «Приветствие» (рис. 3.2). Пользователь имеет возможность создать новую учетную запись или войти в ранее созданную учетную запись, введя адрес электронной почты и пароль в поля ввода текста с надписями «Email» и «Пароль» и нажав на зеленую кнопку под полями ввода.

Во многих приложениях функциональности входа в аккаунт и регистрации представлены на разных экранах. Однако в нашем приложении данные, вводимые пользователем в этих двух случаях, абсолютно идентичны, поэтому было решено реализовать вход в аккаунт и регистрации на одном экране. Зеленая кнопка под полями ввода отображает действие, которое произойдет после нажатия на нее. Текущее действие может быть изменено нажатием на прозрачные кнопки с серым текстом снизу. Всего возможны 4 действия: «Войти как пациент», «Зарегистрироваться как пациент», «Войти как врач», «Зарегистрироваться как врач».



Алгоритм авторизации пользователей

Cхема 3.8 - Интерфейс AuthRestApi, ответственный за авторизацию пользователей

Для того, чтобы пользователь получал доступ только к доступным для него данным, необходимо продумать систему регистрации и последующей авторизации пользователей. В качестве протокола авторизации был выбран OAuth 2.0 [29].Для обеспечения безопасности передачи данных, все данные передаются между клиентской и серверной частями приложения с использованием протокола HTTPS.

Схема клиент-серверного взаимодействия авторизации пользователей состоит из трех шагов:

Получение данных аккаунта;

Получение access token иrefresh token;

Обновление access token.

Первые два шага происходят на экране «Приветствие» (рис. 3.2), когда пользователь вводит данные своего существующего или нового аккаунта.

На первом в шаге, в зависимости от того, хочет ли пользователь войти в существующий аккаунт или же создать новый, клиент вызывает методы сервера POST«/register» или POST«/login», передавая в качестве тела запроса объект JSON, хранящий в себе поля«email», «password»и «isDoctor». В ответ, сервер отправляет информацию аккаунта пользователя в формате JSON или ошибку. При ошибке, пользователю показывается соответствующее ошибке сообщение и схема завершается. Стоит отметить, что эти два метода являются единственными методами сервера, доступными без предоставления accesstoken.

На втором шаге, клиент вызывает метод сервера POST«/oauth/token», передавая с помощью типа данных «application/x-www-form-urlencoded» поля «password», «username»и «grant_type». Поле «password» - пароль пользователя, «username» - его адрес электронной почты, «grant_type»на этом шаге равен тексту «password», так как получение токена происходит по предоставлению пароля. На этом шаге, сервер проверяет, действительно ли в системе существует данный пользователь, и если он находит его, то возвращает JSON, содержащий поля «access_token», «refresh_token»и «expires_in», иначе - ошибку. В случае успеха, клиент сохраняет информацию аккаунта пользователя, accesstoken и refreshtoken в настройки приложения. Плюсом такой схемы является то, что пароль приложения не хранится на устройстве и не используется для получения доступа к методам сервера.

Наконец, на третьем шаге, происходит обновление accesstoken. Этот шаг происходит тогда, когда сервер в ответ на один из запросов клиента возвращает сообщение о том, что предоставленный accesstoken истек (код ошибки 401).Клиент вызывает метод сервера POST«/oauth/token», передавая с помощью типа данных «application/x-www-form-urlencoded» поля «refresh_token»и «grant_type», равных тексту «refresh_token». В ответ, сервер возвращаетJSON, содержащий поля«access_token», «refresh_token»и «expires_in», и клиент accesstoken и refreshtoken в настройках.

Логика обновления accesstoken на клиенте

Как было сказано ранее, для успешного выполнения любого запроса к серверу, кроме «/login»и «/register», требуется передача accesstoken вместе с запросом. Accesstoken передается на сервер в виде заголовка вида«Authorization: Bearer csaf41214safh214oiwuencr». На любой такой запрос сервер может ответить кодом ошибки 401, в случае чего клиент должен получить новый токен с сервера, используя refreshtoken, после чего отправить запрос заново. Однако, если делать это в месте вызова каждого запроса к серверу, количество однотипного кода в приложении существенно увеличится. Чтобы не нарушать правило «Don'trepeatyourself» [30], необходимо вынести описанную выше логику в отдельный класс.

Специально для таких целей, в библиотеке OkHttp [31],используемой в разработанном мобильном приложении, существует механизм Interceptors. Классы типа Interceptor отвечают за перехват запроса к серверу и ответа от него, дополняя запрос или обрабатывая ответ от сервера.

В нашем случае, класс Credentials Interceptor добавляет к запросу заголовок с текущим accesstoken, а в случае необходимости получает новый access token сервера, используя заголовок с refreshtoken, после чего отправляет запрос с использованием обновленного accesstoken заново.

3.3.2 Обмен сообщениями между пользователями

Интерфейс обмена сообщениями между пользователями



Рисунок 3.4 - Экран «Чат» Рисунок 3.5 - Экран «Чат» в условиях отсутствия интернет-соединения

Экран «Чат» содержит список всех сообщений чата, отсортированный по дате так, что последнее сообщение находится внизу списка, а наиболее ранее - вверху. Этот экран позволяет пациенту отправлять врачу текстовые сообщения и изображения. Также, существуют четыре типа системных сообщений - «Изменение пациентом настроек доступа врача к медкарте», «Отправка врачом записи в медкарту пациента», «Начало вызова», «Окончание вызова». По нажатию на сообщения первых двух типов происходит переход на экраны «Записи от врача» и «Врач», соответственно. Системные сообщения отправляются автоматически без каких-либо действий со стороны пользователей. По нажатию на имя врача происходит переход на экран «Врач».

При отсутствии интернет-соединения происходит отображение сообщений, сохраненных на устройстве. После восстановления интернет-соединения, состояние подключения будет автоматически синхронизировано с сервером без вмешательства со стороны пользователя. Под именем врача отображается текущее состояние подключения: «Подключено», «Обновление…» или «Ожидание подключения…».

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

Организация обмена сообщениями между пользователями

Было сформулировано несколько требований к формату клиент-серверного взаимодействия при обмене пользователями сообщениями в чате. Во-первых, сообщения должны передаваться мгновенно, без задержки. Во-вторых, клиент и сервер должны обмениваться лишь сообщениями текущего чата, а не всех активных чатов пользователя, что позволяет избавить клиентское приложение от необходимости фильтрации получаемых сообщений и делает систему более предсказуемой. Протокол STOMP над протоколом WebSocket удовлетворяет обоим требованиями, к тому же, он хорошо поддерживается фреймворком Spring. Однако, библиотек под Android, реализующих протокол STOMP, практически нет. В то же время, использование чистого протокола WebSocket в мобильной разработке достаточно распространено; существует множество библиотек под Android, облегчающих работу с ним. В разработанном мобильном приложении была использована библиотека Scarlet, позволяющая описывать взаимодействие с сервером в виде интерфейсов с помощью аннотаций (схема 3.5). Поэтому было решено использовать чистый протокол WebSocket над протоколом HTTPS, при этом немного расширив его, передавая при установлении соединения в заголовке c названием «recipient-uuid» идентификатор пользователя, с которым будет вестись общение.

Фреймворк Spring позволяет получить для текущего WebSocket соединения объект типа Principal, хранящий информацию о соединении. Унаследовав класс WebSocketPrincipal (схема 3.9) от класса Principal, можно хранить дополнительную информацию о соединении. 

Схема 3.9 - КлассWebSocketPrincipal

При конфигурации WebSocket соединения, возможно переопределить логику создания объекта Principal в методе «determineUser» (схема 3.10)для передачи в него данных, полученных из заголовков запроса на установление соединения.

Схема 3.10 - Метод determineUser

3.3.3 Аудио- и видеосвязь

Использование Jitsi

Одной из важных функций приложения в целом является возможность общения пациента с врачом через аудио- и видеосвязь. Написание платформы для видеосвязи с нуля отняло бы непозволительно большое количество времени, поэтому было использовано SaaSрешение, платформа Jitsi [32]. Она полностью бесплатна, имеет открытый исходный код и не требует наличия собственного сервера. Платформа построена так, что любой желающий может подключаться к публичным комнатам по ее названию. Однако очевидно, что наше приложение должно обеспечивать приватность и безопасность общения между врачом и пациентом. Поэтому, для создания имени комнаты используется класс UUID из пакета «java.util» позволяющий создавать такие идентификаторы, что вероятность получения доступа к комнате при таком подходе составляет [33].

Платформа Jitsi представляет SDKдля операционной системы Android, позволяющая буквально в пару строк отображать интерфейс необходимой комнаты. На рисунках 3.6 и 3.7 представлен пользовательский интерфейс при взаимодействии с комнатой.

Рисунок 3.6 - Экран «Звонок» Рисунок 3.7 - Экран «Звонок» при включенной камере

Система управлением состояния звонка

Участие пользователей в звонке должно происходить естественно и удобно с точки зрения пользовательского интерфейса. Например, в одно нажатие доктор должен иметь возможность инициировать звонок и завершить его, пациент - принять или отклонить приглашение (рис. 3.8 и 3.9). После выхода одного из пользователей из разговора необходимо закрывать экран «Звонок» на обоих устройствах.

Рисунок 3.8 - Экран «Исходящий вызов»

Рисунок 3.9 - Экран «Входящий вызов»

Однако SDKJitsi для Android предоставляет лишь возможность взаимодействия пользователя с комнатой. Логика входа и выхода из комнаты должна быть реализована самостоятельно. Таким образом, необходимо было создать систему управления состоянием текущего звонка. Для этого был применен концепт StateMachine [34]. Диаграмма состояний звонка в системе представлена на рисунке 3.10.

Рисунок 3.10 - Диаграмма состояний звонка

Концепт StateMachine удобен своей простотой реализации и предсказуемостью. Звонок может находиться в одном из трех состояний: Initiated (Инициирован), Started (Начат), Cancelled (Закончен). Сервер в зависимости от происходящих событий меняет текущее состояние звонка, уведомляя об этом клиентские приложения, отображающие пользовательский интерфейс в соответствии с текущим состоянием. Клиент-серверное взаимодействие в этом случае ведется по протоколу WebSocket, используя текущее соединение для чата.

После нажатия врачом на кнопку «Позвонить» на экране «Чат» (рис. 3.4), сообщение о произошедшем действии отправляется с клиента на сервер. Сервер решает, что текущее состояние звонка меняется на «Initiated»и отправляет сообщение о произошедшем изменении состояния звонка на все связанные со звонком клиенты. После этого, мобильное приложение открывает для врача экран «Исходящий вызов» (рис. 3.8), а для пациента - экран «Входящий вызов» (рис. 3.9).

Если пациент принимает вызов на экране «Входящий вызов», звонок переходит в состояние «Started»и у обоих пользователей открывается экран «Звонок» (рис. 3.6).

В случае, если любой из пользователей в какой-либо момент времени решает прекратить звонок, либо же WebSocket соединение одного из пользователей закрывается по какой-либо причине, система переходит в состояние «Cancelled»; у обоих пользователей закрываются все экраны, связанные со звонком.

3.3.4 Синхронизация записей медкарты

Одна из главных функций приложения - создание, редактирование и удаление записей медкарты пациентом. Записи делятся на два основных типа: «Событиe» и «Показатель здоровья». Для удобства пользователя, был реализован подход Offline-first[10], таким образом, при обновлении, записи будут сохранены в локальную базу данных, а затем синхронизированы с сервером. При этом, события двух типов синхронизируются отдельно.

Для осуществления такого подхода, у каждой записи в базе данных есть специальные поля. Поле«isDeleted»говорит о том, удалена ли запись. Необходимость в таком поле существует, поскольку удаленная запись должна быть синхронизирована с сервером и впоследствии перестать отображаться на всех устройствах, поэтому просто удалить запись из базы данных не получится. Второе поле называется «isChangedLocally» и говорит о том, изменена ли запись после последней успешной синхронизации, для него устанавливается значение true после каждого изменения записи. Вне зависимости от того, доступно ли интернет-соединение во время изменения записи, она будет сохранена в локальное хранилище.



Рисунок 3.11 - Экран «События»

Рисунок 3.12 - Экран «Показатели»

Во время открытия экранов «События» (рис. 3.11) и «Показатели» (рис. 3.12) синхронизируются записи соответствующих типов.

Синхронизация записей двух типов происходит отдельно с использованием разных POST запросов «/synchronizeEventsForPatient»и «/synchronizeParametersForPatient», но по одному алгоритму:

Клиент посылает на сервер все записи, у которых поле «isChangedLocally» равно true, а также время последней синхронизации;

Сервер фиксирует время начала синхронизации по своему времени;

Сервер сохраняет полученные данные с свою базу данных с временем изменения, равным началу синхронизации;

Сервер возвращает на клиент записи, сохраненные в базу данных сервера с момента последней синхронизации клиента вместе с временем начала синхронизации;

Клиент сохраняет в локальной базе данных полученные с сервера записи, а также обновляет время последней синхронизации.

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

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



3.3.5 Система обмена медицинскими данными

Рисунок 3.13 - Экран «Права врача»

Рисунок 3.14 - Экран «Записи пациента»



Одним из главных отличий разработанного продукта от аналогов является система обмена медицинскими записями между врачом и пациентом.

Во-первых, пациент может дать врачу доступ к определенным типам записей своей медкарты, таким как «Вес»,«Сахар в крови», «Аллергия», выбрав их на экране «Права врача» (рис. 3.13).После этого, врач сможет просматривать их на экране «Записи пациента». Записи всех остальных типов будут недоступны для врача. Стоит отметить, что для врача записи не сохраняются на устройстве, так что он не сможет просматривать записи, которые были доступны пациенту, но теперь доступ к ним запрещен. После изменения настроек доступа для врача, соответствующее сообщение будет отображено на экране «Чат» (рис. 3.4).

Рисунок 3.15 - Экран «События от врача»

Во-вторых, врач может отправить пациенту медицинские события, которые будут отображены у пациента на экране «События от врача». После получения записи, пациент может добавить ее в свою медкарту или удалить, поэтому для отправки событий врачу не требуется никаких разрешений. События, полученные от врача, синхронизируются точно так же, как и обычные события медкарт.

3.3.6 Работа с изображениями

Отображение изображений

Рисунок 3.16 - Экран «Аккаунт»



Рисунок 3.17 - Экран «Чат» после для пациента открытия изображения

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

В качестве библиотеки для отображения и кеширования изображений, в мобильном приложении используется библиотека Picasso [35], позволяющая отображать фотографии с устройства и из сети по urlс помощью паттерна Builder (схема 3.11).

Схема 3.11 - Использование библиотеки Picasso

Получение изображений с устройства и загрузка на сервер

Пользователь, загружающий изображение на сервер, может сделать это двумя способами: с помощью стандартного приложения для создания фотоснимков или из галереи. В обоих случаях используется стандартные механизмы фреймворка Android: вызывается метод класса Activitystart Activity For Result, в который передается Intent, представляющий действие, которое необходимо совершить. Результат действия затем обрабатывается в методе класса Activityon Activity Result. В случае успеха, мы получаем объект типа Bitmap, с которым дальше будет вестись работа.

Для загрузки изображения на сервер, полученный объект типа Bitmap сначала сохраняется во временное хранилище приложения и преобразуется таким образом в объект типа File, который затем преобразуется в объект типа MultipartBody.Part и отправляется на сервер с помощью библиотеки Retrofitи типа содержимого «multipart/form-data» (схема 3.12).

Схема 3.12 - Интерфейс Account Rest Api

Сохранение изображений на сервере

После получения изображения сервером, изображению присваивается уникальный идентификатор, с которым оно сохраняется в файловое хранилище, а его идентификатор передается на клиент для отображения. Передача идентификатора на клиент вместо полного url-адреса делает систему более гибкой и позволяет в будущем изменить адрес сервиса без необходимости изменять сохраненные в базе данных устройства адреса изображений.

Метод обработки запроса на получение изображения представлен на схеме 3.13.

Схема 3.13 - Метод обработки запроса на получение изображения



Заключение

архитектура приложение медицинский java

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

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

...