Technical Architecture

Six repositories, one platform — how Chairside is designed and how the pieces connect.

Platform Overview

Chairside is organized into six repositories, each with a clear responsibility. They can run independently or together as a full platform:

api (port 3001) — Express.js backend with 80+ models, 80+ controllers, MongoDB, and the full clinical/billing/scheduling engine
app (port 3000) — React 19 frontend with Chakra UI, 130+ components across 38 feature directories
client (port 9876) — Electron bridge agent for local imaging hardware, TWAIN scanners, and desktop integration
foundation (port 3002) — Standalone Express service for the cross-vendor patient portability registry
docs — Project documentation, API reference, and contributor guides
landing — Public website and marketing pages

Each service has its own package.json, test suite, and can be deployed independently.

The services communicate through well-defined interfaces:

App → API — All frontend requests go through the cqAPI client class, which auto-injects practice ID and user ID, handles retries, and manages auth tokens
API → MongoDB — Mongoose ODM with 80+ schemas. Multi-tenant scoping via practice_id and optional group_id
API → Stedi — EDI clearinghouse integration for insurance claims (837/835 transactions)
API → Stripe Connect — Platform payments for vendors, direct charges for standalone practices
Client → API — Bridge agent polls for imaging requests and pushes captured images via WebSocket events
API → Foundation — Patient portability requests use RSA-signed consent tokens to authorize cross-vendor record transfers
Foundation → FHIR — Uses $everything and $import operations for standardized patient data exchange

Security is layered throughout the stack with multiple complementary mechanisms:

Authentication — JWT tokens issued at login, validated on every request via the authenticateToken middleware
Role-Based Access Control — Users have role arrays like ["admin:practiceId", "dentist:practiceId"]. The has() middleware checks permissions before every protected endpoint
Encryption at rest — Sensitive fields (SSN, credentials) encrypted with AES-256 before storage
OAuth2 tokens — Third-party integrations use scoped OAuth2 tokens that can be revoked per-app and per-practice
RSA consent signing — Patient portability transfers require RSA-signed consent tokens that prove the patient authorized the transfer
Middleware chain — Every request passes through helmet, rate limiting, CORS, session validation, and audit logging before reaching any controller

The superadmin role bypasses permission checks but is still subject to rate limiting and audit logging.

Explore the architecture firsthand. Everything is open source and documented.