COORDINATOR
Gemma 4 26B
Connects questions with catalog lookups and compatible specialist tools. Workflow performance remains under evaluation.
Local text coordination THE CANCER RESEARCH WORKBENCH
Research should
move forward.
Not start over.
OncoloHealth brings cancer datasets, specialist models, and evaluation into one research workbench—so the next discovery can build on the last.
Built for research.
Grounded in evidence.
Grounded in evidence.
IMAGING / RESEARCH EXAMPLES01 — 04
BONE X-RAY / BTXRD01 / BONE RADIOGRAPHOne image.
One image.
More context.
Our BTXRD audit found duplicate images and label conflicts. Patient grouping remains unresolved.
Explore the audit ↗01 / THE ONCOLOHEALTH APPROACHRESEARCH, WITH CONTEXT
01 / THE OPPORTUNITY
Better science starts
with better foundations.
Cancer research moves fast. The work of finding, understanding, and comparing the building blocks is often repeated from scratch.
We’re building a place to bring that work together: the datasets, the models, the provenance, and the questions that still need answers.
Why the evidence matters ↗THE COLLECTION
Datasets and models,
mapped.
THE PROJECT LANDSCAPE94datasets in the reported survey
EXPLORE THE RECORDS23dataset records on this site
MODELS & COORDINATION27model and coordinator records
02 / THE WORKBENCH
From question
to evidence.
Explore the datasets, models, and research behind each stage of the work.
BTXRDRelease audit ↗
3,746images checked against the published release
- Image identity
- 21exact duplicate pairs
- Label agreement
- 2pairs with conflicting labels
- Published splits
- 7exact pairs crossing train and validation lists
DATA REVIEW / BTXRD
What a release
audit revealed.
Duplicate images and contradictory labels can change how a study is interpreted.
We reconciled image files, annotations, and published split lists. Four contradictory copies were excluded from a corrected exploratory split.
Still unresolved
Read the findings and evaluation ↗The release does not provide reliable patient or lesion grouping. The audit cannot establish patient independence.
CONTINUE EXPLORING
Research, platform,
and people.
Explore the evidence behind our work, the tools being built, and the team bringing them together.
RESEARCH / DATA & MODEL EVIDENCE
Data audits.
Model evaluations.
Our current work examines cancer datasets, compares model adaptations, and records the choices that shape each result. Explore the BTXRD release audit and the evaluations below.
source centers.
Frozen RAD-DINO and ResNet-50 encoders, compared across three endpoints.
READ THE SOURCE-SHIFT REPORT ↗BTXRD / RELEASE AUDIT
What the release
contains.
BTXRD is a public bone-tumor X-ray dataset. Our release audit investigated image identity, annotations, labels, and published split lists.
Read the audit ↗3,746image rows and images
21exact duplicate pairs
2pairs with conflicting labels
7exact pairs crossing published train/validation lists
DATA REVIEW / BTXRD
Corrections and
unresolved questions.
Every change needs a reason and a record. The audit distinguishes confirmed inconsistencies from questions that the release cannot resolve.
Read the source paper ↗CONTRADICTORY COPIES4 excluded
Four contradictory copies were excluded from a corrected exploratory split. This does not establish that every duplicate or label error has been found.
SPLIT-LIST FILENAMES27 mismatches
Filenames in the published classification lists were missing their true extension. The release contains 1,867 tumor annotations.
NEAR-DUPLICATESCandidates for review
A separate search surfaced near-duplicate candidates. Candidate matches require review before exclusion.
PATIENT & LESION GROUPINGUnresolved
The release does not supply a reliable patient or lesion mapping. Duplicate screening alone cannot establish patient independence; diagnostic reference evidence also needs review.
BTXRD / SOURCE-SHIFT FOLLOW-UP
Performance changed
across centers.
Exploratory image-level experiments compared frozen RAD-DINO and ResNet-50 encoders. Select an endpoint to inspect the results.
ROC-AUC / BY ENDPOINT
EXPLORATORY · IMAGE-LEVELValidation and test results.
Center 1 validation Centers 2 + 3 test
0.500.600.700.800.901.00
These centers had already been examined in earlier work. Image-level intervals do not account for patient clustering. This is not an independent external evaluation or a measure of clinical performance. Values use padding for RAD-DINO and native crop for ResNet-50.
Read the complete report ↗MODEL ADAPTATION / TEAM-REPORTED RESULTS
Task-specific heads,
compared with the baseline.
OncoloHealth builds on leading research models and measures task-specific adaptations against the prior baseline. A higher accuracy does not resolve every tradeoff.
FROZEN RESNET-50 COMPARISON HEADSACCURACY / ORIGINAL → COMPARISON
01Pathology7,180 test images
51.0%→80.8%
02Skin lesion2,005 test images
51.5%→59.2%
03Breast ultrasound156 test images
76.3%→77.6%
Accuracy shown for the original and comparison heads in the team’s report. For ultrasound, AUROC decreased from 0.833 to 0.830 and malignant recall stayed at 66.7%. These test sources had already been examined, and patient grouping is not established. Results are exploratory, not independent clinical validation. The detailed scoreboards are not currently published in the repository.
Read the comparison record ↗RESEARCH AREAS
Five areas of work,
one evidence trail.
Each area has its own module, a written report and a recorded status. Drag the track or choose an area to see where each one stands.
HOW TO READ THE EVIDENCE
Different records answer
different questions.
Catalog entries, local runs, and study results describe different kinds of work. Their evidence should be assessed separately.
RECORDWHAT IT DOCUMENTSWHAT STILL NEEDS REVIEW
Dataset or model record
A source, declared access conditions, terms, and a description of the resource.
Access, technical compatibility, and evidence for the intended use.
Local specialist run
An input, a model, and an observed output in the local setup.
Training overlap, reproducibility, and performance on an appropriate evaluation set.
Exploratory comparison
Measured results for a stated endpoint, split, and model configuration.
Patient grouping, reference evidence, uncertainty, and genuinely unseen sources.
PLATFORM / THE WORKBENCH
The cancer research
workbench.
Find datasets, inspect data quality, run compatible specialist models locally, and review the result with its source and limitations attached.
View the repository ↗INSIDE THE WORKBENCH
Follow a research question through the project’s documented tools and findings.
THE MODEL STACK
Coordination.
Representation.
Specialization.
Different models do different jobs. The project combines a local coordinator, reusable image representations, and specialist imaging tools.
IMAGE REPRESENTATIONSRAD-DINO
RAD-DINO
& ResNet-50
Frozen encoders support exploratory BTXRD comparisons. Task-specific heads are evaluated against baselines, with source shift and unresolved patient grouping kept visible.
Read the source-shift report ↗IMAGING SPECIALISTSMONAI
MONAI
SegResNet & RetinaNet
Local demonstrations cover brain tumor segmentation and full-scan lung nodule detection. Additional research baselines include ultrasound, pathology, skin, and lung patches.
Explore model records ↗Some demonstration samples may overlap original model training data. Access, technical requirements, and dataset or model terms vary by record.
Open the model registry ↗DATA & MODEL STEWARDSHIP
Review before
reuse.
We select leading research models and datasets for the question at hand, inspect data quality, and measure adaptations against baselines. The proposed sharing standard calls for privacy, permissions, and training-provenance review before release.
CATALOG / A PLACE TO BEGIN
Find the work.
Know the context.
Explore the datasets and models in OncoloHealth’s research landscape—from repository records to mapped resources—with access, evidence, and open questions in view.
View source records ↗DATASETS & MODELS
Search the records.
Search the detailed dataset and model records by modality, access, and status. Each record includes its source, terms, and open questions.
94 datasets in the project surveyTeam-reported · broader than the detailed records belowView modality coverage +
THE DATA LANDSCAPE / PROJECT SURVEY94
datasets in the reported survey
The team-reported survey spans imaging, tissue, clinical data, and genomics. A dataset can appear in more than one modality; the full survey inventory is not linked here.
Survey compiled October 24, 2026. The detailed records below are the subset available in the accessible repository and project materials.MODALITY COVERAGEDATASETS / NOT ADDITIVE
This collection combines the accessible repository snapshot with additional resources named in the project materials. It is not a live inventory of installed or runnable resources. Access, terms, and evidence vary by record.
BEFORE REUSE
Check the data.
Review the terms.
PARTNERSHIPS / RESEARCH COLLABORATION
Better research is
a team effort.
We’re interested in working with research groups, data stewards, and organizations that believe oncology tools should be built on clear evidence and shared learning.
Start a conversation ↗AREAS FOR COLLABORATION
Where we can
work together.
OncoloHealth is early-stage research software. We welcome collaboration across research, data stewardship, and translation.
COLLABORATION / 01RESEARCH TEAMS
WORK WITH ONCOLOHEALTH
Study design &
evaluation.
Work together on clear research questions and evidence that can be reproduced.
01Study designEndpoints and appropriate baselines
02Data qualitySource, labels, and patient grouping
03EvaluationReproducibility and independent testing
SERVICES / WHAT WE CAN TAKE ON
Look beneath
the surface.
Five kinds of work, drawn from what the project already does. Hover or tap a card, or choose X-ray view, to see the method underneath.
- RESEARCH TEAMS
Study design & evaluation
Set the task, endpoint and comparison baseline before anything is trained, then plan an evaluation that others can reproduce.
- Endpoints and appropriate baselines
- Patient- or lesion-grouped splits
- Leakage checks, calibration and uncertainty
- DATA STEWARDS
Dataset audits
The review we ran on the BTXRD release, applied to your data: image identity, duplicates, label conflicts, split lists and source documentation.
- Exact and near-duplicate screening
- Label conflicts between copies
- Corrections kept apart from open questions
- RESEARCH TEAMS
Model adaptation
Task-specific heads on frozen encoders such as RAD-DINO and ResNet-50, measured against the baseline they are meant to improve.
- Frozen-encoder features
- Task heads compared on the same split
- Results reported with their tradeoffs
- RESEARCH TEAMS
Workbench & specialist models
Help running the local research workbench: the catalog, verified downloads within a storage budget, dataset inspection and specialist model runs.
- Runs on localhost
- Downloads recorded with their provenance
- Models routed by modality and task
- ECOSYSTEM PARTNERS
Catalog & licensing review
Check what a dataset’s or model’s terms allow for the intended use before it is built into a study or a product.
- License and access conditions
- Inference permission
- Open questions recorded per record
STARTING A COLLABORATION
Bring a question.
Define the study.
A useful first discussion starts with the research question, the available data, and the evidence a study would need.
- What are we testing?
- The task, intended setting, endpoint, and comparison baseline.
- What can the data support?
- Source documentation, permissions, labels, and patient or lesion grouping.
- What would count as evidence?
- Metrics, leakage checks, independent evaluation, and a record others can inspect.
PROCEDURE / HOW AN ENGAGEMENT RUNS
How an engagement
runs.
Five stages, each ending in something written down. Select a stage to see what it involves.
- Covers
- The task and the setting it is meant for
- The data you hold or plan to use
- What a useful result would look like
From the projectSome questions cannot be answered with the data that exists. Saying so early is part of the work.
OutputAn agreed starting point, or a clear no.
- Covers
- Endpoint and comparison baseline
- Dataset sources, permissions and terms
- Patient or lesion grouping
- What would count as evidence
From the projectDataset and model terms differ, and not every cataloged model can be used commercially. Terms are checked against the intended use.
OutputA written scope both sides can check against.
- Covers
- Exact and near-duplicate screening
- Label conflicts between copies
- Split lists checked for leakage
- Source documentation
From the projectThe BTXRD release audit found 21 exact duplicate pairs, 2 with conflicting labels, and 7 crossing the published train and validation lists.
OutputAn audit that keeps corrections apart from open questions.
- Covers
- Frozen-encoder features and task heads
- Grouped splits fixed in advance
- Configuration and lineage recorded per run
From the projectThe source-shift follow-up compared frozen RAD-DINO and ResNet-50 encoders across three endpoints on BTXRD.
OutputRuns that can be traced and repeated.
- Covers
- Metrics, calibration and uncertainty
- Comparison with the baseline on the same split
- Limitations stated with the result
From the projectImage-level intervals do not account for patient clustering, so the reports say so next to the numbers.
OutputA record others can inspect.
QUESTIONS & ANSWERS
Working with
OncoloHealth.
What does OncoloHealth bring together?+
The project connects cancer datasets, specialist models, data review, and evaluation in a research workbench.
Can every cataloged model be used commercially?+
No. Dataset and model licenses, access conditions, and inference permissions differ. Each must be reviewed for the intended use.
What would a collaboration look like?+
That depends on the question. Relevant starting points include dataset evidence, reproducible workflows, evaluation design, and research partnerships. Connect with Jordi on LinkedIn to start a conversation.
LET’S TALK
Discuss a study
with us.
Have a research question, dataset challenge, or partnership idea? We’d like to hear it.
Request a quote ↗MODELS / THE REGISTRY
Know the model
before you build on it.
Inspect each model’s description, recorded source, access conditions, and open questions. A catalog entry does not establish that a model is installed, runnable, or evaluated for your use.
View the model records ↗ResNet-50.
Candidate cards and the frozen-encoder adapter contract behind the BTXRD comparisons.
READ THE MODEL CARDS ↗REGISTRY / CURRENT RECORDS
What this registry
records.
Counted from this website’s catalog snapshot. Cataloged records come from the repository; mapped records are identified in the project’s model landscape. Check each publisher for current terms and access.
MODEL RECORDS27
- 14 cataloged
- 1 project coordinator
- 12 mapped
OPEN ACCESS9/ 27
- 9 open
- 5 registration or gated
- 13 review source terms
MODALITIES COVERED9
- 13 language & coordination
- 9 pathology
- 7 CT, and 6 more
RECORDS WITH OPEN QUESTIONS13
- 13 name what still needs checking
- 14 none recorded
MODEL REGISTRY / CATALOG RECORDS
Every model,
with its terms.
Filter by modality, access, licence and state, or sort any column. Open a record for its summary, terms, permission and open questions.
| Details |
|---|
No matching models.
Try another search or reset the filters.
Records combine the repository’s catalog/models.json with models named in the project’s research landscape and shortlist.
UPGRADES / MEASURED CHANGES
What has
improved.
Changes measured against the prior baseline, and the dated work behind them. Each result keeps the limits its report records.
Foundation and first catalog
16 model and 14 dataset records, with revisions, sizes, gating and licences checked against their sources. A router that checks fit and never auto-selects a model.
Project record ↗BTXRD inventory and manifest
3,746 images and 1,867 annotation files reconciled. 21 byte-identical pairs now share a duplicate group; two pairs carried conflicting labels.
Project record ↗Model cards and encoder adapter
Candidate cards for RAD-DINO and ResNet-50, and a frozen-encoder adapter that returns an embedding result envelope.
Model cards ↗Exploratory BTXRD baseline
Image-level ROC-AUC of 0.83 to 0.86 when train and test share sources, and 0.60 to 0.62 when trained on center 1 and tested on centers 2 and 3.
Baseline report ↗Source-shift check
The native center crop lifted ResNet-50’s test ROC-AUC from 0.623 to 0.690 for benign vs malignant. The gap to center-1 validation remains.
Source-shift report ↗Metric hardening
Validated inputs and groups, explicit undefined metrics and invalid-draw accounting for bootstrap intervals, covered by 24 synthetic regression tests.
Metric report ↗Experiment workspace
An Experiments screen with draft checks, durable drafts that never authorize execution, and a read-only history of recorded runs.
Workspace report ↗Measured feature provenance
Feature caches bound to measured image bytes, model files and preprocessing. Forty new regressions brought the suite to 218 tests.
Provenance report ↗Literature retrieval
PubMed search for the coordinator, with an identifier-level check that flags citations not retrieved in the same turn.
Retrieval report ↗Offline release review
A read-only audit of the BTXRD archive and an evidence template, checked against 3,746 source-bound rows.
Release review ↗Identity formatting guard
Padded or whitespace-only identities are refused rather than rewritten. The combined suite discovered 253 tests.
Identity report ↗
PUBLIC CODE / THE REPOSITORY
Public code.
Open records.
The workbench, catalog, and research reports are public on GitHub for inspection. A project code licence has not yet been selected; access, model files, and upstream terms also affect reuse.
View on GitHub ↗WHAT IS OPEN
Everything a result
depends on.
Code, records, reports, and evaluation methods live in one repository and change together, so a finding can be traced to what produced it.
- Code
The
cancer_workbench/ ↗cancer_workbenchpackage: catalog validation, model routing, verified downloads, dataset audits, grouped splits, the coordinator, and the local researcher app.- Catalog records
Source-checked dataset and model records with licence, access, evidence state, acquisition, and citation. One canonical copy, validated by the registry.
catalog/ ↗- Reports
Workstream deliverables, including the BTXRD release review, the source-shift follow-up, the evaluation protocol, and the model cards.
docs/reports/ ↗- Evaluation records
Metrics, calibration, thresholds, leakage checks, paired comparisons, the experiment record schema, and a synthetic test suite that runs on every push.
tests/ ↗
Project code licence: to be confirmed. Datasets and models keep their upstream licences and access terms, recorded in each catalog record.
REPOSITORY MAP
Find your way
around the code.
Select a folder to see what it holds and how it connects. Imports flow one way: nothing below the app imports the app.
catalog/SOURCE OF TRUTH
Dataset and
model records.
Source-checked records with licence, access, evidence state, acquisition, and citation. Code reads them and never changes a record’s evidence state on its own.
- Key files
- models.json · datasets.json
- Changes
- Evidence states move only through a reviewed pull request.
cancer_workbench/THE PACKAGE
One package,
a standard-library core.
The command line and the local app sit on top of the modules listed beneath it. ML libraries are optional extras, imported only inside the modules that need them.
- Entry point
- python3 -m cancer_workbench
- Commands
- app · fetch · catalog · route · coordinator · btxrd · baseline · source-shift · near-duplicates
cancer_workbench/common/SHARED TYPES
The contracts
every module shares.
ResultEnvelope, EvidenceState, Permission and ResultStatus, plus project paths that environment variables can override. It imports nothing from the rest of the package.
- Key files
- types.py · paths.py
- Review
- Changes need review from two workstreams.
cancer_workbench/acquisition/VERIFIED DOWNLOADS
Fetch within
the budget.
Resolvers for Hugging Face, Zenodo, figshare, TCIA and plain URLs plan each file. Downloads resume, verify checksums, extract archives safely, and write a PROVENANCE.json beside every artifact.
- Key files
- sources.py · download.py · fetch.py · budget.py
- Storage budget
- Configurable with
CW_STORAGE_BUDGET_GB; check the current setup for its default.
cancer_workbench/registry/CATALOG LOADING
Load and validate
every record.
Loads both catalogs with a duplicate-id check, lookup and search. The schema validator checks required fields, enums, and that adapters and evidence states agree.
- Key files
- store.py · schema.py
- Used by
- Acquisition, the coordinator’s tools, the app, and the command line.
cancer_workbench/routing/COMPATIBILITY
List the options.
Never pick one.
The router returns compatible models with their blockers and rejected models with reasons. A model is runnable only when it is locally reproduced, inference is allowed, and an adapter exists.
- Key file
- router.py
- Functions
- route_models · compatibility_reasons · runnable_blockers
cancer_workbench/adapters/THE ONLY WAY A MODEL RUNS
An honest answer
or none.
execute_specialist checks compatibility, blockers and the adapter, validates the inputs, and returns a result envelope: a rejection or failure instead of an invented answer. The frozen-encoder adapter loads RAD-DINO and ResNet-50 from safetensors only.
- Key files
- base.py · encoder.py · synthetic.py
- Outputs
- Kept native. Different models are never merged into one cancer probability.
cancer_workbench/datasets/MANIFESTS & AUDITS
Audit the data
before the split.
The manifest contract, the dataset audit for leakage, missing patient ids, labels and file integrity, deterministic group-preserving splits, the BTXRD manifest builder, and the offline release review.
- Key files
- manifest.py · audit.py · splits.py · btxrd.py · release_audit.py
- Rule
- A missing patient id is reported by the audit, never invented.
cancer_workbench/learning/FEATURES & HEADS
Frozen features,
measured inputs.
Feature extraction bound to the measured source, model and processor. Input checks run before any fit, and task heads are saved as plain arrays with no pickle.
- Key files
- features.py · provenance.py · heads.py
- Not yet built
- Teacher-student distillation.
cancer_workbench/evaluation/METRICS & LEAKAGE
Numbers that carry
their limits.
Validated metrics and calibration, development-only thresholds, patient-level aggregation, declared split and pretraining overlap checks, and paired patient-cluster bootstrap comparisons.
- Key files
- metrics.py · thresholds.py · aggregate.py · leakage.py · comparison.py
- Protocol
- Described in the F-evaluation-protocol report.
cancer_workbench/experiments/PLANS & RUNS
Drafts that
never execute.
Experiment plans come back blocked or ready for review, never authorized to run. Run records, the exploratory BTXRD baseline and source-shift runners, and near-duplicate ranking also live here.
- Key files
- plan.py · records.py · workspace.py · btxrd_baseline.py · btxrd_source_shift.py
- Run outputs
- Written locally to
runs/, outside version control.
cancer_workbench/coordinator/LOCAL COORDINATION
Tools a model
can call.
Works with compatible model servers through named profiles. The tool box validates every argument, and the loop feeds observed results back to the model until it answers.
- Key files
- providers.py · config.py · tools.py · loop.py · evaluation.py
- Tools
- search_catalog · get_record · route_models · run_specialist
cancer_workbench/retrieval/EVIDENCE SEARCH
A contract,
ready to build.
PubMed search with MedCPT reranking. The module is a stub: its package docstring is the contract to implement against, as with curriculum/ for reviewed tool-use examples.
- Status
- Stub. Calls raise
NotImplementedError. - Workstream
- D, coordinator and retrieval.
cancer_workbench/app/RESEARCHER APP
Seven screens,
on your machine.
A standard-library server bound to 127.0.0.1 with a host check and a per-launch token, JSON endpoints written as plain functions, background fetch and scoring jobs, and a front end with no build step.
- Screens
- Catalog · Downloads · Datasets · Images · Experiments · Assistant · Progress
- Key files
- server.py · api.py · jobs.py · scoring.py
configs/ENDPOINT PROFILES
Bring your own
model server.
Named endpoint profiles for vLLM, SGLang, Ollama, LM Studio and llama.cpp. Local profiles written by the app stay out of version control.
- Key files
- coordinator.example.json · coordinator-evaluation.json
- Local only
- coordinator.json
docs/REPORTS
The record behind
each finding.
Workstream deliverables in reports/, GPU setup notes, the coordinator evaluation guide, and the research handoff that separates verified work from open questions.
- Contents
- reports/ · research-handoff/ · big-machine.md · coordinator-evaluation.md
- Naming
- reports/<workstream>-<topic>.md
scripts/OFFLINE DEMOS
Run the demo
without data.
The offline demo exercises real catalog and execution calls with a scripted coordinator. It needs no medical data or model weights. The evaluation script runs the versioned development trace suite, offline by default.
- Key files
- demo_observed_results.py · evaluate_coordinator.py
- Results
- Synthetic software checks, not model reasoning.
tests/SYNTHETIC TESTS
Checked on
every push.
A standard-library test suite with synthetic fixtures only. GitHub Actions runs it on Ubuntu for each push and pull request. ML tests skip when their packages are absent, and no datasets, weights or secrets are needed.
- Run
- python3 -m unittest discover -s tests
- Python
- 3.11 · 3.12 · 3.13 · 3.14
QUICK START
From clone to
local app.
The core needs only Python 3.11 or later. The researcher app runs on your machine at 127.0.0.1:8765.
Live scoring and model work need the pinned ml extra. Add imaging or clip as needed.
$ git clone https://github.com/oncolohealth/oncolohealth.git$ cd oncolohealth$ python3 -m cancer_workbench app# opens the researcher app at http://127.0.0.1:8765$ python3 -m unittest discover -s tests$ python3 -m cancer_workbench catalog validate$ python3 -m cancer_workbench fetch list$ python3 -m cancer_workbench fetch plan --tier default$ python3 -m cancer_workbench route --task feature_extraction --modality xray --anatomy bone$ uv venv$ uv pip install -e ".[ml]"# add the imaging and clip extras as needed$ .venv/bin/python -m cancer_workbench appPUBLIC DATA / LOOK CLOSER
Inspect the
source images.
The imaging examples on this site come from public research datasets. Move across an image to magnify it. On touch, drag the lens; with a keyboard, focus the image and use the arrow keys.
- Dataset
- LUNA16 / LIDC-IDRI
- Licence
- CC BY 3.0
- Lens
- 2.5× · x 390 · y 390
HOW TO CONTRIBUTE
Claim a workstream.
Keep the record.
These steps follow the project’s working rules in PROGRESS.md and AGENTS.md. Datasets and models also need the documentation set out in the contribution standard.
Read the contribution standard ↗- 01
Read the map
Start with ARCHITECTURE.md for the code, PROGRESS.md for status and owners, and the research context for the scientific ground rules.
- 02
Claim a workstream
Put your name in the owner cell of one workstream in PROGRESS.md, from dataset curation (A) to independent review (H).
- 03
Stay inside your modules
Treat other modules as fixed interfaces. If you need a change there, open an issue or pull request and tag its owner. Shared types and the manifest contract need review from two workstreams.
- 04
Test with synthetic fixtures
Mark fixtures SYNTHETIC and never report synthetic results as medical performance. Run
python3 -m unittest discover -s testsbefore pushing; the core stays standard-library only. - 05
Report what you found
Put deliverables in
docs/reports/<workstream>-<topic>.md. Evidence states change only through a reviewed pull request to the catalog.
BUILD ON THE WORK
Read it. Rerun it.
Improve it.
Questions, corrections, and contributions go through the GitHub repository.
SUPPORT / RESEARCH & PARTNERS
Help for research.
And for partners.
OncoloHealth is early-stage research software. Find the right route for your question, see what the next release is planned to add, and cite the work you build on.
SUPPORT PATHS
Choose your
route in.
Research users work in the open repository. Commercial and partner conversations start with the partnerships team.
PUBLIC RESEARCHWork in the open,
Work in the open,
with the record.
The code, the catalog, the reports, and the issue tracker are public. Support for research users happens there, where everyone can see the answer.
- GITHUB ISSUESReport a bug or a record error
Bugs, reproducibility questions, and corrections to a dataset or model record. Include the command, your Python version, and the record id.
↗ - REPORTSRead the evidence
The BTXRD release audit, the source-shift follow-up, and how to read each kind of record.
↗ - CATALOGCheck a dataset or model
Source, licence, access conditions, evidence state, and open questions for each record.
↗
COMMERCIAL & PARTNERSPlan the study
Plan the study
together.
We work with research groups, data stewards, and organizations that want oncology tools built on clear evidence and shared learning.
- PARTNERSHIPSExplore collaboration
Research teams, data stewards, and ecosystem partners: where we can work together and how a study starts.
↗ - QUOTERequest a quote
Tell us about the work you have in mind, and we will scope it with you.
↗ - PERMISSIONSCheck licences first
Dataset and model licences, access conditions, and inference permissions differ. Each must be reviewed for the intended use.
↗ - CONTACTTalk to Jordi Nieves
Project coordination. Start a conversation on LinkedIn.
↗
HOW TO CITE
Cite the
repository.
Cite the repository with the commit you used, so others can reproduce your setup. Cite each dataset and model too: every catalog record carries its upstream citation.
Find a record’s citation ↗OncoloHealth contributors. (2026). Cancer AI research workbench (cancer-workbench, version 0.1.0) [Computer software]. GitHub. https://github.com/oncolohealth/oncolohealth@software{oncolohealth_workbench_2026, author = {{OncoloHealth contributors}}, title = {Cancer AI research workbench}, year = {2026}, version = {0.1.0}, url = {https://github.com/oncolohealth/oncolohealth}}git rev-parse HEAD to your methods section.PROJECT STATUS
Work in progress,
from the record.
Local demonstrations, open questions, and planned work from the project’s progress record. Availability depends on the setup; research demonstrations are not clinical validation.
Next release
- Contribution workflow
Review and sharing safeguards for contributed datasets and models.
Planned - Contribution records
Source and version, permissions, private-information review, training provenance, and release context.
Planned - Release gate
Unverified sources, permissions, or training-data documentation keep a contribution from release.
Planned - Code licence
A licence for the project code remains to be chosen.
Open decision
Bone X-ray workflow
- Endpoint decision
Three-class, tumor vs normal, or benign vs malignant for BTXRD.
Open decision - Reference standard
Confirm label meanings and their reference standard from the source paper.
Open - Bone classifier
A local research demonstration has run; its evidence, grouping and intended use still need review.
Local demonstration - Analyze an image
Compatible inputs can be run in the configured local research setup. A result is not a validated diagnosis.
Research use
Specialists and coordination
- Lung CT
A full-scan nodule-detection demonstration ran locally on an already-inspected sample; broader evaluation remains open.
Local demonstration - Brain MRI
A segmentation demonstration ran locally on a public sample; training overlap and evaluation limits matter.
Local demonstration - Pathology
Local patch-level demonstrations and comparison heads have been examined; whole-slide grading remains open.
Research in progress - Live coordinator
A local assistant and tool workflows have been tested on the project machine. Further evaluation and failure review remain open.
Local research
QUESTIONS & ANSWERS
Before you
ask.
Short answers drawn from the repository and the sharing standard.
Which licence covers the code?+
A licence for the project code has not been chosen yet; it is an open decision in the progress record. Datasets and models keep their own licences and access terms, recorded in each catalog record.
Where do I report a problem?+
Open a GitHub issue. For a catalog correction, name the record id and the source that supports the change. Evidence states change only through a reviewed pull request.
Can I contribute a dataset or model?+
Not through this website, which does not accept uploads. The contribution workflow and its safeguards are planned for the next release. Model weights alone cannot establish that their training data were free of private information.
What do I need to run the workbench?+
Python 3.11 or later for the core, which uses only the standard library. Model work and live scoring need the pinned ml extra. Storage needs vary by dataset and model. Check the current setup guide and configure a storage budget if needed.
Where does the app run?+
On your machine. The researcher app binds to 127.0.0.1 and checks the host and a per-launch token. Downloads come from each record’s publisher, and the assistant connects to the endpoint profile you configure.
Can every cataloged model be used commercially?+
No. Dataset and model licences, access conditions, and inference permissions differ. Each must be reviewed for the intended use.
CONTACT
Talk to
the team.
For collaboration and partnership questions, contact Jordi Nieves, who coordinates the project. For bugs and record corrections, open a GitHub issue.
REQUEST A QUOTE / PARTNERSHIPS
Tell us what you’re
working on.
Describe the question, the data and the help you need. The form can save answers in your browser session and prepares a brief for you to copy and send to Jordi on LinkedIn.
Your brief
Your brief is ready.
Copy it and send it to Jordi on LinkedIn, where collaboration conversations start.
PRIVACY / RESPONSIBLE SHARING
Protect people.
Advance research.
Our proposed sharing standard calls for review of private information, permissions, and training provenance before datasets or models are shared.
THE SHARING STANDARDNEXT RELEASE
Privacy before
sharing.
sharing.
DATASETS
Review for private
information.
MODELS
Review training
provenance.
DOCUMENTREVIEWSHARE
THIS WEBSITE / CURRENT BEHAVIOR
What happens
when you visit.
The website and the research workbench are separate. This page describes the current website experience.
- Quote brief
- With no quote endpoint configured, the form prepares a brief for you to copy and send to Jordi on LinkedIn. It does not submit the request to OncoloHealth.
- Browser session
- When browser storage is available, the form saves answers in session storage so you can return to them during that session. The form’s restart control clears its saved answers.
- Fonts & links
- The website serves its typefaces with the site instead of requesting them from a third-party font service. Following a link to LinkedIn, GitHub, or a research source takes you to that service.
- Before launch
- Hosting, server logs, retention, and any deployed contact service need to be documented for the actual production setup.
CONTRIBUTION REVIEW / NEXT RELEASE
What a contribution
must document.
Sharing a useful resource requires a clear record of where it came from, what it contains, and how it may be used.
The next release is planned to include safeguards for contribution review and sharing. Unverified sources, permissions, or training-data documentation should keep a contribution from being released.
- Source & version
- Where the resource originated, the release or checkpoint, and the records needed to trace it.
- Permissions
- The dataset and model terms, authorized uses, and any restrictions on redistribution.
- Private-information review
- Evidence of the review of data for private personal information, including patient identifiers and sensitive personal details.
- Training provenance
- For models, the datasets and methods used in training. Submitting weights alone does not establish the privacy of the training data.
- Release context
- The intended use, method, and known limitations that must accompany an eligible contribution.
CURRENT WEBSITEContribution safeguards
Contribution safeguards
in the next release.
The contribution workflow and its safeguards are planned for the next release. This website does not accept dataset or model uploads.
Model weights alone cannot establish that the training data were free of private information. Training-data provenance needs review alongside the contribution.
Explore the project’s existing records and documented research.
Dataset & model catalog ↗Research reports ↗ABOUT / ONCOLOHEALTH
The people behind
OncoloHealth.
We’re building a shared workbench for cancer research, connecting datasets, specialist models, data review, and evaluation.
THE PROJECT
Keep the source.
Build on the result.
A useful result needs a record of the data, model, permissions, and choices behind it.
OncoloHealth brings those records into the research workflow. Our work includes dataset and model catalogs, local specialist demonstrations, and exploratory studies of data quality and model performance.
The BTXRD audit is one example: duplicate images and label conflicts led to a closer review of the release and the limits of its published splits.
THE TEAM
Building
OncoloHealth.
The project brings together work on implementation, research evaluation, and communication.
Contact Jordi on LinkedIn ↗- Jordi Nieves
- Project coordination
- Sebastian Rueda-Villamil
- Model & dataset implementation
- Moshe Helman
- Project collaborator
- Inam Qasimi
- Presentation & research communication
UPSTREAM WORK
Built with
open research.
The project builds on datasets, models, and methods released by the wider research community.
We keep source records and terms visible so researchers can inspect the work and review whether it fits their intended use. References to upstream work do not imply affiliation or endorsement.
Explore the datasets and models ↗