Skip to main content

Research brief: AWS demonstrable use-case catalog for a HIPAA-compliant healthcare platform (September 2026)

Generated at build time from research/aws-demo-catalog/brief.md in the repo — edit the source, not this page.

Triage run: 2026-09-04. Output directory: research/aws-demo-catalog/. Hypothesis document under test: research/aws-demo-catalog/catalog-v0.md (read it first; every scout validates and fills it, nobody re-derives it).

Topic​

Build a catalog of demonstrable AWS use-case solutions for a HIPAA-compliant healthcare platform — responsive web portal plus native iOS and Android apps — with AI embedded in the workflows (Bedrock / AgentCore) and custom ML models trained from large volumes of connected-device data (SageMaker AI). The catalog is not a service tour: each entry is a use case that pulls in many services, backed by a public repository that takes an empty AWS account to a live, working deployment, and explained in a chapter of an education portal. The research question is twofold: (1) what already exists publicly — aws-samples, awslabs, aws-solutions, AWS Solutions Library Guidance, Amplify samples, AWS workshops, healthcare reference architectures — that demonstrates each catalog item, and (2) what the September 2026 building blocks are (HIPAA-eligible services, health-specific services and their lifecycle, the recommended mobile stack, and how AWS structures learn-by-deploying content).

Feeds decision​

An AWS-using consultant/engineer needs to explain and demonstrate what can be built on modern AWS, through an education portal where each chapter is a use case backed by a public repo and a running deployment. She does not want to re-create examples that already exist publicly. The research decides, for each catalog item (F0, U1–U6, P0):

  1. Keep, merge, or drop the item from the catalog.
  2. Fork/compose vs. build new — whether an existing public repo or Guidance covers it well enough to fork or compose, or whether nothing demonstrable exists and new work has real demonstration value.
  3. Link vs. rebuild — whether an existing AWS workshop or Solutions Library page already teaches it well enough that the portal should link out rather than re-implement.

Secondary outputs that feed the build: the confirmed HIPAA-eligible status of every service in the catalog's stack spine, the lifecycle status and pricing of the health-specific services, and the 2026 mobile/push/device path so the reference application (U1) is built on supported components.

Already assumed / known (do not re-research)​

