Business context, continued

Use case matrix

Each use case has a business outcome, a primary architecture pattern, and a portfolio role. UC2 and UC5 are the implemented POCs.

Use case	Business outcome	Primary architecture pattern	Portfolio role
UC1, Procedure Readiness for Scheduling	Identify clinical and administrative readiness conditions before scheduling.	Evidence collection, policy evaluation, deterministic readiness rules, and exception review.	Future payer-provider workflow.
UC2, Intelligent Referral Matching and Routing	Identify appropriate in-network specialists and route referrals with evidence.	Document understanding, authoritative search, deterministic filters, ranking, and explanation.	POC 1 and detailed enablement plan.
UC3, Automated Scheduling and Admin Assistant	Improve member self-service and administrative coordination.	Conversation, workflow state, provider context, slot discovery, confirmation, and transaction control.	Next care-access workflow.
UC4, Specialist Network Integration	Create trusted specialist and network context across payer sources.	Entity resolution, taxonomy, provenance, network-product mapping, and data-quality workflow.	Strategic data foundation.
UC5, Claims Ingestion and Normalization	Normalize claim intake and improve exception investigation.	Deterministic X12 pipeline, canonical data, grounded investigation, and operational routing.	POC 2.

01 · Opening

Autonomize · Solution Architecture Review

AI Acceleration
as a Service

Two working POCs on one reusable healthcare AI platform

Healthcare Payer | Solution Architecture | Interview Presentation

Automated test execution: 6 of 6 passed.

02 · Opening

Table of contents

What I will cover

Opening

03What I was asked to do

Portfolio

Use cases

Recommendation

14Executive recommendation

POC deep dives

Selection

Platform

Production

Plan

03 · Opening

Engagement scope and objectives

What I was asked to do

The assignment covers five candidate payer use cases and the deliverables required around them.

The assignment

Review five candidate healthcare payer use cases.
Score them in a value-versus-lift evaluation and recommend which to build first.
Implement two POCs and show a shared logical architecture behind them.
Provide an AWS production reference architecture.
Provide a detailed AI enablement plan for the selected primary use case, UC2.

Explicit delivery requirements

A twelve-week delivery plan with a delivery-team estimate.
Production-readiness criteria and a sequenced roadmap.
Practical POCs with synthetic data and reproducible scenarios.
Agentic patterns combined with deterministic healthcare processing and human review.
Editable deliverables: Word document, Mermaid diagram sources, and slide content.

04 · Portfolio

Business context

Five use cases form two value streams

The care-access stream combines specialist-network intelligence, referral matching, scheduling, and procedure readiness. The payer-operations stream applies intelligent exception handling to claims ingestion.

Value stream 1

Care Access and Navigation

UC4

Specialist Network Integration

Strategic data foundation.

UC2POC 1

Intelligent Referral Matching and Routing

POC 1 and detailed enablement plan.

UC3

Automated Scheduling and Admin Assistant

Next care-access workflow.

UC1

Procedure Readiness for Scheduling

Future payer-provider workflow.

Value stream 2

Core Payer Operations

UC5POC 2

Claims Ingestion and Normalization

POC 2.

Instead of five separate applications, common platform parts are built once and reused: task instructions, workflow state, tool contracts, knowledge, audit, and review.

05 · Portfolio

Business context, continued

Use case matrix

Each use case has a business outcome, a primary architecture pattern, and a portfolio role. UC2 and UC5 are the implemented POCs.

Use case	Business outcome	Primary architecture pattern	Portfolio role
UC1, Procedure Readiness for Scheduling	Identify clinical and administrative readiness conditions before scheduling.	Evidence collection, policy evaluation, deterministic readiness rules, and exception review.	Future payer-provider workflow.
UC2, Intelligent Referral Matching and Routing	Identify appropriate in-network specialists and route referrals with evidence.	Document understanding, authoritative search, deterministic filters, ranking, and explanation.	POC 1 and detailed enablement plan.
UC3, Automated Scheduling and Admin Assistant	Improve member self-service and administrative coordination.	Conversation, workflow state, provider context, slot discovery, confirmation, and transaction control.	Next care-access workflow.
UC4, Specialist Network Integration	Create trusted specialist and network context across payer sources.	Entity resolution, taxonomy, provenance, network-product mapping, and data-quality workflow.	Strategic data foundation.
UC5, Claims Ingestion and Normalization	Normalize claim intake and improve exception investigation.	Deterministic X12 pipeline, canonical data, grounded investigation, and operational routing.	POC 2.

06 · Use cases

Use case overview · UC1

UC1 - Procedure Readiness for Scheduling

My understanding

UC1 identifies clinical and administrative readiness conditions before scheduling.

Architecture pattern and portfolio role

Objective. Identify clinical and administrative readiness conditions before scheduling.
Pattern. Evidence collection, policy evaluation, deterministic readiness rules, and exception review.
Portfolio role. Future payer-provider workflow.

Source-grounded detail

