A chemotherapy plan can run for months, and the dose can change on any treatment day. A patient who has a hard week after one cycle may return with a lower dose, a delayed start, or a different supporting drug. The ASCO-ONS safety standards expect the care team to document a toxicity-related dose change and communicate it before the next dose.
That is why an oncology EHR is built around the regimen, not the visit, and two design rules make it work. The first is a gate: each safety check is a timestamped step that the next step depends on, so nobody can skip ahead. The second is a loop: every dose change returns to the plan with its reason. A record organized around single visits can store each change, but someone has to rebuild the thread by hand.
Short answer: an oncology EHR holds the treatment plan, records how each dose was calculated, confirms every safety check, and logs each change with its reason. Vendors would modernize oral and home therapy ordering and put standards-based APIs around the core data, so AI, decision support, and reporting can plug in.
What an oncology EHR has to remember between treatment days
The ASCO-ONS standards treat a regimen as one continuous plan. Before the first dose of a new regimen, they require nine documented elements, among them the diagnosis, drugs, doses, route, duration, and goals of therapy. The standards also expect standard regimens by diagnosis, with references, and standardized orders at the regimen level.
For a product team, that makes the plan the parent record. Orders, dose calculations, verifications, and changes all hang from it, so the next clinician sees the whole course in one view. The table shows how that differs from a record built around the visit.
| Design question | Built around the visit | Built around the regimen (Nalashaa’s view) |
|---|---|---|
| Where the plan lives | In a note from the first visit | As a parent record that every order and change references |
| What an order points to | The encounter | The regimen, the cycle and the treatment day |
| Where a dose change goes | A new order and a free-text note | A logged change linked to its cycle, with the reason |
| What the next clinician sees | The latest visit | The full course so far and what comes next |
A visit-based record fails quietly. Each encounter is complete on its own, so a dose change from cycle 2 sits in one note that the cycle 3 clinician has to find. Next, the checks that run between the order and the infusion.
How the checks run from order to infusion
Safety in oncology is a chain of checks, and each link needs a record the next link can read. The diagram below is Nalashaa’s view of that chain, from the plan through administration and back to the plan when a dose changes.
Read the top row left to right, then follow the bottom row back to the plan.
Each step in the chain maps to an expectation in the ASCO-ONS standards, and each would shape a data model:
- Dose calculation: The order documents the calculation method, the variables, how often weight and lab values get re-evaluated, and which changes force a recalculation. The standards also require metric height and weight, checked by two people, one of them a licensed clinician. The record would store the formula, the inputs, and both checkers, not only the final dose.
- Verification: For parenteral drugs, the standards require four separate verifications, and the documentation must confirm all four before administration, as the table below shows. The EHR would make each one a timestamped step that the next step depends on.
- Exceptions: A deviation from a standard regimen needs a documented rationale, plus a supporting reference or a second practitioner’s authorization before the order goes out. The record would ask for both at order entry and keep them with the order.
- Toxicity and dose changes: The record would store each change as an event on the regimen, with its cycle, its reason, and the toxicity that prompted it, and would show it on the next treatment day’s order.
The four verifications in standard 3.12 apply to parenteral drugs only. Oral drugs skip this gate but keep the plan and the dose calculation.
| Verification | When | Who | What the record would capture |
|---|---|---|---|
| 1 | Before drug preparation | Approved personnel | Two patient identifiers, drug, dose, route, rate, dose calculation and variables, treatment day and cycle |
| 2 | When the drug is prepared | A second licensed clinician approved to prepare antineoplastics | Vials, concentration, volume, diluent, route, filters and tubing |
| 3 | Before each administration | At least two licensed clinicians, working independently | Drug, dose, volume, rate, route, expiration, and the drug’s appearance and integrity |
| 4 | With the patient present | At least two licensed clinicians, one of them on site | Patient identity, drug, dose, rate, duration, route, administration set, and pump settings |
Illustration: a clinician lowers a drug dose after cycle 2 because of toxicity. In a regimen-based record, that single event updates the plan, flags the change on the cycle 3 order, and triggers a new dose calculation with the same method and variables. The new dose then passes through the four verifications before administration, and the cycle 3 clinician sees the reason without searching notes.
Where AI, data exchange and reporting plug into the record
Once the regimen record holds the plan, the dose history, and the change log, every other layer of an oncology product reads from it. The table shows what the EHR would expose to each layer.
| Layer | What the EHR would expose (Nalashaa’s view) |
|---|---|
| Authorization | Diagnosis, drugs, doses, and the regimen schedule |
| Claims | Verified doses, administered amounts, and the reason for each change |
| AI in the workflow | The plan, the dose record, and the change log as inputs |
| Agents | Defined steps and verification gates an agent can act within |
| Decision support and pathways | Standard regimens with references and versions |
| Data exchange | Plan, orders and changes through standards-based APIs, shaped by oncology data standards such as mCODE and USCDI+ Cancer |
| Analytics | Dose, cycle and change events with timestamps |
| Value-based reporting | The treatment course and its outcomes, tied to the regimen, including the data the Enhancing Oncology Model asks for |
| Care navigation | The treatment calendar and the steps ahead |
A vendor would design that record first, so every later layer has one place to connect. For the authorization layer, read prior authorization for oncology drugs. For claims, read AI in oncology medical billing. For care navigation, see the oncology patient navigation guide.
What the Latest update adds for oral, home, and social care
The ASCO-ONS standards were updated in May 2024, and the ONS summary of the update names additions that reach into product design:
- Oral and home therapy: The update extends safe administration to the home setting, and oral anticancer drugs must be ordered in the EHR or on preprinted forms, with quantity, refills, and schedule. The record would hold the oral order, the patient instructions, and the follow-up check inside the regimen, so every order type has an ordering path in the product.
- Social needs assessment: The update adds an initial and an ongoing assessment. The record would store each one as a dated entry that the care team can revisit during treatment.
The post on the HTI-5 paradox covers what the certification changes mean for vendors, while the safety standards stay the steadier target for product design.
Deciding whether to keep, wrap, or rebuild an existing product
Most vendors already ship a product, so the practical question is which parts to change. Nalashaa’s view is to sort each part into one of three paths, based on how it handles the regimen record.
| Path | Choose it when | What it looks like |
|---|---|---|
| Keep | The regimen is already the parent record, and orders, calculations, and changes link to it | Close gaps in place, such as oral therapy ordering |
| Wrap | The data is sound, but other systems cannot read it easily | Add an API layer so AI, decision support, and reporting connect without touching the core |
| Rebuild | Orders point to visits and dose changes live in free-text notes | Move the plan to the center, migrate the treatment history to it, and plan the cutover for patients who are mid-regimen |
The wrap path adds reach while the core stays untouched. In one case study, Nalashaa’s team added a plug-in API that returns FHIR, CCDA, and JSON to an oncology EHR, alongside a React and Redux interface update and Selenium test automation. The vendor reached certification, gained a better user experience, and shortened its release cycles.
For the engineering steps behind any of the three paths, see the guide on how to create EHR software.
Seven things to build or check in the next release
Use this list to scope the next release. Each item traces back to a section above.
- Regimen as the parent record: Every order, calculation, verification, and change would reference one regimen, cycle, and treatment day.
- A standard regimen library: Each regimen would carry its references, its version, and any exception reasons.
- A dose calculation record: Each dose would carry its method, its variables, metric height and weight, and both checkers.
- Verification gates with timestamps: Each of the four verifications would unlock the next step.
- A dose-change loop: Each change would return to the plan and show on the next treatment day.
- Oral and home therapy ordering: Oral orders and home instructions would live in the same regimen as the infusions.
- An API surface for the layers: The plan, the dose record, and the change log would reach each layer in the hub table through standards-based APIs.
How Nalashaa helps
Nalashaa’s product engineering team works with healthcare software vendors on the work this post describes: modernizing a specialty EHR, adding FHIR APIs around its core, and taking products through ONC certification. The oncology EHR case study above is one example. The team works with FHIR R4, HL7 v2, C-CDA, NCPDP, and X12, under a BAA and an ISO 27001:2022-certified process.
A first conversation gives you three things:
- A free feasibility review: A 45-minute call where we walk the seven-point checklist against your product and name a path for each part: keep, wrap, or rebuild.
- A written scope summary: You receive it within five business days of the call.
- A choice of engagement model: Options are fixed scope, dedicated team, staff augmentation, or outcome-based.
If you are building or modernizing a specialty EHR, see our product engineering services or connect to us at info@nalashaa.com.
FAQ
What is an oncology EHR?
An oncology EHR, also called an oncology EMR, is the record system that manages cancer treatment from the first plan to the last dose. It keeps the plan, the dose history, and every change with its reason in one place, so the care team sees the whole course across visits.
How is an oncology EHR different from a general EHR?
A general EHR organizes care around the visit. An oncology EHR adds the regimen as the parent record, so orders, dose calculations, verifications, and dose changes all link to a plan that runs for weeks or months.
What should an oncology EHR include?
At minimum, it would include a treatment plan, a standard regimen library, a dose calculation record, verification gates, a dose-change loop, oral and home therapy ordering, and APIs for AI, decision support, and reporting. The seven-point checklist above gives the details on each.
Latest posts by Priti Prabha (see all)
- AI EHR Integration for Oncology: What AI can Read and Write - October 23, 2026