78 items with this tag.
Как 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.
Как сравнивать измерения одного биомаркера, сделанные в разных лабораториях с разными 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.
Когда мы генерируем отчёт о здоровье на определённую дату — какие данные пациента подаём в генератор? Две независимые оси: по времени (отсекаем то, чего на эту дату ещё не было) и по охвату (берём ли только биомаркеры этого теста или всю историю пациента). Сейчас работает только временное обрезание; вторая ось — открытый вопрос для обсуждения с командой.
Какие URL'ы класть в identifier.system на ресурсах, которые пишет наш pipeline. Сейчас inconsistent: clinical-impression / care-plan (по resource-type) vs patient-summary (по семантической роли). Vocabulary evolves — нужен принцип, который выживает rename'ы.
На каком уровне модели данных живёт ответственность за структурное отображение медицинских записей пациента — 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-компонентов.
Открытый вопрос — где и как pipeline должен **дозапрашивать пользователя** информацию, которой не хватает для качественного анализа. Сейчас вопрос беременности задаётся на каждый загруз вне зависимости от возраста/пола (наивно). Целевая модель: на шаге генерации agent сам определяет какие связи в графе биомаркеров не покрыты и формулирует follow-up. Пересекается с chat-интерфейсом, кнопками, UX-flow «загрузка → распознавание → генерация».
Открытый вопрос — что выбрать новым именем продукта вместо «BloodGPT». Текущее имя создаёт впечатление что продукт только про кровь, а реальный scope шире (любые медицинские документы). Имя должно покрывать и B2C (пользовательский портал), и B2B middleware (внутреннее имя «FHIR Gravity»). Решение не принято.
Открытый вопрос — когда пользователь загружает N фотографий, как понять, что несколько из них относятся к одному документу (одному анализу) и должны быть сгруппированы перед recognition? Решение пока не сформулировано — нужна формулировка контекста, вариантов и критериев выбора.
Направление по AI-блоку сложилось в чате 2026-05-14 , не обсуждено с Артуром / Катей / Васей. Триггер — BG-1432 (90-сек спиннер тренд-анализа, который никогда не дозаполняется) + Slack-тред 2026-05-14 про то, что показывать вместо...
Когда пациент сообщает в 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) на разные термины («усталость», «метформин», «диабет»).
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 хочется иной формы. Открытый вопрос — какой именно.
Рассматриваем варианты; конкретный driver — algo-hub (нет инструментации, BG-1429 followup), но решение задаёт pattern и для остальных сервисов где сейчас manual wrapping.
Стек защиты от supply chain атак: pre-install gate (release-age + ignore-scripts + опционально GAR proxy $3-6/мес) + malicious-behavior scanner (Socket free + GuardDog) + CVE scanner (OSV-Scanner). Замещает повисший с ноября 2025 tooling-вопрос; ждёт согласования с Женей и Артёмом.
Сегодня — A (каждый frontend сам). Решение не было принято осознанно: первый next.js API-route скопировал паттерн «direct inngest.send», b2b-api сделал то же со своей стороны, в комментарии у app/api/summary/route.ts зафиксирован выбор...
Принцип в одну фразу: между orchestrator-шагами (../technical/inngest сегодня; потенциально Temporal / self-hosted Inngest в будущем) идут только refs на ресурсы + опаковые ID + минимальная metadata — никогда не содержательное PHI...
I/O-контракт LLM-сервиса описываем таблицей полей симметрично (Input: Поле/Тип/Источник/Зачем модели; Output: #/Поле/Тип/Что решает/Что НЕ смотрит), не TS-fence'ом. Семантика впереди типа, язык-агностично.
Вопрос завис с session f09d1111, никто не двигает.
Решение касается выхода сервиса актуальности (PatientValidityProfile): для каждого наблюдения — finalStatus ∈ {representative / with_caveat / outdated / lifelong / error}, плюс contextSignals[], routeTrace, pastShelf. Шесть вариантов хранения; фактическая implementation выбрала Variant F (один patient-level CI + sub-extensions per биомаркер) без формального закрытия decision.
Сервис (../technical/biomarker-actuality-service) — gate перед биомаркер-анализом в healthReportPipeline; это известно с самого начала и тут не обсуждается. Страница картирует открытые вопросы и готчи, которые надо разобрать при...
Вопрос открыт. Сейчас в коде и то, и другое: фаза recognize построена как один оркестратор (step.invoke-цепочка), а всё ниже по потоку (interpret → enrichments → save-FHIR-AI → doctor-review → PDF) — как choreography (функции слушают...
Все 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 «выполни метод»). Это и...
Решения по именам в системе 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).
Какие `Resource.category` gap'ы закрыть для timeline v1 (для иконок). Закрываем MedicationStatement (`patientspecified`) / Procedure (SNOMED-based) / Composition (`assess-plan`) / CarePlan. Откладываем DiagnosticReport granular + Immunization builder.
Раздельные 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'ах). Эта страница фиксирует подмножество которое мы фактически принимаем и обрабатываем — и что отвечаем на остальное.
Кандидат на удаление — поле задумывалось как metadata-сигнал «документ представляет historical records», ни в Node.js, ни в .NET не доросло до runtime branching, прокидывается насквозь без потребителя.
Lifecycle rules для ресурсов в FHIR-store по их `origin` tag — user-uploaded immutable, ai-generated mutable, external-data immutable. Discriminator (meta.tag origin) определяется в [[../technical/fhir-meta-tagging]]. Гэп — `enrich-fhir-observations` нарушает immutability на user-uploaded Observation; рекомендация удалить (V2.5 ClinicalImpression заменяет). Stale-detection через `?_tag=origin|user-uploaded&_lastUpdated=gt<...>`.
Подвопрос внутри 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).
В секции «Follow Up Testing» ../product/patient-portal пациент должен иметь возможность поставить напоминание чтобы пересдать тесты в указанный AI-pipeline'ом момент. UX-pattern для этого действия не зафиксирован: одна часть стека...
Custom Bifrost-плагины регистрируются через SyncLoadedPlugin (компиляция вместе с bifrost'ом), не через `.so` shared object — избегаем ABI-coupling на patch-версии bifrost-core. Реализовано в `cmd/bifrost-with-plugins/main.go`. Open: re-enable через runtime API сломан как побочный эффект.
Два плагина в bifrost-цепочке для mock'а LLM на стейдже: domain-agnostic `schema-mocker` (валидный JSON по schema без LLM-вызова) + BloodGPT-specific `fhir-postprocessor` (medical biomarker substitution + FHIR `valueQuantity` patch). Реализовано в `Realai-plus/bifrost-plugins`, не задеплоено.
Решение касается per-параметрного rich-output ../technical/biomarker-analysis-pipeline (~8 полей: clinicalInterpretation, whatAdditionalDataWouldClarify, foundContext[], missingContext[], referenceContext[], additionalWorkup[], triage,...
Direction зафиксирован. Конкретные значения TTL per panel в работе, медицинской верификации пока нет (первое приближение через guideline-research).
Builder в worktrees/v2-5-fhir/packages/analysis-core/src/lib/fhir-clinical-impression-builder.ts сейчас пишет в .finding[] с kind="found-context" sub-extension — это противоречит FHIR R4 spec (finding[] = диагностические выводы, не...
Heads sync 2026-04-27. Тактическое sequencing решение, продиктованное regulatory асимметрией.
Все файлы пользователь загружает в **один drop-zone** — без разделения на «тесты», «medical context», «medical notes». Система автоматически определяет тип документа и структурирует. Это касается общей технологии распознавания, лежащей и за FHIR Gravity (B2B middleware), и за B2C-порталом BloodGPT — один engine, не два продукта. UI-концепт — «file manager» с раздельными шагами загрузка → обработка.
Для 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 проверку.
5% UX-зона около границы reference range как marketing UX, не clinical interpretation. Initial decision Apr 17 — убрать, на следующем созвоне reversed; keep как захардкоженная константа. Без научного / регуляторного основания.
Один TS-сервис маппинга биомаркеров (объединяет normalization-service + loinc-harmonization-service) с Dictionary-First lookup-layer + admin UI поверх. Старая нормализация → fallback внутри LOINC-сервиса. Tracker: BG-876, BG-1023.
Продуктовое позиционирование принято Apr 9 после спора Ильдар vs Вася; на Apr 17 формулировка «врач может ошибаться, прибор — нет» уже общая для команды (Вася + Катя).
Направление прямых продаж в крупные американские клиники закрыто после фидбэка от специалиста Mayo Clinic (Apr 8). Разрешённые альтернативы — онлайн, специализированные сегменты, партнёры.
Жёсткое продуктовое и регуляторное ограничение, обозначено Натой Apr 8, подтверждено Катей в работе с медицинскими кейсами.
Три позиции, критерий прозрачности не сформулирован, спор возвращается каждый раз при значимом архитектурном изменении.
Установка Ильдара принята Apr 1, реализация раскатывается через скилл auto-verify и Agent Browser. Полностью замкнутый цикл (LLM пишет → LLM тестирует → человек получает отчёт) ещё не достигнут.
Carry-over от Ильдара: «может это не цель, а промежуточный результат».
Для structured-LLM задач (LOINC mapping и подобных). Применимость к другим задачам BloodGPT — добавляется по мере появления опыта.
4 позиции, консенсуса нет с января 2026. Возможно становится moot point в направлении loinc-unification-direction (один сервис → нет inter-service cache).
Основная идея Ильдара для нового 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.
Текущее поведение системы при конфликте.
Apr 17 был принят first-step compromise, но финальный shape хранения не зафиксирован.
Contested decision (обсуждалось Mar 20 1:1, не приоритет сейчас): LOINC overrides хранить в отдельной таблице vs единая таблица маппингов с историей версий. Обе позиции имеют merit; компромисс не достигнут.
Техническое решение принято при миграции аутентификации из .NET в WorkOS. На Apr 8 daily Ильдар отчитался о тестовой soft migration одного пользователя.
Pivot с Device на Organization подтверждён через session c9560637 (Feb 17–20 2026): Google Healthcare API не принимает Device-references в author[x] choice type. Это vendor-specific ограничение — FHIR R4 spec разрешает Device через...
Решение 2026-02-14 формулировалось как «ровно один custom extension». По факту к 2026-05 их около десятка (см. «Текущее состояние»). Принцип, который остался в силе: каждое новое поле сначала ищет стандартное место в R4, custom...
В pipeline процесса анализа крови есть фаза AI analysis, которая генерирует:
Phase 1). Phase 2 — custom client domains через ../technical/cloudflare-custom-hostnames.
Multi-tenant архитектура BloodGPT: где хранить PHI (Protected Health Information) — лабораторные значения, демография пациента, AI-генерированные интерпретации. Cloud SQL уже используется для бизнес-логики (Organization, ApiKey,...