Файл: Технология «Клиент-сервис».pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 29.02.2024

Просмотров: 44

Скачиваний: 0

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Содержание:

Введение

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

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

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

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

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


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

  1. Проанализировать существующие решения;
  2. Разработать алгоритм работы и определить функциональность приложения;
  3. Разработать серверное API, определить основные сущности бизнес-логики сервера;
  4. Определить архитектуру и используемые библиотек на клиентской и серверной частях;
  5. Создать прототипы дизайна и навигации;
  6. Разработать клиентскуючасть приложения;
  7. Разработать серверную часть приложения;
  8. Протестировать и отладить приложение;
  9. Написать техническую документацию.

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

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

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

Рисунок 1.1. «Яндекс.Здоровье»Рисунок 1.2. «Doc+» Рисунок 1.3. «DocDoc»

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

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


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



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

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

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

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


 







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

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


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

Таким образом, исходя из обзора приведенных выше Android приложений, разработка нового программного продукта имеет смысл. Каждое из рассмотренных приложений имеет недостатки в сценариях общения врача с пациентом или ведения медкарты. Разработанный программный продукт «e-Doctor» обладает набором функций, на момент разработки программы не доступным ни в одном приложении на рынке. Дополнительно стоит отметить, что клиентская часть приложения полностью локализована на русский и английский языки, а ее интерфейс спроектирован с учетом MeterialDesign. Сравнение разработанного приложения с конкурентами представлено на рис. 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. Схема Чистой Архитектуры[15]