Можливості
OpenOnco — декларативний rule engine для онкологічних рекомендацій. На вході — JSON-профіль пацієнта (FHIR R4 / mCODE сумісний). На виході — Plan із ≥2 альтернативними треками (стандартний + агресивний) або DiagnosticPlan з workup brief, якщо гістологія ще не підтверджена. Кожна claim — з citation на джерело, кожен крок алгоритму — у trace. Сторінка нижче — повний і чесний опис того, що ми робимо, а в кінці — те, чого навмисно не робимо, і де лікар лишається finальною інстанцією.
2026-05-12 18:40 UTC.
Це інструмент підтримки рішень, не медичний пристрій.
Один JSON-профіль → два альтернативні плани лікування з цитатою під кожною рекомендацією.
Декларативний rule engine на 78 хворобах, 488 red flags, 436 показань, 370 режимів. Без LLM у клінічному рішенні, без серверу, без логів. Patient JSON ніколи не покидає машину.
disease, biomarkers,
findings, line_of_therapy.
revise_plan(...) оновлює рекомендацію щойно з'являються
нові біомаркери чи findings.
0. Що нового за останній тиждень
Останні дні KB і engine отримали кілька структурних апдейтів — вони міняють те, як engine працює, не лише наповнення:
Перейшли з закритого OncoKB (несумісний з CHARTER §2 — non-commercial)
на CIViC (CC0). Engine читає nightly YAML snapshot
через SnapshotCIViCClient, fusion-aware matcher
обробляє і point mutations, і fusions (BCR::ABL1 тощо).
Render видає ESCAT-primary з CIViC-detailed deep-dive.
Monthly snapshot refresh у CI + diff-only update,
щоб не дрейфувало.
Regimen.phases декомпозує курс на впорядковані
named blocks (induction → consolidation → maintenance).
bridging_options — це список регіменів-мостів між
фазами (наприклад, для CAR-T). Render — phases-aware, кожна фаза
рендериться з власним cycle schedule. Back-compat: старі
однофазні YAMLs auto-wrap у one-phase form.
Жодна BMA-claim не виходить у HTML без явної citation. Render-time guard перевіряє статус кожної комірки в actionability таблиці; якщо джерела немає — рядок отримує warn-badge або відсікається у strict mode. Це Layer 3 трирівневої системи — попередньо є background citation verifier (3-layer grounding для всіх sidecar PRs) і loader-level SRC-* referential integrity.
Per-disease таблиця: bio / drug / ind / reg / rf counts, 1L+2L
checkmarks, questionnaire status, fill% + verified%. Згрупована
за лімфоїдною / мієлоїдною гематологією і солідними пухлинами,
з family-level avg-показниками. Канонічна UI-поверхня для
disease_coverage.json.
→ Подивитись матрицю
Disease-grouped drill-down замість плоскої сітки. 159 hand-curated випадків (включно з останнім chunked feat'ом — Phase 2: NSCLC × 12, BREAST × 8, CRC × 6, AML × 4, DLBCL × 3, …, ~60 нових за 4 дні) + 362 verified variant profiles, які engine генерує з базових профілів через variant generator + 65 auto-base (по одному на хворобу). Кожен — повний Plan або Diagnostic Brief з усіма цитатами. → Дивитись приклади
Ваш AI-агент (Claude Code, Codex, Cursor, ChatGPT) бере один structured chunk (~100k–300k токенів роботи), виконує за 1-3 години і відкриває PR. Maintainer + Clinical Co-Lead перевіряють і мерджать. За останні 4 дні — 7 хвиль, десятки chunks, ~73 BMA-кандидати, 23 BMA-драфти, 53 source stubs. Деталі — у розділі TaskTorrent нижче. → Contributor Quickstart
1. Що вже зроблено — числа з реальної KB
Кожна хвороба має свій archetype (etiologically_driven, risk_stratified, biomarker_driven, stage_driven), що визначає логіку алгоритму вибору лікування. Зараз 1L покрито для всіх 78 (91 алгоритмів), 2L+ — для 34 гематологічних та 21 солідних (61 алгоритмів).
Гематолог, патолог, інфекціоніст-гепатолог, радіолог, молекулярний генетик, клінічний фармацевт, радіотерапевт, паліативна допомога та інші — кожен активується на конкретні тригери у профілі і додає свої open-questions + supportive care recommendations до плану.
Коли гістологія ще не підтверджена (CHARTER §15.2 C7 забороняє
treatment Plan без неї), engine вмикає diagnostic mode:
видає Workup Brief з тестами, biopsy approach, IHC panel і ролями
triage MDT. Як тільки histology підтверджено — diagnostic plan
promote-иться у treatment plan через revise_plan(...).
Структуровані клінічні умови, що автоматично змінюють план: RF-BULKY-DISEASE (нодальна маса >7 см) перемикає HCV-MZL з antiviral-first на BR + DAA; RF-MM-HIGH-RISK-CYTOGENETICS (t(4;14), del(17p), gain 1q) ескалує MM з триплету VRd до квадруплету D-VRd. Кожен RF прив'язаний до domain-role, який «виловлює» його у MDT brief. Алмост-універсальне RF-trigger alias-purpose cover'ить ~76% попередніх «unevaluated RedFlag» warnings.
Кожна схема — список drugs з дозами, шкалою циклів, dose adjustments (renal impairment, FIB-4, frailty), premedications, mandatory supportive care і monitoring schedule. Indication (disease + line + biomarker / stage / demographic-фільтри) гейтить конкретний Regimen — наприклад, MGMT-METHYLATION для GBM Stupp, CD79B/COO/IPI для DLBCL R-CHOP vs Pola-R-CHP, t(11;14)/MIPI для MCL, MYC+BCL2 rearrangements для HGBL-DH, AFP для HCC, FLIPI для FL.
ATC/RxNorm-кодовані. Кожен з регуляторним статусом FDA/EMA/MOЗ + НСЗУ reimbursement (наприклад, daratumumab наразі НЕ реімбурсується НСЗУ — це блокер для D-VRd, явно фіксований у плані). Останні поповнення: cell therapies (cilta-cel, liso-cel, loncastuximab-tesirine), antiemetics, FN-empirical antibacterials, antifungals.
LOINC-кодовані лабораторні + imaging + histology + IHC +
genomic тести. Кожен має priority_class
(critical / standard / desired / calculation_based) — рендеряться
у Plan як «pre-treatment investigations» таблиця.
Під цими 388 джерелами — десятки тисяч primary clinical publications (RCTs, мета-аналізи, когортні дослідження) і тисячі сторінок керівництв. Кожна Indication / Regimen / RedFlag цитує конкретні джерела з position (supports / contradicts / context), paraphrased quote, page/section. FDA Criterion 4 — лікар незалежно перевіряє підставу кожної рекомендації.
2. Як обробляється запит — 6 стадій engine
Лікар дає engine'у JSON-профіль (FHIR/mCODE-сумісний у майбутньому, спрощений dict у MVP). Engine виконує 6 послідовних стадій і повертає Plan з ≥2 альтернативними tracks (CHARTER §2 — обидва треки в одному документі, alternative не сховано).
disease.icd_o_3_morphology або disease.id
→ знайти Disease entity. Disease + line_of_therapy +
disease_state → знайти Algorithm.
demographics + biomarkers +
findings в один flat dict для evaluation.
any_of/all_of/none_of
clauses з threshold-ами. RF-trigger alias map зменшила «unevaluated»
warnings ~на 76%.
result або next_step). Trace зберігає
всі fired_red_flags на кожному кроці.
algorithm.output_indications стають
окремими tracks (standard / aggressive / surveillance). Біомаркер-
aware track filter виключає треки, що не задовольняють
biomarker_requirements_excluded.
Час обробки одного пацієнта — 50-200 мс (KB load домінує). У Pyodide перший запуск 8-15 сек (завантаження runtime), наступні — як локальний CLI. Серверу немає — engine крутиться локально (CLI) або у браузері користувача (Pyodide). Patient JSON ніколи не залишає машину.
3. Coverage matrix — публічна картинка прогресу
Сторінка /ukr/diseases.html
— це per-disease таблиця, що показує, що наявне у KB для кожної з
78 хвороб. Згрупована у три родини: лімфоїдна
гематологія, мієлоїдна гематологія, солідні пухлини. Для кожної
хвороби: counts по біомаркерах / препаратах / показаннях / режимах /
red flags, checkmarks для алгоритмів 1L і 2L, статус анкети
(real / stub / none), fill% і verified%. Family-рівневі avg-показники
у footer кожної таблиці. Це канонічна UI-поверхня для
/disease_coverage.json — той самий dataset, доступний
машинно.
4. CIViC actionability — як ми визначаємо «що з біомаркером робити»
До недавнього часу actionability (рівень доказів для biomarker→drug зв'язків) приходила з OncoKB. OncoKB ToS заборонив non-commercial public derivatives — це конфлікт з CHARTER §2 (free public resource). Ми мігрували на CIViC (CC0) — Clinical Interpretation of Variants in Cancer, відкритий ресурс WashU. Нижче — як це працює зараз:
Engine не звертається до CIViC API в runtime — читає
локальний snapshot з knowledge_base/hosted/civic/<date>/.
Це гарантує детермінізм результатів і працює офлайн.
SnapshotCIViCClient — публічний інтерфейс до цього
snapshot.
civic_variant_matcher обробляє і point mutations
(BRAF V600E), і fusions (BCR::ABL1 — обидва
компоненти індексовано), і structural variants. Fusion-агностичні
запити («ABL1») і component-specific запити мапляться однаково.
У Plan render: ESCAT tier (I-A, II-B, …) — primary signal, на рівні ока. CIViC evidence rating (A/B/C/D, supports/does-not-support) + clinical-significance — у details-розкривашці. Без OncoKB-level fields у render.
civic-monthly-refresh.yml в GitHub Actions щомісяця
тягне новий CIViC dump, генерує snapshot, рахує diff проти
попередньої версії. Якщо новий snapshot змінив N entities —
відкриває PR з diff-чек-лістом для review. Без сюрпризів у
рекомендаціях через silent upstream changes.
5. Multi-phase regimens — induction → consolidation → maintenance
До PR1-3 з phases-refactor режим був плоским списком drugs з одним
cycle schedule. Зараз Regimen.phases — це впорядкований
список named blocks, кожен зі своїм компонентним списком, циклами,
тривалістю, тригером переходу до наступної фази. Це коректно
відображає реальні протоколи: R-CHOP × 6 → maintenance, AML 7+3 →
HiDAC consolidation, axi-cel bridging → infusion → preemptive
tocilizumab maintenance.
Regimen.bridging_options — список ID режимів-мостів
між фазами (наприклад, для CAR-T: bridging chemo між apheresis і
infusion). Render — phases-aware: кожна фаза рендериться як
окремий блок з власним cycle schedule, premedications, monitoring.
components: на верхньому рівні без phases:)
автоматично wrap'аться у one-phase form через
auto_wrap_legacy_components() при load. One-way only:
якщо автор YAML вказав phases: явно —
components не торкаємо. 18 high-stakes регіменів
мігровано вручну (PR3).
6. Citation guard — нічого не виходить у HTML без джерела
Трирівнева система верифікації цитувань — три точки, де ми ловимо claims без джерел:
| Layer | Де ловить | Що робить |
|---|---|---|
| Layer 1 — Loader | YAML load time (Pydantic) | Перевіряє SRC-* referential integrity:
кожне source_id в Indication/Regimen/RedFlag
повинно резолвитись у Source entity. Невідомий SRC-ID → load fail. |
| Layer 2 — Background verifier | Sidecar PR audit (CI) | citation-verifier: three-layer grounding для
кожної AI-generated claim у sidecar — чи джерело існує, чи
paraphrase grounded в оригінальному тексті, чи claim-anchor
координати потрапляють у цитований розділ. Тригериться на
кожен contributor PR. |
| Layer 3 — Render guard | HTML output time | _citation_guard: на render-time перевіряє
кожну BMA-комірку. Без citation → warn-badge у lenient mode або
cell skip у strict_citation_guard=True. Гарантує:
те, що ви бачите в HTML, має джерело. |
7. Як ми працюємо з даними пацієнта
Engine читає лише структуровані поля з patient profile. Кожне поле має чітку семантику: або тригерить RedFlag, або filter'ує доступні Indications, або configurує Regimen materialization. Невпізнані поля ігноруються — ніяких «прихованих ефектів».
| Категорія | Що читаємо | Як використовуємо |
|---|---|---|
| Disease (вхідна точка) | disease.id · icd_o_3_morphology · line_of_therapy · disease_state |
визначає який Algorithm запускати |
| Diagnostic mode trigger | disease.suspicion.lineage_hint · tissue_locations · presentation |
вмикає DiagnosticPlan замість Plan (workup brief) |
| Demographics | age · sex · ecog · fit_for_transplant · decompensated_cirrhosis · pregnancy_status |
filter в Indication.applicable_to.demographic_constraints |
| Biomarkers | будь-які BIO-X з KB як ключі: BIO-CLL-HIGH-RISK-GENETICS, BIO-MM-CYTOGENETICS-HR, BIO-HCV-RNA, ... |
тригерять RedFlags, filter'ять Indications, мапляться у CIViC actionability |
| Findings | сотні структурованих полів — dominant_nodal_mass_cm, ldh_ratio_to_uln, creatinine_clearance_ml_min, blastoid_morphology, tp53_mutation, del_17p, ... |
thresholds у RedFlag triggers |
| Prior tests completed | prior_tests_completed: [TEST-IDs] |
виключає вже зроблені тести з generated workup_steps |
| Clinical record (free-form) | будь-який clinical_record envelope |
не читається engine'ом — використовується тільки render layer для context |
8. Способи запустити engine — три, жоден не серверний
python -m knowledge_base.engine.cli --patient profile.json --render plan.html.
Працює offline, не потребує мережі. Profile залишається на диску.
Pyodide v0.26.4 завантажує Python WebAssembly runtime, micropip ставить pydantic+pyyaml, розпаковує engine bundle (~2.4 МБ) у in-memory FS. Engine крутиться у браузері. Patient JSON не покидає машину. Service worker кешує bundle для offline-режиму.
from knowledge_base.engine import generate_plan, revise_plan
— інтеграція з EHR, CSV pipelines, batch testing. Stateless,
deterministic.
Plan.knowledge_base_state.algorithm_version
фіксує версію KB → same input + same KB = same output.
9. Що повертаємо назад — Plan / DiagnosticPlan
| Поле | Що містить |
|---|---|
tracks[] | ≥2 alternative tracks (default first), кожен з indication + regimen (+ phases) + monitoring + supportive_care + contraindications |
access_matrix | per-track agg-table: UA-реєстрації, НСЗУ-покриття, cost orientation (₴ ranges), primary AccessPathway. Render-time only. Stale-cost warning при cost_last_updated > 180 днів. |
experimental_options | третій трек: enumerate_experimental_options запитує ClinicalTrials.gov v2 за disease + biomarker + line, повертає sites_ua / countries metadata. 7-day on-disk TTL cache. |
actionability_hits | CIViC matches з ESCAT-primary level + CIViC details (variant, evidence rating, clinical significance, source citations) |
fda_compliance | FDA Criterion 4 fields: intended_use, hcp_user_specification, patient_population_match, algorithm_summary, data_sources_summary, data_limitations, automation_bias_warning |
trace | покрокова історія walk_algorithm: step / outcome / branch / fired_red_flags для кожного кроку |
knowledge_base_state | snapshot версії KB на момент генерації (audit per CHARTER §10.2) + civic_snapshot_date |
warnings | schema/ref errors, time_critical disqualifications, missing data hints, citation-guard warnings |
supersedes / superseded_by | версійний chain між plans для тієї ж пацієнта |
Опціонально вмикається MDT brief —
orchestrate_mdt() читає Plan + патієнтський профіль і
додає required/recommended/optional ролі (з 16 віртуальних
спеціалістів), open questions, provenance graph. Renders як inline
section у Plan HTML.
10. Як план оновлюється при появі нових даних
revise_plan(updated_patient, previous_plan, revision_trigger)
приймає оновлений профіль і генерує нову версію плану з
supersedes/superseded_by chain. Три легальні
переходи + одна заборона:
| Із | Зі змінами | Перехід | Результат |
|---|---|---|---|
| DiagnosticPlan vN | тільки suspicion (без histology) | diagnostic → diagnostic | DiagnosticPlan v(N+1) |
| DiagnosticPlan vN | підтверджена histology | diagnostic → treatment (promotion) | Plan v1 (перший treatment) |
| Plan vN | будь-яке оновлення з histology | treatment → treatment | Plan v(N+1) |
| Plan vN | видалено histology | ILLEGAL — ValueError, CHARTER §15.2 C7 | |
Попередній plan не мутується — повертається deep
copy з superseded_by заповненим. Caller (CLI / EHR) сам
вирішує що робити з обома версіями. Per CHARTER §10.2 — стара версія
зберігається indefinitely.
11. Examples gallery — 586 кейсів
/ukr/gallery.html —
disease-grouped drill-down. Початковий вигляд: tile-сітка хвороб з
counts. Клік → drill у case list для цієї хвороби. Кожен case —
повний Plan (або Diagnostic Brief), згенерований engine'ом з
реалістичного профілю. Це не реальні пацієнти
(CHARTER §9.3), а курована демонстрація engine output. Зараз
у галереї 586 кейсів:
- 159 hand-curated кейсів — у тому числі ~60 нових за останній тиждень (Phase 2 chunked feat: NSCLC × 12 biomarker variants, BREAST × 8 receptor-subtypes, CRC × 6 line variants, MELANOMA × 5 BRAF/IO variants, AML × 4 subtypes, DLBCL × 3 line variants, та інші — 12 chunks загалом).
- 362 verified variant profiles — engine
будує їх із базових патернів через
variant generator, кожен verified валідатором. - 65 auto-base кейсів — по одному на хворобу, автогенеровані як seed для drill-down.
Межі — те, чого engine навмисно не робить
Знати межі так само важливо, як знати можливості. Розділи нижче — повний і чесний список того, де engine відмовляється генерувати рішення без даних, де клінічне рішення лишається за лікарем, і які архітектурні позиції ми не плануємо змінювати.
12. Open Questions — як engine відмовляється від рішень без даних
Engine не приймає рішення без потрібних даних. Замість мовчазного default'у він явно фіксує які поля бракує і якого тесту чи висновку потребує. Це механізм Open Questions — частина MDT-orchestrator (Q1-Q6 + DQ1-DQ4 rules per MDT_ORCHESTRATOR_SPEC §3).
Treatment-mode Open Questions (Q1-Q6) — приклади з реального коду
- Q1 — Histology not confirmed: якщо
disease.idрезолвиться але немаєbiopsy_dateчиhistology_report— emit warning «Treatment Plan generated against ICD-O-3 code only; recommend confirming primary histology before initiating therapy». - Q2 — Stage missing: якщо Algorithm.decision_tree посилається на staging але profile немає
stage— fall-through на default з flag «Lugano/Ann Arbor stage required for confident risk-stratification». - Q3 — RedFlag clause references findings absent: якщо
RF-MM-HIGH-RISK-CYTOGENETICSперевіряєtp53_mutation+del_17p+t_4_14+gain_1q, а в profile є тількиdel_17p— engine не дає false negative; emit «Cytogenetic panel incomplete; high-risk status assessed with partial data». - Q4 — Biomarker required by Indication missing: якщо
IND-CLL-1L-VENOвимагаєBIO-CLL-HIGH-RISK-GENETICSдля default-track selection — emit «IGHV mutation status + FISH del(17p) required to confirm 1L recommendation». - Q5 — Performance status missing: якщо
ecogвідсутній — fall на conservative default (тільки standard track), emit «ECOG performance status required for transplant-eligibility assessment». - Q6 — Drug availability flag: якщо selected Regimen містить препарат позначений як
nszu_reimbursement: false(наприклад daratumumab у MM) — emit «D-VRd: daratumumab not currently NSZU-reimbursed in Ukraine; verify funding pathway before initiation».
Diagnostic-mode Open Questions (DQ1-DQ4) — для pre-biopsy режиму
- DQ1 — Tissue location missing: якщо
suspicion.tissue_locationsempty — workup match не може ranжувати, emit «Тип ткани локалізації потрібно вказати для матчингу workup». - DQ2 — Lineage hint absent: без
lineage_hintengine використовує тільки tissue + presentation для matching, lower confidence. - DQ3 — Presentation free-text empty: presentation_keywords scoring × 0; only lineage + tissue brati участь.
- DQ4 — Working hypotheses not provided: engine не має preferred direction, переважає найбільш generic workup.
13. Що engine навмисно не робить — gap-и персоналізації
«Персоналізація» в OpenOnco — це rule-based вибір з фіксованих варіантів, а не AI-генерація. Це навмисна архітектурна позиція (CHARTER §8.3). Конкретні gap-и:
Без per-patient dose calculation
Regimen зберігає стандартну дозу
(bortezomib 1.3 mg/m²), не множиться на BSA пацієнта
і не зменшується під CrCl 30 мл/хв автоматично. Лікар сам
перераховує. Це принципово, щоб уникнути класифікації як FDA
medical device.
Без response-adapted cycle adjustment
Regimen фіксує total_cycles: 6 + 2 maintenance.
Engine не адаптується автоматично на основі response (PR vs CR
після PET2). Re-staging plan генерується через окремий
revise_plan з новим profile — лікар явно тригерить.
Genomic matching обмежений curated biomarkers
CIViC покриває велику частину actionable variants. Поза CIViC (rare, novel, unverified variants) engine emits warning «no actionability evidence in current snapshot», але не «creative» інтерпретації. Це обмеження coverage, не engine-логіки.
SupportiveCare однакова для всіх на одному режимі
PJP prophylaxis attached до D-VRd для всіх — навіть для пацієнта з алергією на bactrim. Engine не знає альтернатив (dapsone замість bactrim). Лікар сам substitute'ить.
Без cumulative-toxicity tracking між lines
2L+ алгоритми вже існують для 34 гематологічних
хвороб (172 показань 2L+), але profile не carrier'ить
prior_treatment_history як structured field. 2L plan
для пацієнта що отримав bortezomib у 1L з grade 2 нейропатією —
engine не знає про попередній exposure якщо нічого нового не
вказано; лікар сам інтерпретує prior_lines з вільного тексту.
14. CHARTER-обмеження — will not change
Це не technical debt — це принципові архітектурні рішення, що визначають позицію проекту як non-device CDS і gатекіпять FDA / клінічну безпеку.
LLM не приймає клінічні рішення
LLM-и допомагають лише з: boilerplate code, doc drafts, extraction з clinical documents (з human verification), translation з clinical review. Не: вибір режиму, генерація доз, інтерпретація biomarker для therapy selection.
Без histology — без treatment Plan
Treatment Plan генерується тільки якщо disease.id
або icd_o_3_morphology підтверджені. Інакше engine
відмовляється і вмикає DiagnosticPlan mode.
revise_plan з treatment назад в diagnostic —
заборонено, raises ValueError.
Без time-critical recommendations
Engine не призначений для emergency oncology (oncologic
emergencies, time-sensitive infusion reactions). Це б тригернуло
device classification. Якщо Indication позначена
time_critical: true — engine додає disqualification
warning у FDA compliance.
Two-reviewer merge для clinical content
Будь-яка зміна під knowledge_base/hosted/content/
що affects clinical recommendations потребує два з трьох Clinical
Co-Lead approvals. Без цього Indication залишається STUB.
Anti automation-bias mandatory
Engine ніколи не показує тільки одну рекомендацію — завжди ≥2 tracks side-by-side. Alternative не buried, не «click to expand», не fine-print. Лікар бачить, що це вибір, не директива.
Patient data ніколи не у repo / public artifact
patient_plans/ gitignored. Будь-які patient HTML —
gitignored pattern. Site (docs/) показує тільки
synthetic examples. Збір telemetry заборонений без explicit
consent.
15. Поточне покриття — де ще STUB і чого ще немає
OpenOnco — work in progress. Зараз модельовано 78 захворювань (38 гематологічних + 40 солідних) — це далеко не повний WHO-HAEM5 / WHO Classification of Tumours. Конкретно:
| Категорія | Стан | Що це означає |
|---|---|---|
| Хвороби з повним ланцюгом | 77 / 78 | Решта — частково модельовані; engine може видати warning «no Algorithm found for disease=X» |
| Indications 1L | 230 | Перша лінія покрита для всіх 78 хвороб |
| Indications 2L+ | 172 | Друга-четверта лінія: 34 гематологічних + 21 солідних. Решта solid-tumor 2L+ — частково (CRC, breast, urothelial), не systematically. |
| RedFlags | 488 | Cover критичні clinical scenarios для існуючих хвороб; для нових disease треба додавати |
| Pediatric oncology | 0 | Out of scope for MVP — окремий track спеціалізації |
| Радіотерапія планів | частково | RT входить у мультимодальні Indications (cervical CRT, GBM Stupp, PMBCL R-CHOP+RT, esophageal CROSS), але як окрема сутність з технічними параметрами (доза/фракції/target volumes) ще не моделюється |
| Хірургія планів | не модельовано | Surgical oncology indications відсутні |
| НСЗУ formulary live-feed | статичний flag | Поки що hard-coded на режимах; не auto-refresh з НСЗУ — окремий backlog |
| Reviewer dual-signoff | 15/431 | Більшість контенту — STUB. Capacity план: 431 → ≥85% verified — це наша основна bottleneck-метрика, описана у kb_coverage_strategy v0.2 |
| Clinical gap audit | live dashboard | Build-generated audit for sign-off, solid-tumour 2L+, surgery/radiation structure, supportive care, and drug indication tracking. |
16. Що engine ніколи не робить — explicit boundary list
Не сховує alternative track
Обидві рекомендації завжди показані. UI не has «expand to see alternative» pattern.
Не генерує нову Indication LLM-ом
Усе вибирається з уже-curated KB. Якщо немає підходящої Indication — emit warning, не «creative invention».
Не модифікує дози «під пацієнта»
Дози зі стандартного NCCN/ESMO. Adjustments тільки через explicit dose_modification_rules у Regimen YAML, ніяких ad hoc calculations.
Не оцінює «що краще» між tracks
Algorithm обирає default, але не вирішує що default «кращий». Лікар має повну autonomy обрати alternative — задокументовано у automation_bias_warning.
Не інтерпретує imaging
«Bulky disease» приходить як structured field dominant_nodal_mass_cm, не з аналізу зображень. Image analysis = device classification.
Не робить cohort matching
«У базі з N пацієнтів M% обрали X» — окремий future feature, потребує persisted patient registry + privacy review. Поки недоступно.
17. Як з цим жити — workflow для лікаря
Цей engine задумано як підготовку до tumor-board, не заміну. Лікар вводить profile, отримує structured draft з усіма sources і open questions, далі:
Кожна claim у плані має citation. Лікар може прочитати оригінальний NCCN/ESMO/МОЗ розділ і підтвердити, що engine не misquote'ить. Citation guard вже відсікав комірки без джерел.
Якщо engine emit'ить «cytogenetic panel incomplete» — лікар замовляє
тест, додає у profile, запускає revise_plan. Plan
оновлюється, OpenQuestion закривається.
Дози пере-перевіряє, supportive care substitute'ить за алергіями, Ukraine-availability перевіряє вручну. Engine — draft, лікар — final.
MDT brief показує, які ролі activated і які питання відкриті. Це structured agenda для board meeting. Decisions з board fixед'аться як provenance events.
18. Як долучитись — верифікувати алгоритми токенами вашого AI
Найбільший gap на цій сторінці — 15/431 dual-reviewer sign-off. Це bottleneck, який не вирішується новим кодом — він вирішується контрибуторами з AI-tool'ами, які беруть structured chunks роботи і виконують їх кожен у свій worktree. Ми називаємо це TaskTorrent.
Maintainer публікує «чанк» — одну конкретну, завершену задачу (~100k–300k токенів структурованої AI-роботи): «реверифікувати BMA evidence для DLBCL × 17 entities» або «backfill source-license для 8 sources». Контрибутор бере чанк, AI-агент виконує, відкриває PR.
AI-tool з token budget на чанк (Claude Code Pro+, Codex, Cursor,
ChatGPT з web access). GitHub account + gh CLI.
Python 3.10+. ~1-3 години часу. Без клінічної експертизи
— ви не пишете medical advice; ви тригерите structured drafting,
а лікарі-co-leads потім signoff'ять.
Скопіюйте 8-рядковий промпт з
CONTRIBUTOR_QUICKSTART.md
у свій AI-агент. Він сам знайде наступний доступний chunk,
прочитає його spec, claim'не його, виконає роботу під
contributions/<chunk-id>/, прогоне валідатор,
відкриє PR.
Maintainer перевіряє mechanical частину (валідатор, schema
integrity). Clinical Co-Lead робить sample review semantic
частини (CHARTER §6.1). Після merge — sidecar landing у master,
потім upsert у hosted KB, потім у render для пацієнтів. Внесок
із атрибуцією у _contribution_meta.yaml (ai_tool +
ai_model).