EHR Integration Testing
A patient’s record is not one system — it is many systems passing information to each other. This lesson teaches you to test the joins, where one system’s output becomes another’s clinical input.
1 The Hook
A fictional NZ GP, working at a clinic called Rata Medical, sent an electronic referral to a hospital outpatient service for a patient with a worrying symptom. The GP’s system reported the referral as sent. The GP moved on, reasonably assuming the hospital now had it.
Three months later the patient phoned, still waiting, still unwell. The referral had never reached the hospital’s booking system. It had left the GP system, passed into an integration layer between the two organisations, and stalled there — rejected by the hospital end because a field it required was formatted differently than expected. The rejection went into a technical queue no clinician watched. To the GP, the referral said sent. To the hospital, it had never arrived. To the patient, nothing happened at all.
No single system was broken. The GP system sent. The integration layer received. The hospital system was running. The defect lived in the seam between them — in the assumption that “sent” from one system means “received and actioned” by the next. And no test had ever followed a referral all the way from the GP’s click to a booking actually appearing in the hospital’s system, with the rejection path checked too.
Here is the lesson hidden in that story. The team had tested each system on its own, and each passed. Integration testing is not testing the systems — it is testing the joins between them, end to end, including what happens when one end rejects what the other sent. A referral, a lab result, or a patient identity is only correct when it has arrived, matched the right patient, and become actionable in the receiving system.
2 The Rule
“Sent” is not “received,” and “received” is not “actioned.” In health integration the defects live in the seams between systems, not inside them. Test every join end to end — from the originating click to the information becoming actionable in the receiving system, matched to the right patient — and always test the rejection path, because a referral or result that silently fails to arrive is the most dangerous outcome of all.
3 The Analogy
Sending a tracked courier parcel across the country.
When you hand a parcel to the courier, the receipt says “accepted.” That is not the same as “delivered.” Between the two are handovers — depot to truck, truck to depot, depot to courier — and a parcel can stall at any one of them. A good tracking system shows the parcel at every handover and raises an exception if it gets stuck, so someone can act. A bad one just says “accepted” and goes quiet, and you only find out it never arrived when the recipient phones to ask where it is.
A health integration is that delivery chain. Rata Medical got the “accepted” receipt — the referral said sent — but it stalled at a handover between two organisations, in a queue no one watched, exactly like a parcel stuck at a depot with the exception ignored. An integration tester is the person who tracks the parcel through every handover, confirms it actually arrived and was actioned at the far end, and checks that when it does get stuck, an exception reaches someone who can act — not a silent technical queue.
4 What an EHR Integration Is
An electronic health record is rarely a single application. A patient’s information is spread across a GP practice system, hospital systems, laboratory systems, radiology, pharmacy, and shared regional or national platforms such as Hira. These systems pass information to each other constantly, usually through the HL7 v2 and FHIR mechanisms from Lesson 2, often via an integration engine that routes and sometimes transforms messages between them.
The crucial shift for a tester is where the risk sits. Inside one system, the data is under one team’s control. The moment information crosses a boundary — GP to hospital, lab to GP, any system to a shared platform — two teams’ assumptions meet, and that is where things break. Common boundaries you will test:
- eReferrals: a GP refers a patient to a hospital or specialist service — the Rata Medical case.
- Lab and radiology results: a result generated in one system must land in the ordering clinician’s system, against the right patient.
- Discharge and clinical summaries: a hospital discharge summary flows back to the patient’s GP so care continues.
- Shared-record updates: a local change propagates to a regional or national view, and conflicting updates must resolve sensibly.
- Patient identity: the NHI from Lesson 1 must travel with the information and match the same person on both sides — the thread that ties every integration together.
End-to-end integration testing means picking a real clinical event — a referral, a result — and following it across every boundary from origin to the point where a clinician at the far end can act on it, asserting at each handover that the right information, for the right patient, arrived intact.
5 eReferrals
An eReferral is a structured message that moves a request for care from one provider to another. Testing it well means following it the whole way and exercising the failure paths, not just the success path.
- End-to-end delivery: a referral sent from the GP system actually appears as an actionable item in the receiving service’s worklist — not just “sent” in the GP system. This is the test Rata Medical never had.
- Rejection and acknowledgement: when the receiving end rejects a referral — a missing or malformed field — the rejection is surfaced back to the sender clearly, to someone who will act, not buried in a technical queue.
- Patient identity carried through: the NHI travels with the referral and resolves to the same patient at the hospital. A referral that arrives but attaches to the wrong patient is the Lesson 1 risk reappearing across a boundary.
- Content integrity: the clinical detail, attachments, and priority survive the trip. A referral marked urgent that arrives as routine is a dangerous transformation defect.
- Status feedback loop: the sender can see the referral was received and what happened to it — accepted, declined, triaged — so “sent and forgotten” is not the only possible state.
6 Lab Results
Lab-results integration carries the result from a laboratory system into the ordering clinician’s record, and it combines almost every lesson in this track. The message structure is Lesson 2, the patient identity is Lesson 1, and the delivery seam is this lesson. What to test:
- Right result, right patient: the result lands against the correct NHI in the ordering clinician’s system — the Awa Pathology wrong-patient risk, now across an integration boundary.
- Value integrity: the value, units, and reference range survive intact — the Tui decimal bug from Lesson 2, tested end to end rather than at the message alone.
- Critical-result handling: an abnormal or critical result is not just delivered but flagged so it is noticed; a critical result that arrives silently into a long list is a known clinical hazard.
- Amendments and corrections: a corrected result supersedes the earlier one in the receiving system, rather than sitting alongside a stale value the clinician might read first.
- Unmatched results: a result that cannot be confidently matched to a patient is held and surfaced for review — never auto-filed to a guess, and never silently dropped.
- No silent loss: a result that fails to deliver raises an exception someone monitors — the integration equivalent of the Lesson 1 fail-safe rule.
7 NHI Matching and Record Continuity
Across every integration, the NHI is the thread that keeps a patient’s record continuous as it moves between systems. If the identity breaks at a boundary, everything downstream attaches to the wrong person or floats unmatched. So NHI matching is the most important thing an integration tester checks, and it has subtleties beyond a single-system match.
- Identity survives the boundary: the NHI sent by one system resolves to the same patient in the receiving system, even when other details (an updated address, a changed surname) differ.
- No silent name-and-DOB fallback: when the NHI is missing or does not match, the receiving system holds the item for review rather than guessing by name and date of birth — the cross-system version of the Lesson 1 rule.
- Demographic update propagation: when a patient’s details change in one system, the change reaches the others sensibly, and a stale demographic in one place does not cause a mismatch elsewhere.
- Merge and unmerge: when two records for one person are merged (or a wrongful merge is reversed), the linked results, referrals, and notes follow correctly — a notoriously error-prone operation that can stitch one patient’s data onto another.
- Continuity over time: a patient’s history remains coherent as information accumulates from multiple sources — results, referrals, and discharges all attach to one continuous record, in a sensible order.
8 Building End-to-End Test Cases
An integration test case names the boundaries it crosses, follows a real clinical event from origin to actionable destination, and asserts at each handover — including the rejection path. It does not stop at “sent.”
Here is a worked end-to-end test case for the Rata Medical eReferral:
Boundaries crossed: GP system → integration engine → hospital booking system
Clinical risk: Referral silently fails to arrive (patient never seen)
Pre-conditions: Test patient with a valid NHI in both systems; a referral to send.
Action (success): Send a valid eReferral from the GP system.
Expected (success): 1) Referral leaves the GP system and is logged as sent.
2) It appears as an actionable item in the hospital worklist.
3) It resolves to the correct NHI at the hospital end.
4) Priority (e.g. urgent) is preserved, not downgraded.
5) Status is fed back to the GP (received/triaged).
Action (rejection): Send a referral the hospital end will reject (bad field).
Expected (reject): Rejection is surfaced to a human at the GP end who can act —
not left in a technical queue no clinician watches.
Evidence required: Sent log; hospital worklist entry; resolved NHI; preserved
priority; status feedback; the rejection notification to the GP.
Traceability: Integration risk register IR-09 (referral silent-failure).
Result: [Pass / Fail]
Notice what makes this catch the Hook bug: it names all three boundaries, it asserts the referral becomes actionable at the hospital (stage 2), not just that the GP system said sent, it checks the NHI resolves correctly and the priority survives, and it explicitly tests the rejection path arriving back at a human. The evidence spans both systems and the seam between them — not a screenshot of “sent.”
9 Common Mistakes
🚫 Stopping the test at “sent” in the originating system
Why it happens: The sending system says sent, which feels like success.
The fix: Sent is not received, and received is not actioned — the Rata Medical trap. Follow the event to the point where a clinician at the far end can act on it, asserting it arrived, matched the right patient, and became an actionable item.
🚫 Never testing the rejection path
Why it happens: The happy path is the obvious scenario and rejections feel like an edge case.
The fix: Silent rejection is the most dangerous outcome — a referral that fails into an unwatched queue is invisible until a patient phones. Deliberately send something the far end rejects and prove the rejection reaches a human who can act.
🚫 Testing each system in isolation and assuming the join works
Why it happens: Each system passes its own tests, so the integration feels covered.
The fix: The defects live in the seams, not the systems — two teams’ assumptions meeting at a boundary. Test the join end to end, across every handover, because a referral can leave one system cleanly and stall in the layer between.
🚫 Letting patient identity break at the boundary
Why it happens: Within one system the NHI is reliable, so cross-system matching is assumed safe.
The fix: Identity is where cross-system harm concentrates — a result or referral that arrives but attaches to the wrong patient, or a merge that grafts one patient’s data onto another. Assert the NHI resolves to the same person on both sides, and test merges and unmerges hard.
10 Now You Try
Three graded exercises across eReferrals, lab results, and NHI continuity. Write your answer, run it for AI feedback, then compare to the model answer.
Read the description of a fictional NZ GP-to-hospital eReferral integration below. Identify 3 integration risks that could cause a referral to fail silently, reach the wrong patient, or arrive wrong, and name the safer behaviour each needs.
When a GP sends a referral, their system marks it “sent” as soon as it leaves. If the hospital’s system rejects it, the rejection goes into a technical error queue that the integration team checks weekly. The hospital matches the incoming referral to a patient by name and date of birth if the NHI is missing. Referral priority is mapped between the two systems by a lookup table that has no entry for the GP system’s “urgent” value, so those default to “routine”.
List 3 integration 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. "Sent" with a weekly-checked rejection queue — the GP sees "sent" while a rejection sits up to a week in a technical queue no clinician watches. Safer behaviour: surface rejections back to a human at the GP end promptly; do not treat "sent" as "received". Consequence: a referral fails silently and the patient waits, unseen (the Rata Medical failure). 2. Name+DOB fallback on missing NHI — the hospital guesses the patient by name and date of birth when the NHI is absent. Safer behaviour: hold unmatched referrals for review; never auto-match by name+DOB. Consequence: the referral attaches to the wrong patient. 3. Priority downgraded by a gap in the lookup — "urgent" has no mapping entry, so urgent referrals default to "routine". Safer behaviour: fail safe on an unmapped value (reject/flag, or escalate), never silently downgrade priority. Consequence: an urgent patient is triaged as routine and waits far too long. Bonus: no status feedback loop — the GP cannot see whether the referral was received or triaged. Safer behaviour: feed status back to the sender so "sent and forgotten" is not the only state. The trap: each of these passes a "the referral was sent" test, because sending works.
The integration test case below stops at “sent” and tests only one system. Rewrite it as an end-to-end test, with these fields: Test ID, Boundaries crossed, Clinical risk, Pre-conditions, Action (success), Expected (success), Action (rejection), Expected (rejection), Evidence required, Traceability. Use a fictional lab-result delivery from a lab to a GP system as the context.
“Send a result from the lab system. Check the lab system says it was sent. Pass if it says sent.”
Rewrite as an end-to-end integration test case:
Show model answer
Test ID: EHR-LAB-017 Boundaries crossed: Lab system → integration engine → GP system Clinical risk: Result lost, mis-matched, or corrupted across the boundary (wrong/missing result to clinician) Pre-conditions: Test patient with a valid NHI in both systems; a result (with a decimal value) to send. Action (success): Send a valid lab result for the patient from the lab system; let the integration run. Expected (success): 1) Result leaves the lab system. 2) It lands in the ordering clinician's GP record. 3) It resolves to the correct NHI. 4) Value, units, and reference range are intact (e.g. 14.5, not 145). 5) A critical/abnormal result is flagged, not just delivered into a list. Action (rejection): Send a result whose NHI is missing/ambiguous, and one the GP system will reject. Expected (rejection): The unmatched result is held for review, not auto-filed by name+DOB; a delivery failure raises an exception someone monitors — nothing is silently dropped. Evidence required: Lab send log; GP record entry with the stored value/units/range; resolved NHI; the abnormal flag; the held-for-review/unmatched queue entry; the exception for the failed delivery. Traceability: Integration risk register IR-06 (lab result silent loss) and IR-02 (value corruption across boundary). What makes it strong: it crosses all the boundaries, asserts the result becomes part of the correct patient's record (not just "sent"), checks value integrity end to end, flags critical results, and tests the unmatched and rejection paths — none of which the original touched.
Design an NHI continuity test plan of 5 test cases for a fictional NZ shared-record platform receiving updates from GP, hospital, and lab systems. Each case needs at least: an ID, what it verifies, an acceptance criterion, and the evidence required. Cover identity surviving a boundary, a missing/mismatched NHI, a demographic update propagating, a record merge, and a record unmerge.
Show model answer
CONT-01 | Verifies: NHI identity survives a system boundary | Acceptance criteria: an item sent with a valid NHI resolves to the same patient on the receiving platform even when other demographics differ | Evidence required: source NHI; resolved patient on the platform; the differing demographics that did not break the match CONT-02 | Verifies: a missing/mismatched NHI is not guessed | Acceptance criteria: when the NHI is absent or does not match, the item is held for review; 0 name+DOB auto-matches | Evidence required: the no/bad-NHI input; the held-for-review entry; confirmation no record was guessed CONT-03 | Verifies: a demographic update propagates correctly | Acceptance criteria: a change (e.g. address or surname) in one system reaches the shared platform without causing a mismatch elsewhere; the NHI link is preserved | Evidence required: before/after demographics; the propagated update; confirmation the identity link held CONT-04 | Verifies: a record merge moves linked artefacts to the right patient | Acceptance criteria: merging two records for one person attaches all linked results/referrals/notes to the correct single patient; 0 artefacts orphaned or mis-attached | Evidence required: pre-merge records; post-merge linked artefacts; the merge log CONT-05 | Verifies: a record unmerge cleanly reverses a wrongful merge | Acceptance criteria: an unmerge restores each patient's own artefacts to their record with nothing left on the wrong patient | Evidence required: the wrongful merge state; the post-unmerge records; confirmation each artefact returned to the correct patient Strong plans: each case is specific, has a measurable criterion, names concrete evidence, and together they cover identity across a boundary, missing/mismatched NHI, demographic propagation, merge, and unmerge. Weak plans say "check NHI continuity works" five times — that is the difference being marked.
11 Self-Check
Click each question to reveal the answer.
Q1: Why is “sent” not enough to prove an eReferral works?
Because sent is not received, and received is not actioned. The Rata Medical referral said sent but stalled in the seam between two organisations and never became an actionable item at the hospital. You must follow the event end to end, to the point where a clinician at the far end can act on it, matched to the right patient.
Q2: Where do health-integration defects mostly live, and what follows for testing?
In the seams between systems, not inside them — where two teams’ assumptions meet at a boundary. It follows that testing each system in isolation is not enough; you must test the join end to end across every handover, because information can leave one system cleanly and stall in the layer between.
Q3: Why is the rejection path the most important one to test?
Because a silent rejection is the most dangerous outcome — a referral or result that fails into an unwatched technical queue is invisible until a patient phones, months later. Deliberately send something the far end rejects and prove the rejection comes back to a human at the sending end who can act on it.
Q4: Why is NHI matching the thread that ties every integration together?
Because the NHI keeps a patient’s record continuous as it moves between systems. If identity breaks at a boundary, everything downstream attaches to the wrong person or floats unmatched. Assert the NHI sent by one system resolves to the same patient in the next, and never let the receiver fall back to guessing by name and date of birth.
Q5: Why are record merges a high-risk operation to test?
Because a merge can graft one patient’s results, referrals, and notes onto another patient’s record permanently — some of the worst cross-system corruption there is. Test merges hard, including the unmerge that must cleanly reverse a wrongful merge, and verify every linked artefact follows the correct patient.
12 Interview Prep
Real questions asked in NZ QA interviews for health-integration roles. Read the model answers, then practise your own version.
“How would you test an eReferral integration from a GP to a hospital?”
End to end, never stopping at “sent.” I follow the referral from the GP’s click, through the integration engine, into the hospital system, and assert it becomes an actionable item on the hospital worklist — not just that the GP system logged it as sent. I check the NHI resolves to the same patient at the hospital, that priority like “urgent” survives and is not downgraded, and that status feeds back to the GP. Then I test the rejection path deliberately, because that is where patients get lost: I send something the hospital end rejects and prove the rejection reaches a human at the GP end, not a technical queue no one watches. That last test is exactly the one whose absence makes patients wait months.
“A GP referral was marked sent but the patient never got an appointment. How do you investigate?”
My first hypothesis is a silent failure in the seam — the referral left the GP system but stalled in the integration layer or was rejected by the hospital end into an unmonitored queue. I’d trace the referral across every boundary: did it leave the GP system, did the integration engine receive and route it, did it arrive and become actionable at the hospital, and was there a rejection sitting somewhere unwatched. The fix I’d verify is that “sent” is tracked through to “received and actioned,” that rejections surface to a human who can act, and that the GP gets status feedback. I’d also check the NHI resolved correctly, in case it arrived but attached to the wrong patient.
“What makes patient identity hard to get right across integrated systems?”
Within one system the NHI is reliable, but at a boundary two systems’ views of the same person meet, and they can disagree — a missing NHI, a stale demographic, an updated surname. The danger is a receiver that falls back to matching by name and date of birth when the NHI does not match, which is how a result or referral attaches to the wrong patient. The hardest case is record merges, where a mistaken merge can graft one patient’s data permanently onto another. So I assert the NHI resolves to the same person on both sides, hold unmatched items for review rather than guessing, and test merges and unmerges hard, verifying every linked artefact follows the right patient.