Key Highlights
- Three adoption problems surface in almost every hospital EHR switch (workflow mismatch, cognitive overload, and weak training), but only one sits fully within the hospital’s control.
- KLAS Arch Collaborative data from more than 500,000 clinicians shows a 90-point gap in EHR experience between clinicians who feel their training prepared them and those who don’t. Training quality is the strongest lever a hospital holds.
- Productivity typically falls by around a third in the weeks after go-live (Medical Economics). With structured support the dip is brief; without it, it can persist for months, and a poor early experience tends to stick.
- Vendor training teaches how the system works; only the hospital can teach how its own workflows run in it. That second layer is where go-lives are won or lost.
- The strongest version is built by the hospital’s own people and practised on an anonymised copy of the live system. CHU Montpellier cut classroom time from three hours to 40 minutes; Zuyderland prepared 2,500 staff with patient care uninterrupted.
A new EHR is supposed to help. The first few months rarely feel that way.
A hospital replaces its electronic health record to improve care, standardise processes, and give clinicians better information. Then go-live arrives, and for a stretch of weeks the system seems to do the opposite: clinics run behind, order entry takes longer than it did on the old platform, and the help desk is buried. Whether the new system is Epic, Oracle Health (formerly Cerner), or MEDITECH, the pattern repeats, and it has little to do with which vendor was chosen.
The reasons are well studied. Physicians already spend close to two hours on EHR and desk work for every hour of direct patient care, according to the landmark Sinsky study in Annals of Internal Medicine (2016). The AMA’s own 2024 analysis still puts it at roughly six hours of EHR time per eight scheduled hours. Add a new system on top of that load without enough preparation, and adoption breaks down.
The problems that cause it fall into three groups. Knowing which of the three you can change is what separates a rocky go-live from a failed one.
Three problems show up in almost every rollout
Workflow mismatch. New EHRs push clinicians into standardised, often rigid processes that don’t map onto how care is delivered in practice. A task that took one screen now takes several orders and clicks. When the system fights the workflow, clinicians invent their own: shadow spreadsheets, paper notes, workarounds outside the record. Every one of those is a patient-safety and data-integrity risk.
Cognitive overload. Enterprise EHRs surface enormous volumes of data, and they interrupt constantly. Alert fatigue, where clinicians dismiss pop-up warnings because there are too many of them, is a documented safety problem, not a preference. Poor information layering turns routine charting into mental work, and that fatigue follows people home. The “pajama time” that Sinsky’s team quantified, around 86 minutes of after-hours EHR work each night for family physicians, is the visible symptom.
Weak training and change management. Implementations pour budget into the technical build and treat the human side as a line item to trim. Training defaults to generic, classroom-style instruction delivered once, weeks before anyone touches the real system in anger. The initial learning curve gets underestimated, and clinics stay slow for far longer than planned.
All three are real. But they aren’t equally within your control, and that distinction matters more than it first appears.
Two of the three are settled in the build
Workflow mismatch and cognitive overload are mostly build decisions. How the system routes a process, how many clicks an order takes, which alerts fire, how information sits on the screen: these are set during configuration, shaped by the vendor’s model and the choices your project team makes months before anyone goes live. You can influence them through design and optimisation, but you can’t re-architect them in the fortnight before cutover, and you certainly can’t fix them once clinicians are struggling on the floor.
Training and support are different. They’re the part of the transition a hospital fully owns, right up to go-live and beyond, and the part most consistently cut when timelines tighten. That’s the opportunity, because the evidence on how much training matters is unusually clear.
The lever hospitals do control
The KLAS Arch Collaborative has surveyed more than 500,000 clinicians on their EHR experience, and one of its earliest and most durable findings is also its bluntest. There’s a 90-point difference in Net EHR Experience Score, a scale that runs from -100 to 100, between clinicians who strongly agree their initial training prepared them well and those who strongly disagree. Few variables in healthcare IT move a number that far.
It goes further than satisfaction. KLAS found that clinicians with workflow-specific training are less likely to report burnout or to plan to leave, and EHR burnout drives people out of the door. Its 2025 data attributes some level of burnout to 30% of nurses and 32% of physicians; among those who are burned out, the EHR is named as a contributor by 43% of nurses and 62% of physicians. Only 18% of physicians report a strong or elite EHR experience at all.
When a rollout goes badly for clinicians, the usual response is to blame the software or wait for people to adapt. The data points somewhere more useful. The training and support wrapped around the system is the highest-impact thing you can change, and it’s the thing most often done generically, late, and at too low a volume.
What a rushed rollout costs
The cost of underfunding the human side is measurable. Productivity typically falls by around 30% in the first weeks after cutover (Medical Economics), clinics see fewer patients when the organisation can least afford it, and KLAS finds the initial experience durably shapes how clinicians rate the system for years, so a rough start can harden into a lasting baseline rather than fading in a month. Add the attrition that follows burnout, and the bill compounds. We break these costs down in full in our companion post on the real cost of poor EHR adoption. The point here is simpler: when the EHR is a named driver of burnout, training that reduces it protects the workforce and the balance sheet at once.
Building a digital adoption approach for a major clinical system? Our playbook covers how healthcare organisations scale training and accelerate software adoption.
The training gap only the hospital can close
A clinician has to learn two things, easily confused. The first is how the system works: the screens, the navigation, the mechanics. Vendors teach this well. The second is how this hospital does its own work in the system: how admissions flow here, how medication reconciliation runs on this ward, how the hand-off between these teams happens. Only the hospital holds that knowledge, so generic training can’t supply it, and it’s the layer where go-lives are won or lost. The gap widens outside the vendor’s home market, where materials arrive in English and in a reference build, so a hospital in the Netherlands or France bridges a language and a configuration gap on top of the workflow one. The space between knowing the software and knowing the job is where the go-live dip lives.
Build it once, safely, and keep it in the hospital’s hands
Two things make that second layer stick: hands-on practice before go-live, and content the hospital builds itself.
Practice has to be safe. You can’t turn a ward loose on the live record, and no one should learn on real patients. Assima’s object-based cloning produces an anonymised, editable copy of the actual EHR (Epic, Oracle Health, or whichever system you run), so clinicians rehearse complete tasks, the awkward exceptions included, with no patient data exposed. Assima Train builds those clones into guided lessons that behave the way the live record does, so the high-risk workflows (medication administration and reconciliation, patient identification, allergy documentation, order entry) can be drilled until they’re automatic. Rehearsed in a simulator, a first mistake costs nothing.
The content works best when the hospital’s own people make it, because they hold what the vendor can’t. It is the same in-house approach we make the case for in enterprise systems training more broadly, and in healthcare it is already proven. At CHU Montpellier, the training team built more than 150 lessons across every staff profile and cut classroom time per course from three hours to forty minutes. At Zuyderland, a Dutch group of four hospitals, nurses built around 300 exercises and prepared 2,500 staff for a new clinical system, halving classroom time from seven days to three and a half, with patient care uninterrupted. In both, Assima supplied the tooling while the hospital supplied and owned the content.
Owning the content pays off after go-live too. Because the clones are editable, training updates in a few clicks when a protocol changes, so no one rehearses a procedure the hospital has already retired. And as clinicians work through the lessons, the platform shows where they stall and where errors cluster, so L&D fixes the weak points before real patients are involved.
Support at the point of care, and a readiness test that means something
Preparation only reaches so far, and the first weeks live are when unfamiliar tasks surface. Support that sits inside the EHR bridges the rest. Assima Assist walks a clinician through a step at the moment they’re stuck, and Assima In-App Search brings up the hospital’s own instruction for the task, so the answer arrives without a phone call or a paused clinic.
One question is worth more than a course-completion figure: can a clinician carry a real case through the system, safely, from start to finish? Answer that plainly before go-live, and the surprises on the day are far fewer.
Conclusion
Of the three problems behind most hospital EHR struggles, two (workflow mismatch and cognitive overload) are settled in the build and can only be shaped before go-live. The third, how clinicians are prepared and supported, sits entirely in the hospital’s hands, and the evidence says it moves the outcome most. So that’s the part to protect when the schedule tightens. A new EHR earns its return only when clinicians can work in it without fighting it, and the hospitals that get there treat readiness as clinical infrastructure rather than a box to tick. Get it right and the dip is brief and expected; get it wrong and the system inherits the blame for a gap that was never its fault.
See it on your own systems. Book a demo and watch Assima shrink the EHR go-live dip.
Frequently Asked Questions
Let’s Answer Some of Your Questions.
Because clinicians are learning an unfamiliar system while still caring for patients, so tasks that were automatic on the old platform now take longer. Productivity typically falls 20 to 40 per cent in the first month. With structured support it usually recovers within 60 to 90 days; without it, recovery can take 6 to 12 months or longer.
It adds to an already heavy load and feeds burnout. Physicians spend close to two hours on the EHR for every hour of patient care, and the EHR is named as a burnout contributor by 43 per cent of nurses and 62 per cent of physicians who are affected. Because burnout drives turnover, poor adoption becomes a retention problem, and replacing an experienced clinician is costly in recruitment, onboarding, and lost knowledge.
When staff cannot use the system smoothly, they create workarounds like shadow spreadsheets and paper notes, each of which is a safety and data-integrity risk. Errors concentrate in the first weeks after go-live, particularly in high-risk tasks such as medication reconciliation, patient identification, and allergy documentation.
Its depth and length can be reduced sharply. The dip is driven largely by how well clinicians were prepared, which is the part a hospital controls. Realistic practice before go-live and support inside the system afterwards keep the dip brief and expected rather than deep and prolonged.
The hospital itself, with the right tooling. Vendors teach the system well in general, but only the hospital knows how its own workflows run. At CHU Montpellier and Zuyderland, the hospitals’ own teams built the simulations while Assima supplied the platform, so the content stayed accurate and owned by the people who use it.
