EHR Upgrade Planning
What to ask of QA, and when to ask for it.
If your organization runs an EHR, another upgrade or migration is coming. Leaders can’t control a vendor’s release calendar or a regulator’s deadlines. They do control how the project is set up: who is on the team, what the plan includes, and when QA gets involved. This six-part series is for executives planning or running an EHR upgrade. A new part publishes every Thursday.
SQA² is QA-only. QA is all we do, and we offer no other products or services.
- 1When QA joins
- 2Requirements review
- 3Test evidence
- 4Clinical time for UAT
- 5Time to set up
- 6QA capacity
Six questions to ask before your next EHR upgrade
One question from each part of the series. Mark each one Yes, Partly, or No. Every answer that isn’t a Yes is a decision worth revisiting while the plan can still change. It takes about two minutes, with no email required.
Check your project in about two minutes
Answer for the project as it’s planned today. Your answers stay in your browser.
Does your project plan bring QA in at the start, before the build?
Good looks like QA joining at the start to review the requirements, plan the testing, and set up the evidence the organization will need at the end.
Has QA reviewed the requirements and asked how each one will be verified?
Good looks like an agreed way to verify every requirement before the build starts, and a recorded resolution for each gap QA found.
Before testing begins, can QA show you a traceability matrix and an evidence standard?
Good looks like one record linking every requirement to its test cases, results, defects, and sign-off, plus a standard for what counts as proof, where it’s stored, and who reviews it.
Is clinical staff time for UAT built into the upgrade budget and department schedules?
Good looks like testers scheduled weeks ahead with their managers’ approval, and department heads who have planned coverage for that time.
Does QA have weeks, not days, between its start date and the first test run?
Good looks like time to set the test strategy and plan, get environments and interfaces working, build realistic test data, and set up access that matches real user roles.
Can you add QA capacity for the heaviest weeks without hiring full-time testers?
Good looks like a QA team that can start in days, scales up for the heaviest phases, and scales down when the work tapers off.
The series
Six parts, one every Thursday.
Your EHR upgrade is coming. Decide now when QA joins.
Upgrades are unavoidable, but the schedule is not. Part 1 compares what happens when QA arrives after the build with what happens when it joins at the start, and ends with one question to ask your project sponsor this week.
Read Part 1
Protect the budget by having QA review the requirements.
A requirement that can’t be tested usually can’t be built correctly either. Part 2 covers the gaps QA tends to find during the definition phase, and why fixing one there means rewording a requirement instead of moving the go-live date.
Read Part 2
Could you produce your last upgrade’s test evidence for an auditor?
Regulatory dates keep moving, but the need to show that systems were tested does not. Part 3 explains the two things to expect from QA before testing begins: a traceability matrix and an evidence standard.
Read Part 3
UAT needs clinical time. Commit it early.
User acceptance testing depends on nurses, physicians, pharmacists, and billing staff who have the least time to spare. Part 4 separates what a QA partner can coordinate from the one thing only leadership can do.
Read Part 4
Give QA the weeks it needs before testing begins.
When a schedule slips, test time is often the first thing cut. Part 5 lists the setup QA does before the first test runs, explains why it takes weeks, and shows the evidence it gives leadership at the go-live decision.
Read Part 5
Add QA capacity in days, and scale it by phase.
An EHR upgrade needs more QA capacity than most organizations keep on staff, but only for a while. Part 6 covers how SQA² joins a project at the definition phase and scales with it, and how a 30-day pilot works.
Read Part 6
Also for health tech leaders: Patch Smart
Our six-part series on keeping health tech safe at patch speed. Every fix is a change to working software, and it needs proof that the flaw is closed and nothing else broke. It comes with a free patch readiness checklist.
See the Patch Smart seriesTalk to us about a 30-day pilot
A pilot covers one release or workstream for 30 days. You see how our team works with your people, your environments, and your schedule before making a larger decision. If an upgrade or migration is on your roadmap, the best time to start is before the requirements are final.