GenAI on AWS for healthcare: HIPAA, PHI, and an architecture that holds up.
Amazon Bedrock is a HIPAA-eligible service, so you can build healthcare GenAI on it with protected health information (PHI). First sign the AWS Business Associate Addendum (BAA) and keep PHI inside HIPAA-eligible services. Then encrypt with KMS, keep traffic private with PrivateLink, redact PHI with Guardrails, log everything and keep a clinician in the loop.
- You can build GenAI for healthcare on AWS, but PHI changes the rules. You need a signed AWS BAA, PHI only in HIPAA-eligible services (Bedrock is one), and an architecture that encrypts, isolates and logs PHI. The platform being eligible does not make your application compliant. Your design does.
- AWS says data you send to Bedrock is not used to improve the base models and is not shared with model providers. A Bedrock Guardrail can detect and redact PII and PHI in prompts and responses. Add customer-managed KMS keys, PrivateLink, least-privilege IAM and CloudTrail, and you have a PHI boundary you can defend in a security review.
- The architecture depends on the use case: documentation summarization, patient intake and medical-coding assist each expose PHI differently. Where a use case does not need identifiers, de-identify first (Safe Harbor or Expert Determination; Amazon Comprehend Medical can detect PHI at scale).
- Funding: if the build qualifies, a vetted AWS partner can file POC funding for a test, or incremental workload (IW) funding if you already run on AWS. For startups this is typically $50K to $150K. Depends on the workload; AWS approves. You apply for Activate credits yourself.
IHIPAA on AWS: the BAA, eligible services and shared responsibility
Healthcare GenAI on AWS rests on three facts. You need a signed BAA. PHI may only go through HIPAA-eligible services. And AWS securing the cloud does not make your application compliant.
HIPAA governs how protected health information (PHI) is used, stored, sent and disclosed. PHI is health information tied to an identifiable person. If your application touches PHI and you are a covered entity (a provider, health plan or clearinghouse) or a business associate of one, HIPAA applies to the whole application, including its GenAI parts.
First, sign the AWS Business Associate Addendum (BAA). In it, AWS agrees to act as your business associate and safeguard PHI under HIPAA. You can accept it in AWS Artifact, for one account or for your AWS Organization. Without a signed BAA, do not put PHI on AWS at all.
Second, the BAA only covers HIPAA-eligible services. Amazon Bedrock is on the list, as are the services you build around it: Amazon S3, AWS KMS, Lambda, ECS and EKS, API Gateway, CloudWatch, CloudTrail and Amazon Comprehend Medical, among others. One non-eligible service in the PHI path (an analytics tool, a logging sink, a third-party SaaS) breaks the boundary. The list changes, so check the HIPAA-eligible services reference before you finalize a design.
Third, HIPAA on AWS is shared responsibility. AWS secures the infrastructure and the eligible services. You secure what you build: encryption, IAM, networking, logging, retention, and what PHI you send to a model. "Bedrock is HIPAA-eligible" describes the AWS half. The rest of this guide is your half.
Before PHI touches a model on AWS: (1) a signed AWS BAA, (2) every service in the PHI path is HIPAA-eligible, and (3) your half of shared responsibility is designed: encryption, IAM, network isolation, logging and retention.
IIHow PHI is handled on Bedrock
Four properties make Bedrock a credible place for healthcare GenAI. Your data does not train the models. It is encrypted. It can stay off the public internet. And a Guardrail can redact PHI before anyone sees it.
Your data does not improve the base models
AWS says data you send to Bedrock is not used to improve the base models and is not shared with model providers such as Anthropic, Meta or Mistral. Model providers have no access to Bedrock logs or to your prompts and completions. A model you customize on Bedrock is private to your account. This is why clinical text can go to Bedrock when it could never go to a consumer chatbot. Confirm it on the Bedrock security and compliance page and in the data protection docs, and record it in your risk assessment.
Encryption with AWS KMS
Traffic to Bedrock uses TLS. Data at rest (S3 documents, the vector store, logs, fine-tuning data) is encrypted with AWS KMS. For PHI, use customer-managed keys: you control the key policy and rotation, and CloudTrail records every decrypt, so you can show who accessed encrypted PHI and when. Scope key policies so only the roles that must decrypt PHI can.
Network isolation with PrivateLink
Create a VPC interface endpoint for Bedrock (AWS PrivateLink) so your application calls the model over a private connection, not through an internet gateway. Add an S3 gateway endpoint for your documents, private subnets, security groups and endpoint policies. The whole PHI path then stays inside your VPC. Security reviewers ask for this early.
Guardrails: PII and PHI redaction
A Bedrock Guardrail controls what goes into and out of the model. Its sensitive information filter detects PII and PHI (names, addresses, phone numbers, emails, ID numbers and more) in prompts and responses. For each type you choose to block the exchange or mask the value. Custom regex patterns cover your own identifiers, such as medical-record and encounter numbers. The same Guardrail can enforce denied topics (for example, no diagnosis in an informational app), content filters, a prompt-attack filter and contextual grounding, so the model does not assert claims your sources do not support. See Guardrails PII redaction.
| Control | Risk it closes | AWS mechanism |
|---|---|---|
| No training on your data | PHI absorbed into a shared model | Bedrock data handling, scoped to your account and Region |
| Encryption at rest | PHI readable in storage | AWS KMS with customer-managed keys |
| Encryption in transit | PHI intercepted on the wire | TLS to all endpoints |
| Network isolation | PHI crossing the public internet | PrivateLink plus VPC endpoints |
| Guardrail redaction | PHI leaking in a prompt or response | Sensitive information filter (block or mask) plus custom regex |
| Denied topics and grounding | Out-of-scope advice, invented claims | Denied topics plus contextual grounding thresholds |
| Least-privilege IAM | Broad access to PHI and models | Scoped IAM roles and KMS key policies |
| Audit logging | No evidence of who accessed PHI | CloudTrail, CloudWatch and Bedrock invocation logging |
IIIReference architectures for clinical and administrative use cases
PHI exposure depends on what the application does. Match the controls to the exposure.
Clinical documentation summarization (PHI-heavy, internal)
Summarize notes, visit transcripts or a patient record into a draft note for a clinician. PHI exposure is high, but the audience is trusted, so the design leans on isolation and grounding more than heavy redaction. Documents sit in an S3 bucket encrypted with a customer-managed key. The app runs in a private VPC and calls Bedrock over PrivateLink. A model such as Claude on Bedrock writes the summary. A Guardrail enforces grounding and blocks prompt attacks. Every call is logged with the user identity. Treat the output as decision support: a clinician reviews it before it reaches the record.
Patient intake and patient-facing assistants (PHI in, public-facing)
Collect intake details, answer benefits or scheduling questions, or route symptoms to the right resource. The audience is untrusted and PHI flows both ways. Set the Guardrail to mask identifiers before storage and logging, add denied topics for diagnosis and treatment advice, turn on the prompt-attack filter, and ground answers in a Knowledge Base of approved content. Isolate retrieval by user and session so one patient never sees another's data. Authenticate before collecting PHI, and offer a handoff to a person.
Medical-coding assist (PHI-heavy, accuracy-critical)
Suggest ICD-10, CPT or HCPCS codes from documentation to help a certified coder. Accuracy and audit matter because miscoding has financial and compliance consequences. Use retrieval-augmented generation grounded in the coding guidelines and the patient documentation. The model proposes codes with the supporting passage cited, a Guardrail redacts PHI from logs, and a human coder confirms every code. Never auto-submit.
| Use case | Audience | PHI exposure | Design emphasis |
|---|---|---|---|
| Documentation summarization | Clinicians | High | Isolation, grounding, clinician review |
| Patient intake assistant | Patients | Both directions | Redaction, denied topics, prompt-attack filter, session isolation |
| Medical-coding assist | Certified coders | High, accuracy-critical | RAG grounding, citations, human confirmation |
| Admin work (claims, prior-auth drafts) | Staff | Varies | De-identify where possible, grounding, logging |
IVDe-identification: the strongest control is not sending PHI at all
Properly de-identified data is no longer PHI under HIPAA. Where a use case does not need identifiers, remove them before the model sees the data.
A clinician summarizing one patient's record needs the identifiers. Analytics, model evaluation, prompt datasets, fine-tuning data and many admin tasks often do not. For those, strip PHI first.
HIPAA recognizes two methods. Safe Harbor removes 18 categories of identifiers (names, geography smaller than a state, dates more specific than the year, contact details, record and account numbers, device identifiers, biometrics, full-face photos and other unique codes), with no actual knowledge that what remains could identify the person. Expert Determination uses a qualified expert who documents that the risk of re-identification is very small; it lets you keep more detail, such as specific dates. Pick the method with your compliance counsel.
Amazon Comprehend Medical is a HIPAA-eligible service with a PHI detection feature (DetectPHI). A common pattern: run documents through it, redact or tokenize what it finds, then send the de-identified text to Bedrock. Keep the Guardrail on as a second layer, and test detection recall on your own documents.
VAudit, logging, access control and retention
HIPAA requires that you protect PHI and that you can prove it. This layer is what an assessment or a hospital security review will ask to see.
- Least-privilege IAM: Only the application roles that must call Bedrock or read PHI can do so, with a matching KMS key policy. Use roles, not long-lived keys. Require sign-in before collecting PHI. Separate the role that reads PHI from the role that administers the account.
- CloudTrail: Records every API call, including Bedrock calls and KMS decrypts. Send it to a dedicated, access-restricted log bucket, and consider S3 Object Lock so the trail cannot be changed.
- Bedrock invocation logging: Bedrock can log calls to CloudWatch Logs or S3. Full prompt and response logging captures PHI, so encrypt those logs with a customer-managed key, restrict access, set retention, and log after redaction where you can.
- CloudWatch alarms: Alert on unusual call volume, access from unexpected roles and spikes in Guardrail blocks.
- Retention and disposal: Set how long PHI, logs and training data are kept, and enforce it with S3 lifecycle rules and log retention settings. When data ages out, delete it.
- A versioned Guardrail: Guardrail versions do not change once created, so you can show which PHI policy was in force at any time. Define it in infrastructure as code and call a specific version.
VIWhat not to do: mistakes that break compliance
Most compliance failures come from a short list of omissions. Each has a fix already covered above.
- PHI without a BAA: No signed AWS BAA means no PHI on AWS. Never send PHI to a consumer AI tool or any service outside the BAA.
- Treating eligibility as compliance: Misconfigured IAM, a public bucket, missing encryption, no logging or an unredacted patient assistant are all your responsibility.
- Raw PHI in logs: Verbose invocation logs are a common silent leak. Encrypt, restrict, set retention and log after redaction.
- Unauthorized clinical advice: An informational assistant that drifts into diagnosis is a clinical and liability problem. Use denied topics and keep a clinician in the loop.
- Ungrounded output for clinical or coding decisions: Use RAG, citations and grounding thresholds, and have a credentialed person confirm every clinical or coding output.
- Skipping de-identification: If de-identified data would do, sending full PHI only widens your risk.
- PHI on the public internet: Skipping PrivateLink, or piping PHI through a non-eligible tool, breaks the boundary.
- Set and forget: Thresholds drift, attacks change, and eligible-service scope and staff access change. Review them on a schedule.
VIIA HIPAA-ready build, in order
Contracts and scope first, then the secure foundation, then the model, then the controls, then the evidence. Starting with the model is the most common cause of rework.
- Step 1: sign the BAA and fix the service boundary: Accept the AWS BAA in AWS Artifact and list the HIPAA-eligible services PHI will flow through. Nothing outside that list touches PHI.
- Step 2: build the secure foundation: Private VPC and subnets, PrivateLink for Bedrock, an S3 gateway endpoint, customer-managed KMS keys on every PHI store, least-privilege IAM, and CloudTrail to a locked log bucket. Do this before any model call.
- Step 3: de-identify where you can: Run analytics, evaluation and training datasets through Comprehend Medical so those paths carry no PHI.
- Step 4: build the model layer: Access to many Bedrock models is on by default; Anthropic models need a one-time use-case form, and the first call to a third-party model needs AWS Marketplace permissions. Pick a model, build a Knowledge Base over vetted content for grounded use cases, and call Bedrock only over PrivateLink.
- Step 5: put a PHI-aware Guardrail in front: One versioned Guardrail: PII and PHI masking with custom regex, denied topics, content and prompt-attack filters, and grounding thresholds for RAG answers.
- Step 6: wire audit, alarms and retention: Encrypted, restricted invocation logs (redacted where possible), CloudWatch alarms, and retention rules for PHI and PHI-bearing logs.
- Step 7: test, keep humans in the loop, operate: Build a test set of normal, PHI-heavy, jailbreak and out-of-scope cases and keep it as a regression suite. A credentialed person confirms clinical and coding output. Review thresholds and access on a schedule.
VIIIWho files AWS funding for a healthcare GenAI build
A partner files one kind of AWS funding. You apply for the other.
Partner-filed funding. If the build qualifies, your matched AWS partner can file POC (proof of concept) funding to test the use case, or incremental workload (IW) funding if you already run on AWS and are launching new work. If you are moving to AWS from another cloud, it can file MAP migration funding. For startups this is typically $50K to $150K. Depends on the workload; AWS approves. See AWS partner funding.
AWS Activate credits. You apply yourself at aws.amazon.com/startups/credits: Activate Founders gives $1,000 to start, up to $5,000; Activate Portfolio gives up to $200,000 with an Org ID from your VC, accelerator or angel group if it is an Activate Provider. A consulting partner cannot file Activate for you.
Healthcare builds are where a partner with HIPAA experience helps most: the BAA scope, PrivateLink, KMS, Guardrails and the audit trail are easy to get wrong. If your team has done this before and you only need Activate credits, apply yourself; you do not need a partner.
HIPAA-ready vs risky: the same build, two ways
The gap between a defensible build and an incident is a handful of decisions. Read the middle column as the standard and the right column as what to avoid.
| Decision point | HIPAA-ready (do this) | Risky (avoid) |
|---|---|---|
| Contract | Signed AWS BAA before any PHI | PHI on AWS with no BAA |
| Services in the PHI path | Only HIPAA-eligible services | A non-eligible analytics, SaaS or logging tool in the path |
| Model data handling | Bedrock: no training on your data, scoped to your account | A consumer chatbot or unvetted API |
| Encryption | Customer-managed KMS keys plus TLS | Default keys, or unencrypted stores and logs |
| Network | PrivateLink and VPC endpoints | The public Bedrock endpoint over the internet |
| Prompt and response safety | Guardrail: PHI masking, denied topics, grounding | Raw model calls with no redaction |
| Logging | CloudTrail plus redacted, encrypted invocation logs | Raw PHI in under-protected logs |
| Human oversight | A clinician or coder confirms clinical output | Model output applied to the record automatically |
How a match works (example)
- You tell us about the work
You fill in a short form: what you run today, what you want to move, test or build, your stage and your region.
- We pick one partner
We read your answers and pick one vetted AWS consulting partner that fits the work, the stack and the region. We reply within 24 hours; your matched partner reaches out within 5 business days.
- The partner checks POC funding
Your matched partner scopes the test with you. Then it checks whether the test qualifies for POC (proof of concept) funding. A POC can fit whether or not you run on AWS today.
- The partner files, AWS decides
If the work qualifies, the partner files the funding request with AWS. AWS reviews it and decides. The amount depends on the workload.
- You pay nothing
CloudRoute is free for startups. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
AWS Activate credits are separate, and you apply for them yourself. Use Activate Founders if no investor backs you. Use Activate Portfolio with the Org ID or invite from your VC, accelerator, incubator or angel group if it is an Activate Provider. A consulting partner cannot apply for Activate on your behalf.
Common questions
Is Amazon Bedrock HIPAA-eligible, and can I use it with PHI?
Does Amazon Bedrock use my healthcare data to train its models?
What is the AWS BAA and do I need one for healthcare GenAI?
How do I stop PHI from leaking into prompts or model responses?
How should I set up the network and encryption for PHI on Bedrock?
What is de-identification and how does Amazon Comprehend Medical help?
Who files AWS funding for a healthcare GenAI build?
Build HIPAA-ready GenAI on AWS with a partner who can file the funding.
CloudRoute matches you with one vetted AWS partner with HIPAA experience: BAA scope, PrivateLink, KMS, PHI redaction and the audit trail. If the build qualifies, the partner files POC or incremental workload (IW) funding, typically $50K to $150K for startups. Depends on the workload; AWS approves. CloudRoute is free for startups.