В пространстве health-приложений работают принципиально разные классы данных. Это таксономия, которая определяет что приложение может сделать, какому regulatory режиму подчиняется, какому trust frame’у соответствует, и какой output ожидается на выходе. Различение полезно для понимания где конкурируем мы (BloodGPT) и где работают игроки вроде Google Health, Superpower, Hone, Function — потому что они на самом деле в другом классе данных, не в нашем.
Два класса
Lifestyle data
Что попадает: активность (шаги, тренировки, сожжённые калории), сон (длительность, фазы), витальные с носимого устройства (heart rate trend, HRV, blood oxygen), wellness-метрики, menstrual tracking, stress/mindfulness scores. Иногда self-reported (вес, диета, симптомы по шкале 1-10).
Источники: wearable (Fitbit, Apple Watch, Garmin, Oura, Whoop), phone sensors, manual user input.
Свойства данных:
- Continuous timeseries (датапойнт каждую секунду/минуту)
- Шумные (motion artifacts, sensor drift)
- Не имеют clinical reference range в строгом смысле — есть «healthy ranges», но не диагностические
- Не привязаны к биологическому маркеру в крови / тканях / визуализации
Clinical data
Что попадает: лабораторные панели (биомаркеры в крови, моче, других жидкостях), результаты визуализации (рентген, КТ, МРТ, УЗИ), врачебные заключения и диагнозы, медикаменты, процедуры, аллергии, vital signs из клинического визита.
Источники: лаборатории (LabCorp, Quest, Helix, локальные), клиники / госпитали через EHR, медицинские устройства в clinical setting.
Свойства данных:
- Discrete events с timestamps (одно измерение в дату X)
- Высокая precision (regulated assays)
- Имеют clinical reference ranges с этиологическим смыслом — выход за range это диагностический сигнал
- Имеют установленные коды в clinical vocabularies (LOINC, ICD-10, SNOMED, RxNorm)
- Регулируется (CLIA для лаб в US, медицинская тайна, HIPAA)
FHIR alignment
В FHIR обе категории моделируются ресурсом Observation, но различаются через category:
vital-signs— для wearable-derived continuous metrics (heart rate, blood pressure, oxygen sat). См. fhir-resource-categories.laboratory— для lab panel results.activity— для activity/fitness data.
В нашем pipeline (recognize_image_to_fhir) явно разделяется laboratory vs vital-signs при разборе документа. Lifestyle-сторона FHIR (activity, wearable observations) у нас не используется — мы не входим в этот класс данных.
См. также:
- region-aware-ranges — наши reference ranges работают для
laboratoryкатегории, не для lifestyle - multi-tenant-fhir-storage — хранение clinical data с PHI
Implications
Класс данных определяет downstream-характеристики приложения. Эти три параметра идут пакетом — не выбираются независимо.
| Lifestyle data | Clinical data | |
|---|---|---|
| Trust frame | Wellness coach (помочь улучшить behaviour) | Медицинский прибор / second opinion (объяснить диагностический сигнал) |
| Output style | Behavioural nudges («больше двигайся», «спи дольше») | Клиническая интерпретация панели (что означает биомаркер, попадает ли в guidelines, что делать) |
| Regulatory path | Wellness app, обычно не SaMD (US FDA wellness device guidance) | Path к software-as-medical-device (SaMD), нужен doctor validation, регуляторный риск выше |
| Liability | Низкий (suggestion, не diagnosis) | Высокий (interpretation может быть understood as medical advice) |
| Vocabulary | Generic «active minutes», «sleep score» | LOINC + SNOMED + ICD-10, фиксированные коды |
| Reference standard | Healthy ranges (CDC guidelines, peer comparison) | Clinical reference ranges с патологическими порогами (ULN/LLN) + regional differences |
Гибридные продукты — где живёт пересечение
Современные приложения часто комбинируют оба класса данных:
- Apple Health — собирает оба (lifestyle через Health app + clinical через Health Records FHIR-import), но сама не интерпретирует clinical data. Aggregator role1.
- Google Health app (2026) — wearable-led + viewer медицинских записей в US (см. google-health). Health Coach даёт lifestyle-нудж’и, не клиническую интерпретацию.
- Superpower / Function / Hone — продают clinical data (lab panels) end-customer’у, но monetize через supplement/lifestyle marketplace. Их output — упрощённая интерпретация + lifestyle-нудж + supplement upsell.
Наблюдение: даже когда продукт обладает clinical data на входе, он часто упрощает output до lifestyle-нудж’ей. Глубокая клиническая интерпретация (с биомаркер-графом, regional ranges, guidelines) — отдельный режим работы который требует другой команды и другого regulatory подхода.
Где BloodGPT
Чисто в classe clinical data. Точка входа — лабораторная панель (PDF/photo от user’а или integration с лаб). Output — интерпретация: что означает каждый биомаркер в контексте reference range / других маркеров / клинических guidelines / medical-context-survey пациента. Не входим в lifestyle data — нет wearable integration, нет activity tracking, нет sleep analysis.
Это позиционирует BloodGPT в другом сегменте рынка чем Google Health (lifestyle-led) и чем supplement-marketplaces типа Superpower (clinical data → lifestyle output).
См. medical-as-instrument-not-recommendation — как это выражено в product positioning.
Открытые вопросы
- В каких случаях BloodGPT мог бы добавить lifestyle data на входе? Например, knowing что у пациента низкая активность (Fitbit data), интерпретация HbA1c становится нюансированнее. Сейчас это carry-over — не приоритет, но потенциальный feature.
- Health Connect API (Google) и HealthKit (Apple) — потенциальные distribution channels: BloodGPT публикует interpretation как Observation в этих aggregator’ах, попадает в lifestyle-products как clinical data. См. google-health про Health Connect.
- Где регуляторная граница — когда lifestyle product «слишком близко» подходит к clinical interpretation и попадает под SaMD regulation? Прецеденты: FTC enforcement против wellness-апликаций с clinical claims (carry-over: найти конкретные).
Связано
- google-health — пример lifestyle-led игрока с viewer’ом clinical data
- big-tech-in-health-interpretation — паттерн отступления big tech из deep clinical interpretation
- superpower — пример clinical-data-on-input с lifestyle-output продукта
- medical-as-instrument-not-recommendation — наше anti-coach positioning
- fhir-resource-categories — FHIR Observation.category coding
- region-aware-ranges — clinical reference ranges, не lifestyle
- no-prescription-red-line — supplement/prescription граница (актуальна для clinical-output продуктов)
- US FDA: Software as a Medical Device (SaMD) guidance — https://www.fda.gov/medical-devices/digital-health-center-excellence/software-medical-device-samd (carry-over: добавить direct quote про границы)
Сноски
-
Apple Developer documentation. HKFHIRResource API, Health Records architecture. https://developer.apple.com/documentation/healthkit/hkfhirresource — Цит. по сессии a648ae4e. Apple Health Records aggregates FHIR data from US providers (US Core IG v3.1.1 R4 / Argonaut DSTU2) для timeline view; не выполняет clinical interpretation. ↩