EventMED Dispatch

EventMED Dispatch User Manual

Important: EventMED Dispatch is a dispatch coordination and resource management tool. It is not a medical device and must not be used to make clinical decisions. Clinical responsibility remains with qualified medical personnel.

1. First Launch

On first launch, the End User Licence Agreement is shown. Scroll to the bottom to enable Accept. Choose Accept to continue or Decline & Quit to close the app.

The EULA is recorded locally after acceptance. It can be viewed again from About.

If the operating system secure storage service is unavailable, the app shows a startup warning explaining that the database may be stored unencrypted. On Linux this usually means libsecret, GNOME Keyring, KWallet, or another secret service is not available.

2. Licensing and Trial

Trial and read-only access

The app can be evaluated for 30 days. Trial exports include a watermark. After the trial expires, existing event data remains viewable/exportable, but write actions are blocked until a valid licence is activated.

Licence tiers

The Command Module is also available during an active trial and in development builds. Where the installed licence does not include Command, the Command workspace remains visible but dimmed and explains that Organisation or Enterprise is required. The same entitlement is enforced by the application services, not only by the startup screen.

Licence expiry and grace period

When a paid licence expires, a 14-day grace period applies during which write access remains fully available. After the grace period ends, the account enters read-only mode — existing event data remains viewable and exportable, but write actions are blocked until the licence is renewed.

Activating a licence

1. Open About or use the licence prompt on startup.
2. Choose Manage Licence or Activate Licence.
3. Paste the licence key and click Activate.

3. Startup Screen

The startup screen appears when the app opens and when leaving an event.

• Use the persistent Dispatch and Command workspace buttons at the top to choose how this installation will be used. The last workspace is remembered.
• The app finishes loading local data and licence state before showing the workspace. Startup notices such as the EULA, licence prompt, and encryption warning are shown in priority order rather than replacing one another.

Dispatch startup

• Controller Name: required before creating, opening, or joining an event. It is used on logs, audit entries, and reports and is remembered on this installation.
• Continue: opens the remembered or most recent active event in one click.
• Recent Events: the five newest events, with venue, call count, date, and a textual Active, Locked, or Completed state.
• View All Events: opens the complete event history in a searchable, status-filterable table. From there you can open, export, replay, archive, or delete an event.
• Tools: expands less frequent administration actions so the main startup path remains uncluttered.

Command startup

Enter the duty officer name and, where useful, their role. The officer is signed in as part of opening Command; there is no separate sign-in button on the Command dashboard. Use Handover later when another officer assumes responsibility.

Choose one of three paths:

An active standalone session appears as a one-click Continue action. Ended sessions remain available to reopen; each session has an explicit End Session action so separate standalone operations do not become one continuous record.

4. Events

Creating an event

Click New Event, enter an event name and venue, optionally choose a scenario template, then click Create Event.

Editing event information

In the dispatch screen, click the event name in the header to edit event metadata, attendance, notes, and map settings.

Completing an event

Use Complete Event from event details when an event is operationally finished. The workflow warns about open calls and incomplete tasks, asks for final notes, confirms that operational reports are exported or deferred, and requires a closeout backup. It then signs off active units and records the completion time, completing controller, log entry, and audit entry as one all-or-nothing close-down. Finalise and export the governed Command report after completion, then create the archival backup containing that final report.

Completed events show a textual Completed state on the startup screen. They remain viewable and reportable, but editing event data, units, calls, tasks, logs, maps, or audit-affecting data requires reopening the event first. Reopening is an explicit action in event details and is audit/log tracked.

Locking and reopening

Locked events are protected from further modification but remain viewable and exportable. Use event locking after final checks, exports, and backups are complete if your organisation needs a separate lock.

5. Training Mode

Training mode is for practice and tabletop exercises. It is not saved to the database and is discarded when you leave the session.

• Supports sign-on, calls, assignments, logs, tasks, scenarios, and drag-to-assign workflows.
• Shows a visible training banner.
• Does not provide persistent reports, audit trail, or sync.

6. Dispatch Screen

The main event screen has three resizable areas:

Drag vertical or horizontal dividers to resize the working areas. Keyboard users can focus a divider and use the arrow keys to resize it. When the app window is resized, EventMED keeps the centre call area usable and clamps the side panels so resize handles remain available. On narrower screens the dispatch layout becomes more compact to preserve the operational view.

