Три способа как BloodGPT встречает пользователя. Они отличаются не “тремя pipeline’ами”, а тремя режимами одного pipeline по осям входа/выхода.
Матрица 6 вопросов × 3 ролей
| Lab (простой путь) | Doctor (B2B) | PHR | |
|---|---|---|---|
| Кто загружает | Лаборатория (API/portal) | Врач | Сам пациент |
| Что знаем о пациенте | Только то что в результатах крови (демография максимум) | Врач может ввести conditions/medications через UI | Пациент сам отвечает на questionnaire; накопительно обрастает |
| Кому показываем | Пациенту (лаборатория пересылает) или API-клиенту raw JSON | Доктору — обе версии (для себя + preview для пациента) | Пациенту |
| Medical context на входе | Пустой | Частичный (врач ввёл что знает) | Эволюционирующий (обрастает с каждым тестом + ответами) |
| Questionnaire | Нет (нет канала связи с пациентом) | Нет — врач сам вместо | Да — non-blocking “ромашка” |
| Цель UX | Отдать результат; минимум шума | Инструмент принятия решений; отправка пациенту | Долгоиграющий “борт здоровья”; вовлечение; накопление истории |
Doctor (B2B) mode сейчас в transition — legacy реализация на .NET-стеке (отдельный фронт-клон patient + accountType=Doctor + own subscription) мигрирует в фичу внутри B2B-решения. См. doctor-portal.
Три оси параметризации одного pipeline
Различия между use cases укладываются в 3 параметра, не 3 разных pipeline’а:
contextSource: 'lab' | 'doctor' | 'patient-self'
outputAudience: ['patient'] | ['doctor', 'patient'] # doctor видит обе
questionnaireMode: 'off' | 'manual' | 'non-blocking-auto'
Один и тот же biomarker-analysis-pipeline обслуживает все три use case через эти параметры. Doctor/patient fork = частный случай “какой Writer запустить при триггере X для audience Y”, не отдельный pipeline.
Эволюционные связи между use case’ами
- Lab → phr возможен: если лаборатория интегрируется с patient app и пациент начинает отвечать на questionnaire → Lab-flow перерастает в PHR-flow
- Doctor → phr возможен: если врач передал пациенту login → пациент продолжает использовать сам
- PHR — самый широкий case по data accumulation, остальные — degenerate scenarios
Calibration: customer segments в public docs vs наши pipeline modes
Public docs (Realai-plus/docs) описывают два customer-сегмента:
| Segment (public docs) | Кто это | Какие наши pipeline modes использует |
|---|---|---|
| Diagnostic Laboratory | Клинические лаборатории, которые предлагают AI-интерпретацию как premium service сверх обычных результатов | В основном Lab mode (пациент получает интерпретацию через лабораторию); опционально Doctor mode через doctor-validation для regulatory sign-off |
| Wellness Platform | Wellness программы / корпоративные health-проekты, где coach создаёт personalized plan на основе результатов | Стартуют с Doctor mode (manual interpretation медперсоналом), переходят на automated с coach-review (близко к Lab mode + downstream coaching) |
Это разные frame — не противоречие:
- Public docs sales-positioning = «кто это покупает и под какую боль»
- Внутренние use-cases = «как один pipeline параметризуется под разные потоки»
Один customer segment может проходить разные modes по мере зрелости. Например, Diagnostic Lab сначала использует Lab mode (autopilot), потом подключает Doctor Validation для high-risk случаев, потом open’ит portal для пациентов = выходит в PHR-flow.
PHR-mode в public docs не имеет своего B2B customer-сегмента — это наш собственный B2C продукт PHR, а не B2B integration use case. Для B2B пациент-канала есть patient-portal (white-label), который сам по себе остаётся в Lab или Doctor mode (пациент видит результаты, но questionnaire / накопление контекста через questionnaire — это уже территория phr).
Связано
- integration-options — три integration paths (PDF / Patient Portal / Full API) ортогональны use case’ам — Diagnostic Lab может выбрать любую из трёх
- doctor-validation — opt-in поверх любого use case
- patient-portal — основной канал доставки в Lab-mode для Diagnostic Laboratory segment
- PHR — наш B2C продукт = реализация PHR-mode (третий столбец таблицы)
- biomarker-analysis-pipeline — pipeline, параметризуемый этими 3 осями
- health-report-vision — каждый use case может иметь разный snapshot frequency / format
- doctor-patient-prompts-not-fork — audience-split реализуется на уровне Generator-промптов
Источники
Источники: 1.
Сноски
-
Сессия
ildar/34e93701, 2026-04-24 — ` (Apr 24 2026) — обсуждение use cases и матрицы. ↩