AI Accelerator · Case management

Ayin Iris

Claims operations inquiry and case platform—in-product questions route into analyst ticket workflows with role-based PHI visibility, multi-carrier workspaces, and a path from UX prototype to Lambda-backed production. $250K+ annual organizational savings.

$250K+/yr savingsClaim inquiry workflowVue 3 · QuasarPHI-aware
Ayin Iris inquiry queue
Inquiry queue — work items linked to claims, members, and carriers under workspace scope

Problem

Claims operations spend enormous time answering the same operational questions—status, auth linkage, COB, member eligibility—scattered across CIM tools, email, and chat. Without a dedicated envelope, context dies in threads and PHI exposure is hard to control.

Generic ticketing tools (Zendesk and similar) never really closed the gap. PHI policies blocked them from surfacing the actual problem—claim notes, member context, and operational detail live in systems those tools could not safely integrate with. Tickets became empty shells: a subject line and a handoff, not the issue itself. Analysts burned cycles hopping CIM, imaging, and side channels just to reconstruct what was wrong before they could respond.

Iris turns those questions into first-class work items with the problem in the envelope—linked claim/member context, notes, triage, assign, reply, resolve, and audit—with carrier/workspace scope and role permissions enforced on every mutation.

Role

Principal Product Designer on the AI Accelerator Team for Module 1 of the Claims Operations Toolset (AIA-137). Owned end-to-end product design for queue, inquiry detail, inbox, live ops, and settings— then partnered on the production graduation path (AIA-158): shared API contracts, mock-to-Lambda dual entrypoints, and CIM | id identity.

Product design

  • Queue-first ops: filterable inquiry list with status, SLA signals, and deep links into claim/member context.
  • Inquiry workspace: timeline of replies and activity, AI summary hooks (Bedrock target), attachments, and reassignment across teams.
  • Identity & scope: mock-identity header in dev mirrors production OIDC claims; directors see multi-carrier firehose; analysts land in scoped carriers.
  • Contracts as product: @ayin/contracts is the shared TypeScript source of truth for SPA and API—so design of payloads is part of the design system of the product.
Iris inquiry detail workspace
Inquiry detail — case envelope over CIM claim/member context with role-gated actions
Iris internal collaboration inbox
Inbox — internal collaboration scoped to the signed-in principal
Iris live operations analytics
Live ops — oversight views for queue health and throughput

Architecture (today → production)

Today: Quasar SPA + Fastify mock-api with fixture data and synthetic CIM—no real PHI until security gate AIA-169. Production target: SPA on S3/CloudFront, ALB OIDC (CIM | id), Lambda Fastify wrapper over the same api-core, DynamoDB workflow store, CIM read-replica, Bedrock summaries.

Outcomes

  • Shipped a coherent inquiry product that operators can demo and engineers can harden.
  • Measurable ops savings ($250K+/yr) from consolidating claim Q&A into ticketed workflows.
  • Contract-first design so real backends implement the same surface the UX was proven against.

Related work

Iris is its own product—not a CIM module. It can read claim/member context from CIM (and related systems) while owning the inquiry workflow, permissions, and case envelope. AI Claims is a separate adjudication product those inquiries may reference; synthetic demo populations come from the Ayin Data Generator.

Stack

Vue 3 · Quasar 2 · Pinia · Fastify · TypeScript contracts · Lambda (prod) · DynamoDB · CIM read · Bedrock (target)

← All case studies