7. Header Bar

The header provides Back, About, event details, controller swap, live counters, wait list, audit status, sync controls, snapshot (sync clients only), map window, zoom, theme, audio mute, and clock. The current date is shown directly below the clock.

Live counters

The OPEN counter is the quickest way to see at a glance whether any calls are waiting for a resource.

Wait list

The wait list is a lightweight holding area for units that are not yet deployable but should remain visible. Right-click any unit and choose Wait List to add it. Multi-select units and use Wait List (N) to add several at once.

When units are on the wait list, their callsigns appear in the header labelled WL. Click any callsign tag in the header to remove it immediately. You can also right-click the unit in the sidebar and choose Remove from Wait List. Additions and removals are logged.

Sync client snapshot

When connected to a Dispatch host as a sync client, a Snapshot button appears in the header. Clicking it saves a .emdevt file of the current live event state — calls, units, log, tasks, and Command records — to a location of your choice.

Snapshots are also saved automatically every 10 minutes to the configured auto-backup folder (the same folder used by the host for scheduled backups). The button label updates to show the time of the last auto-snapshot.

A client snapshot can be imported using Tools → Import Event on any installation, recovering the event up to the moment of the last snapshot if the host machine becomes unavailable and no recent full backup exists.

Audio alerts

EventMED plays audible alerts for two situations:

• New call raised — a short ascending double-beep when any call is created (including in training mode).
• Unassigned call warning — a three-tone warning pattern that plays alongside the on-screen escalation toast when a call has had no unit assigned for five minutes.

The 🔔 button in the header mutes all audio alerts. When muted it shows 🔇. The mute preference is saved and restored on next launch.

8. Units

Use Sign On or F9 to add a unit with callsign, role, zone, crew, telephone, and standby location. CSV import can batch sign on units.

Unit statuses

The usual response flow is: Available/Clear → Responding → On Scene → Left Scene → Arrived → Clear. A non-conveying unit may clear directly from scene. Use Sign Off when a unit's shift ends.

Right-click actions

Right-click units for actions such as clear at standby, assign to the selected call, on scene, left scene, arrived, clear, stand down, edit, and sign off. For a unit with no active call assignment, use the Status submenu to choose Available, Clear, Standby, Unavailable, or Off Duty. The current status is shown but cannot be selected again.

Shift+click supports multi-select and bulk actions. The bulk Status (N) submenu changes only eligible selected units and will not overwrite an active call assignment. Status changes are written to the event log and audit trail.

Unit context menus can also be opened from the keyboard. Focus a unit row, then press the Context Menu key or Shift+F10. Use the arrow keys to move through menu items and submenus, Enter to choose an action, and Escape to close the menu.

Actions that remove a unit from an active assignment, such as Stand Down and Clear From Call, ask for confirmation before changing the call timeline.

Status dots include both colour and shape cues. Deployable or travelling states such as Available, Clear, Responding, and Left Scene use a round indicator; stationary or unavailable states use a square indicator. Hover over a status dot to read the status text.

Undo last unit action

After any unit status change or timeline stamp, a 30-second undo window is available. Right-click any unit to see ↩ Undo — restore [callsign] to [previous status] at the top of the context menu. Using undo clears the timestamp that was just set, restores the unit's previous status, and logs the reversal. Undo is not available in training mode and disappears automatically after 30 seconds.

CSV sign-on

callsign,role,standby_loc,crew,tel
AMB1,Ambulance,Gate A,"A Smith;B Jones",07123456789

9. Calls

Use Raise Call or F1 to create a call. Record priority, location, origin, details, comments, and optional auto-assignment. Category, age range, and PRF can be completed later through Patient / Reporting and the close workflow.

Priorities

Priority changes require a reason and are logged and audited.

Assigning units

Assign units by right-clicking a unit, dragging a clear unit onto a call card, or using call or unit context actions. Multiple units can be assigned to a single call.

Delayed call entry

Use Delayed in the unit sidebar to enter a call retrospectively. Delayed calls use the normal call record, but the date, received time, call details, assigned units, and unit timeline stamps can be entered manually.

