One problem, three brands
Demos of CIM, Iris, AI Claims, and the data platform fall flat when carriers are named “Test Plan A.” Operators and stakeholders need a shared fictional universe: real-feeling plan names, LOBs, member journeys, and plan documents—without ever touching real PHI or real payers.
These three sites are not three different product lines. They are the same kind of artifact: public marketing + member portal front doors for synthetic personas that the Data Generator emits and that Wiki stores as curated plan knowledge (EOCs, SBCs, dental schedules, CCO narratives, and related ops docs).
How the synthetic stack fits together
- Data Generator — persona DAGs (
pchp,camas_cco,timberline) produce members, networks, claims, auths, appeals, and connector packs (CIM SQL, FHIR, warehouses). - FHIR-based API — maps generator output into FHIR-shaped resources. Member portals on these sites and the CIM UX laboratory both consume that API so claims, coverage, and member context stay one source of truth across member-facing and ops demos.
- Ayin Wiki — synthetic plan documents and operational knowledge (e.g. Crest Silver / Summit MA material, CCO and dental policy pages) that humans and agents can browse; the same corpus grounds demos and RAG-style product stories.
- These websites — marketing + member portal front doors so demos can start from “I am a Pacific Crest / Camas / Timberline member,” open portal claims/benefits via FHIR, then continue into CIM lab or other ops tools without switching data universes.
That path is intentional: complete end-to-end workflows—not disconnected mock screens. Downstream products— CIM UX laboratory, Iris, AI Claims—share the same fictional tenants and generator-backed data shape. Brands stay separate from those products; they supply narrative and the member-facing half of the FHIR demo loop.
End-to-end demo loop
A typical walkthrough: pick a persona on a plan site → portal dashboard and claims pull from the FHIR API → those resources resolve to rows the Data Generator created → open the same member or claim in the CIM lab (also FHIR-backed) for ops density tests. Marketing pages stay static story; portals and CIM are live clients of the synthetic integration layer.
Role
Principal Product Designer / AI Accelerator stakeholder for the synthetic plan program: brand systems, marketing IA, portal flows, demo ethics (always-on fictional-plan banners), and the linkage from site personas to generator packages and wiki plan docs. Each site is implemented as a modern Vue front end suitable for live walkthroughs and, where needed, static/CDK deploy.
Three faces of the same program
Pacific Crest Health Plan
Flagship multi-LOB brand used across most Accelerator demos—commercial, Medicare Advantage, and Medicaid-oriented storylines under one crest. Marketing site (home, plans, providers, about) plus member portal (dashboard, claims, find care, ID card, pharmacy, messages). Static Vue + Tailwind, S3/CloudFront/CDK pipeline for a real hosting path. Demo login for presentations; carrier name surfaces in CIM lab and Iris fixtures as the default tenant narrative.
Camas Coordinated Care
Oregon Medicaid CCO front door—whole-person care (physical, behavioral, oral, pharmacy, NEMT, community supports) with an explicit $0 member cost model. Vue 3 + Vite SPA from design handoff: camas-violet brand, six OHP/CHIP personas (e.g. prenatal, behavioral health, tribal care), marketing pages, and portal (dashboard, care & claims, benefits, ID card, documents). Positioned as a Pacific Crest–universe demo concept; site-wide fictional-plan banner for ethics.
Timberline Dental Plan
Regional dental plan for Oregon & Washington—stand-alone dental story that commercial medical brands usually under-serve. Vue 3 + Vite marketing (home, plans & pricing, find a dentist, about, members, brokers) and portal (login personas, dashboard, claims, benefits, find dentist, ID card, documents). Six sample members with PPO vs DHMO coverage views; active member in localStorage. Aligns with the Data Generator’s timberline persona (CDT codes, predeterminations, dental claims DAG).
Shared design principles
- Always-on demo ethics: banners and copy state fictional plan, invented data, not a real insurance product—safe for screenshots and external portfolio.
- Marketing + portal pair: every brand has a public story and a member shell so demos can start outside ops tools.
- Persona switchers: multiple members per brand so walkthroughs span aid categories, LOBs, and care types without rebuilding fixtures mid-demo.
- One synthetic spine: Data Generator → FHIR API → member portals + CIM lab, with wiki plan docs for narrative and RAG demos—one invented world end to end.
Outcomes
- Established a reusable synthetic plan-brand program (medical multi-LOB, Medicaid CCO, dental) instead of one-off lorem carriers.
- Gave Data Generator and Wiki a member-facing counterpart—plan documents and populations have a place members “live.”
- Wired member portals and the CIM lab to a FHIR-based API over generator data so demos exercise full claim/member workflows, not static mock screens.
- Enabled coherent demos across CIM lab, Iris, AI Claims, and enablement sessions with zero real PHI.
- Shipped three production-quality Vue sites suitable for live walkthrough and static deploy patterns.
Related work
The Ayin Data Generator emits the persona datasets and FHIR/connector packs; Ayin Wiki holds synthetic plan documents and ops knowledge; CIM UX laboratory consumes the same FHIR-backed synthetic universe for ops-density experiments—demo tenants only, never production payers.
Stack
Vue 3 · Vite · Vue Router · Tailwind (PCHP) · static/CDN + CDK (PCHP) · FHIR-based API · Ayin Data Generator · Ayin Wiki