The automatic suggestion when creating an operation can now be configured in the control center settings. If the option is enabled, the system automatically creates one resource suggestion for a new operation as soon as location and keyword are set. If it is disabled, a suggestion is only created on request.

The window for operation handling was completely reworked. It now offers tabs for resources and the resource browser, tasks, documentation, event log and quick documentation, as well as a revised dispatch flow with patients and reservations.

The GIS is optionally available in a dark map style, and the choice is saved in the user settings. For the open operation, the routes of the resources on their way are shown with an ETA overview.

A resource's context menu now shows the end of duty or the next start of duty. In the resource list in the operation window, resources whose duty ends within the next 60 minutes are marked.

The resource search now also finds the verbal callsign and shows the matched alias.

With district grouping enabled (by name or ZIP code), an area's dispatch groups were not applied to addresses in another district of the same group, so no dispatch order took effect. The dispatch groups now apply to all districts of the group.

After selecting a keyword in the operation window, the input field lost its focus. The focus is now kept so you can continue right away.

When switching between operations in the operation window, the patient data of the previous operation could still be shown. The data of the selected operation is now always shown.

The GIS preselection did not use the operation selected in the operation window. This has been fixed.

Status changes of operations and the completion of tasks were sometimes transmitted with stale values, so the display was only correct after a reload (e.g. a task stayed in the "processing" state). The display now updates correctly right away.

OAuth 2.1 now supports refresh tokens with rotation and revocation. The Realm (sessions) is connected as a resource server and provides MCP access for sessions, controlled by license.

The API error format (problem details) is described in the OpenAPI documentation, and API error messages are unified. API calls without sign-in now return status codes instead of redirects to the login page.

Changes to an operation in the Realm now always require an explicit operation ID; the implicit "current operation" no longer applies.

Patient transport to hospital is now fully based on the patient allocation code (PZC). No patient is transported without a PZC any more; it decides which hospitals and which department come into question for the patient. This integrates the hospital transport assignments and bed capacities announced in 4.8.0.

The resource transmits its patient's PZC before transport begins: resources with GPS do so automatically 10 to 25 seconds after the patient data (the full code consists of incident code, patient age and urgency level), and the PZC appears in the operation's event log. In the notification window, an open task appears that stays until a destination has been assigned to the patient. Resources without GPS report the PZC, their preferred hospital and parts of the pre-registration details verbally by radio or via the office line; nothing is entered automatically in the operation window. Such a resource only drives to a destination the control center tells it.

The urgency of the PZC (red, yellow, green) determines triage: resources treat the most urgent patients first.

Who chooses the hospital is set by the session owner with the PZC mode, at simulation start or while it runs via the home window: in "Auto" mode the resource enters preselection and destination itself, in "Hybrid" mode it transmits a preselection and drives there until the control center assigns a different hospital (it is then re-routed), in "Manual" mode it waits on scene for the control center's assignment.

On the PZC page in the dashboard, the control center defines which hospitals accept which PZC and urgency levels; maximum care hospitals are supported.

New is the control center option "Transport destination by PZC assignment of the hospitals": if it is enabled, a patient is transported to the nearest hospital to which the control center has assigned the incident code of the PZC. Without the option, a default table applies that defines the minimum required departments per incident code (deliberately kept lean so that not every patient ends up at the maximum care hospital); the patient is then transported to the nearest hospital with these departments. If the required departments are missing, the simulation falls back to the nearest hospital that has them.

The assignment is made in the "Hospitals" tab of the status overview: received PZCs can be taken over, or a PZC can be entered by hand. The tab lists only hospitals that accept the PZC and its urgency, each with the accepting department and an occupancy grid; the resource's preselection is marked. The hospital's registration form assigns the patient, and the arrival time is derived from the resource's route. On acceptance, hospital and department are entered automatically in the operation's patient module. The hospital refuses if the department is at capacity during the treatment. Active allocations are listed and can be cancelled.

Only allocations made with the form occupy a place at the hospital. The operation desk's patient module covers only the agreement between control center and resource and does not inform the hospital; a destination set directly there does not change the occupancy.

The PZC as a whole is a planning tool. What counts is what the dispatcher assigns in the operation's patient module: even if a hospital has no PZC configuration or does not accept the PZC, the simulation carries out the assignment and the patient is treated there (forced).