To add crews to a delayed call, choose Add Unit in the Delayed Call Entry form, select the unit, then enter any known Activated, On Scene, Left Scene, Destination, Arrived, and Cleared values for that unit. Use Add Unit again for each additional crew that attended. Unit timelines are independent, so one unit can be recorded as on scene while another is only activated, cleared, or omitted.

If a delayed call is already cleared or closed, it records the call history without changing the units' current live status. If the delayed call is still open, each assigned unit's current status is set from that unit's latest entered timeline point. Invalid timeline order is rejected per unit, and the same unit cannot be added twice to one delayed call.

Tick Close call after entry when the incident was already complete before it was entered. If a close classification is available for the event, choose it before saving. Delayed entries are marked in the audit trail and event log as retrospective entries.

Secondary assignments

A unit already active on one open call can be assigned to another open call as a secondary assignment. Select the additional call, right-click the active unit, and choose Assign secondary.

The unit remains primarily attached to its original call, and the sidebar shows a multi-call indicator. When a unit has more than one active assignment, right-click it and use Update Call Status to choose the specific call before recording On Scene, Left Scene, Arrived, or Clear updates. Each submenu is labelled with the call reference and location so the timeline stamp is applied to the intended call.

Clearing a unit from one call does not clear it from its other active calls. The unit becomes clear only after all active assignments have been cleared.

Linked unit badges

Linked units are marked in the unit sidebar with a compact link badge beside the callsign. The badge does not show a text label in the list, keeping the sidebar easy to scan. Hover over the badge to see the linked group name, lead unit, and members.

To link units, select two or more units in the sidebar, right-click one of the selected units, and choose Link selected units. Right-click an already linked unit to set it as the lead, unlink that unit, or unlink the whole group.

Linked group actions are explicit. When a linked unit is eligible, its context menu can assign clear linked members to the selected call, mark linked responders on scene for the same call, record left scene and arrived for linked members on the same call, or clear linked active members from that call. Units that are unavailable, signed off, or not on the same call are left unchanged.

If linked units drift into different states or calls, the badge changes to a warning style. Hover over it to see which unit is out of step.

Linked groups do not automatically copy every action from one unit to another. Use the linked-group menu actions when you intend to move the group together. This keeps bulk changes deliberate while still making common paired-team workflows quick.

Call list filters

Three filter tabs appear above the call list:

When the Open or All view contains open calls, press Arrow Up or Arrow Down to move through them in their displayed order. Selection stays visible as the list scrolls. Arrow-key call navigation is suspended while typing in a field or while a modal or context menu is open.

Unassigned escalation alerts

If an open call has no unit assigned for five minutes, a warning toast appears and the unassigned audio alert sounds. Each call triggers this alert once per unassignment period — if a unit is assigned and later removed, the timer resets. The check runs every 30 seconds.

Open call cards also show assignment state. Calls with no active unit show AWAITING, and long-waiting unassigned calls show ESCALATE so they can be picked out without confusing that state with clinical priority.

Closing and reopening calls

Calls can be closed with a configured classification. A PRF number (Patient Report Form reference) can be recorded at close. Closed calls can be reopened from call detail if needed.

The close form also includes optional reporting fields for high-level incident category and patient age range. These fields are designed for quick capture rather than clinical assessment, and can be completed at close when the information is known.

Required fields are highlighted and focused when a form cannot be submitted, alongside the error toast. Correct the highlighted field and try the action again.

10. Call Detail

Select a call to view and manage its details, assigned units, response timeline, notes, close controls, and map pin action.

The compact Patient / Reporting strip shows category and age range. Completed reporting fields are highlighted green; missing fields are highlighted red so controllers can quickly see what still needs recording. Click a field to update it on an editable call.

• Activated: unit assigned and responding.
• On scene: unit arrived at incident location.
• Left scene: unit left incident location, optionally with destination.
• Arrived: unit arrived at destination.
• Cleared: unit is free or stood down from the call.

Per-call preview/export includes call details, timeline, assigned units, and relevant log information.

11. Log and SpeedType

Event log

The log records operational notes, call/unit updates, and controller actions. It is searchable and newest-first.

Press F2, F4, or F6 to add a log entry. Use Ctrl+Enter to submit from the log entry modal.

Editing log entries

Existing entries can be edited. The change is attributed and audit-tracked.

SpeedType

