Health NZ EHR Migration
A legacy patient management system is being replaced by a new cloud EHR. You're the Test Manager. Navigate the governance, privacy, three-vendor complexity, and clinical safety risk to a successful go-live.
The Situation
Health NZ Whanganui is migrating from a 1998-era Patient Management System (PMS Legacy) to CloudMed EHR — a cloud-hosted Electronic Health Record system. You have been contracted as Test Manager. The programme is 14 weeks from go-live.
The Players
Supplies and hosts the software
Configures and integrates CloudMed with existing systems
Manages network and legacy interfaces in-house
Independent quality governance across all vendors
Key Facts
- 47,000 active patient records to migrate
- Go-live in 14 weeks
- Regulated under: Health Information Privacy Code 2020 (HIPC), NZ Health and Disability Commissioner Act, Health and Safety at Work Act (clinical safety obligations)
- Three integration interfaces: PMS Legacy → CloudMed (patient records), Lab system → CloudMed (results), Pharmacy system → CloudMed (prescriptions)
- Ministry of Health sign-off on clinical safety required before go-live
- Known data quality issues: ~3,000 records with missing date-of-birth; ~800 with duplicate IRD numbers
Question 1 of 5
You've just joined the programme. What is your first deliverable?
Why B is correct: A test schedule (A) is a tactical output — it presupposes you know the scope. A Jira setup (C) is a tool, not a strategy. A vendor meeting (D) is an input to the strategy. The test strategy is the document that defines everything else: what is in scope, which vendor tests which seam, what "done" looks like for each phase, how PII is handled, and what clinical safety gates must be passed before go-live. On a clinical programme, the strategy also needs to identify the regulatory framework — HIPC, Health and Disability Commissioner Act — before any testing begins. Without the strategy, you're running blind.
Question 2 of 5
The three integration interfaces have no documented test ownership. What do you do?
Why B is correct: Option A assumes TechInt NZ's SOW covers all three interfaces — it probably doesn't. Option C puts you in an execution role, not a governance role. Option D registers the risk but doesn't resolve it — and a go-live in 14 weeks can't afford a passive risk response. The integration test ownership matrix is the right tool: it makes ownership explicit, forces vendor acknowledgement, and gives you a governance artefact to reference when disputes arise. On a clinical programme with patient-to-lab and patient-to-pharmacy interfaces, an untested seam is a patient safety risk — not just a quality risk.
Question 3 of 5
Data quality issues: 3,000 records missing date-of-birth, 800 with duplicate IRD numbers. CloudMed says they'll "handle it in migration." What is your response?
Why B is correct: "We'll handle it in migration" is not a testable commitment — it's a verbal assurance with no measurable exit criteria. Option A accepts risk without evidence. Option C assigns blame but doesn't resolve the problem. Option D removes 3,800 patient records from a health system — those are real patients who need care, and excluding them from the migration creates a different clinical risk. The correct approach is: document the known quality issues, require a pre-migration data quality report, define what "correctly migrated" means for each exception type, and run a post-migration reconciliation test that verifies record-level accuracy. Any record that cannot be resolved needs a documented exception with clinical sign-off — not a silent exclusion.
Question 4 of 5
MoH requires a clinical safety sign-off. What document does the Test Manager produce as input to that sign-off?
Why B is correct: A Jira export (A) is raw data, not a synthesised view — MoH cannot make a governance decision from a defect list. A vendor letter (C) is self-certification, which has no independent assurance value for a regulator. UAT sign-off (D) only covers user acceptance — it doesn't cover clinical risk, data migration accuracy, or integration correctness. The test summary report is the Test Manager's primary governance output: it synthesises everything tested, everything still open, what risks have been accepted and by whom, and a clear recommendation. This document becomes part of the evidence chain in any post-incident investigation. If something goes wrong after go-live, the test summary report is the first document a regulator will ask for.
Question 5 of 5
Three weeks from go-live, a HIGH severity defect is found: the lab results interface sends results to the wrong patient record when a patient has a hyphenated surname. CloudMed says it's TechInt's configuration. TechInt says it's CloudMed's API. How do you handle it?
Why B is correct: Option A is passive — escalating without a resolution process just parks the problem. Option C accepts a patient safety risk: misrouted lab results can cause a clinician to act on another patient's results. On a health programme, this is not an acceptable risk to carry through go-live. Option D introduces delay without resolving the clinical risk. The correct response is immediate: call all relevant vendors within 24 hours, require evidence-based root cause investigation with a defined timeline, document a temporary clinical workaround (manually verify results for hyphenated surname patients), and formally block go-live until the defect is verified fixed. The programme director may pressure you to proceed — your job is to make the clinical risk explicit and put the go-live decision back to the Clinical Director with full information, not to make it for them.
Model Approach: Health NZ EHR Programme
Work through all five questions first, then reveal what strong Test Manager practice looks like on a clinical programme.
What makes clinical systems different
Test Strategy Elements Unique to Clinical Systems
- Clinical risk classification: Every test scenario must be classified by clinical impact — patient safety (high), care coordination (medium), administrative (low). Test sequencing follows risk, not technical convenience.
- Patient safety test scenarios: Define specific scenarios for misrouted results, duplicate records, missing allergies, incorrect DOBs. These are not edge cases — they are primary test objectives on a clinical programme.
- HIPC obligations for test data: No real patient data in test environments without explicit governance approval. Synthetic data must reflect clinical reality — including edge cases like hyphenated surnames, te reo Māori names, and records with incomplete fields.
- Vendor sign-off requirements: Each vendor signs off their component and their integration seams independently. The Test Manager's summary report aggregates all vendor sign-offs — it is not a substitute for them.
One-Page Release Recommendation for the Clinical Director
Structure it as follows:
- Executive summary (3 sentences): What was tested, overall quality status, and recommendation.
- Scope tested: List of systems, interfaces, and data migration components covered. Note any areas explicitly not tested and why.
- Outstanding risk items: Every open defect by severity. For each medium or high item: the clinical risk if it occurs post-go-live, and who has accepted that risk.
- Clinical safety attestation: Statement that clinical test scenarios were executed, including patient safety scenarios, misrouted results, and duplicate record scenarios — with results.
- Recommendation: Go / Conditional Go (with named conditions) / No-Go. A Conditional Go means "go-live is acceptable IF these specific items are resolved within 48 hours of go-live." State the conditions explicitly.
NZ-Specific: Data Breach Notification
Under the Health Information Privacy Code 2020 and the Privacy Act 2020, a health data breach is notifiable to the Office of the Privacy Commissioner within 72 hours of the organisation becoming aware of it. The Test Manager's test summary report is part of the evidence chain in any post-incident investigation — it demonstrates what was tested, what was known, and what risks were accepted. If your summary report is vague or missing, it will be read as evidence of inadequate quality governance. Write it as if a regulator will read it — because they might.
Key Principle
"Clinical safety is not a vendor obligation — it is a programme obligation. You own the evidence that the system was tested adequately."
CloudMed can certify their product is safe. TechInt can certify their configuration is correct. Neither of them owns the end-to-end patient journey across all three vendors and all three integration seams. That is your scope, and it is non-negotiable on a clinical programme.