Reusable pattern coverage: readiness rules and explanations, procedure evidence model, authorization / provider / facility / scheduling tools, readiness and authorization policy, missing-prerequisite tracking, and blocker evidence for review.
UC1 has meaningful value, but complete readiness also depends on provider-side clinical and operational ownership.

Status in this engagement

Not implemented as a POC. Presented as a future payer-provider workflow.

Business value /20

Implementation lift /20

Portfolio leverage /20

Roadmap role

Sequence 6. Add UC1 Procedure Readiness, reusing policy, document, authorization, provider, state, and review services. New capability added: procedure evidence model, readiness rules, and payer-provider coordination.

Recommendation: Roadmap and cross-enterprise candidate.

07 · Use cases

Use case overview · UC2

UC2 - Intelligent Referral Matching and Routing

My understanding

UC2 identifies appropriate in-network specialists and routes referrals with evidence.

Architecture pattern and portfolio role

Objective. Identify the specialist need from referral text, apply hard payer requirements, rank only valid candidates, explain the result, and route or review.
Pattern. Document understanding, authoritative search, deterministic filters, ranking, and explanation.
Portfolio role. POC 1 and detailed enablement plan.

Source-grounded detail

The POC uses synthetic referral and provider data. It does not connect to a production EHR, enrollment platform, provider directory, network-contracting platform, authorization system, or routing queue.
It proves the task structure, API contracts, deterministic filter order, ranking approach, explanation structure, review logic, and audit output.
The current POC ranking weights are 55 percent clinical and subspecialty relevance, 30 percent normalized quality, and 15 percent distance. These are POC implementation settings and require business validation before production.

Status in this engagement

POC 1, implemented. Also the selected use case for the detailed AI enablement plan.

Business value /20

Implementation lift /20

Portfolio leverage /20

Roadmap role

Sequence 2. Productionize UC2 with real payer connectors, PHI controls, operations, resilience, and monitoring.

Recommendation: Select as POC 1 and detailed enablement plan.

08 · Use cases

Use case overview · UC3

UC3 - Automated Scheduling and Admin Assistant

My understanding

UC3 improves member self-service and administrative coordination for scheduling.

Architecture pattern and portfolio role

Objective. Improve member self-service and administrative coordination.
Pattern. Conversation, workflow state, provider context, slot discovery, confirmation, and transaction control.
Portfolio role. Next care-access workflow.

Source-grounded detail

Reusable pattern coverage: booking and confirmation controls, intent and appointment context, provider / schedule / communication tools, administrative guidance knowledge, confirmation-failure-escalation state, and appointment and escalation explanation.
Risk noted in the source: scheduling connectivity limits automation for UC3. Keep UC3 on the roadmap until availability and booking interfaces are confirmed.

Status in this engagement

Not implemented as a POC. Presented as the next care-access workflow.

Business value /20

Implementation lift /20

Portfolio leverage /20

Roadmap role

Sequence 3. Extend to UC3, reusing member, referral, provider, coverage, workflow, audit, and human review. New capability added: conversation state, availability, booking confirmation, and communications.

Recommendation: Select as the next care-access workflow.

09 · Use cases

Use case overview · UC4

UC4 - Specialist Network Integration

My understanding

UC4 creates trusted specialist and network context across payer sources.

Architecture pattern and portfolio role

Objective. Create trusted specialist and network context across payer sources.
Pattern. Entity resolution, taxonomy, provenance, network-product mapping, and data-quality workflow.
Portfolio role. Strategic data foundation.

Source-grounded detail

Reusable pattern coverage: identity and network validations, trusted specialist profile, directory / contracting / credentialing tools, taxonomy and data-quality rules, source-conflict resolution, and source and quality explanation.
UC4 has broad strategic value, but its production scope includes identity resolution, source reconciliation, product participation, and provider-data governance.
UC4 should be treated as the provider-intelligence foundation that strengthens UC2 and UC3.

Status in this engagement

Not implemented as a POC. Presented as the strategic provider-data foundation.

Business value /20

Implementation lift /20

Portfolio leverage /20

Roadmap role

Sequence 4. Mature UC4, reusing the provider contract and data-quality feedback. New capability added: identity resolution, provenance, network-product mastering, and stewardship.

Recommendation: Treat as the strategic provider-data foundation.

10 · Use cases

Use case overview · UC5

UC5 - Claims Ingestion and Normalization

My understanding

UC5 normalizes claim intake and improves exception investigation.

Architecture pattern and portfolio role

Objective. Parse and check an X12 837P claim, create a canonical claim, and use AI-assisted investigation for exceptions.
Pattern. Deterministic X12 pipeline, canonical data, grounded investigation, and operational routing.
Portfolio role. POC 2.

Source-grounded detail

The use case improves intake and operations. It does not perform adjudication or decide whether a claim should be paid.
X12 identifies the 837 transaction set as the healthcare claim format used to submit and transfer professional, institutional, and dental claims and encounters to payers. This supports keeping transaction parsing and syntax validation deterministic.
The successful path bypasses investigation. The exception path collects validator output or downstream error evidence and compares it with the approved runbook.