SpeedType stores application-wide abbreviations shared across all controllers on the same installation. Type an abbreviation in a supported text field and press Space or Tab to expand it. Manage abbreviations from the SpeedType button in the header.

Use Export in the SpeedType modal to save abbreviations as a .json file, and Import to load them on another installation. This is the recommended way to keep SpeedType sets consistent across multiple machines.

12. Tasks

Tasks are in-event reminders with an optional due date and time. Add tasks from the right panel, mark them complete, or reopen them. The creator and completing controller are recorded automatically.

Due tasks trigger one on-screen toast alert. New tasks store an exact deadline, so overnight and multi-day reminders are unambiguous. Legacy time-only tasks remain supported. Task state is included in synced event state for connected clients.

13. Reports and Exports

Built-in reports

• Event summary report.
• Internal patient reporting report.
• Organiser report.
• Full event log CSV.
• Unit roster CSV.
• Per-call report/preview.
• Audit report HTML and audit JSONL export.
• Event timeline export.
• M/ETHANE after-action report.

Longer exports show progress in the relevant button or panel while the file is being generated, so the interface remains responsive during CSV, HTML, or PDF generation.

The Reports panel shows Patient Reporting Completeness for category and age range. The internal Patient Reporting report contains:

• completion rates for category and age range;
• category, age-range, and outcome breakdowns;
• call-level reporting rows with priority, status, category, age range, outcome, and PRF where recorded.

These figures are call-level reporting records, not a patient headcount. A call can involve zero, one, or multiple patients. The public summary remains aggregate and deliberately excludes individual incident, patient, PRF, and personnel details.

Summary and organiser reports include call category breakdowns where categories have been recorded. The full summary includes age range in its call table when that data exists. Call exports and ad-hoc call reports can include category, patient age range, and PRF columns for internal post-event analysis.

Ad-hoc report builder

Choose a source such as calls, units, or log entries; select columns; add filters; sort the table; export as CSV or PDF/HTML.

Unit reports are based on units that were genuinely signed on or operationally active during the event, not scenario roster seed data that was never brought into use.

Dispatch Replay access

Use Open Replay in the Reports panel to review the current event as a time-based replay. From the startup screen, choose View All Events and then Replay beside any saved event to open replay without entering the live dispatch screen.

14. Dispatch Replay Mode

Dispatch Replay Mode reconstructs an event at a selected point in time. It is intended for debriefs, controller training, event review, and checking how calls, units, logs, tasks, and major incident markers developed during the operation.

Replay is read-only. Changing the replay time does not edit the original event.

Replay layout

Timeline filters

The filter buttons in the top bar show or hide categories in the Timeline Events panel and on the bottom scrubber.

Filters do not change the replay time or the event state shown in the units and calls panels. They only change which timeline markers are visible.

Playing and stepping through replay

• Play/Pause runs the replay clock forward.
• Speed changes playback rate.
• Prev and Next jump between visible timeline markers. Active filters affect which markers these buttons use.
• Clicking a timeline row or scrubber dot jumps directly to that moment.
• Selecting a call keeps its detail panel focused while the replay time changes, where possible.

Replay counters

The replay header counters show the event state at the selected replay time:

Exporting a replay snapshot

Use Export Snapshot to save a text summary of the current replay moment. The snapshot includes open calls, visible units, and nearby timeline entries around the selected time.

15. Scenarios

Scenario templates let you reuse event configuration:

• Standby locations.
• Medical destinations.
• Unit roles.
• Zones.
• Closing classifications.
• Optional unit roster seed data.

Use the Scenario panel during an event to edit the current event lists. Use Tools → Scenarios at startup to create, edit, import, export, or delete reusable templates — no open event is required to build or update a scenario.

In the in-event Scenario panel, click a row name to edit it. Use the arrow buttons to reorder lists, and the delete button to remove an item.

16. Major Incidents

The M/ETHANE panel supports standby ETHANE declarations and full METHANE major incident records.

• Record Major declaration, Exact location, Type, Hazards, Access, Number of casualties, and Emergency services.
• Escalate ETHANE to METHANE.
• Add casualties with triage category and destination.
• Add incident log entries.
• Generate SITREP text for sharing.
• Stand down and export an after-action report.

Clinical note: Triage categories are records of clinical decisions made by qualified personnel. The software does not make triage recommendations.

17. Maps

Uploading and removing maps

