2023ВКР750301ИСАКОВ

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

Позже эти механизмы найдут свое применение в исключении из анализа некачественных дневников и синхронизации времени перекусов с фактическим ростом кривой ППГО.

В приложении предусмотрено информирование и обучение пациента,

для этого подготовлены специальные PDF материалы по теме ГСД, ссылки на методическую базу и многое другое (см. рисунок 29).

Рисунок 29 – Экранные формы обучающих материалов

Раздел «Дополнительно» содержит все, что трудно поддается систематизации: помощь пациенту по техническим вопросам, связанными с ошибками работы приложения, сведения о версии приложения, изменениях в последних обновлениях и так далее. Здесь же расположен раздел о самом пациенте, назначенном лечащем враче, дате начала беременности, росте и весе до беременности (см. рисунок 30).

81

Рисунок 30 – Экранные формы дополнительных разделов

Экспорт накопленной информации предусмотрен путем отправки Excel

дневника врачу по почте или в мессенджере, как это продемонстрировано на рисунке 31. Сформированное электронное дополнительно письмо отражает статистику регулярности заполнения пациентом электронного дневника.

Рисунок 31 – Экранные формы экспорта электронного дневника

В данном подразделе были описаны результаты работы над созданием мобильного приложения удаленного мониторинга.

На рисунках 32 и 33 представлены образцы получившихся в результате экспорта электронных таблиц Excel.

82

Рисунок 32 – Стандартизированный вид электронной таблицы измерений сахара и инсулина

Цветовая дифференциация измерений сахара натощак придерживается следующего правила: низкий (меньше 4) – синий, нормальный (от 4 до 5) –

желтый, и высокий (больше 5) – красный. Для всех остальных измерений границы нормы чуть больше: высоким сахар считается от 7.

Рисунок 33 – Стандартизированный вид электронной таблицы приемов пищи

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

жиры, углеводы, а также энергетическая ценность, ГИ и ГН.

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

83

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

Приложение доступно для скачивая в магазине приложений App Store

