AWS capability-demonstration catalog — v1 (2026-09-04)
Generated at build time from
docs/catalog/catalog-v1.mdin the repo — edit the source, not this page.
Revision of catalog-v0.md applying the research pass. Evidence for every statement is in dossier.md (claim ids C-n, contradictions X-n, gaps G-n); this file is the decision layer. Where a choice is a lead decision rather than a finding it is marked as such.
What changed from v0 in one paragraph. All eight items are kept; none is merged or dropped, but F0 splits into a single-account baseline (build) and an organisation layer (link), U3 is re-based on HealthScribe direct with Connect Health as a documented alternative, and U6 is reshaped from a Lex + Lambda build into a product-demonstration chapter. Five service choices are corrected: Pinpoint → AWS End User Messaging or SNS mobile push; "Guardrails at the tool boundary" → AgentCore Gateway interceptors calling Guardrails + Cedar Policy; Clarify → SHAP + bias metrics logged to SageMaker AI MLflow; QuickSight → Amazon Quick; Kinesis Data Analytics → Managed Service for Apache Flink. Amplify Gen 2 with native Swift and Kotlin is the mobile path (Flutter excluded by missing passkeys and AppSync Events). HealthScribe pins the primary demo region to us-east-1. The empty-account runbook must start from an "AWS (advanced)" account.
Design rules (v1)
- One use case pulls in many services; the portal explains services through the use case.
- Three tiers per use case: Tier 1 Core → Tier 2 Embedded AI → Tier 3 Learned models.
- Reuse before rebuild; fork/link only permissive licences (MIT, MIT-0, Apache-2.0); label community provenance.
- Retired / maintenance list (nothing here in new designs): App Runner, Bedrock Agents classic, Kendra, Q Business, IoT Events, IoT Analytics, Timestream for LiveAnalytics, Greengrass v1, Lookout family, Forecast, SageMaker A2I / Clarify / Ground Truth / Model Monitor / Debugger (maintenance, no new customers from 2026-07-30), Connect Voice ID, Lex V1, Amazon Pinpoint (EOS 2026-10-30), SageMaker Edge Manager (gone 2024-04-26), classic AWS Mobile SDKs for iOS/Android (EOS 2026-08-01), Amplify Gen 1 (maintenance 2026-05-01, EOL 2027-05-01). Naming: "Kinesis Data Analytics" → Managed Service for Apache Flink; "QuickSight" → Amazon Quick; "Security Hub" standards → Security Hub CSPM; "Amazon Connect" → Amazon Connect Customer (contact centre) and Amazon Connect Health (clinical). (C12, C17, C20, C33, C59, C77)
- Stack spine everywhere: CDK (TypeScript), FastAPI on ECS Fargate Express Mode, Aurora PostgreSQL Serverless v2, DynamoDB, Cognito, CloudFront, Bedrock + AgentCore, SageMaker AI.
- New — Tier 2 PHI rule: a Bedrock Guardrail on the model call covers prompt and completion text only. Tool inputs, tool results and tool definitions are protected by AgentCore Gateway REQUEST/RESPONSE Lambda interceptors that call
ApplyGuardrail, Cedar Policy on which tools an agent may call, and a CloudWatch Logs data-protection policy (invocation logs keep the raw prompt). US health identifiers (MRN, Medicare, NPI) need regex entities; built-ins cover only CA and UK. (C74, C75, X1) - New — model/retention rule: PHI prompts go to a model whose retention mode can be
none(e.g. Claude Opus 4.8); Claude Fable 5 / 5.1 requireaws_review(30-day AWS retention, possible AWS human review) and are used only on de-identified inputs with the decision logged. Enforce withbedrock:DataRetentionMode/bedrock-mantle:DataRetentionModeconditions; use a US-only inference profile because retained data lands in the destination region. (C73) - New — eligibility-by-feature-rule rule: S3 Tables, Timestream for InfluxDB, the Valkey engine, and Bedrock Knowledge Bases / Guardrails / Data Automation are not on the HIPAA Eligible Services Reference by name; they rest on the "GA features of listed services" clause. The portal says so explicitly, and until G2/G3 are confirmed with the account team, PHI landing in S3 Tables or InfluxDB is device-keyed and de-identified (identifiers live in Aurora/HealthLake). (C11, C28, C55)
- New — region rule: primary demo region us-east-1 (HealthScribe is us-east-1 only); us-west-2 is a valid secondary for everything except HealthScribe; Device Farm is us-west-2 only and never receives PHI. (C35, C25, C78)
- New — account rule: the empty-account runbook starts from an "AWS (advanced)" account with advanced features activated; the BAA is accepted in AWS Artifact (account scope, or organisation scope from the management account) before any PHI step. (C7, C8)
F0 — HIPAA-ready landing zone
Decision: keep, split into F0a (single account, build) and F0b (organisation layer, link). Reason: the only AWS-official artefact (LZA + healthcare config) requires an Organization with three mandatory accounts and idles at ~US$430/month; no public single-account HIPAA baseline exists, so F0a has real demonstration value and F0b is a link. (C1, C2, C3)
Story. Bare "AWS (advanced)" account → BAA accepted → one cdk deploy → an account that passes the Config HIPAA pack and Security Hub CSPM standards, with PHI discovery on, and evidence you can hand to an auditor.
F0a — single-account HIPAA baseline · Tier 1 only (no AI/ML tiers; it is the foundation)
- Pulls in: KMS customer-managed keys; CloudTrail (account trail; org trail moves to F0b); AWS Config with the "Operational Best Practices for HIPAA Security" conformance pack (130-rule cap, last commit 2025-01-07); Security Hub CSPM with FSBP + NIST 800-53 r5 + AI Security Best Practices; GuardDuty; Macie with the 12 PHI managed data identifiers selected explicitly (none are in the default sets; accounts that enabled automated discovery before 2023-08-02 differ); VPC + private subnets + endpoints; WAF + Shield; Secrets Manager; IAM Identity Center (single-account mode); CDK Pipelines; tagging/cost allocation; the AWS Artifact BAA step in the runbook. (C4, C5, C6, C7, C76)
- Verdict: BUILD. No fork base. Borrow shape from
aws-samples/deploy-conformance-pack-for-aws-startup-security-baseline(CDK Python, MIT-0, pushed 2025-03-28 — deploys the startup pack, not the HIPAA pack) and linkaws-samples/aws-security-reference-architecture-examples(CC-BY-SA-4.0, pushed 2026-09-04 — link only, never fork). (C2, C10) - New work: the whole CDK TS stack set; the "advanced features" prerequisite text; a Macie identifier-selection construct; evidence export (Security Hub findings + Config compliance to S3 with Object Lock). Link the Healthcare Industry Lens with its 2022-11-17 date and note the whitepaper is archived. (C8, C9)
- Demonstration value: High (nothing public exists; every other item depends on it).
F0b — organisation layer (optional extension)
- Pulls in: Organizations, Control Tower (controls-dedicated experience 2025-11-21 for an existing Organization, or full landing zone), LZA + LZA-for-Healthcare config, org-scope BAA from the management account, org trail, SCPs including the Bedrock
DataRetentionModeSCP from rule 7. (C1, C3, C7, C73) - Verdict: LINK.
aws-samples/landing-zone-accelerator-on-aws-for-healthcare(MIT-0, pushed 2026-06-18, config v1.9.0-e 2025-11-29) onawslabs/landing-zone-accelerator-on-aws(Apache-2.0, v1.16.2 2026-09-02); LZA cost page US$430.22/month sample.aws-solutions/aws-control-tower-customizations(Apache-2.0, pushed 2026-07-01). - New work: a chapter, not code — plus the SCP snippet. Open: whether HIPAA is among Control Catalog's new compliance frameworks (G7).
- Demonstration value: Low (AWS already demonstrates it; the portal explains why it is not the "first deploy").
U1 — Patient portal + companion mobile app (the reference application)
Decision: keep; highest-value new build. Reason: no AWS-official portal + native mobile + Cognito + HealthLake example exists on any stack; three independent absence searches. (C13)
Story. Patient signs up, verifies with MFA or a passkey, sees appointments and lab results, messages the care team, uploads documents, receives reminders — on web, iPhone and Android — with every PHI access logged.
Tier 1 — Core
- Web: React 19 + Vite on S3/CloudFront (Amplify Hosting optional — "AWS Amplify Console" is HIPAA-listed).
- Mobile (lead decision, ambiguity 4 below): native Swift + Kotlin on Amplify Gen 2. Amplify Swift 2.60.2 (2026-09-01) and Android 2.41.1 (2026-09-02) have passkeys and AppSync Events; Flutter 2.15.0 has neither (issues open since 2025-03/04, WebAuthn PR still draft); React Native follows JS but Expo Go is unsupported and the U2 device path (IoT Device SDK for Swift / Java v2, HealthKit, Health Connect, BLE) is native anyway. Gen 1 is in maintenance (EOL 2027-05-01). (C15, C16, C29, C30)
- Auth: Cognito user pool on the Essentials plan with Managed Login; sign-in = password + MFA (TOTP/SMS via End User Messaging) or passkey with
MULTI_FACTOR_WITH_USER_VERIFICATION; no OTP-first-factor (incompatible with required MFA); passkeys cannot be a second factor to password; mobile passkeys need the.well-knownassociation files; social IdP optional; refresh-token rotation on. (C19) - API: API Gateway HTTP API → FastAPI on Fargate Express Mode (existing backend proxy pattern) + AppSync Events for real-time (messages, result-ready). No AWS doc prefers AppSync over API Gateway for this shape; both HIPAA-listed. (C18)
- Data: Aurora Serverless v2 (SQLAlchemy/Alembic) for app state; S3 + KMS for documents; HealthLake as the FHIR R4 clinical record — GA, shipping (2026-03/05/07 releases), seven regions, US$0.27/data-store-hour ≈ US$197/month (the dominant running cost — make it a stack toggle). (C24)
- Notifications (corrected): app push via SNS mobile push (undeprecated, EventBridge → SNS fan-out shared with U2 alerts) with AWS End User Messaging Push as the AWS-named alternative; SMS/OTP via End User Messaging; email via SES; reminders/journeys via Amazon Connect Customer outbound campaigns + Customer Profiles (push through journeys + Lambda action). Lead decision: SNS is the default for the demo because the EUM Push path still keys on a Pinpoint application resource whose survival past 2026-10-30 is unconfirmed (G18); revisit after that date. Design rule: no PHI in push payloads (APNs/FCM are outside the BAA) — notifications say "you have a new result", the app fetches it. (C20, C21, X2)
- Verdict: BUILD. Fork
aws-samples/sample-intelligent-security-for-healthcare-apis(MIT-0, CloudFormation, pushed 2026-08-14; Cognito MFA, Comprehend Medical redaction before audit logging, Bedrock Guardrail; empty→running 10–15 min) for the API-boundary pattern andaws-samples/aws-healthlake-smart-on-fhir(MIT-0, CDK TS, pushed 2024-03-16; no UI, external IdP) for HealthLake SMART wiring. (C14) - New work: everything user-facing (web, Swift, Kotlin), Cognito passkey flow, FastAPI service, HealthLake integration on Cognito rather than ORY, notification fan-out, CDK TS conversion of the forked CloudFormation.
- Demonstration value: Highest.
Tier 2 — Embedded AI
- In-app assistant ("what does this lab result mean?") on Bedrock with a Managed Knowledge Base over patient-education content and AgentCore Gateway tools that read the patient's own FHIR data, protected per rule 6 (interceptors + Guardrails + Cedar + logs data protection) and rule 7 (retention mode). AgentCore Memory KMS-encrypted; Macie/Comprehend Medical pre-ingestion scan of KB content; S3 Object Lock on logs (per the AWS public-sector blueprint, 2026-08-14). (C22, C73–C75)
- Verdict: FORK SCAFFOLDING, BUILD THE ASSISTANT.
aws-samples/amazon-bedrock-agents-healthcare-lifesciences(MIT-0, pushed 2026-09-03, Strands + AgentCore, life-science skew, no patient agents);aws-samples/sample-healthcare-agent-with-agentcore-on-aws(MIT-0, pushed 2026-08-03,agentcore deploy, calls a SageMaker endpoint — the Tier 2→3 bridge; no IaC). (C22) - New work: patient-scoped FHIR tools; the interceptor Lambda pattern (no public healthcare sample — G17 risk analysis); Guardrail regex entities for US identifiers; retention-mode enforcement; the audit trail.
- Demonstration value: High.
Tier 3 — Learned models
- No-show / appointment-adherence model (XGBoost, Feature Store) → reminders in the app.
- Verdict: BUILD on
aws-samples/amazon-sagemaker-pipeline-deploy-manage-100x-models-python-cdk(MIT-0, pushed 2026-07-28; Pipelines + Model Registry + endpoints in four CDK stacks). Bias/explainability = SHAP + metrics logged to SageMaker AI MLflow (Clarify successor, C59). (C23) - New work: feature pipeline from Aurora/HealthLake, training, batch scoring to DynamoDB, reminder trigger. Demonstration value: Medium.
U2 — Remote patient monitoring from connected devices at scale
Decision: keep; the "large device data → models → back into the app" showcase. Reason: no end-to-end RPM example, no AWS HealthKit/Health Connect guidance, no current phone→IoT Core sample; every tier is new work. (C26–C33)
Story. Cuffs, meters and wearables stream vitals through the patient's phone; the care team sees trends and anomaly alerts; the patient sees their own data and an assistant explains it; models trained on the fleet's history score new readings in the cloud and at the edge.
Tier 1 — Core
- Pipeline (unchanged from the library, HIPAA check applied): IoT Core (X.509 per gateway device, Device Shadows, Fleet Provisioning) → IoT Rules → Kinesis Data Streams → Managed Service for Apache Flink → Timestream for InfluxDB (hot; feature-rule eligibility only, rows device-keyed and de-identified per rule 8) + Firehose → S3 Tables (Iceberg) (cold; same caveat) → Athena; Greengrass v2 gateway with offline buffering ("AWS IoT Greengrass" listed without version); EventBridge alerts → SNS (app push) / End User Messaging (SMS). (C11, C27, C28, C34)
- Phone-paired devices (corrected): phone authenticates with Cognito identity pool + IAM role plus an IoT policy attached to the Cognito identity, publishes MQTT 5 over WebSocket/SigV4. iOS: AWS IoT Device SDK for Swift (GA 2026-06-24, Apache-2.0); Android: IoT Device SDK for Java v2. HealthKit and Health Connect are read on-device by the app (no cloud API; Apple 5.1.3 forbids iCloud storage of health data; Health Connect has background reads + sync) and forwarded through the same MQTT path or a REST ingest; BLE devices bridged by the phone. State plainly in the chapter: AWS publishes no guidance for this — it is our pattern (G11). (C29, C30)
- Portal side: device-management UI plus a real-time view forked from
aws-samples/aws-appsync-iot-core-realtime-dashboard(MIT-0, Amplify Gen 2,npx ampx sandbox, pushed 2026-09-03). (C27) - Verdict: BUILD. Fork:
aws-solutions-library-samples/guidance-for-aws-iot-greengrass-foundations(MIT-0, CDK v2 TS, pushed 2026-07-23) for the gateway;aws-samples/aws-greengrass-ec2-device-farm(Apache-2.0, CDK v2, pushed 2026-08-30) for a simulated fleet at scale;aws-samples/aws-amplify-cdk-iot-ble-swift-app(MIT-0, CDK v2 + least-privilege IoT policy since 2026-06-09) CDK only — its iOS layer pins Amplify v1 + the EOS classic SDK and must be rewritten on Amplify Swift 2.x + IoT Device SDK for Swift. (C31, X6) - New work: the Flink job, the InfluxDB and S3 Tables landing with IaC (no public sample — G4), Kotlin BLE/Health Connect client, Swift HealthKit/BLE client, alerting, device UI, load generation to the scale target. Demonstration value: Highest.
Tier 2 — Embedded AI (rewritten per X1)
- AgentCore Gateway exposes typed telemetry queries as MCP tools (tools, not embeddings); the assistant answers "how has my BP trended this month?". PHI control at the tool boundary = Gateway REQUEST/RESPONSE interceptors calling Guardrails
ApplyGuardrail+ Cedar Policy restricting each patient principal to their own device tools + CloudWatch Logs data protection — not a model-call Guardrail, which does not see tool I/O. (C32, C74, C75) - Verdict: BUILD. No example; generic Gateway samples only. Demonstration value: High (first public healthcare example of interceptor-based PHI masking).
Tier 3 — Learned models
- Per-patient anomaly detection (Random Cut Forest in Flink state; autoencoder on SageMaker), deterioration forecasting (DeepAR; Chronos as an option — not evaluated by this pass), SageMaker Pipelines retraining, Model Registry, real-time endpoint called from Flink, edge scoring = quantised ONNX model deployed as a Greengrass v2 component (SageMaker Edge Manager is gone; AWS names ONNX + Greengrass v2). (C33, C34)
- Verdict: BUILD. Fork logic from
aws-samples/flink-keyed-random-cut-forest-example(MIT-0, pushed 2025-12-19, no IaC) andaws-samples/amazon-sagemaker-deepar-mlops-pipeline-cdk(MIT-0, pushed 2025-04-10); pattern referenceamazon-sagemaker-feature-store-streaming-inference-msk-kda(MIT-0, 2024-01-04, fraud domain). Do not linkgreengrass-v2-sagemaker-edge-manager-pythonor the archived Greengrass-v1 forecasting sample. (C27, C33) - New work: IaC for the RCF job, the ONNX export + Greengrass component, Flink → endpoint call, retraining pipeline. Demonstration value: High.
U3 — Ambient clinical documentation (visit → note)
Decision: keep; re-base Tier 1 on HealthScribe direct; Connect Health Ambient becomes a documented alternative and is demonstrated in U6. Reason below (X3).
Story. Clinician records a visit on phone or web; the system produces a structured SOAP note, ICD-10 suggestions and a patient-friendly summary with timestamp citations; the clinician reviews and approves; the note lands in HealthLake as a FHIR DocumentReference. Human-in-the-loop approval is the point of the demo.
The Connect Health decision (X3) — option pair
| Option A — HealthScribe direct | Option B — Amazon Connect Health Ambient | |
|---|---|---|
| Region | us-east-1 only (en-US) | us-east-1 + us-west-2 |
| Price | US$0.10/min | US$99/user/month subscription (600 encounters), overage US$0.036/min |
| Deploy story | sample-healthscribe-bedrock-clinical-analysis: CDK TS, Fargate, React+Vite, Cognito, CloudFront, ./deploy.sh — empty→running (needs an ACM cert) | Requires a registered Connect instance + Connect Health domain + subscription — semi-manual, couples U3 to a Connect footprint |
| Best sample | Matches the stack spine; no coding step, no HealthLake write-back | sample-amazon-connect-health-unified-clinical-workflow uses Bedrock Agents classic (retired list); point-of-care sibling is clean but CloudFormation and Connect-bound |
| Lifecycle signal | HealthScribe dev guide banner steers to Connect Health Ambient | Newer product surface; medical coding still gated preview |
| Sources | C35, C39 | C37, C38, C60 |
Recommendation (lead decision): Option A for the U3 repo and chapter, because it deploys from an empty account on the catalog's own spine, costs cents per demo rather than a per-user subscription, and stays independent of U6. Accept the us-east-1 pin (rule 9). Write the chapter with an explicit "Option B: the product path" section that links to U6, where Connect Health is demonstrated as a product; revisit if HealthScribe gets an end-of-support notice (today it is "steered", not retired).
Tier 1 — Core
- Mobile/web capture → S3 → HealthScribe (streaming or batch) → Comprehend Medical (entities; ICD-10-CM / RxNorm / SNOMED linking — quiet but not retired, ontology refreshed 2025-02 and 2025-08) → Step Functions review workflow → clinician review UI → HealthLake FHIR DocumentReference. Fallback for other regions: Transcribe Medical + Bedrock, as
sup-hcls-generate-clinical-notes-with-aidoes. (C35, C36) - Verdict: FORK + BUILD (X4 composition). Fork
aws-samples/sample-healthscribe-bedrock-clinical-analysis(MIT-0, CDK TS, pushed 2026-04-07) for structure and UI; port the Comprehend Medical ICD-10 step fromaws-solutions-library-samples/guidance-for-identifying-diagnosis-codes-from-clinical-notes-on-aws(MIT-0, CDK Python, pushed 2026-04-13 — only the Comprehend Medical → Bedrock → OpenSearch Serverless slice is in code; drop its US$350/month OpenSearch Serverless line in favour of a Managed Knowledge Base). Borrow UI ideas only fromaws-healthscribe-demo(Gen 1). (C39, C40, C41) - New work: Step Functions review workflow, approval UI states, HealthLake write-back, coding step port, cost table (Comprehend Medical unit prices still needed — G6). Demonstration value: Medium (fork bases exist; the composition is the value).
Tier 2 — Embedded AI
- Bedrock drafts the SOAP note and patient summary with timestamp citations; Guardrails on the model call (text) plus rule 6 if tools are used; retention mode per rule 7 (visit transcripts are PHI → ZDR-capable model). (C73, C74)
- Verdict: FORK the 12-specialist orchestration in the same sample; build the citation and approval logic. Demonstration value: Medium.
Tier 3 — Learned models
- Note-quality / coding-suggestion classifier on SageMaker; evaluation harness comparing model versions.
- Verdict: BUILD; reuse
healthcare-LLM-as-a-Judgeandeval-genai-techniques-clinicalreportnotebooks for the harness. (C42) Demonstration value: Medium.
U4 — Intelligent document intake (referrals, faxes, claims, prior auth)
Decision: keep, but shrink the new-build scope to the healthcare layer. Reason: best-covered item; the IDP Accelerator and sample-healthcare-agents are current, MIT-0, and together cover Tier 1–2 generically. (C44, C46, C51)
Story. PDFs and faxes arrive; the system extracts, classifies and routes them; PHI is detected and masked for logging; a human resolves exceptions; an agent assembles a prior-auth packet.
Tier 1 — Core
- S3 intake → Bedrock Data Automation (2026 default, Pattern 1) with Textract (Pattern 2, on the HIPAA list by name) retained for OCR-first documents → Comprehend Medical → Step Functions + SQS → review UI (web + mobile) → Aurora/HealthLake; Macie on the intake bucket with PHI identifiers selected explicitly. The chapter states that BDA's eligibility rests on the feature rule (rule 8). (C6, C47)
- Verdict: LINK
aws-solutions-library-samples/accelerated-intelligent-document-processing-on-aws(MIT-0, pushed 2026-09-04, 302 stars; one-click CloudFormation in us-east-1/us-west-2/eu-central-1, CDK/Terraform alternates, built-in human review, MLflow evaluation, Cognito + WAF UI, MCP via AgentCore Gateway) as the chapter's primary deployable. Embed the Guidance for Intelligent Document Processing on AWS page (AgentCore Runtime/Identity/Gateway + Strands + Textract) as the architecture explainer; its repoaws-samples/aws-ai-intelligent-document-processing(pushed 2026-05-04) is fork-blocked until its LICENSE text is confirmed (GitHub detects none; README says MIT-0). Do not linksample-scalable-…-bedrock-data-automation(A2I + Ground Truth). (C44, C45, C48) - New work: Comprehend Medical PHI step + Macie construct +
aws-samples/aws-ai-phi-deidentification(MIT-0, CDK, pushed 2025-04-23) as the de-id stage, HealthLake landing, Guidance disclaimer on the chapter. State that automated de-identification assists but does not satisfy Safe Harbor on its own (Comprehend Medical FAQ). (C43, C49) Demonstration value: Low.
Tier 2 — Embedded AI
- Bedrock structured extraction with a confidence-gated review queue (Accelerator has it); AgentCore agent that assembles a prior-auth packet.
- Verdict: FORK
aws-samples/sample-healthcare-agents(MIT-0, CDK TScdk deploy --all, pushed 2026-09-03; AgentCore Runtime + Gateway, Strands, HealthLake FHIR R4, Comprehend Medical, B2B Data Interchange EDI 837P, CDS Hooks; prior auth, eligibility, coding, claims, appeals; has payor-policy PDF upload tools, lacks patient-document intake). (C46) - New work: wire the Accelerator's extraction output into the agent's intake; apply rule 6/7 controls. Demonstration value: Low-Medium.
Tier 3 — Learned models
- Document-type classifier and denial-risk model on SageMaker from intake history (the Accelerator classifies with Bedrock; no SageMaker example). Verdict: BUILD. (C50) Demonstration value: Medium.
U5 — Population health analytics and risk models (the data platform)
Decision: keep. Reason: the closest artefact is a 2024-12 notebook Guidance; S3 Tables, Quick and de-identification are all new; Tier 2 has only a snippet. (C53, C55, C56, C58)
Story. Data from U1–U4 lands in a governed lake; analysts get Quick dashboards and ask questions in natural language; models compute risk scores that flow back into U1.
Tier 1 — Core
- HealthLake export + Firehose/Iceberg from U2 → S3 Tables (Iceberg; rule 8 caveat, G2) → Glue Data Catalog → Athena → Amazon Quick (HIPAA-listed; every existing sample still says QuickSight — rename pass required); Lake Formation fine-grained access; EMPI via AWS Entity Resolution; de-identification pipeline (Comprehend Medical DetectPHI + Macie + the de-id sample) with human review documented as part of the process. (C43, C49, C54, C56)
- Verdict: FORK + BUILD. Fork
aws-solutions-library-samples/guidance-for-multi-modal-data-analysis-with-aws-health-and-ml-services(MIT-0, pushed 2024-12-17; one-click SageMaker domain + notebooks; HealthOmics/HealthLake/HealthImaging → Lake Formation → Athena; Synthea Coherent) for the data model and notebooks; forkguidance-for-patient-entity-resolution-with-aws-healthlake(MIT-0, pushed 2025-09-11). Linkhealthlake-workshop(archived 2026-02) for concepts only. (C53, C54) - New work: S3 Tables landing with IaC (no sample), Quick dashboards, de-id pipeline, CDK TS conversion, cost table (the Guidance has none). Demonstration value: Medium.
Tier 2 — Embedded AI
- Natural-language analytics over the lake (Quick, or Bedrock + Athena tools via AgentCore Gateway under rule 6); Managed KB over care guidelines.
- Verdict: BUILD.
aws-samples/extract-medical-insights-from-amazon-healthlake-with-bedrock(Apache-2.0, pushed 2024-11-05, Streamlit, no IaC, text-to-SQL) is a snippet to read, not fork. (C58) Demonstration value: Medium-High (no current example of NL analytics over a HIPAA lake).
Tier 3 — Learned models
- Readmission / chronic-condition risk models (Feature Store, Pipelines, Model Registry), batch scores to DynamoDB, risk flags in U1. Clarify successor (corrected): bias and explainability are built into the pipeline — standardised bias metrics (pandas/scikit-learn) + SHAP, logged to SageMaker AI MLflow, with monitoring from
aws-samples/sample-aiops-on-amazon-sagemakerai/monitoring(Model Monitor is also in maintenance). (C59) - Verdict: FORK CONTENT, BUILD INFRASTRUCTURE (X5). Modelling logic (Feature Store schema, AutoGluon training, endpoint) from the Multi-Modal Guidance re-targeted to readmission risk, on the
amazon-sagemaker-pipeline-deploy-manage-100x-models-python-cdkspine (pushed 2026-07-28). All healthcare readmission samples are 2021–2022 — cite for domain only. (C57) Demonstration value: Medium.
U6 — Patient engagement contact centre with AI agents (optional)
Decision: keep as optional (light coverage per brief OQ7), reshaped from a build into a product-demonstration chapter that also hosts the Connect Health Option B for U3. Reason: Connect Health makes patient verification (GA) and appointment management (preview) product features, so Lex + Lambda identity code would demonstrate the wrong thing; Amazon Connect (Customer) and Lex are HIPAA-listed; no healthcare Connect workshop or Guidance exists. (C60, C61, C64)
Story. Patient calls or chats; Connect Health verifies identity (US$0.15/action) and handles scheduling and FAQs; a Bedrock-backed agent answers policy questions; escalation to a human carries context; the same Connect Customer campaigns send U1's reminders.
Tier 1 — Core
- Amazon Connect Customer instance + Amazon Connect Health domain (patient verification GA; appointment management preview); Lex V2 for chat where needed; web chat widget + in-app chat; SMS via End User Messaging, email via SES;
sample-healthcare-realtime-eligibility(MIT-0, pushed 2026-03-03) for insurance eligibility. Connect Health Ambient documentation (US$99/user/month) demonstrated here as U3 Option B. (C37, C60) - Verdict: LINK the product (console-driven; Connect instances are not empty→running by CDK alone). Demonstration value: Low.
Tier 2 — Embedded AI
- Connect Health agentic features + Knowledge Base over policies; agent assist.
- Verdict: OPTIONAL FORK
aws-samples/sample-Nova-Sonic-AgentCore-Healthcare-Call-Center(MIT, CDK Python, pushed 2026-05-21; AgentCore + Nova 2 Sonic over WebSocket, no Amazon Connect) if a deployable repo is wanted. Do not linksample-amazon-connect-bedrock-agent-voice-integration(Bedrock Agents classic) orsample-amazon-connect-health-unified-clinical-workflow(same).serverless-patient-engagement-stack(MIT-0, CDK TS, 2025-04-01) is reusable for the engagement flow only after Pinpoint is replaced by Connect Customer campaigns. (C20, C62, C63, C65)
Tier 3 — Learned models
- Contact-reason classification could be a SageMaker build, but demand forecasting / capacity planning / scheduling is a Connect product feature — LINK, not a SageMaker tier. (C64) Demonstration value: Low.
Cross-cutting chapters (not use cases)
- Scale: load testing to 1.5× peak on the ambiguity-3 envelope; AppSync Events / WebSocket API Gateway for streaming; ElastiCache for Valkey fan-out (Valkey engine is feature-rule eligibility, rule 8); RDS Proxy; DynamoDB session state; multi-Region path (us-east-1 primary, us-west-2 secondary minus HealthScribe).
- Operations: OpenTelemetry → CloudWatch/X-Ray, AgentCore Observability, blue/green, Alembic-gated migrations, cost dashboards (HealthLake ≈US$197/month per store is the line to watch; reconcile with the "~$500/month" figure in one README — G21).
- Compliance evidence (expanded): audit-log walkthrough; PHI access reports; Guardrails test suite including the tool-I/O negative test that shows a model-call Guardrail missing PHI in
toolResult; interceptor-based masking demo; Bedrock retention modes +DataRetentionModeSCP/IAM condition (Fable 5.1aws_reviewvs Opus 4.8none); Security Hub CSPM AI Security Best Practices findings; Macie PHI identifier selection; the F-15 closure text (Bedrock does not train on or share customer content); the feature-rule eligibility table; the "AWS (advanced)" account requirement. (C6, C8, C11, C72–C76)
P0 — The education portal
Decision: keep; build new. Reason: no public education-portal repo for this purpose exists; AWS's content surfaces have stable contracts to copy; Workshop Studio pages cannot be read programmatically, so link-outs are provisional until G1 is closed by a browser session. (C66–C71)
Verdict: BUILD on the same React/CloudFront stack, or — lead recommendation — a Docusaurus site (precedent aws-samples/eks-workshop-v2, Apache-2.0) generated at build time from each use-case repo, with Backstage TechDocs / Antora as alternatives if the catalog outgrows one site. Each chapter links the live demo, the repo, the CDK stack list, the architecture diagram and a "deploy this yourself" runbook; forked chapters carry the Guidance disclaimer ("not for production accounts"). Demonstration value: High (it is the frame every other item is seen through).
Content contract recommendation (what every use-case repo must ship so the portal never drifts)
README.mdfollowing the Guidance README contract: Overview → Cost (table, dated, region) → Prerequisites (incl. "AWS (advanced)" account, BAA, region) → Deployment → Validation → Running the demo → Next Steps → Cleanup; tail## Security/## License(MIT-0 default). (C68, C69)catalog-item.jsonmodelled on serverless-patterns'_pattern-model/example-pattern.json: item id, tiers implemented, services with HIPAA-list entry name and eligibility basis (named / feature rule), regions supported, fork provenance (upstream URL, licence, commit), retired-service check date. This one file drives the portal's tables. (C69)docs/decisions/— MADR 4 ADRs for every lead decision named in this file (mobile stack, push channel, U3 option, hot-store PHI handling, model/retention choice). (C70)docs/architecture/— diagram source + PNG; numbered-step description in the Guidance page style. (C68)contentspec.yamlper use case (Workshop Studio v2.0 shape,accountSources: [CustomerProvided]at minimum) so any chapter can later be submitted as a workshop without rewriting; CDK-synthesised templates understatic/. (C66)- Generated, never hand-written: the CDK stack list (
cdk lsoutput), the cost table's service rows, and the retired-service audit — emitted by CI into the portal build. - Link-out policy: AWS workshops and Guidance pages are linked only after their module list has been read (G1); community repos are labelled as such (brief OQ1).
Recommended build order
- P0 content contract + site skeleton (first week, alongside F0a). Every repo after this conforms from its first commit; retrofitting the contract is the most expensive mistake available.
- F0a — single-account HIPAA baseline. Build this first. Every deployment sits on it; it settles the two prerequisites that gate all PHI work (advanced-features account, BAA); it has no public example, so it is a genuine contribution; and it is small enough to finish quickly.
- U1 Tier 1 — the reference application. Highest-value gap, and it fixes the decisions every other item inherits (native mobile, Cognito flow, API layer, notification path, HealthLake toggle).
- U2 Tier 1 — the device-data showcase; depends on U1's mobile apps for pairing and its notification path for alerts.
- U4 Tier 1–2 — the cheap win. Link the Accelerator, fork
sample-healthcare-agents; two chapters for little code, and it exercises the portal's link + fork paths early. - U1 Tier 2 + the compliance-evidence chapter — establishes the interceptor/Guardrails/Cedar/retention pattern once; U2 T2, U4 T2, U5 T2 then reuse it.
- U3 (Option A) — fork + composition; us-east-1.
- U5 Tier 1–2 — needs U1–U4 data to be interesting.
- Tier 3 across U1, U2, U5 (then U3, U4) — the SageMaker Pipelines spine is built once in U1 T3 and reused.
- U6 (optional, product chapter) and F0b (org-layer link chapter) — last, both mostly prose.
Four ambiguities the requester should confirm (from triage)
- Single-account vs organisation for F0. v1 assumes F0a single account is mandatory and F0b organisation is an optional extension (LZA needs three accounts and ~US$430/month; no single-account example exists). Confirm that a single-account baseline is an acceptable "HIPAA-ready landing zone" for the portal's story.
- Region defaults. v1 pins us-east-1 primary, us-west-2 secondary; HealthScribe alone forces this (HealthLake is in seven regions, Connect Health in both defaults, Device Farm us-west-2 only). Confirm us-east-1 is acceptable, or accept Connect Health Ambient (Option B) for U3 to keep us-west-2 parity.
- Scale target. v1 keeps the library's 100K-user / tens-of-thousands-concurrent envelope; nothing in the research changes it, but the U2 load generator and cost tables need a number. Confirm or replace.
- Native vs cross-platform mobile. v1 chooses native Swift + Kotlin on Amplify Gen 2 (Flutter lacks passkeys and AppSync Events; classic Mobile SDKs are EOS; the device path is native regardless). React Native is the only viable cross-platform alternative (no Expo Go). Confirm two native codebases are acceptable for the reference app.
Two smaller confirmations ride along: whether PHI may land in Timestream for InfluxDB and S3 Tables at all before G2/G3 are answered (v1 default: de-identified, device-keyed rows), and whether community-maintained repos may be linked at all (v1 default: yes, labelled).