---
cuppy_hub: aws
cuppy_path: examples/healthcare-master-data/09-interview-brief.md
cuppy_section: docs
cuppy_doc: DDYH-N27X
cuppy_doc_uuid: 66fa42a7-64f7-4be1-91d7-1f515a4ee073
cuppy_permalink: https://cuppy.io/aws/d/DDYH-N27X
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/aws/docs/examples/healthcare-master-data/09-interview-brief
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: f2783c8d17584eaf7d9ceb23f49526f08697cff2f86567c55d756b98d104b3f1
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# Interview brief: the pattern in one page

## The architecture in five sentences

1. Source systems land every payload unchanged in an immutable S3 raw zone with Object Lock, and
   Glue standardises and quality-checks it into a curated zone catalogued in Glue and governed by
   Lake Formation.
2. AWS Entity Resolution matches those curated tables — exact waterfall rules as the primary
   technique, a preset ML model as a second pass — and writes match groups with match IDs to S3.
3. Custom code does what no AWS service does: resolves match IDs to a stable master identifier
   through a crosswalk, replays steward decisions, applies per-attribute survivorship, and writes
   versioned golden records with attribute-level provenance into Aurora PostgreSQL.
4. HealthLake holds the FHIR R4 view for interoperability, with its own deterministic resource
   matching producing FHIR `Linkage` resources, and changes publish to consumers via EventBridge,
   SNS and SQS.
5. It all runs in a multi-account Control Tower landing zone under one AWS business associate
   addendum, with KMS customer managed keys, CloudTrail, the Config HIPAA Security conformance pack
   and Security Hub CSPM.

## Ten likely questions

**1. Why not just buy an MDM product?** Because the component that historically justified the
licence — matching — is now a metered AWS service at $0.25 per 1,000 records. What a licence still
buys is the governance surface: a steward workbench, a survivorship rules editor, lineage. If the
requirement is a resolved data asset for analytics and interoperability with a few expert stewards,
native wins. If the requirement is a business application for many stewards, buy it. I would not
recommend native to an organisation that cannot fund a platform team indefinitely.

**2. Does AWS Entity Resolution give me a golden record?** No. It gives match groups with a match
ID, written to S3. The documentation describes a "consolidated data output table"; it never mentions
survivorship, trust scores or golden records. Survivorship, the master store, the crosswalk and
stewardship are all custom. That is the central honest point of this design.

**3. How do you keep the master identifier stable?** I mint it myself and never expose a match ID
downstream. Entity Resolution does retrieve existing match IDs for records already in a workflow —
`GenerateMatchId` says so, and bulk processing applies "updates to existing matches" — but the
glossary defines the match ID as workflow-run output metadata, and nothing documents that a rebuilt
workflow, a changed rule set or an ML pass produces the same IDs. The only stability sentence, "a
record's match ID is fixed upon its first match", is scoped to transitive matching inside a run. So
the crosswalk — source system, source record id, master id, match id, run — is the authoritative
mapping. I back it up harder than anything else, journal every mutation into the Object Lock raw
zone so it is rebuildable, and derive `master_id` deterministically where the identifiers allow.

**4. Rule-based or ML matching for patients?** Rule-based as primary, because healthcare identity
rests on scoped identifiers like an MRN plus assigning authority, and rule-based matching supports
automatic incremental processing. ML as a periodic second pass for demographic duplicates. Two
caveats I would state: rule-based matching is "designed to find exact matches" on normalised values,
so it does not absorb typos; and the ML model uses name, email, phone, address and date of birth —
no clinical identifier is an input to it.

**5. How does this scale?** The binding constraint is not compute. It is the quota "Concurrent
matching jobs — 1 per Region — Adjustable: No". Four entity types cannot match in parallel in one
account and Region, so I serialise with Step Functions and keep the option of a second resolve
account to lift effective concurrency. The record ceilings are generous and, importantly,
adjustable: 100 million per rule-based workflow, 600 million for ML in the larger Regions. That is
the real shape of the constraint — the volume limits move, the concurrency does not.

**6. Real-time patient lookup at registration?** `GenerateMatchId`, which processes a record against
the workflow's rules, retrieves an existing match ID or generates a new one, and saves results to
S3. It is rule-based only, one record per call, 10 requests per second by default, and each call is
chargeable. Its default `CONSISTENT` mode gives highest accuracy with slower response, which is the
right trade clinically. `GetMatchId` at 50 per second is the cheaper retrieval-only path when the
record is already matched.

