The SQA2 Blog: General
If your organization runs an EHR, another upgrade or migration is coming. Vendors retire versions, certification rules change, and clinical and business teams ask for new capabilities. The question is not whether it will happen. The question is how the project is set up when it does.
What leadership controls
Leaders cannot control a vendor’s release calendar or a regulator’s deadlines. They do control the project’s structure: who is on the team, what the plan includes, and when QA gets involved.
What late QA looks like
When QA arrives after the build is done, testing is squeezed between a late build and a fixed go-live date. Testers find defects with little time left to fix and retest them. Clinical staff are asked to join user acceptance testing on short notice. Nobody has agreed on what test evidence the organization will keep. The date usually moves.
What early QA looks like
From a QA standpoint, the upgrades that hold their go-live dates have something in common. QA was part of the project from the start. QA reviewed the requirements, planned the testing, and set up the evidence the organization would need at the end.
That early involvement produces three things:
- Problems found while they are still cheap to fix.
- A test plan agreed before the build ends.
- Test records that are organized and ready if an auditor asks.
The question to ask this week
Ask your project sponsor: at what point does our project plan bring QA in? If the answer is after the build, that is a decision worth revisiting while the plan can still change.
This article opens a six-part series for executives planning or running an EHR upgrade. The next five cover:
- QA in the definition phase
- Traceability and test evidence
- Coordinating user acceptance testing with clinical staff
- Giving QA time to set up
- Adding QA capacity for the length of the project
This is a part of our overall EHR Upgrade Planning series.
