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.
01 / IN DAILY USE
Tasks and responsibility.
You choose this module according to your institution's needs. The interfaces described are configured for the areas you select. AI support is available exclusively on request and processes data on Oronela's own servers in Switzerland.
Communication and documents keep information with its domain case. Messages, documents, signatures and email tickets use controlled recipient groups and traceable revisions. Personal and functional sending identities are managed separately.
Documents can be accessed from different dossier views without being stored multiple times. The original, a preview, OCR and a translation remain distinguishable. Residents and authorised representatives receive explicitly approved content through the portal. Delivery, reading, acknowledgement and completion each have their own meaning.
Information maintained by the module
Area
Content and meaning
Message and ticket
Case, participants, responsibility, deadline, internal or external content and evidenced processing status.
Document revision
Original, type, language, source, validity, access area, approval, and separate preview and translation.
Signing and email identity
Required parties and evidence, together with verified domains, personal addresses, functional addresses and sending permissions.
02 / MODULE FUNCTIONAL SCOPE
What this module covers.
6 functional areas connect this module's tasks. The following sections explain the content, handling and responsibilities.
01
Messages and acknowledgements linked to a process
Bring queries together in the correct case and reliably distinguish who was merely notified from who acted with responsibility.
Messages reference a permitted case or resident, priority, sender, addressed people or role scopes, required response and any deadline; the service checks both recipient selection and subsequent reading permissions.
Delivered, displayed or read, explicitly acknowledged and professional task completed each have different evidence. Push or WebSocket receipt must not confirm a professional state.
Permission changes remove new reading opportunities from search indexes, push references and active connections too; sensitive previews on locked devices remain hidden.
Message corrections and withdrawals are managed with visible revisions. A withdrawal does not claim to make a recipient forget content already read.
Deadlines and substitutes come from the workflow service; alerts show the responsible party without sending health data to arbitrary groups.
Responsibility
All authorised professional and operational roles within the relationship and purpose; group moderation does not grant additional permission to read resident data.
Automation & AI
Local AI may create drafts with recipients and translations marked by language. The sender confirms recipients and content; escalation follows rules within the authorised recipient group. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.
02
Document revisions, secure channels and approvals
Reliably find valid documents and demonstrate secure external communication without duplicate storage.
Documents have a type, source, author, language, content hash, revision, validity interval, domain reference, access scope and approval or signature status. Originals and derived previews, OCR or translations are separate.
Uploads pass through format and size limits, quarantine and malicious-content checks; previews and OCR run in isolation. A preview must not execute active content.
Approved documents are not overwritten. Historical appointments reference the revision valid at the time; the current view explains replacement or withdrawal.
External transmission of medically relevant information uses only an approved channel and partner contract. Delivery, clinical acceptance and signature validation are separate records; errors activate the approved alternative workflow.
Downloads, previews and time-limited object references check current permissions; a signed URL alone does not replace an appropriate protection and revocation strategy.
Responsibility
Document authors and professional approvers depend on the type; external recipients are checked against the purpose and address directory. Support cannot view document contents without approved access.
Automation & AI
Local OCR or AI suggests type, metadata and summaries; manipulated instructions in documents remain data. Validity, signatures and external recipient approval require deterministic checks and responsible people. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.
03
Resident and family portal and representation
Make approved appointments, information and feedback independently accessible and reduce queries to staff.
Every account is personal and tied to verified representation, validity, resident reference and an explicit approval catalogue. Family membership alone does not authorise full access.
Approvals apply per content type, process and revision with purpose, period and revocation; portal views are their own projections, not a reduced CSS representation of a complete record.
Authorised people can view appointments, submit participation responses or queries and read approved documents. An appointment response does not change a medical order or another resource booking without professional review.
Changes of representative and revocations end new API, web, app and WebSocket access and revoke active permissions. There are no permanent download links with unlimited validity.
Language selection, accessible interaction and supported authentication and recovery routes also apply to portal users; security levels are not lowered in favour of simple sharing links.
Responsibility
Residents and representatives see their explicit content; responsible administration checks representation and professionals approve professional content. A portal administrator does not have general record access.
Automation & AI
Notifications follow the recipient's locale and approval. Local AI can explain approved content understandably; it adds nothing from unapproved internal context and makes no individual medical decision. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.
04
Multiple signatures, signature validation and paper originals
A shared signing process serves resident, personnel and supplier contracts.
The process maintains required signatories, signing authority, order, deadlines and completion evidence. Invitations may be delivered in parallel. The document content and cryptographic signature chain must nevertheless remain consistent; independently signed files are not simply combined into an allegedly jointly signed original.
Every signing step is bound to the specific content revision. A subsequent signature is a further signature revision; a changed clause, however, is a content change and starts the necessary new process. Signed attachments are included within the approved scope.
Reminders, refusal, cancellation, corrected party assignment and incomplete multiple signatures remain visible. A selection rule such as two out of several authorised signatories requires a professionally confirmed signing rule. A visual stamp does not replace a required personal signature.
Document, certificate and timestamp validations are archived together with provider evidence and long-term validation. The appropriate signature form is defined for each contract and legal profile. A drawn signature or unsuitable certificate type is not described as a Swiss qualified electronic signature.
Paper processes document receipt, completeness checks, signing details and the original's location. Scans, OCR and translations remain separate from the original. Retention and later destruction follow the verified profile; a scan is not presented as automatic authenticity verification.
Responsibility
Professional processes determine content and signing authority. M12 coordinates signing and verification; M17 connects the approved signature service.
Automation & AI
AI can prepare checklists or summaries. It never signs for a person or overrides a validation finding. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.
Connection & offline use
Invitation, approval, signature and final validation take place online. Unconfirmed responses remain open.
05
Email tickets, responsibility and replies
Incoming correspondence is assigned to an actionable case with a protected history.
Personal and team queues group messages by responsible professional area. A ticket records participants, its reference to a resident, employee, supplier or process, responsibility, deadlines and processing status. Internal notes and external replies have different audiences.
Automatic assignment checks the actual transport and recipient context, known participants, provenance and current permissions. A ticket number, forged reply header or address in the message text does not grant access to someone else's history.
Replies are prepared within the case, assigned a permitted sending identity and rechecked against recipients and content before dispatch. Kitchen, HR and medical areas remain separate in searches, attachments and exports too. General ticket access does not grant additional record permissions.
Forwarding, merging, reclassification and corrections are traceable against revisions. When an internal note and external reply occur simultaneously, the confidentiality boundary must be preserved. Delivery, reading and professional handling are displayed separately.
Malicious attachments and active email content are handled in quarantine or a safe preview. Technical errors, returned mail and unclear dispatch outcomes create actionable cases. Messages are adopted only after their professional assignment has been checked; an AI summary does not replace that assignment.
Responsibility
Authorised employees handle their own or assigned team tickets. Protected staff and medication tickets have separate access groups.
Automation & AI
Private AI can structure permitted correspondence, label translations and draft replies. Sender, recipient and approval remain subject to responsible confirmation. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.
Connection & offline use
Binding assignment and external replies require a current online check. Drafts are clearly distinguished from tickets actually received or sent.
06
Own domains, personal addresses and sending rights
The institution receives controlled email identities with clearly separated functions and dossier assignments.
Domains and subdomains are verified and uniquely bound per customer account. Personal employee addresses, role addresses and contact-related assignment addresses are different types. A reassigned domain or recycled employee address does not inherit a confidential historical message store.
Staff may send only through explicitly permitted personal or functional identities. Sender, reply address and technical sending address are determined on the server and checked immediately before dispatch. An old delegation or manipulated sender field does not grant sending rights.
Resident, doctor and supplier aliases assist with incoming messages and correct case assignment. They are not accounts through which staff may impersonate these external people as senders. A random reply address for a case also serves routing and does not replace reading permissions.
Departure, a change of role, revocation of delegation and a domain change end new sending capabilities in a controlled way. Historical correspondence remains within the approved access group. A new representative does not automatically receive the previous person's private HR messages.
Address directories, domain checks, approvals and changes retain provenance, validity and revision. Technical email transport in M17 uses these rules; wording in an email or an AI suggestion changes neither the tenant nor the permitted sending identity.
Responsibility
Authorised administrators manage domains and identities. Domain-specific send-as delegations apply only within the approved scope and period.
Automation & AI
Automatic checks verify assignment and validity. AI may explain address suggestions but cannot approve a domain or sending permission. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.
Connection & offline use
Domain binding, delegations and sending approvals require an online connection.
03 / ADDITIONAL FEATURES
Further features in detail.
Dossier views and secure invoice copies
Folders for residents, staff, suppliers or individual cases are authorised views of the same documents. They do not create a second copy with different approval or retention rules. The original revision, historical references and permitted derivatives remain traceable together.
For the new billing process, M11 passes the approved original invoice and resident copy with the same invoice revision. The portal process checks the recipient, current representation, consent to electronic delivery and scope of approval. Paper handover receives its own record; producing a PDF does not confirm delivery.
Medical correspondence uses the approved secure channel. HIN, the protected portal, digital signature service and postal dispatch have different functions and evidence. Failure of the chosen channel opens the checked fallback workflow without automatically sending protected content unencrypted.
04 / PRACTICAL EXAMPLE
Resident contract with multiple signatories
01
M11 approves the content and specific attachments for signing.
02
M12 determines the required parties and binds their authority to the document revision.
03
The selected digital or paper route collects the prescribed evidence.
04
Only the complete verification reports execution back to the responsible professional process.
A sent invitation is not a signed contract. Changed content requires a new process; previous originals and evidence are preserved.
SYSTEM WORKFLOW / Typical workflow
Typical workflow
01
An authorised person creates content and a revision in the associated case.
02
Approval, valid rights and the recipient group are checked before delivery.
03
Delivery, reading, acknowledgement and completion are maintained as separate states.
View the domain workflow in 3D +
M12 / WORKFLOWStep by step
Document revisionBeing transferred
Illustrative workflow model
01Content & revision
→
INFORMATIONDocument revision
→
02Check the recipient group
Content · Author · Process referenceReady for handover
An authorised person creates content and a revision in the associated case.
Approved content reaches precisely the authorised recipient group.What information is passed on?
01 → 02
Document revision
Content · Author · Process reference
02 → 03
Approved message
Revision · Recipient group · Permissions
DATA EXCHANGE / MODULE CONNECTIONS
Interfaces in context.
M12 is at the centre. The connections show which modules can provide or receive information when they have been selected and configured for your institution. Select a connection to view the data it covers.
M12 / CONNECTIONSExchange across modules
Representation & consentBeing transferred
Versioned module contracts
M01Representation & consent
→
INFORMATIONRepresentation & consent
→
M12This module
Authorised contacts and approved recipient context.Ready for handover
Authorised contacts and approved recipient context. Contact information does not yet mean content approval.
The connections show domain data relationships. Specific API contracts and partner connections are versioned and approved separately.
The check also applies to relative and resident views.
The module requirements define the exchange of domain information. Each module manages its own data; other modules use approved, versioned contracts. Permissions, tenant, revision and acknowledgement are preserved throughout.
This module, selectable according to need, is part of Oronela in finalisation. Functions, responsibilities and interfaces form the fixed scope. Finalisation combines professional acceptance reviews with feedback from care institutions: real needs determine the final improvements.
Comparison with the module requirements, implementation plan and current Oronela system codebase: 1 October 2026. Product requirements M12-01–M12-05 · M12-A–F. The following areas are explained on this page: