RestartiX Platform

English

Română

English

Română

Appearance

Features Index ​

This directory contains 18 core features, each documented for both non-technical and technical audiences.

How to Read This Documentation ​

Every feature page follows the same structure:

# Feature Name
> One-liner for anyone

## What this enables
Plain-language bullets explaining business value

## How it works
Step-by-step workflow for non-technical users

---

## Technical Reference
[All technical details for developers]
- Database schema with indexes and RLS
- Complete API endpoint documentation
- Architecture decisions and trade-offs
- Code examples

Reading guide:

  • 👤 Non-technical folks: Read the top section (one-liner + "What this enables" + "How it works")
  • 👨‍💻 Developers: Jump to Technical Reference section for schema, API, and implementation details

Browse All Features ​

auth/ ​

Authentication & Principals - Authentication, sessions, organization context, Clerk integration

  • Tables: principals, humans, organization_memberships (there is no users table — see Actor Model)
  • Endpoints: /v1/me
  • Key concepts: Clerk auth, RLS session variables, organization context

organizations/ ​

Organization Management - Organization CRUD, settings, API keys

  • Tables: organizations, organization_integrations
  • Endpoints: /v1/organizations/*
  • Key concepts: Multi-tenancy root, slug-based lookup, API key management

Service Catalog & Scheduling ​

services/ ​

Service Catalog - What the organization offers (procedures, therapies, consultations)

  • Tables: services, service_specialists, service_forms, service_attachments, service_plans, patient_service_plans, products, service_plan_products
  • Endpoints: /v1/services/*, /v1/service-plans/*, /v1/products/*
  • Key concepts: Service catalog, three plan types (session_based, time_based, hybrid), access grants (telerehab_access, library_access), add-on services, product catalog (reference only, no e-commerce), product bundling with plans
  • Replaces: appointment-templates (deprecated)

scheduling/ ​

Calendars & Booking - When/how services can be booked

  • Tables: calendars, calendar_specialists, calendar_forms, specialist_weekly_hours, specialist_schedule_overrides, specialist_assignment_tracking
  • Endpoints: /v1/calendars/*, /v1/calendars/{id}/timeslots, /v1/holds/*
  • Key concepts: Calendars (bookable units), availability engine, hold system (Redis), SSE streaming, timezone handling, campaign calendars with hour overrides
  • Note: Calendars link to services; one service can have many calendars (default, campaigns, promotions)

appointments/ ​

Appointment Management - What was booked (booking records + lifecycle)

  • Tables: appointments, appointment_files, appointment_reviews
  • Endpoints: /v1/appointments/*, /v1/calendar
  • Key concepts: State machine (booked → upcoming → done), Daily.co integration, patient onboarding, service + calendar references, add-ons, reviews

Profile Management ​

patients/ ​

Patient Profiles - Patient CRUD, onboarding, impersonation

  • Tables: patients
  • Endpoints: /v1/patients/*
  • Key concepts: Onboarding flow, admin impersonation, profile management

specialists/ ​

Specialist Profiles - Specialist CRUD, scheduling configuration

  • Tables: specialists, specialist_specialties
  • Endpoints: /v1/specialists/*
  • Key concepts: Scheduling profile, timezone, weekly hours, date overrides

specialties/ ​

Specialty Categories - Medical specialty definitions

  • Tables: specialties
  • Endpoints: /v1/specialties/*
  • Key concepts: Specialty categorization, specialist associations

Data Collection System ​

custom-fields/ ​

Versioned Field Library - Reusable, versioned field definitions for all entities

  • Tables: custom_fields, custom_field_versions, custom_field_values
  • Endpoints: /v1/custom-fields/*, /v1/patients/{id}/profile, /v1/specialists/{id}/profile
  • Key concepts: Field library model, versioning (automatic propagation), system fields, profile data, entity attributes
  • Architecture: Custom fields ARE the schema (forms reference them, not duplicate)

forms/ ​

Dynamic Forms - Form templates (design) and instances (runtime filled forms)

  • Tables: form_templates, form_template_versions, forms
  • Endpoints: /v1/form-templates/*, /v1/forms/*
  • Key concepts: Templates reference custom_field_id (no schema duplication), instances snapshot custom field versions (immutability), one-off fields (custom_field_id: null), auto-fill from profiles, lifecycle state machine

segments/ ​

Patient Cohorts - Rules-based patient grouping from forms, profiles, and appointments

  • Tables: segments, segment_members, segment_versions
  • Endpoints: /v1/segments/*
  • Key concepts: Multi-source rules (forms.values + custom_field_values + appointments), tiered evaluation, auto-update on data changes

Telerehabilitation ​

exercise-library/ ​

Exercise Video Library — Global + org-scoped exercise library with video, taxonomy, and instructions

  • Tables: exercises, exercise_categories, exercise_body_regions, exercise_equipment, exercise_tags, exercise_instructions, exercise_contraindications
  • Endpoints: /v1/exercises/*, /v1/exercise-categories/*, /v1/exercise-body-regions/*, /v1/exercise-equipment/*
  • Key concepts: Global + org dual-scope (organization_id IS NULL = global), CDN-agnostic video (Bunny Stream / S3), full taxonomy (categories, body regions, equipment, difficulty, contraindications), soft delete, clone from global to org
  • New RLS pattern: organization_id IS NULL visible to all authenticated users

programs-and-assignments/ ​

Programs & Protocols + Patient Stats — Content hierarchy (exercises → sessions → optional phases → programs) with three-tier copy-on-derive (every prescribe / self-enroll deep-copies the source into a patient-instance program), polymorphic patient protocols (prescription | enrollment) with a cadence engine, and the clinic-side patient stats surface

  • Tables: content_files, programs (with derived_from_program_id flat lineage for org variants), program_phases, program_assets, session_audio_items, session_assets, protocols (renamed from patient_assignments on 2026-05-23), protocol_pauses, plus sessions.kind enum and sessions.program_id/phase_id/order_in_phase (replacing the retired program_sessions junction)
  • Endpoints: /v1/programs/*, /v1/sessions/* (extended), /v1/content-files/*, /v1/patients/{patientId}/protocols/*, /v1/me/protocols/*, /v1/patients/{patientId}/stats/*
  • Key concepts: catalog-ownership tiers (P49) — platform / org / patient_specific — applied to exercises, sessions, programs, content_files; three-tier copy-on-derive (deep copy at every prescribe / enroll / save-as-variant transition); two-cadence engine (flexible patient-anchored | scheduled calendar-anchored) along orthogonal supervision_mode (unsupervised/supervised) and per-appointment channel (in_person/online_live) — see cadence & supervision; three progress lanes (adherence / course progress / engagement); query-time stats over raw event tables; storage path convention (/platform/... vs /orgs/{org_id}/...)
  • Phased delivery: Phase 1 substrate ships before June 10; Phase 2 builds clinic UI + patient UI + stats page on top; Phase 3 evolves (audio content, org uploads, pose metrics)

treatment-plans/ — retired ​

The legacy treatment-plans / patient-treatment-plans / patient-session-completions design was superseded by programs-and-assignments/ (locked 2026-05-21) and the subfolder was deleted from the docs tree on 2026-08-02. Git history keeps it; there is no treatment_plans table and there will not be one.

Supporting Features ​

automations/ ​

Lifecycle Workflows - Event-driven automation rules for patient and appointment lifecycle

  • Tables: automation_rules, automation_executions
  • Endpoints: /v1/automations/rules/*, /v1/automations/executions/*
  • Key concepts: Trigger events (patient.onboarded, appointment.first_booked, etc.), actions (require_form, send_email, etc.), conditional execution, execution history
  • Replaces: Hardcoded template_policy_id/template_terms_id with flexible automation rules

pdf-templates/ ​

Visual PDF Designer - Block-based template editor for professional PDFs, chromedp rendering

  • Tables: pdf_templates, pdf_template_versions, pdf_template_components
  • Endpoints: /v1/pdf-templates/*, /v1/pdf-template-components/*
  • Key concepts: Block-based editor, Go template syntax, component library (letterhead, footer, signature), versioning, live preview, forms integration

documents/ ​

Reports & Prescriptions - PDF generation, digital signatures, templating

  • Tables: appointment_documents, appointment_document_files
  • Endpoints: /v1/reports/*, /v1/prescriptions/*
  • Key concepts: PDF pipeline, template rendering, signature handling, caching

webhooks/ ​

Webhook System - Org-scoped event subscriptions, delivery, retry logic

  • Tables: webhook_subscriptions, webhook_deliveries
  • Endpoints: Webhook management, event delivery
  • Key concepts: Event catalog, signing, retry with backoff, idempotency

integrations/ ​

External Services - Third-party API integrations, data migration

  • Services: Daily.co (videocalls), AWS S3 (file storage)
  • Key concepts: Cross-tenant isolation, org-scoped keys, meeting tokens, signed URLs, legacy migration

audit/ ​

Audit Logging - Comprehensive audit trail for HIPAA/GDPR compliance

  • Tables: audit_log (local Postgres, monthly partitioned per P41) — single source of truth for compliance audit; no telemetry forwarding (the earlier design has been rejected)
  • Key concepts: synchronous local write, append-only, classification + RLS-scoped, three-tier retention (hot Postgres → warm S3 → purge)
  • For patient-engagement / pose-tracking telemetry (separate concern, Layer 2 feature), see ../telemetry/

Quick Navigation ​

Finding a feature:

Cross-cutting concerns:

  • See ../reference/ for RBAC, GDPR, encryption, scaling, etc.
  • See ../telemetry/ for the Layer 2 patient-engagement + pose-tracking pipeline (compliance audit lives in audit_log in the main DB, not telemetry)

Adding a New Feature ​

When adding a new feature, create a folder with:

features/my-feature/
├── index.md            # Feature overview, key concepts
├── api.md              # API endpoints with request/response
└── [feature-specific docs as needed]

Template structure:

  1. index.md - What is this feature? Why does it exist?
  2. api.md - All endpoints, grouped logically
  3. Additional docs - Lifecycle, workflows, edge cases, performance

Schema lives in architecture/data-model.md, not in feature folders. Earlier specs shipped a per-feature schema.sql that drifted from the migrations as the principal model and UUID PKs landed (Layer 1.24, P26). The architecture doc is now the single canonical schema; services/api/cmd/check-migrations rejects stale patterns from any new migration so the spec and schema stay in sync. When adding a feature, contribute its tables to the relevant Area N in data-model.md alongside the migration PR.

Update these files: