Prior Authorization in Medical Oncology: Joining the CodeX Effort to Get Patients to Treatment Faster

We're excited to share that Vermonster is part of the CodeX Prior Authorization in Medical Oncology (PA in MedOnc) use case team — a multi-stakeholder HL7 FHIR Accelerator working group that met with practicing oncologists and administrators at the end of 2025 to understand, in their own words, what prior authorization actually looks like at the bedside. The findings were recently published by CodeX, and they confirm what most of us in the space have felt for years: the technology exists, the standards exist, and the gap is getting them to work together in the workflow that already exists.

We're contributing to the specification development alongside AMA, ASCO, Drummond Group, Hike Health, Oracle Health, OncoHealth, Onyx, Optum, PhenoML, and others, and we're building an initial reference implementation of the Da Vinci burden reduction APIs in the breast cancer scenario the group is prototyping. If we get this right, it's not just about efficiency. It's about getting patients to treatment faster.

This post is half announcement, half perspective. The full CodeX write-up is worth reading in its own right, and we'll link to it. What's below is what we heard, what we're doing about it, and why we think the oncology use case is the right forcing function for a problem that runs through the rest of healthcare.

---

What the focus groups actually said

CodeX ran seven one-hour focus groups between October 28 and December 19, 2025, with 14 participants — 7 physicians and 7 administrators from 9 practices and health systems, across both hospital-based and outpatient settings. The participants were invited by the AMA and ASCO representatives on the working group. The conversations were recorded and transcribed.

Four themes came through clearly. None of them are surprising on their own. What's striking is how consistently they showed up across both physicians and administrators, and how directly they point to a specific kind of solution.

The data is already in the record — it just can't be used

Multiple oncologists stressed how much of what prior authorization needs is already documented in the chart — but in PDFs, scanned attachments from third-party labs, or narrative clinical notes that don't round-trip through any structured field. One hospital-based oncologist on the West Coast said it plainly:

"Lung cancers, the way you treat anybody with stage 4 — actually now, stage 2 and 3 lung cancer — really depends on their EGFR mutation status... sarcomas depend on a lot of discrete pathologic data, including size, number of mitoses in the tumor... these are all things that you'd have to get from pathology [from external systems]."

The data exists. It lives in the EHR, in outside lab portals, in scanned PDFs, in dictated notes. None of it is queryable in a way that prior authorization can use without a human re-entering it into a payer portal. The unlock isn't more data capture — it's making existing data legible to the systems that need it.

Provider pathways and payer pathways are not the same

Providers follow clinical pathways from NCCN, ASCO, Dana-Farber, or their own proprietary pathway. Payers, in the experience of the focus group participants, often use their own proprietary pathways — and even where they align with published guidelines, the preferred drugs on a payer's pathway may not match what a community oncologist would actually prescribe. One oncologist put the alignment between their practice's pathway and payer pathways at "around 25%."

The 25% number is the one that should stop a room. It means that the majority of the time, an oncologist following their own pathway is going to find out, in retrospect, that the payer has a different preferred route. The CodeX piece quotes a hospital-based oncologist on the East Coast:

"Our doctors are really blind to what the payer's pathway is... they're looking at our source of truth, our gold standard... And it's only in retrospect after [it's] submitted that we might find that that's not offered on the payer's pathway."

The same oncologist called it "a gift" to have something that could read payer medical policies up front and surface the differences early. That's the entire premise of CRD (Coverage Requirements Discovery) — the question is whether it can be made to work for the specific shape of oncology regimens.

Any new technology has to fit the EHR — not the other way around

After the focus group discussion, the working group demoed a prototype EHR flow that uses FHIR to "work behind the scenes" during prior authorization submission. The reactions are the most useful part of the article.

Participants were clear: any new technology has to fit seamlessly into the existing EHR workflow, minimize clicks, and avoid sending the user to a separate payer portal. One hospital-based oncologist in the Midwest said:

