--- cuppy_hub: aws cuppy_path: examples/healthcare-master-data/00-overview-and-decision.md cuppy_section: docs cuppy_doc: HKST-6FW6 cuppy_doc_uuid: 979f45f3-c317-4990-a7d9-aeb2371d01ca cuppy_permalink: https://cuppy.io/aws/d/HKST-6FW6 cuppy_version: 1 cuppy_updated: 2026-10-23T16:16:52.575Z cuppy_canonical: https://cuppy.io/aws/docs/examples/healthcare-master-data/00-overview-and-decision cuppy_mcp: https://cuppy.io/mcp cuppy_body_sha256: 530e78e8f274f1f7d28e6106533b34a8cd9b30c5b2b535e08c39d5eb3171297f # cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks. --- # Native AWS healthcare master data: the decision 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 | --- You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 131 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/aws/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.