All of the following is settled in catalog-v0.md and the library, and scouts must treat it as given:

  • The catalog structure and items (catalog-v0.md, "Design rules" and F0/U1–U6/P0 sections): one use case pulls in many services; three tiers per use case (Core → Embedded AI → Learned models); reuse before rebuild; one stack spine everywhere.
  • The app-tier stack spine (catalog-v0.md rule 5; library entry high-scale-app-tier-defaults): CDK (TypeScript), FastAPI on ECS Fargate Express Mode, Aurora PostgreSQL Serverless v2, DynamoDB, Cognito, CloudFront, Bedrock + AgentCore, SageMaker AI. Do not re-evaluate compute/data/cache choices.
  • The IoT → ML data path (catalog-v0.md U2; library entry iot-telemetry-to-llm-and-ml-path): IoT Core → Rules → Kinesis Data Streams → Managed Service for Apache Flink → Timestream for InfluxDB (hot) + Firehose → S3 Iceberg → Athena → SageMaker AI; telemetry exposed to the assistant as typed MCP tools via AgentCore Gateway, not embedded. Do not re-derive the pipeline; only check HIPAA eligibility and find public examples of it.
  • The retired-services list (catalog-v0.md rule 4; library entry retired-services-to-avoid-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, Connect Voice ID, Lex V1 and the rest of that entry. Only Pinpoint is still marked VERIFY there.
  • The AWS AI landscape (research/aws-ai-services-landscape/dossier.md, 2026-09-03): the Bedrock platform, model catalog, AgentCore, Managed Knowledge Base, Guardrails, Data Automation, Kiro / Quick, the 2026-07-30 closure wave, the Opus 5 ZDR vs Fable 5.1 aws_review retention difference, and the applied-AI API lifecycle table. Scouts must not redo this landscape. One exception is explicitly open: the dossier carried Bedrock's HIPAA eligibility and compliance list at Medium confidence, unchecked (dossier item F-15) — angle 2 closes that.

Genuinely unknown (what the team must find out)​

Every VERIFY marker in catalog-v0.md plus its four "Open questions for the research pass", restated here as the scout questions:

  1. For each of F0, U1, U2, U3, U4, U5, U6, P0: which public repos, Guidance, or workshops already demonstrate it, how completely, on what stack, under what license, and how recently maintained. Which items have no good public example.
  2. HIPAA on AWS in 2026: the eligible-services list for every service the catalog names; the lifecycle status and pricing of HealthLake, HealthImaging, HealthOmics, HealthScribe, Transcribe Medical, Comprehend Medical; the current Config conformance pack and Security Hub standard names; Macie for PHI; de-identification patterns; Bedrock data-retention modes as they apply to PHI.
  3. The 2026 AWS-recommended mobile stack: Amplify Gen 2 status and native Swift/Kotlin vs React Native/Flutter library coverage; AppSync vs API Gateway for mobile; Cognito mobile patterns; push notifications given Pinpoint's lifecycle (end-of-support date and named successor); Device Farm and Location Service status; getting phone-paired health devices (HealthKit, Health Connect, BLE) into IoT Core or a REST ingest.
  4. How AWS and others structure "learn a solution through a working deployment" content, and whether existing healthcare workshops already cover catalog items well enough to link rather than rebuild.

Two catalog sub-questions ride along inside those angles: whether Textract or Bedrock Data Automation is the 2026 default for document intake (U4; angle 1 via which repos exist, angle 2 via HIPAA eligibility of each), and whether Control Tower is the current landing-zone path (F0; angle 1 and angle 2).

External-safe framing​

"Public reference implementations and 2026 building blocks for a HIPAA-compliant healthcare platform on AWS: responsive web portal plus iOS and Android apps, embedded generative AI via Amazon Bedrock and AgentCore, and custom ML models on SageMaker AI trained from high-volume connected-device (remote patient monitoring) data. Covers HIPAA-eligible services and BAA, AWS health-specific services (HealthLake, HealthImaging, HealthOmics, HealthScribe, Transcribe Medical, Comprehend Medical), the Amplify Gen 2 mobile stack and push-notification path after Amazon Pinpoint, IoT Core ingestion of phone-paired devices, and how AWS Solutions Library, aws-samples and Workshop Studio structure learn-by-deploying content."

The catalog content — use-case names, the stack spine, the tier structure, the service list — is public-safe and may be used verbatim in queries. Scouts may quote catalog-v0.md sections when searching.

Internal context (not for external queries)​

Per D-003. The only non-public elements are the requester's identity and her consulting framing:

  • Do not use the requester's name, email, AWS account identifiers, or CLI profile names in any query, source note, or artifact.
  • Do not mention any client organization or client account. Describe the requester, if at all, only as "an AWS-using consultant/engineer".
  • The internal reason for the catalog (a consultant's demonstration portal) is not itself sensitive, but scouts should phrase queries in terms of the platform being built, not the person building it.

Nothing else in the topic is proprietary.

Angle set​

The default set (market-size / competitors / monetization) is dropped entirely: this is an inventory-and-validation topic with no sizing or business-model question attached. Four angles replace it. Each scout reads catalog-v0.md before starting and writes to sources/<angle-slug>.md.

1. existing-reference-repos​

For each catalog item — F0 (HIPAA-ready landing zone), U1 (patient portal + companion mobile app), U2 (remote patient monitoring at scale, including the Tier 3 IoT→Flink→SageMaker→Greengrass edge-scoring path), U3 (ambient clinical documentation), U4 (intelligent document intake), U5 (population-health data platform and risk models), U6 (Connect contact center with AI agents), P0 (education portal) — find the public artefacts that already demonstrate it:

  • GitHub organisations: aws-samples, awslabs, aws-solutions, aws-amplify samples, aws-ia, plus healthcare-specific reference architectures from AWS partners or the community.
  • AWS Solutions Library: both "Solutions" (deployable) and "Guidance" (architecture + sample code) pages.
  • AWS workshops: catalog.workshops.aws / Workshop Studio, and any healthcare or life-sciences workshop series.

For each artefact record: URL; maintainer/organisation; last-commit or last-updated date; stack and IaC (CDK, CloudFormation, Terraform, SAM, Amplify); license (note MIT-0 vs Apache-2.0 vs other; flag anything non-permissive); which catalog item and which tier(s) it covers; and an honest coverage estimate (full / partial / one component only). Also record the deploy story: does it actually go from empty account to running system, or is it a snippet?

Deliver two tables: (a) artefacts found, keyed by catalog item and tier; (b) catalog items and tiers with no good public example, which is where new work has demonstration value. Note explicitly any repo that still uses a retired service from catalog-v0.md rule 4 (it may still be worth forking for structure, but it cannot be linked as-is).

2. healthcare-compliance-building-blocks​

HIPAA on AWS as of September 2026, scoped to what the catalog actually uses:

  • BAA: current mechanism (AWS Artifact self-service acceptance), whether it is account- or organisation-level, and whether any service in the catalog requires additional opt-in.
  • HIPAA-eligible services list: for each of the following, state eligible / not eligible / not found on the list, with the retrieval date: Bedrock (including AgentCore, Knowledge Bases, Guardrails, Data Automation), HealthLake, HealthImaging, HealthOmics, HealthScribe, Transcribe Medical, Comprehend Medical, Textract, Connect (and Lex V2), Amplify (Hosting and the libraries/Gen 2 backend), AppSync, API Gateway, IoT Core, Greengrass v2, Kinesis Data Streams, Firehose, Managed Service for Apache Flink, Timestream for InfluxDB, S3 Tables, Athena, Glue, Lake Formation, SageMaker AI (Feature Store, Pipelines, endpoints), Amazon Quick, Step Functions, EventBridge, SNS, ECS Fargate, Aurora, DynamoDB, ElastiCache for Valkey, Cognito, CloudFront, WAF, Macie, Security Hub, Config, GuardDuty, Control Tower.
  • Health-specific services: lifecycle status (GA / preview / maintenance / closed), region availability, and headline pricing units for HealthLake, HealthImaging, HealthOmics, HealthScribe, Transcribe Medical, Comprehend Medical. State plainly if any has been quietly de-emphasised (no What's New posts in 12+ months) vs officially retired.
  • Controls and evidence: the current name of the Config HIPAA conformance pack and the Security Hub standards relevant to HIPAA (e.g. AWS Foundational Security Best Practices, NIST 800-53), Macie's PHI/PII managed data identifiers, Control Tower's current status as the landing-zone path.
  • PHI handling patterns: de-identification (Comprehend Medical PHI detection, Macie, any newer Bedrock-based approach), and the Bedrock data-retention / abuse-detection modes and model-provider retention differences as they apply to PHI in prompts — build on dossier §2.E.4 rather than re-deriving it, and close dossier item F-15 (Bedrock FAQ no-training / no-sharing statement and compliance list).

Primary sources only for eligibility claims: aws.amazon.com/compliance/hipaa-eligible-services-reference, the Services in Scope page, and service docs. A blog post saying a service "can be used for healthcare" is not an eligibility claim.

3. mobile-and-device-stack​

The 2026 AWS-recommended path for iOS + Android + responsive web, scoped to U1 and U2:

  • Amplify Gen 2: current status; which client libraries are actively maintained (Swift, Android/Kotlin, JavaScript/React, React Native, Flutter) and at what version/parity; whether Gen 1 is in maintenance; Amplify Hosting status; any first-party or community Amplify healthcare samples.
  • API layer for mobile: AppSync (GraphQL, real-time subscriptions, Events API) vs API Gateway REST/WebSocket in front of the FastAPI backend — what AWS currently recommends for a mobile-plus-web app and whether either has a HIPAA caveat (cross-check angle 2).
  • Auth: Cognito user pool patterns for mobile (managed login, passkeys/WebAuthn, MFA, social IdP, token handling on device), and any 2025–2026 Cognito changes relevant to mobile.
  • Push notifications: Amazon Pinpoint's lifecycle — verify the end-of-support date and the AWS-named successor(s) for push, SMS, and email (SNS mobile push, AWS End User Messaging, SES, EventBridge), and what the migration path is.
  • Device testing and location: AWS Device Farm status; Amazon Location Service status and relevance.
  • Phone-paired health devices: the supported ways to get HealthKit (iOS), Health Connect (Android), and BLE-connected cuffs/meters/wearables into the backend — AWS IoT Device SDK from a phone vs REST ingest vs IoT Core credentials-provider patterns — with any public sample repos (cross-reference angle 1 rather than duplicating its table).

Report each item as "recommended by AWS docs", "supported but not recommended", or "no AWS guidance found", dated.

4. education-portal-and-workshop-patterns​

How AWS and others structure "learn a solution through a working deployment", to shape P0 and decide link-vs-rebuild:

  • Workshop Studio / catalog.workshops.aws: page and module structure, how deployment is provisioned (event-engine accounts vs own account), and the current inventory of healthcare / life-sciences / HIPAA workshops, mapped against catalog items F0–U6 with a "covers well enough to link" judgement.
  • AWS Solutions Library: the page anatomy of a Guidance (overview, architecture diagram, well-architected pillars, sample code, deployment guide, cost estimate) and of a Solution, and whether healthcare Guidance already covers catalog items.
  • aws-samples repo conventions: the README + architecture diagram + CDK deploy + cost + cleanup pattern, CONTRIBUTING/LICENSE conventions, and any repo-template used across aws-samples.
  • Documentation-from-code patterns: approaches for generating portal content from repos' own README/ADR/CDK metadata so the portal does not drift (docs-as-code toolchains, ADR conventions, CDK construct documentation), including non-AWS examples if they are the clearer pattern.
  • Comparable education portals: 2–3 examples (AWS-run or third-party) of a site that teaches cloud services through end-to-end deployable use cases, to note what works.

Deliver a short recommendation per catalog item: link out / fork and adapt / build new, from the content-structure point of view (angle 1 gives the repo-coverage point of view; the comparator reconciles).

Sourcing rules (apply to every angle)​

  1. Date every claim. Each fact carries the date of the source (announcement date, doc "last updated" date, repo last-commit date, or retrieval date). Undated claims are not usable.
  2. Prefer primary sources: aws.amazon.com product, pricing, and compliance pages; docs.aws.amazon.com; AWS What's New; AWS official blogs; the repositories themselves (commit history, README, LICENSE). Third-party posts are leads only and must be confirmed against a primary source before a claim is recorded.
  3. Distinguish "quiet" from "retired". A service with no recent releases is "no What's New since ", not "deprecated", unless AWS has posted an end-of-support notice.
  4. Cite catalog-v0.md by item and tier (e.g. "U2 Tier 3") so the comparator can map findings back to the hypothesis.
  5. Do not re-research the dossier. If a Bedrock/AgentCore/Quick/Kiro fact is needed, cite research/aws-ai-services-landscape/dossier.md by section and move on.

Output contract​

  • Each scout writes exactly one file: research/aws-demo-catalog/sources/<angle-slug>.md, where the slug is one of existing-reference-repos, healthcare-compliance-building-blocks, mobile-and-device-stack, education-portal-and-workshop-patterns.
  • Each source file opens with the angle name, the date, and a one-paragraph summary; then the findings tables described above; then a "gaps" section listing what was searched for and not found; then the source list with dates.
  • Every finding that touches a catalog item names the item and tier.
  • The comparator reads all four sources/*.md and writes comparison.md; the validator writes validation.md; the lead writes dossier.md and, as the actionable deliverable, a catalog-v1.md that applies keep / merge / drop and fork / link / build decisions to every item in catalog-v0.md.
  • STATUS.md advances through triage: done → scouts: done (4 angles) → comparator: done → validator: done → complete.

Open questions​

Flagged rather than assumed. The pipeline can proceed on the stated defaults; the requester should confirm them before the catalog is finalised.

  1. Community vs AWS-official repos. Angle 1 is scoped to AWS-official organisations first, with community/partner repos included when they are the only coverage. If the portal must only link AWS-maintained code, community finds should be marked as such. Default: include both, label provenance.
  2. Single-account vs organisation demo for F0. Control Tower and an org trail require an Organizations management account; a public "empty account → running" repo may only be reproducible in a single account. Angle 1 should note which F0 examples assume an organisation. Default: F0 must work in a fresh single account, with the organisation layer as an optional extension.
  3. Target region(s). The health-specific services and some AI services have limited region availability, and HIPAA eligibility is region-agnostic but availability is not. Default: us-east-1 and us-west-2; angle 2 should flag any catalog service unavailable in either.
  4. Scale target for "large device-data volumes". Not quantified in the topic. Default: the 100K-user / tens-of-thousands-concurrent envelope from the library's high-scale-app-tier-defaults entry, so the catalog stays consistent with prior work.
  5. License constraint for forking. The portal's repos will be public. Whether copyleft or non-permissive licenses are acceptable to fork from is unstated. Default: permissive only (MIT, MIT-0, Apache-2.0); angle 1 flags anything else.
  6. Native vs cross-platform mobile. The catalog leaves this VERIFY. Angle 3 reports both paths; the choice is a build decision for the lead, not a research assumption.
  7. Depth on U6. Marked optional in catalog-v0.md. Default: scouts give U6 lighter coverage (one pass, no deep dive) unless a strong existing Guidance makes it a cheap win.
  8. Bedrock model-retention detail. The catalog references Opus 5 ZDR vs Fable 5.1 aws_review from the dossier. Angle 2 should only confirm how those modes interact with PHI, not re-establish the modes themselves.