**7. Is every service HIPAA eligible?** Every component here is covered by the HIPAA eligible
services reference — most as their own entry, and PrivateLink by inheritance, since it is a
generally available feature of VPC and VPC is listed. Three nuances. The page says "Unless
specifically excluded, generally available features ... are also considered HIPAA eligible", which
is what makes Glue Data Quality eligible without its own line. HealthLake's resource matching is
labelled Preview, which is not generally available — I would raise that with the account team before
routing PHI through it. And RDS carries an engine restriction where Aurora, which I use, does not.

**8. How do you prove compliance to an auditor?** I would start by saying there is nothing to
certify: AWS states "There is no HIPAA certification for a cloud service provider (CSP) such as
AWS". The evidence is the executed BAA from AWS Artifact, the Config conformance pack
`Operational-Best-Practices-for-HIPAA-Security` with its compliance dashboard, Security Hub CSPM
findings, CloudTrail including data events on the PHI buckets in a log archive account the data
accounts cannot write to, and my own attribute-level change history. I would not propose Audit
Manager: AWS's own documentation now states "AWS Audit Manager is no longer open to new customers",
so a new landing zone cannot adopt it. AWS directs customers to Config conformance packs, and both
of its HIPAA frameworks map to `Operational-Best-Practices-for-HIPAA-Security`.

**9. How do you handle de-identification?** As a customer obligation, and I would start by being
precise about terms, because this is where the word is usually misused. A column-filtered analytics
view that still carries `master_id` is pseudonymised PHI, not de-identified data — the code
re-identifies every row against the crosswalk — so it stays inside the BAA and the Data OU's
controls. A genuinely de-identified extract needs the linking code removed or replaced by a
per-extract value whose key is not disclosed, plus suppression, generalisation and date shifting.
For free text, Comprehend Medical's `DetectPHI` detects `NAME`, `AGE`, `DATE`, `ADDRESS`, `ID`,
`PHONE_OR_FAX`, `EMAIL`, `URL` and `PROFESSION`; AWS says it "does cover all the relevant
identifiers" for unstructured text but that those entities "don't map 1:1 to the list specified by
the Safe Harbor method", and recommends human review for compliance use cases. So it is a strong
aid, not a de-identification control. Non-production gets synthetic data only.

**10. What is the disaster recovery story?** AWS Backup covers S3 and Aurora with cross-Region and
cross-account copy, Vault Lock for WORM and a logically air-gapped vault; DynamoDB needs AWS Backup
advanced features to get cross-account copy and an air-gapped vault at all. HealthLake is not listed
on AWS Backup's supported resources, so its recovery is built from scheduled Bulk Data export to
another account plus the ability to rebuild from the raw zone — and I would rehearse the rebuild,
because an untested one is not a plan. RPO for the master is minutes via Aurora continuous backup;
HealthLake's is the export cadence. I would also name availability before being asked: the master
sits on a synchronous clinical path, so it runs an Aurora writer with a reader in a second
Availability Zone, and registration degrades to `GenerateMatchId` plus deferred reconciliation
rather than blocking if the master is unreachable.

## Trade-offs to volunteer unprompted

Raising these before being asked is what distinguishes a designer from a describer.

| Trade-off | What to say |
| --- | --- |
| One matching job per Region | Serialise with Step Functions, or add a resolve account |
| Rule-based exactness | Fast and incremental, but blind to typos; ML covers that, at a cost |
| Aurora Standard vs I/O-Optimized | Standard wins at 500M I/Os; crossover near 650M at this profile |
| Immutability vs retention | Object Lock compliance mode cannot be reversed except by closing the account |
| Link vs merge | Both engines link; keeping duplicates visible is right for clinical safety |
| HealthLake as source or consumer | Both are valid; match first, then write the governed view |
| Macie scope | $1 per GB inspected dominates if unscoped; target landing and extract prefixes |
| Preview features | Architect on GA; pilot Preview on synthetic data |
| Build vs buy for stewardship | The honest reason a licence still sells |

## Numbers to remember

