22 items under this folder.
End-to-end user journey пациента с несколькими тестами за разные годы — что система делает на каждом шаге, что пользователь видит, как работает actuality classifier и snapshot navigation. Конкретный fictional scenario (Анна, 3 теста 2022→2024→2026) с биомаркер-данными и FHIR-эффектами. Ключевая дизайн-позиция: интерпретация ВСЕГДА patient-wide, только asOfDate сдвигается; не делаем отдельный test-scoped pipeline.
Стандарт того, как мы называем customer-segments / платформы наружу (sales, контракты, public-docs) — vs внутреннее техническое именование (B2C / B2B в коде). До унификации внутренние ярлыки (B2C / B2B) использовались в разговорах с клиентами и в drafting контрактов, что путало: один и тот же offering звучал по-разному для разных аудиторий. Outward-facing convention: B2C / B2B – Clinician / B2B – SaaS / B2B – Integrated / B2B – Enterprise. Источник — Slack-объявление 2026-05-18.
Открытый вопрос — где и как pipeline должен **дозапрашивать пользователя** информацию, которой не хватает для качественного анализа. Сейчас вопрос беременности задаётся на каждый загруз вне зависимости от возраста/пола (наивно). Целевая модель: на шаге генерации agent сам определяет какие связи в графе биомаркеров не покрыты и формулирует follow-up. Пересекается с chat-интерфейсом, кнопками, UX-flow «загрузка → распознавание → генерация».
Открытый вопрос — что выбрать новым именем продукта вместо «BloodGPT». Текущее имя создаёт впечатление что продукт только про кровь, а реальный scope шире (любые медицинские документы). Имя должно покрывать и B2C (пользовательский портал), и B2B middleware (внутреннее имя «FHIR Gravity»). Решение не принято.
Направление по AI-блоку сложилось в чате 2026-05-14 , не обсуждено с Артуром / Катей / Васей. Триггер — BG-1432 (90-сек спиннер тренд-анализа, который никогда не дозаполняется) + Slack-тред 2026-05-14 про то, что показывать вместо...
Раздельные view'ы clinical (что было с пациентом) и system (история нашего сервиса), не одновременно две оси. Vertical layout. Multi-date документ → N в clinical / 1 в system. AI-generations НЕ показываются на clinical timeline. Versioning UX — open.
Полный набор существующих типов описан в ../domain/uploaded-document-types (16 классов в 4 tier'ах). Эта страница фиксирует подмножество которое мы фактически принимаем и обрабатываем — и что отвечаем на остальное.
В секции «Follow Up Testing» ../product/patient-portal пациент должен иметь возможность поставить напоминание чтобы пересдать тесты в указанный AI-pipeline'ом момент. UX-pattern для этого действия не зафиксирован: одна часть стека...
Heads sync 2026-04-27. Тактическое sequencing решение, продиктованное regulatory асимметрией.
My Health — финальная UI-страница пациента, на которой рендерится последний Health Report. 5 секций Insights (Главное / Общее / Что меняется / Чего не хватает / С врачом) + биомаркеры, повлиявшие на эти Insights. История Report'ов через timeline-навигацию. Status: pipeline в работе; UI-имя «My Health» — рабочее (chain 6bfe41d1), Васино исходное «Health Status» — pending передоговор.
Все файлы пользователь загружает в **один drop-zone** — без разделения на «тесты», «medical context», «medical notes». Система автоматически определяет тип документа и структурирует. Это касается общей технологии распознавания, лежащей и за FHIR Gravity (B2B middleware), и за B2C-порталом BloodGPT — один engine, не два продукта. UI-концепт — «file manager» с раздельными шагами загрузка → обработка.
`platform.bloodgpt.tech` — админка для организаций-клиентов (клиники / лаборатории): команда, API keys, monitoring обработки, brand / white-label, feature flags. Apps: `b2b-platform`.
Профессиональный кабинет врача — управление своими пациентами, загрузка анализов, генерация отчётов под собственным брендом. Состояние в transition: legacy .NET-стек ещё работает, целевая форма — фича внутри B2B Portal (врач как member маленькой org), не отдельный продукт-с-подпиской.
Opt-in режим: врач approves / edits / rejects AI-интерпретацию до доставки пациенту, visible verification stamp. Поверх любой integration option (PDF / Patient Portal / Full API). Role `doctor` в WorkOS, route `dashboard/[id]/validation/`.
Бренд для продажи технологии превращения неструктурированных мед.данных (PDF / HL7 / CSV / Excel / изображения) в FHIR R4. Middleware-product для лабораторий / EHR-вендоров / агрегаторов, у которых full-cycle BloodGPT избыточен. Та же recognition-технология, другой framing.
Меню из трёх integration paths, которое B2B клиент выбирает при онбординге (PDF-Only / Patient Portal / Full API). Корневая product taxonomy — большинство других продуктовых страниц позиционируются относительно этих трёх вариантов.
Продуктовое позиционирование принято Apr 9 после спора Ильдар vs Вася; на Apr 17 формулировка «врач может ошибаться, прибор — нет» уже общая для команды (Вася + Катя).
Направление прямых продаж в крупные американские клиники закрыто после фидбэка от специалиста Mayo Clinic (Apr 8). Разрешённые альтернативы — онлайн, специализированные сегменты, партнёры.
Жёсткое продуктовое и регуляторное ограничение, обозначено Натой Apr 8, подтверждено Катей в работе с медицинскими кейсами.
White-label B2B портал — клиника / лаборатория получает готовый patient-facing UI на собственном subdomain, брендированный под себя. Magic-link auth, Next.js + Prisma + Mailgun. Не путать с PHR — там B2C с другой экономикой (платит пациент, не клиника).
B2C Personal Health Record на `phr.bloodgpt.tech` — individual users регистрируются, загружают свои анализы, ведут историю, чатятся с AI, оплачивают Stripe-подпиской. Активная миграция legacy .NET → новый стек (`apps/b2c-dashboard/`, ветка `feature/b2c-dashboard`).
Три способа как BloodGPT встречает пользователя: Lab (простой путь) / Doctor (B2B) / PHR. Не три pipeline'а — три режима **одного** pipeline по осям (входа / выхода / контекста / questionnaire / UX). Матрица 6 вопросов × 3 ролей.