Oncology Practice Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does an oncology software project turn into an electronic health record replacement?

The scope starts narrow and defensible: fix authorizations and drug inventory. Then somebody observes that the treatment plan lives in the electronic health record, so the new system needs to read it, and reading turns into writing, and writing turns into a conversation about whether the physicians would prefer to order in the new interface. Now you are replacing clinical documentation, which is a multi year project with a high failure rate that solves a problem you did not have.

It happens because the treatment plan is the true centre of the operation, so anything touching operations eventually reaches for it.

The fix is a rule stated before scoping begins: the electronic health record keeps clinical documentation and regimen ordering, full stop. The build reads from it and owns authorizations, inventory with lot traceability, and administration level margin. That scope is the $60k to $130k, 12 to 16 week first release, and it stays in that band because it never touches the system physicians already know. Projects that respect the line ship. Projects that cross it become the story everyone in the group tells for years.

What goes wrong migrating the authorization tracker and the regimen library?

Your authorization spreadsheet is the best specification you have, and migrating it is how you find out what your team has been resolving by memory. Does a cycle count mean administrations or calendar cycles. Does the date range mean the approval window or the treatment window. When the dose was reduced at cycle 2, was the approval band re-checked or assumed. Different coordinators answered those differently, so the same column holds several meanings.

The regimen library is harder. Encoding regimens with their dose modification rules, cycle structures, premedication and growth factor dependencies is real domain work, and every group has local variants their physicians expect. A team that has not built oncology software before will learn this on your budget and your timeline.

The fix is to plan two to three weeks for mapping and cleanup on a mature tracker, and to expect records that cannot be reconciled. That list is useful rather than embarrassing, because it shows exactly where the process leaks. On regimens, decide early whether you accept a standard set or need your physicians' variants encoded, because that decision is the difference between a library that gets used and one the clinical team routes around.

Why do the payer portal and electronic health record integrations break after launch?

Payer portals break because they are not interfaces, they are websites that get redesigned on someone else's schedule. Automation written against a portal in March may need attention in September, and nobody warns you. The failure is silent: submissions stop landing, the queue looks quiet, and a coordinator assumes it was a slow week.

The record integration breaks in the other direction. Reading is cheap and stable. Writing back is where the scars are, and the specific failure is a mismatch between what the clinical system thinks an order is and what the operational system assumed, so a held dose updates in one place and not the other.

The fixes: agree before signing who maintains portal automations after launch, on what response time, and at what ongoing cost, because a shop that has not thought about this has not run one of these in production for a year. Build a heartbeat into every automation so absence of activity raises an alert rather than reading as calm. And prefer reading plus explicit user confirmation over silent write back until the mapping has proved itself across a full quarter.

What happens when lot traceability and waste documentation are not covered?

Two costs sit here and both are quiet. The first is single dose vials opened against patients who do not arrive. Without a demand projection tied to confirmed appointments and your real no show pattern by site and day, compounding decisions are made on judgement, and an expensive biologic opened at 8.55 for a patient who called at 8.52 is scrap.

The second is billing units. If waste is not captured at the point it happens, modifier documentation is reconstructed later or omitted, and units get undercounted on claims you were entitled to. That is not aggressive billing, it is being paid accurately for drug you purchased and administered.

The third, if you transfer product between sites, is traceability. An undocumented drive from one location to another breaks the chain between lot and chart, which matters for recalls and matters more if you have any 340B exposure.

The fix is scanning at three points, receipt, compounding and administration, so the lot on the pump is the lot in the chart, with waste recorded by reason at the moment it occurs. Then run the fourteen day demand projection against confirmed appointments resolved to regimens and doses, and let it flag both shortfalls against wholesaler lead time and lots that will expire before the schedule consumes them.

Should you build custom or configure what you already own?

Plenty of practices should not build. A single site with under six chairs, one dominant payer and a stable regimen mix has an authorization burden that fits inside one coordinator's head, and spending $90k to systematise a problem costing you far less is a bad trade. We say that on calls that end without a project.

Before commissioning anything, exhaust what Flatiron OncoEMR, iKnowMed or Epic Beacon already offer. These are good products and most groups have not fully configured regimen templates, order sets and the reporting their vendor provides, because nobody had two uninterrupted weeks to do it. Whatever remains impossible after that exercise is your genuine specification, and it will be shorter and sharper than the wish list you started with.

Build when the lines are crossed together: more than two sites with routine undocumented transfers, a drug denial rate your billing company cannot break down by regimen, inventory you cannot age, and a second coordinator hired instead of fixing the queue. The clearest tell is a spreadsheet the practice would stop functioning without. It exists because the software cannot hold the shape of your business, and it will keep existing until something else does.

How do hidden costs get into the quote?

Payer portals are the largest and most underestimated. The first two or three are manageable; every additional payer without an application programming interface adds engineering plus permanent maintenance, and that maintenance is an ongoing operating cost rather than a build line.

Compliance posture is second. A business associate agreement is the floor. Real cost sits in audit logging that captures reads and not only writes, role based access a compliance officer can independently test, and a defensible policy for protected health information in development and staging environments, which is where leaks actually happen. Teams that treat these as change orders in month four are telling you what month four looks like.

Third is integration depth. Reading from your record system is inexpensive; writing orders back is materially more work and carries clinical risk, so it deserves its own estimate rather than being folded into a line called integration.

Fourth, if you are 340B, contract pharmacy reconciliation is its own project and should be quoted separately. Fifth, multi site adds less than people fear, perhaps a tenth, unless your locations have genuinely different payer mixes and formularies, in which case it adds considerably more.

What separates a build that works from one that fails here?

The data model, tested before anyone quotes. Ask a developer to represent an authorization, a regimen and a lot. If the authorization is a field on the patient rather than an entity with a drug identified by code, an approved dose range, a cycle counter and a date window, they have not built this. If they cannot explain why a regimen is more than a list of drugs, keep looking. Twenty minutes of that conversation separates the field.

Second, checks at three points rather than one: at booking, at seventy two hours out, and at the moment pharmacy releases for compounding. A single check at scheduling misses everything that changes in between, and what changes in between is what costs you.

Third, an event model with a durable log, so a held dose propagates to chair time, the compounding queue, the authorization check, the inventory reservation and the charge draft on the same transaction, and so an auditor can be told who changed what and when.

Fourth, ownership in writing before kickoff. Source in your repository, deploying to cloud accounts you own, transferring fully with no license back or runtime dependency on the vendor. Settle the portal maintenance question in the same document, because that is the obligation that outlives the build.