Skip to main content

AWS capability-demonstration catalog — v1 (2026-09-04)

Generated at build time from docs/catalog/catalog-v1.md in 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)

  1. One use case pulls in many services; the portal explains services through the use case.
  2. Three tiers per use case: Tier 1 CoreTier 2 Embedded AITier 3 Learned models.
  3. Reuse before rebuild; fork/link only permissive licences (MIT, MIT-0, Apache-2.0); label community provenance.
  4. 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)
  5. Stack spine everywhere: CDK (TypeScript), FastAPI on ECS Fargate Express Mode, Aurora PostgreSQL Serverless v2, DynamoDB, Cognito, CloudFront, Bedrock + AgentCore, SageMaker AI.
  6. 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)
  7. 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 require aws_review (30-day AWS retention, possible AWS human review) and are used only on de-identified inputs with the decision logged. Enforce with bedrock:DataRetentionMode / bedrock-mantle:DataRetentionMode conditions; use a US-only inference profile because retained data lands in the destination region. (C73)
  8. 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)
  9. 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)
  10. 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 link aws-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 DataRetentionMode SCP 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) on awslabs/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-known association 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 and aws-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 FlinkTimestream 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) and aws-samples/amazon-sagemaker-deepar-mlops-pipeline-cdk (MIT-0, pushed 2025-04-10); pattern reference amazon-sagemaker-feature-store-streaming-inference-msk-kda (MIT-0, 2024-01-04, fraud domain). Do not link greengrass-v2-sagemaker-edge-manager-python or 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 directOption B — Amazon Connect Health Ambient
Regionus-east-1 only (en-US)us-east-1 + us-west-2
PriceUS$0.10/minUS$99/user/month subscription (600 encounters), overage US$0.036/min
Deploy storysample-healthscribe-bedrock-clinical-analysis: CDK TS, Fargate, React+Vite, Cognito, CloudFront, ./deploy.shempty→running (needs an ACM cert)Requires a registered Connect instance + Connect Health domain + subscription — semi-manual, couples U3 to a Connect footprint
Best sampleMatches the stack spine; no coding step, no HealthLake write-backsample-amazon-connect-health-unified-clinical-workflow uses Bedrock Agents classic (retired list); point-of-care sibling is clean but CloudFormation and Connect-bound
Lifecycle signalHealthScribe dev guide banner steers to Connect Health AmbientNewer product surface; medical coding still gated preview
SourcesC35, C39C37, 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-ai does. (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 from aws-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 from aws-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-Judge and eval-genai-techniques-clinicalreport notebooks 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 repo aws-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 link sample-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 TS cdk 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; fork guidance-for-patient-entity-resolution-with-aws-healthlake (MIT-0, pushed 2025-09-11). Link healthlake-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-cdk spine (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 link sample-amazon-connect-bedrock-agent-voice-integration (Bedrock Agents classic) or sample-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 + DataRetentionMode SCP/IAM condition (Fable 5.1 aws_review vs Opus 4.8 none); 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)

  1. README.md following 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)
  2. catalog-item.json modelled 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)
  3. 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)
  4. docs/architecture/ — diagram source + PNG; numbered-step description in the Guidance page style. (C68)
  5. contentspec.yaml per 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 under static/. (C66)
  6. Generated, never hand-written: the CDK stack list (cdk ls output), the cost table's service rows, and the retired-service audit — emitted by CI into the portal build.
  7. 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).

  1. 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.
  2. 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.
  3. 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).
  4. U2 Tier 1 — the device-data showcase; depends on U1's mobile apps for pairing and its notification path for alerts.
  5. 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.
  6. U1 Tier 2 + the compliance-evidence chapter — establishes the interceptor/Guardrails/Cedar/retention pattern once; U2 T2, U4 T2, U5 T2 then reuse it.
  7. U3 (Option A) — fork + composition; us-east-1.
  8. U5 Tier 1–2 — needs U1–U4 data to be interesting.
  9. Tier 3 across U1, U2, U5 (then U3, U4) — the SageMaker Pipelines spine is built once in U1 T3 and reused.
  10. U6 (optional, product chapter) and F0b (org-layer link chapter) — last, both mostly prose.

Four ambiguities the requester should confirm (from triage)

  1. 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.
  2. 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.
  3. 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.
  4. 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).