Technology you can verify.

One shared domain core. Clear responsibilities.

Oronela is being finalised. The 18 modules connect care, support, administration and operations. You choose the scope that suits your institution. The technical platform brings together login, current permissions, encrypted storage, background jobs and traceable changes. A module receives information from other areas through defined interfaces rather than changing their data arbitrarily.

The browser interface uses Vue and TypeScript. The server-side professional core and API are written in Rust. SQL defines data structures, integrity rules and migrations in PostgreSQL. Python supports checking tools, operational workflows and private AI operations. Executable logic and its interfaces are stored with their associated tests in the product repository.

The interface communicates with a controlled API. A backend-for-frontend manages the session on the server and connects the interface with identity and domain processes. The browser device receives neither direct database access nor an unrestricted connection to the model server. An open screen does not replace a permission check: before a binding action, tenant, role, responsibility, domain context and current revision are considered again.

1. 01

   Workspace

   Resident windows, care, staff, kitchen and administration in the browser.

2. 02

   API and professional core

   Current permissions, domain rules and versioned module contracts.

3. 03

   Protected data

   PostgreSQL, encrypted documents, key management and audit.

4. 04

   Approved handovers

   Partner connections and optional private AI with a limited data scope.

The specifically pinned versions.

This table reflects the versions pinned in the product repository on 4 October 2026. It describes the traceable development and integration status. An installation is additionally governed by its associated release package, approved configuration and version evidence.

Python tools are also included. A shared Python version is not fixed in the root manifest examined; we therefore do not invent a version number for it. The version is recorded in the relevant operational and verification evidence. Model, runtime and configuration are managed as separate versions.

Version sources: rust-toolchain.toml, Cargo.toml and Cargo.lock, package.json and pnpm-lock.yaml, compose.yaml and the documented private AI runtime evidence.

Oronela SaaS or your own installation.

Every customer can choose between the Oronela SaaS service and a self-hosted system. With the SaaS service, Oronela operates the system on its own Swiss infrastructure. Storage, processing and optional AI stay in Switzerland. The infrastructure is ISO 27001 certified; this does not imply separate certification of the application.

For a self-hosted installation, your institution and its IT team determine the operating location and technical operational responsibility together. These customers also receive ongoing updates. The release package, included versions and documented installation and migration steps provide the shared basis. Those who host the system themselves take on the associated responsibility for access, network boundaries, keys, backups and monitoring, or appoint a suitable operations partner.

The functional scope is configured according to need. AI is also a deliberate choice by your institution. Self-hosting is no reason to pass data to a public AI service: model processing and permitted sources remain within the dedicated environment configured for them. The system concept excludes silent substitution by third-party AI.

• SaaS: Oronela is responsible for the agreed operations and controlled delivery of updates.
• Self-hosting: your IT team receives the technical foundations and ongoing updates for your own installation.
• Both options: versions, security changes, dependencies and migration notes remain traceable.

Source code access is included.

All Oronela customers receive access to the source code. Security promises should be verifiable against the actual implementation. Your IT team or a specialist you appoint can trace how a permission is checked, where a key is used, which data a connection receives and how a change is logged.

Understanding the system involves more than its visible interfaces. Its technical assets include professional modules, API contracts, database schemas, migrations, tests and developer documentation. Own code and developer materials use English so that interfaces and maintenance knowledge remain clear across people and languages. User documentation remains available in your interface language.

Source code access also provides a basis for independent audits and long-term hosting decisions. It enables your institution to examine critical paths directly and ask questions based on specific code locations. Access credentials, private keys and resident data are, of course, excluded from this source code.

Protect data in transit and at rest.

The professional core includes authenticated encryption with AES-256-GCM. A fresh data key is used for each encryption. OpenBao protects this key in a separate key service. The plaintext of a professional record is not sent to the key service for this key operation.

Encrypted information is bound to its expected identity: tenant, storage object, purpose and revision are part of the checked context. Simply copying encrypted content into another record is therefore insufficient. Changes to the content or an inappropriate context cause rejection. Decryption also remains bound to current professional permission; valid cryptographic content alone does not permit access.

Larger documents are processed in authenticated segments. The existing document path checks, among other things, the full length, the end of the document and the final acknowledgement. Individual decrypted parts are not already treated as an approved document. Key versions and document revisions remain traceable so that rotation and recovery account for the correct originals.

The system uses HTTPS for transmission. Internal service connections receive verified certificates and service identities according to their operational profile, including through mutual TLS authentication. Database roles, network access and key purposes are limited. If an error occurs, neither medical content nor tokens are disclosed in general error messages.

