Clinical Systems & Patient Safety
In most software a defect costs time or money. In a clinical system a defect can reach a patient. This lesson teaches you why that changes how you test, and what rigour the domain expects.
1 The Hook
A fictional NZ regional laboratory, Awa Pathology, sent blood test results to hospital wards through a results system. One afternoon a phlebotomist drew samples from two patients within a few minutes of each other — a Mr Tane Wiremu and a Ms Tania Williams. Their names looked alike on a busy screen, and the results system matched incoming results to patients by name and date of birth, not by a single reliable identifier.
One patient’s critically high potassium result was filed against the other patient’s record. The clinician reading the chart saw a normal result for a patient who actually had a dangerous one, and a worrying result for a patient who was fine. The patient who needed urgent treatment did not get it as quickly as they should have. The patient who was fine was very nearly treated for a condition they did not have.
There was no crash. No error message. The system did exactly what it was built to do — it matched a result to a patient using the fields it was given. The defect was that those fields were not enough to identify a person safely, and no one had tested the case where two patients share a similar name and birth date.
Here is the lesson hidden in that story. The team had tested that results flowed from the lab to the ward. They had a green path where a result arrived and displayed. No test asked the harder question: when the system cannot be certain which patient a result belongs to, what does it do? In a clinical system, that question is not an edge case. It is the whole job.
In NZ, the answer to “which patient” is the National Health Index — the NHI — and a patient-safety tester treats correct patient identification as the first thing to prove, not the last.
2 The Rule
In a clinical system, the worst defects do not crash — they quietly attach the right data to the wrong patient, or hide information a clinician needed to see. Test that the system identifies the patient correctly, fails safely when it cannot, and never shows wrong or missing clinical information without making the uncertainty obvious. A clinical defect is not measured by whether the software ran, but by whether a patient could be harmed.
3 The Analogy
Baggage handling at Auckland Airport.
Every bag carries a barcode tag that ties it to one passenger and one flight. If the system matched bags to people by name alone, two travellers called J. Smith on the same flight could swap suitcases and never know until they opened them. So the airport does not trust the name — it trusts a unique tag scanned at every handover, and if a tag will not scan, the bag is pulled aside rather than guessed onto a belt.
A clinical system works the same way, and the NHI is the barcode for the patient. Awa Pathology matched results by name and birth date — the equivalent of routing bags by passenger name — and two similar patients got their results swapped. The safe design ties every result to the patient’s NHI and, when it cannot be sure of the match, sets the result aside for a human rather than guessing. A patient-safety tester is the person who checks that the system pulls the unscannable bag aside instead of sending it down the wrong chute.
4 Why a Clinical Defect Can Harm
Traditional software sits between a user and a task. A clinical system sits between a clinician and a patient, which means its outputs become inputs to decisions about a person’s body. That is what raises the stakes. The same categories of defect you already know take on a sharper edge:
- Wrong-patient data: a result, allergy, or medication recorded against the wrong person. The Awa Pathology failure. This is the single most dangerous class of clinical defect, because the information looks correct — it is just attached to the wrong human.
- Missing or hidden information: an allergy that does not display, a result that never arrives on the ward, a medication that drops off a list. The clinician acts on what they can see, so information that silently disappears is as dangerous as information that is wrong.
- Misleading presentation: a dose where the unit is ambiguous, a result without its reference range, a date shown in a format that flips day and month. The data is technically present but a human reads it wrongly.
- Unsafe defaults and silent failures: a system that proceeds on a guess instead of stopping, or swallows an integration error so a result simply never appears, with no one alerted that it is missing.
The common thread is that none of these necessarily produces an error message. A clinical system can be “working” in every technical sense and still be unsafe. That is why patient-safety testing is less about “does it run” and more about “what happens to the patient when it goes wrong.”
5 The National Health Index
The National Health Index is NZ’s unique identifier for a person receiving health and disability services. Conceptually it is the single reliable key that ties a patient to their information across the many systems that hold pieces of their record. Where the airport uses a bag tag, NZ health uses the NHI.
For a tester, the important properties to reason about are these. The NHI is meant to identify one person, so two records for the same person under two different NHIs, or two people sharing one NHI, are both serious data-quality defects. Matching a patient by softer fields — name, date of birth, address — is exactly the kind of fuzzy matching that produced the Awa Pathology swap, because those fields are not unique and change over time.
There is also a format and validity dimension. An identifier like the NHI follows a defined structure and typically carries a check mechanism so that a mistyped or invalid value can be detected rather than silently accepted. As a tester you do not need to memorise the exact algorithm, but you do need to test that the system rejects malformed identifiers, does not silently accept a number that fails its check, and never invents or defaults an identifier when one is missing.
6 Clinical Risk and Test Severity
Not every defect in a clinical system carries the same weight, and a patient-safety tester learns to grade them by potential harm, not just by how broken the software looks. A misaligned button is cosmetic. A wrong-patient allergy is potentially fatal. Those two defects might both be “a field showing the wrong thing,” but they are worlds apart in clinical risk.
A practical way to think about clinical risk is the combination of two questions: how likely is this defect to occur in real use, and how badly could a patient be harmed if it does? A rare defect with catastrophic harm can outrank a common defect with trivial harm. This is why a single reproducible wrong-patient result is a release-blocker even if it only happens for similar names, while a cosmetic glitch that happens every day may not be.
This grading is not the tester’s opinion alone. In clinical software, defect severity is set with clinical input — people who understand what actually happens to a patient when the information is wrong. Your job as a tester is to surface the defect clearly enough, with a realistic scenario and the patient consequence spelled out, that the clinical reviewer can grade it. “Field shows wrong value” is a weak bug report here. “Patient A’s critical potassium result displays against Patient B, so the clinician sees a normal result for a patient who needs urgent treatment” is a strong one, because it names the harm.
7 What to Test in a Clinical System
The practical checklist for patient-safety testing of a clinical feature:
- Patient identification: the right information attaches to the right NHI; similar patients (same name, close birth dates) are not confused; a missing or invalid NHI is handled safely, not guessed.
- Fail-safe behaviour: when the system cannot be certain — an ambiguous match, a failed integration, a missing field — it stops or flags for a human rather than proceeding on an assumption.
- No silent loss: a result or referral that cannot be delivered raises an alert; nothing critical simply disappears without anyone being told.
- Correct and unambiguous presentation: doses carry units, results carry reference ranges, dates are unambiguous, allergies and alerts are visible and not buried.
- Allergy and alert integrity: a recorded allergy or clinical alert always displays where a clinician would act on it, and is never dropped during a transfer between screens or systems.
- Audit and traceability: who entered, changed, or viewed clinical information is recorded — both for safety investigation and because, as Lesson 3 covers, it is a privacy requirement.
Notice how many of these are about what happens when something goes wrong. In ordinary software the happy path is most of the value. In a clinical system the unhappy paths — uncertainty, failure, ambiguity — are where patient harm lives, so that is where most of your test design should go.
8 Building Patient-Safety Test Cases
A patient-safety test case names the clinical risk it addresses, describes a realistic scenario, and states the safe expected behaviour — including what the system must do when it cannot be certain. The expected result is not just “the result displays” but “the result displays against the correct patient, or is withheld and flagged if the patient cannot be confirmed.”
Here is a worked test case for the Awa Pathology scenario, written to catch the exact failure:
Clinical risk: Wrong-patient result (critical result on wrong record)
Severity: High — potential serious harm; clinically reviewed
Pre-conditions: Two patients with similar names and close dates of birth,
each with a distinct NHI; a critical lab result to deliver.
Action: Deliver the critical result, identified by NHI, to one patient.
Expected result: 1) The result files against the matching NHI only.
2) The similar patient’s record is unchanged.
3) If the inbound result lacks a confident NHI match, it is
held for manual review, not auto-matched by name/DOB.
Fail-safe check: No result is ever filed by name+DOB alone when the NHI is
missing or ambiguous.
Evidence required: Both patient records before/after; the inbound message;
the match decision log; the manual-review queue entry.
Traceability: Clinical risk register CR-02 (wrong-patient result).
Result: [Pass / Fail]
Notice what makes this catch the Hook bug: the expected result includes the ambiguous-match path explicitly (stage 3), the fail-safe check forbids the unsafe name+DOB fallback, and the case names a clinical risk with a severity set by clinical review. The evidence is the match decision and the state of both records — not a screenshot of one result displaying.
9 Common Mistakes
🚫 Testing only the happy path where the patient is identified correctly
Why it happens: The demo uses one clean patient and the result displays, so it feels done.
The fix: The danger is in ambiguity — similar names, missing NHIs, failed matches. Design most of your tests around what the system does when it cannot be certain which patient it is dealing with. That is where wrong-patient harm lives.
🚫 Matching patients on name and date of birth instead of the NHI
Why it happens: Name and birth date are easy to read and usually right, so they feel sufficient.
The fix: They are not unique and they change. Test that the system identifies on the NHI, rejects invalid identifiers, and never silently falls back to name+DOB when the NHI is missing or ambiguous — the exact Awa Pathology trap.
🚫 Treating a silent failure as a pass because nothing crashed
Why it happens: No error message looks like success, and the result “was sent.”
The fix: A result that silently never arrives is as dangerous as a wrong one — a clinician acts on what they can see. Test that undeliverable results and referrals raise an alert, so missing information is loud, not silent.
🚫 Raising clinical defects without stating the patient consequence
Why it happens: “Field shows wrong value” is how we write bugs in other domains.
The fix: Severity here is graded by harm, with clinical input. Spell out what could happen to a real patient if this shipped, so the clinical reviewer can prioritise it. The consequence sentence is what turns a defect into a graded risk.
10 Now You Try
Three graded exercises across patient identification and clinical risk. Write your answer, run it for AI feedback, then compare to the model answer.
Read the description of a fictional NZ outpatient results portal below. Identify 3 patient-safety risks that could attach data to the wrong patient, hide information, or fail silently, and name the safer behaviour each needs.
Results arrive from a lab and are matched to a patient by first name, surname, and date of birth. If no exact match is found, the system picks the closest match and files the result there. Recorded allergies are shown on the patient summary screen but are not carried onto the printed prescription. When the lab connection drops mid-batch, results that did not arrive are not retried and no alert is raised — the clinician simply sees no new results. The NHI field exists on the record but is optional and often blank.
List 3 patient-safety risks and the safer behaviour for each:
Show model answer
There are at least four real risks here; any three well-explained earns full marks. 1. Closest-match filing — When there is no exact match the system files the result against the nearest patient, which can attach a result to the wrong person. Safer behaviour: hold unmatched results for manual review; never auto-file an uncertain match. Consequence: a critical result lands on the wrong record (the Awa Pathology failure). 2. Allergy not on the prescription — Allergies show on one screen but drop off the printed prescription, so the clinician prescribing may not see them at the point of action. Safer behaviour: the allergy must display wherever a prescribing decision is made. Consequence: a patient is prescribed something they are allergic to. 3. Silent loss on connection drop — Results that fail to arrive are not retried and raise no alert, so the clinician sees no new results and cannot tell any are missing. Safer behaviour: detect undelivered results and raise a visible alert; retry or queue. Consequence: a needed result never reaches the clinician and care is delayed. Bonus: optional, often-blank NHI — matching on name+DOB with no reliable identifier is the root cause behind risk 1. Safer behaviour: identify on the NHI and reject/flag records without a valid one. The trap: every one of these passes a "the result displayed" test, because for the clean patient it does.
The clinical test case below stops at “the result shows” and ignores patient identity and fail-safe behaviour. Rewrite it to be patient-safety-focused, with these fields: Test ID, Clinical risk, Severity, Pre-conditions, Action, Expected result, Fail-safe check, Evidence required, Traceability. Use a fictional Te Whatu Ora ward results screen as the context.
“Send a result for the patient. Check it appears on the ward screen. Pass if the result shows.”
Rewrite as a patient-safety test case:
Show model answer
Test ID: CLIN-ID-012 Clinical risk: Wrong-patient result on the ward screen Severity: High — potential serious harm; severity confirmed with clinical reviewer Pre-conditions: Two ward patients with similar names and close dates of birth, each with a distinct NHI; one has a critical result to deliver. Action: Deliver the critical result identified by NHI; also send a second result whose NHI is missing/ambiguous. Expected result: 1) The NHI-matched result files against the correct patient only; the similar patient's record is unchanged. 2) The result displays with its reference range so "critical" is unambiguous. 3) The result whose NHI is missing/ambiguous is held for manual review, not auto-matched by name+DOB. Fail-safe check: No result is filed by name+DOB alone; an unmatched result raises a visible review item rather than disappearing. Evidence required: Before/after state of both patient records; the inbound messages; the match decision log; the manual-review queue entry; screenshot of the displayed result with its reference range. Traceability: Clinical risk register CR-02 (wrong-patient result) and CR-05 (silent loss of undelivered result). What makes it strong: it names the clinical risk and a clinically-set severity, identifies on the NHI, asserts the similar patient is untouched, includes the ambiguous-match fail-safe path, and demands evidence of the match decision and both records — not just "the result showed".
Design a patient-identification test plan of 5 test cases for a fictional NHI matching feature in an NZ clinical system. Each case needs at least: an ID, what it verifies, an acceptance criterion, and the evidence required. Cover valid NHI match, invalid/malformed NHI, missing NHI, ambiguous match between two similar patients, and a duplicate-record (same person, two NHIs) situation.
Show model answer
ID-01 | Verifies: a valid NHI matches the correct single patient | Acceptance criteria: a valid NHI resolves to exactly one patient; the right record is returned | Evidence required: the NHI used; the resolved patient record; match log ID-02 | Verifies: a malformed/invalid NHI is rejected | Acceptance criteria: an identifier failing its format/check is rejected with a clear error; 0 records returned; no fallback match attempted | Evidence required: the invalid value; the rejection response; confirmation no record was returned ID-03 | Verifies: a missing NHI is handled safely | Acceptance criteria: with no NHI the system does not auto-match on name+DOB; the action is blocked or routed to manual review | Evidence required: the no-NHI input; the block/review outcome; manual-review queue entry ID-04 | Verifies: an ambiguous match between two similar patients is not auto-resolved | Acceptance criteria: two patients with similar name and close DOB are never silently merged or guessed; the case is flagged for human resolution | Evidence required: both candidate records; the ambiguity flag; review entry; both records confirmed unchanged ID-05 | Verifies: a duplicate-record situation (one person, two NHIs) is detected | Acceptance criteria: the system flags suspected duplicate NHIs for the same person rather than treating them as two patients or auto-merging | Evidence required: the two NHIs; the duplicate-detection flag; the review/escalation record Strong plans: each case is specific, has a measurable criterion, names concrete evidence, and together they cover valid match, invalid NHI, missing NHI, ambiguous match, and duplicate record. Weak plans say "check NHI matching works" five times — that is the difference being marked.
11 Self-Check
Click each question to reveal the answer.
Q1: Why is a wrong-patient result more dangerous than a system crash?
A crash is obvious — everyone knows something is wrong and stops. A wrong-patient result produces no error: the information looks correct, it is simply attached to the wrong person, so a clinician acts on it with full confidence. The danger of a clinical defect is measured by potential patient harm, not by whether the software ran.
Q2: Why is matching a patient on name and date of birth unsafe, and what is the safer key?
Name and date of birth are not unique and can change — two similar patients can be confused, which is exactly the Awa Pathology swap. The safer key is the National Health Index (NHI), a unique identifier for the person. Test that the system identifies on the NHI and never silently falls back to name+DOB when the NHI is missing or ambiguous.
Q3: What does “fail safe” mean for a clinical system, and why test it?
When the system cannot be certain — an ambiguous patient match, a failed integration, a missing field — it should stop or flag for a human rather than guess and proceed. You test it because most patient harm comes from the system confidently doing the wrong thing under uncertainty, not from it obviously breaking.
Q4: Why is a silently lost result as dangerous as a wrong one?
A clinician acts on what they can see. If a result silently never arrives and no alert is raised, the clinician has no way to know it is missing, so needed care can be delayed exactly as if the result were wrong. Test that undeliverable results and referrals raise a visible alert — missing information must be loud.
Q5: How is defect severity decided in clinical software, and what should your bug report include?
Severity is graded by potential patient harm, with clinical input — not by how broken the software looks. Your report should state the patient consequence: a realistic scenario and what could happen to a real person if it shipped. That sentence lets the clinical reviewer prioritise it and is the mark of an experienced healthcare tester.
12 Interview Prep
Real questions asked in NZ QA interviews for healthcare roles. Read the model answers, then practise your own version.
“How does testing a clinical system differ from testing ordinary business software?”
The outputs of a clinical system become inputs to decisions about a person’s body, so the worst defects do not crash — they quietly attach the right data to the wrong patient or hide information a clinician needed. I weight my testing toward the unhappy paths: ambiguous patient matches, missing identifiers, failed integrations, fail-safe behaviour under uncertainty. I identify patients on the NHI rather than name and date of birth, and I grade defects by potential patient harm with clinical input, writing the patient consequence into every bug report. The question is never just “did it run” — it is “what happens to the patient when it goes wrong.”
“A result has been filed against the wrong patient. How would you investigate and prevent it?”
My first hypothesis is matching on name and date of birth instead of a unique identifier — two similar patients getting confused. I’d reproduce it with two patients who share a similar name and close birth dates, each with a distinct NHI, and a result whose identifier is missing or ambiguous, then watch what the system does. The fix I’d verify is that results match on the NHI and that an uncertain match is held for manual review rather than auto-filed by name+DOB. I’d also check the match decision log exists, because without it you cannot investigate a wrong-patient event after the fact.
“What is the National Health Index and why does it matter to a tester?”
The NHI is NZ’s unique identifier for a person receiving health services — the single reliable key that ties a patient to their information across systems. It matters because safe patient identification depends on it: matching on softer fields like name and date of birth is how results get swapped. As a tester I check that the system identifies on the NHI, rejects malformed or invalid identifiers rather than silently accepting them, never invents or defaults one, and treats two NHIs for one person, or one NHI for two people, as serious data-quality defects.