Oncology Practice Software: Fixing the Regimen, Authorization and Drug Inventory Gap

Why regimen, authorization and inventory software makes or breaks an oncology group

Oncology is the only outpatient specialty where a single administration decision can put $18,000 of drug into a patient's arm before anyone has confirmed the payer will cover it. That asymmetry is what your software either protects you from or exposes you to. Most groups we work with run some combination of Flatiron OncoEMR, McKesson iKnowMed or Epic Beacon for the regimen side, a separate portal per payer for authorizations (Availity, Evicore, Carelon, CoverMyMeds, plus the direct payer portals nobody has automated), McKesson or Cardinal for wholesale ordering, and then a spreadsheet nobody admits to for the part where those three have to agree.

We watched this play out at a five-site group in the Southeast. Tuesday, 7:40am. The infusion nurse pulls a patient for cycle 3 of pembrolizumab plus carboplatin plus pemetrexed. The auth on file covers six cycles, approved in March, expiring at the end of this month. Nobody flagged it because the expiration lives in a PDF attached to the chart, and the schedule was built in the practice management system, which has never read that PDF. The vial gets pulled, reconstituted, and hung. Twelve days later the denial comes back: auth lapsed on day 4 of the cycle window. That is $11,400 the group eats, plus the 90 minutes the auth coordinator spends on a peer-to-peer that will not succeed because the drug is already in the patient.

In the reconciliations we run at the front of these projects, the leak shows up in three buckets every time. Authorizations that expire or that never covered the actual dose administered. Vials wasted because the schedule and the compounding queue were never reconciled, so a single-dose vial of an expensive biologic gets opened for a patient who no-showed. And J-code billing that undercounts units because the waste documentation on the JW modifier was never captured at the pump. None of these are exotic. They are all the same root cause: the regimen, the authorization, and the physical vial are three separate records that only a human ties together, and the human is a 26-year-old auth coordinator with 40 charts in her queue.

Problem 1: Authorizations are tracked as documents, not as living entitlements

Your auth coordinator submits through Availity, gets a PDF back, uploads it to the chart, and types the auth number into a text field. From that moment forward, the authorization is a dead artifact. It does not know how many cycles have been consumed. It does not know that the oncologist dose-reduced from 200mg to 150mg at cycle 2, which may or may not be within the approved band. It does not know it expires in 11 days.

OncoEMR and Beacon will store the auth. They will not model it. The reason is structural: an authorization is a payer-specific entitlement with a drug, a dose range, a cycle count, a date window, a site of care, and sometimes a step-therapy precondition. That is a six-dimension object. The EHR gives you a string field. Every workaround built on top of that string, the Excel tracker with conditional formatting, the shared Outlook calendar with reminders, the Monday-morning huddle where someone reads out expiring auths, is a person doing a database's job.

What a custom build does: model the authorization as a first-class record with structured fields, then bind it to the treatment plan. Auth has drug (by HCPCS J-code, not free text), approved dose range, cycles approved, cycles consumed, valid-from and valid-through, site of care, and payer. Every scheduled administration checks against it at three points: when the appointment is booked, at 72 hours out, and at the moment pharmacy releases the order for compounding. If cycle 3 falls outside the window, the appointment cannot be confirmed without an override that names the person overriding. If the oncologist dose-reduces, the system recomputes whether the new dose sits inside the approved band and, if not, opens a reauth task automatically with the dose delta pre-filled.

The AI piece here is narrow: document extraction. Payer approval letters arrive as PDFs and faxes in about 30 different layouts. A model reads the letter, pulls out auth number, drug, units approved, date span, and cycle count, and populates the structured record with a confidence score. Anything under threshold routes to a human for 15 seconds of confirmation instead of 4 minutes of retyping. At 300 auths a month, that gives you back roughly 15 to 20 hours in our experience, and it kills the transcription errors that cause denials nobody can appeal.

Problem 2: Drug inventory and the treatment schedule live in different universes

You order from McKesson against a par level. You schedule patients in the practice management system. The connection between those two is a pharmacy tech's judgment. When it works, it works because that tech has been there nine years and knows Tuesday is heavy.

