01
No single workflow
Screenings, care plans, scheduling, and billing don’t talk to each other. The care plan, invoice, and calendar can disagree.
← Ai Projects
Theraxis — Clinical ops for pediatric therapy centers
PRD, design, and a live web build for pediatric therapy centers : Done using Cursor
RoleProduct & Systems Design
ScopeClinic platform from PRD to live web build
DomainPediatric therapy · Multi-tenant web
StakeholdersClinic staff · Doctors · Parents
Product ManagersSelf — PRD & product definition
DesignersSole designer
The problem
Therapy centers ran care, scheduling, and billing in separate places — so staff and families lost the thread.
Every conversation repeated the same breaks. Centers and parents were asking different versions of the same questions — and nobody had one trustworthy answer.
02
Billing is manual and leaky
Pricing and tax live in spreadsheets. Kids can start sessions before an invoice is paid — so revenue slips away.
03
Progress is guesswork
Goals aren’t tied to assessment evidence. Session outcomes aren’t structured. There’s no clear trail of what worked.
Ops calendar
No single view of who’s booked and what’s free.
Multi-center
Branches jump tools — no shared roster or billing.
Scheduling
Double-books and WhatsApp reshuffles.
Last session
“What happened last time?” lives in memory.
Is my kid better?
Parents ask weekly — answers are anecdotes.
Home carryover
What to practice fades after the drive home.
Research
Where this came from
Theraxis started from direct conversations, not a hypothesis. I talked to parents, therapists, therapy center owners, clinical admins, and center heads — primarily in Hyderabad, with the same pattern in Chennai and Pune.
I spent time with three Hyderabad centers — Daffodils Child Development Center, Ignitio Child Development Center, and Ankura Hospitals’ pediatric services — different scales, same structural gaps.
Daffodils CDC
Hyderabad · Speech, OT, ABA, behavioral therapy
Ignitio CDC
Hyderabad · Speech, OT, ABA, early intervention
Ankura Hospitals
Hyderabad, Pune + 5 cities · Pediatric specialty care
Research conversations only — not clients, not partners, not endorsements.
Hard system gates
Enforced at the database / Supabase RLS layer
These gates are not UI niceties — they refuse invalid states before a screen can look “empty” or permissive.
Gate 01
Evidence → Care Plan
Refuses Care Plan generation if domain evidence is insufficient.
Gate 02
Payment → Session
Financial confirmation / payment gates session start and resource allocation.
Gate 03
Availability conflicts
Availability grid disables conflict slots natively — no double-book path.
Gate 04
Row-Level Security
RLS policies enforce tenant/role isolation at the DB layer, not via UI filtering.
Gate 05
Domain separation
Clinical vs financial domains separated by role — billing noise can’t bleed into care.
Personas
Who feels it most
Staff need continuity between sessions. Families need a clear answer to “is my child improving?”
Persona 01
Therapist
“What did we work on last session — and what should I do today?”
Opens every day
- Session notes, the day’s schedule, and whichever child walks in next
Problem
- Last session lives in chat or paper
- No structured outcomes or next tasks
- Billing noise distracts from care
Needs
- History and last-session notes before walking in
- Progress against goals — not gut feel
- A clean handoff when another therapist covers
Persona 02
Parent
“Is my child getting better — and what should I do at home?”
Opens every day
- Messages from the center — or waits until pickup to ask
Problem
- Updates are informal or missing
- No visible answer to “is my kid improving?”
- Home practice fades after the drive home
Needs
- Progress without calling the front desk
- Upcoming sessions and whether they happened
- Clear home carryover between visits
Parent app. Separate mobile product for progress, calendar, and home carryover — still under construction. No screens yet. Staff experience is the web build below.
What I did
Research → PRD → design → build
End-to-end ownership — same person from field notes to a running app in Cursor.
01
Research
Centers, therapists, parents — Hyderabad first, then the same pattern elsewhere.
02
PRD
Roles, five hard gates, workflows, access — enforced in the database, not the UI.
03
Design
Staff web for roster, screening, assessments, billing, and admin overview.
04
Build
Working multi-tenant app (Cursor). Tested with clinicians. Parent mobile next.
Product
What it looks like
Screens from the live staff web build — not mockups.
01 · Center pulse
Admin Overview
Students, revenue, staff — one tenant view.
02 · Roster
Students & profile
Status on the board, then the full record.
03 · Evidence
Screening that sticks
Age-band checklists → domain bars — not anecdotes.
04 · Clinical + billing
Assessments & access
Age-filtered tools — approve and price before work continues.
Status
Built and in active testing
Working build. PRD, gates, and architecture are implemented — screenshots above are from the live app, not mockups.
Tested directly with practicing doctors, who responded well — they said it addressed real clinical and operational gaps, and that they’d expect to pay more for something that solves those problems than for a typical practice-management tool.
Not a center’s system of record yet. Parent mobile still under construction. Next phase is rollout validation.
Product requirements
Full PRD
Goals, roles, gates, workflows, access matrix, architecture
Product requirements
Full PRD Goals, roles, gates, workflows, access matrix, architectureThis PRD represents the work honestly — systems rules, not just screens. The application is built and running; screenshots on this page are from the live build. I built it end-to-end with Cursor.
Role: Product & Systems Design — built end-to-end
01Goals & Success Criteria
- Eliminate unbilled/under-billed enrollments by making financial confirmation a hard prerequisite for clinical resource commitment.
- Make every care plan traceable to the assessment evidence that produced it — zero care plans issued without sufficient domain evidence.
- Collapse clinical, billing, and scheduling into one system of record so no downstream action can exist without a valid upstream state.
02Non-Goals
Multi-currency billing and non-INR pricing are out of scope — the spec targets Indian therapy centers on GST-based pricing. Insurance claims processing, non-pediatric therapy types, were deferred for v1. The Parent experience is a separate mobile app under construction — not part of the staff web product.
03Users & Roles
| Role | Data Scope | Core Capability | Cannot Do |
|---|---|---|---|
| Receptionist | Own center only | Intake, appointment booking, session reschedule/cancel | Clinical records, billing, care plans |
| Center Manager | Own center only | Admissions, enrollment, invoicing, session scheduling | Clinical notes, care plan approval |
| Senior Therapist | Center + supervisees | Care plan generation/approval, pre-session tasks, session review | Billing, staff management |
| Therapist | Assigned children only | Assessments, care plan drafts, session conduct, MCQ submission | Billing, scheduling, unapproved plans |
| Tenant Admin | All centers | Everything across all centers | Nothing — full access |
| Parent | Own child only | Progress view, session calendar, home carryover | Clinical data, billing, staff info |
04Personas
Receptionist
Front desk · Own center · No clinical access
"I need to register a new child and get them booked in under five minutes."
Goals
- Register children quickly at intake
- Book and reschedule sessions
- Cancel with reason, notify parents
Friction
- No view of therapist availability
- Billing coordination is manual
- Cannot see session status in real time
Center Manager
Operations · Own center · Billing + scheduling authority
"I need to turn a care plan into a running therapy schedule the same day the family says yes."
Goals
- Confirm enrollment, auto-generate invoices
- Schedule recurring sessions with no conflicts
- Monitor center revenue and pending invoices
Friction
- Pricing inconsistencies across therapists
- Double-bookings discovered late
- No clear view of billed vs. conducted
Senior Therapist
Clinical supervisor · Center + supervisees' children
"I approve care plans. I need the full picture before I can sign off."
Goals
- Review and approve care plans rigorously
- Add task checklists before each session
- Read notes and plan the next session
Friction
- Task assignment has no structured flow
- Notes disconnected from care plan goals
- No approval audit trail
Therapist
Clinical delivery · Assigned children only · No billing access
"I open a session, work through the checklist, write my notes, and submit."
Goals
- See sessions with clear task checklists
- Submit MCQ outcomes after each session
- Track goal progress across sessions
Friction
- Tasks communicated informally
- No structured place to write linked notes
- No visibility into what's next
Tenant Admin
Platform oversight · All centers · Full access
"I need to see across every center I run, not just one — and I need to be the fallback when something's stuck."
Goals
- Onboard and configure new centers
- Resolve access or approval issues escalated from center staff
- Monitor billing and compliance health across the whole tenant
Friction
- No single view of risk across centers before this system
- Escalations required jumping into individual center data with no shortcuts
Parent
Family · Own child only · No clinical or billing access
"I just want to know my child is improving, and what I should be doing at home."
Goals
- Check upcoming session times
- See progress without needing to ask staff
- Follow through on take-home activities between sessions
Friction
- Progress updates came informally, if at all
- No visibility into whether a session actually happened as scheduled
05Functional Requirements
1
Child intake & family information2
Screenings & standardised assessments3
Evidence-synthesised care plans (AI-assisted + human governance)4
Therapy enrollment & invoice billing5
Session scheduling — availability-aware6
Session conduct — tasks, notes, MCQ outcomes"Nothing downstream happens until the thing upstream of it is valid. Every gate is enforced at the database layer — not the UI." This is the single most important requirement in the system.
06Core Clinical Flow Seven gated stages — nothing proceeds until the upstream condition is met
1
Intake
Receptionist
2
Assessment
Therapist
Invoice paid
3
Care Plan
Sr. Therapist
Evidence sufficient
4
Enrollment
Center Manager
Plan approved
5
Scheduling
Center Manager
Invoice paid
6
Sessions
Therapist
Tasks added
7
Progress
All roles
MCQs submitted
Closed feedback loop — session notes and MCQ outcomes automatically become evidence for the next care plan cycle. Progress compounds; the system improves its own clinical input over time.
07Core Workflows
Use Case 1 — Intake to Published Care Plan
Five steps, three roles, before a single session can be scheduled.
- ReceptionistAdd Student wizardTwo-step form: child info (name, DOB, center, contact, referral) and family info. Student created with status: New.
- TherapistRun assessmentAssessment type selected from the service catalogue, invoice issued. Family pays → "Yet to take." Therapist conducts → "Completed." Results enter the evidence engine.
- Sr. TherapistGenerate care planEvidence engine synthesizes finalized assessments across 14 clinical domains; low-confidence domains flagged. Sr. Therapist reviews the AI-generated draft and edits all six sections.
- Sr. TherapistApprove care planFour gates must all pass: 5P formulation complete, ≥1 goal with an evidence link, therapy recommendations present, no unacknowledged gaps. Draft → Reviewed → Approved → Published.
- Center ManagerConfirm enrollmentTherapies selected from billing menu, live invoice preview. On confirm: one invoice auto-created. Family pays → therapy start date unlocks → therapist notified.
Use Case 2 — Billing to First Session
Payment is the gate. Scheduling only happens on genuinely free slots.
- Center ManagerOpen scheduling wizardFrom the student's therapy tab; therapies selected, session counts auto-filled from the care plan, live invoice preview with GST.
- SystemDraft invoice createdAll therapies on a single invoice. Price and GST are snapshotted at this moment and never change retroactively.
- Center ManagerIssue & collect paymentInvoice issued, family pays, payment recorded with method and reference. Invoice paid → enrollment status → Active.
- TherapistSet therapy start dateNotified in-app, opens the student, sets the start date — session slots become schedulable.
- ReceptionistBook on the availability gridBooked slots are disabled and greyed out with the conflicting child shown — only genuinely free slots are selectable. Duration and end time compute automatically.
- SystemSessions createdPreview shows all N sessions with dates/times — no conflicts, since slots were validated before selection. Confirm → sessions created with status: "Needs tasks."
Use Case 3 — Session Conduct Workflow
A repeating loop between Senior Therapist and Therapist for every session in the therapy.
- Sr. TherapistBefore sessionReviews the previous session's completed tasks and notes, adds the checklist for the upcoming session. Status: "Needs tasks" → "Ready."
- TherapistDuring sessionOpens the session, sees the checklist (cannot add tasks), checks off completed items, marks skipped ones with a reason.
- TherapistAfter sessionSubmits MCQ outcomes — performance level, accuracy, generalisation, behaviour interference, caregiver carryover. Status → Completed. Notes sent to the Senior Therapist.
- Sr. TherapistReview & plan nextReads notes and MCQ data, marks the session Reviewed, adds tasks for Session N+1 — which unlocks for the Therapist, restarting the loop.
08Design & Product Decisions Every decision traces to a stated clinical or business rule — not a UX convention
01
Evidence gates the care plan
The system refuses to generate a plan if domain evidence is insufficient.
Why: a plan without evidence is clinical fabrication — a clinical integrity requirement, not a UX choice.
02
Payment gates session start
Centers can't commit clinical resources before financial confirmation. Enforced at the API layer; Center Manager can override with a recorded reason.
Why: closes the exact revenue-leak problem, with a controlled exception path.
03
Conflict slots are disabled, not warned
A slot is either selectable or it isn't — no warnings to dismiss, no overrides to design.
Why: the grid prevents conflicts by construction, not by hoping someone reads a warning.
04
Row-Level Security at the database
Role permissions are Supabase RLS policies — a direct API query still only returns a therapist's assigned children.
Why: the UI is downstream of enforcement, never a substitute for it.
05
Clinical and financial domains separated by role
Therapists never see prices; Center Managers never touch session notes or care plans.
Why: insulates clinical judgment from commercial pressure.
06
Session notes become future evidence
Completed notes and MCQ data automatically feed the evidence engine for the next cycle.
Why: progress compounds instead of each cycle being isolated.
09Access Control — Role Matrix
Permitted
Not permitted
| Capability | Recept. | Ctr Mgr | Sr. Ther. | Therapist | Tenant Admin | Parent |
|---|---|---|---|---|---|---|
| Create students | — | — | — | — | ||
| Run assessments | — | — | — | — | ||
| Generate care plans | — | — | — | |||
| Approve care plans | — | — | — | — | ||
| Create admissions & invoices | — | — | — | — | ||
| Schedule sessions | — | — | — | — | ||
| Conduct sessions + MCQs | — | — | — | — | ||
| View billing & invoices | — | — | — | — | ||
| Manage staff & centers | — | — | — | — | — | |
| View child progress | — | — |
10System Architecture
Internal Platform
Theraxis staff
- Tenant management
- License & credit ledger
- Service catalogue configuration
- Platform billing & reconciliation
Tenant Platform
Clinic staff — all 5 roles
- Students, assessments, care plans
- Enrollment & billing
- Session scheduling & conduct
- Center & staff management
Parent Portal
Families
- Child progress summary
- Session calendar (read-only)
- Home carryover activities
- Therapy notifications
Data layer: Supabase with Row-Level Security. All data is tenant-scoped; every role has a database-level policy. UI filtering is downstream of enforcement — never a substitute for it.
11Reflections
The sharpest tension in this project was between the AI-assisted care plan draft and clinical governance: an evidence engine that synthesizes 14 assessment domains into a draft plan is only useful if a Senior Therapist can trust it, and trust required making every gap and low-confidence domain visible rather than letting the draft look more finished than the evidence supported. That's why the draft is never auto-published — a human reviews and edits all six sections before anything moves to Approved.
Enforcing the five hard gates at the database layer rather than in the UI changed how the rest of the spec was written: a rule that only lives in a screen is a suggestion, not a guarantee. Writing gates as Row-Level Security policies forced every requirement to be stated precisely enough for a database to enforce it, not just precisely enough for a designer to explain it.
With more time, the next area to pressure-test is the override path on payment gating — a Center Manager can unlock a session before payment clears, with a recorded reason. That's the one place the system trades a hard rule for judgment, and it deserves the same scrutiny the other four gates got before this goes further.
Confidentiality note: This project is under NDA. Design is complete and moving into development.
Interface redrawn and figures synthesized for case study presentation.
The core architectural logic and UX constraints remain true to production.
More work
View all work