"As long as it pulls [from the EHR automatically]... because a lot of this information [are things] physicians or staff in their own practice are putting into their own system. And what is infuriating and frustrating is to go to another portal and add in the same information you already put in."

That quote is the whole product thesis. The user is not going to retype data they already entered into their own system. If the workflow requires it, the workflow is wrong. The technical question is whether the FHIR APIs and the EHR data model are expressive enough to make the auto-population real, and not just a demo.

The current roles are entrenched because the system is broken

PA workflows in oncology today are mostly the domain of specialized administrators — not because the work is administrative, but because the clinical knowledge required to fill out a payer-specific form correctly has drifted out of any single role. Physicians don't have time, and don't have the payer-policy knowledge. Administrators have the payer knowledge but usually not the clinical context to know, for example, which line of therapy a patient is on or which biomarker test result to attach.

A hospital-based oncologist in the Northeast described the volume problem:

"Our volumes are just so intense that you don't have time to dedicate what we used to. I mean, when I first graduated in 2006 to do a full day was about 15 patients. Now, a full day is up to 26, 27 patients. And the complexity of patients now, too, is that you're not just dealing with pathology, you're dealing with molecular. Do you have [specific genetic] tests? Do you have circulating tumor cells? You know, all these things are required for every patient."

The compounding effect — more patients per day, more complex decisions per patient, more documentation required per decision — is what makes the status quo untenable. The technology can't fix the volume, but it can fix the part of the volume that comes from re-doing work that was already done.

---

Why oncology is the right use case to start with

Prior authorization is hard in every specialty. Oncology is where it's hardest, and that's exactly why it's the right place to do the work.

Three things make oncology a forcing function:

• Regimens, not services. Most prior authorization in healthcare is for a discrete test, procedure, or drug. In oncology, the unit of authorization is usually a regimen — multiple drugs, given on a schedule, often spanning both the medical and pharmacy benefit. The Da Vinci burden reduction APIs were originally written around the simpler case. Oncology stretches them, and any fix that works for oncology works for the simpler cases too.
• Evidence moves weekly. A new indication, a new combination, a new biomarker — oncology guidelines don't sit still. The "current guidelines" used in a prior auth form may be a version behind. That's part of why the CodeX work is paying close attention to the mCODE Implementation Guide (developed by MITRE and ASCO) as a common language for digitized oncology data. If the data is mCODE-shaped, guideline updates become a query, not a re-authoring effort.
• The cost of delay is measured in weeks of life. This is the part the technical community tends to underweight. A few days of administrative delay in approving a hypertension medication is one thing. A few days of delay in approving a first-line therapy for an aggressive malignancy is, in many cases, the difference between a patient who gets curative-intent treatment and one who doesn't. The reason to do this work is not that the workflow is bad. The reason is that the workflow is bad at the worst possible time.

That's why the CodeX team's decision to start with a real oncology scenario — breast cancer, in the initial proof of concept — matters more than it might look. The complexity isn't a side effect of the use case. The complexity is the use case.

---

What we're contributing

Our piece in the working group is split across two tracks: specification development and an initial reference implementation.

On the spec side

The CodeX PA in MedOnc use case is building on the existing Da Vinci burden reduction Implementation Guides — CRD (Coverage Requirements Discovery), DTR (Documents Templates & Rules), and PAS (Prior Authorization Support) — and identifying where they need to be extended or constrained to handle the regimen-level shape of oncology prior auth. Our team is working alongside the rest of the working group to:

• Identify the clinical data elements that an oncology prior auth questionnaire needs to be able to auto-populate from a structured record, and the gaps where today's EHR data isn't structured enough to populate them.
• Define how a CRD response should communicate pathway differences — not just "this service requires prior auth" but "this service requires prior auth and the payer's preferred regimen for this indication differs from the regimen your pathway would suggest." That's the bit that turns CRD from a coverage check into a clinically useful preview.
• Map the data elements required by the use case against the mCODE IG, so that the data the prior auth needs is the same data that other oncology use cases (clinical trial matching, registry submission, quality measurement) also need. We want one record, many use cases — not a new oncology PA silo.

