В текущей FHIR-text-pipeline реализации. Альтернатива substrate-уровневого фильтра (patient-content-filter) рассмотрена и отвергнута: обе версии работают параллельно поверх identical substrate, разница реализуется через prompt-level инструкции — включая скрытие категорий (diagnoses, conditions, medications) патиенту. LLM-leakage возможен, контролируется post-hoc проверкой.
Контекст
FHIR-based pipeline генерирует AI-тексты на основе данных пациента (panel overview, test overview, follow-up, generator). Эти тексты отличаются по аудитории — врачебная версия (медицинский язык, более точные термины) и пациентская (упрощённый язык, без jargon). Возникает вопрос: как дублировать эту разницу в системе?
Рассматривали
- A. Раздвоение кода — отдельные функции / pipeline для doctor vs patient. Каждая версия — свой control flow.
- B. Один pipeline, разные промпты — одинаковый retriever и flow; меняются только инструкции в финальном генераторе и downstream-шагах (panel overview, test overview, follow-up).
Выбрали: B (разные промпты, без раздвоения кода)
Почему
- Один retriever — одна точка истины для FHIR-данных. Если ретривер ошибся — ошибка одинаково проявляется в обеих версиях, легко найти.
- Меньше кода для maintenance. Изменение в pipeline — один путь, два промпта.
- Различия по аудитории действительно лежат на уровне языка и стиля, не структуры данных. Промпт — правильный уровень абстракции.
Следствия
- Бизнес-логика когда какую версию запускать — отдельный вопрос (см. ниже).
- При изменении ретривера / pipeline structure — нужно verify обе версии (промпты могут не отразить новое поле и т.п.).
- При добавлении новой аудитории (например, родственник пациента) — новый промпт, не новый pipeline.
Открытые вопросы
- Когда показывать пациентскую версию vs врачебную? Когда врач хочет показать пациенту результаты — генерируем заново пациентскую версию? Или врачи получают свои тексты и не делятся с пациентами? Решения нет.
- Coverage других downstream-шагов — gen / panel overview / test overview / follow-up. Все ли используют этот pattern или есть исключения. TBD verify.
- Upgrade на facts-as-substrate — этот decision становится частным случаем более общего pattern, см. health-facts-as-generation-substrate (active, Variant D). Migration ещё не завершён.
Связано
- biomarker-analysis-pipeline — parent — 3-agent pipeline где живёт этот audience-split
- health-facts-as-generation-substrate — active upgrade этого decision (facts as substrate, Variant D)
- patient-content-filter — рассмотренная и отвергнутая альтернатива (substrate-уровневый фильтр)
- patient-summary — adjacent (PatientSummaryAgent — другой pipeline для retrieval, не для text generation)
- fhir-modeling-ai-content — общий концепт mapping AI-output в FHIR
- agent-vs-workflow — общая design philosophy (этот частный случай decomposed)
Источники
Сноски
-
2026-04-16 transcript “Обновление FHIR-based пайплайна”, accessed 2026-05-17, https://github.com/Realai-plus/meeting-digests/blob/main/data/digest/2026/04/2026-04-16T16%3A57%3A00.000Z_Обновление_FHIR-based_пайплайна_01KPBKHZDBP9NQ6FPCFNDTWMFV.md. ↩
-
2026-04-24 Slack thread (Ильдар,
#ai-engineering) про facts → dual rendering, accessed 2026-05-17, https://realaicorp.slack.com/archives/C094GRT3CBY/p1777040691399849?thread_ts=1776356279.568619. ↩ -
2026-04-27 Health status-centric юзер флоу, accessed 2026-05-17, https://github.com/Realai-plus/meeting-digests/blob/main/data/digest/2026/04/2026-04-27T17%3A00%3A00.000Z_Health_status-centric_%D1%8E%D0%B7%D0%B5%D1%80_%D1%84%D0%BB%D0%BE%D1%83_01KQ7WPNNMNBT3K8NDZQXM2321.md. ↩