Status in this engagement

POC 2, implemented.

Business value /20

Implementation lift /20

Portfolio leverage /20

Roadmap role

Sequence 5. Expand UC5 claims operations, reusing canonical claim, runbook, investigation, routing, and audit. New capability added: production EDI, log correlation, work queues, replay, and scale.

Recommendation: Select as POC 2.

11 · Portfolio

Value-versus-lift evaluation

UC2 has the best value-to-lift position

Business value covers payer ownership, operational impact, experience impact, and strategic reuse. Implementation lift covers integration, data, AI workflow, and production complexity.

Circle size shows portfolio leverage. A solid circle marks a selected POC. The best position is upper left. Exact scores appear on the next slide.

Value, lift, and portfolio leverage scores for the five use cases
Use case	Business value out of 20	Implementation lift out of 20	Portfolio leverage out of 20
UC1, Procedure Readiness	13	17	14
UC2, Referral Matching	18	13	19
UC3, Scheduling Assistant	17	14	18
UC4, Specialist Network	18	17	18
UC5, Claims Ingestion	18	16	18

12 · Portfolio

Value-versus-lift evaluation, continued

Exact scorecard

Full use case names with the exact scores behind the plot. UC2 and UC5 are highlighted as the selected POCs.

Use case	Value /20	Lift /20	Leverage /20	Value - lift
UC1, Procedure Readiness	13	17	14	-4
UC2, Referral Matching	18	13	19	+5
UC3, Scheduling Assistant	17	14	18	+3
UC4, Specialist Network	18	17	18	+1
UC5, Claims Ingestion	18	16	18	+2

13 · Portfolio

Value-versus-lift evaluation, continued

Selection rationale

Five conclusions follow from the scores.

Why UC2 and UC5 were selected

UC2 has the strongest value-versus-lift position and the highest portfolio leverage.
UC5 provides a complementary payer operations pattern with a practical focused synthetic POC.
UC3 has strong value, but its most important production outcome depends on external provider scheduling connectivity.
UC4 has broad strategic value, but production scope includes identity resolution, source reconciliation, product participation, and provider-data governance.
UC1 has meaningful value, but complete readiness also depends on provider-side clinical and operational ownership.

14 · Recommendation

Executive recommendation

Start with two proven workflows

UC2 supports care access. UC5 supports core payer operations. Both run on one shared platform design.

POC 1 · Care access and navigation

UC2 - Intelligent Referral Matching and Routing

Reads the referral, finds valid providers, applies fixed payer rules, ranks valid choices, explains the result, and routes the referral.
Selected for the detailed AI enablement plan because it exercises the broadest set of shared platform capabilities.

POC 2 · Core payer operations

UC5 - Claims Ingestion and Normalization

Parses and checks a synthetic X12 837P claim, creates a common claim record, and helps staff investigate exceptions.
Improves intake and operations. It does not perform adjudication or decide whether a claim should be paid.

Three decisions requested today

1. Approve UC2 and UC5 as the two interview POCs.
2. Use UC2 as the first production enablement plan.
3. Build the common task, tool, knowledge, state, audit, and evaluation services once.

Immediate next step: a focused discovery to confirm client systems, data owners, operating teams, security rules, and acceptance measures.

15 · POC deep dives

UC2 implemented workflow

UC2 filters first, then ranks

Product participation and accepting-new-patient status are enforced before ranking. The reasoning layer never invents a provider or changes network status.

01Read

Referral intake and structured extraction.

02Search

Provider tool returns authoritative candidates.

03Filter

Deterministic network and new-patient filters run before ranking.

Hard filters precede ranking

Product network participation required. Accepting new patients required.

Deterministic order

The reasoning layer never invents a provider and never changes network status.

16 · POC deep dives

UC2 implemented workflow, continued

UC2 ranks, explains, and routes

Only valid candidates are ranked. Every result returns evidence, rules, score, and confidence.

04Rank

Only valid candidates are ranked.

05Explain

Evidence, rules, score, and confidence.

06Route

Route the referral or send it to human review.

POC ranking weights

55% clinical and subspecialty relevance, 30% normalized quality, 15% distance. POC settings requiring business validation before production.

Review path

If specialty intent is unclear or confidence is low, the workflow does not rank providers and routes the case to a referral specialist.

Endpoint contract

POST /referrals/match

Receives a referral identifier, member identifier, referral text, ZIP code, product, and preferred language. Returns interpreted need, rules applied, excluded candidates, ranked candidates, explanation, confidence, review flag, and audit events.

17 · POC deep dives

UC2 validated scenarios

UC2 passed three clear scenarios

Every result returns rules, evidence, confidence, review state, and audit events.

Scenario	Input and control	Validated output
Normal referral	Synthetic knee referral for a PPO member.	Status ROUTED. Provider P100, Capital Ortho Sports Medicine, ranks first with match score 0.951. Human review is false.
Network guardrail	A clinically strong provider participates in HMO but not the member's PPO product.	Provider P101 is placed in excluded candidates before ranking, with reason “Not in member product PPO”.
Ambiguous referral	Referral supports both Orthopedic Surgery and Neurology.	Status REVIEW_REQUIRED, confidence 0.58, no ranked candidates, and human review is true.

Launch UC2 demonstration (REF-002)Synthetic dataAutomated test execution: 6 of 6 passed.

Implementation boundary

Deterministic POC demonstration using synthetic data. These are the saved tested outputs of the supplied FastAPI POC. They are not an LLM result, a Bedrock result, or a production result.

18 · POC deep dives

UC5 implemented workflow

UC5 keeps AI off the successful claim path

Successful claims are parsed, validated, and normalized deterministically and bypass investigation. AI investigation runs only on the exception path.

01Receive

Synthetic 837P transaction received.

02Parse

Deterministic X12 parsing.

03Validate

Required-field validation.

The POC does not

Validate X12 through AI, adjudicate payment, change financial values, or invent identifiers.

Endpoint contract

POST /claims/process

Receives a claim identifier, an X12 string, and an optional simulated downstream error. The parser extracts member identifier, rendering-provider NPI, claim number, total charge, diagnosis code, procedure code, and line charge.

19 · POC deep dives

UC5 implemented workflow, continued

UC5 normalizes, then branches

Successful claims bypass investigation. Exceptions open an investigation case with grounded evidence.

04Normalize

Canonical claim JSON created.

05Accepted / Investigate

Successful claims bypass investigation. Exceptions open an investigation case.

06Explain and route

Root cause, runbook evidence, and queue.

Successful path

A successful claim does not call the investigation flow. This protects throughput, latency, cost, and transaction integrity. AI services scale according to exception volume rather than total claims volume.

20 · POC deep dives

UC5 approved knowledge

Investigation is grounded in an approved runbook

The exception path compares validator output or downstream error evidence with the approved claims runbook.

Approved claims runbook

VAL-RENDERING-NPI - The professional claim is missing a rendering provider NPI.Route to EDI operations / trading partner correction. Do not infer or invent the provider identifier.
MAP-204 - A downstream mapping step failed while transforming claim line diagnosis pointer information.Route to claims integration support. Compare the active trading-partner mapping with the canonical mapping and replay only after correction.

The investigation assistant may explain and route an exception. It must not change claim financial values, invent missing identifiers, or adjudicate payment.

21 · POC deep dives

UC5 validated scenarios

UC5 passed three clear scenarios

Every result returns validator evidence, runbook sources, confidence, and audit events.

Scenario	Control	Validated output
Valid claim	Complete required values.	Status ACCEPTED, canonical claim created with rendering-provider NPI 1234567890, and the audit states that successful processing bypassed investigation.
Missing rendering-provider NPI	Required provider value omitted.	Status EXCEPTION, error VAL-RENDERING-NPI, grounded explanation, route to EDI Operations / Trading Partner Correction, confidence 0.98.
MAP-204 downstream failure	Valid claim plus simulated diagnosis-pointer mapping failure.	Status DOWNSTREAM_EXCEPTION, canonical claim retained, runbook evidence identified, route to Claims Integration Support, confidence 0.94.

Launch UC5 demonstration (CLM-003)Synthetic dataAutomated test execution: 6 of 6 passed.

Implementation boundary

Deterministic POC demonstration using synthetic data. These are the saved tested outputs of the supplied FastAPI POC. They are not an LLM result, a Bedrock result, or a production result.

22 · Selection

POC selection and value story

The two POCs tell one strong story

The selection is based on breadth and complementarity rather than two similar demonstrations. UC2 shows understand, match, explain, and route. UC5 shows normalize, investigate, explain, and resolve.

Care access

UC2, Referral Matching

Business story: help a member or coordinator identify an appropriate valid specialist and route the referral.
Agentic behavior: interpret clinical text, identify specialty, explain ranking, detect ambiguity, and coordinate tools.
Deterministic boundary: provider facts, network status, accepting-new-patient status, and hard filters remain authoritative and deterministic.

Core operations

UC5, Claims Ingestion

Business story: normalize a claim and help operations investigate exceptions.
Agentic behavior: explain validator output, collect evidence, identify likely root cause, and recommend a queue.
Deterministic boundary: X12 parsing, required-field validation, canonical mapping, and the successful claims path remain deterministic.

23 · Selection

POC selection and value story, continued

One platform between them

Both POCs use the same shared platform capabilities. Only the business task configuration differs.

Task and execution

Shared execution capabilities

Task instructions
Tool contracts
Workflow state

Trust and quality

Shared trust capabilities

Audit and evidence
Human review
Security and guardrails
Automated tests

24 · Selection

Implementation evidence

The POCs are working today

The supplied package is one lightweight FastAPI application that hosts both workflows using synthetic data.

Workflow endpoints

Synthetic scenarios

6 / 6

Automated tests passed

LLM or Bedrock calls

Validation evidence

Automated test execution: 6 of 6 passed.

Six automated tests cover normal, guardrail, human-review, accepted claim, known error, and downstream error paths.

Implementation boundary

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.
A production architecture can introduce an approved model gateway, such as a Bedrock-based gateway, without changing task and tool contracts.

Synthetic dataNo cloud credentials are required to run or demonstrate the POCs.

25 · Selection

Implementation evidence, continued

What the package contains

The supplied package is one lightweight FastAPI application that hosts both workflows using synthetic data.

Application and data

One lightweight FastAPI application with two workflow endpoints.
Synthetic referral, provider, and claims data.
External task instructions stored outside the runtime logic.

Services, knowledge, and evidence

Deterministic services: provider filters and ranking, X12 parsing, validation, and normalization.
Approved claims runbook knowledge used by the investigation flow.
Typed outputs, audit events, and six automated tests.

Synthetic dataAutomated test execution: 6 of 6 passed.

26 · Platform

Common patterns and reuse

Patterns one to three

All five use cases use six common patterns. Each POC therefore creates parts that can support the next workflow.

Reusable pattern	UC1	UC2	UC3	UC4	UC5
Deterministic core plus AI reasoning	Readiness rules and explanations.	Hard filters before ranking.	Booking and confirmation controls.	Identity and network validations.	X12 pipeline and exception reasoning.
Extraction, normalization, and entity resolution	Procedure evidence model.	Referral case model.	Intent and appointment context.	Trusted specialist profile.	Canonical claim model.
Enterprise tool and API orchestration	Authorization, provider, facility, scheduling.	Member, benefit, provider, network, authorization.	Provider, schedule, communication.	Directory, contracting, credentialing.	Validator, logs, claims platform, queues.

27 · Platform

Common patterns and reuse, continued

Patterns four to six

Grounded knowledge, workflow state, and explainability complete the shared pattern set.

Reusable pattern	UC1	UC2	UC3	UC4	UC5
Grounded knowledge and RAG	Readiness and authorization policy.	Specialty and routing policy.	Administrative guidance.	Taxonomy and data-quality rules.	Companion guides and runbooks.
Workflow state and exception management	Missing prerequisite tracking.	Ambiguity and routing review.	Confirmation, failure, and escalation.	Source conflict resolution.	Error case, replay, and resolution.
Explainability and human review	Blocker evidence.	Recommendation evidence.	Appointment and escalation explanation.	Source and quality explanation.	Root-cause evidence and operational route.

28 · Platform

Trust boundary

Keep trusted facts outside the model

AI can recommend and explain. Trusted systems and people keep control of transactions and material actions.

AI reasoning

Interprets and explains

Reads unstructured text and interprets ambiguity.
Explains results with evidence.
Investigates exceptions.
Coordinates allowed tools.

Deterministic services

Establish and enforce facts

Systems of record establish trusted facts.
Network and new-patient filters run before ranking.
X12 parsing, required-field checks, and canonical mapping.
Transaction controls and saved workflow state.

People

Own material actions

Review exceptions and low-confidence cases.
Approve material changes.
Own final operational disposition.

Explanation contract

Explanations show the answer, evidence, rules, confidence, and next action. They do not expose internal chain-of-thought. The platform records a concise reasoning summary and structured evidence.

29 · Platform

Target logical architecture

One shared platform supports every use case

Workflow logic stays separate from enterprise systems. Security, audit, monitoring, cost control, governance, reliability, and recovery apply to every layer.

Experience, intake, and access

Member and staff channels

Referral, document, and claims intake

Enterprise APIs

Identity, consent, authorization, and rate controls

Shared agentic AI platform

Task and state, AI services, and fixed services

Durable tasks, workflow state, tool registry, and human review

Document understanding, model gateway, RAG, matching, explanation, and evaluation

Rules, entity resolution, parsing, validation, normalization, and transaction controls

Integration and healthcare systems

Governed connector framework

EHR, FHIR, referral, and document systems

Member, benefit, authorization, provider, and network systems

Scheduling, communication, claims, EDI, logs, and work queues

30 · Platform

Target logical architecture, continued

Cross-cutting controls and layer detail

Security, audit, monitoring, cost control, governance, reliability, and recovery apply to every layer.

Cross-cutting controls

Security and PHI controls
Audit and traceability
Observability and cost
Model policy and data governance
Reliability and recovery

What each layer provides

The access layer checks identity, consent, permission, requests, and traffic limits.
The shared platform stores task instructions and workflow state.
The shared platform provides tool contracts, policy checks, human review, document reading, and model access.
The shared platform provides knowledge search, ranking, explanation, parsing, validation, normalization, and transaction controls.

31 · Platform

Implemented POC runtime

The POC runtime is small and reusable

The runtime is intentionally replaceable. A production model gateway, such as an approved Bedrock-based gateway, can replace the local implementation while preserving the task and service contracts.

Runtime element	Implemented evidence	Production evolution
API surface	GET /demo/referrals, GET /demo/claims, POST /referrals/match, and POST /claims/process.	API Gateway, enterprise identity, request policy, rate control, and service-level monitoring.
Durable tasks	Referral and claims instructions stored under app/tasks.	Versioned task registry with approval, deployment, rollback, and ownership controls.
Reasoning adapter	Local deterministic referral interpretation and claims exception reasoning.	Model gateway using approved Amazon Bedrock models or the client model service.
Enterprise tools	Synthetic provider data, deterministic claim parser, validator, normalizer, and runbook access.	Typed connectors to payer systems, FHIR APIs, EDI services, logs, and work queues.

32 · Platform

Implemented POC runtime, continued

Knowledge, state, audit, and evaluation

Knowledge, typed state and audit, and automated evaluation complete the runtime picture.

Runtime element	Implemented evidence	Production evolution
Knowledge	claims_runbook.md provides grounded entries for known errors.	Curated, approved, versioned knowledge with retrieval quality controls and citations.
State and audit	Typed response objects include status, evidence, confidence, review flags, and audit events.	Persistent workflow store, trace correlation, immutable audit history, and operational dashboards.
Evaluation	Six automated tests cover normal, guardrail, human-review, accepted claim, known error, and downstream error paths.	Golden datasets, tool-mock suites, security tests, load tests, and release gates.

Implementation boundary

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. A production architecture can introduce an approved model gateway, such as a Bedrock-based gateway, without changing task and tool contracts.

Automated test execution: 6 of 6 passed.

33 · Production

AWS production reference architecture

AWS maps to the logical design

This is a production reference implementation rather than a mandatory service list, and it is not current POC evidence. The logical capabilities remain portable.

Entry

Route 53

CloudFront

AWS WAF

API Gateway or Application Load Balancer

Amazon Cognito or enterprise identity provider

Runtime

Step Functions or containerized workflow runtime

Lambda and ECS on Fargate

EventBridge

SQS and dead-letter queues

Human review application

AI and data

Amazon Bedrock behind a model gateway

Bedrock Guardrails

Approved knowledge retrieval (Bedrock Knowledge Bases, OpenSearch Serverless)

Amazon S3, versioned and encrypted

DynamoDB or Aurora

34 · Production

AWS production reference architecture, continued

Integration and control services

Integration and security control services complete the reference implementation. This is not current POC evidence.

Integration

Connector, mapping, and validation services

FHIR and payer APIs

Scheduling and communication

X12 EDI and claims platforms

Logs, work queues, secure files, and events

Controls

KMS and Secrets Manager

PrivateLink and VPC endpoints

CloudTrail and S3 Object Lock

CloudWatch, X-Ray, and OpenTelemetry

AWS Config, Security Hub, and GuardDuty

Step Functions can coordinate explicit workflows and integrates with Amazon Bedrock for model tasks. Containerized services or Lambda can implement deterministic tools, adapters, and workflow activities. SQS and EventBridge support asynchronous work and decoupling. DynamoDB or Aurora can store workflow and business state according to transaction needs.

35 · Production

Production controls

Production needs clear safety and recovery rules

Security, scaling, reliability, observability, and human review are one connected control system.

Security, privacy, and AI governance

Identity and access: workload and user identity, least privilege, role separation, time-bound access, and tool-level authorization.
PHI protection: data minimization, encryption in transit and at rest, approved model endpoints, private network paths, secure logging, and retention controls.
Prompt and tool security: input validation, instruction hierarchy, prompt-injection defenses, tool allowlists, parameter validation, and output schemas.
Grounding: approved sources, version and effective date, citation, retrieval-quality evaluation, and blocking or review thresholds.
Model governance: approved models, documented intended use, evaluation evidence, change control, fallback, monitoring, and retirement.

36 · Production

Production controls, continued

Audit, scaling, and reliability

Workflow state persists outside the model, and every case carries a complete audit record.

Audit record

Audit: identity, case, correlation ID, input reference, model version, task version, tool calls, rules, evidence, human action, and final disposition.

Scaling and reliability

Workflow state persists outside the model. Every case receives a correlation identifier.
Asynchronous workloads use idempotency keys, retries with bounded backoff, dead-letter queues, replay, and explicit terminal states.
Successful claim transactions remain on the deterministic path and avoid model calls.
Traffic spikes use queue-based buffering, horizontal scaling, backpressure, rate limits, and workload isolation.
Regional disruption uses client-defined recovery point and recovery time objectives, replicated durable state, backup, and tested recovery.

37 · Production

Production controls, continued

Observability and human review

Operations measure business outcomes, system health, model behavior, and cost, and people own material actions.

Observability

Observability covers business outcomes, system health, model behavior, tool behavior, security signals, and cost. Core metrics include workflow volume, state duration, exception rate, human-review rate, tool success, tool latency, model latency, grounded-response rate, guardrail interventions, token usage, cost per case, and final disposition.

Human review

Review triggers: low confidence, ambiguous interpretation, conflicting source facts, material correction, and unknown pattern. Reviews have approved reviewer roles, service levels, disposition codes, and escalation paths. Explanations show answer, evidence, rules, confidence, and next action, and never expose chain-of-thought.

38 · Production

UC2 AI enablement plan

UC2 is the first production target

UC2 is the selected production-readiness use case because it exercises the broadest common platform capabilities. The plan moves from the synthetic FastAPI implementation to a production payer workflow.

Area	Current POC	Production readiness action	Exit evidence
Referral intake	Synthetic referral JSON and text.	Validate source systems, document quality, referral identifiers, and FHIR or API mappings.	Approved source-to-case mapping and test data.
Member context	Request fields.	Connect enrollment, eligibility, benefit, and product services.	Signed interface contract and verified response behavior.
Provider and network	Synthetic provider JSON.	Establish provider identity, specialty, location, product participation, accepting status, quality, access, and provenance.	Data-quality baseline and authoritative ownership model.
Authorization context	Architectural placeholder.	Connect utilization-management and authorization status. Validate CRD, DTR, PAS, X12, or proprietary interfaces.	Approved interface and status taxonomy.
Human review queue	Boolean review flag.	Implement referral-specialist queue, evidence view, disposition, ownership, and service level.	Operational runbook and reviewer acceptance.

39 · Production

UC2 AI enablement plan, continued

Evaluation, operations, and controls

Evaluation, operations, model gateway, security, and workflow state complete the production readiness plan.

Area	Current POC	Production readiness action	Exit evidence
Evaluation	Three automated UC2 tests.	Build representative golden dataset, adversarial tests, tool-failure tests, fairness review, and regression gates.	Agreed thresholds and release report.
Operations	Reproducible local demo.	Define monitoring, support ownership, incident response, model and policy change process, and rollback.	Production support readiness review.
Model gateway	Local deterministic reasoning adapter.	Introduce approved model gateway, structured outputs, guardrails, fallback, monitoring, and cost controls.	Model evaluation and release approval.
Security	Synthetic data only.	Complete PHI, privacy, IAM, network, encryption, logging, retention, and threat review.	Security and privacy approval.
Workflow state	Endpoint response and audit list.	Implement persistent case state, queue integration, retry, timeout, and escalation.	Recovery and state-transition tests.

40 · Plan

Twelve-week delivery plan

Weeks one to six

Discovery and validation, architecture and POC design, then the shared runtime and UC2 build.

WEEKS 1 to 201

Discovery and validation

Confirm scope, business owners, system inventory, assumptions, success measures, security constraints, synthetic data, and production dependency risks.

WEEKS 3 to 402

Architecture and POC design

Approve logical architecture, task definitions, tool contracts, canonical models, evaluation cases, user experience, POC backlog, and demo scripts.

WEEKS 5 to 603

Shared runtime and UC2 build

Implement runtime services, referral workflow, mock payer tools, deterministic filters, explanation, human review, audit, and automated tests.

41 · Plan

Twelve-week delivery plan, continued

Weeks seven to twelve

UC5 build, evaluation and stakeholder validation, then the production plan and executive close.

WEEKS 7 to 804

UC5 build and integration

Implement X12 sample pipeline, canonical claim, runbook retrieval, exception investigation, routing, audit, and automated tests.

WEEKS 9 to 1005

Evaluation and stakeholder validation

Run normal, exception, ambiguity, missing-data, tool-failure, and security scenarios. Refine architecture and operating assumptions.

WEEKS 11 to 1206

Production plan and executive close

Complete UC2 enablement plan, sizing, roadmap, production-readiness criteria, final architecture document, editable deck, and decision package.

42 · Plan

Phase One team

Core delivery roles

Phase One capacity is estimated at approximately 4.45 to 5.80 full-time-equivalent across twelve weeks. Roles can be fractional.

Role	Representative capacity	Primary responsibility
Solution Architect	0.75 FTE	Architecture, client decisions, integration contracts, security alignment, and technical narrative.
AI Engineer	1.0 to 1.5 FTE	Task definitions, model gateway, structured output, retrieval, evaluation, and POC behavior.
Backend and API Engineer	1.0 FTE	FastAPI services, workflow state, tools, mock integrations, and deployment automation.
Healthcare SME and Product Analyst	0.5 to 0.75 FTE	Workflow validation, taxonomy, business rules, demonstration scripts, and acceptance.

43 · Plan

Phase One team, continued

Quality, security, and integration roles

Evaluation, security, and data integration capacity complete the Phase One team.

Role	Representative capacity	Primary responsibility
QA and Evaluation Engineer	0.5 to 0.75 FTE	Automated tests, golden datasets, failure scenarios, and release evidence.
Security Architect	0.2 to 0.3 FTE	Data classification, identity, threat controls, architecture review, and production criteria.
Data and Integration Engineer	0.5 to 0.75 FTE	FHIR, X12, provider data, canonical models, and connector specifications.

44 · Plan

Sequenced roadmap

Reuse makes the roadmap faster

The roadmap uses the Phase One POCs to create shared platform assets, then expands through production and future workflows.

Complete and validate UC2 and UC5 POCs.

Reused. Shared FastAPI runtime, task assets, tool contracts, audit, and tests.

Added. Referral matching, canonical claims, and exception investigation.

Productionize UC2.

Reused. Referral task, provider tool contract, filters, explanation, review, and evaluation.

Added. Real payer connectors, PHI controls, operations, resilience, and monitoring.

Extend to UC3 Scheduling and Admin Assistant.

Reused. Member, referral, provider, coverage, workflow, audit, and human review.

Added. Conversation state, availability, booking confirmation, and communications.

45 · Plan

Sequenced roadmap, continued

Sequence four to six

Provider-data mastering, expanded claims operations, and procedure readiness follow the first three sequences.

Mature UC4 Specialist Network Integration.

Reused. Provider contract and data-quality feedback.

Added. Identity resolution, provenance, network-product mastering, and stewardship.

Expand UC5 claims operations.

Reused. Canonical claim, runbook, investigation, routing, and audit.

Added. Production EDI, log correlation, work queues, replay, and scale.

Add UC1 Procedure Readiness.

Reused. Policy, document, authorization, provider, state, and review services.

Added. Procedure evidence model, readiness rules, and payer-provider coordination.

Automated test execution: 6 of 6 passed.

46 · Close

Recommendation and close

Approve the two-POC path

Three decisions today, and one immediate next step.

Decision 1

Approve UC2 and UC5

Approve the two proof of concepts as the interview targets.

Decision 2

Productionize UC2 first

Use referral matching for the first production enablement plan.

Decision 3

Build core services once

Build all core platform services once for maximum reuse.

Immediate next step

Focused discovery to validate client systems, data owners, operating teams, security rules, and acceptance measures. Discovery replaces the documented assumptions with client facts and produces the production backlog.

Sequencing guidance

UC4 is the provider-intelligence foundation that strengthens UC2 and UC3.
UC3 follows when scheduling connectivity is confirmed.
UC5 progresses from POC to a production exception-investigation capability after the EDI gateway, claims platform, log sources, and operational queues are validated.
UC1 remains a later cross-enterprise workflow.

47 · Close

Artifacts and resources

Everything in this presentation is downloadable

The PowerPoint deck is the official conventional fallback if this application is unavailable.

DOCXSolution Architecture and AI Enablement PlanEditable technical source of truth: strategy, POC architecture, production architecture, enablement plan, delivery model, and roadmap.Autonomize_AI_Solution_Architecture_and_Enablement_Final.docx PPTXAI Acceleration as a Service - presentation deckThe official conventional static fallback for this presentation.AI_Acceleration_as_a_Service.pptx DOCXTwo-POC Demo GuideSetup, endpoints, recommended live demo order, scenario expectations, timing, and recovery plan.Autonomize_POC_Demo_Guide.docx DOCXInterview Reading ScriptSlide-by-slide reading script, key messages, transitions, demo cues, and question preparation.Autonomize_Interview_Reading_Script_Final.docx

48 · Close

Artifacts and resources, continued

Source code, diagrams, and mapping note

The POC source archive, editable diagrams, and the AWS mapping note are downloadable here.

ZIPTwo working POCsFastAPI application, synthetic data, task instructions, claims runbook, six automated tests, and saved demo outputs.Autonomize_Two_Working_POCs.zip ZIPEditable diagrams and 4K exportsMermaid diagram sources and 4K PNG exports for the logical, AWS, UC2, UC5, reuse, and scoring diagrams.Autonomize_Editable_Diagrams_and_4K_Exports.zip MDAWS maps to the logical designNarrative note covering the AWS mapping and the supporting presentation sections.1_-_AWS_Maps_to_the_Logical_Design.md

Use case matrix

AI Accelerationas a Service

The assignment

Explicit delivery requirements

Care Access and Navigation

Core Payer Operations

Architecture pattern and portfolio role

Source-grounded detail

Status in this engagement

Roadmap role

Architecture pattern and portfolio role

Source-grounded detail

Status in this engagement

Roadmap role

Architecture pattern and portfolio role

Source-grounded detail

Status in this engagement

Roadmap role

Architecture pattern and portfolio role

Source-grounded detail

Status in this engagement

Roadmap role

Architecture pattern and portfolio role

Source-grounded detail

Status in this engagement

Roadmap role

Why UC2 and UC5 were selected

UC2 - Intelligent Referral Matching and Routing

UC5 - Claims Ingestion and Normalization

Three decisions requested today

Endpoint contract

Endpoint contract

Approved claims runbook

UC2, Referral Matching

UC5, Claims Ingestion

Shared execution capabilities

Shared trust capabilities

Validation evidence

Application and data

Services, knowledge, and evidence

Interprets and explains

Establish and enforce facts

Own material actions

Explanation contract

Cross-cutting controls

What each layer provides

Security, privacy, and AI governance

Audit record

Scaling and reliability

Observability

Human review

Approve UC2 and UC5

Productionize UC2 first

Build core services once

Immediate next step

Sequencing guidance

AI Acceleration
as a Service