Automated medication reconciliation works by pulling a patient’s medication history from outside the practice and comparing it with the local list, and the outside history comes from three different sources that routinely disagree. Dispensed history from the pharmacy network shows what was actually filled. Payer claims history shows what was billed, which lags and misses cash purchases. The local EHR list shows what was prescribed, which says nothing about whether the patient collected it. Reconciling them is only possible once the patient has been matched confidently across all three, which is why identity verification is a precondition rather than a feature — a history query that returns the wrong person’s medications is worse than returning nothing. In practice, automation retrieves and normalizes the sources, and the clinician still adjudicates the differences, because the systems cannot tell which discrepancy is an error and which is a real change in therapy.
What Is Medication Reconciliation, and Why Is It Hard to Automate?
Medication reconciliation is the process of comparing a patient’s actual medication regimen against what a clinical record shows they’re supposed to be taking, and catching the differences before they cause harm. It matters more than the phrase suggests: the Institute of Medicine estimates up to 1.5 million preventable adverse drug events happen in the U.S. annually, and most medication errors — around 66% — occur specifically at transition-of-care points: admission, transfer, discharge, and outpatient handoffs. It’s hard to automate for a structural reason, not a technical one: there is no single authoritative source for “what a patient is actually taking.” That data lives in three places that don’t agree with each other, which is what the rest of this post is actually about.
Where Does Medication History Actually Come From?
Three distinct sources feed into a real medication history, and confusing them is the most common design mistake in systems that attempt this automatically:
- Dispensed history — from the pharmacy network, showing what was actually filled at a pharmacy counter
- Payer claims history — showing what was billed to insurance, which lags real-time and misses anything paid cash
- The local EHR medication list — showing what was prescribed, which says nothing about whether the patient ever picked it up or is still taking it
Each answers a genuinely different question. None of them alone answers “what is this patient actually taking right now.”
Why the Three Sources Disagree
Prescribed does not equal dispensed does not equal taken, and the gaps between them are real and predictable: a patient who never filled a prescription, a cash purchase that never generates a claims record, a sample handed out in the office that never touches a pharmacy system at all, an over-the-counter medication nobody asked about. Each gap has a different clinical meaning, and none of them is automatically an “error” in the record — some are simply the reality of how patients actually manage their own medications.
Why Identity Verification Comes First
This directly answers the harder half of what people are actually asking when they search for HIPAA-compliant solutions that connect these systems “with identity verification” — and it’s the genuine insight buried in that specific phrasing. None of the reconciliation above means anything until the patient has been matched confidently across all three sources, and patient matching in U.S. healthcare is a real, measured problem, not a theoretical one. Match rates can fall to 50–60% when records are shared across disparate health system EHRs, and industry research has found roughly 18% of patient records within organizations are duplicates — well short of ONC’s own targets for reducing duplication.
A medication history query that confidently returns the wrong person’s medications is a worse outcome than returning nothing at all, because it looks authoritative. That’s why identity verification is a precondition for reconciliation to work safely, not an optional add-on feature layered on afterward.
What Automation Can and Cannot Do
Be honest about the boundary here, because it’s what actually makes a reconciliation tool trustworthy rather than dangerous. Retrieval and normalization — pulling the three sources, matching the patient, presenting the data in a comparable format — is genuinely automatable and where real engineering value gets created. Adjudicating the discrepancies is not: a system cannot reliably tell the difference between a documentation error and a real, intentional change in therapy, and pretending otherwise by silently “resolving” conflicts is how automation causes harm instead of preventing it. Studies of pharmacy-led medication reconciliation have shown it can cut admission-prescribing-error-driven adverse drug events by around 43% — but that’s reconciliation done with a clinician actively adjudicating, not a system quietly auto-merging lists.
Which Standards Carry This Data?
Dispensed history moves over NCPDP standards from the pharmacy network side — the same network I go through in how pharmacy systems connect to clinical records. On the FHIR side, MedicationDispense carries individual fill events and MedicationStatement serves as the consolidated summary across everything ordered, dispensed and administered for a patient over time. A system built to reconcile medications needs both legs — the pharmacy-side retrieval and the FHIR-side representation — working together.
Building This Into a Custom EHR
If you’re building this capability, the sequence that actually works: solve patient identity matching first, connect the pharmacy dispensed-history feed second, and build the clinician-facing adjudication interface last — resist the temptation to build the interface first and bolt identity matching on afterward, because that’s the exact inversion that produces a confident, wrong tool.
Next Steps
Medication reconciliation is a patient-safety feature before it’s a convenience feature, and the engineering has to reflect that — identity verification first, honest adjudication boundaries always. If you’re building this into a custom EHR, talk to our team about sequencing the identity-matching and pharmacy-integration work correctly from day one.
