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.
Support and therapy staff organise activities, personal preferences and actual participation. Group activities, individual activities and prescribed therapy sessions receive appropriate resources and responsible people. Registration, consent, refusal and completion remain separate information.
The daily schedule brings together permitted information from care, appointments and nutrition. Conflicts become visible before a binding booking is made. Residents and authorised relatives see an explicitly approved participation view; their feedback remains separate from professional documentation.
Information maintained by the module
Area
Content and meaning
Activity and therapy session
Goal, resources, capacity, support, responsible people and, where applicable, a confirmed therapy order.
Participation
Preference, registration, actual participation, cancellation, refusal and documented source.
Daily routine and publication
Workflow view linked to sources, conflict, confirmed rescheduling and approved portal scope.
02 / MODULE FUNCTIONAL SCOPE
What this module covers.
3 functional areas connect this module's tasks. The following sections explain their content, processing and responsibilities.
01
Activities, therapy orders and participation
Manage individual preferences, group activities and prescribed therapy in a clear plan and document actual participation easily.
Manage individual and group activities with goals, required resources, accessibility and support needs, capacity and responsible people.
Therapy sessions are linked to a confirmed order and valid competence where such an order is required; leisure activities and prescribed treatment remain distinguishable.
Manage preferences, activities, registration and actual participation separately. Cancellation, refusal, absence and not documented are different outcomes, not a blanket non-participation status.
Use resident preferences for defined purposes; group views must not reveal other people's diagnoses, consent or care notes.
Changes to activities, resources or therapy orders check outstanding participant confirmations; documented participation retains its historical assignment unchanged.
Recurrences and templates simplify planning but do not automatically carry over past participation or consent.
Responsibility
Support and therapy staff plan and document within their competence; nursing staff add support needs; residents and representatives express preferences through the approved portal channel. Therapeutic authority is not a general administrator role.
Automation & AI
AI suggests activities from preferences and approved knowledge and formulates draft documentation. It confirms neither a therapy order nor consent or participation, and does not interpret refusal as consent. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.
Connection & offline use
Read minimal activity and participant information locally and provisionally record actual non-critical participation. Binding resource booking, therapy order approval and capacity-critical registration require an online connection.
02
Coordinated daily routine and conflict resolution
Coordinate care, therapy, rest, meals and appointments in a shared daily view and resolve burdensome overlaps early.
Project the daily routine from authorised sources for care, rest periods, medical appointments, meals and activities; each item specifies the source module, status and revision.
Make conflicts in time, resources, accompaniment and resident preferences visible before a booking is confirmed. Clearly distinguish mandatory clinical restrictions from preferences that can be balanced.
Authorised employees can change the operational sequence or escalate a conflict for professional decision; orders are changed only in the authoritative professional module.
Automatic rescheduling is initially a proposal showing effects on all involved sources; confirmations use each module's commands and visible partial statuses.
Take rest and communication needs and necessary buffers into account without passing diagnoses to roles that do not need them. Flag unknown appointment duration or buffer time as uncertainty.
The daily view becomes outdated when sources change and refreshes the relevant data; it does not present a mixture of old and new reservations as binding.
Responsibility
Support, therapy and care staff see the daily structure they need; ward management decides operational conflicts within its competence; only the corresponding professional makes medical changes.
Automation & AI
AI formulates resource-conscious workflow suggestions and explains effects using sources. Deterministic conflict checks and individual preferences remain visible; clinical tasks are never cancelled automatically. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.
Connection & offline use
Read the prepared daily schedule with its status and draft change requests locally; binding rescheduling and conflict resolution take place online using current server data.
03
Approved participation view for residents and representatives
Involve residents and authorised relatives or representatives in an understandable way, and allow feedback without access to internal care reports.
Provide approved activities, public activity information, personal registration and permitted feedback as a separate minimised portal projection.
Tie access to the current resident relationship, specific authority to represent, scope of approval and validity; family relationship alone does not grant blanket access.
Distinguish family and resident feedback, participation preferences and actual professional documentation. Portal feedback must not automatically confirm participation or clinical services.
Obtain resident approval and lawful representation decisions traceably through the authoritative portal access and content approval process of M12-C. M09 does not hold a second grant. Revocation in M12 also invalidates the M09 activity projection, API access, search and cache projections and WebSocket within the specified online time window.
Group activities do not show identifiable other residents; comments, photos and attachments require a separately checked approval context. Internal care reports never appear in a portal projection.
Queries receive responsible recipients and a status; translations of feedback remain derived texts with the original source and language.
Responsibility
Resident, specifically authorised representative, responsible support or nursing staff and administrators authorised to approve. Technical operators cannot create representation authority themselves.
Automation & AI
AI can translate permitted feedback and create draft replies. The original is retained; clinically relevant statements trigger a professional query rather than automatic interpretation. AI does not automatically send messages as a resident or professional. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.
Connection & offline use
Portal access is online in this baseline; no new offline datasets containing sensitive information for relatives. Unfinished harmless form content follows only the approved device strategy, not uncontrolled storage in the browser.
03 / PRACTICAL EXAMPLE
Therapy and an off-site appointment overlap
01
The daily view shows both confirmed sources and the scheduling conflict.
02
The responsible support team clarifies the available alternative with care and therapy staff.
03
The change is confirmed in the respective authoritative appointment or therapy process.
04
The approved resident view receives the updated status.
A scheduling proposal does not cancel a clinical task. Preferences and necessary rest periods are considered; missing duration information remains visible uncertainty.
SYSTEM WORKFLOW / Typical workflow
Typical workflow
01
The activity is planned with the preference, goal, clinical context and required resource.
02
Planning considers care, meals, rest periods and other appointments.
03
Actual participation and delivery are documented separately from the original plan.
View the domain workflow in 3D +
M09 / WORKFLOWResident · Care · Doctor
Therapy & activity offeringBeing transferred
Illustrative workflow model
01Plan an activity
→
INFORMATIONTherapy & activity offering
→
02Review the daily routine
Goal · Resource · PreferenceReady for handover
The activity is planned with the preference, goal, clinical context and required resource.
Activities and therapy are coordinated with the individual's daily routine.What information is passed on?
01 → 02
Therapy & activity offering
Goal · Resource · Preference
02 → 03
Coordinated daily plan
Appointment · Participation · Accompaniment
DATA EXCHANGE / MODULE CONNECTIONS
Interfaces in context.
M09 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.
M09 / CONNECTIONSExchange across modules
Resident preferenceBeing transferred
Versioned module contracts
M01Preferences & context
→
INFORMATIONResident preference
→
M09This module
Personal preferences and approved resident context.Ready for handover
Personal preferences and approved resident context. Views for relatives require explicit approval.
The connections show domain data relationships. Specific API contracts and partner connections are versioned and approved separately.
Programme and authorised resident or relative view.
Professional rule
Only explicitly approved content is delivered.
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.
Cross-checked against the module requirements, implementation specification and current Oronela system codebase: 1 October 2026. Product requirements M09-01–M09-03 · M09-A–C. The following areas are explained on this page: