VA’s Oracle Cerner EHR: Patient-Safety Incidents in a Troubled Modernization
VA's Oracle Cerner EHR modernization turned technical defects, hidden queues, outages, training gaps, and weak problem resolution into documented patient-safety risks.
VA chose a shared commercial EHR to modernize one of America’s largest health systems
In 2018, the Department of Veterans Affairs awarded Cerner, now Oracle Health, a ten-year contract to replace VA’s aging VistA environment with the same commercial EHR family used by the Department of Defense. The strategic goal was interoperability and a common longitudinal record. But deploying a new EHR across VA meant replacing workflows, interfaces, training, support processes, and safety mechanisms in a system serving millions of veterans. The VA Office of Inspector General later documented hundreds of major performance incidents at the first deployed medical centers.[1]
A national EHR rollout creates a national failure surface
Problems discovered at the first sites are not local curiosities; they are evidence about risks that could be replicated across every future deployment.
The unknown queue became one of the clearest patient-safety defects
The new EHR could route orders for care into an “unknown queue” rather than to the intended destination. VA OIG found that thousands of orders entered this undetectable location and that clinical review identified 149 patient-harm events related to the issue.[2] The defect was especially dangerous because an order could appear to have been placed while the receiving team never saw it. This is a classic distributed-workflow failure: the sending component completes locally, but end-to-end delivery has not actually succeeded.
System support processes often failed to close the loop on reported defects
At the Mann-Grandstaff VA Medical Center, users filed more than 38,700 tickets in the first months after go-live. OIG found problems with replication, tracking, closure, communication, and workarounds; some tickets were closed without documented resolution.[3] A help desk is part of the safety architecture during a major rollout. If recurring defects disappear into ticket queues, frontline users learn to build unofficial workarounds, and central teams lose the evidence needed to identify systemic hazards.
Unresolved tickets become shadow requirements
Every workaround encodes a need the official system does not yet meet, but workarounds are rarely tested, documented, or visible to programme leadership.
Interoperability remained incomplete despite being a central rationale for the project
A joint VA and Defense Department audit found that the organizations had not consistently migrated all necessary legacy information, built all needed medical-device interfaces, or fully controlled user access roles.[4] Interoperability is not achieved merely by buying the same vendor platform. It requires data definitions, migration, interface engineering, identity, authorization, and operational governance to align across institutions.
Scheduling defects showed how EHR limitations translate into delayed care
VA OIG found significant limitations in the new patient scheduling system at early deployment sites. Staff created workarounds, ticket management was ineffective, and unresolved issues increased the risk of care delays.[5] Scheduling is easy to dismiss as administrative software, but in healthcare it determines whether a patient reaches a clinician at all. A usability or state-management problem can therefore become a clinical access problem.
Administrative software can be safety-critical through workflow dependence
A defect does not need to calculate a dose incorrectly to harm a patient; it can simply keep the patient from reaching the person who would provide treatment.
Major performance incidents exposed weak change and downtime controls
OIG later concluded that VA and Oracle Health lacked adequate controls to prevent changes from triggering major incidents, respond consistently, and mitigate effects with standardized downtime procedures.[1] This is a reliability-engineering problem as much as a procurement problem. Healthcare systems need predictable change management, rollback capability, incident classification, and rehearsed degraded-mode operations because clinicians cannot stop working when the EHR does.
The programme demonstrates why safety evidence must drive rollout speed
Large government programmes face pressure to maintain schedules and avoid stranded investment. Yet early deployment sites function as safety experiments whether leaders call them pilots or not. The unknown queue, training gaps, unresolved tickets, and performance incidents created evidence that had to be incorporated before expansion.[2][3] A rollout process should define measurable safety gates, not just completion dates.
Learning only counts if later sites inherit the lesson
A defect discovered at one hospital should change configuration, training, monitoring, or architecture before the same workflow reaches the next hospital.
Why the VA EHR modernization belongs in software-failure history
The VA case is not a story about a single bug or a failed product. It is a system-level failure involving software behavior, integration, support, training, procurement controls, and rollout governance. The most serious findings involved invisible work loss, degraded performance, and process weaknesses capable of affecting patient care.[1][5]
The lesson is that large clinical software programmes need safety engineering comparable to other high-hazard systems. End-to-end delivery must be observable, downtime must be rehearsed, tickets must become engineering knowledge, and rollout decisions must respond to documented harm. An EHR is not merely a record database; it is the routing fabric through which modern healthcare work happens.
That standard should be measurable.
Works Cited
- 01
- 02
- 03
- 04
- 05
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.