для регионов Российской Федерации и Республике Беларусь. Политика конфиденциальности доступна на странице приложения в App Store (https://apps.apple.com/ru/app/диа-компаньон/id1614880612).

3.2 Разработка базы данных мобильного приложения

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

Клиентская реализуется применением встроенной СУБД SQLite, ее задача хранить локальные данные, критически важные для бесшовной непрерывной работы приложения, а также временную информацию,

накапливающуюся в ходе мониторинга. Такими временными данными могут быть, история редактирования и копии удаленных строк. Они могут храниться вплоть до тридцати дней или до тех пор, пока пациент не отправит электронный дневник врачу. К критически важной инфраструктуре приложения относятся таблицы продуктов питания, приемов пищи, а также сахаров и инсулина. Помимо этого, в БД содержатся записи физической активности / сна, измерений веса, уровня кетонов в мочевине и т.д.

Для создания серверной части было решено использовать СУБД

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

84

Рисунок 34 – Структура клиент-серверной базы данных

В таблице users представлена основная информация о пациентах,

принимающих участие в исследовании или назначенных на удаленный мониторинг по иным причинам, поэтому в таблице предусмотрен столбец app_type.

Таблица records содержит в себе некоторое абстрактное отображение всех записей всех пациентов. В ней предусмотрен составной первичный ключ из трех полей: id_user (id пациента), table (название таблицы) и id_table (id

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

Также таблица содержит два дополнительных столбца – date_time и date_time_submited, содержащих указанное пациентом и фактическое время создания записи. По умолчанию в таблице records индексируется только уникальное поле id, но для ускорения работы SQL запросов к нескольким таблицам было решено проиндексировать и оставшиеся поля. Процедура индексирования всегда немого повышает требования к памяти, но разительно увеличивает скорость работы.

Таблицы: sugar_level_table, insulin_table, workout_table, sleep_table, ketons_table, weight_table – устроены схожим образом. В них есть внешний по отношению к таблице records ключ id, а также дополнительные поля,

85

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

таблица sleep_table – продолжительность сна.

Таблица приемов пищи meal_table представляет собой набор строк,

вида: {тип приема пищи: обед; уровень сахара до: 5.5; уровень сахара после: 6.8}. Каждой такой строчке соответствует первичный ключ – id. Информация о составе приема пищи содержится в связанной по внешнему ключу id_meal

таблице food_in_meal_table, которая в свою очередь связана по полю food_id с id продуктов питания, хранящихся в food_data. Таблица food_data

представлена в урезанном виде, т.к. хранит более 50 различных нутриентов.

3.3 Разработка серверного API

Для соединения серверной и клиентской части мобильного приложения используется технология известная как интерфейс прикладного программирования (API – Application Programming Interface). На стороне веб-сервера создается несколько конечных точек (Endpoint), часто, они представляют собой методы, к которым приложение обращается по некоторому URL адресу. Например, https://diacompanion.ru/login или https://diacompanion.ru/signup. В первом случае конечной точкой будет процедура login, во втором – signup. Оба метода послужат для регистрации и аутенфикации пользователя. Подразумевается, что идентификация включена в механизм аутенфикации.

Для защиты от подделки межсайтовых запросов СSRF (Cross Site Request Forgery) решено было использовать стандарт JWT (JSON Web Token).

В таком случае, перед тем как приложение сможет запросить или отправить что-либо через API, ему потребуется запросить у пользователя логин и пароль,

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

86

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

В разработанном приложении алгоритм планируется реализовать через библиотеку Simple JWT, упрощающую работу с DRF (Django REST Framework) для Django веб-приложений. Сам сервер должен будет иметь следующую архитектуру (см. рисунок 35).

Рисунок 35 – Структура взаимодействия клиентского приложения с

Django сервером

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

направленные к серверу не через 443 порт, должны либо отсекаться, либо перенаправляться, т.к. только 443 порт поддерживает TSL (Transport Security

87

Layer) шифрование и соответствует протоколу передачи гипертекста HTTPS.

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

Django-приложение формирует ответ в некоторой доступной для обработки веб-сервером форме, это может быть текстовый файл JSON / XML,

программный код веб-страницы и т.д. Полученный от Django приложения ответ веб-сервер отправляет по обратному маршруту на клиентское приложение.

Django приложение располагает некоторым набором функций и подключенной базой данных PostgreSQL. Т.к. Python приложения не могут напрямую взаимодействовать с Nginx или Apache серверами, для синхронизации их работы используется промежуточный WSGI (Web Server Gateway Interface) сервер Gunicorn. Для поддержания непрерывной работы приложения и оперативного реагирования используется Supervisor. С его помощью администратор может автоматизировать поведение сервера в некоторых стандартных ситуациях, таких как, например, перезапуск программного сервера после выключения физического на момент проведения технических работ.

На текущий момент разработано Django приложение и необходимая для работы API база данных PostgreSQL. Результаты упакованы в Docker образ,

который можно запустить на VPS / VDS (Virtual Private Server). Выбор поставщика услуг, оплата и разворачивание образа отдельная процедура, не вошедшая в обозрение этой исследовательской работы. Конечному заказчику придется решить эту задачу самостоятельно.

88

бактериальных признаков

Данные микробиома были получены у 96 пациенток (65 женщин с ГСД и 31 женщина без нарушений углеводного обмена) методом секвенирования рибосомальной РНК кишечной микробиоты. Прочтения РНК подверглись укорочению слева на 20 пар оснований и справа до 180 пар оснований при помощи программы qiime2 версии 2020.8. Таким образом была получена таблица соответствия числа прочтений бактерий в каждом образце. С целью определения таксономического состава полученных бактериальных признаков путем сравнительного анализа последовательностей гипервариабельного региона V4 гена 16SrRNA был использован байесовский наивный классификатор. Модель построена на основе открытой базы данных референсных последовательностей РНК с известным таксономическим составом GreenGenes 515F/816R.

К аннотированной таблице были применены следующие фильтры: по частоте встречаемости признака в образцах (минимум в трех) и по числу копий бактериальных признаков (минимум 20). В результате для построения модели прогнозирования ППГО было отобрано 780 бактериальных признаков

(показателей представленности бактерий в образце), преобразованных методом центрированного преобразования логарифмического отношения.

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

мгновенный уровень сахара в крови до еды, снятый ручным глюкометром,

данные пациенток (антропометрические данные, данные общесоматического,

акушерского анамнеза и анамнеза жизни), данные анкетирования о привычном питании и физической активности до и во время беременности.

89

В виду высокого значения проверки качества вводимых пациентками

данных о приемах пищи при самоконтроле диеты, были применены критерии

иалгоритмы автоматической оценки качества дневников питания,

разработанные и описанные в работе ранее.

3.4.1 Метод регрессии опорных векторов

Всего было реализовано пять моделей для отобранных исследовательской группой ключевых параметров, характеризующих ППГО: BG60, BG120, BGMax, AUC120 и iAUC120. Показатели группы BG отражают абсолютное значения уровня сахара спустя некоторое время после приема пищи и измеряется в ммоль/л, в то время как AUC является оценкой площади под кривой ППГО и измеряется в ммоль/л*час. Из исходных параметров, по методу взаимной информации, для каждой выходной величины были взяты лишь 10% от предикторов, внесших наибольший вклад в показатель информативности Шеннона. Всего для каждой модели получилось 76

пациентов и 3887 записей приемов пищи.

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

Каждая модель (см. таблицу 2) следовала одному и тому же алгоритму обучения, что дает возможность прямого сравнения их результатов: 1) отбор строк, для которых искомая выходная величина не является пропущенным значением; 2) стандартизация; 3) импутация пропущенных значений предикторов по методу k-NN; 4) отбор наиболее весомых клинических параметров по методу взаимной информации; 5) построение модели.

90