Hospitals have departments with a name, an entrance and a capacity. The overview shows each department's free places as a badge (free/total), counts announced patients and updates live. Treatment times depend on the urgency.

A session starts with a realistic, time-of-day dependent hospital occupancy; the hospitals' own patients take the treatment times of allocations.

Resources drive to the entrance of the assigned department. An accompanying emergency doctor is added to the transported patient.

Helicopter landing zones (HLZ) are now POIs of their own with the category "Helicopter landing zone". Hospitals, stations and departments refer to an HLZ POI when they are created instead of storing the coordinates of a landing zone.

If the HLZ is more than 500 m from the hospital (or department), the helicopter requests a ground transport by radio right after take-off and names the HLZ. The dispatcher creates the operation at the HLZ POI, and the patient moves to a new operation without a caller. The ambulance there waits for the helicopter or takes over the patient after landing; the helicopter's doctor rides along if the doctor accompanies the patient.

After the handover at the hospital, an ambulance brings the helicopter's doctor back to the HLZ. This also covers the combined ground and air transport in which the helicopter flies to the HLZ empty. An ambulance that takes over the patient, transports it or brings the doctor back is not available for dispatch and states the reason by radio.

New radio messages: the control center can tell a resource the assigned destination by radio (and in the resource's phone call) and ask for the PZC, the preferred hospital and the pre-registration details. Resources report the number of triaged patients and their triage category (red, yellow, green). Helicopters request a ground transport from the HLZ to the hospital by radio, and ambulances report when they are not available because of a patient takeover or the doctor's return to the HLZ.

Resources can be sent back to their station from the menu ("force drive back").

Resources react immediately to speak requests. The radio flow was reworked and is now event-driven with correct timing.

The phone and radio window, the home window with virtual control room and the notification window were moved to the new interface.

Entering a session is now considerably faster; the session state is restored in the background behind a loading screen. If a window loses its session, a status screen is shown.

The chat announces when users join or leave the session. System messages are shown in each user's language.

A resource's simulation information can be copied for the forum.

Control center validation was adjusted. External hospitals and maximum care hospitals are no longer mandatory, and the required three hospitals are checked as the message describes. The minimum mission load is checked against the daily total instead of a single hour.

The patient data reported by the resource now fills the patient in the operation, ages are consistent and missions are more varied.

When taking over call data, the first AML location was set as the place if the caller had no known POI, although only the phone number (and, if enabled, the caller's known POI) should be taken over. This has been fixed; AML locations remain selectable via the AML menu.

Urgent EMS missions that always require an emergency doctor (e.g. resuscitation) could be created without a doctor requirement, so the dispatched NEF found no indication and left again. Such missions now always require a doctor, and urgent missions follow the event's doctor category.

With grouped districts, after a failed load of the addresses, missions could only be created at POIs and no longer on streets. Street missions are created again.

When a resource reached a location off the drivable roads (e.g. a POI at a lake), it reported the location as not found. It now recognizes the mission by its location text and starts processing the mission there.

Patient health jumped abruptly after periods without treatment instead of changing continuously. This has been fixed.

During operations with an aerial ladder (DLK) and door openings, the mission processing stopped although it should have progressed. It now continues reliably.

EMS missions stopped after an aerial ladder (DLK) arrived at the scene. They now continue normally.

During patient handover on scene, a resource could get stuck in a loop. The handover is now completed.

When an operation was cancelled, the resource continued its drive although it was no longer dispatched. It now ends the drive immediately and reacts correctly to the cancellation.

Paused simulations continued with the wrong time after a session was restored, and time scaling could produce a flood of events at once. Both have been fixed.

Status 4 was not sent correctly after the dispatch for a doctor pickup. This has been fixed.

A free-text radio message from the control center caused an error when no resource was selected. It is now sent correctly.

Resources acknowledged control center radio messages (e.g. "doctor on the way") partly with control center wording such as "dispatch has understood". The acknowledgement now comes from the resource itself.

Sessions could be deleted prematurely although they should not have counted as inactive. This has been fixed, and inactive sessions are cleaned up more reliably.

Under high load, the simulation and the suggestions could react with a delay. Performance was considerably improved.