121 items under this folder.
Как UI HealthReport показывает 5 классов вывода actuality-классификатора. Live prototype (2026-05-19) — выбран M2 amber-секция для likely_outdated. Lifelong_no_retest не дроп'ается, проходит pipeline как обычный representative. Caveat / error — открытые вопросы UI surface'а.
Bifrost gateway internal logging отключён — `client.enable_logging: false` + `logs_store.enabled: false` (Phase 1, фиксит SQLite-leak OOM). Memory limits подняты 256Mi/512Mi → 512Mi/1Gi + `GOMEMLIMIT=900MiB` для concurrent in-flight buffering (Phase 1b). LLM observability покрыта Langfuse на application-слое. Phase 2 (опциональный gateway audit через OTLP-export в Langfuse или Postgres logs_store) — open. BG-1202.
Технический разбор памяти bifrost под production-нагрузкой: что аллоцируется (worker pools, in-flight buffers, response objects, goroutine stacks, plugin clones, SQLite), как Go runtime взаимодействует с container limits (GOMEMLIMIT, GOGC, cgroup), какие failure modes наблюдаются (slow leak vs burst OOM vs GC thrashing vs FD exhaustion) и какие диагностические сигналы. Vendor claim про low memory — про idle/baseline, не peak concurrent.
Phase 2 [[health-report-pipeline|Health Report Pipeline]] — per-biomarker AI-цепочка над FHIR пациента. Two-tier: abnormal → Diagnostician → Retriever → Reasoner → DoctorWriter → Personalizer; normal → Generator (single-LLM, cost economy). Output: `BiomarkerAnalysis` record per биомаркер с structured evidence + per-audience prose.
Biomarker Knowledge Layer (BKL) — накапливающееся знание BloodGPT о биомаркерах: LOINC-маппинги, trending-группы, biomarker graph, ручные правки, референсные диапазоны, сигналы актуальности. Один продукт, видимый с разных сторон; растёт нарастающим итогом как актив, а не как временный кэш.
Как сравнивать измерения одного биомаркера, сделанные в разных лабораториях с разными reference ranges. Выбрано: структурно-позиционная нормализация `(value − upper_ref) / (upper_ref − lower_ref)` — позиция значения в собственном reference range каждого лаба. Альтернативы — конвертация единиц, сравнение без нормализации, z-score, percentile rank, quantile mapping — отвергнуты или сужены до граничных случаев.
Что делает биомаркер «main» для блока Highlights в Health Report. Рассмотрены восемь сигналов-кандидатов; выбрана комбинация из трёх (фенотип-кластер, контекст пациента, тренд) через OR поверх двух sanity-проверок, бинарный `main` / `not_main`, без LLM в момент принятия решения. Отвергнуто: список панических значений, бинарная привязка к диагнозу, объяснимость через контекст, reflex-логика, числовые шкалы тяжести, LOINC-panel matching, отдельная корзина «возможная ошибка».
Удаление загруженных пациентом медицинских документов (PDF / images) и всей downstream-цепочки (BloodTest, BloodTestFile, GCS-объекты, FHIR Observation / DiagnosticReport / Composition). Две оси ограничений: бизнес / compliance (HIPAA, GDPR right-to-be-forgotten, retention rules, customer SLA) и техника (cascade, FHIR _history, recovery). Сегодня — три разных pattern'а без единой стратегии (Patient.deletedAt timestamp, BloodTest.status='deleted' enum, FHIR DELETE). Варианты решения: cascade physical purge, FHIR DELETE с history-tombstone, unified deletedAt soft-delete, hybrid. NB: status='entered-in-error' это НЕ deletion (means 'should never have existed', не 'user wants to remove').
URL pattern для собственных FHIR extensions и StructureDefinitions. Сейчас в коде сосуществуют две конвенции (`bloodgpt.com/fhir/StructureDefinition/...` и `bloodgpt.com/fhir/extension/...`) — нужно унифицировать. Выбор влияет на cross-references из profiles, на URL resolution в опубликованном IG, и на migration cost.
Стоит ли формализовать наши FHIR-профили — писать StructureDefinitions, генерировать TS-типы и Zod-валидаторы, публиковать IG. Несколько осей: какой первый профиль, когда триггер, какой объём генерации (только types / + Zod / + IG для партнёров), какой инструмент. Incremental rollout по одному ресурсу делает это не all-or-nothing.
Когда мы генерируем отчёт о здоровье на определённую дату — какие данные пациента подаём в генератор? Две независимые оси: по времени (отсекаем то, чего на эту дату ещё не было) и по охвату (берём ли только биомаркеры этого теста или всю историю пациента). Сейчас работает только временное обрезание; вторая ось — открытый вопрос для обсуждения с командой.
Test Analysis Pipeline — orchestration shell который интерпретирует один blood test после recognition. Триггерится `fhir.analysis.requested` event'ом из `/api/v1/interpret/:testId` (b2b legacy клиенты; исторически b2c тоже). Stages: `analyze-blood-parameters` (per-Observation single-prompt LLM-вызов, см. [[single-prompt-analysis]]) → fan-out 5 enrichments в параллель (overview / follow-up / panel-overview / trends / product-recommendations) → `checkAndTriggerPdf` ждёт 4 readiness-flag'а → PDF generation → финальный FHIR Composition + CarePlan. Transient state живёт в `BloodTest.enrichmentDraft` (Json column), post-completion source of truth — FHIR. BG-1337 PR-5/PR-7 дропнул 5 legacy clinical tables; storage layer полностью FHIR-backed.
Третья ось рядом с [[tool-calling]] и [[code-mode-pattern]]. Tools, которые мы экспонируем агенту — это API; дизайн-craft тот же, что для обычного кода, но consumer — стохастический LLM, а не детерминированный caller. Pipeline эволюционирует tool-call → function-call по мере того, как underlying-операции становятся решёнными; scope масштабируется от 3-20 ручек до целой библиотеки (code-mode).
Какие URL'ы класть в identifier.system на ресурсах, которые пишет наш pipeline. Сейчас inconsistent: clinical-impression / care-plan (по resource-type) vs patient-summary (по семантической роли). Vocabulary evolves — нужен принцип, который выживает rename'ы.
Постепенная консолидация всех legacy-сервисов BloodGPT в TS-монорепо `bloodgpt-for-business`: .NET-бэкенд (`BloodGPT-dotnet`), Python-сервисы (loinc_harmonization, normalization, частично fhir-services), single Postgres → FHIR Healthcare API, прямые LLM-вызовы → bifrost-proxy. Не один tracked проект, а распределённая работа: куски функционала по очереди переезжают в новый стек. Страница — placeholder.
Детерминистический classifier `main` / `not_main` на каждый биомаркер для блока «Main now» в Health Report. Чистая функция (zod + pino, без LLM в момент принятия решения): 2 sanity-проверки плюс 3 OR-сигнала (кластер / контекст пациента / тренд) поверх результата Ретривера на каждое последнее измерение. Отдельный GitHub-репозиторий `Realai-plus/main-biomarkers-detection` (Артур + Катя), при merge ложится в `packages/`.
На каком уровне модели данных живёт ответственность за структурное отображение медицинских записей пациента — FHIR-категории (Resource.category), SNOMED-иерархия, или Composition с секциями исходного документа. Подходы не взаимоисключающие; обсуждается порядок реализации.
Нормальные биомаркеры идут через Diagnostician + Retriever + Reasoner + DoctorWriter, но НЕ через Personalizer. Триггер: actuality-классификатор требует `retrieved` (граф-связи) для всех биомаркеров, а Personalizer персонализирует connections, которые для нормалов в UI скрываются — wasted LLM-вызов. Single fork point — Personalizer yes/no. UI-hide реализуется фильтром в API-endpoint'е на response, не на уровне React-компонентов.
Legacy Trend Panel — per-biomarker UI компонент в bloodgpt-frontend (.NET stack). Тренд = first-class object внутри parameter'а, с двумя ребёнками: `trendData` (raw points map по датам) + `trendAnalysis` (AI-generated markdown prose). Lazy fetch через `useLazyTrendAnalysis` по `trendingGroupId`. Editable для docto/org-admin ролей. Single-value mode (один тест) скрывает trend секцию, показывает только base description биомаркера. FHIR-стэк новой архитектуры пока не повторяет этот shape symmetrically — series выводятся on-demand из Observation history, prose carry-over.
Pre-computed grouping over LOINC, по которому идентифицируются биомаркеры между observation'ами. `trending_group_id` пишется в FHIR Observation extension (URL `…/trending-group-id`) и читается всеми downstream-сервисами как ключ для трендов / patient summary / biomarker графа. 14 943 LOINC-кодов покрыто, 5895 уникальных групп; 4 уровня (L1 native LOINC Flowsheet → L4 singleton). Source: `loinc_harmonization_service/data/trending_groups.csv`.
Параллель между FHIR-моделированием и Domain-Driven Design (Эрик Эванс, 2003): Resource ≈ Entity, DataType ≈ Value Object, IG profiling ≈ Bounded Context, coding systems ≈ Ubiquitous Language. Не строгая эквивалентность, но узнаваемые primitives — знание DDD помогает FHIR-интуиции и наоборот.
Health Report Pipeline — 4 фазы (Snapshot Building / Biomarker Analysis / Insight Synthesis / Persist Report) внутри нижнего конуса hourglass'а. Patient-scoped — produces один Health Report per patient per run (CI + Composition + CarePlan); версии через FHIR `_history`. Triggered explicitly через `/api/summary` (b2c GenerateButton с asOfDate) с событием `health-report/generation.requested`.
Открытый вопрос — когда пользователь загружает N фотографий, как понять, что несколько из них относятся к одному документу (одному анализу) и должны быть сгруппированы перед recognition? Решение пока не сформулировано — нужна формулировка контекста, вариантов и критериев выбора.
Как BloodGPT превращает LLM-извлечённые medical terms в SNOMED-коды. **Два параллельных pipeline'а** с одной задачей и разными реализациями — (1) `narrative-to-fhir` (deployed) — two-tier hardcoded `SNOMED_QUICK_LOOKUP` + LLM fallback `gpt-5.2`; (2) V0.5 Mastra write tools (decided per [[llm-numeric-codes-policy]], не deployed) — LLM English term + terminology server `$expand`. История проб: bare LLM coding на gpt-4o-mini выдаёт garbage codes, JSON cache узкое покрытие, SQLite RF2 too heavy. Audit май-2026 (Артур) через CSIRO Ontoserver пофиксил wrong-concept bugs в hardcoded table.
Когда пациент сообщает в chat / survey / document import то же клиническое состояние повторно (та же болезнь, тот же симптом) — это update existing record или новый? Три уровня sameness — exact code (dedup), code hierarchy (reconciliation), semantic similarity (hard). V0.5 решено: exact-match dedup only, hierarchy / semantic — отложено. State-transition reactivation bug (resolved→active) — известная проблема, требует tuning agent prompt.
Унифицированная политика как помечать каждый ресурс в FHIR-store через `meta.tag` (origin + source codesystems), `meta.security` (HL7 AIAST для AI-asserted), и Provenance (full audit trail). Позволяет фильтровать «все AI», «всё из chat», «полный audit конкретного write-event». Используется через все write paths — recognition pipeline, V2.5 AI builders, V0.5 Mastra write tools, TextToFHIR document import.
LLM-агентам не доверять числовые clinical codes (SNOMED / ICD / RxNorm). LLM возвращает только English medical term, coding выполняется на write-side через resolver — terminology server `$expand` или mitigated LLM Tier 2 с strict schema + «Never invent» instruction + confidence score. Verified провал bare LLM coding на gpt-4o-mini: один и тот же garbage `431855005` (CKD stage 1) на разные термины («усталость», «метформин», «диабет»).
HL7 US Core IG — официальный набор FHIR R4 профилей для здравоохранения США, регуляторно обязателен для certified EHR через USCDI; сегодня BloodGPT не профилирует под US Core, но использует его conventions (`problem-list-item` default, `health-concern` category).
Russian Core FHIR IG (`build.fhir.org/ig/fhir-ru/RuCoreIG`, v0.4.2 май 2026) — российский аналог US Core / IL Core / HL7 EU Base. R5, профили Patient/Address/PractitionerRole/RelatedPerson + (планируется) Claim/Contract для ОМС. Известные дефекты: Address mismatch (fix 0.3.0), extension search parameters gap, over-strict constraints. У BloodGPT не используется (мы на R4 с Healthcare API); relevant если интеграция с ЕГИСЗ.
LLM-нагрузка Диагноста сегодня сосредоточена в трёх местах: (1) fuzzy-match имени биомаркера с keys графа на Tier 1, (2) выбор домена для unknown биомаркера на Tier 2, (3) генерация связей из медицинских знаний на Tier 3. Это страница...
Сегодня граф (../technical/biomarker-graph) лежит как ~13 000 строк JSON в коде, в packages/analysis-core/src/data/biomarker_graph.json. Это работает на dev-стадии, но для production хочется иной формы. Открытый вопрос — какой именно.
Multi-layer visibility для LLM-flow — как вызов из браузера до Gemini/OpenAI проходит через 4 слоя (Edge CF+GCP LB / Application Langfuse / Gateway Bifrost / Provider) и какой слой что видит. Visibility matrix + слепые пятна. С 2026-05-19 bifrost internal logging отключён ([[bifrost-logging]]) — gateway-колонка обнулена, algo-hub становится абсолютно слепым per-LLM-call. Парная с [[llm-resilience-stack]].
Рассматриваем варианты; конкретный driver — algo-hub (нет инструментации, BG-1429 followup), но решение задаёт pattern и для остальных сервисов где сейчас manual wrapping.
**Top-level карта observability surfaces** — какие сигналы куда пишутся по доменам (LLM-flow / infra+k8s / DB+FHIR / audit / orchestration / product / errors / edge), где смотреть первым по симптомам, cross-cutting вопросы (trace correlation, cost). Точка входа; deep dives на specialized pages (LLM-flow active, остальные TBD).
Сегодня — A (каждый frontend сам). Решение не было принято осознанно: первый next.js API-route скопировал паттерн «direct inngest.send», b2b-api сделал то же со своей стороны, в комментарии у app/api/summary/route.ts зафиксирован выбор...
Transport-layer reliability для LLM-стека — что делаем чтобы не сломалось (rate limits, retries, fallbacks, circuit breakers) по слоям application / queue ([[inngest]]) / gateway ([[bifrost]]) / observability ([[langfuse]]) / provider. Capabilities matrix «possible vs реально used». Парная с [[llm-observability-stack]] + [[llm-call-failure-classes]].
Принцип в одну фразу: между orchestrator-шагами (../technical/inngest сегодня; потенциально Temporal / self-hosted Inngest в будущем) идут только refs на ресурсы + опаковые ID + минимальная metadata — никогда не содержательное PHI...
Защита от package-registry атак (npm/PyPI). Триггер — **Shai-Hulud 2.0** ноября 2025 (`@postman/tunnel-agent` preinstall script → GitHub PAT с правами на 42 приватных репо Realai-plus + self-hosted runner + lateral movement) + mini-Shai-Hulud мая 2026 (~400 пакетов на TanStack + PyPI). Three-layer защита: pre-install / malicious-behavior / CVE.
Per-observation LLM-сервис отвечающий «можно ли опираться на это лаб-значение **сейчас**, или устарело / искажено активным драйвером (диагноз / лекарство) / биологически неизменно». Раньше — «validity classifier», название «актуальность» зафиксировано с Артуром 2026-05-12. Внутрикодовые имена пока не переименованы.
Diagnostician Agent — LLM-агент, единственный код-консьюмер [[biomarker-graph]]. Первый шаг biomarker-analysis pipeline (Diagnostician → Retriever → Reasoner → Writer / Personalizer). Возвращает `DiagnosticPlan` — список биомаркеров с указанием связанных параметров / диагнозов / лекарств для retrieval из FHIR. Не диагностирует — это knowledge-planner.
Open-source LLM engineering platform — observability (traces / generations), prompt management, evaluation (datasets + scores), cost tracking. Основной observability layer для всего BloodGPT LLM-стека. Все Mastra agents + analysis-worker pipelines пишут traces в Langfuse.
Вопрос завис с session f09d1111, никто не двигает.
Как LLM-вызовы из BloodGPT-сервисов доходят до провайдеров (OpenAI / Gemini). Сейчас **mixed topology** — разные сервисы используют разные пути, есть env-split stage vs prod. Целевой substrate — [[bifrost]] (single LLM proxy через который всё идёт).
Pipeline превращающий свободный медицинский текст (анамнез, диагнозы, лекарства, аллергии, процедуры, family history, симптомы) в типизированные FHIR R4 resources. Конвертер «клинический нарратив → структурированный patient state». Phase 2a — parallel SNOMED resolution через [[clinical-code-resolution]].
Перенос LLM-сервисов BloodGPT с Python на TS (Mastra-агенты или ai-sdk). Главная сложность — **parity-гэпы не видны на компиляции** и часто не на бенчмарк-числах: TS проходит тесты, но генерирует subtly другой output (потерянный production-промпт, порядок полей, словарь, кейс). Methodology + lessons learned.
V2 Retriever Agent — шаг 2 pipeline параметр-анализа. Берёт diagnostic plan от [[diagnostician]] и собирает запрошенные данные пациента из FHIR. Output `V2GenerationReadyPackage` — relatedFound vs relatedMissing per биомаркер. С [[biomarker-graph]] напрямую не работает.
Решение касается выхода сервиса актуальности (PatientValidityProfile): для каждого наблюдения — finalStatus ∈ {representative / with_caveat / outdated / lifelong / error}, плюс contextSignals[], routeTrace, pastShelf. Шесть вариантов хранения; фактическая implementation выбрала Variant F (один patient-level CI + sub-extensions per биомаркер) без формального закрытия decision.
Система квот для Gemini-моделей на Vertex AI (`aiplatform.googleapis.com`). Ключевой факт — Google перешёл с traditional per-project RPM/TPM на **spend-based tier system** (бывший "Dynamic Shared Quota" / DSQ, переименован в Standard PayGo). Меняет и view на квоты, и path их увеличения.
Сервис (../technical/biomarker-actuality-service) — gate перед биомаркер-анализом в healthReportPipeline; это известно с самого начала и тут не обсуждается. Страница картирует открытые вопросы и готчи, которые надо разобрать при...
Gemini «doom loop» — повторяющийся прод-issue: модель посреди генерации либо уходит в дегенеративный repetition-loop (community-термин «doom loop»), либо упирается в MAX_TOKENS на честно длинном ответе, либо зависает без error. Все три → `finishReason != STOP` или таймаут. Recognize (BG-1066), validity-классификатор etc. Подходы — детекция + перезапуск; Google официально подтвердил температурный триггер.
Вопрос открыт. Сейчас в коде и то, и другое: фаза recognize построена как один оркестратор (step.invoke-цепочка), а всё ниже по потоку (interpret → enrichments → save-FHIR-AI → doctor-review → PDF) — как choreography (функции слушают...
Таксономия сбоев LLM-вызова (особенно structured-output) — три класса с разными слоями обработки: **транспорт** (провайдер недоступен/завис → инфра/прокси: retry+nonce, fallback-model) · **схема** (криво держит контракт → cleanSchema, maxOutputTokens, detect-on-finishReason → прокси) · **семантика** (форма OK но содержание не подходит → app-level validator → reject/retry/degrade). Транспорт+схема generic, семантика task-specific.
Паттерн «сколько LLM-вызовов на задачу: 1 / N / батчами» — дилемма гранулярности при N независимых элементов, и **трёхуровневая декомпозиция** (один LLM-вызов ⊂ один батч ⊂ один прогон с бисекцией) которая выпадает при «батчами». Trade-offs setup overhead / failure scope / parallelism / observability. Каноничный носитель — validity-классификатор Артура.
Когда LLM-шаг производит вывод per-record (анализ на параметр, классификация на наблюдение), нужно привязать обратно к конкретному FHIR-ресурсу — обычно `Observation`. Pattern для записи AI-добавки на него / ссылки в Composition или ClinicalImpression / sматча при импорте.
Все outbound LLM-вызовы BloodGPT идут через прокси-слой; целевой прокси — Bifrost (self-hosted в нашем кластере). LiteLLM — первый прокси, который мы поставили, сейчас в режиме phasing-out (остатки в коде на ревизию). Managed-варианты...
Давно зафиксированное направление, формулируется явно). У нас один orchestrator — ../technical/inngest. Изобретать в коде свою очередь задач, свой worker-pool с ручной concurrency, свой retry-loop с бэкоффом, свой «фан-аут руками» —...
Для координации многошаговой работы между сервисами BloodGPT мы используем инструмент уровня workflow engine, конкретно ../technical/inngest — не message broker (сырой транспорт) и не job queue (fire-and-forget «выполни метод»). Это и...
Приём — порядок полей в схеме structured-output (`generateObject` / `responseSchema`) = порядок chain-of-thought, поскольку модель эмитит поля по порядку схемы; поздние conform к ранним; «reasoning» последним как резюме. Топологически уложенное рассуждение бесплатно. Носитель — validity-классификатор. Требует провайдера уважающего порядок (Vertex — да).
Снимок прежней standalone v2-архитектуры validity-classifier на ветке Артура `feat/v2-5` HEAD `0da5fc41` (батчинг по 8, LLM сам эмитит finalStatus, бисекция упавшего батча). Заменён v3 graph-driven архитектурой ([[biomarker-actuality-service]]). Страница оставлена как historical reference.
Решения по именам в системе Health Report. Что выбрали и почему — для каждого ключевого имени: артефакт (Health Report vs Report/Snapshot), вход в пайплайн (Snapshot), секции внутри (Insights vs Findings), типы (Observation/Biomarker/Evidence/Inference). Trade-offs описаны inline.
(SUPERSEDED 2026-05-20) Ранний снимок shift'а тест-scoped → пациент-scoped интерпретации. Содержание поглощено более полной серией: [[health-report-vision]] (paradigm shift и snapshot-центрик), [[health-report-pipeline]] (concrete 4-фазная имплементация), [[interpretation-scope-axes]] (horizontal + vertical scope axes на дату интерпретации). Эта страница смешала decision-level фрейминг с глубокой технической детализацией текущей кодовой ситуации (legacy V2 ветка, фантомные BloodTest строки, и т.п.) — материал актуальнее держать в pipeline / vision страницах, чем в одной decision.
Реализовано в chain 6bfe41d1 (2026-05-10): save-fhir-ai-resources ветвится по scope (см. «Реализация»). Решение про как хранить один (POST новой каждый run vs PUT canonical) — отдельно, см. health-report-versioning-model; здесь...
Предложение, обсуждается в chain 6bfe41d1, 2026-05-10).
Кандидат на удаление — поле задумывалось как metadata-сигнал «документ представляет historical records», ни в Node.js, ни в .NET не доросло до runtime branching, прокидывается насквозь без потребителя.
Подвопрос внутри staged-output-fhir-storage и foundcontext-fhir-mapping: каждый item в foundContext[] (а возможно и в referenceContext[] / missingContext[]) описывает связь между anchor-параметром и preexisting patient-ресурсом. У этой...
Health Report (Composition + CarePlan + ClinicalImpression) — одна evolving entity на пациента; run history живёт в FHIR `_history` через conditional PUT по identifier; default-render версия из `_history` выбирается по max(`Composition.event[0].period.start`), а не по max(lastUpdated).
Историческая страница — декомпозированный pipeline AI-интерпретации биомаркера представлялся как decision-альтернатива single-prompt подходу. После того как single-prompt стал legacy (Phase A-G renames, 2026-05), contrast-фрейминг потерял смысл; pipeline остаётся каноническим. Объединено в [[biomarker-analysis-pipeline]] как entity-page.
Custom Bifrost-плагины регистрируются через SyncLoadedPlugin (компиляция вместе с bifrost'ом), не через `.so` shared object — избегаем ABI-coupling на patch-версии bifrost-core. Реализовано в `cmd/bifrost-with-plugins/main.go`. Open: re-enable через runtime API сломан как побочный эффект.
Пара Go-плагинов для [[bifrost]] (schema-mocker + fhir-postprocessor) short-circuit'ят `response_format: json_schema` запросы — синтетический JSON по схеме без LLM-вызова. Замена утерянного TS `apps/mock-llm-server`. BG-1068.
Два плагина в bifrost-цепочке для mock'а LLM на стейдже: domain-agnostic `schema-mocker` (валидный JSON по schema без LLM-вызова) + BloodGPT-specific `fhir-postprocessor` (medical biomarker substitution + FHIR `valueQuantity` patch). Реализовано в `Realai-plus/bifrost-plugins`, не задеплоено.
Pipeline превращает AI-сгенерированный список follow-up расписаний в напоминания (email через Mailgun, WhatsApp через WABA-org). LLM → Postgres + FHIR CarePlan → patient-portal → Inngest. Defects — FHIR-roundtrip теряет `days_till_followup`, time-of-day нормализация, unique-key collision. UX-pattern отдельно — [[../product/follow-up-reminders-ui-pattern]].
Подход к AI-интерпретации параметра **одним LLM-вызовом** (Langfuse `single_parameter_analysis`), статический medical context из FHIR, flat output в Postgres ParameterAnalysis + копия в `Observation.note[]`. Toggle `SKIP_LEGACY_ANALYSIS`. Парный с [[biomarker-analysis-pipeline]] (V2.5).
Решение касается per-параметрного rich-output ../technical/biomarker-analysis-pipeline (~8 полей: clinicalInterpretation, whatAdditionalDataWouldClarify, foundContext[], missingContext[], referenceContext[], additionalWorkup[], triage,...
Обзор runtime-категорий для изоляции произвольного untrusted-кода — in-process isolate / OS namespace / sidecar / managed cloud / heavy isolation. Research, не deployed. Текущий триггер — Никитин FHIR-агент с `execute_python_code` без изоляции.
Emerging industry-идея 2025 — code execution с типизированными bindings (Cloudflare «Code Mode» + Anthropic «Code Execution with MCP», оба тоном exploratory, не established). Tradeoffs vs dominant tool calling — меньше данных в context, но infrastructure complexity + trust-boundary вопросы. В BloodGPT не используется.
Industry-standard pattern для LLM-агентов — LLM описывается набором typed-схема тулов; на каждом шаге LLM emit'ит discrete tool invocations (один или N parallel); runtime парсит / исполняет / возвращает result. Используется во всех 5 production-агентах + Никитином агенте. Терминология провайдеров — function calling / tool use / MCP.
Для unified-upload UI нужен отдельный endpoint (`POST /api/upload`, принимает N файлов, не возвращает TestID). Существующий B2B endpoint остаётся как `POST /api/recognize` (1 файл → 1 TestID), backward-compat сохраняется. Альтернативное имя `ingest` отвергнуто из-за конфликта с Inngest.
Substrate-уровневый фильтр отвергнут в пользу prompt-level разницы: обе версии работают параллельно поверх identical substrate, ограничения на пациентский output реализуются через инструкции writer'а и post-hoc проверку.
Архитектурный фрейм всего BloodGPT pipeline в форме **песочных часов**: вход (PDF/картинка, unstructured) → recognition → **узкое горло FHIR R4** → enrichment → выход (Report PDF/HTML, unstructured). Метафора объясняет почему FHIR — единая точка структуризации, и почему inputs/outputs могут быть любыми форматами.
Carry-over от Ильдара: «может это не цель, а промежуточный результат».
Для structured-LLM задач (LOINC mapping и подобных). Применимость к другим задачам BloodGPT — добавляется по мере появления опыта.
LLM proxy-сервис (Go), через который BloodGPT routes outbound LLM-вызовы (Gemini, GPT). Self-hosted, ~11µs overhead. Централизация auth / rate limiting / observability / caching / cascade fallback. Заменяет LiteLLM (memory leak). Целевой LLM-proxy per [[llm-proxy-choice]].
Клинический граф знаний BloodGPT — `biomarker_graph.json` структурированный «справочник связей» (биомаркеры × диагнозы × лекарства × преаналитические факторы) с rationale и цитатами guideline'ов. Питает [[diagnostician]] / [[retriever]] и опосредованно [[biomarker-actuality-service]].
Recognition output с bounding-box координатами на странице → visual validation interface для review правильности распознавания. Ильдар исследовал и достиг успеха, создал прототип. Placeholder для углубления.
4 позиции, консенсуса нет с января 2026. Возможно становится moot point в направлении loinc-unification-direction (один сервис → нет inter-service cache).
Единый админский инструмент для контроля качества данных в pipeline (DQD, RFC-022). Реализован в `b2b-platform` как Admin / Org Monitoring Dashboard + Generation Quality block. Покрывает Analysis-слой через [[llm-judges]] (5/11 критериев Никиты, G-Eval + logprobs) + таблица `EvaluationScore`. Recognition / Normalization остаются на старом мониторинге.
Strategy наполнения Dictionary (см. [[dictionary-first-paradigm]]) — особенно при онбординге новой лабы. Placeholder для углубления.
Основная идея Ильдара для нового LOINC-сервиса. Часть loinc-unification-direction.
В текущей FHIR-text-pipeline реализации. Альтернатива substrate-уровневого фильтра (patient-content-filter) рассмотрена и отвергнута: обе версии работают параллельно поверх identical substrate, разница реализуется через prompt-level...
Status: active — реализовано через BG-1196 в bloodgpt-for-business (апрель 2026), до этого proposed с весны.
Никита-version сейчас интегрируется в production pipeline.
В работе. Direction зафиксирован Apr 22-23 (`#ai-engineering` thread feat/image-recognize-to-fhir review).
Variant D: сухая медицинская инструкция как substrate, writer-промпты per audience поверх. Апгрейд Generator-шага — разделить reasoning (substrate-builder) и rendering (writer per audience) на 2 шага. Принято на daily Apr 27 после спора C vs D.
Paradigm shift тест-центрик → snapshot-центрик. Конвергенция трёх векторов: (1) patient-summary IPS; (2) multi-source events (chat / survey / document import) через 5 smart write tools + Provenance/meta.tag; (3) timeline UX. Future Health Status page — финальная поверхность с aggregate всей истории + versioned snapshots.
HL7 v2 — один из input-форматов наряду с PDF и JSON. Pipeline для него отдельный, не описан в wiki. Placeholder для углубления.
Текущее поведение системы при конфликте.
LLM proxy / unified API gateway (Python). Оборачивает множество LLM provider APIs (OpenAI / Anthropic / Gemini) в OpenAI-compatible interface. У нас — первый прокси, **выводится** в пользу [[bifrost]] (memory leak при streaming, деградация TTFT). См. [[llm-proxy-choice]].
LLM-as-judge — методология автоматической оценки качества LLM-ответов через другую LLM, которая по YAML-критерию выставляет рейтинг 1-5 с rationale. Используется в [[data-quality-dashboard]] (Analysis-слой) + standalone CLI. **Частичный TS-порт** evaluation framework Никиты (`Realai-plus/eval`) — 5 из 11 критериев, без DeepEval + без composite scoring.
Наш 3-step algorithm маппинга raw lab parameters → LOINC codes (KeywordGen → search → Selector + Agent Fallback). Production Python + Mastra TS port (два кодопути). Decision cache, specimen families, Method-only signature. См. сам стандарт [[../domain/loinc]].
Production Python микросервис, host [[loinc-harmonization-pipeline]] алгоритма. Async API + Redis queue + FastAPI. Отдельный репо, отдельный deploy. Superseded — migration to TS in `loinc-harmonization-pipeline` Mastra port.
TypeScript-фреймворк для AI agents — tool calling, structured output (Zod), agentic loops, multi-turn conversations, встроенный observability (Langfuse). Используется в BloodGPT для портирования Python-сервисов на TS-агенты в worktree `bloodgpt-for-business-mastra-agents` (ветка `feat/mastra-agents`). 5 production-агентов.
Каталог детерминированных медицинских формул (≈859 алгоритмов) + диагностических алгоритмов от Evidencio API. Технически — отдельная подсистема, разделяющая с BloodGPT общий recognition pipeline (unstructured → FHIR) и единый пользовательский профиль. Бесплатные калькуляторы vs paid диагностика по тарифу Evidencio (5000 EUR/год). Развёрнуто Apr 2026, UI в стадии тюнинга.
Apr 17 был принят first-step compromise, но финальный shape хранения не зафиксирован.
Старый Python-микросервис, определяет canonical normalizationId биомаркеров. Появился до [[loinc-harmonization-service]] (когда команда не знала про LOINC). Parallel путь в тренды (ParameterV2Id vs LOINC TrendingGroupId). Целевая судьба — TS-port + merge as fallback в LOINC service. См. [[../domain/loinc-unification-direction]].
Contested decision (обсуждалось Mar 20 1:1, не приоритет сейчас): LOINC overrides хранить в отдельной таблице vs единая таблица маппингов с историей версий. Обе позиции имеют merit; компромисс не достигнут.
Langfuse-промпт `parameter_range_type` (b2b-production v10) — анализ одного лабораторного параметра + FHIR R4 value[x] mapping + SNOMED CT coding. Output 9 fields включая `interpretation: N/H/L/A` и `range_type: EMPTY_OR_MISSING/LOWER_BOUND_ONLY/UPPER_BOUND_ONLY/BOTH_BOUNDS`. Core LLM-step в V2 parameter analysis pipeline.
Pipeline извлечения данных из неструктурированных документов (PDF / image) в структурированный набор параметров. `recognize_gpt` Langfuse prompt. **Fact-based redesign в работе** (Никита-version интегрируется). RFC-013 original_status. Bounding-box validation interface (Ильдар) — отдельный track.
Инструмент сравнения разных pipeline'ов распознавания анализов из PDF / фото на размеченном датасете с метриками (recall, precision, F1, value/unit/range accuracy, composite). Развивался итерациями: standalone TS-эксперимент в eval-репо (OCR vs Vision-LLM) → переехал в монорепо `bloodgpt-for-business/apps/benchmark/` (BG-1056) с bbox annotation UI + multi-eval framework.
Техническое решение принято при миграции аутентификации из .NET в WorkOS. На Apr 8 daily Ильдар отчитался о тестовой soft migration одного пользователя.
В pipeline процесса анализа крови есть фаза AI analysis, которая генерирует:
Cloudflare for SaaS — механизм custom client-owned domains через CF managed SSL + DNS. Запланировано как Phase 2 поверх [[hash-based-subdomain]] (Phase 1). В продакшене не задействовано.
GCP-managed FHIR backend (+ DICOM, HL7v2 — не критично). Primary FHIR storage для BloodGPT multi-tenant (session 871a7608 decision). Альтернативы — [[hapi-fhir]] self-hosted, Azure FHIR, Medplum. Known gotcha — Device-references в `author[x]` не принимаются (см. [[../domain/authorship-organization-not-device]]).
Reference Java-implementation FHIR-сервера. В BloodGPT — development/staging only; production на [[google-healthcare-api]] per-tenant. Public HAPI test server `hapi.fhir.org/baseR4` использовался до session 871a7608 (без HIPAA, общий). Остаётся как альтернатива для FHIR-stack без vendor lock-in.
Phase 1). Phase 2 — custom client domains через ../technical/cloudflare-custom-hostnames.
Workflow-движок создающий **иллюзию единого процесса** — обычный последовательный код, движок прячет распределённость (шаги переживают crash'и / ретраят / ждут событий). Основной оркестратор pipeline'ов recognize / interpret / enrichments в BloodGPT. Function/step/event primitives, queue/concurrency/retry через него, не self-rolled.
Multi-tenant архитектура BloodGPT: где хранить PHI (Protected Health Information) — лабораторные значения, демография пациента, AI-генерированные интерпретации. Cloud SQL уже используется для бизнес-логики (Organization, ApiKey,...
B2B SaaS auth provider — SSO, directory sync, SCIM, organization management. В BloodGPT — `b2b-platform`, `b2b-api`, `phr`. Для `patient-portal` обсуждался как design proposal (session 871a7608), не реализован — magic-link auth остался.
Tenant-routing на уровне frontend / ingress — дефолтный subdomain (`{hash}.portal.bloodgpt.tech` через [[hash-based-subdomain]]) + опциональный client-owned domain через [[cloudflare-custom-hostnames|Cloudflare for SaaS]] + auth-flow через [[workos]]. Phase 1 active, Phase 2 planned.
Как структурированный AI-output BloodGPT (интерпретация анализов, рекомендации, follow-up) ложится — и не ложится — на стандартный FHIR R4. Состояние подвижное: deployed-модель минимальная, rich-output последнего многостадийного анализа биомаркеров пока без settled-формы, набор custom extensions ещё не зафиксирован.
Multi-tenant FHIR architecture — PHI целиком в FHIR-хранилище ([[phi-in-fhir-not-sql]]), ноль в Cloud SQL. Defense-in-depth 5 слоёв (trifold: дизайн / реальность / drift), live-leak risk + Organization/bloodgpt provisioning gap.
Как из FHIR-хранилища (анализы, выписки, PHR за годы) получить «текущее состояние здоровья» для LLM. IPS-стандарт у нас + Tool Calling vs RAG, cold start scoring, industry patterns. Origin — session 18d2aef8 + RFC-019.