VA’s Oracle Cerner rollout made clinical-system governance

Summary

VA began the electronic health record modernisation programme in 2017 and awarded Cerner a contract in May 2018. The first site went live in October 2020. By 2023, five sites were using the system, and VA paused further deployments while it addressed reliability, workflow and user concerns.
GAO reports documented unresolved critical or high-severity test findings, migrated-data problems, weak satisfaction measures, large ticket and configuration backlogs, incomplete lifecycle estimates and recommendations that remained open years into the programme.
VA’s April 2023 reset was a governance decision: future deployments would wait until existing sites met readiness criteria. Later VA announcements described service improvements and a plan to resume deployment in 2026, with a target of completing the federal rollout in 2031.
Vendor accountability and agency accountability are related but not interchangeable. Oracle Health controls platform engineering and contracted service; VA controls clinical policy, site readiness, configuration priorities, acceptance evidence, funding and the decision to deploy.
A release-ready governance model would connect every safety or operational claim to a dated issue, accountable owner, clinical impact, tested fix, user validation, residual risk and deployment gate. Programme activity and improving averages cannot replace that evidence.

This was a clinical operating-model decision

An electronic health record is often described as a database and an interface. In a health system the size of VA, it is closer to a clinical operating system. It determines how clinicians see allergies, reconcile medication, enter orders, route laboratory results, document encounters, manage referrals, dispense prescriptions and exchange information with other providers. It also structures the work of schedulers, pharmacists, billing teams, administrators and technology staff. Changing it modifies care delivery even when the medical policy itself has not changed.

That makes the Federal Electronic Health Record programme different from an ordinary enterprise software migration. A delayed finance report can be serious; a missing or hard-to-find allergy, an interrupted prescription workflow or an order that reaches the wrong queue can create an immediate clinical hazard. The correct governance standard is therefore not simply whether the application is online, on budget or installed. The standard is whether the whole socio-technical system supports safe, intelligible and recoverable work.

The programme also pursued interoperability with the Department of Defense. A shared record promised continuity as service members became veterans and received care across federal facilities. That strategic objective is important, but it does not cancel VA’s responsibility to test how one standardised platform behaves in different hospitals and clinics. Interoperability can improve information continuity while a particular workflow remains difficult. Standardisation can reduce variation while a shared defect increases common-mode exposure.

Accountability begins by naming those layers. Oracle Health supplies and operates important elements of the platform under contract. VA owns the mission, the clinical policies, the acceptance decision and the consequences for veterans. Local staff bring essential workflow knowledge but cannot redesign the vendor architecture on their own. Congress funds and oversees the programme; GAO and other oversight bodies evaluate evidence. Veterans use the resulting service but do not control any deployment gate. Treating all of these actors as one “programme” hides the practical control needed to fix a risk.

The timeline is evidence, not background

VA initiated the modernisation effort in 2017 and awarded Cerner a contract in May 2018 with a stated maximum value of nearly $10 billion over ten years. The first deployment occurred at Mann-Grandstaff VA Medical Center in Spokane, Washington, in October 2020. Additional sites followed. By the time VA announced a full reset in April 2023, the system had been deployed at five facilities, and the agency said it would pause future go-lives while prioritising improvements at those sites.

The sequence matters because each deployment created more operational evidence. Early sites were not merely milestones on a national schedule. They were tests of migrated data, configuration, training, help-desk capacity, pharmacy integration, downtime response and user adaptation. A programme that treats those signals as local inconvenience loses the main benefit of staged deployment. A programme that converts them into national release gates turns early difficulty into institutional learning.

VA later deployed at the joint VA-Department of Defense Captain James A. Lovell Federal Health Care Center in 2024. In December 2024, the agency announced early planning for four Michigan sites in mid-2026. In March 2025, it said nine additional sites would join the 2026 sequence, producing thirteen planned deployments for that year. VA also identified 2031 as the target for completing deployment across the enterprise.