Open event details from the header, upload an image map, or remove the current map. Supported image types include PNG, JPG/JPEG, GIF, WebP, and SVG.

Map window

Open the map window from the header. It is suitable for a second screen and refreshes as calls, units, pins, and map configuration change.

Map setup

Use Map Setup to place standby locations, unit home positions, and landmarks. These positions are stored with the event.

Call pins

Select a call, use the pin action in call detail, click the map position, and save. Closed calls are removed from the live map.

Sync and locks

Map changes are sync-aware and validated by the host. Locked events reject map write actions.

18. Multi-Controller Sync

Sync lets one host share event state with clients on the same LAN. It is available on Organisation and Enterprise licences. Both Dispatch controllers and Command officers connect to the same sync session — there is one host per event and all other installations are clients, regardless of whether they are running in Dispatch or Command mode.

Sync traffic is encrypted with AES-256-GCM using a PIN-derived session key. Hosts also enforce payload, connection, authentication-attempt, pending-approval, and message-rate limits. These controls complement rather than replace use of a trusted local network and host approval of every controller.

Hosting

1. Open sync controls from the header bar.
2. Choose Host Session.
3. Set a 4–6 digit numeric PIN. Blank or non-numeric PINs are rejected. A random 4-digit PIN is suggested; change it before sharing.
4. Note the displayed IP address and PIN. Share these with all controllers and command officers who need to connect.

Joining as a Dispatch controller

1. At startup choose Join Dispatch Session, or from within the dispatch screen open sync controls and choose Join Host.
2. Enter the host IP address, your display name, and the PIN.
3. Click Join and wait. The host must accept the connection before the event loads.

Joining as a Command officer

Command connects to a Dispatch host from the startup screen. Enter the officer name and role, then choose Connect to Dispatch. Enter the host IP address and the same session PIN used for Dispatch clients. The host must accept the connection in exactly the same way as a Dispatch join. Once accepted, Command loads the event state and records the officer sign-in.

Command and Dispatch share one sync session. The PIN is the same for both. The host does not distinguish between Dispatch and Command connections at the network level — it approves or rejects them all from the pending-client list.

Host controls

The host can accept or reject pending clients, kick connected clients, update the PIN, stop hosting, and broadcast current state.

When another connected controller is editing a call or unit, the affected item shows an editing indicator. The indicator is informational: it helps operators avoid stepping on each other's work, but it does not lock the item.

Auto-reconnect

If a client loses the connection due to a network interruption, it automatically retries with exponential backoff starting at 3 seconds and capping at 60 seconds. The client shows a Disconnected badge while retrying. When the connection is restored, the host must accept the client again from the pending-client list. State is resynchronised from the host at that point.

If the host machine restarts mid-event, all clients will show Disconnected and keep retrying. To restore the session:

1. On the host machine, restart EventMED Dispatch and open the event.
2. Start hosting again from the sync controls using the same or a new PIN.
3. Share the (new) PIN with all controllers and command officers.
4. Each client will need to re-enter the PIN and wait to be accepted.

There is no automatic re-acceptance after a host restart. Each controller must be individually approved. Keep a written record of who should be connected at events of significant scale.

Security

All traffic after the initial connection handshake is encrypted with AES-256-GCM. The session key is derived from the PIN using PBKDF2 (210,000 iterations, SHA-256) with a fresh random nonce generated per connection. An eavesdropper on the network cannot read event data without knowing the PIN. Older client versions using 10,000-iteration keys are still accepted for compatibility.

19. Command Module

The Command Module provides a duty-officer view for operational oversight, decisions, objectives, communications, handover, situation reporting, and governance records. It is available with Organisation and Enterprise licences, and during an active trial.

Session types and ownership

For a connected session, Command shows explicit Connecting, Waiting for Dispatch approval, and final loading/sign-in states. Cancelling or retrying leaves the incomplete connection cleanly. Command opens only after host authentication, approval, initial event state, and the officer sign-in action have succeeded.

Event-linked Command activity can continue when Dispatch has locked or completed the event, allowing the duty officer to maintain the command record through operational close-down. Dispatch-owned resources and calls remain subject to their normal ownership and lock rules.

Command layout

