EHR Software Development Problems: The 7 That Cost Clinics Real Money, and How to Avoid Them

Why does replacing the whole system at once go wrong so often?

The instinct is understandable. If the electronic health record system, or EHR, is the problem, replace the EHR. So the project is scoped as clinical, scheduling, billing, portal and interfaces, all cut over together, and it becomes the largest thing the practice has ever attempted while the practice continues seeing patients every day.

What goes wrong is not usually the engineering. It is that a single cutover puts clinical trust and revenue collection at risk in the same week. If charting is unfamiliar and claims are also flowing through new rails, every problem is ambiguous: nobody can say whether the denial is a coding issue, an interface issue or a training issue, and the practice loses confidence in the whole project rather than in one component.

The pattern that works is to build the layer where you are differentiated and leave the rest alone until it has earned trust. That usually means specialty charting, group wide scheduling and the analytics layer first, reading from the incumbent through its interface during transition, with proven billing rails untouched. Replace the core last, location by location.

Two rules make this survivable. Never put clinical go live and billing cutover in the same phase. And run each location in parallel for a defined period with a written fallback, including who decides to invoke it. A developer who has never rolled a clinic back has never really cut one over, and the plan they hand you will read like a schedule rather than a risk document.

What goes wrong when you migrate years of clinical data?

Migration in this category is where optimistic timelines die, and the reason is that the interesting data is the least structured. Problems, medications, allergies and results can be exported and mapped. What cannot be mapped cleanly is everything that was recorded as free text because the incumbent had nowhere else to put it, which in a specialty practice is often the clinically important part.

Three traps recur. The first is medication lists with reconciliation history: knowing what a patient takes now is straightforward, and knowing what was stopped, when and by whom is what a clinician actually wants at the next visit. The second is results that arrived as faxed documents and were never discretised, so an imaging result exists as an image of text and is unsearchable in the new system unless somebody plans for that. The third is duplicate patient records, which every practice has and which merging is a clinical safety decision rather than a deduplication script.

The workable approach is a split with a stated line. Migrate discrete data for active patients, meaning problems, medications with their history, allergies, immunisations and results your clinicians will act on. Archive everything else as searchable documents attached to the patient, retrievable without being pretended into structure. Then verify by sampling: have treating clinicians confirm a set of complex active charts is safe to work from before their location goes live. A quote that treats migration as a data load has not looked at your archive.

Why do lab, e-prescribing and clearinghouse interfaces break after launch?

Interfaces are the most common source of post launch incidents, and they rarely fail loudly. A laboratory results feed keeps delivering, then a compendium update renames a test code and results start filing as unmatched, sitting in a queue nobody watches. A clearinghouse changes a validation and a claim category starts rejecting, which looks like a billing problem for three weeks until someone traces it. An e-prescribing directory entry changes and prescriptions to one pharmacy chain stop routing.

The pattern is that interfaces degrade partially, and partial degradation is invisible unless you are looking for absence. A results feed that stops entirely triggers a call from the lab. A results feed that silently misfiles four percent of results does not, and those four percent are somebody's biopsy.

The fixes are operational as much as technical. Monitor expected volume per interface per day and alert on a drop rather than only on errors, because silence is the dangerous state. Give every unmatched or failed message a queue with a named owner and a daily review, and make that queue visible to a clinical lead rather than only to technical staff. Version your code mappings and treat compendium and directory updates as change requests with a person accountable, not as vendor housekeeping.

And ask any prospective developer which specific interfaces they have built and to what, because named experience with laboratory results feeds, a certified e-prescribing partner and real claim and remittance transactions is evidence and an architecture diagram is not.

What happens when compliance and audit design are left until later?

Compliance treated as a checklist at the end produces a system that has to be partially rebuilt, because the requirements are architectural. Access control granular enough to be defensible, audit logging that records who viewed which record and when in a form that survives scrutiny, encryption in transit and at rest, and a signed business associate agreement with every party touching patient data are all design decisions that shape the data model.