The failure is expensive and specific. A single-dose vial of a checkpoint inhibitor gets opened for a 9am patient who called in sick at 8:52. That vial is now scrap. Or the reverse: a patient shows and you are short, so somebody drives product from the Marietta site to the Alpharetta site, which is a controlled-substance-adjacent transfer nobody documented properly and which now breaks your lot traceability. And under buy-and-bill, you are financing this inventory. A group carrying $600k of drug on the shelf at any moment is carrying real cost of capital, and most groups carry more than they need because nobody has the confidence to run leaner.

Off-the-shelf inventory tools do not fix this because they are built for consumables, not for a $9,000 vial whose value is tied to a specific patient on a specific day with a specific authorization. Cardinal and McKesson portals show you what you bought. They do not know your schedule.

What a custom build does: a demand forecast keyed to the confirmed schedule, not to historical par. The system reads the next 14 days of confirmed appointments, resolves each to a regimen, resolves each regimen to drugs and doses by patient BSA and current dose modifications, and produces a required-units projection by NDC. That projection nets against on-hand lots with expiry dates, and it flags two things: shortfalls that need an order today given the wholesaler lead time, and lots that will expire before the schedule consumes them, so you can either sequence a patient onto that lot or return it while the window is still open.

Lot-level tracking is the other half. Every vial gets scanned at receipt, at compounding, and at administration, so the lot on the pump is the lot in the chart. This matters for recalls, it matters for 340B if you are covered-entity adjacent, and it matters for the waste documentation that drives your JW and JZ modifier accuracy. The forecasting model does one useful thing: it learns your real no-show pattern per site, per day, per payer class, so the 14-day projection knows the Thursday clinic at your second site and does not tell you to open vials against it.

Problem 3: Regimen changes do not propagate to anything downstream

An oncologist decides on Monday to hold the carboplatin for cycle 4 because platelets are at 68. In the EHR she updates the plan. That change now needs to reach: the schedule (the infusion is shorter, the chair time changes), pharmacy (do not compound the carbo), the auth record (did the approval cover the doublet as a unit or as separate line items), inventory (that vial goes back to available), and billing (the claim drops one J-code and the units on another).

In practice it reaches the nurse, verbally, and everything else catches up over the next four days or does not catch up at all. Beacon handles the clinical side of this reasonably. It does not handle the operational and financial side, because those systems are downstream of a different vendor.

What a custom build does: treat the treatment plan as the single source of truth and make every downstream system a subscriber. When a dose is held or reduced, the event fires and each subscriber reacts on the same transaction: chair time recomputes and releases the freed slot back to scheduling, the compounding queue drops the item before the tech touches it, the auth checker re-evaluates coverage, the inventory reservation releases, and the charge capture draft updates. That is an event model with a durable log, so you can answer "who changed what and when" during an audit. The part that takes real domain work is the regimen library itself: encoding NCCN-aligned regimens with their dose-modification rules, their cycle structures, their premedication and growth-factor dependencies, and their site-specific variations. That library is the asset, and it is what separates a shop that has built oncology software from one learning on your budget.

Problem 4: Nobody can see margin per regimen until the quarter closes

Ask a practice administrator what the contribution margin is on their most-used first-line lung regimen, right now, at the second site, under their largest commercial payer. They will get you an answer in three weeks with help from the billing company. Under buy-and-bill, where you purchase the drug and bill the payer, the spread between acquisition cost and allowed amount is the business. ASP changes quarterly. Your contracted rates change annually and unevenly by payer. Your acquisition cost changes with your wholesaler tier and any GPO participation.

Generic BI (Business Intelligence) on top of the practice management system gives you charges and collections. It does not give you the drug cost against the specific lot administered, and it does not tie the denial back to the regimen decision that caused it.

What a custom build does: compute margin at the administration level, not the claim level. Each administration carries its actual acquisition cost from the lot, its expected allowed amount from the contracted rate table for that payer and J-code, its actual paid amount when the remit lands, and the variance. Roll that up by regimen, by payer, by site, by ordering physician. Now the conversation with your largest commercial payer at contract renewal is not "our costs are up," it is "on these four J-codes your allowed sits below our acquisition plus handling, here is 14 months of administration-level data." That conversation is worth more than the software costs.

Problem 5: The after-hours and between-visit gap

