Можливості
OpenOnco приймає JSON-профіль пацієнта і повертає структурований план лікування або діагностичний brief, з повним trace кожного рішення і цитуваннями всіх джерел. Жодного «чорного ящика»: усе рішення складається з декларативних правил, які можна прочитати у KB і відстежити в trace. Нижче — детально, як ми працюємо з даними, джерелами і запитами.
Один JSON-профіль → два альтернативні плани лікування з цитатою під кожною рекомендацією.
Декларативний rule engine на 65 хворобах, реферує 26,062+ публікацій під 162 джерелами верхнього рівня. Без LLM у клінічному рішенні, без серверу, без логів. Patient JSON ніколи не покидає машину.
disease, biomarkers,
findings, line_of_therapy.
revise_plan(...) оновлює рекомендацію щойно з'являються
нові біомаркери чи findings.
Що вже зроблено
Кожна хвороба має свій archetype (etiologically_driven як HCV-MZL, risk_stratified як MM, biomarker_driven як NSCLC/EGFR або HGBL/MYC-BCL2, stage_driven як cervical), що визначає логіку алгоритму вибору лікування. Зараз 1L покрито для всіх 65 хвороб (57 алгоритмів), 2L+ — для 34 гематологічних та 4 солідних (38 алгоритмів).
Гематолог, патолог, інфекціоніст-гепатолог, радіолог, молекулярний генетик, клінічний фармацевт, радіотерапевт, паліативна допомога та інші — кожен активується на конкретні тригери у профілі пацієнта і додає свої 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. Кожен RedFlag прив'язаний до domain-role, який «виловлює» його у MDT brief.
Кожна схема — список drugs з дозами, шкалою циклів, dose adjustments (для renal impairment, FIB-4, frailty), premedications, mandatory supportive care та monitoring schedule. Кожна Indication (сполучення disease + line_of_therapy + 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, явно фіксований у плані).
LOINC-кодовані лабораторні + imaging + histology + IHC + genomic тести.
Кожен має priority_class (critical / standard / desired /
calculation_based) — рендеряться у Plan як «pre-treatment investigations»
таблиця.
Під цими 162 джерелами — 26,062+ primary clinical publications (RCTs, мета-аналізи, когортні дослідження) і 10,269 сторінок керівництв. Сама лише NCCN B-Cell Lymphomas guideline — ~500 сторінок з ~700 references. Кожна Indication / Regimen / RedFlag цитує конкретні джерела з position (supports / contradicts / context), paraphrased quote, page/section. FDA Criterion 4 — лікар незалежно перевіряє підставу кожної рекомендації.
CHARTER (governance + FDA позиціювання), CLINICAL_CONTENT_STANDARDS, KNOWLEDGE_SCHEMA, DATA_STANDARDS, SOURCE_INGESTION, REFERENCE_CASE, MDT_ORCHESTRATOR, DIAGNOSTIC_MDT, WORKUP_METHODOLOGY, SKILL_ARCHITECTURE.
2026-04-26 23:04 UTC.
Reviewer sign-offs ≥ 2: 15/202
— увесь клінічний контент позначено як STUB до dual-sign-off
Clinical Co-Lead. Це інструмент підтримки рішень, не медичний пристрій.
1. Як обробляється запит
Лікар дає 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
→ знайти відповідний Algorithm.
demographics + biomarkers
+ findings в один flat dict для evaluation.
any_of/all_of/none_of
clauses з threshold-ами.
result або next_step). Trace зберігає
всі fired_red_flags на кожному кроці.
algorithm.output_indications стають
окремими tracks (standard / aggressive / surveillance). Selected
= default, перший. Решта — alternative.
Час обробки одного пацієнта — 50-200 ms (KB load домінує). У Pyodide перший запуск 8-15 сек (завантаження runtime), наступні — як локальний CLI. Серверу немає — engine крутиться локально (CLI) або у браузері користувача (Pyodide). Patient JSON ніколи не залишає машину.
2. Як ми працюємо з даними пацієнта
Engine читає лише структуровані поля з patient profile. Кожне поле має чітку семантику: або тригерить RedFlag, або filter'ує доступні Indications, або configurує Regimen materialization. Невпізнані поля ігноруються — ніяких «прихованих ефектів».
| Категорія | Що читаємо | Як використовуємо |
|---|---|---|
| Disease (вхідна точка) | disease.id · icd_o_3_morphology · line_of_therapy |
визначає який 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 |
| Findings | 310+ структурованих полів — 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 |
3. Як ми працюємо з джерелами — і чому це наша ключова перевага
Кожне джерело — це окрема Source entity з власним ID
(наприклад SRC-NCCN-BCELL-2025), title, version, license,
access mode (referenced vs hosted per SOURCE_INGESTION_SPEC §1.4).
Зараз у KB 162 джерел:
| Source ID | Тип | Сторінок | Primary refs | Роль у корпусі |
|---|---|---|---|---|
SRC-NCCN-BCELL-2025 | NCCN B-Cell Lymphomas v.2.2025 | 500 | 700 | primary_guideline |
SRC-NCCN-MM-2025 | NCCN Multiple Myeloma 2025 | 400 | 600 | primary_guideline |
SRC-NCCN-AML-2025 | NCCN AML 2025 | 350 | 500 | primary_guideline |
SRC-NCCN-MPN-2025 | NCCN MPN 2025 | 300 | 400 | primary_guideline |
SRC-EASL-HCV-2023 | EASL HCV Guidelines 2023 | 80 | 250 | primary_guideline |
SRC-WHO-LNSC-2023 | WHO Lymph Node, Spleen, Thymus Cytopathology | 150 | 200 | diagnostic_methodology |
SRC-CTCAE-V5 | NCI CTCAE v5.0 (toxicity terminology) | 150 | 30 | terminology |
SRC-ESMO-MZL-2024 | ESMO Marginal Zone Lymphomas 2024 | 30 | 150 | primary_guideline |
SRC-BSH-MZL-2024 | BSH MZL Guideline 2024 | 50 | 120 | regional_guideline |
SRC-EHA-WORKUP-2024 | EHA Practical Workup Guidelines 2024 | 40 | 100 | diagnostic_methodology |
SRC-MOZ-UA-LYMPH-2024 | МОЗ Україна — Лімфоми (placeholder) | 60 | 50 | regional_guideline |
SRC-ARCAINI-2014 | IELSG-19 RCT — MALT lymphoma | 10 | 50 | rct_publication |
SRC-FDA-CDS-2026 | FDA CDS Software Guidance 2026 | 30 | 20 | regulatory |
| Сумарно | 10,269 | 26,062+ | — | |
Кожна клінічна claim у KB має citation. Indication,
Regimen, RedFlag, Algorithm — всі мають поле sources: list
де для кожного джерела вказано:
Структура citation
source_id— посилання на Source entityposition— supports / contradicts / contextrelevant_quote_paraphrase— паніфразоване твердження з guideline (не дослівне copy-paste для license safety)page_or_section— точна локалізація в документі
Render layer показує повний список cited sources під кожною Indication у Plan. Це і є FDA Criterion 4 (CHARTER §15.2): лікар може незалежно перевірити підставу кожної рекомендації, не довіряючись engine на віру.
4. Як ми обробляємо запити
Три способи запустити 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 (~302KB) у in-memory FS. Engine крутиться у браузері. Patient JSON не покидає машину.
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.
5. Що повертаємо назад
Engine повертає Plan (treatment mode) або DiagnosticPlan (workup brief). Кожен Plan містить:
| Поле | Що містить |
|---|---|
tracks[] | ≥2 alternative tracks (default first), кожен з indication + regimen + monitoring + supportive_care + contraindications |
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) |
kb_resolved | всі referenced entities (Disease, Tests, RedFlags, Algorithm) для render layer |
warnings | schema/ref errors, time_critical disqualifications, missing data hints |
supersedes / superseded_by | версійний chain між plans для тієї ж пацієнта |
Опціонально вмикається MDT brief — orchestrate_mdt() читає Plan + патієнтський профіль і додає required/recommended/optional ролі (з 16 віртуальних спеціалістів), open questions, provenance graph. Renders як inline section у Plan HTML.
6. Як план оновлюється при появі нових даних
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.
clinical_record
free-text НЕ тригерить regeneration (engine не читає free text).
7. Що ще робимо
Pre-biopsy режим: коли histology ще немає, engine видає Workup Brief зі списком тестів, biopsy approach, IHC panel і ролей triage MDT. Per CHARTER §15.2 C7 — без histology treatment Plan не генерується.
Orchestrator читає Plan + profile і призначає required/recommended/ optional ролі (16 catalog), формулює open questions (Q1-Q6 + DQ1-DQ4), будує decision provenance graph.
python -m knowledge_base.stats — actual entity counts
+ per-disease coverage matrix + reviewer signoff ratio. Доступне
як CLI / JSON / embeddable HTML widget для landing page.
Single-file HTML з embedded CSS, без external assets крім Google Fonts.
Adapt'ується під A4 print через @page + @media print.
Tracks side-by-side, alternative не сховано (anti automation-bias per CHARTER §15.2 C6).
enumerate_experimental_options(...) запитує
ClinicalTrials.gov v2 за disease + biomarker + line_of_therapy і
повертає ExperimentalOption з UA-availability metadata
(sites_ua, countries) — render-time, engine не використовує trial
як сигнал вибору. Status filter: RECRUITING /
ACTIVE_NOT_RECRUITING / ENROLLING_BY_INVITATION; інтегровано у
generate_plan, render показує третій трек у Plan;
7-day on-disk TTL cache для офлайн-запусків.
Кожен Plan містить AccessMatrix — per-track agg-table
UA-реєстрації, НСЗУ-покриття, cost orientation (₴ ranges) і
primary AccessPathway. Render-time only (CHARTER §8.3,
invariant test guarantee). Stale-cost warning при
cost_last_updated > 180 днів. Trial-рядки додаються
автоматично коли experimental track активний.