| Fact | Value |
| --- | --- |
| Entity Resolution | $0.25 per 1,000 records processed; no free tier |
| Provider-led matching | $0.10 per 1,000 records, licence required |
| Concurrent matching jobs | 1 per Region, not adjustable |
| Records per rule-based workflow | 100,000,000, and adjustable |
| Records per ML workflow | 600,000,000 in the larger Regions; 150,000,000 in three |
| Maximum data inputs | 20 |
| `GetMatchId` / `GenerateMatchId` | 50 and 10 requests per second |
| ML confidence score range | 0.0 to 1.0 |
| HealthLake data store | $0.27 per hour, about $197 per month |
| HealthLake storage | $0.25 per GB-month Standard, $0.37 Advanced; 10 GB included |
| HealthLake export / NLP | $0.19 per GB; $0.0010 per 100 characters |
| Glue | $0.44 per DPU-hour; Data Quality 2 DPU, 1-minute minimum |
| Glue DQ limits | 2,000 rules and 65 KB per ruleset |
| S3 Standard / Glacier Deep Archive | $0.023 / $0.00099 per GB-month |
| Aurora Serverless v2 | $0.12 per ACU-hour Standard; $0.156 I/O-Optimized |
| Athena | $5 per TB scanned |
| KMS | $1 per key per month; 20,000 requests free |
| Macie | $0.10 per bucket, $0.01 per 100K objects, $1 per GB inspected |
| Audit Manager HIPAA framework | 24 automated, 61 manual controls, 5 control sets |
| Audit Manager | In maintenance mode; closed to new accounts since 30 April 2026 |
| HealthLake linkage cap | A resource sharing an identifier with more than 100 others |
| Worked monthly estimate | About $3,735 at the stated scale; $3,110 initial load |
| Aurora reader for HA | 2 ACU averages about $175 per month |

## Three quotes worth knowing verbatim

1. HealthLake, on resource matching: "so you can build an accurate, unified view without operating a
   master data management system." This is AWS endorsing the pattern.
2. The same page, on its limit: "It does not perform probabilistic or demographic fuzzy matching on
   names, dates of birth, or addresses."
3. AWS on compliance: "There is no HIPAA certification for a cloud service provider (CSP) such as
   AWS."

## Three things NOT to claim

**1. Do not say AWS Entity Resolution produces golden records or does survivorship.** The pages
cited in this set describe match groups, match IDs and a consolidated output table. Golden record,
survivorship, trust score, merge rule and steward appear nowhere. Say: "it gives me match groups and
a match ID; survivorship and the golden record are mine to build."

**2. Do not say HealthLake resource matching is HIPAA eligible for PHI today.** The eligible
services page extends eligibility to *generally available* features. Resource matching is labelled
"available as a preview capability and is subject to change". That is an unresolved question, not a
yes. Say: "HealthLake is a HIPAA eligible service; resource matching is in Preview, so I would
confirm PHI eligibility with the account team before putting production PHI through it." Framing it
as a question you would ask is stronger than an answer either way.

**3. Do not claim a licence saving as a number, and never call a `master_id`-bearing extract
de-identified.** No vendor list price was read for this set, so any comparison figure would be
invented — describe the structural difference (usage-based versus a commitment floor) and say the
comparison needs your own quote. And an analytics extract that carries the master identifier is
pseudonymised PHI; the difference from de-identified data is legal, not stylistic.

Macie is the other one to get right: its documentation scopes the managed data identifiers to
"Amazon Simple Storage Service (Amazon S3) objects", so it is not a scanner for Aurora, DynamoDB,
Redshift or HealthLake.

Two smaller ones in the same spirit: do not cite the "Architecting for HIPAA Security and Compliance
on AWS" whitepaper, which is archived; and do not enumerate the HIPAA Safe Harbor identifier list
from memory — the only figure in this set is AWS's own reference to "a list of 18 identifiers" on
the Comprehend Medical page, alongside its warning that its entities do not map to that list
one-to-one.

## The likely follow-up to question one

"What would you do differently with a bigger budget?" The answer inverts the build-or-buy line
exactly where the economics turn: buy the steward workbench, keep the AWS matching and the lake.
Matching is metered and cheap; the governance surface is the expensive thing to build and the
expensive thing to maintain. Spending on the one component that is months of bespoke PHI-handling
application work, while keeping the parts AWS already meters, is a better allocation than either
extreme.

## If you do not know

Say which page would answer it. "The Entity Resolution quotas page would tell us whether that limit
is adjustable" is a better answer than a guess, and it is the habit this whole document set is built
on. An architect who distinguishes what they verified from what they assume is more trustworthy than
one who sounds certain about everything.


---
<!-- cuppy -->
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.
<!-- /cuppy -->