Бренд для продажи технологии превращения неструктурированных медицинских данных (PDF, HL7, CSV, Excel, изображения) в структурированный FHIR R4. Игра слов: FHIR-стандарт + gravity как метафора стягивания хаоса в структуру.
Это не отдельный технический стэк — та же технология распознавания работает внутри B2C BloodGPT. FHIR Gravity — это product framing для middleware-сегмента (лаборатории, EHR-вендоры, агрегаторы), которым нужен только preprocessing, без full-cycle интерпретации.
«Два разных продукта: middleware (FHIR Gravity) и full cycle (BloodGPT). [Middleware] решает техническую проблему — пациенты или доктора не видят этот продукт. С BloodGPT full cycle, с интерпретацией, его видят доктора, партнёры, пациенты.»1
Зачем отдельный продукт
Рынок middleware и рынок full-cycle интерпретации — разные. Клиенты которые сами умеют интерпретировать (лаборатории, EHR-вендоры, агрегаторы) или умеют интегрироваться с FHIR-сервером (InterSystems IRIS, Healthcare API), но не умеют принять «любую нечисть» на входе — потенциальный целевой сегмент middleware. BloodGPT для них избыточен; FHIR Gravity — то что им нужно.
Команда зафиксировала два стека работы с данными клиентов1:
- plug-and-play API к существующему FHIR-серверу клиента (InterSystems и т.п.) — без middleware.
- конвертер для неструктурированных данных — на входе «любая нечисть» (PDF, CSV, HL7, Excel, изображения), на выходе структурированный FHIR R4.
Второй стек — это и есть FHIR Gravity.
Дополнительная мотивация: клиники, лаборатории и больницы не могут использовать LLM напрямую для лабораторных данных — нужна специализированная инфраструктура, без неё «LLM просто производит текст», несовместимый с клиническими системами1.
Состав
Технические компоненты middleware (внутренние, общие с BloodGPT):
- Recognition — извлечение данных из PDF / image / HL7 / JSON. См. recognition.
- Нормализация / LOINC harmonization — маппинг raw названий биомаркеров на canonical-ID и LOINC. См. loinc-harmonization-pipeline / normalization-service.
- FHIR write — структурированный output по R4 без extensions. См. zero-extensions-fhir.
- Multi-tenant хранение — изоляция per-tenant, GCP Healthcare API + 5 слоёв defense-in-depth. См. multi-tenant-fhir-storage.
Снаружи: общий бэкенд для алгоритмов / калькуляторов и BloodGPT, единый профиль пользователя (Apr 22 [Р2]).
PDF2FHIR — sub-продукт
Конкретный сценарий middleware: PDF → FHIR R4 как самостоятельный API endpoint.
- Спецификация собрана.
- Цена и латентность — числа в карточке озвучивались, конкретные значения требуют verify (carry-over).
- Перед коммерциализацией нужна medical validation — ищут партнёра, кандидат Jonda Health1.
Не зафиксировано как именно PDF2FHIR соотносится с FHIR Gravity-зонтом — возможно отдельная коммерческая обёртка, возможно один из endpoints общего middleware-API.
Маркетинговая концепция
Ната готовит креативную визуализацию «хаос данных → структура» для маркетинга. Метафора имени: gravity стягивает хаотические разрозненные данные в упорядоченную FHIR-структуру.
Это не про технику — это про то как объяснять клиентам и инвесторам что мы делаем.
Состояние
- Главный текущий блокер — точность распознавания PDF/изображений. Это сейчас bottleneck для всего middleware-направления, активная работа.
- Общий backend FHIR Gravity — в работе, план перехода обсуждается на daily / heads sync.
- PDF2FHIR — спека есть, ждёт medical validation и партнёрства.
Открытые вопросы
- Брендинг. FHIR Gravity как самостоятельный бренд vs «powered by BloodGPT» middleware vs обратная история (BloodGPT — full cycle на FHIR Gravity-инфраструктуре).1
- Граница продуктов. Где middleware заканчивается и где начинается интерпретация. Алгоритмы и калькуляторы — middleware-уровень или частично интерпретация.
- Готовый конвертер от InterSystems. Вася предлагал использовать готовые инструменты InterSystems как часть стека. Не выбрано.1
- Pricing и упаковка middleware для разных типов клиентов: лаборатории / EHR-вендоры / агрегаторы / прямые корпоратив-клиенты.
Связано
- recognition — главный технический компонент входа
- loinc-harmonization-pipeline — нормализация биомаркеров часть пайплайна
- normalization-service — старая нормализация (parallel, мигрирует)
- multi-tenant-fhir-storage — куда middleware пишет
- zero-extensions-fhir — стараемся использовать максимально стандартный FHIR (страница в основном про AI-генерируемый контент, но принцип общий)
- medical-calculators — соседний продукт в бандле «версии для врачей», работает поверх того же FHIR
- no-large-us-clinics-direct-sales — middleware-стек как альтернативный способ зайти к клиентам у которых уже есть EHR
- use-cases — три способа как продукт встречает пользователя (Lab / Doctor / B2C)
Carry-over: нужна страница про «Recommendations» — соседний продукт в линейке версий для врачей, parallel medical-calculators. Если не существует — создать.
Note: в Fireflies-транскриптах имя записано как «FireGravity» / «Fire Gravity» — ASR путает «FHIR» и «Fire» из-за одинакового звучания. Аналогично PDF2Fire = вероятно PDF2FHIR. Здесь используется правильное написание; при поиске в digest-ах учитывать обе формы.
Сноски
-
V-N-J еженедельный стратегический звонок (Jonathan / Vasiliy / Nata), 2026-04-22: https://github.com/Realai-plus/meeting-digests/blob/main/data/digest/2026/04/2026-04-22T10%3A30%3A00.000Z_V-N-J_01KPBC592SNMKJ5T2E03WXXMZ9.md — middleware vs full-cycle разделение, два стека работы с данными клиентов, FHIR Gravity как общий компонент, открытый вопрос брендинга, PDF2FHIR нужна medical validation (кандидат Jonda Health). ↩ ↩2 ↩3 ↩4 ↩5 ↩6