AWS for Industries
Resolve duplicate health records with AWS HealthLake
Duplicate records remain one of the costliest challenges in healthcare data management. Studies estimate that 10–20% of patient records in a typical health system are duplicates created through misspellings, name changes, data entry errors, or patients presenting at different facilities within a network. The same fragmentation affects the providers, organizations, locations, and medical devices that are referenced in clinical data.
The consequences are far-reaching. Incomplete medical histories make it harder for clinicians to identify potential drug interactions, avoid redundant procedures, or identify gaps in a patient’s care journey. From an operational standpoint, duplicates inflate costs through billing errors and manual reconciliation efforts that consume valuable staff time. At scale, fragmented patient identities undermine population health analytics, quality measure reporting, and the very interoperability goals that Fast Healthcare Interoperability Resources (FHIR)-based solutions are designed to achieve.
For organizations building longitudinal patient records from multiple sources like Electronic Health Records (EHRs), Health Information Systems (HIEs), claims systems, and connected devices. Resolving these duplicate identities is essential when new data feeds risk introducing another representation of the same real-world entity. But resolution is difficult to get right. Identifiers carry different meanings depending on who issued them (the same medical record number can belong to two different patients at two different hospitals), sources write the same identifier under different naming conventions, and every new record can introduce new duplicates. Until now, solving this has meant deploying a separate master data management (MDM) or enterprise master patient index (EMPI) system alongside your clinical data store.
Introducing resource matching for AWS HealthLake
We are excited to announce resource matching for AWS HealthLake, now available in gated preview. Resource matching is a built-in capability that automatically identifies FHIR resources representing the same real-world entity and links them without modifying or merging the original data.
Resource matching works across seven FHIR R4 resource types: Patient, RelatedPerson, Practitioner, PractitionerRole, Organization, Location, and Device, so you can build an accurate, unified view of patients, providers, and the entities they reference without operating a separate master data management system.
Resource matching is non-destructive; when it finds a match, it creates an FHIR Linkage resource that points to the linked resources and leaves the originals unchanged. It links resources based on the healthcare identifiers present in your data; it doesn’t yet perform probabilistic or demographic fuzzy matching on names, dates of birth, or addresses.
How it works
When enabled on your datastore, every resource written through a bulk import job or a REST API (create, update, or delete) is automatically evaluated against the other resources of the same type in your datastore. Matching is deterministic: two resources are linked when they share a high-confidence healthcare identifier, matched according to its real-world scope:
- Globally unique identifiers – Identifiers such as a Social Security Number (SSN) or National Provider Identifier (NPI) that refer to the same entity regardless of the issuing system and are matched on value.
- Scoped identifiers – Identifiers such as a medical record number (MRN), driver’s license, or device serial number that are only unique within a namespace (such as a hospital, state, or manufacturer) and are matched on the combination of system and value. This ensures MRN 456 at one hospital is never linked to MRN 456 at another.
Resource matching also recognizes when the same identifier appears under different system URIs (for example, an SSN written under http://hl7.org/fhir/sid/us-ssn and under urn:oid:2.16.840.1.113883.4.1), so records from sources with different URI conventions still match. It automatically ignores placeholder values such as all-zero strings, common placeholders (unknown, n/a, test), and values shorter than three characters.
Each resource type matches on a specific set of identifiers including SSN, MRN, driver’s license, and Medicare MBI for patients; NPI, DEA, and medical license number for practitioners; and NPI, EIN, CLIA, and CCN for organizations. For the full per-type identifier tables, see matching duplicate FHIR resources documentation in the HealthLake developer guide.
Matching runs asynchronously after a resource is written and is eventually consistent.
Enable resource matching
Resource matching is available in gated preview. To enable it for your datastore during the preview period, request to be added to the resource matching preview allowlist. When this feature becomes generally available, you will be able to enable it directly through the UpdateDataStore API and the AWS Management Console for HealthLake.
Note that resource matching isn’t applied retroactively: if you disable and later re-enable resource matching, only resources written while it is enabled are evaluated.
The FHIR Linkage resource
When resource matching finds a match, it creates an FHIR Linkage resource that references the matched resources. It uses a grouped model: all resources determined to be the same entity are collected into a single linkage with one source item (the oldest resource, by meta.lastUpdated) and one or more alternate items. Each system-generated linkage is tagged as SYSTEM_GENERATED, so you can distinguish it from Linkage resources you create yourself, and it records how the match was made in its extensions—the match tier and the specific identifier (system|value) that caused each set of resources to be linked.
The following example shows a Linkage grouping three Patient resources: patient-A and patient-B share an SSN, and patient-A and patient-C share a hospital MRN:
{
"resourceType": "Linkage",
"id": "linkage-001",
"active": true,
"meta": {
"tag": [
{ "system": "http://healthlake.amazonaws.com/linkage-source", "code": "aws-healthlake" },
{ "display": "SYSTEM_GENERATED" }
]
},
"extension": [
{
"url": "http://healthlake.amazonaws.com/linkage-match-tier",
"valueCode": "identifier"
},
{
"url": "http://healthlake.amazonaws.com/linkage-match-detail",
"extension": [
{ "url": "identifier", "valueString": "http://hl7.org/fhir/sid/us-ssn|123-45-6789" },
{ "url": "linked-resource", "valueReference": { "reference": "Patient/patient-A" } },
{ "url": "linked-resource", "valueReference": { "reference": "Patient/patient-B" } }
]
},
{
"url": "http://healthlake.amazonaws.com/linkage-match-detail",
"extension": [
{ "url": "identifier", "valueString": "http://hospital-a.org/mrn|MRN-456" },
{ "url": "linked-resource", "valueReference": { "reference": "Patient/patient-A" } },
{ "url": "linked-resource", "valueReference": { "reference": "Patient/patient-C" } }
]
}
],
"item": [
{ "type": "source", "resource": { "reference": "Patient/patient-A" } },
{ "type": "alternate", "resource": { "reference": "Patient/patient-B" } },
{ "type": "alternate", "resource": { "reference": "Patient/patient-C" } }
]
}You remain in control of reconciling the linked records, your original data is never combined or replaced. As data changes, links are maintained automatically: groups join, merge, and split as resources are created, updated, and deleted, and superseded groupings are retained with active set to false so their history stays queryable.
Querying linked data
Because a matched entity is stored as multiple resources connected by a linkage, you retrieve linked data with standard FHIR R4 search. To get everything linked to a patient, find the patient’s linkage and include the linked resources in the same bundle:
GET /Linkage?item=Patient/patient-A&_include=Linkage:itemTo separate current links from historical ones, filter on the active search parameter (active=true for current groupings, active=false for superseded ones).
How this helps solve healthcare data challenges
Resource matching in HealthLake addresses critical use cases across the healthcare data lifecycle.
Unified longitudinal records
When data flows into HealthLake from multiple sources—hospital EHRs, ambulatory clinics, labs, and payers—matching helps ensure that a single patient’s complete history is accessible through linked records, giving clinicians a holistic view without manual chart reconciliation.
Improved analytics
Duplicate records skew cohort analyses, inflate disease prevalence calculations, and distort quality metrics. By linking duplicates at the data layer, organizations can trust that their analytics reflect true patient populations; enabling more accurate risk stratification, care gap identification, and outcomes measurement. It also means that you can use HealthLake as the primary data foundation layer for future AI and agentic capabilities you might choose to build from this data.
Streamlined interoperability
As health systems participate in information exchanges and respond to payer data requests under CMS interoperability rules, linked patient records reduce the friction of matching and responding with complete, deduplicated data sets.
Reduced operational burden
Manual reconciliation, whether performed by Health Information Management (HIM) staff or through third-party Master Patient Index (MPI) solutions, is resource-intensive and time consuming. The matching built into HealthLake reduces this burden by continuously maintaining linkages as data arrives, without additional tooling or workflows.
Resource matching pairs naturally with AWS HealthLake data transformation. After legacy data is converted to FHIR and lands in your datastore, matching links the duplicate identities that inevitably arrive across multiple source systems.
Conclusion
Resource matching for AWS HealthLake brings an essential data quality capability directly into your FHIR datastore with no additional infrastructure and complex configurations required.
The feature is fully automatic: enable it once, and every subsequent resource that is created, updated, or deleted is evaluated and linked when matches are found. Whether you’re ingesting data from a single EHR or aggregating records across an entire health network, HealthLake now helps ensure that each real-world entity is represented as a single, linked identity across all seven supported resource types.
Ready to get started? Resource matching is available in gated preview. Request access to enable it on your HealthLake datastore and begin building a cleaner, more reliable and scalable clinical data foundation.
Further reading: