Every organisation that runs more than one system eventually holds the same person several times over. A referral arrives with a shortened first name and no date of birth. The patient administration system has them at their old address. The billing system has a typo from a phone booking in 2019. Someone in reception creates a new record because search returned nothing useful, and now there are four.
This post is part of the Practical AI in Health series, and it covers the least glamorous work in the whole series: getting records to agree on who a person is before you build anything on top of them.
Matching is an accreditation obligation, not just data hygiene
NSQHS Standard 6 requires health service organisations to use at least three approved patient identifiers at registration, at every point of care, and on handover, transfer and discharge documents. Room number, bed number and diagnosis are explicitly not approved identifiers. Action 6.6 goes further and requires organisations to document the processes used to match patients to their intended care (ACSQHC).
That last point changes the engineering. Your matching design is an artefact an assessor can ask to see. If the answer is "the vendor's algorithm does it", you have a documentation problem as well as a data problem.
Start with the identifiers that actually hold
The Individual Healthcare Identifier is a 16-digit number assigned automatically to everyone enrolled in Medicare or with DVA, and it stays with the person for life. A Medicare number does not. A person can hold several over a lifetime, which is exactly why so many systems that keyed on it have duplicates (Australian Digital Health Agency).
The IHI is not a free pass either. The ADHA's National Healthcare Identifiers Roadmap 2023-2028 names the defects it is working through, including retired IHI records turning up in search results, failed message searches, identifier status flags that do not do their job, and poor matching outcomes for Aboriginal and Torres Strait Islander peoples. Design as though a returned identifier can be stale.
The deterministic layer does most of the work
Most duplicate pairs are boring and resolvable by rules. Normalise first, then block, then compare. Something like this, running inside the integration layer rather than in any one source system:
// 1. Trusted identifier match: auto-resolve, no review needed.
if (HasValue(a.Ihi) && a.Ihi == b.Ihi && a.IhiStatus == Active) return Verdict.Merge;
// 2. Normalised composite: strip punctuation, fold case, standardise
// address via a locality/postcode lookup, keep nickname expansions.
var ka = Key(a); var kb = Key(b); // (soundex(family), dob, postcode)
if (ka == kb && SimilarGiven(a, b) > 0.9) return Verdict.Merge;
// 3. Everything scoring between the thresholds goes to the grey-zone queue.
var score = Weighted(a, b);
return score >= AutoThreshold ? Verdict.Merge
: score <= RejectThreshold ? Verdict.Distinct
: Verdict.Review;
Tune the thresholds so the deterministic layer never merges on a guess. That leaves a queue, and the queue is where the interesting work sits.
What the grey zone looks like
A published comparison of real matching approaches gives useful numbers. Probabilistic matching returned sensitivity of 0.6366 with positive predictive value of 0.9995. Referential matching returned 0.9351 sensitivity at 0.9996 PPV (Grannis et al., JAMIA 2022). Read those two columns together. Tuned matching almost never merges two different people. What it does is miss matches, and a third of them in the probabilistic case.
Missed matches are duplicates. Duplicates mean a clinician sees part of a history, a recall letter goes to one record and not the other, and your reporting counts one person as two.
Where an LLM earns its place
The candidate pairs that survive the deterministic layer are usually hard for a reason a human can articulate. Transposed given and family names in a culturally diverse patient base. A married name in one system and a maiden name in another with the same date of birth. Two siblings at one address with dates of birth six days apart in different years. A mononymous person whose single name the source system split across two fields, which the HL7 identity matching guidance says should be submitted in the last-name field (HL7 Interoperable Digital Identity and Patient Matching IG).
An LLM is good at exactly this narrow adjudication: read two records, weigh the evidence, and explain the reasoning in a sentence a reviewer can accept or reject. Current research is worth reading before you build it, because the framing of the task changes the results as much as the choice of model. Pairwise match, comparison and selection formulations all perform differently (Wang et al., COLING 2025).
Two design requirements we treat as non-negotiable. The model never writes a merge. It ranks the queue and drafts the justification, and a named human approves each merge, with the decision and the reasoning stored against the golden record. And every merge is reversible, because you will be unmerging some of them.
Field completeness beats algorithm choice
The AIHW's COVID-19 linked data set achieved over 90 per cent linkage in every jurisdiction, with Tasmania highest at 99 per cent and Victoria carrying the largest volume at 2,536,790 individuals. The Northern Territory lagged, and the stated reason was limited address information (AIHW). No model fixes an empty field.
The same analysis found people aged 70 and over had the highest proportion of unlinked records at 9.9 per cent, and linkage fell where sex was recorded inconsistently or as 'Other'. Matching failure lands unevenly on older patients and on people whose demographics do not fit a two-value field. Report your match rates by cohort, not just in aggregate, or you will never see it.
The integration architecture
We build this as a layer beside the source systems, not inside them, using Centazio, our MIT-licensed C# integration and master data platform.
- Sources publish changes into Centazio, which handles fault tolerance and near real time delivery into a central database.
- Records land in a canonical Patient shape. AU Core v1.0.0, built on FHIR R4 by the CSIRO-led Sparked accelerator, is the sensible target. Note its limits: Patient carries historical names and addresses but only a single birthDate.
- Deterministic rules run on write, producing merges, rejections and a review queue.
- The LLM adjudicator scores and explains the queue. Humans decide.
- The golden record keeps every source identifier as a cross reference, so nothing is destroyed and every merge can be walked back.
- Serve matches out via the FHIR
Patient/$matchoperation, which returns a scored bundle with a match grade. The base specification deliberately mandates no algorithm and no minimum input data set, so the accuracy is entirely yours to own and document.
Centazio came out of this kind of work. At the Cruising Yacht Club of Australia an initial cross-system reporting dashboard turned into a five-year transformation plan with the systems integrated through Centazio, and it runs in similar integration roles for clients including Guide Dogs NSW/ACT.
Costs, limits and the compliance clock
Token cost is not the expensive part, because the LLM only sees the grey zone and the grey zone is small. Reviewer time is the real budget line, so size the queue before you promise anyone a timeline. Expect a heavy first pass on historical data and a much lighter steady state.
There is also a date to plan for. The Privacy and Other Legislation Amendment Act 2024 inserts APP 1.7, requiring privacy policies to disclose automated decision making that affects people's rights or interests, commencing 10 December 2026, with infringement notices of up to $66,000 per contravention (MinterEllison). An AI-assisted decision about whether two records are the same person sits inside that.
Leaving the duplicates alone is not the safe option either. Health service providers were the most notified sector in the OAIC's 2025 breach statistics with 225 notifications, 19 per cent of a record 1,205 total, and human error drove 37 per cent of breaches in the January to June period (OAIC). Fragmented records mean more places to send the wrong document to the wrong person.
Start by measuring. Run your deterministic rules over a copy of production, count the auto-merges, count the grey zone, and have two experienced staff review a sample of 200 pairs. That gives you a baseline, a queue size and a training set, and it takes a couple of weeks rather than a couple of quarters.
PicNet builds production AI systems for Australian organisations. Talk to us about what a first project could look like.
Originally published at picnet.com.au.
Top comments (0)