A certified tumor registrar reads an oncology note and pulls out stage, histology, biomarker status, and treatment line. It is careful, expert work, and it is slow, measured in minutes per patient, multiplied across every case a cancer center sees. Until recently, the only way to go faster was to train a narrow model for each field you wanted. That constraint just changed.
The change is "zero-shot" extraction: handing a large language model a clinical note and a description of the data elements you want, and getting structured output back without training the model on a single labeled example. No annotated corpus, no per-field classifier, no months of curation before you see a result. That is a genuinely different starting position for anyone who abstracts cancer data for a living, and it is worth being precise about both what it enables and where it still falls short.
What "zero-shot" actually means here
Traditional clinical natural language processing is supervised. If you want to extract tumor stage from notes, you assemble a few hundred or few thousand notes, have experts annotate the stage in each one, and train a model to reproduce those annotations. Want biomarker status too? Largely start over. The annotation burden is the reason most cancer NLP projects die in the planning phase, the labeled data is expensive, the experts who can produce it are scarce, and the resulting model extracts exactly the fields it was trained on and nothing else.
Zero-shot extraction inverts that. The model already encodes a great deal of medical language from pretraining, so instead of teaching it what a "stage" is, you tell it, in plain instructions, which elements to find and what shape to return them in. My colleagues and I described one version of this in Introducing mCODEGPT as a zero-shot information extraction from clinical free text data tool for cancer research (Zhang, Huang, Malin, Osterman, Long & Jiang, Communications Medicine, 2025). The premise is in the name: point a language model at unstructured oncology notes and ask it to populate mCODE, the minimal Common Oncology Data Elements, without the per-entity annotation and model training that conventional methods require.
Two things make that combination more than a demo. First, the absence of training data removes the single biggest cost in clinical NLP. Second, and less obvious, the model is not extracting into a vacuum. It is extracting into a schema.
The schema is what makes it usable
I have argued for years that the structured data layer is the real bottleneck in clinical AI, and zero-shot extraction does not change that, it depends on it. An LLM that returns free-floating "findings" produces more prose, not less. An LLM that returns mCODE-conformant elements produces something a registry, a trial-matching engine, or a quality program can actually consume.
This is why the standard matters as much as the model. mCODE defines what a cancer record should carry, disease, treatments, genomics, outcomes, in a form that travels between institutions. When the extraction target is a real schema, three things become tractable that are otherwise hopeless. You can validate output against a defined set of permissible values instead of judging prose. You can compose extraction across institutions, because everyone is aiming at the same elements. And you can route the result straight into existing infrastructure that already speaks the standard. The model does the reading; the standard makes the reading portable. Take either away and you are back to bespoke pipelines.
Where this could land: registries, trials, and EOM
If reliable zero-shot abstraction matures, the operational consequences are large and concrete.
- Registries. Cancer registry abstraction is a national-scale manual bottleneck. A capable extractor that produces a structured first draft for a human registrar to verify, rather than asking that registrar to start from a blank form, changes the unit economics of registry reporting, and could narrow the lag between a patient's care and that care becoming analyzable data.
- Trial matching. Matching patients to trials breaks down when the matching criteria live in prose the algorithm can't read. Zero-shot extraction of stage, biomarkers, and prior lines from notes is exactly the missing input, the difference between a trial that is theoretically open and a patient an engine can actually surface.
- EOM reporting. mCODE is the only method of submitting data to CMS's Enhancing Oncology Model. For a community practice, the cost of producing conformant data is a real barrier to participation. An extractor that helps populate mCODE from existing documentation lowers that barrier, turning a standard that is mandatory into one that is achievable.
The common thread is that all three are abstraction problems disguised as policy or research problems. The data exists; it is just trapped in narrative. Anything that reliably frees it compounds across every downstream use at once.
The caveats are the whole story
Now the discipline. A fluent answer is not a correct one, and the failure mode of a language model is precisely that it is wrong in well-formed, confident prose. When my team ran one of the first peer-reviewed clinical evaluations of a general LLM answering physician questions, the lesson was unambiguous: you cannot tell a reliable output from an unreliable one by reading it. You need ground truth and a measurement, and that is exactly as true for extraction as it was for question-answering.
So a zero-shot extractor is not a system you deploy and trust. It is a system you have to govern.
The errors that matter in oncology are not random, they are systematic and clinically loaded. A model that misreads a negation ("no evidence of metastatic disease" extracted as metastatic disease) does not produce noise; it produces a patient miscategorized in a way that can route them to the wrong trial or the wrong quality bucket. Temporality is hard: a note that recounts a prior stage alongside a current one invites the model to conflate them. Hallucinated specificity, a confident exact value where the source text was vague, is more dangerous than an honest abstention, because it survives a casual read. And performance is not portable for free: an extractor that looks excellent on one institution's notes can degrade on another's documentation style, which means every adopting site owes itself a local evaluation rather than a borrowed one.
None of this is an argument against the technology. It is an argument for treating extraction the way we treat any clinical instrument: with a measured accuracy, a characterized failure profile, and a human in the loop calibrated to where the model is weak. The right framing is not "the model replaces the abstractor." It is "the model produces a structured draft, and the abstractor's expensive expertise moves from transcription to verification", which is both a better use of that expertise and a safer system.
What I'd tell a registry, a trialist, or a CMIO
If you run abstraction-heavy operations, the actionable posture is neither adoption nor abstinence. It is the middle path that the caveats demand.
Pick a single, well-defined extraction target, one with a clear schema and an obvious downstream consumer, and build an evaluation before you build a workflow. Decide, in advance, what accuracy you require for that field and how you will measure it against ground truth in your own population, not a published benchmark. Run the model as a draft generator behind expert verification, instrument where it fails, and let the failure profile, not the hype, decide how much autonomy it earns. Extract into a standard from day one, so that whatever you abstract is portable to the next use instead of stranded in a one-off format.
The larger shift is already underway and is not going to reverse: the marginal cost of turning an oncology note into structured data is collapsing. That is good news for registries, for trials, and for every patient whose care is currently invisible to the systems meant to learn from it, but only for the institutions that pair the new extraction power with the old discipline of measuring whether it is right. The model is finally cheap. The reliability still has to be earned. If you want the foundation this rests on, the mCODE case study traces how the standard became the infrastructure that makes extraction worth doing in the first place.