2021ВКР750107ИСАКОВ
.pdf3.Разработать составные части веб-приложения: базу данных, модель предсказания уровня сахара в крови и пользовательский интерфейс;
4.Подготовить сопроводительный материал.
Объект исследования – система удаленного мониторинга диеты и физической активности пользователя.
Предмет исследования – разработка программной реализации системы удаленного мониторинга диеты и физической активности пользователя, ее компонентов, и их экспериментальная апробация.
Область применения. Предложенное веб-приложение можно интегрировать в медицинских исследовательских центрах, а также больницах и поликлиниках, для непрерывного мониторинга и информационной поддержки больных СД.
11
1 АНАЛИЗ СОВРЕМЕННОГО СОСТОЯНИЯ ПРОБЛЕМЫ РАЗРАБОТКИ ВЕБ-ПРИЛОЖЕНИЙ ДЛЯ УДАЛЕННОГО МОНИТОРИНГА
1.1 Общие вопросы внедрения систем удаленного мониторинга
Увеличение распространенности хронических заболеваний во всем мире представляет серьезную проблему для лимитированного потенциала служб здравоохранения. Одним из современных подходов к профилактике роста числа хронических заболеваний, оптимизации лечебного процесса и повышения качества жизни является внедрение облачных, мобильных и иных e-Health технологий, принцип работы которых базируется на периодическом анализе диагностической информации, детекции отклонений от нормы и предоставлении рекомендаций посредством сети Интернет. Однако,
концепция несет в себе ряд проблем при интеграции в клиническую практику,
например: обучение медперсонала, выделение значительных средств из бюджета на покупку и отладку при первом запуске, а также сложность разработки, в связи со спецификой медицинских приложений.
1.1.1 Консервативность медицинской среды
Насущные проблемы современного здравоохранения, среди которых можно выделить: оперативность оказания услуг и их доступность, нехватка ресурсов и, как следствие, рост затрат, способствовали переносу части услуг в активно развивающуюся интернет сферу. Однако, по мнению исследователей из Гонконгского университета (специальный административный район КНР)
и университета Юты (США), использовавших в своих исследованиях модель принятия технологий (TAM – Technology Acceptance Model) в рамках теории запланированного поведения (TPB – Theory of Planned Behavior), для наращивания уверенного темпа роста числа внедренных в клиническую практику технологий необходимо, чтобы администрация клиники решала вопросы адаптации технологии среди врачей, играющих решающую роль в
12
процессе ввода [1, 2]. Как известно, медицинский персонал имеет приобретенный за годы обучения и практики набор паттернов ухода,
наблюдения и постановки диагноза. В силу объемности традиционных программ обучения, времени на ознакомление с существующим кластером электронных технологий не остается. Как отмечают шотландские врачи в ходе исследования отношения к электронному здравоохранению врачей и медсестер [3] наиболее значимой проблемой больше, чем у половины опрошенных (55%), стало отсутствие подготовки. На освоение расширенного инструментария, требуется дополнительное время, которое, как подразумевается, врачи выделят либо в ущерб рабочему времени, либо же из личного времени. По итогам того же исследования в результате перехода на удаленную работу выросла нагрузка на терапевта/медсестру (43%). Вероятно,
в силу неосведомленности о принципах передачи информации большинство опрошенных также беспокоил вопрос сохранения конфиденциальности персональных данных. Сложившаяся ситуация может быть решена краткосрочными тренингами на базе собственного медицинского центра при сотрудничестве с производителем программного обеспечения, как это уже происходит при вводе в эксплуатацию медоборудования. Повысить заинтересованность врача и рейтинг доверия к использованию телемедицинских технологий возможно путем интеграции клинических экспертов на каждом этапе создания приложения.
Нельзя не сказать и о системах взаимодействия врачей друг с другом. В
силу занятости, недостатка опыта и нехватки профильных специалистов в развивающихся странах возникла необходимость консультации заграницей для постановки диагноза. Австралийские исследователи отмечают, что за исследуемый период было проведено 125 успешных консультаций [4]. Они касались широкого круга специальностей, например, ортопедия – 17%,
дерматология – 16%, акушерство и гинекология – 11%. В то же время международная телемедицина открывает возможности удаленной работы врачей, например, из Индии в качестве экспертов расшифровки снимков
13
компьютерной томографии, сделанных клиникой в США, и могут быть в дальнейшем использованы врачом терапевтом для постановки диагноза. При этом ключевым вопросом, вставшим на пути развития интернациональной медицины, стало лицензирование специалистов. В Индии в рамках решения вопроса о регулировании экспорта услуг электронной медицины рассматриваются возможности взаимного признания странами медицинской лицензии, выданной родной страной врача, или введение ограниченной лицензии, которая бы позволяла осуществлять практику через лечащего врача в стране, где проживает пациент [5].
1.1.2 Дороговизна приобретения и наладки телемедицинских систем
Как уже отмечалось ранее, телемедицинские технологии призваны сократить рост затрат на здравоохранение. Однако, недавнее исследование [6]
в США показало, что из-за высокой стоимости начальных вложений (от 16000
до 36000 долларов США) врачи, оставшиеся без финансовой поддержи, с
большей вероятностью откажутся от внедрения телемедицинских систем.
Сопутствующей задачей стало определение стоимости услуг, оказанных посредством сети Интернет. Аналогичная ситуация коснулась и стран членов Европейского Союза (ЕС). Удаленное консультирование в Европейском регионе не столь активно субсидируется в силу небольшого числа врачей общей практики, предлагающих услуги электронного здравоохранения;
относительно небольшого числа интернет-пользователей, воспринимающих интернет, как важный канал получения информации о здоровье [7] и
дороговизны введения в эксплуатацию электронных систем мониторинга [8].
Ведь в итоговую стоимость, помимо покупки веб-приложения, войдут и ежемесячная оплата серверов, и их периодическое обслуживание, а также создание межинституциональной системы электронных дневников пациентов,
затраты на обучение медперсонала и, вероятно, сопутствующие статьи расходов: системные администраторы, оперативный персонал, менеджеры и бухгалтеры. Отсюда становится понятной причина невнимательной оценки
14
экономических преимуществ электронной медицины. Однако, профессор государственного университета Оклахомы, описывая ряд статей бюджета,
расходы на которые можно сократить, приходит к выводу, что в сельских городах США выгода от применения телемедицинских технологий составила до 1,3 миллионов долларов США ежегодно и порядка 522 тысяч долларов США в среднем [9]. В рамках другого исследования [10] оценивалась экономическая эффективность десяти приложений и сайтов электронного здравоохранения в Европе, т.е. в развитой урбанистической среде. Немецкие ученые приходят к выводу, что все системы принесли устойчивую чистую прибыль, а среднее время, необходимое для того, чтобы общие выгоды превысили общие затраты, составило пять лет. Таким образом можно охарактеризовать вклад в e-Health системы как долгосрочный, а в зависимости от темпов развития интернета и роста числа практикующих удаленное консультирование врачей, выбрать умеренную или же агрессивную стратегию долгосрочного инвестирования.
1.1.3 Доступность систем удаленного мониторинга для людей
разного возраста и физических особенностей
Немаловажно учитывать возраст пациента, например, повышая интерактивность, руководствуясь детской психологией, и наоборот,
максимально упрощая, в случае возрастной категории пользователей. В
исследовании, проведенном департаментом психологии и питания государственного университета Юты, геймификация приложений показывает значительный прирост заинтересованности среди детей, посещавших начальную школу: потребление фруктов увеличилось на 66%, а потребление овощей – на 44% по сравнению с базовым уровнем, см. рисунок 1 [11].
15
Рисунок 1 – Оценка потребления фруктов и овощей по сравнению с базовым уровнем
Другое исследование [12], направленное на описание траекторий нормального когнитивного старения, указывает на снижение скорости реакции, памяти и способностей к рассуждению у людей после 60 лет, см.
рисунок 2. При этом согласно эндокринологическому исследованию [13],
проведенному в США, сахарный диабет выявлен у 10,9 миллиона взрослых в возрасте 65 лет и старше, и, по прогнозам, это число достигнет 26,7 миллиона к 2050 году, что означает 55% всех случаев диабета. Для таких возрастных пациентов нагруженный рекламными интеграциями, динамичный и малознакомый интерфейс ухудшает общее впечатление от использования приложения. Затронем также неоднозначный вопрос напоминаний. В одном из исследований ученые приходят к выводу, что пациенты с диабетом,
получавшие мобильные уведомления, продемонстрировали лучшие показатели самоконтроля [14]. Хотя на этот счет есть и альтернативное мнение, исследователи из Вашингтонского университета оценивают автоматические уведомления как раздражающие [15].
16
Рисунок 2 – Кривые нормального когнитивного старения Кроме того, медицинское приложение должно адаптироваться под
пользователя, меняя цветовую гамму при дальтонизме – врожденном или приобретенном нарушение зрения, при котором проявляется неспособность глаза различать один или несколько основных цветов, оттенков. Сложность внедрения заключается в использовании разработчиком средств имитации дефицита цветового зрения [16], что позволяет легко избежать дефектного цветового диапазона. Возможно также использование систем компенсации цвета для дальтоников [17].
При полной или частичной потере зрения возможно использование специальных браузерных программ чтения с экрана. В некоторых случаях
Safari и Google Chrome предлагают перевести страницу в режим для чтения,
внутри которого встроен скринридер. Аналогичного эффекта можно добиться,
используя команды голосового помощника. Например, голосовой ассистент
Siri по команде «Читать экран вслух» озвучит выбранный текст или все содержимое экрана [18]. Однако, ни один из приведенных вариантов не будет работать, если использовать семантически неграмотные теги в ходе верстки
HTML (язык разметки гипертекста) шаблона страницы. Подобное
17
ограничение сложнее всего, а значит и дороже, реализовать в уже готовых продуктах, в то время как на стадии разработки учесть особенности семантики разных функциональных блоков веб-приложения не составит проблем.
1.2 Особенности работы с данными
В настоящее время существуют некоторые многоаспектные системы оценки здоровья человека, такие как Apple Health или Samsung Health. Однако используемые ими каналы обмена информации с медицинскими учреждениями частично или полностью недоступны на территории Российской Федерации [19]. Кроме того, специалистам важно учитывать, что зачастую разработчики при создании локальной интеграции приложения с медицинским учреждением на базе разработок крупнейших представителей рынка, таких как Apple HealthKit или Samsung Health SDK (Software Development Kit), выделяют только широко известные пользователям макроэлементы и нутриенты. В попытках скомпенсировать отсутствие редких продуктов, а также обширный пласт блюд, приготовленных по индивидуальным рецептам, пользователю может быть предложено на свое усмотрение ввести информацию о приеме пищи, что отрицательно скажется на достоверности и воспроизводимости результатов мониторинга [20]. Также часть сектора разработчиков предпочитают целиком полагаться на открытые базы данных, например, Fat secret. Такой подход может быть оправдан, однако, наше веб-приложение использует закрытую отечественную базу данных, собранную профессионалами для кроссплатформенного проекта ДиаКомпаньон при поддержке гранта Российского научного фонда (проект №15-14-30012) [21].
1.2.1 Выбор базы данных и формата хранения записей
Внутри базы данных записи могут храниться в любом формате, хотя обрабатывать и выводить во внешние приложения удобнее разные типы данных. Например, извлекая числовой формат данных из полей белков, жиров
18
и углеводов, рассчитывая скользящее среднее в Python и выводя в виде текста в Excel таблицу. Подобный подход позволяет избежать ошибок неверного определения формата данных Microsoft Excel. Чаще всего программа выдаст ошибку «неверный формат даты» или автоматически преобразует число.
Проблема заключается в разделительном знаке дробной части числа, в Python,
по умолчанию – это точка, в то время как в Excel – запятая. Однако, Excel не единственный получатель, нередко данные передаются по пути «клиент – сервер – клиент». В таком случае формат данных на выходе может сильно отличаться от того, в каком он был сохранен изначально. Специально для таких случаев в практику были введены словари, где ключом может выступать слово, а значением – любой формат данных. Словари Python совместимы с
JSON (JavaScript Object Notation) форматом данных, поэтому чаще всего при отправке переменных в браузер, с последующей обработкой средствами
JavaScript, используются словари, например: JSON.parse('{{ doc | tojson }}'), со стороны клиента и jsonify({"Message": "ИМТ записан"}), со стороны сервера,
где ИМТ – индекс массы тела. Также возможен вариант преобразования набора объектов в словарь со стороны клиента методом JSON.stringify(ИМТ: 18.5, масса: 60, рост: 181). В последнем случае со стороны сервера на Python
версии 3.8 и выше работа с принятым JSON данными ничем не отличается от действий со словарями. Спецификация JavaScript меняется год от года, методы
JSON.parse() и JSON.stringify() на данный момент являются предпочтительней устаревшего варианта tojson().
Для того, чтобы определиться с выбором базы данных (БД) необходимо прежде всего четко обозначить различие между системой управления базами данных (СУБД), как совокупности программных средств для манипуляции содержимым БД, и непосредственно базами, как совокупностями данных. По способу доступа к базам данных СУБД делятся на:
•Файл-серверные
•Клиент-серверные
•Встраиваемые
19
Наиболее простым для реализации вариантом стала встраиваемая SQLite
база данных. В таком случае на серверном компьютере хранился бы один файл реляционной базы данных, а в качестве СУБД выступала бы подключаемая библиотека. Прикладная программа и БД взаимодействуют через специализированные программные интерфейсы приложений (API). Такой подход уменьшает накладные расходы, время отклика и упрощает программу,
не требуя профессионального администрирования. Общая архитектура приложения изображена на рисунке 3. Однако, БД не рассчитана на многопользовательское подключение, SQLite позволяет нескольким пользователям читать файл одновременно, но не записывать (хотя возможно реализовать автоматическое повторение попыток записи в течении заданного периода). Чаще всего SQLite базы используют для локального хранения информации, например, в мобильных приложениях для сохранения кэша данных. Для решения задачи многопользовательского доступа к БД можно рассмотреть MySQL СУБД. Она относится к разряду клиент-серверных и обрабатывает все клиентские запросы централизованно. Недостаток такого подхода заключается в повышенных требованиях к серверу, а значит, его удорожание. С другой стороны, она обеспечивает более низкую нагрузку локальной сети, высокую надежность и безопасность. Оптимальным методом было бы сочетать сильные стороны обеих СУБД, производить считывание данных по каждому из блюд в локальной SQLite, а ведение пользовательских записей осуществлять через MySQL.
Рисунок 3 – Клиент-серверная архитектура приложения
20