The problem
Real CIM is high-stakes: regulated workflows, real members, release trains that punish large UI swings. That’s fine for shipping carefully. It’s a poor place to answer questions like:
- Should Claim Manager use a chip-forward header or the dense legacy form?
- Does one search → results → workspace pattern train faster than a layout per tool?
- How do charge grids, referral episodes, or member cards behave with realistic volume?
Static mockups lied to me. Three happy-path claim rows hide density bugs. I needed a faithful recreation where experiments could run end-to-end on believable multi-entity data, without touching production.
Research
- Production paradigm audit
- A/B route experiments
- Synthetic end-to-end task tests
- Design-system conversion checks
- Stakeholder demo debriefs
Research here is experimental on purpose. Production CIM can’t absorb every IA or interaction bet. The lab is where I compare paradigms (navigation, claim workspaces, referral flows) on synthetic populations, run route-based A/B variants, and debrief stakeholders with real task runs—not just screenshots.
Success for a lab session is simple: can someone complete a realistic multi-entity path (search → claim or member → related referral) without breaking the fiction of multi-tenant ops?
What I owned
I design and build 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. No paired eng team on the lab SPA.
When a direction proves usable, I don’t drop it straight into live CIM. I keep the working reference, document the decisions, and hand production eng something they can pull from selectively—patterns and shareable SCSS, not a silent rewrite of their app.
Approach
Try big UX bets on a full CIM recreation with synthetic data—A/B routes, no PHI, hand off what works.
Hypothesis: if the lab feels like real CIM density and the data is multi-entity, A/B results are worth trusting. Goal: learn faster than production change control, then hand off evidence instead of opinions.
- 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 PHI playground, or Iris (separate product).
- Data: synthetic only. Members, claims, referrals, carriers from the Data Generator. No production PHI enters the lab.
End-to-end: FHIR API + Data Generator
Complete demos need a real contract. Screenshots with static fixtures aren’t enough. The lab consumes a FHIR-based API that resolves Patient, Coverage, Claim, Encounter, and related resources against populations the Data Generator emits (persona DAGs for fictional plans like Pacific Crest, Camas CCO, Timberline).
- Generator → FHIR surface: DAG output becomes FHIR-shaped resources (and connector packs) so the SPA queries the way an integration-minded client would.
- CIM lab → API: Member Manager, Claim Manager, Referral Manager, and related tools read through that layer. Lists, detail, and cross-links share one synthetic source of truth.
- Same spine as member portals:demo plan brands use the same generator universe, so ops lab and member-facing demos tell one story.
A walkthrough can start on a member portal, open a claim that exists in the generator set, then flip to the CIM lab and inspect the same entities. No real payers. No real PHI.
Synthetic data as design material
Empty states lie. Sparse fixtures hide density bugs. I drive the lab with persona-driven synthetic worlds: Pacific Crest–style multi-LOB populations, claim lines, referrals, providers, documents. Served through the FHIR API so every experiment faces realistic volume, edge cases, and cross-entity links.
- Generator → FHIR → lab: worklists, member search, referral episodes, and documents all come from that path.
- Demo tenants: multi-carrier context (e.g. Pacific Crest Health Plan) matches how operators switch umbrellas without real accounts.
- Ethics: synthetic-only. Safe for screenshots, stakeholder demos, and this portfolio.
A/B variants as a first-class workflow
The lab’s killer feature is route-based variants (/A/tools/…, /B/tools/…, /C/tools/…). I can ship competing UX paradigms side by side on the same synthetic dataset, then promote a winner to default when the evidence is clear. No forking business logic into three codebases.
- Same data, different shell: Claim Manager redesign vs. legacy control 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 eng at the working reference so they can adopt selectively.
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 paths. Stress-tested with generator-scale volume, not three happy rows.
Member Manager
Find-and-inspect under the shared search band: multi-field search, result cards with enrollment, plan/PCP, flags, and contact. The question I’m always asking: can member cards and rails stay consistent with claims and referrals so operators relearn less when they switch tools?
Referral Manager
UM-adjacent work: 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 isn’t a cosmetic reskin. It’s how I keep A/B tests fair. Tokens, chips, density, drawers, and footers live in one system. An in-product browser documents them for designers and for LLM-assisted scaffolding. The lab is also where patterns get proven before production CIM imports shareable SCSS (tokens, components, density rules) instead of re-deriving the language by hand.
How it relates to other products
- Production CIM stays the source of truth for real ops. The lab is parallel. What it supplies is design system material and documented workflow experiments eng can choose to pull in.
- Data Generator + FHIR API are the exclusive population engine and contract for complete end-to-end workflows (lab and member portals).
- Iris and AI Claims are separate Accelerator products. They share fictional plan narratives (e.g. Pacific Crest) and can lean on the same design language where it’s useful.
Results
- A safe, high-fidelity CIM recreation for paradigm and workflow experiments.
- Route-based A/B variants (e.g. Claim Manager redesign vs. legacy) on identical synthetic data.
- Design system and workflow patterns proven in code I own, handed off as reference + decisions.
- Closed the empty-fixture gap with FHIR over Data Generator populations. Multi-entity workflows instead of disconnected mocks.
- Quality gates (lint, vitest, Playwright) keep the lab shippable as a real SPA. Demos stay reliable.
Why this still matters
You can’t judge a Claim Manager redesign on three empty rows. The lab lets me compare real alternatives on full synthetic populations, with A/B routes and no PHI risk—so production only inherits what already held up under density.
Stack
Vue 3 · Quasar 2 · Pinia · route-based A/B variants · FHIR-based API · Ayin Data Generator · Playwright · Vitest · design system docs