Two specific items get discovered late and hurt. Electronic prescribing of controlled substances carries identity proofing and audit requirements that are materially more demanding than ordinary prescribing, and adding it after the fact means revisiting authentication for the whole system. And certification scope: if your providers report under programmes that require a certified EHR, you need a clear decision early about whether you keep a certified module alongside the custom build or pursue certification, because retrofitting that decision is expensive and the answer depends on your payer mix rather than on your preference.

The fix is to make compliance part of discovery. The developer should sign a business associate agreement before discovery begins, walk you through audit logging and access design unprompted, and give you a straight answer about certification rather than deferring it. Insist that no real patient data is ever used in a development or test environment, which means someone has to produce realistic synthetic data, a task people consistently forget to price.

Should you build custom or configure what you already own?

Plenty of groups should not build. Under roughly ten providers, the percentage of collections bill is irritating rather than structural, and a custom project would consume management attention you cannot spare. If your specialty is well served by a strong niche system, buy it. If you need certified quality reporting next quarter, this is not the quarter to start a build.

Before commissioning anything, be honest about whether your complaint is the product or its configuration. A great deal of charting friction in athenahealth is encounter plans that were set up during implementation and never revisited as the practice changed, and a competent configuration pass with your highest volume physicians in the room resolves more of it than most groups expect. Similarly, if your frustration is reporting, ask what your existing system can actually export before concluding it cannot.

If you are on Epic through a host organisation, the honest constraint is queue position rather than capability, and that is worth testing directly. Ask what a specific template change would take. Sometimes the answer is reasonable and the problem is that nobody has asked properly.

Build when the changes you need are structural rather than cosmetic. Your specialty's core objects, such as a lesion pinned to a body map with a biopsy lifecycle, or an operative episode linking injury, imaging, procedure, implants and post operative milestones, do not exist in the vendor's schema and never will. You employ people whose actual job is working around the software. Your annual spend climbs with revenue rather than usage. Any two of those and the arithmetic usually closes on its own.

How do hidden costs get into the quote?

The first is interface count, which is the dominant driver and is frequently quoted as one line called integrations. Each laboratory feed, each e-prescribing connection, each clearinghouse transaction set and each device is separate work with separate ongoing maintenance. Ask for them itemised and named.

The second is migration depth, measured in years of discrete data rather than volume of documents. Two years of structured problems and medications is a different project from a decade including scanned archives, and the difference is not linear.

The third is controlled substance prescribing, with its identity proofing and audit obligations, which is regularly assumed to be included in e-prescribing and is not.

The fourth is multi state telehealth, where consent requirements and licensing conditions vary and each variation is logic somebody has to build and maintain.

The fifth is the parallel run. Running two systems per location for a defined period costs staff time, doubles some data entry temporarily, and requires supervision. It is the single most important risk control in the project and it is the line most often missing from an estimate, usually because including it makes the proposal look slower than a competitor who omitted it.

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

The data model speaks the domain. If the team cannot sketch on a whiteboard how they would model a medication list with reconciliation history, and if standard clinical resource names are not their natural vocabulary, they will invent a schema you will regret inside a year.

The chart closes before the physician leaves the room. That is the design target worth holding everyone to, and it is measurable. Track time from encounter start to note signed, per physician, before and after, and treat a regression as a defect rather than a training issue. Groups that measure this get systems clinicians defend. Groups that measure feature delivery get systems clinicians tolerate.

Operational data lands in your own analytics store as it happens, so the administrator can answer schedule utilisation, no show rate by location and hour, days in accounts receivable by payer and referral conversion without filing a request. When a new question requires a support ticket, the practice stops asking new questions, which is a slower and more expensive failure than any interface outage.

And ownership is unambiguous and written down before kickoff: full assignment of the code on payment, the repository and cloud accounts in your name, and documentation another team could pick up. Anyone proposing a licence to their own platform is recreating the vendor lock in you are trying to escape, with less scale behind it.