• Top bar: return to Dispatch or end a standalone session, event/session identity, call and resource indicators, duty officer, Handover, zoom, theme, and clock with date below it.
• Search: searches decisions, objectives, communications, SITREPs, and event-log records from one field.
• Overview: operational alerts, call and unit summaries, active objectives, recent decisions, and key times. Alerts identify unassigned critical calls, major-incident state, missing or overdue SITREPs, draft SITREPs, decision review triggers, and lost Dispatch sync. The SITREP reminder interval is configurable.
• Command Log: a unified chronological view of Command records and, for event-linked sessions, the Dispatch event log.
• Decisions: records the decision type, decision, rationale, reference, assigned actions, who was informed, review schedule, officer, timestamp, lifecycle status, and outcome. Reviews can be set for a specific date and time, after a standard interval, on a selected or custom operational trigger, or omitted. Scheduled reviews appear in Operational Alerts and are highlighted when overdue. New decisions can be Open or Active. Use Update to close or cancel a decision and record its outcome. Use Supersede to preserve an earlier decision while linking its replacement; the earlier record is automatically marked Superseded.
• Objectives: ordered operational objectives with Active, Achieved, or Cancelled state and completion attribution.
• Comms: contacts and communications recorded with method, content, officer, and time.
• SITREPs: versioned Draft or Final situation reports with recipient, notes, template, and a frozen snapshot of the event state.
• Reports: every Command session provides the Command Log, Decision and Objective Register, Communications Log, and Handover Brief. Event-linked Command also provides the Current Situation Brief, Operational Summary, Patient Reporting, and a formal End of Event Command Report. Its closeout workspace stores learning, issues, assigned actions, preparer, reviewer, and distribution, and warns about outstanding operational records. After event completion, Finalise New Version creates an immutable, audited report snapshot with a SHA-256 content digest; later changes create another version instead of overwriting history. Final versions remain available for export and are included in event backups. CSV and JSON structured exports are available in both modes.
• Resources: read-only unit status and crew list. A unit's current call is shown as the call reference and location; click it to open the full call preview and response-time breakdown.
• Event Log, Tasks, and M/ETHANE: read-only or controlled views of Dispatch-owned operational data where applicable.
• Quick Actions rail: Log Decision, Log Communication, Generate SITREP, Set Operational Status, and Start Handover, plus connection state, current service posture, last-record time, and active objectives. Status is persisted as Normal, Busy, Stretched, Saturated, Escalated, Recovery, or Stand Down and recorded in the event log and audit trail.

What is recorded and where

Command records are stored in the main event database alongside all Dispatch data. The table below shows where each type of record is held and who can read it.

Decisions, objectives, communications, and SITREPs are not visible to Dispatch operators in the event log panel. They are fully stored in the database and verifiable in the audit chain, but access is through the Command module only. Operational status changes and officer sign-in, sign-out, and handover events cross into the shared event log and are visible to both Dispatch and Command.

All Command records are included in event exports (.emdevt) and full database backups (.emdbak).

Officer sign-in and handover

Opening event-linked Command signs in the officer entered on the startup screen. Sign-in, sign-out, and handover are written to the event log, replay stream, and audit chain, so they appear in Dispatch and the unified Command Log.

Use Handover when responsibility changes. Record the incoming officer and role, review or edit the situation, outstanding objectives, and actions required, then confirm acceptance. The handover creates a governance decision and updates the duty officer; it does not create a second unrelated Command session.

Standalone session start, reopen, handover, and end are retained in the portable Command record because no Dispatch event log exists. End one standalone session before starting a distinct operation unless the records are intentionally part of the same command period.

SITREPs and patient reporting

Generating a SITREP captures the current state at that moment. Later changes to the event do not rewrite an earlier SITREP. The snapshot includes calls by priority and open/closed state, close outcomes, resource state, active objectives, active decisions, escalations, recent decisions, major-incident state, and aggregate patient-reporting completeness, categories, age ranges, and outcomes.

Command patient reporting is intentionally aggregate and call-level. Individual PRF numbers are not placed in Command SITREP or Current Situation summaries. Use the internal Patient Reporting report or authorised structured export when call-level PRF detail is required. Do not interpret call totals as a count of individual patients.

Ending, reopening, and attaching standalone sessions

