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.
Nutrition and hospitality connect personal choices, safe dietary requirements and the kitchen's work. Residents, employees and guests order through appropriate individual views; the kitchen receives a shared production requirement. The person ordering, consumer and payer remain clearly assigned.
Recipes, ingredients, allergy information, dietary requirements and consistency are used at their confirmed status. Production and procurement access the supplies inventory in M10. Meals taken off site add labelling, transport, handover and, where applicable, outstanding professional approval for consumption.
Information maintained by the module
Area
Content and meaning
Nutrition profile
Preferences, confirmed restrictions, texture, support and time requirements with source and validity.
Meal order
Menu revision, consumer, person ordering, payer, portion, pricing profile, location and acceptance or change status.
Production and serving
Aggregated demand, recipe yield, ingredient batches, portions, handover, leftovers and recall reference.
02 / MODULE FUNCTIONAL SCOPE
What this module covers.
5 functional areas connect this module's tasks. The following sections explain their content, processing and responsibilities.
01
Nutrition profile and purpose-limited kitchen view
Accommodate preferences in everyday practice and provide the kitchen with precisely the necessary, safe information from a current profile.
Manage preferences, confirmed allergies or intolerances, approved diet, consistency, required assistance and timing requirements as separate categories with source, confirmation and validity.
A confirmed clinical restriction takes priority over a preference. Unknown, unresolved and explicitly ruled-out allergy statuses remain distinguishable.
The clinical allergy and order source remains in M03; M08 maintains only a purpose-specific versioned projection and its own catering information. There is no independent, contradictory allergy master database.
The kitchen view shows only necessary identification, delivery or portion, relevant restrictions and handling instructions. Diagnoses, full care records and private life histories remain excluded.
Profile changes invalidate prepared suggestions and relevant tasks not yet executed; an unclear source prompts a query to a named responsible professional.
Shared devices do not show previous resident profiles after logout or a user change. Exports and labels are subject to the same field minimisation.
Responsibility
The kitchen maintains permitted preferences and catering data; qualified care staff and doctors confirm clinical requirements in the responsible module; support staff add expressed preferences without approving allergies or diets.
Automation & AI
AI structures preferences and suggests suitable meal descriptions. Deterministic, approved ingredient and constraint checks remain authoritative; AI cannot override an allergy or authorise a diet. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.
Connection & offline use
Read minimal authorised kitchen data with its status and record preferences as drafts; clinical approval and current confirmation of safety-relevant nutritional changes take place online.
02
Menus, portions and meal orders
Derive meal requirements from presence and confirmed profiles, and avoid duplicate orders and manual quantity reconciliation.
Maintain the menu plan, recipe and ingredient version, portion size, serving time and place, special diets and resident orders together; version ingredient provenance and approved allergen labelling.
Consider presence or absence, existing orders and off-site appointments when determining needs. An uncertain return time is shown as planning uncertainty, not invented.
Maintain a unique domain order reference for each resident, meal and service date; alternative or replacement meals replace or supplement an order only explicitly and with a reason.
A change after the kitchen order deadline creates a change order requiring confirmation; a portion already produced or served must not be silently deleted.
Check the current relevant nutrition revision before production or serving approval. A changed allergy or diet requires a checked alternative or restriction.
Quantity aggregates and serving labels contain only necessary resident information; order and serving status and deviations are traceable.
Responsibility
The kitchen plans menus and confirms preparation; nursing and support staff record permitted order preferences; professional dietary requirements are changed only by authorised clinical roles.
Automation & AI
AI suggests alternatives based on approved preferences and recipes and explains demand discrepancies. Quantities, allergy checks and order deduplication are deterministic; unverified ingredients are not automatically confirmed. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.
Connection & offline use
A non-critical meal preference can be a local draft. Binding orders, changes and safety-related serving checks require an online connection; outages follow a clinically approved kitchen process with later retrospective entry clearly marked.
03
Meals taken off site, handover and approval for consumption
Reliably prepare and hand over appropriate food for a medical appointment, and permit consumption only according to confirmed instructions.
Meals taken off site bind the resident, confirmed appointment, transport or accompaniment, nutrition profile, specific preparation instructions and their revisions.
Select the composition using approved recipes, allergies, diet or texture and preferences. Preferences apply only within permitted options.
Document labelling, portion, necessary storage and transport conditions, serving or handover time and receiving person; unclear shelf life or storage leads to a query or a professionally defined restriction route.
The consumption rule is explicit: a confirmed time or order condition, or approval pending. After an examination, approval is never calculated solely from the time, appointment end or distance travelled.
Appointment, order or allergy changes before handover invalidate affected approvals. A portion already handed over triggers a clear warning, contact or correction task and remains visible in the history.
Handover, authorised receipt of clinical permission to eat and actual documented consumption are different forms of evidence. The kitchen does not give medical approval.
Responsibility
The kitchen confirms composition and preparation; accompaniment staff confirm handover and applicable requirements; a competent clinical person confirms permissible approval in the order module. Transport staff see only necessary handling information.
Automation & AI
AI suggests compatible alternatives and creates localised packing-list drafts. Clinical restrictions and approvals are deterministic; AI must invent neither a permitted consumption time nor storage instructions. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.
Connection & offline use
Authorised packing lists are readable locally with their status; binding safety-relevant handover and approval checks take place online. In a connectivity gap, no supposedly current approval status is shown; the professional outage process remains visible.
04
Order meals for residents, employees and guests
All consumer groups use the same ordering process with their own views and appropriate permissions.
Residents choose their meals themselves or with care staff support. Authorised relatives can order for the resident and additionally choose their own visitor meal. Employees use “My meals”; guests receive limited access or are registered at reception. These entry points lead to the same meal core.
The person ordering, actual consumer, resident reference, payer and authority to represent are managed separately. A relative ordering two meals therefore does not accidentally inherit the resident's allergy profile or invoice for their own meal.
Daily and weekly plans show alternatives, quantities, prices or subsidies, location, collection or delivery, and order and cancellation deadlines. Recurring orders support end dates and exceptions. Extra portions are explicitly selected; resubmitting does not create another portion.
A resident's order entered by care staff and the resident's own choice refer to the same logical meal. A new allergy or unresolved ingredient causes the affected choice to be rechecked. A change after the deadline goes to the kitchen as a change order rather than deleting work already produced.
Employee leave cancels a privately ordered meal only if a corresponding rule is approved. Guest data is retained for a limited period according to its purpose. Charging and subsidies provide M11 with a verified service reference; a payroll deduction requires an explicitly approved handover rule.
Responsibility
Each person manages their own orders. Orders on behalf of residents require current, appropriate authority; the kitchen sees the necessary production quantities.
Automation & AI
AI suggests alternatives from verified recipes and drafts preferences. Quantities, prices and allergy checks follow the approved rules. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.
Connection & offline use
A choice can be saved provisionally locally. Binding orders, changes and cancellations are checked online against the current profile.
05
Production, kitchen procurement and portion-specific serving
Confirmed orders create a traceable quantity and production plan through to serving.
Confirmed meals are grouped by menu, diet, serving location and consumer group. Recipe yields, portion sizes and unit conversions are versioned. Committed stock and expiry dates feed into requirements; missing quantities or unclear conversions are flagged for review.
Procurement suggestions use the current ingredient stock from M10. Budget, supplier, price limits and responsibility are checked before an external order. M08 manages recipes, orders and production; inventory, purchasing and goods receipt remain with M10. Ingredients are therefore not counted in two inventory ledgers.
Production batches link the recipe and ingredient revisions used to the portions produced. Approved quality, storage, transport and serving evidence is documented according to the kitchen profile. The system does not invent temperature limits or shelf-life limits.
For a substitute product, allergens, cross-contact and current nutritional requirements are checked again. A recall can be traced to the affected batches and portions. Clinically relevant serving requirements remain visible without opening a complete care record to the kitchen.
Preparation, serving, handover, documented consumption, and leftover or waste quantities remain separate records. A late cancellation creates a traceable deviation, not negative production. Resident, staff and guest meals produced together are billed separately using their respective service and payer references.
Responsibility
The kitchen plans and confirms production, procurement approves purchases within the appropriate scope, and M10 checks goods receipt.
Automation & AI
AI can explain demand and permitted reuse. Approved standard orders can be automated within checked rules; unclear substitutions remain human decisions. AI features require activation at your request. Processing remains on Oronela's own servers in Switzerland.
Connection & offline use
Binding orders, stock and safety-related serving checks require an online check. A professionally confirmed kitchen process describes operation during outages.
03 / PRACTICAL EXAMPLE
One menu for three consumer groups
01
Residents, staff and guests choose through their own views.
02
The kitchen groups confirmed quantities by menu and diet.
03
A substitute product is checked against current ingredient and allergy requirements.
04
Serving is documented by portion; services go to M11 with separate payer references.
Shared production does not require multiple ordering and inventory processes. The kitchen sees necessary nutritional information while private HR and care content remains protected.
SYSTEM WORKFLOW / Typical workflow
Typical workflow
01
Approved dietary requirements, relevant allergies and personal preferences determine demand.
02
Kitchen planning coordinates menus and quantities with requirements, absences and handover.
03
Serving and handover are confirmed; changes remain attributable to the valid order.
View the domain workflow in 3D +
M08 / WORKFLOWResidents
Approved dietary requirementsBeing transferred
Illustrative workflow model
RulesProfessional foundation
→
INFORMATIONApproved dietary requirements
→
02Plan menu & quantities
Allergy · Diet · ValidityReady for handover
Approved dietary requirements, relevant allergies and personal preferences determine demand.
Preferences and approved dietary requirements become an appropriate meal.What information is passed on?
Rules → 02
Approved dietary requirements
Allergy · Diet · Validity
01 → 02
Personal needs
Preferences · Absence · Portion
02 → 03
Menu & serving list
Meal · Quantity · Handover
DATA EXCHANGE / MODULE CONNECTIONS
Interfaces in context.
M08 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.
M08 / CONNECTIONSExchange across modules
Personal preferenceBeing transferred
Versioned module contracts
M01Personal preferences
→
INFORMATIONPersonal preference
→
M08This module
Preferences and resident context approved for a defined purpose.Ready for handover
Preferences and resident context approved for a defined purpose. The kitchen sees only necessary nutrition information.
The connections show domain data relationships. Specific API contracts and partner connections are versioned and approved separately.
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 M08-01–M08-04 · M08-A–E. The following areas are explained on this page: