By:Victoria Brazil (@SocraticEM)
Most clinicians don’t need convincing that electronic health records can be hard work. Even on a calm day, EHRs can feel clunky, slow, and oddly disconnected from how clinical work actually happens. During a cardiac arrest, that problem is magnified. The stakes are higher, the pace is brutal, and the margin for error is slim.
Documenting a code is one of the hardest cognitive tasks we ask clinicians (generally nurses) to do. You have to watch the patient, track the team, listen to shouted information, keep time, and enter accurate data in real time. Paper charts were never perfect, but they were forgiving. EHRs are not. They demand clicks, navigation, and precision in a noisy and chaotic environment.
Some marvellous work (and research article) by Biesbroek and colleagues (1) describes this problem clearly and honestly, using the paediatric and neonatal resuscitation context. Their starting point is refreshing: if the documentation tool does not fit the work, clinicians will work around it. And when that happens, we get incomplete records, retrospective transcription, and safety risks.
What makes this paper important is not that it identifies usability problems. Most clinicians could have done that in five minutes. What matters is how the authors went about fixing them.
Simulation was central – not to train people to “use the EHR better,” but to interrogate the system itself. That distinction matters. The focus was not on individual performance, but on how the software, workflows, environment, roles, and timing all interact during a real code.
Across multiple rounds of usability testing and in situ systems simulation, they generated more than 200 concrete recommendations. Many were about the build itself: too many fields, poor sequencing, confusing medication lists, alerts that distract rather than help. Some were about process: who documents what, when paper is still needed, how downtime should work. Others were about training, but very targeted training—focused on known pain points rather than generic EHR orientation.
This is systems focused or translational simulation in action. Not a one-off event. Not a glossy “simulation day.” A strategy.
And a strategy with key principles. First, the work was iterative. The team used multiple Plan–Do–Study–Act cycles. They tested, changed the system, then tested again. Importantly, they discovered new risks introduced by fixes!. One apparently helpful free-text field turned out to reset the pulse-check timer – something that would never have been spotted in a meeting room.
Second, there was a clear mechanism for follow-up. Recommendations were tracked. Adoption was audited after go-live. About two-thirds of the changes were implemented within a year. That matters. Simulation that identifies problems but has no connection to action is wasted time and effort.
This paper also challenges a common reflex: when EHRs are painful, we often blame clinicians for not being trained enough. This work flips that assumption. It shows that many problems sit in design, configuration, and system logic – not user motivation. Simulation becomes a way to make those problems visible, defensible, and fixable.
For clinician educators, there is a bigger lesson here. If we want simulation to improve care, it has to move upstream. Into IT projects. Into procurement decisions. Into build and redesign conversations. EHRs are not going away. Codes will never slow down. If we care about safety, accuracy, and clinician sanity, we need better ways to make systems work under pressure. This paper shows how we can realise the potential for simulation to contribute to healthcare quality and safety.
References
- Biesbroek S, et al. Using Human Factors and Systems Simulation to Optimize the Usability of a Code Documentation Tool. Pediatr Emerg Care. 2026 Jan 21.
Photo – AI generated
The views and opinions expressed in this post are those of the author(s) and do not necessarily reflect the official policy or position of the University of Ottawa. For more details on our site disclaimers, please see our ‘About’ page