Oncology Technology

What is oncology technology?

Oncology technology is the set of systems and data standards used to record, exchange and analyze cancer care: oncology EHR modules for treatment plans, the HL7 mCODE FHIR implementation guide for structured cancer data, NAACCR standards for registry reporting, patient-reported outcome tools and clinical trial matching services built on that data.

The difficulty is that one cancer case produces data for several audiences. The same diagnosis, stage and treatment feed the clinician's plan, the state registry, a payer program and a trial screen, and each one wants different fields on a different schedule.

Cancer data also changes over time in ways most clinical data does not. Stage is assigned at a point in time, treatment runs in cycles, and disease status is reassessed after each phase, so a product needs dates and history on every element, not only the latest value.

Which systems hold oncology data?

Oncology data sits in at least six kinds of system, and a product usually reads from two or three of them. Naming the source of truth for each element early avoids conflicting copies later.

• Oncology EHR module: Treatment plans, regimens, cycles, dose changes and staging, for example Epic Beacon in Epic.
• Pathology and lab systems: Diagnosis, histology, biomarkers and synoptic pathology reports.
• Genomics labs: Somatic and germline test results, delivered as reports and, from some labs, as structured data.
• Hospital cancer registry: Cases abstracted and coded by trained registrars and sent on to the state central registry.
• Patient-reported outcome tools: Symptom reports between visits, including instruments based on NCI's PRO-CTCAE.
• Trial systems: Study protocols, eligibility criteria and enrollment records, including public listings on ClinicalTrials.gov.

Genomic results deserve their own intake decision. A report that arrives only as a document cannot drive trial screening or analytics until someone, or a reviewed extraction step, turns its key findings into coded data.

Patient-reported outcomes need a response path as well as a form. A symptom score collected between cycles helps only if someone on the care team sees it in time, so ePRO tools are built with routing and escalation rules agreed with clinicians.

How does mCODE structure cancer data?

mCODE, the minimal Common Oncology Data Elements, is an HL7 FHIR implementation guide that assembles a core set of structured oncology data elements as FHIR profiles. Version 4.0.0 (STU4) is based on FHIR 4.0.1 and contains about 40 profiles, grouped into six areas.

• Patient: The person with cancer and the characteristics that affect treatment.
• Disease: Primary and secondary cancer conditions, histology, staging and tumor markers.
• Assessment: Health assessments such as performance status and comorbidities.
• Genomics: Genomic variants and test results relevant to the cancer.
• Treatment: Cancer-related surgery, radiotherapy and medications.
• Outcome: Disease status over time and measurements such as tumor size.

mCODE does not require every patient record to carry a fixed set of data. It defines how to represent each concept when it is recorded, and the guide states that it adds no requirements beyond base FHIR and US Core. The CodeX FHIR Accelerator is the member-driven community that runs implementation work around it.

For a product team, mCODE works best as the canonical shape inside the product. Each source system is mapped into it once, original source codes are kept beside the mapped ones, and analytics, trial screening and registry extracts all read the same structure.

How does cancer registry reporting work?

Cancer registry reporting moves case data from hospitals, physician offices and pathology labs to a state central cancer registry. Each year the central registries submit de-identified incidence data to CDC's National Program of Cancer Registries or NCI's SEER program.

• NPCR origin: Congress created the National Program of Cancer Registries in 1992 through the Cancer Registries Amendment Act, which lets CDC fund and assist statewide, population-based registries.
• Coverage: According to CDC, NPCR supports central registries in 46 states, the District of Columbia, Puerto Rico, the U.S. Affiliated Pacific Islands and the U.S. Virgin Islands, about 97% of the U.S. population; SEER supports the other four states.
• Pathology messages: NAACCR's Laboratory Electronic Pathology Reporting guidelines specify HL7 version 2.5.1 ORU^R01 messages for pathology reports sent to central registries.
• Data dictionary: NAACCR also maintains the data item definitions and record layout that registries exchange, which a registry extract has to follow.

Most registry data still comes from hospitals, where registrars read the record and code site, histology, stage and first course of treatment. Software can shorten that work by pre-filling fields from structured EHR and pathology data, while the registrar keeps the final coding decision.

