What this is (and is not)
Production CIM is the multi-tenant ops system health plans use every day. This project is a recreation of that product surface: same domains (claims, members, referrals, documents, tasks), same density and multi-tenant chrome, but built as a design laboratory. The goal is not to ship another production stack—it is to learn faster than production allows.
- Is: a high-fidelity Vue/Quasar environment for paradigm tests, A/B variants, workflow rewrites, and design-system conversion.
- Is not: the live CIM deployment, a substitute for production data, or Ayin Iris (a separate product).
- Data: synthetic only—members, claims, referrals, and carriers from the Data Generator. No production PHI enters the lab.
- Integration: the lab does not hard-code a one-off JSON dump as the product model. It talks to a FHIR-based API whose resources map back to generator output—so workflows stay realistic from search → workspace → related entities.
End-to-end: FHIR API + Data Generator
Complete demos need a real contract, not screenshots with static fixtures. The CIM lab consumes a FHIR-based API that resolves Patient, Coverage, Claim, Encounter, and related resources against synthetic populations the Data Generator emits (persona DAGs for fictional plans like Pacific Crest, Camas CCO, Timberline).
- Generator → FHIR surface: DAG output is exposed as FHIR-shaped resources (and connector packs) so the lab SPA can query the same way an integration-minded client would.
- CIM lab → API: Member Manager, Claim Manager, Referral Manager, and related tools read through that API layer—lists, detail, and cross-links stay consistent with one synthetic source of truth.
- Same spine as member portals:demo plan brands use the same generator universe (and the same FHIR-backed path for portal claims/coverage flows) so ops lab and member-facing demos tell one story end to end.
A walkthrough can start on a member portal, open a claim that exists in the generator set, then flip to the CIM lab and adjudicate or inspect the same entities—without real payers or real PHI.
Problem
Real CIM is high-stakes: regulated workflows, real members, and release trains that punish large UI swings. That makes it a poor place to answer questions like:
- Should Claim Manager use a chip-forward header or a dense legacy form?
- Does a shared search → results → workspace pattern train faster than per-tool chrome?
- How do redesigned charge grids, referral episodes, or member cards behave with realistic volume?
We needed a faithful recreation where those experiments could run end-to-end— with believable multi-entity data—without touching production.
Role
Principal Product Designer—and builder—of the CIM UX laboratory. I design and implement the lab myself with LLM-assisted coding: tool IA, design system conversion, A/B/C variant strategy, and the full loop from hypothesis → interactive prototype → comparison → recommendation. This is not a paired build with engineering; the lab is my sandbox SPA.
When a paradigm proves usable, I reference the working implementation and document the decisions as a handoff. Production engineering can adopt what they want from my code and patterns—they choose what lands in theirs. Validated UX becomes evidence and material, not a silent force-push into live CIM.
Synthetic data as a design material
Empty states lie. Sparse fixtures hide density bugs. The lab is driven by persona-driven synthetic worlds from the Data Generator—Pacific Crest–style multi-LOB populations, claim lines, referrals/auths, providers, and documents—served through the FHIR API so every experiment faces realistic volume, edge cases, and cross-entity links.
- Generator → FHIR → lab: DAG outputs map into FHIR resources; the SPA consumes that API for claim worklists, member search, referral episodes, and documents.
- Demo tenants: multi-carrier context (e.g. Pacific Crest Health Plan) matches how operators switch umbrellas in the real product—without real accounts.
- Ethics: synthetic-only path; safe for screenshots, stakeholder demos, and external portfolio storytelling.
A/B variants as a first-class workflow
The lab’s killer feature is route-based variants (/A/tools/…, /B/tools/…, /C/tools/…). Design can ship competing UX paradigms side by side on the same synthetic dataset, then promote a winner to default when evidence is clear— without forking business logic into three codebases.
- Same data, different chrome: Claim Manager default vs. legacy control (C) show conversion impact with identical claim math and member links.
- Thin variant layers: shared search, stores, and domain services; variants own presentation and interaction differences.
- Handoff path: validated paradigms become the lab default; I document decisions and point engineering at the working reference code so they can selectively adopt—not a silent force-push to live CIM.
Redesigned workflows under test
Claim Manager
Flagship redesign: search institutional and professional claims, open a workspace for charges, member context, COB, notes, and audit. Experiments target scanability (status/type/ICD chips), charge-line status, bulk actions, and keyboard power-user paths—stress-tested with generator-scale claim volume rather than three happy-path rows.
Member Manager
Member find-and-inspect under the shared search band: multi-field search, result cards with enrollment status, plan/PCP, flags, and contact. Redesign work asks whether member cards and rails can stay consistent with claims/referrals so operators relearn less when they switch tools.
Referral Manager
UM-adjacent workflow: reference #, auth #, patient, date range; episodes grouped by member; request type and determination status at a glance. Redesign focuses on episode grouping, status language shared with claims, and list → detail without leaving the shell—again on generator-backed referrals, not empty lists.
Design system as experiment infrastructure
Converting tools is not a cosmetic reskin—it is the lab’s way of locking shared rules so variant experiments stay fair. Tokens, chips, density, drawers, and footers live in one system; an in-product design system browser documents them for designers and for LLM-assisted scaffolding. That same system is what gets exposed to production CIM: the lab is the place patterns are proven, and the SCSS sheets (tokens, components, density rules) can be shared into the production codebase so eng isn’t re-deriving the design language by hand.
How the lab relates to other products
- Production CIM: still the source of truth for real ops—the lab is not a replacement app. What it does supply is the design system, including shareable SCSS sheets (tokens, components, density) that production CIM can import. Workflow experiments and A/B winners stay reference implementations + documented decisions; eng chooses which patterns—and which stylesheets—to pull into their codebase.
- Data Generator + FHIR API: exclusive population engine for the lab’s synthetic worlds; FHIR is the contract the CIM lab (and member portals) call for complete end-to-end workflows.
- Iris and AI Claims: separate Accelerator products—not modules of this recreation—though they share the same fictional plan narratives (e.g. Pacific Crest) and can lean on the same design language where useful.
Outcomes
- Established a safe, high-fidelity CIM recreation for UX paradigm and workflow experiments.
- Route-based A/B variants enable side-by-side comparison (e.g. Claim Manager redesign vs. legacy) on identical synthetic data.
- Design system and workflow patterns proven in code I own, then handed off as reference + documented decisions for engineering to pull from selectively.
- Closed the empty-fixture gap with a FHIR-based API over Data Generator populations— full multi-entity workflows, not disconnected mocks.
- Quality gates (lint, vitest, Playwright e2e) keep the laboratory shippable as a real SPA— demos and research sessions stay reliable.
Stack
Vue 3 · Quasar 2 · Pinia · route-based A/B variants · FHIR-based API · Ayin Data Generator personas · Playwright · Vitest · design system docs