Those announcements describe agency decisions and plans, not proof that every condition is satisfied. GAO’s December 2025 review said VA had a notional schedule but lacked sufficient supporting documentation and did not have a complete updated lifecycle cost estimate. Its report also said sixteen of eighteen recommendations in its body of work had not been fully implemented at that point. The tension between a faster rollout ambition and incomplete programme evidence is the central governance question for the restart.

As of a VA FAQ updated in July 2026, the federal record was operating at fourteen VA medical centres, fifty-five associated clinics and 116 remote or other service locations. That current operating footprint is meaningful. It gives VA more real-world evidence than it had during the first go-lives. It also increases the cost of a common defect and the number of users whose experience must be measured. Scale is both progress and exposure.

Testing had to prove clinical consequence, not software completion

GAO’s 2021 review examined VA’s testing before the first deployment. It reported that the agency had identified critical and high-severity findings and recommended postponing deployment at new locations until such findings were closed or had been appropriately deferred. That recommendation captures an essential distinction: a defect list is not a readiness decision.

Not every open issue should block a site. Clinical systems are never free of defects, enhancement requests or usability complaints. Governance must classify them by plausible harm, affected population, detectability, workaround reliability and recovery time. A cosmetic issue may be accepted. A failure that can hide an allergy, delay a prescription or interrupt order completion requires a different burden of proof. “Deferred” must mean an authorised risk acceptance with an owner and expiry, not a label that allows the schedule to proceed.

Test coverage must also reflect real work rather than ideal scripts. A technically valid order-entry path may fail when a clinician is covering another service, when a patient has records from multiple facilities, when a pharmacist must resolve a conflicting medication, or when a network interruption occurs mid-task. Testing should include night shifts, emergency conditions, unusual referrals, high-volume pharmacy periods, external records, corrections and recovery from downtime.

For each severe finding, the evidence record should show the original scenario, expected behaviour, observed result, clinical consequence, affected configuration, interim control, fix version, regression result and local user validation. If leaders cannot reconstruct that chain, they cannot distinguish a permanently closed risk from a ticket that disappeared into a new category.

The deployment decision should then be made against explicit thresholds. A site should know which findings are nationally blocking, which require local remediation, which can be monitored after go-live and who has authority to stop the launch. A schedule date should be the output of readiness evidence. It should not become the input that reclassifies risks until the date appears achievable.

Data migration was a patient-safety control

GAO’s 2022 work identified problems affecting migrated allergy, medication and immunisation information. This category of risk is easy to underestimate because the data may technically exist while remaining incomplete, duplicated, inconsistently coded or difficult for a clinician to find. Availability at the storage layer is not the same as safe availability during care.

Migration governance starts with provenance. A clinical fact should retain its source, date, status, authoritativeness and transformation history. If two systems use different codes or confidence rules, the mapping must be explicit. If an old allergy entry cannot be converted reliably, it needs a visible exception pathway rather than silent omission. If duplicate medication records arise, the system must help an authorised clinician reconcile them without erasing the audit trail.

Responsibility is shared but separable. Oracle Health controls conversion tooling and important platform representations. VA controls source-data quality, clinical definitions, acceptance criteria and the decision to rely on the migrated record. Local clinicians can identify surprising results, but they should not bear sole responsibility for discovering systematic conversion failures during live care.

The evidence for migration readiness should include completeness by data domain, exception rates, clinically significant discrepancies, reconciliation time, unresolved populations and post-go-live monitoring. A single “migration complete” status conceals the distribution that matters. The board and Congress need to know whether the remaining uncertainty is concentrated in low-risk administrative data or in information used for diagnosis and medication.

Configuration requests revealed an ownership problem

Commercial electronic records are heavily configured. Templates, alerts, order sets, roles, routing rules, pharmacy logic and reporting views must reflect clinical policy and local operations. Configuration is therefore neither purely vendor work nor a collection of user preferences. It is controlled translation between a national platform and care delivery.

GAO reported in March 2025 that VA and Oracle had made more than 1,500 changes by June 2024, while approximately 1,800 configuration requests remained outstanding in February 2025. The counts show substantial activity and a substantial queue. Neither number, standing alone, shows whether risk is falling.

A request backlog combines different things: patient-safety defects, regulatory requirements, workflow corrections, usability improvements, local preferences and duplicate requests. Governance must classify and deduplicate the queue, connect each item to a clinical owner and expose ageing by consequence. Otherwise a programme can celebrate closing many simple requests while a smaller set of pharmacy or safety issues remains unresolved.

National standardisation creates a further tension. VA is right to avoid thousands of unsupported local variants. A common baseline can improve training, updates, analytics and portability. But “standard” cannot mean that a workflow designed around one facility’s assumptions is imposed where it creates unsafe workarounds. Variance should require evidence, yet the baseline itself must remain challengeable.

A mature configuration board includes clinical, pharmacy, nursing, informatics, operations, security, accessibility and vendor expertise. It records why a request was accepted, rejected, merged or deferred. It tests interactions with other settings and publishes the decision in language local teams can use. Emergency safety changes need an expedited route without becoming an uncontrolled bypass.

The key control is traceability from reported problem to production state. For a request described as closed, VA should be able to show the affected sites, approved design, version, test results, deployment date, user validation and monitoring. If a workaround remains, it should have an owner and sunset criterion. A falling backlog is useful only when closure preserves that evidence.

Pharmacy risk needed its own release gate

Pharmacy repeatedly appears in the public oversight record because medication workflows join clinical judgment, inventory, prescribing, verification, dispensing and patient communication. A defect can cross several teams before its effect becomes visible. That makes pharmacy an appropriate independent release gate rather than one workstream inside a blended readiness score.

GAO’s 2025 report discussed priority patient-safety and pharmacy-related configuration requests and noted that important items remained unresolved at the dates it reviewed. The correct reading is dated and specific. It does not prove that every listed issue remained open later, and it should not be converted into a claim that the system was uniformly unsafe. It does show that closure evidence for high-consequence items deserved more visibility than an aggregate improvement statement.

A pharmacy gate should test end-to-end cases: new prescriptions, renewals, discontinuations, allergies, interactions, substitutions, controlled substances, partial fills, mail delivery, inpatient-to-outpatient transition, external prescriptions and downtime recovery. It should include the queues and handoffs where an apparently successful screen action can fail to produce the intended downstream work.

The gate also needs operational capacity measures. A workflow can be technically correct yet create a backlog that delays fulfilment. VA should track aged prescriptions, abandoned tasks, manual re-entry, call volume, overtime, error correction and time to reach a pharmacist. Those measures must be segmented by facility and risk class; an enterprise average can hide a struggling site.

Clinicians and pharmacists need protected reporting channels. If raising a defect is slow, repetitive or perceived as futile, the formal ticket count understates risk. Near misses and workarounds are valuable evidence. Reporting them should not punish the person who prevented harm. It should trigger triage, pattern detection and a response visible to the reporter.

Vendor service levels should then connect to clinical impact. Availability percentages and response times matter, but a contract should distinguish a cosmetic defect from a failure that interrupts medication work. Credits alone do not restore care. The accountability objective is a verified fix, a safe interim process and learning that prevents recurrence.

Uptime was necessary and limited public evidence

Congressional hearings examined system availability and the way VA and Oracle described outages. The record contains competing perspectives about improvements, disruption and measurement. Those statements should be attributed to their witnesses rather than collapsed into one uncontested fact. The broader control lesson is clear: the definition of uptime determines what leaders can see.

A platform may be reachable while a critical function is degraded. A clinician may log in but be unable to retrieve a result, complete an order or use a connected pharmacy service. Conversely, a planned maintenance window may lower a simple uptime percentage even when the clinical fallback is well controlled. One number cannot represent all forms of availability.

VA needs a service map that links technical components to clinical capabilities. For each incident, the record should identify start time, detection source, affected functions and sites, patient-facing effect, workaround, restoration, data reconciliation and recurrence risk. Vendor telemetry should be compared with user reports and local operational measures. Disagreement is a signal to investigate the metric, not a reason to choose the more favourable dashboard.

Continuity plans must be tested, not merely documented. Staff should rehearse how to access essential information, issue orders, manage medications, record actions and reconcile data when the system returns. Paper or offline workflows can protect care for a short period, but they create later transcription and duplication risk. Recovery is not complete until deferred work is reconciled.

The strongest availability target is capability based. It asks whether a facility can deliver defined critical services within safe limits during a component failure. That target can coexist with contractual uptime, mean-time-to-repair and incident-volume measures. Together they show technical reliability, clinical resilience and the quality of recovery.

User dissatisfaction was operational evidence

GAO’s 2023 review highlighted unusually low user-survey results from 2021 and 2022. It reported that roughly six percent of respondents agreed the system enabled high-quality care and roughly four percent agreed it enabled them to work efficiently. GAO also found weaknesses in VA’s satisfaction goals and measurement approach.

These dated results should not be portrayed as a permanent verdict on the system. Users can learn, software can improve and workflows can be redesigned. The results were nevertheless severe operational evidence. When the people responsible for care overwhelmingly reject propositions about quality and efficiency, management must investigate the causes before treating rollout as a standard adoption problem.

User sentiment needs decomposition. A clinician may dislike a changed interface but still complete work safely. Another may report acceptable overall satisfaction while relying on a risky workaround. Surveys should therefore be linked with task completion, click burden, queue ageing, support demand, error reports and observed workflow studies. Free-text comments and local interviews can reveal why a score moved.

Targets matter because they define what improvement is enough. If management reports only a rising trend, a move from a very low baseline can look successful while performance remains unacceptable. VA should publish threshold logic: which measures are informational, which require remediation and which block the next deployment.

Training is part of the response but cannot become a universal explanation. Repeated user difficulty may reflect inadequate training, poor configuration, a platform defect, staffing pressure or an unnecessarily complex workflow. Assigning every problem to “change resistance” transfers accountability from the system owner to the people absorbing its costs.

Trouble tickets needed to become learning evidence

Support tickets are the programme’s richest operational dataset when they are handled as evidence rather than queue volume. Each ticket can identify an affected role, site, task, configuration, version and consequence. Patterns reveal where standard workflows fail in actual care.

GAO found challenges with ticket management and the accumulation of unresolved work. Counting opened and closed tickets is not enough. Duplicate closure, recategorisation and mass resolution can improve a dashboard without correcting the underlying problem. A ticket linked to a patient-safety issue should not disappear when it is merged; its evidence lineage must survive.

Triage should use clinical consequence, frequency, exposure and workaround quality. A rare issue with severe plausible harm can outrank a frequent nuisance. A frequent nuisance can still become a safety concern if it produces fatigue or workarounds. Priority decisions should be reviewable by clinical owners rather than determined solely by service-desk labels.

Time measures should distinguish acknowledgement, containment, technical fix, production deployment and verified closure. A quick reply does not mean the risk is controlled. If a temporary procedure is required, the ticket should name who communicated it, which sites adopted it and how compliance is monitored.

Root-cause analysis should connect related events across sites. The same underlying defect may appear as a pharmacy complaint, an order-routing failure and a data discrepancy. Shared taxonomy and platform telemetry can expose the common mechanism. Without that connection, each facility spends effort rediscovering a national problem.

The programme should publish a bounded, privacy-safe view of severe issue performance: new items, aged items, recurring items, interim controls, clinically validated closures and reopenings. Transparency must protect sensitive system and patient information, but confidentiality should not turn the entire risk state into an assertion that outsiders cannot test.

The 2023 reset was a control, not a defeat

VA’s April 2023 announcement paused future deployments and said the programme would focus on improvements at the five existing sites. It established that launches would resume when the system met readiness criteria. Halting a national schedule after operational evidence showed significant problems was an exercise of control.

A reset becomes credible only if it changes decision rights and evidence. Renaming a programme, extending a date or creating more committees does not repair a workflow. VA needed to define the conditions for leaving reset, identify who could veto a launch, and show how findings from existing sites changed the national baseline.

The agency later reported improvements in service performance and user experience. Those claims are useful indicators and should be considered alongside GAO and congressional evidence. Because they are agency-reported, they should not be treated as independent validation. The correct question is whether the underlying definitions, time periods and populations are visible enough to reproduce the conclusion.

The reset also created a natural comparison. VA could measure the same tasks before and after each change at the existing sites: medication processing, order completion, ticket ageing, outage impact, survey results and manual workload. Improvements that persist across sites and releases are stronger evidence than a short interval after intensive support.

There is a governance risk in keeping early sites in a permanent exceptional state. Extra staff, vendor attention and temporary workarounds can make performance appear sustainable while national replication would require resources that do not scale. Exit evidence should therefore show normal staffing, routine support and stable controls over a meaningful period.

Calling the pause a failure or calling the restart a success both oversimplify. The pause protected future sites from known exposure. The restart is justified when the evidence shows that risks have been reduced, owned or consciously accepted. Each is a decision point, not a verdict on the whole programme.

Restarting in 2026 raised the burden of proof

VA’s December 2024 and March 2025 announcements set out a renewed deployment path: four Michigan facilities followed by nine additional sites during 2026, using a standardised baseline and working toward enterprise completion in 2031. The current footprint reported in July 2026 indicates that rollout activity has resumed.

Acceleration can be rational. A long pause carries costs: legacy systems require maintenance, interoperability benefits are delayed, staff prepare repeatedly and programme knowledge decays. Existing sites can also benefit when a broader user base supports more standardisation and investment. The alternative to deployment is not risk free.

Yet a faster cadence compresses learning time. If several sites launch before defects from the first are understood, the programme amplifies exposure. Training teams, clinical informaticists, service desks and vendor engineers can become bottlenecks. A problem that was manageable with intensive attention at one facility may become systemic across many.

The restart should therefore use waves with explicit stop conditions. Each wave needs a stabilisation window, leading indicators, independent review and authority to delay the next group. Site readiness should cover infrastructure, data, workforce, workflow, continuity and local leadership, while national readiness should cover platform capacity, vendor support and unresolved common defects.

The standard baseline should be version controlled. Leaders must know exactly which configuration, interfaces, training material and known issues each site receives. Changes made during a wave should be assessed for already-live locations as well as future sites. Otherwise “standard” fragments into undocumented versions.

Public reporting should distinguish scheduled, technically activated, clinically operational and stabilised sites. A go-live count can rise while intensive support continues. Completion should mean that routine care is supported, severe issues are within thresholds, data is reconciled and local teams can operate without extraordinary intervention.

Cost and schedule estimates were governance instruments

GAO’s March 2025 report contrasted VA’s older $16.1 billion lifecycle estimate with an independent estimate of about $49.8 billion and said VA still lacked an updated, reliable lifecycle cost estimate and integrated schedule. The figures are not directly interchangeable without reading their assumptions, scope and time horizon. Their divergence is itself a governance signal.

A lifecycle estimate forces choices into one model: licences, infrastructure, interfaces, data conversion, training, deployment support, legacy-system sustainment, remediation, staffing and operations. If major categories or schedule dependencies are missing, decision makers cannot compare acceleration with delay or understand the cost of temporary controls.

The estimate should include uncertainty rather than one authoritative point. Deployment pace, vendor pricing, legacy retirement, configuration demand and site complexity can change the range. Congress needs to see which assumptions drive it and how actual experience updates them. A wide but honest range is more useful than a precise number disconnected from observed performance.

An integrated schedule is equally important because clinical readiness tasks depend on one another. Data cannot be validated before conversion rules are stable. Training cannot be finalised before workflows and roles are known. A site cannot safely launch if required interfaces or continuity exercises are incomplete. Milestones should carry logical predecessors and evidence, not only target dates.

GAO’s December 2025 work said VA had a notional deployment schedule but lacked adequate documentation supporting it and still lacked the updated cost estimate. That finding should not be read as a claim that no scheduling occurred. It means the public oversight evidence did not support the degree of confidence required for a multi-year accelerated plan.

Cost governance also prevents sunk-cost reasoning. Money already spent cannot justify accepting a future risk. Each wave should be judged against prospective clinical benefit, remaining cost, alternatives and control evidence. Conversely, overruns do not automatically prove that cancellation is safer; a fragmented legacy environment has its own cost and risk.

Contract accountability required measurable clinical outcomes

VA’s contract with Cerner, now operating as Oracle Health, created commercial duties around the platform. In May 2025, VA announced that it would continue the partnership for another option period under a structure allowing annual review. An option decision is one of the agency’s strongest accountability levers.

Traditional technology service levels focus on uptime, response time and defect severity. Those measures are necessary, but the contract should connect them to capabilities VA must deliver. An outage that interrupts pharmacy service, an interface failure that delays results and a cosmetic screen defect should not produce the same consequence merely because they share a duration.

Measures should be resistant to definition games. VA and Oracle need agreed clocks, event boundaries, affected-user counts, exclusion rules and data sources. When measurements differ, the discrepancy should be retained and resolved. A contract that permits one party to define both performance and exceptions cannot provide independent evidence.

Financial remedies have limits. Service credits may recognise poor performance, but they do not compensate a veteran for delayed care or restore exhausted staff. The primary remedy must be containment, repair, validation and prevention. Escalating consequences can support that goal when repeated failures show that ordinary incentives are limited public evidence.

VA must also own its side of the dependency. The vendor cannot decide national clinical policy, resolve every local workflow dispute, repair source-data quality alone or accept risk for the agency. A contract cannot outsource the statutory mission. When responsibilities overlap, the issue record should separate vendor defect, VA configuration, source data, local process and joint integration rather than assigning blame before analysis.

Option-year evidence should include unresolved severe items, repeated incidents, delivery quality, staffing commitments, configuration throughput, security obligations, cost, transition risk and independently validated clinical performance. Continuing the contract may be the responsible choice, especially given switching cost. Accountability lies in making that choice against visible evidence, not in pretending lock-in removes agency leverage.

Lock-in changed the shape of the duty

Once clinical data, interfaces, workflows, training and operations depend on a platform, replacement becomes expensive and disruptive. That lock-in is not unique to Oracle or to VA. It is a structural property of large electronic health records. It changes what prudent governance must preserve.

VA needs usable access to its data, configuration history, interface specifications, audit logs and test evidence. It needs continuity rights if the vendor relationship changes, and a credible ability to operate through disputes or transition. The objective is not to maintain a fully interchangeable supplier at every moment. It is to prevent dependence from becoming inability to verify or act.

Architecture decisions should identify which capabilities are portable, which are proprietary and which require long transition periods. Data export should be tested for completeness and semantics, not merely promised contractually. Critical interfaces should have documented owners and recovery procedures. VA personnel must retain enough technical and clinical knowledge to challenge vendor explanations.

Lock-in also increases the importance of disciplined customisation. Excessive divergence can make updates harder and deepen dependence on specialised support. Too little adaptation can force unsafe local workarounds. The accountable balance is a controlled standard with justified variation, transparent debt and a plan to retire temporary deviations.

Switching threats are not a substitute for performance management. A sudden replacement could expose veterans to greater risk than continuing and improving the current system. VA’s leverage includes option periods, payment structure, acceptance criteria, transparency, executive escalation, competition for peripheral services and the ability to require specific evidence.

