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.
Occupancy management connects physical resources with prospective residents, reservations and actual stays. Buildings, rooms, beds and equipment are managed over time. Organisational locations and units come from M15; this module adds their physical places and availability for occupancy.
A free slot in a calendar is not enough for a reliable commitment of a place. Blocks, cleaning, equipment, place requirements and competing reservations must be checked together. The operational overview distinguishes scheduled occupancy, actual presence and occupancy billable under the valid tariff.
Information maintained by the module
Area
Content and meaning
Resource and restriction
Bed, room, equipment, period and traceable availability status.
Prospective resident and reservation
Requested place, period, requirements, responsibility and expiry of a provisional commitment.
Occupancy interval
Confirmed assignment with stay reference, controlled transfer and historical validity.
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
Physical resources, equipment and availability for occupancy
Create a reliable current view of available, restricted and cleaned places and reduce telephone queries between planning and housekeeping.
Manage buildings, rooms, beds and equipment features with temporal validity. Organisational locations and units belong exclusively to M15-A; M05 references their IDs and revisions and owns the physical assignments. No second location or unit master data set is created. Renaming does not change historical location information.
Derive availability for occupancy deterministically from the active resource, blocking period, cleaning and release status, and approved operational restrictions; an unknown status is not automatically available.
Manage restrictions with a reason category, period, responsible department and evidence. Show technical or infection-related details only to roles authorised for that purpose.
Distinguish cleaning requested, in progress, completed and approved; version the definition of required approvals. Restricted places remain visible in the plan but cannot normally be booked.
Model time intervals in the location's time zone with clear boundaries; new equipment and temporary withdrawal from service are managed as revisions.
Responsibility
Occupancy administration manages resources; housekeeping confirms assigned cleaning; maintenance confirms its part of the release; professionals apply permitted clinical blocks. Operational views contain no full diagnoses.
Automation & AI
AI can structure fault descriptions and suggest suitable work order templates. It does not lift a restriction or declare a bed clean; deterministic availability works without AI. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.
Connection & offline use
Read status locally with its timestamp and provisionally record a work note; binding availability or restriction approvals require an online connection. An offline view cannot promise a reservation.
02
Waiting list, reservation and confirmed place allocation
Guide prospective residents and occupancy preferences through a controlled process and find suitable places without double occupancy.
Manage prospective resident, waiting-list position, requested period, provisional reservation, confirmed occupancy, transfer and absence reference separately; prospective residents are not automatically admitted residents.
Use clinical placement requirements and approved preferences as minimised constraints, such as equipment or support needs. Diagnoses remain hidden where the planning decision only requires a need code.
Transactionally protect occupancy intervals against overlapping confirmed assignments and effective restrictions. A UI check alone or a late event is not sufficient.
A provisional reservation has an expiry and an assigned responsibility; an expired reservation is not shown as a binding commitment. Extensions check current competing reservations again.
A transfer references source and destination occupancy and controlled confirmation; partial failures leave a traceable transaction open. The original place is not silently released before a secured professional handover.
Show conflicting preferences with reasons; mandatory clinical constraints cannot be overridden by AI ranking or a comfort preference.
Responsibility
Occupancy planning reserves and assigns places; professional care confirms relevant needs; administration manages the waiting list. Housekeeping receives only room, time and work order information.
Automation & AI
AI explains suitable candidates and structures preferences. Rankings must disclose the approved criteria; releasing places and allocating them remain subject to deterministic checks and explicit confirmation. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.
Connection & offline use
Schedule drafts and provisional preferences can be prepared locally; reservation commitments, definitive bed allocations and transfer confirmations require an online connection.
03
Occupancy forecast, absence and indicators
Clearly distinguish planning, actual presence and tariff-dependent occupancy, and identify capacity shortages early.
Show planned occupancy, actual stay or presence occupancy and billable occupancy as separate metrics with definition, period and data version.
Hospital absence and a bed kept available are projected under the effective contract or tariff rule; no blanket legal treatment is invented. Authority over tariffs remains with M11.
Every indicator and forecast can be traced to resource, reservation, stay and tariff revisions; future expectations are labelled as forecasts.
Corrections create a recalculated projection with a traceable difference and timestamp. An invoice already sent is not silently changed by recalculation.
Shortage alerts inform the responsible planning team and can suggest tasks; they change neither occupancy nor the staff roster. Exports show the approved definition and permission scope.
Responsibility
Occupancy management and care home management receive permitted indicators; operational billing receives the individual references it needs; other staff do not receive broad resident lists.
Automation & AI
AI explains shortages and summarises evidenced causes. Forecast assumptions are disclosed; actual indicators and billable values are calculated deterministically, with no LLM tariff decisions. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.
Connection & offline use
Read only a prepared, authorised snapshot; new calculations, exports and planning that affects decisions require an online connection. The data version remains visible at all times.
03 / PRACTICAL EXAMPLE
Room change followed by cleaning
01
The planning team reserves a suitable available destination place.
02
The transfer is confirmed in a controlled process with admission administration.
03
A housekeeping work order is created for the previous room.
04
After completion and the required inspection, M05 confirms availability for occupancy again.
The original place becomes available only within the secured workflow. A completed cleaning task and confirmed room release remain separate steps.
SYSTEM WORKFLOW / Typical workflow
Typical workflow
01
Suitability, availability and the approved room status are checked for the period.
02
The reservation connects the intended stay to the physical resource.
03
The confirmed assignment carries forward admission and transfer; room approval enables the next occupancy.
View the domain workflow in 3D +
M05 / WORKFLOWResident · Care
Available placeBeing transferred
Illustrative workflow model
01Check place
→
INFORMATIONAvailable place
→
02Reserve
Room · Suitability · PeriodReady for handover
Suitability, availability and the approved room status are checked for the period.
Reservation and stay work together; room release completes the cycle.What information is passed on?
01 → 02
Available place
Room · Suitability · Period
02 → 03
Confirmed reservation
Stay · Resource · Admission
03 → 01
Room release
Discharge · Cleaning · Availability for occupancy
DATA EXCHANGE / MODULE CONNECTIONS
Interfaces in context.
M05 is at the centre. The connections show which modules can provide or receive information when selected and configured for your institution. Choose a connection to see its data scope.
M05 / CONNECTIONSExchange across modules
Place & reservationBeing transferred
Versioned module contracts
M05This module
→
INFORMATIONPlace & reservation
→
M01Stay & assignment
Reservation, admission, transfer and absence.Ready for handover
Reservation, admission, transfer and absence. Double occupancy is prevented.
The connections show domain data relationships. Specific API contracts and partner connections are versioned and approved separately.
Resources and occupancy periods with their data version.
Professional rule
The definition and period of every indicator remain visible.
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 M05-01–M05-04 · M05-A–C. The following areas are explained on this page: