A healthcare master data management capability keeps one trustworthy record per patient, provider, organisation and location, across every system that writes about them. Commercial MDM platforms package that capability and license it. This document set describes assembling it from AWS services instead, and is honest about which parts AWS supplies and which parts become your code.

All AWS claims in this set are quoted from the pages in each document's provenance, read on 2026-10-21. Where documentation does not support a claim, the text says so.

The capability model

Treat MDM as nine capabilities rather than one product. The decision is not "build or buy MDM"; it is "which of these nine do AWS services already cover".

Capability	AWS coverage	Nature of the gap
Ingestion and standardisation	Strong	Glue, Lambda, Kinesis, MSK; normal pipeline work
Data quality measurement	Strong	Glue Data Quality with DQDL rules and scores
Identity resolution — matching	Strong	AWS Entity Resolution; HealthLake resource matching
Survivorship and golden record	None found	Entirely custom; see document 02
Master identifier and crosswalk	None found	Entirely custom; the sharpest gap
Stewardship workflow and UI	None found	A full application to build
Lineage and audit	Partial	CloudTrail and Lake Formation audit; attribute lineage custom
Publish and subscribe	Partial	EventBridge, SNS, SQS; HealthLake FHIR Subscriptions
Interoperability — FHIR	Strong	HealthLake is a managed FHIR R4 store

Four of nine are strong, two are partial, three have no managed equivalent found in the cited pages. That ratio is the whole decision in one line: AWS gives you the engine and the plumbing; the governance surface is yours.

What AWS actually supplies for matching

Two managed capabilities, and both are explicit that they link rather than merge.

AWS Entity Resolution "helps you match, link, and enhance related records stored across multiple applications, channels, and data stores", with "rule-based matching, machine learning-based matching (ML matching), and data service provider-led matching". Its output is match groups carrying a match ID, written to S3.

HealthLake resource matching is more pointed, and this sentence is the best single piece of evidence that the pattern is a legitimate one rather than a workaround:

"When aggregating data from multiple systems, resource matching connects the same entity written as several separate resources so you can build an accurate, unified view without operating a master data management system."

AWS says the quiet part itself. It also constrains itself in the same breath — "Resource matching is non-destructive", and "It does not perform probabilistic or demographic fuzzy matching on names, dates of birth, or addresses" — and the feature is labelled Preview on the cited page, which has compliance consequences set out in document 04.

Why native is a defensible choice

Licence structure versus usage. A licensed MDM platform is normally bought as a subscription sized to records, entities, cores or users, and that commitment is made before the first match runs and renews whether volume grows or not. The AWS components bill on dimensions you can compute: Entity Resolution is listed at $0.25 per 1,000 records processed; Glue at $0.44 per DPU-hour; S3 at $0.023 per GB-month in US East (N. Virginia). Glue Data Quality's own documentation makes the contrast explicitly: "There are no annual licenses you need to use AWS Glue Data Quality." Document 07 works a monthly estimate from these figures.

No separate compliance envelope. Every component named in this set appears on the AWS HIPAA eligible services page. There is one BAA and one audit boundary rather than a vendor's compliance posture to assess alongside AWS's. The page's own words: you "agree not to use these HIPAA Eligible Services for any purpose or in any manner involving Protected Health Information ... without first entering into an AWS business associate agreement."

PHI does not leave the Region, and never reaches a third party. Entity Resolution "supports Regionalization, which means that your matching workflows run to process your data in the same AWS Region from where you're using the service", reads Glue tables you own and writes a bucket you own. Regionalization is a statement about Region rather than account, and Entity Resolution is an AWS-operated managed service — the claim worth making is that no PHI is copied to a vendor-operated tenancy. Provider-led matching would change that, and this design does not use it.

The data stays in open formats. The master is a database and a set of S3 objects you can query with Athena. Extraction from a proprietary MDM repository is a project; here there is nothing to extract from.

Elasticity matches the workload. Matching is bursty — a large initial load, then deltas. Paying per record processed and per DPU-second fits that shape better than a fixed licence.

When native is the wrong call

This matters more than the case for it.

When you need a steward workbench next quarter. The single largest gap is the data steward application: a candidate-match queue, side-by-side comparison, attribute-level override, merge and unmerge, and a per-decision audit trail. A licensed product ships this on day one. Building it is months, and it is a PHI-handling application with its own authentication, authorisation and audit obligations. If stewardship is the immediate requirement, buy it.

When survivorship is politically complex. If twelve departments must negotiate per-attribute precedence, a product with a mature rules editor and simulation tooling earns its licence. A rules table you wrote is harder to govern across that many stakeholders.

When fuzzy matching on clinical identifiers is the core requirement. Entity Resolution's rule-based matching is "designed to find exact matches", and its ML model uses name, email, phone, address and date of birth. Neither does approximate matching on an MRN or member number. Specialist patient-matching vendors invest heavily there.

When you have no platform team. This pattern is roughly a dozen services wired together. That is an operating commitment — on-call, upgrades, quota management, cost review — not a one-off build. A licence can be cheaper than the headcount.

When regulatory validation is required. If an auditor requires validated vendor software, your own code carries a validation burden you must fund. Note also that AWS itself states "There is no HIPAA certification for a cloud service provider (CSP) such as AWS", so eligibility is a contractual and architectural property, never a certificate you can show.

When time to first value dominates. A licensed product can show matched patients in weeks. This pattern reaches an equivalent demonstration in weeks too, but reaches a governable master much later, because the governance surface is the part you are building.

The honest summary

The right framing is not "native MDM is cheaper". It is: AWS has productised the hardest algorithmic component and none of the operational ones. Matching — the part that historically justified the licence — is now a metered service. Survivorship, crosswalk and stewardship are not, and they are where most of a licence's remaining value lives.

So the pattern is strong when the requirement is a trustworthy resolved data asset feeding analytics, interoperability and downstream systems, with a small number of expert stewards. It is weak when the requirement is a business application for many stewards with rich governance workflow out of the box.

How to read the rest of this set

Document	What it settles
01 reference architecture	The end-to-end flow and every service's role
02 identity resolution	What the matchers do, verbatim, and where custom code starts
03 data model and FHIR	HealthLake, FHIR R4, and the master entity model
04 security and HIPAA	BAA, eligibility, encryption, audit, break-glass
05 stewardship and quality	Glue Data Quality, and the steward application gap
06 operations	Throughput, idempotency, reprocessing, backup, DR
07 cost model	A worked estimate with every assumption stated
08 gaps register	All 24 gaps with severity and effort
09 interview brief	The study sheet, and three things not to claim