The board-level question is therefore not “Can VA leave tomorrow?” It is “Can VA verify performance, protect care, preserve its information and choose among realistic paths without the vendor controlling the facts?” That is operational sovereignty within a long-term partnership.

Independent assessment was a missing counterweight

GAO’s 2023 report recommended an independent operational assessment. Independence matters because programme offices are rewarded for delivery, vendors are rewarded for contract performance and local leaders may feel pressure to support an enterprise decision. None of those perspectives is automatically unreliable, but each has incentives that a review design must recognise.

An independent assessment should observe real workflows, inspect severe issues, sample data, test continuity, compare metrics with raw evidence and speak confidentially with users. It should not merely review the same dashboards used by programme leadership. Its scope and sampling should be published far enough to make conclusions interpretable.

Independence does not mean distance from clinical expertise. Reviewers need physicians, nurses, pharmacists, informaticists, safety specialists, engineers, security experts and programme-control professionals. A purely technical audit can miss clinical consequence; a purely clinical review can miss platform-wide failure modes.

The assessment should report both conditions and limits. A sample of several sites cannot prove every facility ready. A successful exercise cannot guarantee future performance. But structured independent evidence can show whether management’s claims are reasonable, whether severe risks are classified consistently and whether the release process can stop itself.

VA can retain final authority while committing to respond publicly to recommendations. If it accepts a risk that reviewers consider blocking, it should identify the accountable executive, rationale, interim control and reconsideration date. That is not weakness; it is visible governance.

Independent review is particularly important before acceleration. When a programme has spent years addressing known problems, familiarity can normalise residual risk. A fresh team can ask whether a workaround has silently become permanent, whether a metric lost meaning or whether the baseline still reflects current clinical work.

Responsibility followed practical control

VA senior leadership controlled programme objectives, funding requests, readiness policy, risk acceptance, contract options and the decision to resume deployment. It therefore owned the enterprise duty to prove that the system supported safe care. That duty did not require leaders to configure individual order sets, but it required them to demand reliable evidence from those who did.

The VA programme office controlled integrated planning, issue governance, measurement, deployment coordination and much of the relationship with Oracle. Clinical leadership controlled national policy and acceptance of clinical workflows. Site leaders controlled local preparation, staffing, training and escalation within the constraints of the national system.

Oracle Health controlled contracted platform engineering, hosting or service components, defect remediation, configuration delivery and evidence specified by the agreement. The public record does not support assigning every workflow problem to a vendor defect. Some issues arise from VA choices, source data, integration or local process. Shared causation should produce a joint corrective plan with separate tasks.

Frontline clinicians, pharmacists and support staff controlled their immediate actions and reporting. They did not control national architecture, vendor capacity or deployment dates. Workarounds that preserve care are evidence of professional resilience, not proof that the system is acceptable. Management must avoid converting user adaptation into an invisible subsidy for poor design.

GAO and other oversight bodies controlled independent evaluation and recommendation. Congress controlled appropriations, hearings and statutory oversight. Neither operated the record. Veterans controlled neither the platform nor the programme; their responsibility should never be framed as learning to tolerate a difficult service.

Responsibility should be recorded at the level of each risk. “VA and Oracle are working together” is a relationship statement, not an accountable plan. Every severe issue needs one decision owner, named delivery owners, dates, evidence and a rule for escalation.

The shared record also requires coordinated cybersecurity ownership across VA, Defense, Oracle and connected federal services. GAO’s June 2026 review called for clearer interagency goals, roles and performance measures; it did not identify a particular EHR breach. The governance implication is bounded: a joint incident or interface risk needs one accountable lead, agreed evidence and tested recovery rather than parallel assurances from each organisation.

The board-ready evidence package

A board, secretary or congressional committee cannot review thousands of tickets. It can require a compact evidence package that preserves the risk distribution. The first layer should describe clinical capability: medication, orders, results, documentation, referrals, scheduling, data exchange and downtime recovery.

For each capability, the package should show severe open risks, recent incidents, affected sites, trend, interim controls and validated closures. It should distinguish technical availability from successful clinical completion. Averages should be accompanied by worst-site and high-risk-population views.

The second layer should cover data. It should report migration completeness, clinically significant discrepancies, exception ageing, reconciliation, lineage and post-go-live corrections. Patient privacy limits public detail, but internal assurance should be able to trace a sampled fact from source to clinician display.

The third layer should cover people and work. Survey results, response rates, task time, training completion, support volume, overtime, turnover and workaround prevalence show whether the platform is imposing unsustainable burden. Positive trend should be tested across roles and sites.

The fourth layer should cover vendor and programme control: service levels, repeat defects, configuration throughput by risk, cost range, integrated schedule confidence, recommendation status and contract decisions. Every changed definition should be disclosed.

Finally, the package should contain a release decision. It should state which criteria passed, which did not, which risks were accepted, who accepted them and what would trigger a stop. Evidence should be dated and retained so later reviewers can tell what leaders knew at the time. That protects both veterans and responsible decision makers.

What a credible site gate would look like

Ninety days before go-live, the site should freeze its critical workflow inventory and identify national and local variations. Data conversion rehearsals should quantify exceptions. Infrastructure and interfaces should undergo load and failure tests. Staffing and training plans should include backfill, super-user coverage and post-launch demand.

Thirty days before go-live, all nationally blocking issues should be closed with evidence. Local severe items should be closed or explicitly accepted by an authorised clinical executive with a tested interim control. The site should complete downtime and recovery exercises. User surveys should test confidence in defined tasks rather than general enthusiasm.

At the final gate, an independent team should sample the evidence and observe high-risk scenarios. The decision forum should include clinical, pharmacy, operations, technology, safety, security, data and vendor leaders. Anyone responsible for a blocking domain should be able to request delay without career penalty.

During launch, VA should monitor capability measures in near real time: prescription ageing, abandoned orders, interface queues, results delivery, help requests, workarounds and continuity events. A command centre should record decisions and preserve the issue lineage rather than solve problems only through transient chat.

After launch, stabilisation criteria should determine when extraordinary support can leave. A site is not complete because the switch occurred. It is complete when severe risks remain within threshold, reconciliation is finished, the local team can operate sustainably and national owners have incorporated lessons into the next baseline.

The next wave should not begin automatically. Programme leadership should review the preceding wave’s evidence and explicitly confirm that capacity remains sufficient. This short feedback loop is the control that turns staged deployment into learning.

What remains unknown

Public reports do not expose every patient-safety event, configuration request, incident log, contract measure or internal risk acceptance. Sensitive health, security, commercial and supervisory information properly limits disclosure. The absence of public detail is not proof that a control is absent.

The available record also does not permit a clean causal allocation of every problem among vendor software, VA configuration, migrated data, infrastructure, training, staffing and local workflow. Those factors interact. Assigning all difficulty to Oracle or all difficulty to VA would go beyond the evidence.

Agency statements describe improvement during the reset, while oversight reports document continuing gaps at specific dates. Both can be true. Performance may improve while important recommendations remain open. A national average may rise while one capability or site remains weak.

The July 2026 footprint is current to the cited VA page, not a guarantee about every site’s stabilisation state. The 2031 date is a target, not a completed integrated schedule. The cost figures use different scopes and assumptions and should not be subtracted as though they were comparable invoices.

No public source in the frozen set supports claiming that the programme caused a particular death, that every deployed site is unsafe, that Oracle alone controls clinical readiness or that the reset solved all significant issues. Those claims are excluded.

The conclusion is narrower and stronger: VA accumulated enough evidence to know that EHR deployment is a clinical governance decision. Its next phase will be credible to the extent that it preserves the lessons of the pause in measurable gates, independent review and responsibility attached to practical control.

VA’s Oracle Cerner rollout made clinical-system governance an auditable accountability test