A patient on day 6 of a cycle calls at 8pm with a fever of 100.9. That is a neutropenic fever question and it is time-critical. Your answering service takes a message. The on-call gets it 40 minutes later without the chart, without knowing the regimen, without knowing the nadir window. Separately, your symptom monitoring program, the one that reduces ED visits, exists as a nurse calling patients from a paper list when she has time.

What a custom build does: structured between-visit capture tied to the treatment calendar. The patient gets a simple check-in on the days that matter for their specific regimen, because the system knows the nadir window for their protocol. Responses are triaged by rule first: temp over 100.4 on a myelosuppressive regimen inside the nadir window pages the on-call with the regimen, the cycle day, the last CBC, and the protocol on the same screen. A model helps at the intake edge, taking a free-text or voice symptom report and mapping it to structured CTCAE-style grading with a confidence score, so the triage nurse reads a graded summary instead of a paragraph. It does not make the clinical call. It makes the clinical call arrive with context.

What this costs and how long it takes

These are Digital Heroes delivery bands from across 2,000-plus projects, not market averages. A focused first release runs $60k to $130k and ships in 12 to 16 weeks. In this category the right first release is almost always the authorization workspace plus drug inventory with lot tracking, reading your existing EHR rather than replacing it. That scope pays for itself fastest and it does not require you to touch clinical documentation, which is where projects go to die. A full platform, regimen orchestration, scheduling integration, margin analytics, patient monitoring, runs $150k to $400k phased over 6 to 12 months.

What drives price up specifically here: the number of payer portals you need to submit into and how many of them lack an API, so somebody is writing and maintaining automation against a portal that redesigns twice a year. Every payer beyond the first three adds real cost. HL7 v2 or FHIR integration depth with your EHR, reading is cheap, writing back into Beacon is not. The size of your regimen library and whether you accept a standard set or need your physicians' local variants encoded. HIPAA posture, which at minimum means a BAA, audit logging on every PHI read, encryption at rest and in transit, and role-based access that a compliance officer can actually test. If you are 340B, add contract pharmacy reconciliation, which is its own project. And multi-site adds less than people fear, maybe 10 percent, unless your sites have genuinely different payer mixes and formularies, in which case it is more.

Build or buy: the honest line

Stay with off-the-shelf if you are a single site with under six chairs, one dominant payer, and a stable regimen mix. Flatiron, iKnowMed and Beacon are good products. The auth burden at that scale is one coordinator's job and she can hold it in her head. Spending $90k to systematize a problem that costs you $40k a year is a bad trade, and we will tell you that on the call.

Build when you cross these lines. You have more than two sites and drug transfers between them are routine and undocumented. Your denial rate on drug claims is above 6 percent and your billing company cannot tell you why by regimen. You are carrying more than $400k of inventory and cannot say what fraction of it is aging out. You have added a payer or a service line and the auth queue did not scale, so you hired a second coordinator instead of fixing the system. Or the tell that matters most: someone in your organization maintains a spreadsheet that the practice would stop functioning without. That spreadsheet is your spec. It exists because your software cannot hold the shape of your business, and it will keep existing until something else holds that shape.

How to choose a developer for oncology practice software

Make them draw the data model before they quote. Ask how they would represent an authorization, a regimen, and a lot. If the auth is a field on the patient rather than an entity with a dose range and a cycle counter, they have not built this. If they cannot explain why a regimen is more than a list of drugs, walk. This takes 20 minutes and it separates the field.

Ask what they have actually integrated, by name and by direction. "We do healthcare integrations" is not an answer. The answer is "we have read from OncoEMR via their export, we have written orders into Beacon via HL7 v2 ORM, we have pulled 271 eligibility, and here is what broke." Reading is easy. Writing back is where the scars are. Ask about the scars.

Test their compliance answer for depth, not for vocabulary. Anyone will say HIPAA. Ask who signs the BAA, where PHI sits at rest, whether audit logs capture reads and not just writes, how they handle PHI in their own dev and staging environments, and what happens to your data if the engagement ends. A team that has shipped in this space answers these flatly. A team that has not gets vague around dev environments, which is exactly where PHI leaks.

Settle code ownership and the payer-portal maintenance question in writing, before kickoff. You should own the source outright, in your repository, with your infrastructure accounts. Separately: portal automations break when payers redesign. Ask who fixes that, on what SLA, and what it costs after the initial build. A shop that has not thought about this has not run one of these in production for a year.