TEFCA + FHIR for Oncology: The Data Spine That Makes Agentic Care Possible
TEFCA and FHIR are the boring infrastructure behind serious oncology AI. Without longitudinal interoperability, the agent is blind.
Most AI-in-oncology pitches start too late.
They start with the agent, the model, the interface, or the workflow automation. But the hard problem appears one layer below: can the system see the longitudinal cancer record well enough to act responsibly?
If the answer is no, the product is plumbing-incomplete.
TEFCA and FHIR are not glamorous. They are the data spine that makes agentic oncology care possible. TEFCA defines a national exchange framework. FHIR defines a modern API-shaped resource model. mCODE narrows that model toward oncology. Together, they do not solve every workflow problem, but they move oncology AI from screen-scraping and PDFs toward computable care context.
This is why interoperability is not a side topic. It is the substrate for Agentic Prior Authorization in Oncology and the structural answer to the payer-provider arms race.
The simple map
Think of the stack in four layers.
TEFCA is the exchange layer. The Assistant Secretary for Technology Policy/ONC describes TEFCA as the framework for nationwide network-to-network health information exchange, with Qualified Health Information Networks participating under a Common Agreement (ASTP/ONC). The Sequoia Project's RCE materials frame the Common Agreement as the contract that governs QHIN-to-QHIN exchange (RCE).
FHIR is the API layer. It provides resources such as Condition, Observation, MedicationRequest, MedicationStatement, DiagnosticReport, ServiceRequest, and CarePlan. In oncology, those resources are the raw material for diagnosis, biomarkers, treatment orders, labs, imaging, and requested services.
mCODE is the oncology layer. The HL7 mCODE implementation guide defines a minimal set of structured oncology data elements intended to improve interoperability and make research-quality cancer data more available from EHRs (HL7 mCODE).
The agent is the labor layer. It retrieves, reasons, drafts, checks, routes, and monitors. But it can only do that safely if the lower layers give it reliable context.
Why oncology is harder than generic FHIR
Generic FHIR interoperability is not enough for serious oncology work.
Oncology context is longitudinal and stateful. A safe system needs diagnosis, stage, histology, biomarkers, prior lines of therapy, response, progression, toxicities, performance status, organ function, goals of care, and payer-specific evidence requirements. Those facts live across structured fields, notes, pathology reports, molecular reports, imaging reports, scanned documents, and external records.
FHIR gives the grammar. mCODE gives oncology vocabulary. TEFCA improves exchange. The implementation still has to assemble a coherent cancer story.
That assembly is where agentic systems can help, and where they can fail.
For example, an Observation resource can carry a lab result or molecular finding, but the model must know whether the observation is current, whether it is relevant to the cancer in question, and whether it came from a reliable source (HL7 Observation). A ServiceRequest can represent an order or proposal for a service, but prior authorization may require diagnosis, prior therapy, and guideline rationale beyond the request itself (HL7 ServiceRequest).
The data spine is necessary. It is not sufficient.
What an oncology agent needs to see
A practical oncology agent should be built around a source hierarchy.
For diagnosis and pathology, pathology reports and structured cancer-condition elements carry more weight than a copied note problem list. For treatment history, medication administration and signed oncology notes matter more than a patient portal message. For molecular status, the signed molecular report matters more than a brief mention in a plan. For payer work, the exact payer criterion matters more than the practice's memory of prior approvals.
The agent should not flatten those sources into a single blob of text. It should preserve provenance.
The minimum useful record for many oncology workflows includes:
- Cancer diagnosis and relevant histology.
- Stage or disease state.
- Biomarker and molecular results, with report source and date.
- Prior therapies and current treatment intent.
- Key labs and organ-function constraints.
- Imaging and response context.
- Active orders or service requests.
- Payer rule or guideline source when administrative work is involved.
Where CMS policy matters
The CMS Interoperability and Prior Authorization Final Rule matters because it pushes payers toward API-based data exchange and more transparent prior authorization operations (CMS). That does not make prior authorization easy. It changes the technical assumptions.
If payers expose better APIs and providers maintain computable oncology records, an agent can prepare a cleaner request, match it to criteria, detect missing elements, and track status. If either side remains PDF-first and portal-fragmented, the agent spends most of its energy compensating for broken infrastructure.
This is the point missed in many AI demos. The model looks impressive when the context is handed to it. Real oncology systems have to find the context, verify it, and preserve where it came from.
A practical implementation pattern
The first version should not attempt a universal oncology brain. It should build a narrow data spine for a bounded workflow.
For prior authorization, start with diagnosis, stage, regimen, line of therapy, biomarkers, prior therapy, lab constraints, service request, payer criterion, and source links.
For molecular tumor board preparation, start with diagnosis, stage, genomic alteration, assay details, prior therapy, evidence links, trial candidates, and human-review status.
For survivorship planning, start with diagnosis, treatment exposures, surveillance context, toxicity risks, and patient-facing educational boundaries.
Each workflow gets its own source map, acceptance checks, and escalation rules. That is slower than a demo, but faster than rebuilding trust after a bad deployment.
The strategic conclusion
TEFCA and FHIR are not the product story most users will care about. They are still the product reality.
The agent that cannot see the longitudinal oncology record will hallucinate around the missing pieces. The agent that can see the record but cannot preserve provenance will be hard to trust. The agent that preserves provenance but lacks workflow boundaries will still be unsafe.
The winning stack is boring underneath and intelligent on top: TEFCA for exchange, FHIR for APIs, mCODE for oncology structure, source-grounded agents for bounded labor, and clinical validation as the floor.
Without that spine, "AI in oncology" is just a fluent interface pointed at incomplete plumbing.
Editorial boundary: This article is educational analysis for clinicians and health-IT leaders. It is not medical advice, does not recommend care for any individual patient, and uses no PHI.
Found this analysis useful?
Get the Weekly Signal — one email per week with the most important developments in oncology informatics and AI.