• Fields and documents: authenticated encryption rather than simply marking data as confidential.
• Keys: separate management with tenant- and purpose-specific access.
• Transmission: protected connections and an explicitly approved group of recipients.
• Recovery: originals, key history and actual readability are considered together.

Tenant boundaries and professional permissions work together.

A care institution and a site are not arbitrary interface filters. The server works with the reliably established tenant and the current authority of the person acting. Data storage and limited database roles complement this professional boundary. Another resident's ID or a manipulated browser form must not create access.

Permissions may change while a window is open. A binding command therefore checks the current situation. Depending on the transaction, this includes professional competence, purpose, source status and revision. An outdated copy or expired approval does not become valid simply because it was displayed earlier.

A module retains responsibility for its own domain information. For example, admission and stay belong to M01, places and rooms to M05, and contractual tariff foundations to M11. Other areas obtain the information they need through versioned contracts. This helps prevent conflicting copies and unclear responsibilities.

An audit follows the actual workflow.

For relevant changes, the technical audit trail records source, time, context and revision. Professional state, history, audit and outgoing downstream orders are handled together through the designated transaction path. The outbox separates durable recording of an order from its later delivery. An order can therefore be processed again after a connection failure without blindly duplicating its professional effect.

Audit events are linked to their predecessor using SHA-256. Verification considers the originally stored bytes and the relevant event type. The separate archive verifies received packages and issues signed acknowledgements; the existing acknowledgement path uses Ed25519. The source confirms archiving only on the basis of a matching verified acknowledgement. Technical delivery and professional confirmation remain different facts.

Relevant read approvals also receive a traceable context. A limited audit view does not claim completeness over historical areas it does not contain. Reviews therefore consider scope, period, chain linkage, archive acknowledgements and access permissions together.

The product's security and quality audit complements this operational evidence. Changes are traced back to requirements, risk, data protection and dependencies. Release criteria require independent review, specific check results and responsible professional, security and operational assessment. A passing component test replaces neither clinical acceptance nor an independent audit.

Ongoing development without uncontrolled data changes.

Care workflows, legal frameworks and technical requirements change. Oronela therefore continues to evolve. Real needs from institutions feed into concrete requirements; these become traceable changes with tests and documented effects. Proven workflows, interfaces and historical evidence remain a shared responsibility of domain development and operations.

Versioning covers the application, libraries, database migrations, rules and optional AI. A changed rule must not silently reinterpret a historical care or billing record. A current suggestion references the sources actually used; an original already created retains its foundations at the time.

Database changes are maintained through ordered migrations. The release process requires defined starting and target states, dependencies, compatibility, checksums and a recovery route. Safe reversal depends on the specific type of change and later writes. Where direct reversal is not permitted, a documented correction or recovery is required.

An update for a self-hosted installation remains verifiable through its release package. This includes new versions, their effects on configuration and interfaces and the required migration steps. In SaaS operations, the same approved version forms the basis for controlled delivery.

• Understand the requirement and its impact.
• Change code, tests and documentation together.
• Bring together independent review and appropriate evidence.
• Approve the exact version and deliver it under control.
• Monitor operations, collect feedback and provide corrections in a traceable way.

AI remains optional and within your data environment.

Oronela works with the modules selected by your institution. AI is used only when you want it and the relevant functions are activated. In the Oronela SaaS service, model processing and knowledge access run on Oronela's own servers in Switzerland. There is no hidden call to a public AI provider.

The technical verification state includes a Qwen model runtime actually used locally. Model version, runtime and artefact provenance are recorded separately. The model receives the context needed for an approved purpose. Permitted sources, the current person acting and removal of context are parts of the application path.

A response remains a suggestion with distinguishable sources. A summary does not replace a documented observation, and a shift-scheduling recommendation does not override a domain rule. In the documented test case, the model selects among shift-schedule proposals already rechecked; it does not freely change their assignments. Approval remains with the people authorised to grant it.

Model quality is assessed using appropriate professional cases and data protection checks. Conventional code coverage can measure adapter logic but cannot justify a claim of 100 per cent correct model responses. A new model or prompt version therefore receives its own evaluation and approval context.

Your IT team can take a closer look.

We present technical properties in a way that keeps them verifiable. Questions about encryption, tenant boundaries, versions or recovery can be discussed using specific implementations and evidence. Source code access enables your specialists to examine the paths important to your institution themselves.

For operation, the actual release scope, its configuration and associated approvals are considered together. General product descriptions do not replace these documents. Please contact us if your IT team, data protection team or an independent auditor needs specific evidence, or if you would like to discuss hosting the system yourselves.