On the reference implementation side

The working group is prototyping in a simulated breast cancer scenario, with a clinical advisory group providing feedback along the way. The reference implementation is a runnable end-to-end demonstration of:

• A provider EHR (or a faithful stand-in for one) expressing the relevant data in FHIR using QI-Core and mCODE profiles
• A payer-side CRD/DTR/PAS endpoint that consumes the request, evaluates payer policy, and returns the prior auth questionnaire pre-populated from the patient's record
• A clinician-facing flow that shows, before submission, where the proposed regimen aligns with the payer's pathway and where it doesn't — the "pathway preview" the East Coast oncologist asked for
• A submission path that writes the result back to the EHR and tracks status through the existing workflow, not a separate portal

The reference implementation isn't a product. It's a working artifact the working group can use to validate the spec, show end-to-end feasibility at Connectathons, and give implementers something concrete to point to. We'll publish what we build in the open as the working group agrees on what to share.

---

What we think this changes

A few things this effort can move, if it lands:

• The "25% alignment" number becomes a leading indicator. If pathway differences are surfaced in CRD, alignment becomes something you can measure in real time across regimens, indications, and payers. The 25% becomes a number that moves — and a number someone in a payer or provider organization can be accountable for.
• mCODE becomes the lingua franca for oncology data, by pressure not by mandate. The more prior auth, quality measurement, registry, and trial-matching use cases that ask for the same structured data, the less optional mCODE-shaped data becomes. We're not mandating adoption. We're just making it the path of least resistance.
• The reference implementation becomes the Connectathon substrate. One of the things that slows down prior auth interoperability is that every implementer ends up building a slightly different prototype. A shared reference implementation, validated against the spec and used as the basis for Connectathon testing, gets everyone arguing about the same concrete behavior instead of about abstractions.
• The "getting to treatment faster" promise becomes measurable. Not just "we automated a step" — but "time from treatment decision to PA decision dropped from N days to N hours, with no loss of clinical appropriateness." That's the outcome that justifies the work.

None of this is a guarantee. Working groups publish findings, and not all of them land. The reason we think this one might is that the use case is concrete (breast cancer scenario, real regimen, real questionnaire), the standards are real (CRD/DTR/PAS plus mCODE), the participants are real (provider organizations, payers, vendors, specialty societies, the standards body), and the cost of the status quo is real in a way that doesn't let anyone pretend otherwise.

---

How to follow or get involved

The CodeX team has been generous with their work, and the article is the public-facing summary. The underlying materials — confluence pages, focus group discussion guides, the spec drafts as they mature — live with the working group.

• Read the CodeX write-up. It's the source for most of what we summarized above and goes into more depth on the focus group methodology and the individual quotes. The CodeX HL7 FHIR Accelerator published it on LinkedIn, and we'll link to it from this post.
• Reach out to the working group. The CodeX PMO (PMO@HL7CodeX.org) is the right contact for getting involved as a use case participant or following the work.
• Talk to us. If you're a payer, provider, specialty society, or vendor working on oncology prior auth — or if you're building the EHR side of this and want to compare notes on mCODE-shaped data — we'd love to talk. ReasonHub is the platform side of what we do; the human side of what we do is conversation.
• Watch the Q4 2026 findings. That's when the proof of concept wraps and the working group publishes what they learned. If the spec is right and the reference implementation demonstrates the workflow, we expect a Connectathon track in the next HL7 cycle.

The reason this work matters is captured in a single sentence from the focus groups:

"The prior auth process is never going to go away. We all realize that. But it has to be equitable, and it has to be feasible from a provider and a patient standpoint."

That's the whole brief. Equitable and feasible. The standards give us a chance at feasible. The patient is the reason we have to keep trying for equitable. We're glad to be part of the working group, and we'll keep you posted as the work progresses.

Thanks for reading. And if you're an oncologist or administrator who's lived this workflow — we see you. The work is for you.