EHR usability is how well clinicians can do their work in an electronic health record: how quickly, with how few errors and with how much effort. Poor usability shows up as extra clicks, missed results, wrong-patient orders and documentation that spills into the evening.
This guide covers the federal safety-enhanced design criterion, the user-centered design methods behind it, NIST and AHRQ guidance on testing, and how to measure clicks, time and errors so that usability work is judged on evidence rather than opinion.
What is EHR usability?
Designing or testing clinician screens?
Agnotic builds and usability-tests clinician-facing EHR apps and extensions for the client.
EHR usability is the extent to which clinicians and staff can complete clinical tasks in an electronic health record effectively, efficiently and with satisfaction, without errors that put patients at risk. It is measured with real users doing real tasks: success rates, errors, time on task, clicks and the users' own ratings.
Effectiveness, efficiency and satisfaction are the usual three measures of usability in any field. Health care adds a fourth concern: use errors, where the design leads a careful user into a wrong action, such as an order on the wrong patient or a dose in the wrong unit.
Usability belongs to the system as configured and used, not to the product alone. The same certified EHR can be easy in one hospital and hard in another because of local build decisions, so vendors and provider organizations share the work.
What does safety-enhanced design require?
Safety-enhanced design, 45 CFR 170.315(g)(3), is the ONC certification criterion that requires EHR developers to apply user-centered design to specific clinical capabilities and to report summative usability test results. It applies to developers seeking certification, not to provider organizations.
As the criterion reads in the 2015 Edition text, before HTI-5 takes effect, it has four parts:
- Covered capabilities: Computerized provider order entry for medications, laboratory and diagnostic imaging, drug-drug and drug-allergy interaction checks, demographics, the implantable device list, clinical information reconciliation, electronic prescribing and decision support interventions.
- User-centered design process: The developer names the process it used, either an industry or federal standard, or its own process with an outline and a reason no standard was practical.
- Summative testing: At least 10 test participants for each capability, with the test scenarios submitted.
- Reporting: Results in the NISTIR 7742 format, including participant profiles, the tasks tested, success and failure rates, time on task and a satisfaction rating for each task.
HTI-5 changes the picture. The ASTP/ONC summary of the HTI-5 final rule, dated 26 October 2026, lists (g)(3) as revised rather than removed, effective on the rule's effective date. Read the final rule text on healthit.gov or federalregister.gov for the revised requirements before planning certification testing.
For buyers, the practical value of (g)(3) is the published test report. Certified products carry their safety-enhanced design results on the Certified Health IT Product List, and reading them shows which tasks a vendor tested, with how many users, and where those users struggled.
How does user-centered design apply to an EHR?
User-centered design keeps clinicians involved at every stage: research before design, formative tests during it and a summative test at the end. NIST's EHR Usability Protocol, published as NISTIR 7804 in 2012, sets out three steps: analysis of how the application functions, expert review, and validation testing with representative users.
- 1. Context research: Observe each role in its real setting, such as a nurse at the bedside or a physician between exam rooms, and record interruptions, handoffs and workarounds.
- 2. Task analysis: List the critical tasks, especially those where an error can harm a patient, such as ordering, reconciling medications and acknowledging results.
- 3. Design: Shape screens around those tasks, with patient identity, units and abnormal values visible wherever a decision is made.
- 4. Expert review: Usability specialists and clinicians review the design against known heuristics and documented use errors.
- 5. Formative tests: Short rounds with a few users each, fixing problems between rounds.
- 6. Summative test: A final test with representative users on the critical tasks, measuring success, errors, time and satisfaction.
Formative rounds are where design problems are cheapest to fix, because each round is small enough to run again next week. Save the summative test for a design the team already believes in, and treat a failed task there as a reason to go back a step, not to adjust the pass mark.
How do you measure clicks, time and errors?
Use two sources: task-based tests, which show why something is slow, and EHR audit-log data, which shows how slow it is across all users. Neither is enough on its own.
- Clicks per task: Count the clicks and screen changes needed to finish a defined task, such as ordering a common lab test, in a scripted session.
- Time on task: Measure start to finish for each task in testing, and time in the record per visit from audit logs in production.
- Success and errors: Record whether each task finished correctly, and log every use error along the way, near misses included.
- After-hours work: From audit logs, the share of documentation time outside scheduled clinic hours, broken down by role.
- Satisfaction: A short standard questionnaire after each test session, so scores can be compared from one round to the next.
- Alert response: How often each interruptive alert fires, and how often users override it.
Define each measure once and keep it stable. A change that removes clicks but raises the error rate is not an improvement, so always report errors next to speed.
Audit-log measures need care. They record activity in the chart, not thinking time away from it, and idle timeouts change the numbers. Compare like with like: the same role, the same visit type and the same measurement rules before and after a change.
How can a provider test the usability of its own build?
A provider can run a smaller version of the same method on its configured system: pick the critical tasks, recruit a few users from each role, and time them on a test patient before and after a change. It needs a test environment that matches production, not the vendor's demonstration system.
- Tasks from real signals: Start with the tasks named in safety event reports, help desk tickets and clinician complaints, because those point to friction users already feel.
- A scripted scenario: A test patient, a starting screen and a clear end point, so every session measures the same task in the same way.
- Observation without coaching: The facilitator records where users hesitate or make errors, and steps in only when a user is completely stuck.
- Fix, then retest: Change the build and run the same script with different users to confirm the fix worked and did not move the problem elsewhere.
- A short result: One page per task with before and after numbers, sent to the governance group that approved the change.
Short rounds repeated after each fix give decision makers evidence they can act on quickly. They also build a library of scripted tasks the organization can rerun after every vendor upgrade.
Keep the users in these sessions away from production. Test patients in a non-production environment avoid accidental orders on real charts and keep session recordings free of real patient data.
What belongs in a usability test plan?
A test plan fixes who is tested, on what, in which environment and against which pass mark, before the first session. Writing it first stops a test from turning into a demonstration.
- Purpose: The decision the test will inform, such as releasing a redesigned order screen or choosing between two note layouts.
- Participants: The roles and experience levels to recruit, and how many of each, with new users included alongside experienced ones.
- Tasks: The critical tasks in priority order, each with a clear start and end point and the data the user is given.
- Environment: A test system configured like production, with synthetic patients built for each scenario.
- Measures: Task success, use errors, time on task, clicks and a short satisfaction questionnaire, defined the same way for every session.
- Pass mark: The result each task must reach before release, agreed with the clinical owner in advance.
- Moderator script: The words used to introduce each task, so every participant hears the same instructions.
- Reporting: A summary per task with findings ranked by risk to patients, and the fix proposed for each one.
AHRQ has also published an EHR usability toolkit for primary care practices that want to assess their own systems, which can serve as a starting point for a practice without in-house usability staff. The method stays the same whatever the source: representative users, critical tasks, measured outcomes and documented fixes.
Usability problems that create safety risk
Some usability problems only cost time. The ones below can lead to harm, so test for them first.
- Wrong-patient actions: Patient identity is not visible on every screen where an order or note is entered, or several charts are open without clear separation.
- Unit and dose confusion: Free-text doses, mixed units or default values that a hurried user accepts without reading.
- Hidden results: Abnormal results look the same as normal ones, or sit on a separate tab the user has to remember to open.
- Alert overload: Interruptive alerts for low-value rules teach users to override everything, including the alerts that matter.
- Copy and paste drift: Notes carried forward from earlier visits keep outdated findings that the next reader takes as current.
- Truncated lists: Medication or problem lists are cut off with no visible sign that more items exist.
- Inconsistent controls: The same action sits in a different place on different screens.
Each of these can come from the vendor's design or from local configuration, so test the build as configured, not the vendor's demonstration system.
How Agnotic can help
Usability findings often stall at the point where they need engineering: a SMART on FHIR app that brings a specialty's key data onto one screen, a CDS service that replaces a noisy built-in rule, or audit-log analytics that measure the effect of a fix. Agnotic Technologies builds those for the client and runs task-based usability tests on the apps it builds.
For developers preparing a product for certification, Agnotic builds clinician-facing features with a user-centered design process documented from the first research session.
Improve EHR usability with Agnotic
Start with EHR integration services, or browse more articles in the EHR integration hub.
Related reading on Agnotic
Continue with EHR customization, an EHR optimization program, healthcare UX research and clinic screen design.
