AI и Medtech. Даниил Васильев
@medtech_ai
AI и Medtech. Даниил Васильев
Внедрение данных с трекинговых устройств в контекст диалогового ассистента
Мы последовательно расширяем персонализацию ассистента «Я здоров» на данных о здоровье пользователя.
Сейчас он работает с данными медкарты, долгосрочной памяти и дневников — показатели здоровья, приём препаратов и питания.
Сейчас мы прорабатываем следующий шаг — данные с трекинговых устройств.
Скоро у нас появятся интеграции с Apple Watch и Google Health Connect. Далее по плану — Oura, Whoop, Garmin и другие.
Цель интеграции — обогатить этими данными ассистента и рекомендательную систему — и сделать ответы и рекомендации ещё персональнее.
Что мы поняли про данные трекинговых устройств и как планируем внедрять их в контекст ассистента и рекомендательной системы
Эти данные, конечно, не обладают клинической точностью лабораторных биомаркеров и обследований.
Зато их много: они собираются каждый день, непрерывно, без участия человека.
Мы изучаем структуру данных, которые возвращают разные типы устройств. На что эти данные влияют и как связаны между собой. Как одни и те же показатели интерпретируют разные производители.
Разобрали модель Google SensorFM, которая на основе данных с трекеров генерирует медицинские инсайты.
Данные с трекеров условно можно поделить на 3 группы:
Показатели — пульс, HRV, SpO₂, температура кожи и так далее.
События — сон, тренировки, ходьба, активность.
Показатели привязываются к событиям.
Расчётные показатели вендоров — восстановление, качество сна, стресс и другие. Это алгоритмические показатели, которые каждый производитель считает по своей закрытой модели.
Нельзя просто передать в контекст модели данные с трекеров
Во-первых — они просто засорят контекст своим количеством.
И, что ещё хуже, модель будет выдумывать взаимосвязи и корреляции, которых нет, и уверенно их объяснит.
Что неприемлемо для медицинского ассистента.
Этот же вывод есть в статьях разработчиков SensorFM. Передавать в языковую модель сырые данные с трекеров не просто бессмысленно, а вредно.
Наш общий подход и концепция решения
На нашей стороне формируем единую структуру данных, по которой раскладываем все полученные с устройств показатели. Отдельно храним показатели, события и алгоритмические показатели вендоров.
Собираем базу диапазонов общих нормативных значений показателей с учётом пола, возраста и других параметров.
При оценке показателей трекинговых устройств часто значение имеют динамика и отклонения от средних значений в периоде.
Поэтому по каждому показателю рассчитываем среднемедианные значения пользователя за прошедшие периоды.
Рассчитанные средние значения группируются по разным признакам и событиям, например, будни/выходные, покой/нагрузка, фазы женского цикла.
На основе текущих показателей, общих нормативов и средних значений периодов математической моделью формируем инсайты, например: выход показателя за границы общего норматива, отклонение от среднего показателя пользователя или сдвиг тренда.
Добавляем базу правил интерпретации трекинговых данных на основе клинических стандартов и профильных медицинских статей.
По-простому — это правила, описывающие доказанные связи медицинских отклонений и факторов риска с показателями и событиями с трекера.
И эти инсайты уже отправляем в контекст языковой модели — для интерпретации, ответов в диалоге и рекомендаций.
Модель не считает по сырым рядам. Она объясняет то, что уже посчитано.
Вот такой общий подход)
Поставьте реакции, если тема интересна — в следующих постах расскажу про:
• интеграцию с устройствами и структурирование данных о показателях, событиях и расчётных показателях
• общие нормативы, средние значения пользователя и как из них формируются инсайты
• инструкции передачи инсайтов на базе трекинговых устройств в ассистент и рекомендательную систему
• разбор модели Google SensorFM
Работа с данными трекинговых устройств. Интеграции и структура данных
В прошлом посте рассказал наш общий подход к работе с данными трекеров.
Сегодня подробнее про первый шаг - формирование общей структуры базы данных.
Мы планируем поэтапно интегрироваться с разными видами трекинговых устройств и в конечном счете охватить все.
Мы закладываем, что пользователь может сменить устройство. А в редких случаях — пользоваться несколькими одновременно.
Поэтому нам важно было сформировать единую структуру базы данных, которая учитывает все возможные данные и приводит их к одному формату.
Для этого изучили, какую информацию и в каком виде можно получать с Apple Health, Google Health Connect, Whoop, Oura и Garmin — основных и наиболее популярных устройств.
Все данные с трекеров мы делим на три большие группы:
1. Показатели
Разделены на несколько доменов:
Пульс и сердце — пульс дневной, пульс покоя, HRV, пульс при ходьбе
Сон — длительность, время отбоя и подъёма, стадии, время в постели
Активность и движение — шаги, минуты интенсивности, этажи, набор высоты, калории
Дыхание и кислород — SpO₂, суточный и мгновенный
Температура — температура кожи, базальная температура
Показатели бывают разной гранулярности измерения:
мгновенные значения
дневные, средние, ночные
фиксация по триггеру, когда пользователь сам запускает замер
2. События
Тоже делятся на группы: сон, тренировки, бытовая и профессиональная активность, сессии восстановления (баня, массаж, ...)
Показатели связываются с событиями, для этого у нас отдельная таблица связей.
Это важно и для хранения данных, и для их дальнейшей интерпретации: пульс во время сна, пульс на тренировке и пульс в бане — интерпретируются по разному.
3. Расчётные показатели вендора
Это уже не базовые показатели, а алгоритмические — скор активности, восстановление, оценка качества сна, оценка уровня стресса и другие.
Каждый вендор считает их по своей закрытой модели, поэтому для каждого устройства они свои.
Мы их тоже сохраняем — в том объёме, в каком вендор их отдаёт. Но храним в отдельной структуре, потому что интерпретировать их и внедрять в ассистента нужно иначе, чем обычные показатели.
По всем данным обязательно фиксируем id устройства, чтобы отдельно обрабатывать сценарии смены (даже по базовым показателям между данными с разных устройств будут погрешности).
Поставьте реакции, если тема интересна — в следующих постах расскажу про:
• базу общих нормативных значений показателей
• расчёт медианных значений пользователя и зачем они нужны
• определение отклонений разных типов
• наборы правил интерпретации, подкреплённые источниками
• как из всего этого формируются инсайты передачи данных в ассистент
• как эти данные внедряются в контекст диалогов и рекомендательной системы
В прошлом посте рассказал наш общий подход к работе с данными трекеров.
Сегодня подробнее про первый шаг - формирование общей структуры базы данных.
Мы планируем поэтапно интегрироваться с разными видами трекинговых устройств и в конечном счете охватить все.
Мы закладываем, что пользователь может сменить устройство. А в редких случаях — пользоваться несколькими одновременно.
Поэтому нам важно было сформировать единую структуру базы данных, которая учитывает все возможные данные и приводит их к одному формату.
Для этого изучили, какую информацию и в каком виде можно получать с Apple Health, Google Health Connect, Whoop, Oura и Garmin — основных и наиболее популярных устройств.
Все данные с трекеров мы делим на три большие группы:
1. Показатели
Разделены на несколько доменов:
Пульс и сердце — пульс дневной, пульс покоя, HRV, пульс при ходьбе
Сон — длительность, время отбоя и подъёма, стадии, время в постели
Активность и движение — шаги, минуты интенсивности, этажи, набор высоты, калории
Дыхание и кислород — SpO₂, суточный и мгновенный
Температура — температура кожи, базальная температура
Показатели бывают разной гранулярности измерения:
мгновенные значения
дневные, средние, ночные
фиксация по триггеру, когда пользователь сам запускает замер
2. События
Тоже делятся на группы: сон, тренировки, бытовая и профессиональная активность, сессии восстановления (баня, массаж, ...)
Показатели связываются с событиями, для этого у нас отдельная таблица связей.
Это важно и для хранения данных, и для их дальнейшей интерпретации: пульс во время сна, пульс на тренировке и пульс в бане — интерпретируются по разному.
3. Расчётные показатели вендора
Это уже не базовые показатели, а алгоритмические — скор активности, восстановление, оценка качества сна, оценка уровня стресса и другие.
Каждый вендор считает их по своей закрытой модели, поэтому для каждого устройства они свои.
Мы их тоже сохраняем — в том объёме, в каком вендор их отдаёт. Но храним в отдельной структуре, потому что интерпретировать их и внедрять в ассистента нужно иначе, чем обычные показатели.
По всем данным обязательно фиксируем id устройства, чтобы отдельно обрабатывать сценарии смены (даже по базовым показателям между данными с разных устройств будут погрешности).
Поставьте реакции, если тема интересна — в следующих постах расскажу про:
• базу общих нормативных значений показателей
• расчёт медианных значений пользователя и зачем они нужны
• определение отклонений разных типов
• наборы правил интерпретации, подкреплённые источниками
• как из всего этого формируются инсайты передачи данных в ассистент
• как эти данные внедряются в контекст диалогов и рекомендательной системы
👍 4
🔥 4
❤ 3
1 115
Обсуждение 0
Обсуждение не доступно в веб-версии. Чтобы написать комментарий, перейдите в приложение Telegram.
Обсудить в Telegram