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. For most clinics, one tenant equals one practice. For hospital groups, one tenant can contain multiple sites. 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 flows through a dedicated phi log
channel. 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.