Autonomize · Solution Architecture Review
Two working POCs on one reusable healthcare AI platform
Healthcare Payer | Solution Architecture | Interview Presentation
01 · Opening
Autonomize · Solution Architecture Review
Two working POCs on one reusable healthcare AI platform
Healthcare Payer | Solution Architecture | Interview Presentation
02 · Opening
Table of contents
Opening
Portfolio
Use cases
Recommendation
POC deep dives
Selection
Platform
Production
Plan
03 · Opening
Engagement scope and objectives
The assignment covers five candidate payer use cases and the deliverables required around them.
04 · Portfolio
Business context
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
Specialist Network Integration
Strategic data foundation.
Intelligent Referral Matching and Routing
POC 1 and detailed enablement plan.
Automated Scheduling and Admin Assistant
Next care-access workflow.
Procedure Readiness for Scheduling
Future payer-provider workflow.
Value stream 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
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
My understanding
UC1 identifies clinical and administrative readiness conditions before scheduling.
Not implemented as a POC. Presented as a future payer-provider workflow.
13
Business value /20
17
Implementation lift /20
14
Portfolio leverage /20
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
My understanding
UC2 identifies appropriate in-network specialists and routes referrals with evidence.
POC 1, implemented. Also the selected use case for the detailed AI enablement plan.
18
Business value /20
13
Implementation lift /20
19
Portfolio leverage /20
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
My understanding
UC3 improves member self-service and administrative coordination for scheduling.
Not implemented as a POC. Presented as the next care-access workflow.
17
Business value /20
14
Implementation lift /20
18
Portfolio leverage /20
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
My understanding
UC4 creates trusted specialist and network context across payer sources.
Not implemented as a POC. Presented as the strategic provider-data foundation.
18
Business value /20
17
Implementation lift /20
18
Portfolio leverage /20
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
My understanding
UC5 normalizes claim intake and improves exception investigation.
POC 2, implemented.
18
Business value /20
16
Implementation lift /20
18
Portfolio leverage /20
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
Business value covers payer ownership, operational impact, experience impact, and strategic reuse. Implementation lift covers integration, data, AI workflow, and production complexity.
| 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
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
Five conclusions follow from the scores.
14 · Recommendation
Executive recommendation
UC2 supports care access. UC5 supports core payer operations. Both run on one shared platform design.
POC 1 · Care access and navigation
POC 2 · Core payer operations
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
Product participation and accepting-new-patient status are enforced before ranking. The reasoning layer never invents a provider or changes network status.
Referral intake and structured extraction.
Provider tool returns authoritative candidates.
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
Only valid candidates are ranked. Every result returns evidence, rules, score, and confidence.
Only valid candidates are ranked.
Evidence, rules, score, and confidence.
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.
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
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. |
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
Successful claims are parsed, validated, and normalized deterministically and bypass investigation. AI investigation runs only on the exception path.
Synthetic 837P transaction received.
Deterministic X12 parsing.
Required-field validation.
The POC does not
Validate X12 through AI, adjudicate payment, change financial values, or invent identifiers.
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
Successful claims bypass investigation. Exceptions open an investigation case with grounded evidence.
Canonical claim JSON created.
Successful claims bypass investigation. Exceptions open an investigation case.
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
The exception path compares validator output or downstream error evidence with the approved claims runbook.
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
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. |
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 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
Core operations
23 · Selection
POC selection and value story, continued
Both POCs use the same shared platform capabilities. Only the business task configuration differs.
Task and execution
Trust and quality
24 · Selection
Implementation evidence
The supplied package is one lightweight FastAPI application that hosts both workflows using synthetic data.
2
Workflow endpoints
6
Synthetic scenarios
6 / 6
Automated tests passed
0
LLM or Bedrock calls
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
25 · Selection
Implementation evidence, continued
The supplied package is one lightweight FastAPI application that hosts both workflows using synthetic data.
26 · Platform
Common patterns and reuse
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
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
AI can recommend and explain. Trusted systems and people keep control of transactions and material actions.
AI reasoning
Deterministic services
People
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
Workflow logic stays separate from enterprise systems. Security, audit, monitoring, cost control, governance, reliability, and recovery apply to every layer.
Task and state, AI services, and fixed services
30 · Platform
Target logical architecture, continued
Security, audit, monitoring, cost control, governance, reliability, and recovery apply to every layer.
31 · Platform
Implemented POC runtime
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, 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
This is a production reference implementation rather than a mandatory service list, and it is not current POC evidence. The logical capabilities remain portable.
34 · Production
AWS production reference architecture, continued
Integration and security control services complete the reference implementation. This is not current POC evidence.
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
Security, scaling, reliability, observability, and human review are one connected control system.
36 · Production
Production controls, continued
Workflow state persists outside the model, and every case carries a complete audit record.
Audit: identity, case, correlation ID, input reference, model version, task version, tool calls, rules, evidence, human action, and final disposition.
37 · Production
Production controls, continued
Operations measure business outcomes, system health, model behavior, and cost, and people own material actions.
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.
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 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, 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
Discovery and validation, architecture and POC design, then the shared runtime and UC2 build.
Discovery and validation
Confirm scope, business owners, system inventory, assumptions, success measures, security constraints, synthetic data, and production dependency risks.
Architecture and POC design
Approve logical architecture, task definitions, tool contracts, canonical models, evaluation cases, user experience, POC backlog, and demo scripts.
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
UC5 build, evaluation and stakeholder validation, then the production plan and executive close.
UC5 build and integration
Implement X12 sample pipeline, canonical claim, runbook retrieval, exception investigation, routing, audit, and automated tests.
Evaluation and stakeholder validation
Run normal, exception, ambiguity, missing-data, tool-failure, and security scenarios. Refine architecture and operating assumptions.
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
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
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
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
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
Three decisions today, and one immediate next step.
Decision 1
Approve the two proof of concepts as the interview targets.
Decision 2
Use referral matching for the first production enablement plan.
Decision 3
Build all core platform services once for maximum reuse.
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.
47 · Close
Artifacts and resources
The PowerPoint deck is the official conventional fallback if this application is unavailable.
48 · Close
Artifacts and resources, continued
The POC source archive, editable diagrams, and the AWS mapping note are downloadable here.
Slide 1 of 48: AI Acceleration as a Service
AI Acceleration as a Service