# 1 - AWS Maps to the Logical Design

We map this logical design cleanly onto native AWS infrastructure across five operational layers. Entry points use Route 53, CloudFront, WAF, API Gateway, and enterprise identity. The runtime leverages Step Functions, containers, Lambda, and SQS queues. AI and data services run on Amazon Bedrock, Guardrails, knowledge retrieval, and secure data stores. Enterprise integration connects to FHIR, scheduling, and X12 EDI platforms. Finally, security control is anchored by KMS, Secrets Manager, CloudTrail, and GuardDuty. This ensures trusted systems and people retain absolute control over transactions and material actions.

# 2 - Approve the Two-POC Path

We ask for three clear decisions today. First, approve the two proof of concepts as our interview targets. Second, use referral matching for the first production enablement plan. Third, build all core platform services once for maximum reuse. Our immediate next step is focused discovery to validate client systems, data owners, and security rules.

# 3 - Six Patterns Are Reused Across All Workflows

Six core patterns power every workflow across the enterprise, giving us a repeatable formula for success. Rules handle hard needs while AI handles ambiguity, transforming diverse source formats into clean, common records. Enterprise tools fetch trusted facts, and approved runbooks ground every explanation in official policy. Workflow state tracks every step, while clear evidence triggers human review when confidence drops. Building these elements once lets us deploy new use cases with speed and confidence. And that brings us to how we manage our trust boundaries.

# 4 - Keep Trusted Facts Outside the Model

We enforce a strict boundary to keep trusted facts completely outside the AI model. AI reads unstructured text, explains results, investigates exceptions, and chooses allowed tools. But fixed backend services control the truth, enforcing hard rules, checking transactions, and saving workflow state. And human specialists review exceptions, approve changes, and own final operations. AI can recommend and explain, but trusted systems and people always keep control. This design principle ensures safety across every transaction and leads directly into our logical architecture.

# 5 - AI Acceleration as a Service

Welcome everyone to our solution architecture review. Today we are looking at AI Acceleration as a Service, a unified approach built around two working proof of concepts running on a single reusable healthcare AI platform. We know payers face immense pressure to modernize care access and core operations without risking compliance or security. And here's why our design matters. We've built an editable architecture and runnable proof of concepts that prove you can scale safely. Let's explore how we start this journey together.

# 6 - The Twelve-Week Plan Builds Value and Reuse

We organize delivery into a practical twelve-week plan. Weeks one and two focus on discovery, systems, and synthetic data. Weeks three and four lock down architecture and contracts. Weeks five through eight build the shared runtime and core use cases. Weeks nine and ten validate the solution through stakeholder and security reviews. And the final weeks finalize the production and scaling plan.

# 7 - The POCs Are Working Today

We see proof that these solutions work right now. Automated test execution passed six of six tests in our validation report. The current POCs use local deterministic implementations for workflow contracts, fixed controls, task structure, tool boundaries, and exception paths. They do not call an LLM or Amazon Bedrock. Production can use an approved model gateway without changing the contracts. Moving forward, these five use cases naturally form two powerful value streams.

# 8 - One Shared Platform Supports Every Use Case

Every use case runs on one shared platform that spans from member intake to enterprise connectors. Experience channels and access controls sit on top, protecting identity and managing API traffic. In the center, our agentic platform combines task state, AI services, and fixed validation rules. Below that, standardized connectors talk to FHIR, enrollment, and claims systems. And running across every single layer are non-negotiable controls for security, audit, monitoring, and recovery. This layered design gives us a solid foundation for the small, reusable runtime we built next.

# 9 - The POC Runtime Is Small and Reusable

Our proof of concept proves that a small runtime handles complex payer workflows. The current POCs use local deterministic implementations to test workflow contracts, fixed controls, task structure, tool boundaries, and exception paths. They do not call an LLM or Amazon Bedrock. Production can use an approved model gateway without changing those contracts. Automated test execution, 6 of 6 passed. Synthetic data flows into the API endpoints and emerges as typed outputs with clear audit trails. And each workflow starts with services that are already in place.

# 10 - Five Use Cases Form Two Value Streams

Looking across the enterprise, we organize five key use cases into two distinct value streams. On the left, care access and navigation covers specialist network foundation, referral matching, scheduling assistants, and procedure readiness. On the right, core operations focuses on claims ingestion and normalization. Instead of building separate point solutions for each need, you build common platform parts once. You reuse task instructions, workflow state, and audit services across every single workflow. Let's see how we prioritize them based on business value and implementation lift.

# 11 - Production Needs Clear Safety and Recovery Rules

Production scale requires strict controls across security, quality, reliability, and audit. We enforce least privilege and PHI limits while keeping AI grounded in approved knowledge and typed outputs. Workflow reliability demands saved state and replay mechanisms. Meanwhile, claims keep their fast, fixed processing paths, and every automated action leaves a complete audit trail. And that leads directly to our first production target.

# 12 - Start With Two Proven Workflows

We recommend starting your AI modernization journey with two specific, proven workflows. On the care access side, UC2 handles intelligent referral matching, reading referrals, finding valid providers, applying payer rules, and routing complex cases. On the core operations side, UC5 automates 837P claim ingestion, validation, and exception handling. Both workflows follow the exact same structural pattern. But for our immediate production focus, we recommend beginning your detailed enablement plan with UC2. Now let's look at the implementation evidence behind these choices.

# 13 - Reuse Makes the Roadmap Faster

A strong foundation makes future expansion much faster. Automated test execution, 6 of 6 passed. Productionize UC2 with real payer integrations, then reuse those components for UC3, UC4, UC5, and UC1. Each workflow starts with services, controls, and tests that are already in place. Let us look at the final decisions needed to move ahead.

# 14 - The Two POCs Tell One Strong Story

We bring both proof points together because care access and claims operations share the exact same technical backbone. On one side, you have the referral matching workflow moving from understanding to routing. On the other, claims ingestion moves from normalization to recovery. And in the middle, they share task instructions, tool contracts, workflow state, and enterprise guardrails. This proves we aren't building isolated point solutions. We are building a unified platform that supports both care access and claims operations with equal strength. And this design leads right into our core operational patterns.

# 15 - UC2 Is the First Production Target

Referral matching is our first production target. We start by connecting real referral streams or FHIR interfaces to live member and provider data. Then we configure authorization rules, set up human review queues, and define strict evaluation thresholds. This prepares the system for reliable operations and a structured rollout.

# 16 - UC2 Passed Three Clear Scenarios

Automated test execution, 6 of 6 passed. In the normal knee referral, the engine successfully routed to provider P100 with a high confidence score. In the network guardrail test, provider P101 was safely excluded before ranking because its PPO product wasn't supported. And when a referral was ambiguous between orthopedics and neurology, the system flagged it for human review. Every result returns rules, evidence, confidence, and audit events. Now let's examine how we apply a similar boundary to claims ingestion.

# 17 - UC2 Filters First, Then Ranks

Here is how UC2 puts safety into practice by enforcing hard business filters before any AI ranking happens. First, the engine reads the referral and pulls provider facts, then it eliminates any doctor who fails network or new-patient rules. Only valid providers make it to the ranking stage for clinical fit and distance. And notice the fixed boundary at the bottom: the reasoning layer never invents a provider or changes network status. Automated test execution, 6 of 6 passed. Let's look at the exact scenarios this workflow passed.

# 18 - UC5 Passed Three Clear Scenarios

Automated test execution, 6 of 6 passed. A valid 837P claim passed right through to json creation with investigation bypassed entirely. When a rendering provider NPI was missing, the validator caught it, and the system routed it to EDI Operations with a 0.98 confidence score. During a MAP-204 downstream failure, the system identified the root cause and routed it to Claims Integration Support. Every result returns complete validator evidence, runbook sources, confidence, and audit events. Productionize UC2 with real payer integrations.

# 19 - UC5 Keeps AI Off the Successful Claim Path

With UC5, we make sure AI stays completely off the successful, high-volume claim path. Standard 837P claims are parsed, validated, and normalized using fixed X12 logic and sent straight to downstream processing without touching the model. AI only steps in when an exception occurs, gathering the error logs and approved runbook entries to explain the root cause and recommend an operations queue. Remember this model boundary: AI reads, explains, investigates, and recommends, but never validates syntax or decides whether a claim gets paid. Here are the three scenarios we validated for this use case.

# 20 - UC2 Has the Best Value-to-Lift Position

When we evaluate our portfolio on business value versus implementation lift, UC2 stands out with the best position. It delivers high business value while requiring lower implementation lift. We also select UC5 because it brings strong payer value alongside a different technical pattern for core operations. Together, these choices maximize your return on investment while keeping engineering complexity manageable. And as you can see, both POCs tell one strong, unified story for the enterprise.