For a lab or a product that sends pathology results, the build is an HL7 v2 interface: ORU^R01 messages to the NAACCR specification, sent to each state registry and taken through that registry's onboarding and test process.

Where do oncology EHR modules fit?

Oncology EHR modules hold the treatment plan, which is the center of oncology data: regimens laid out in cycles and days, dose changes tied to lab results, and staging. Outside software reaches that data through the EHR's FHIR APIs and HL7 v2 interfaces rather than through the module itself.

The standardized FHIR API that certified EHRs offer carries US Core data such as conditions, medications, lab results and procedures. US Core does not define an oncology regimen model, so plan and cycle detail depends on each EHR vendor's own APIs and interfaces. Check them before promising regimen-level features.

Writing back to the plan needs more care than reading it. A product that suggests a change to a regimen should send it for clinician review inside the EHR, where the oncology team and pharmacy verify orders, rather than writing orders directly.

Payer programs add their own reasons to integrate. Value-based oncology programs can ask practices to collect patient-reported outcomes and report quality data, so an ePRO tool that writes its results back into the EHR saves staff from keying them twice.

How does clinical trial matching use oncology data?

Clinical trial matching compares a patient's diagnosis, stage, biomarkers and treatment history against each study's eligibility criteria. The patient side can be structured with mCODE; the trial side is harder, because eligibility criteria are published mostly as text.

The National Library of Medicine released ClinicalTrials.gov API version 2.0 in 2024. It is a REST API described with the OpenAPI Specification 3.0 and returns JSON, and its EligibilityCriteria field is markup text, so a matching service has to turn criteria into structured rules before comparing them with patient data.

• 1. Normalize the patient: Map diagnosis, stage, biomarkers, prior lines of therapy and performance status to mCODE profiles.
• 2. Structure the criteria: Parse inclusion and exclusion text into coded rules, with a person reviewing the parse for each study.
• 3. Filter: Apply hard rules first, such as cancer type, stage and site location.
• 4. Rank and explain: Show the clinician which criteria matched, which failed and which data was missing.
• 5. Refresh: Recheck after new labs, imaging or a change in treatment, since eligibility shifts over the course of care.

Site fit matters as much as clinical fit. A study that is recruiting only at distant locations may not be a practical option, so the location filter should use each study's listed sites and their recruitment status.

Privacy rules change when data leaves the provider. Disclosing PHI to a trial sponsor requires either the patient's written authorization or a waiver granted by an IRB or privacy board, and once the sponsor holds the data it is generally outside HIPAA, so consent terms and data agreements carry the protection.

Oncology data decisions to settle before building

These seven choices fix the shape of an oncology data model, and reversing one after launch tends to need a data migration. Give each an owner and a written answer before build starts.

• Source of truth: Which system owns stage, biomarkers, regimen and outcomes, and how conflicts between them are resolved.
• Internal model: mCODE profiles as the canonical shape, with original codes kept beside mapped ones.
• Staging system and edition: Record which staging system and edition produced each stage value, since values from different editions are not directly comparable.
• Genomics intake: Structured feeds where labs offer them, and a reviewed extraction step for results that arrive only as reports.
• Registry scope: Which state registries receive reports, in which message format, and who handles each registry's onboarding.
• PRO design: Which instruments, how often, and which symptom scores prompt a call from the care team, with thresholds set by clinicians.
• Research use: Which data may feed trial matching and research, and under which HIPAA pathway it leaves the provider.

How Agnotic can help

Oncology products succeed when their data model handles cycles, stage history and several downstream audiences from the start. Agnotic Technologies builds oncology platforms and integrations for digital health companies and cancer programs: mCODE-based data models, EHR integration through FHIR and HL7 v2, symptom and ePRO tracking, and registry and trial screening feeds.

Agnotic works from the client's source-of-truth map and decision list, builds the mappings and interfaces against them, and tests with synthetic patients whose treatment runs through delays, dose changes and restaging.

Sources

• HL7: mCODE (minimal Common Oncology Data Elements) Implementation Guide
• CDC: About the National Program of Cancer Registries
• NAACCR: Laboratory Electronic Pathology Reporting guidelines
• NLM: ClinicalTrials.gov API version 2.0