Concepts
The mental model behind Tenelix — tenants, modules, the form layer, and the audit substrate.
Tenelix is built on a small number of foundational concepts. Understanding them is the fastest path to using the platform productively.
Tenants
A tenant is a customer-facing organizational unit — one tenant is one clinic account (one slug). A separate facility is a separate tenant today; managing multiple sites under a single account is on the roadmap. Every operational record in Tenelix carries the identity of its tenant — directly via a column for shared tenants, or implicitly via the database for enterprise tenants.
Modules
The platform is composed of six product modules: Patient management, Appointments, Clinical workspace, Billing, Inventory, and Reports. Each module is domain-driven, owns its own tables, and is enabled or disabled per tenant via feature flags.
The form layer
Most clinic-specific customization happens in the form layer, not in code. Patient registration, intake, custom protocols, and any other data-capture surface is defined as a versioned form. Forms support text, number, date, select, multi-select, signature, and file fields, and auto-version when edited after publication.
The audit substrate
Every clinical, billing, and admin action in Tenelix emits a structured event. PHI access is recorded in a dedicated PHI-access audit log. Lifecycle events (form publish, prescription sign, invoice issue, override) flow through their own channels. All events are tenant-aware and queryable.
This is the substrate the platform stands on. It's not bolted on; it's built in from the first migration.