Choose End Session to close a standalone command period. Ended sessions remain available from Command startup and can be reopened with their complete record. Use Export and Import Session to move the portable session record between installations. Use Attach from the standalone session list to associate a portable session with a local event when required; the attachment is audit-tracked. Attachment moves the records into the event permanently and removes the session from the standalone resume list so two editable copies cannot diverge.

Event-linked Command uses ← Dispatch to return to Dispatch and records the officer sign-out. The startup Command workspace remembers the last selected event and offers one-click continuation for an active standalone session.

20. Running a Live Event with Dispatch and Command

This section describes the end-to-end workflow for a coordinated deployment where one or more Dispatch controllers and one or more Command officers are operating together on the same event.

Roles

All writes from clients and Command officers are routed to the host for validation. Clients and Command cannot write to the event independently.

Pre-event setup

1. On the host machine: open EventMED Dispatch, enter the controller name, and create the event. Apply a scenario template in the Scenario panel if one is prepared. Load the unit roster via CSV import or sign on units manually.
2. Start hosting: open sync controls in the header, choose Host Session, set a PIN, and note the IP address shown. Confirm that the PIN and IP are accessible to other operators (written on a board or shared by radio or message).
3. Connect Dispatch clients: on each additional Dispatch terminal, choose Join Dispatch Session at startup, enter the host IP and PIN, and wait. The host accepts each connection from the pending-client list in the sync panel.
4. Connect Command: on the Command terminal, choose the Command workspace, enter the officer name and role, then choose Connect to Dispatch. Enter the host IP and the same PIN. The host accepts the Command officer from the same pending-client list.
5. Verify: once all connections are accepted, each terminal should show the event name, calls, and units from the host. The host sync panel shows the names of all connected peers.

Live operational workflow

Dispatch host and clients:

• Raise calls from any connected Dispatch terminal. Calls appear on all other Dispatch screens within seconds of the host processing them.
• Dispatch units by right-clicking or dragging from any terminal. The host validates the assignment and broadcasts the updated call card to all terminals.
• Update unit statuses (On Scene, Left Scene, Arrived, Clear) from whichever terminal is most convenient.
• If two controllers simultaneously dispatch the same unit to different calls, both actions are processed and both will succeed. Check unit assignments if a unit appears on two call cards — clear it from whichever call is incorrect.
• The host operator can broadcast current state manually from sync controls if any terminal appears out of step.

Command officer:

• The Overview panel shows active calls, unit summary, active objectives, recent decisions, and operational alerts. Use it to stay situationally aware without interfering with the Dispatch workflow.
• Use Log Decision (Quick Actions or Alt+D) whenever a material command decision is made. Choose the decision type, record the rationale, set a review schedule if required, and save. The decision is immediately stored on the host.
• Update Objectives as the operation develops. Mark objectives Achieved or Cancelled as they are resolved.
• Record significant Communications in the Comms section — incoming notifications, briefings given, and agency contacts.
• Generate a SITREP at regular intervals or before briefings. A SITREP captures a frozen snapshot of the current event state; it is not affected by subsequent changes.
• Set Operational Status from the Quick Actions rail when the service posture changes. Status changes (Normal, Busy, Stretched, Saturated, Escalated, Recovery, Stand Down) appear in the Dispatch event log as well as the audit trail.
• Use Handover when a new officer assumes the Command role. The incoming officer is recorded, the outgoing officer is signed out, and a governance decision is created automatically.

Dispatch can see from Command:

• Operational status changes appear in the event log.
• Officer sign-in, sign-out, and handover appear in the event log.

Command can see from Dispatch:

• All calls and units (read-only in Resources).
• The full event log.
• Tasks and M/ETHANE records (read-only).

Closing down

1. Command: finalise any remaining SITREPs and mark draft records as Final. Generate the End of Event Command Report from the Reports section. Use Finalise New Version to create the immutable, audited report snapshot.
2. Dispatch: sign off any remaining units. Ensure all calls are closed or resolved. Use Complete Event in event details. The completion workflow confirms open calls and outstanding tasks, asks for final notes, and requires a closeout backup.
3. Command: after event completion, the End of Event Command Report can still be finalised and exported if it was not completed before the Dispatch closeout.
4. Backup: use Tools → Backup on the host to save a full .emdbak file. This backup includes all Dispatch data and all Command records — decisions, objectives, communications, SITREPs, and the final report.
5. Stop hosting: the host can stop the sync session from sync controls. All connected clients will show Disconnected. They can be closed safely at this point.

