Counterpart Assistant / fictional care-booking demo

Care Booking

The app in the Counterpart Assistant repository is a UX engineering exercise in appointment booking: two locations, six providers, three seeded patients, and two appointment types. The deliberately small domain makes the workflow's decisions visible.

Discovery leads through patient identity, review, and confirmation, with distinct new-patient, returning-patient, staff-booking, and sign-in-required scenarios. All patient data is fictional and stored only in the browser.

Identity without losing context

Guest discovery stays open. In the sign-in-required scenario, the gate appears immediately before confirmation and preserves the booking draft. Staff booking keeps the acting staff member distinct from the patient receiving care.

An established patient relationship is a separate domain fact from merely having a patient record. That distinction matters when newly registered patients move through eligibility checks.

Recovery is part of the flow

Deterministic scenarios expose unavailable appointments, a slot taken during confirmation, a transient failure, and slow responses. Idempotency keys protect retries, while conflict recovery offers a fresh slot rather than treating every failure alike.

Rescheduling preserves the appointment identity and frees the original slot only on success. A failed or stale update must leave the existing appointment intact.

Components and explanation

Shared primitives are Web Components built with Microsoft FAST and exposed to React through a wrapper. The in-app study guide explains the actual domain and architecture decisions with diagrams, interactive walkthroughs, and a component gallery.

Repository tests cover booking invariants, timezone boundaries, scenario recovery, and appointment occupancy. Storybook adds component-level interaction examples.

Demo boundaries

There is no real backend, authentication, patient portal, or cross-device synchronization. Simulated sign-in matches a demo patient email; repository calls introduce artificial latency to make pending states visible.

This is a fictional workflow demonstration, not a clinical service. Its documentation and tests do not constitute a production security or accessibility certification.