DOCUMENTATION / 01
Last updated: 4 October 2026Understand the system.
This documentation describes all 18 modules and their professional workflows. Your care institution chooses according to need; AI is optional. The basis is the product requirements and existing codebase.
The 18 modules form the feature catalogue; they are not a mandatory selection. You decide which areas your institution uses. AI is activated only on request. Clinical dependencies and finalisation are described on the module pages.
COMPARISON WITH THE CURRENT CODEBASE
The complete range of modules.
All 18 modules from the product repository are documented. Each care institution chooses the modules it needs; functional dependencies are taken into account during setup. The documentation explains their 74 functional subareas and covers 14 additional functional areas. These include medication stock and pharmacy orders, staff self-service and apprentice planning, kitchen orders for all consumer groups, contracts concluded in several parts, email tickets, personal AI agents and data protection processes.
The new billing functionality is included in optional module M11. M11 describes tariff profiles, IV and insurer rules, indication codes, rejections and corrections; M03, M12 and M17 explain the associated professional sources and handovers.
01 / SYSTEM MAP
The 18 modules
Choose a module for detailed features, data scope, responsibilities, practical examples and animated interface views.
Care & residents
Daily life & staff
Operations & administration
Platform & AI
02 / Foundations
Connected through modules. Separate responsibilities.
Every module has its own professional data and commands. Information from other modules is obtained through approved contracts. The web interface, API, permission checks and audit services form shared platform layers.
- Web application and mobile apps for everyday work
- Rust-based domain core with versioned interfaces
- Tenant-specific data, encryption and auditable changes
A stay remains in M01, the physical place in M05 and the valid tariff in M11. Changes are passed on with source, time and revision. A downstream order shows its actual confirmation; technical delivery does not count as professional completion. Historical care delivery and signed originals retain their basis at the time.
Web, smartphone and tablet applications use the same domain rules. Information and drafts prepared for offline use are encrypted, limited in scope and labelled with their data status. Current permissions and revisions are checked again on reconnection. Critical approvals, binding allocations and external transmissions require the specified online process.
03 / Security & AI
Private AI, when you want it.
When AI is activated, Oronela's own servers in Switzerland support search, summaries, dictation and drafts. Data stays in Switzerland; no third-party AI is used. Every answer must identify sources. Professional approvals and critical decisions remain with authorised people.
If your institution chooses to activate AI, the personal assistant uses only permitted sources. Resident records, approved SOPs, curated medical references and model inferences remain distinguishable. Gaps in sources are identified; missing documentation is not treated as a negative finding. Our own AI infrastructure has no silent fallback to a public service.
All data remains on Oronela servers in Switzerland. Storage, processing and optional private AI take place on our own Swiss ISO 27001 infrastructure. This complements tenant-specific data storage, encryption and role-based professional approvals. Audit, retention, data protection requests and verified recovery are described in M18. Every external connection receives its own approved data scope and secure transmission route.
Security approach04 / TECHNOLOGY & TRANSPARENCY
Technology, tests and open source code.
Discover which technologies Oronela uses, how encryption and audit work and which checks accompany its ongoing development. All customers receive access to the source code and can choose the Oronela SaaS service or self-hosting with continuous updates.
Technical documentation04 / Finalisation
What is available today.
The technical documentation connects the functional scope of the 18 modules with the existing codebase. It explains domain workflows, interfaces, permissions and the audit process. Oronela is in finalisation for Q1 2027; requirements from care institutions continue to contribute. The module pages describe the respective functions and finalisation.
The documentation comparison confirms that the described scope is complete. Acceptance of a real clinical workflow and its connection to a partner is documented separately in the product project. Oronela is being finalised for Q1 2027. Requirements and requests from real care workflows inform finalisation.