The problem
Claims teams spent most of their day answering the same questions: Where is this claim? Is the auth linked? What’s the COB story? Is the member eligible? The answers already existed. They just lived in CIM, email threads, chat, and someone’s head.
I took that pattern to ops supervisors and plan leadership. Generic ticket tools never stuck for a boring reason: security wouldn’t let them show claim notes and member detail. Tickets became empty shells: a subject line and a ping. Analysts still rebuilt the story before they could act.
“I spend more time reconstructing the question than answering it.” – Claims analyst interview (composite of recurring feedback)
Research
- Stakeholder interviews
- Workflow shadowing / ride-alongs
- Artifact review (email, tickets)
- Security and access reviews
- Prototype walkthroughs
Research started in the work, not a lab. I sat with claims analysts through real inquiry days: how they opened a question, which systems they jumped to, and where the story fell apart. Same theme kept showing up (the quote above is a composite of that feedback): reconstruction time ate answer time.
I paired that with email and chat threads that never became durable cases, and with security conversations about why “just use a ticket tool” failed. The product insight was simple: the case has to carry claim and member context under role-based scope, or people keep rebuilding the story outside the tool.
Before engineering committed, I walked queue → case prototypes with the same roles so we weren’t guessing about Module 1 of the claims-operations shell.
What I owned
End-to-end product design for Iris as Module 1 of the Claims Operations Toolset: queue, inquiry detail, inbox, live ops, and settings. I worked side by side with engineering on shared TypeScript contracts, identity (CIM | id / OIDC), and getting prototypes into the screens operators actually open every day.
Approach
Keep the claim, member, notes, and audit trail on the case—so analysts stop rebuilding the story in email.
Hypothesis: if the case holds the context, analysts stop rebuilding the story in email. Goal: faster first useful response, fewer escalations, PHI that stays scoped by role and carrier.
Directors still need a broad view; analysts should land in their carriers. Scope isn’t a backend footnote. It’s part of the product.
- Queue first: filterable list with status and SLA cues, then deep links into claim and member context.
- Case workspace: replies, activity, attachments, reassignment, and optional AI summary hooks (Bedrock) when threads get long.
- Scope as product: permissions on every read and mutation for claims, authorizations, and related entities.
- Contracts as product:
@ayin/contractskeeps SPA and API on one source of truth so we design payloads up front instead of guessing later.
Results
Finance and ops leadership tracked avoided touch time (less email/chat reconstruction) and fewer escalations once claim Q&A lived in Iris. Conservatively: more than $250K per year in organizational savings once the product was in daily use.
≈40% faster first useful response
Internal ops sampling during rollout; times vary by carrier and claim complexity.
Share of estimated annual value by category: used in internal business case for Iris.
How it fits the platform
Iris is its own product, not a reskin of CIM. It reads claim and member context from CIM while owning the case workflow and permissions. AI Claims is a separate adjudication product that some of those inquiries may point at later.
Why this still matters
When context lives in email and chat, every inquiry starts with reconstruction. Iris put the claim, member, notes, and permissions in one place so analysts could answer instead of rebuild. I use that same idea on cases and agent-assisted queues: keep the work and the evidence together, and scope by role so people only see what they should.
Stack
Vue 3 · Quasar 2 · Pinia · TypeScript contracts · Lambda · DynamoDB · CIM read · CIM | id · Bedrock