If the host machine becomes unavailable

If the host crashes or loses power mid-event:

1. Clients show Disconnected and keep retrying automatically.
2. Restart EventMED Dispatch on the host machine (or on a standby machine that has a recent backup loaded).
3. If using the original host machine: open the event and start hosting again. The database is preserved.
4. If using a standby machine with a backup: restore the backup using Tools → Restore, open the event, and start hosting.
5. Share the IP (and new PIN if it changed) with all controllers and Command.
6. Each client must re-enter the PIN and be accepted by the host. There is no automatic re-acceptance.
7. Clients will receive the full current event state from the host on reconnection.

If no recent host backup is available: any connected sync client will have auto-saved a .emdevt snapshot to the auto-backup folder within the last 10 minutes (see Sync client snapshot). Use Tools → Import Event on the standby machine to load the most recent client snapshot, then start hosting from that event. Some data entered in the gap between the snapshot and the outage will need to be re-entered.

Maintain a documented procedure for which machine acts as standby host and where the most recent backup is stored. The auto-backup feature (Tools → About → Auto-Backup Settings) can keep a rolling set of recent backups on a network share or USB drive. Setting a short auto-backup interval (15 or 30 minutes) reduces the maximum data loss window significantly.

21. Backups and Restore

Manual backup

Use Tools → Backup on the startup screen to save the full database as a .emdbak file. Full backups include events, calls, units, tasks, Command records and final reports, unattached standalone Command sessions, controller profiles, configuration, scenarios, and maps.

Restore

Use Tools → Restore to load a .emdbak file. Full restore replaces all current data and requires confirmation.

Single-event archives

Use event manage mode to export a single event as .emdevt. Use Tools → Import Event at startup to load an .emdevt event archive.

Restoring individual events

Use Tools → Restore on the startup screen and choose Select events from backup to open a backup file and pick which events to import. Selected database records are imported as one transaction; if any selected event is invalid, none of them is added. Existing data is not affected. This is useful for recovering a deleted event or pulling historical records from an older backup without overwriting the current database.

Auto-backup

Open About, expand Auto-Backup Settings, choose a folder, set an interval, and enable scheduled backup. Auto-backups are saved as .emdbak files and the app keeps the 10 most recent. Run Now performs an immediate backup.

Available intervals are 15 minutes, 30 minutes, 1 hour, 2 hours, 4 hours, 6 hours, 8 hours, 12 hours, and 24 hours. For live events where continuity is critical, 15 or 30 minutes is recommended. Client snapshots (see Sync client snapshot) are also saved to this folder automatically and provide an additional recovery point between host backups.

22. Audit Trail

The audit chain is tamper-evident: each audit entry includes a hash linked to the previous entry. If event records are altered outside the app, verification can fail.

• Click the audit badge in the header to view and verify the current event audit log.
• Use startup Tools → Audits to browse audit logs across events.
• Export audit entries as HTML or JSONL where needed.
• The current event audit chain is checked automatically during use.

The Verify Now button in the audit modal runs a full integrity check on demand. While verifying, the status shows VERIFYING… and the button is disabled. Once complete, the result and a Last checked timestamp are displayed.

23. Settings, Updates, and Legal Text

• Theme: toggle dark/light mode from the header.
• Zoom: scale the Dispatch, Command, or Replay workspace from 50% to 200% using the + / − buttons in the header. The startup event picker stays at normal size so saved operational zoom does not make the launch screen oversized. The zoom preference is saved and restored for operational screens.
• Audio: mute or unmute alert sounds using the 🔔/🔇 button in the header. The preference is saved across sessions.
• Controller: set on startup or swap from the header mid-event.
• Updates: About can check for updates, download them, then restart/install. Updates are user-initiated.
• Privacy: operational data remains on devices controlled by your organisation unless you enable direct LAN sync. Update checks contact GitHub but do not send event or patient data. Portable backups, exports, reports, audit files, and map images are not encrypted by the application and must be stored securely.
• Logs: About can open the app log folder.
• EULA and Privacy: available from About.

24. Keyboard Shortcuts

Press ? from the main dispatch screen to open the in-app keyboard shortcut help overlay.

25. Troubleshooting

26. Glossary