B201 Features - Description v1.1 - Western Cape · Dr. Krish Vallabhjee Chief Director EMS - Provincial Government of the Western Cape (Sponsor) Dr. Cleeve Robertson Director –

Document: B201 Features - Description v1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 1 of 56

B201

B201 Features Description

Application Function Model

Provincial Government of the Western Cape (PGWC) Medical Emergency Transport and Rescue Organisation (METRO) Emergency Medical Services (EMS)

METRO EMS Confidential


B201

Document History

Revision History

Revision Number

Revision Date

Summary of Changes Changes marked

1.0 2009-12-03

Final version for sign off No

Approvals

This document requires following approvals. Name Title Dr. Cleeve Robertson Director – Emergency Medical Services

Distribution

This is the intended distribution list for this document: Name Title Dr. Krish Vallabhjee Chief Director EMS - Provincial Government of the Western Cape

(Sponsor) Dr. Cleeve Robertson Director – Emergency Medical Services Dr Shaheem de Vries Deputy Director - Emergency Medical Services Johan Schoombee Project Manager – Emergency Medical Services Dr Paul von Zeuner Information Management - Provincial Government of the Western CapeSteve Hurwitz Centre of e-Innovation - Provincial Government of the Western Cape Dr Alan MacMahon Deputy Director - HealthNET A printed copy and soft copy on CD media will be handed to Dr Shaheem de Vries for further distribution within EMS and PGWC.


B201

Contents 1. Introduction........................................................................................................................... 5

1.1 Identification...................................................................................................................... 5 1.2 Document Context ............................................................................................................. 5 1.3 Document Description....................................................................................................... 5 1.4 Purpose .............................................................................................................................. 6 1.5 References.......................................................................................................................... 6

2. Operational Context .............................................................................................................. 7 3. Function Group Overview .................................................................................................... 8 4. Resource Management.......................................................................................................... 9

4.1 Demand Forecasting .......................................................................................................... 9 4.1.1 Ability to Access Historical Event Information.......................................................... 9 4.1.2 Access to Historical Information from Other Emergency Services............................ 9 4.1.3 Scheduled Events ........................................................................................................ 9 4.1.4 Route Planning.......................................................................................................... 10

4.2 Scheduling ....................................................................................................................... 10 4.2.1 Ambulance and Ambulance Crews........................................................................... 10 4.2.2 Transportation Fleet and Transport Drivers.............................................................. 11 4.2.3 Specialised Medical Equipment................................................................................ 12 4.2.4 Consumables ............................................................................................................. 12 4.2.5 Other Forms of Transport ......................................................................................... 13

4.3 Operational Readiness ..................................................................................................... 13 4.3.1 Shifts Assignment and Sign On ................................................................................ 13 4.3.2 Monitoring ................................................................................................................ 13 4.3.3 Specialised Medical Equipment Assignment............................................................ 14 4.3.4 Consumables Assignment ......................................................................................... 14

5. Control Centre Management............................................................................................... 15 5.1 General Features .............................................................................................................. 15

5.1.1 Sign On ..................................................................................................................... 15 5.1.2 Remote Sign On........................................................................................................ 15 5.1.3 Rules ......................................................................................................................... 16 5.1.4 Control and Replication ............................................................................................ 16 5.1.5 Recording of Event ................................................................................................... 17 5.1.6 Visualisation of Information ..................................................................................... 17 5.1.7 Escalation Facilities .................................................................................................. 17 5.1.8 Teleconferencing Facilities ....................................................................................... 17 5.1.9 Mobile Data Terminals for Drivers........................................................................... 17 5.1.10 Mobile Data Terminals for Emergency Care Practitioners....................................... 18 5.1.11 Management Operation Platform.............................................................................. 18 5.1.12 Media Alerts.............................................................................................................. 18 5.1.13 Dashboards................................................................................................................ 18 5.1.14 Reporting................................................................................................................... 18 5.1.15 Voice and Text Communication ............................................................................... 18


B201

5.1.16 Electronic Messaging................................................................................................ 19 5.1.17 Inter Control Centre Communication ....................................................................... 19

5.2 Client Communication..................................................................................................... 19 5.2.1 Client Registration .................................................................................................... 19 5.2.2 Incoming Calls .......................................................................................................... 20 5.2.3 Advance Transport Booking ..................................................................................... 23 5.2.4 Outgoing Calls .......................................................................................................... 25 5.2.5 Call Load Balancing.................................................................................................. 26

5.3 Directing Emergency Resources...................................................................................... 27 5.3.1 Visualisation of Information ..................................................................................... 27 5.3.2 Priorities and Statuses ............................................................................................... 28 5.3.3 Dispatching ............................................................................................................... 31 5.3.4 On Board Communication ........................................................................................ 33 5.3.5 Traffic Light Pre-emption ......................................................................................... 35

5.4 Directing Non-Emergency Resources ............................................................................. 35 5.4.1 Scheduled and Adhoc Transport ............................................................................... 35

5.5 Incident Command and Control ...................................................................................... 37 5.5.1 Visualisation of Information ..................................................................................... 37 5.5.2 Raising Exception Alerts .......................................................................................... 39 5.5.3 Transfer of Control.................................................................................................... 40 5.5.4 Emergency Communication...................................................................................... 40 5.5.5 Record the Incident Timeline.................................................................................... 41 5.5.6 Protocols ................................................................................................................... 42

5.6 Healthcare Facilities Interaction ...................................................................................... 42 5.6.1 Capacity and Status................................................................................................... 43 5.6.2 Emergency Information ............................................................................................ 43 5.6.3 Patient Information ................................................................................................... 44


B201

1. Introduction This chapter identifies the document and the business to which it relates, describes the contents of the document, and states its purpose.

1.1 Identification

This document describes the solution Features required to enable the Emergency Medical Services (EMS) “To-Be” operational process [1]. It is presented as an Application Function Model following the Enterprise Architectural method. This Project is a Requirements Specification Phase for Provincial Government of the Western Cape (PGWC) METRO EMS in preparation for a Tender for Services.

1.2 Document Context

Stakeholders and Roles (A101)

Organisational Structure (A102)

Information Requirements (B301)

Business Architecture

“To Be” Processes (A104)

Application Architecture Information Architecture

Solution Architecture Overview (B401)

Technical Architecture

Application Features (B201)

Non-Functional Requirements (B202)

Requirements Specification

1.3 Document Description

The Application Function Model is the "Application" component of the Enterprise Architecture. An AFM identifies and defines the major groups of business function, derived from the business processes, which are required in order for the enterprise to meet its business objectives. It identifies the natural boundaries and partitioning of these business functions, and shows how these different partitions, or groups, relate to each other. As such, the model of business functions represents the optimal set of application functions, applications (or application groups) required to support the enterprise.


B201

However this document applies the same principles by expressing the Features within of groups and sub-groups of business function, derived from the business processes. The set of business function groups in an Application Function Model are optimal in that they display the following characteristics:

- The business functions contained within a group are closely related. - The scope and boundaries of each of the groups is clearly defined and do not overlap. - Specific features are supported by a single group and where they are needed by other business

function groups or sub-groups this is clearly indicated. This AFM was developed by identifying the Enablers to the EMS Services and Operational Process (see Operational Context). The Features of those Enablers were identified. Thereafter the business function groups that are needed to support the operational objectives of the METRO EMS Services were identified. These business functions are needed to support the EMS “To-Be” operational processes [1]. All these inputs were used to develop the function group diagram (see Function Group Overview). This was done via workshops with experienced personnel. It was also referred to a Subject Matter Experts for input and their feedback was considered. There after this were reviewed by the approver before being signed off.

1.4 Purpose

This Features document based on Application Function Model principles is used: - To make sure that the future applications and systems provide for the features that are aligned with

the business function groups that have been derived from the operational processes. - To provide a framework against which the features of the applications can be mapped - this will

highlight certain strengths and weaknesses in these applications and will govern their evolution. - To define and develop reusable "components" and promote the enterprise-wide sharing of

processes - by describing the major groupings of business function. - As a basis for partitioning business function - this helps the development team deal with the

complexity of the EMS services, whilst maintaining a single, comprehensive view.

1.5 References

This document is based on and refers to the following documents: [1] A104 To-Be Process v1.1 [2] B401 Solution Architecture Overview v1.1 [3] B301 Information Requirements v1.1 These are found in the same document location as this document.


B201

2. Operational Context The diagram [2] here below illustrates the operational context that has determined the Features that are required for METRO EMS to provide their services.

Non-EmergencyPatient Transport

Patient Emergencies

Bu

sin

ess

Ser

vice

s D

imen

sio

nOperational Process Dimension

Incident Management

COMMUNICATION

INFORMATION

LOGISTICS

SCHEDULING

AUTHORITY

Emergency

Patient

Handling

Incident

HandlingCall

Handling

Resource

Tracking

Non-Emergency

Patient

HandlingResource

Scheduling

En

ablers D

imen

sion

EMS operates in what can be described in three dimensions: Business Services METRO EMS direct and control services from emergency control centres both at Tygerberg and the District emergency control centres of Moorreesburg, Beaufort West, Bredasdorp, George and Worcester. Their operations are designed to react to four types of demand on the EMS services, namely:

Incident management, which is normally handled by the METRO Control desk; Patient emergencies; and Non-emergency transport of patients (including HealthNET pre-booked medical transport

services). Operational Process The operational processes have been described in the “To-Be” process description document [1]. Business and Operational Enablers The Features described in this document were discovered through discussion around the business and process enablers of communication; information; logistics; scheduling and authority. These were categorised and thereafter grouped into business function groups and sub-groups. The features were then prioritised, Annexure A, where priority level 1 is the highest priority, priority level 2 is a high priority, priority level 3 is a low priority, and priority level 4 is the lowest priority.


B201

3. Function Group Overview The diagram [3] here below illustrates the METRO EMS business functional groups and sub-groups. The features required to enable these functions are described in this document. The features have also been prioritised (see Annexure A).These function groups and features should be read in the context of the Operational Processes [1]. In Annexure B there is a “Storyline” that describes one possible outcome when following the Operational Process and how this is enabled by the features described in this document.

The functions have been separated into two main groups: Resource Management This has to do with the functions performed by EMS Operations in scheduling and providing operationally ready resources to be used in fulfilling the METRO EMS services. These resources are a combination of Transport, Personnel and Equipment. Control Centre Management This has to do with the core METRO EMS processes to provide for the various services through command and control from the emergency control centres. The functional groups of Client Communications, Incident Command and Control, Directing Emergency and Non-Emergency Resources have many common functions namely: historical information; internal messaging; visualisation of information; communication; escalation through rule based exception reporting; access security; location tracking and access to standard operation procedures and protocols. There is also a need for interaction with healthcare facilities to know the status and capacity of their services and share emergency and patient information. Both of these main function groups are supported by Information Management [3] and Technology [2].


B201

4. Resource Management Resource management is an important component which assists the Emergency Medical Services control centre with its daily operational activities. This function occurs repeatedly in parallel with the control centre functions. The Resource management functions can be categorized as follows:

Demand Forecasting Scheduling Operational Readiness

Each function and its feature requirements are described further in this section.

4.1 Demand Forecasting

For the control centre to perform their daily operational activities efficiently, the resources they require needs to be scheduled accordingly. The features to perform this function are explained here.

4.1.1 Ability to Access Historical Event Information

Historical events information needs to be available for trend analysis. The outcome of the trend analysis will assist the resource management team to forecast on what will be the demand for EMS services in the metropole and the districts during a given period of time. Historical events information needs to be available at different level such as per control centre, per region, per street etc and for different type of events.

4.1.2 Access to Historical Information from Other Emergency Services

Historical information from other emergency services also needs to be available to add to the information compiled by EMS. The information will augment the trend analysis outcome and will assist the resource management team to provide more accurate demand forecast.

4.1.3 Scheduled Events

The resource management team needs to be aware of scheduled events such as the 2010 FIFA world cup and the Argus Cycling tour. The magnitude and type of scheduled events will assist the resource management team to determine forecasting parameters such as what type of resources will be required, positioning of the resources, time span for which the resources will be required. This feature is also supported by the ability to access historical event information (See 4.1.1) whereby if the scheduled events are for instance yearly events, historical information about the event will be available


B201

4.1.4 Route Planning

The resource management team needs to prepare the advanced booking route plans based on historical demand and treatment offered by healthcare facilities. The route plan needs to take into consideration the date and time of the treatment and the dates the medical practitioners are available for consultation. For instance dialysis patients need to be at healthcare facilities at a specific time. For advance bookings requiring long distance transport, the route plan needs to take into consideration the duration of the trip, the number of legs and if other transports are available for each leg. The route plan needs to be dynamic to accommodate last minute non-emergency requests when required.

4.2 Scheduling

Once demand for EMS resources has been forecasted, the resource management team needs to look at the supply of resources and do the resource scheduling. The scheduling function can be further broken down into sub groups below:

Ambulance and Ambulance Crews Transportation fleet and Transport Drivers Specialised Medical Equipment Consumables Other forms of Transport

4.2.1 Ambulance and Ambulance Crews

This sub group describes the features required to schedule ambulances and their crews. Explanatory Note: The priority of the features in this sub group is based on the requirements of the control centre and not on the fleet management and human resources management requirements.

4.2.1.1 Ambulances Availability

The resource management team needs to know the type of ambulances (ALS, BLS, ILS) and the number of ambulances. The team needs to be able to determine when an ambulance is due for maintenance and when it will be booked for maintenance. The dates and duration of the maintenance needs to be estimated so that the vehicle can be marked as unavailable on the transport plan. The fleet manager also needs to be able to determine if extra ambulances are required over a given period and needs to be able to check availability at other control centres and liaise with them for assistance.

4.2.1.2 Ambulance Crew Availability

The resource management team needs to be aware of the number of EMS practitioners and their availability. The resource management team needs to have access to each EMS practitioner’s leave plan for the year and the practitioner must be marked as unavailable during those days. The leave requests needs to be valid for a given period so that the practitioner has the flexibility to change his/her leave plan without too much disruption to the schedule. Also the schedule needs to be dynamic such that if a practitioner is not able to do a shift, there are stand by resources that can take its place.


B201

4.2.1.3 Ambulance Crew Skills

The resource management team needs to have access to the skills set of each practitioner so that they can determine if the skills set can match the demand. The resource management team needs to ensure that the practitioners maintain their certification and that training requirements are met. For scheduling purposes, the resource management team needs to check whether the practitioner is an ALS, ILS or BLS practitioner.

4.2.1.4 Scheduling Ambulance and Their Crews

Based on the fleet of ambulance available, the supply of practitioners and their skills, the resource management team needs to create a schedule to meet the forecasted demand. The schedule must match two practitioners to an ambulance based on their skills and availability. One practitioner will be driving and the other taking care of the patient. An initial schedule will be produced on a yearly basis and will be reviewed on demand. In the districts, due to limited number of ambulances the ratio of ambulance to practitioners needs to be managed so that practitioners do not sit too long without a vehicle.

4.2.1.5 Dynamic Scheduling

The shifts defined in the schedule needs to be dynamic so that they can easily be amended when required. When the resource management team prepares the initial schedule they need to specify the validity of the schedule for instance valid for a year. Subsequently quarterly, monthly, weekly and even daily schedules can be prepared from this initial schedule on demand. The shift leader needs to be able to access the schedule before the shift and s/he needs to be able to review and make changes if required.

4.2.1.6 Publishing and Distribution of the Schedules

The initial schedule needs to be published for all EMS employees to access. Remote accesses to the schedules also need to be available. The other schedules created from the initial schedule also need to be published thereafter as an amendment to the initial schedule. The EMS practitioners can use the published schedule to swap shifts among themselves if required with the resource management team approval.

4.2.2 Transportation Fleet and Transport Drivers

This sub group describes the features required to schedule transportation fleet and drivers for non-emergency event. Explanatory Note: The priority of the features in this sub group is based on the requirements of the control centre and not on the fleet management and human resources management requirements.

4.2.2.1 Transport Availability

The resource management team needs to know the type of transport and number of seats, stretchers and wheelchairs available. The team needs to be able to determine when a transport is due for maintenance and when it will be booked for maintenance. The dates and duration of the maintenance needs to be estimated so that the vehicle can be marked as unavailable on the transport plan.


B201

4.2.2.2 Transport Driver Availability

The resource management team needs to be aware of the number of drivers and their availability. The resource management team needs to have access to each transport drivers leave plan for the year and the driver must be marked as unavailable during those days. The leave requests needs to be valid for given period so that the driver has the flexibility to change his/her leave plan without too much disruption to the schedule.

4.2.2.3 Scheduling Transport and Their Drivers

Based on the transports available, the supply of drivers and the route plan, the schedule template will be created to meet the forecasted demand for advanced booking. Each slot on the schedule will be updated when an advanced booking request is received that matches the schedule. A completed schedule is published when all the slots are filled in.

4.2.3 Specialised Medical Equipment

The specialised medical equipment cannot be scheduled. At the beginning of a shift, it can be assigned to an ambulance but during the shift it can move to another ambulance if required. This sub group describes the feature required for specialised medical equipment. Explanatory Note: The priority of the feature in this sub group is based on the requirements of the control centre.

4.2.3.1 Tracking of Specialised Medical Equipment

The resource management team needs to know what specialised medical equipment is available to the control centre. Specialised medical equipment is not part of an ambulance; it is mobile and can be used by any ambulance for instance an incubator. The specialised equipment needs to be tracked by the control centre so that they know where it is at all times and can be assigned if required.

4.2.4 Consumables

This sub group describes the features required to schedule other consumables required in the ambulances. Explanatory Note: The priority of the features in this sub group is based on the requirements of the control centre.

4.2.4.1 Stock Control of Consumables

The resource management team needs to know what are the consumables required by the EMS practitioners in their day to day activities. The balance of consumables needs to be available so that the stock can be replenished when required.

4.2.4.2 Consumables On Board the Vehicles

The vehicles are stocked with a certain amount of consumables at the beginning of a shift. The stock of consumables needs to be available on the EMS practitioner’s MDT. Every time the consumable is used, the practitioner needs to update the stock accordingly.


B201

At the end of the shift, the stock of the consumables left in the vehicle is calculated by the MDT and a request for the balance required is sent to the control centre. The control centre is then able to use this request to prepare the new stock for the next shift.

4.2.5 Other Forms of Transport

This sub group describes the features required to schedule other forms of transport.

4.2.5.1 Other Forms of Transport Availability

The resource management team needs to know what other forms of transport is available to the control centre for instance cars, aircraft. The team needs to be able to determine when those transports are due for maintenance and when they are scheduled to be booked for maintenance. The dates and duration of the maintenance needs to be estimated so that the transports can be marked as unavailable on a schedule.

4.3 Operational Readiness

Once the schedules have been created and distributed, the Emergency Medical Services is ready to perform its day to day operations. The features for the operational readiness function are explained here.

4.3.1 Shifts Assignment and Sign On

Once the schedules have been prepared and published, the EMS employees need to be aware of their shifts and be available for those shifts. The EMS employee will need to sign on to indicate that they are ready for deployment. The sign on needs to be linked to the vehicle they are assigned to. Once all crew members assigned to a vehicle the status of the vehicle needs to indicate that it is ready for dispatch. All employees that are part of a crew or a squad need to sign on as an individual and not as crew or squad. For instance both the driver and the EMS practitioner need to sign on to indicate that the ambulance is ready for deployment. The names of the driver and the practitioner will then be associated to that vehicle. When they complete their shifts, the employees must sign off to indicate that they are off duty and another crew will sign on to vehicle. Staggered shifts changes will be used to ensure that some resources are still available. Even if the ambulance crew have not signed on yet and therefore not showing as available, they can still be contacted and dispatched via radio.

4.3.2 Monitoring

The supervisors and squad leaders need to monitor who has signed on for a shift. If an employee is not signed on for shift, they need to follow up with the employee. For instance it might be that the employee is late. If it is determined that the employee is not able to make the shift, the squad leader needs to identify another employee who can do the shift.


B201

4.3.3 Specialised Medical Equipment Assignment

Special medical equipment, for instance an incubator, will be assigned to a crew at the beginning of a shift and one of the EMS crew members need to acknowledge the receipt of this special medical equipment. The crew member will accept the special medical equipment on behalf of his/her crew but both crew members will be responsible for this equipment.

4.3.4 Consumables Assignment

The vehicles will be stocked with consumables at the beginning of a shift and one of the EMS crew members need to acknowledge the initial list of consumables provided. Any of the crew members can accept the supply of consumables on behalf of his/her crew but both crew members will be responsible for the consumables. The crew member will have to sign for some of the pharmaceutical products, for instance narcotics such as Opioid analgesics.


B201

5. Control Centre Management The Control Centre manages the core operational activities of the Emergency Medical Services. The operational process simplistically requires:

Taking and directing a call after determining the urgency and type of emergency Directing activities through dispatching and / or scheduling services Executing the service including the transport of patients to Health Facilities

The Control Centre management functions can be categorized as follows: General Features Client Communication Directing Emergency Resources Directing Non-Emergency Resources Incident Command and Control Healthcare Facilities Interaction

Each function and its feature requirements are described further in this section.

5.1 General Features

There are general features that are needed and that are common across all the function groups and support the features from the function sub groups. These features are explained here.

5.1.1 Sign On

Each EMS employee needs to have a sign on that identifies him/her uniquely. Their personal information and job role will be associated to that sign on. Multiple roles can be associated to their sign on. For instance biometric sign on can be used for call handlers and dispatchers. The EMS employee will be able to switch between roles by selecting from a drop down list of roles available for his/her sign on. Each role needs to be associated with a set of functionalities and security accesses to ensure that only certain functions can be performed when signed on using a given role. For instance, someone can be set up as a call handler and a dispatcher. When signed on as a call handler, the resource is able to capture call information but is only able to view the information about an event if required. S/he can advise a caller regarding a current event but cannot for instance dispatch additional resources to that event. But when signed on as a dispatcher, the resource is able to dispatch resources. It should be very easy to move between these roles or to define roles and the functionalities required for those roles, for example in the districts a single individual has a combined role as a call handler and dispatcher. Supervisors and the directorate will have more authority as they need to be able to access all the information regarding the control centres.

5.1.2 Remote Sign On

The EMS employee needs to be able to sign on remotely if required and authorised to do so.


B201

For instance, the supervisor needs to be able to sign on remotely to monitor the activities at the control centre. The supervisor needs to be able to perform his/her duties remotely for example dealing with escalation issues and liaising with the control centre personnel.

5.1.3 Rules

A set of rules is required for several of the features described. The rules need to be defined to determine prioritisation of a call, to differentiate between a priority 1 and a priority 2 for instance. The priority 1 for instance will be based on a list of cases types and incident types. When an event is assigned to a dispatcher, the rules need to be defined such that the system provides the call handler with the dispatcher zone best suited for this event. When calculating estimated response time for automated and manual dispatching, the rules need to be defined such that for instance the definition of available resources does not only include vehicles that are not allocated but also vehicles that are allocated to a lower priority event and can still be used. The rules need to be configurable such that they can be augmented with additional information if relevant to the outcome of the process they are defining. For instance when determining what resource to dispatch to an event, the initial rules might suggest the closest resource to the event, however there might be road closures or floods in the area causing the closest resource not being able to access the event and another resource needs to be used. In this case the rules need to be augmented for this event to include environmental conditions such that all parameters influencing the outcome of the decision making process are considered. The rules need to be defined to include monitoring and triggering of alerts. For instance if driver does not acknowledge dispatch within 10 seconds 3 times in a row, the supervisor needs to be alerted. The rules can also be augmented with statistical information such as average time an ALS ambulance takes from point A to a hospital.

5.1.4 Control and Replication

Some control centres needs to be able to take over the activities of other control centres. The functions and current activities of those control centre needs to be replicated to the other control centres. For instance, if one of the control centres in the district cannot operate due to a major disaster, the control centre in the metropole needs to be able to take over its current activities and functions. The information from that control centre needs to be replicated to the metropole control centre which will then continue with the district’s control centre operations. This feature is also supported by the sign on (See 5.1.1) and remote sign on (See 5.1.2) features whereby some of EMS employees need to be authorised to access other control centres information remotely in order to allow the take over of other control centres and the replication of the data by their control centres.


B201

5.1.5 Recording of Event

The actions of the call handler, the dispatcher and the dispatched resources needs to be recorded for an event and the recordings need to be available for replay for instance for analysis purposes each action is time stamped. For instance the information captured by the call handler needs to be recorded to ensure that the correct questions were asked and the answers given captured accordingly.

5.1.6 Visualisation of Information

The location of personnel, vehicles, events and healthcare facilities need to be available on a mapping system. The facility to drill down on the map to get further information needs to be available. Various format of maps need to be available for the visualisation of the information from road maps to satellite maps. For instance incidents can be visualised per geographical area where all East zone incidents are specified on a map. Visualisation is also required for management of delta incidents whereby a helicopter view of the positioning of all resources is important and needs to be monitored. Visualisation of that information will assist the commanders in taking strategic decisions.

5.1.7 Escalation Facilities

The EMS employee needs to be able to escalate an operational issue to the various levels of commands of the control centre. The call handler and the dispatcher need to be able to escalate the issues to their supervisor who in turn can escalate further if required. The supervisor needs to be prompted regularly about the escalated issues that she/he needs to take actions on.

5.1.8 Teleconferencing Facilities

The EMS employee needs to be able to use teleconferencing facilities if and when required. For example, the captain of a ship at sea might need to contact the control centre via a third party and an EMS resource such as a doctor also needs to be listening in. Also a supervisor might need to listen in while a call handler is busy on a difficult call and might need to intervene during the call. In the districts, the driver of the ambulance might need to liaise with the caller to clarify directions while the call handler is busy on the call.

5.1.9 Mobile Data Terminals for Drivers

The EMS vehicle driver needs to have access to portable devices such as a mobile data terminal (MDT) to liaise with the control centre. The mission critical MDT needs to be loaded with maps for navigation purposes and have a facility for the driver to communicate with the dispatcher via various status buttons. The protocols and SOPs also need to be available on the MDT.


B201

5.1.10 Mobile Data Terminals for Emergency Care Practitioners

The EMS emergency care practitioner needs to have access to portable devices such as a mobile data terminal (MDT) to liaise with the control centre. The client based MDT needs to interface with the control centre for data transfer. The emergency care practitioner needs to capture information about patients and incidents on the MDT and transfer the information to the control centre via the WAN. The protocols and SOPs also need to be available on the MDT.

5.1.11 Management Operation Platform

Information about the operations of a control centre needs to be available via a management operation platform. This feature is similar to a rule based exception management facility whereby information such as shifts, resources, escalated issues are available to management to take further action if required. The platform needs to be available on the MDTs for authorised mobile employees usually managers supervisors or commanders. This feature is supported by the remote sign on (See 5.1.2), visualisation of information (See 5.1.6), and escalation facilities (See 5.1.7) features whereby management have access to exception management information remotely and can escalate if required.

5.1.12 Media Alerts

Information about major incidents impacting the population of a region needs to be sent to the media via emails or SMS. The supervisor of a control centre needs to be able to have access to an advisory message template that can be used to distribute information about incidents to media agencies without them having to phone the control centre. The media agencies or other institutions interested in the information can register with the control centre to receive information and regular updates about an incident.

5.1.13 Dashboards

Information about events and patients need to be available in the form of dashboards. Several dashboards can be available depending on the role and security access of the employee. Call handler and dispatchers will have a different dashboard compared to supervisors for instance. Ability to drill down or view high level information needs to be available.

5.1.14 Reporting

Information about events, patients and resources need to be available for reporting and analysis purposes. EMS needs to be able to customise and/or create new reports. See Information Requirements [3]

5.1.15 Voice and Text Communication

Voice communication needs to be available for easy communication internally amongst EMS resources but also externally with callers, healthcare facilities and other 3rd parties. The facility to convert voice to text also needs to be available


B201

For instance, the call handler needs to be able to ‘point and click’ to communicate with a predefined list of 3rd parties. Internally, similar to an intercom facility, the call handlers, supervisors and dispatchers need to be able to contact each other. For instance the call handler might need to contact the supervisor regarding an escalated call and ‘point and click’ to call the supervisor. The call handler needs to be able to see if the supervisor is not available for a call and leave a voice message that can be converted to text if necessary. If the dispatcher requires additional information about an event, s/he can also use this facility to ask the call handler to contact the caller for more information.

5.1.16 Electronic Messaging

This facility enables the EMS resources to receive important notification from the organisation for instance in case of major incidents where all resources need to be mobilised. Another example is for advanced booking cancellations whereby if the transport of advanced booking clients is not able to transport the clients as scheduled due to the vehicle being out of order, the call handlers can be advised via electronic messaging and be able to send a bulk SMS to all those advanced bookings clients to notify them of the cancellation.

5.1.17 Inter Control Centre Communication

Control centres in the metropole and the districts need to be able to communicate with each other continuously.

5.2 Client Communication

One of the core operational processes managed by the Control Centre is the Call handling process [1] whereby a Call handler will be taking and directing calls after determining the urgency and type of emergency. The person or institution calling for assistance is defined as the client. The Client Communication function can be further broken down into sub groups below:

Client Registration Incoming Calls Advance Transport Bookings Outgoing Calls Call Load Balancing

The featured requirements for each of those sub groups will be explained here.

5.2.1 Client Registration

This sub group is a facility offered to potential and existing clients of EMS to register their information with EMS. EMS will therefore have a record of the client name, contact details and address. The information can be accessed when a client contacts the control centre.


B201

For example, clients using panic button alerts in their homes or in their vehicles can register, deaf clients can register to be able to send SMSes, and frequent users of EMS services such as advance booking users can register.

5.2.2 Incoming Calls

This sub group describes the features required to handle calls that are coming through to the Control Centre.

5.2.2.1 Call Logging

The telephone system used needs to be able to log information about the call that is coming through. The telephone system used needs to be able to colour code the calls for instance to indicate how long they have been in a queue, if they are call backs by the system etc. This feature is also supported by the ability to identify telephone number feature (See 5.2.2.2) below whereby the incoming telephone number can be populated in the log.

5.2.2.2 Ability to Identify Telephone Number

The telephone system used needs to display the Caller Line Identification (CLI) also known as Automatic Number Identification (ANI). The telephone number needs to be available to enable the telephone system to call back the number if the call is cancelled. This feature is also supported by the ability to identify telephone prefix feature (See 5.2.2.7) whereby the telephone system is able to redirect the call to the suitable call handler according to the area code. The telephone number is also used in the call log generated by the telephone system as per the call logging feature.

5.2.2.3 Ability to Receive SMS

The telephone system used needs to be able to receive Short Message Service (SMS). EMS needs to cater for the deaf population who are not able to call the EMS control centre via the Emergency contact numbers. The deaf callers can therefore send an SMS to the control centre about the event or the booking required and the control centre will send them an SMS back. This feature is also supported by the client registration feature (See 5.2.1) where the deaf caller is a registered client whose information is readily available.

5.2.2.4 Ability to Receive MMS

The telephone system used needs to be able to receive Multimedia Messaging Services (MMS). Callers also need to able to send richer information about the event to the control centres by means of MMS. This will provide more visual information about an event.

5.2.2.5 Ability to Receive Panic Button Alerts

The telephone system used needs to be able to receive alerts via Panic buttons. Emergency Panic buttons are installed in homes and in cars and they are linked to the control centre. If they are activated, the alert will come through to the control centre for further action. This feature is also supported by the client registration feature (See 5.2.1) where the owner of the panic button is a registered client whose information is readily available.


B201

5.2.2.6 Ability to Receive Fax to Email

The telephone system used needs to be able to receive faxes and convert them into an email. Some clients send advance booking requests via fax. The fax received needs to be integrated into the email system for the call handler to process. This feature is also supported by the client registration feature (See 5.2.1) where the person requesting the advanced booking is a registered client whose information is readily available.

5.2.2.7 Ability to Identify Telephone Prefix

The telephone system used needs to be able to identify the telephone prefix of the telephone number that is coming through. The control centre has various call handlers with different skill sets. In some cases, a call might come to a call handler that does not speak the caller’s language fluently causing delay in determining the emergency and loss of essential information in some cases. The control centre will group their call handlers according to their language skills. In many areas of South Africa, the majority of the population in that specific area will be speaking their preferred language. The telephone prefix for that area can therefore be used as a factor to determine where to logically redirect a call. For instance, if the telephone prefix of area A indicates that the majority of its population speaks Xhosa, it is logical to redirect the call to the Xhosa speaking call handlers to ensure the call is handled accordingly. The call can be redirected again once answered if the call handler that received the call needs assistance from another call handler.

5.2.2.8 Ability to Differentiate Between Calls

In the districts, the control centre also serves as a call centre for other emergency services such as the fire department and disaster management. The control centre in the district will contact the other emergency services institutions if their services are required and will follow up the call until it is closed. The control centre needs to be able to distinguish between the calls intended for the EMS services and those received on behalf of other emergency call centres. Also for calls that come through to the control centre via other institutions such as 112, the information obtained from these institutions needs to be handed over to the EMS control centre.

5.2.2.9 Automated Call Back

This feature is supported by the ability to identify telephone number feature (See 5.2.2.2) whereby if a call is dropped, the telephone system is able to automatically call it back if required using the CLI.

5.2.2.10 Voice Recording

The telephone system needs to have recording capabilities so that the incoming calls can be recorded. The voice recording needs to be available in online storage for a given period of time and the call handler or dispatcher needs to be able to replay the recording quickly if required. Once the recording has been archived, it is acceptable to replay it from the offline storage at reduced response time.

5.2.2.11 Simplified Call Taking Screen

The call handler needs to use a simple and complete call taking screen to capture the information provided by the caller easily and timeously.


B201

The fields displayed should have a logical flow with minimal free text fields available for capturing the information. For instance, pre populated drop down fields or predictive text for case types and incident types can be available and additional fields will be populated on the screen depending on the selection. Also it should be possible for the system administrator to change the interface by adding, adjusting or repositioning the fields available to improve the flow of information captured if required.

5.2.2.12 Call Reference Number

Each call received needs to be assigned a unique reference number. The call handler needs to ask the caller if they would like to have the reference number in case they need to call back about the event. The reference needs to be linked to the event information.

5.2.2.13 Ability to Access Historical Call Information

Historical call information needs to be available to identify if a call is a repeat call or a duplicate call about an existing event. If historical call information is available about an event, the call information needs to be linked to that event. For repeat calls, the caller might have additional information regarding the event for instance if the patient condition has worsened since the last call and this information needs to be passed on to the dispatcher. Repeat calls are when the same caller calls again usually to give updated information about the event or to request information e.g. “When will the ambulance be here?” The call handler needs to be able to access the historical information about the event and update it accordingly with the new information. The call handler needs to be able to provide information to the caller about an ongoing event if required. For instance based on his/her security access, the call handler needs to be able to access the information about the event and advise if the ambulance is on its way without having to liaise with the dispatcher. For a duplicate call, the caller might be reporting the same event but without additional information. The call handler will have a list of unfulfilled events and can reference those to identify if the call is a duplicate calls Calls can also be from frequent callers who regularly call for the same reason, e.g. a dialysis patient. The call handler needs to access historical call information to query previous actions taken. The caller’s telephone number will be used to provide available information related to that telephone number such as previous events linked to that number in reverse chronological order, previous reference numbers and caller information. This feature is also supported by the client registration feature (See 5.2.1) where the call handler is able to access historic information about a caller if s/he is a registered client.

5.2.2.14 Ability to Locate the Event

The call handler needs to have access to updated street maps and territorial maps so that s/he can confirm the GIS location of the event.

5.2.2.15 Access to Protocols and SOPs

The call handler needs to have access to protocols and SOPs, if there are some available, that relates to the information captured by the call handler about an event. Protocols can be medical protocols or incident protocols. The call handler can use the protocols to assist the caller if medical advice is required or to determine what further action to take.


B201

5.2.2.16 Call Prioritisation

The call needs to be prioritised accordingly based on the information captured by the call handler and information provided by the protocols. For instance once an event is established as a Priority 1, an EMS crew needs to be dispatched immediately.

5.2.2.17 Assign to Dispatcher by Zone

The dispatchers are grouped in zones and the event needs to be assigned to a dispatching zone and not to a specific dispatcher. For instance, the zones are defined as east and west despatch desk. If an event is in zone east, the system should be able to assign to the event to the east despatch desk.

5.2.2.18 Incoming Call Analysis

Statistics regarding the incoming calls, SMS, MMS, panic button alerts, fax to email messages need to be available for trend analysis purposes. Current call statuses also need to be available to evaluate the current situation of the control centre. This feature is supported by the Call Load balancing feature (See 5.2.5). For instance, the below information needs to be available

List of type of calls received during a given period of time to identify the highest call types received during that time. E.g.: medical advice calls, fire department calls, casualty calls

List of the number of calls received to identify the peaks and valleys are calls during a given period.

List of calls for a given zone or location to identify trends in that zone. List of calls received via telephone, SMS, MMS etc to identify the modes of communication used

by clients. List of incoming calls that are on hold, dropped, called back, activated so that supervisors can

monitor current activities in the control centre. List of calls by priority type per zone so that dispatch priority assigned to calls in a given zone can

be analysed.

5.2.3 Advance Transport Booking

This sub function describes the features required to handle advanced transport booking request that come through to the control centre.

5.2.3.1 Schedule and Routes Definition

A combination of routes needs to be defined for inbound and outbound transport of clients from the districts to the metropole healthcare facilities and vice versa and for clients within the metropole that need to access the healthcare facilities on a regular basis. A set of rules to determine the pick up and drop off times of the client as well as the healthcare facilities visited also need to be put in place. The combination of predefined routes and set of rules will enable the creation of a schedule template with slots that can be filled in when advanced booking requests are received.


B201

5.2.3.2 Online Booking

Advance online booking facility needs to be available and needs to be differentiated from telephone advanced bookings. The advance online bookings process will allocate the booking request received in the predefined available slots. The call handler also needs to be able to access the online booking system if an advanced booking is received via a telephone call. The call handler should be able to capture the booking in the advanced booking facility. Once available slots are filled in, an allocated schedule is generated for the dispatchers to dispatch accordingly. If there are no more available slots for the parameters required, the booking needs to be allocated to the next available slot for the same parameters but for a different date. This feature is also supported by the ability to access historical client information feature (See 5.2.3.4) where the client historic information is available if s/he is a registered client.

5.2.3.3 Simplified Call Taking Screen

The advance online booking facility screen needs to be simple and complete so that the call handler and the healthcare facilities employee can easily and timeously capture the information provided by the client. The fields displayed should have a logical flow with some predefined information in the form of drop down lists so that minimum information is manually captured. For instance, pick up and drop off times available, healthcare facilities visited, doctor visited can be available as drop downs. This feature is also supported by the ability to access historical client information feature (See 5.2.3.4) whereby the information of the client is available if it is a registered client, and the call handler or the healthcare facilities do not have to capture the information again.

5.2.3.4 Ability to Access Historical Client Information

Historical client information needs to be available when a request for advance booking transport is received in order to identify the client and populate the client information such as the name, address, treatment usually requested and contact details in the system.

5.2.3.5 Ability to Send SMS

Clients that have booked advance transport need to receive bulk SMS confirmation once their booking has been allocated and a reference number generated.

5.2.3.6 Online Advanced Booking Log

The advanced booking requests and allocation needs to be logged. The log should contain information such as request received date and time, allocation processing date and time, EMS employee that captured the booking etc.

5.2.3.7 Advance Booking Analysis

The statistics for advanced booking needs to be available for trend analysis purposes. For instance, the below needs to be available:

List of type of adhoc scheduling captured during a given time period.


B201

List of the number of advanced bookings received for a given healthcare facility to analyse the demand.

5.2.4 Outgoing Calls

5.2.4.1 Dropped Calls

The telephone system used needs to be able to identify dropped calls and determine if the caller needs to be called back. The call back process needs to be rule based whereby the telephone system only calls back the dropped calls for a certain number of times if it is the same telephone number that is received. The telephone system used also needs to be able to colour code the call backs on the list of calls produced by the system as per call monitoring feature. This feature is also supported by the call logging feature (See 5.2.2.1) whereby call information such as caller telephone and status is available. It is also supported by the ability to identify telephone number feature (See 5.2.2.2) whereby the telephone system can use the telephone number received to call back the caller.

5.2.4.2 Ability to Contact Client Sending Panic Button Alerts

Registered client information need to be available when the panic button alerts are received. The call handler dealing with the panic button alert received needs to be able to use the registered client information to call back the client and establish the event. This feature is also supported by the client registration feature (See 5.2.1) where the owner of the panic button is a registered client whose information is readily available.

5.2.4.3 Ability to Contact Client Sending SMS

Registered client information needs to be available when SMS are received. The call handler needs to be able to use the registered client information to send an SMS back if s/he is a deaf client or to call back the client and establish the event. Due to the possibility of network congestion the SMS or the call might not be received by the caller. If it is a registered client other means of contacting the client needs to be available such as family member contact details. This feature is also supported by the client registration feature (See 5.2.1) where the deaf caller is a registered client whose information is readily available.

5.2.4.4 Ability to Call Back the Caller

The dispatcher might need additional information from the caller and the call handler needs to be able to access prior calls information to call back the caller. For instance, the call can be dropped while the call handler is liaising with the caller and the call handler needs to call back the caller based on the telephone number information received from the log. Also in cases where more information is required from a caller, for instance location verification, the call handler needs to be able to access a previous call and call back the caller to clarify the information received. This feature is also supported by the ability to identify telephone number feature (See 5.2.2.2) whereby the telephone system logs the initial telephone number from which the call was made.


B201

5.2.4.5 Voice Recording

The telephone system needs to have recording capabilities so that the outgoing calls can be recorded. The voice recording needs to be available in online storage for a given period of time and the call handler or dispatcher needs to be able to replay the recording quickly if required. Once the recording has been archived, it is acceptable to replay it from the offline storage at reduced response time.

5.2.5 Call Load Balancing

This sub function describes the features required for call load balancing when the control centre is receiving a high volume of calls.

5.2.5.1 Calls Monitoring

The telephone system used needs to be able to provide a list of all calls and their status, as well as the status of panic button alerts, fax to email requests, SMS and MMS alerts for call load monitoring. The telephone system used also needs to be able to colour code the calls and alerts received for instance to indicate which calls and alerts have been in the queue the longest or which ones are call backs by the system. For instance, the telephone system can also use the telephone prefix information to identify to which group the awaiting call will be logically transferred. The supervisor of the control centre uses this information to monitor the call load and identify peaks and valleys of calls. This feature is also supported by the call logging feature (See 5.2.2.1) whereby call information such as time received, caller telephone number, status and call handler information is available. It is also supported by the ability to identify telephone prefix feature (See 5.2.2.7) whereby the supervisor can see to which group the majority of awaiting calls will be transferred to.

5.2.5.2 Resource Monitoring

Lists of all call handlers in a shift and their status need to be available for resource monitoring. The list can provide for instance the call handler information, number of calls processed and if currently busy on a call. If the call handlers are grouped according to their languages skills, the system can for instance also provide a list of calls per group.

5.2.5.3 Ability to Escalate Service Level

Using the call monitoring and resource monitoring features, the supervisor of the control centre needs to be able to redistribute the call load accordingly if there is a high volume of incoming calls and alerts. Dynamic resource utilisation facility needs to be available whereby resource capacity during a shift can be increased or decreased if required by the supervisor.


B201

5.3 Directing Emergency Resources

The next main functional group that the Emergency Control Centre needs to perform is that of Directing Emergency Resources. This can be further broken down into the following sub groups:

Visualisation Of Information Priorities And Statuses Dispatching On Board Communication

The feature requirements for each of these sub groups are described here.


This sub group relates to the visualisation of information feature discussed in the general features section but with emphasis on geographical visualisation of resources, events and medical facilities for a given control centre.

5.3.1.1 Visualisation of Event

The dispatcher needs to be able to have a map which shows where the events are located based on the information provided during the call handling. Colour coded icons can be used to differentiate the type of events. For instance a red icon will indicate a priority1 event whilst a priority 2 can be indicated with a yellow icon. Uniquely shaped and colour coded icons should provide as much visual information as possible, for instance the status of the event. Hovering over the icon or further drill down should provide further information about the event. For registered clients, historical information can also be available when hovering on an event that relates to them.

5.3.1.2 Visualisation of Vehicles

The dispatcher needs to be able to see where the vehicles are located compared to the incidents especially if manual dispatch is required. Uniquely shaped and colour coded icons should provide as much visual information as possible. For instance to indicate closest appropriate vehicles and possibly also the vehicle type or whether the vehicle has additional equipment such as an incubator. Further information should be available by hovering over the vehicle and further drill down. Also hovering over the vehicle should show the estimated response time if the vehicle is assigned to an event. And if it has a patient(s) on board the estimated time of arrival at the destination health care facility. This feature is supported by the vehicle tracking feature (See 5.3.1.4) whereby the devices will indicate the positioning of the vehicle.

5.3.1.3 Personnel Tracking

The personnel using the vehicles also need to be tracked so they can be located when they are not in their vehicles. Real time tracking of personnel is required to ensure that the information viewed by the dispatcher is current for instance during mountain rescue operations.


B201

5.3.1.4 Vehicle Tracking

The vehicles need to be fitted with tracking devices so that they can be visible. Real time tracking of vehicles is required to ensure that the information viewed by the dispatcher is current. The vehicle tracking feature should also provide for the monitoring of additional relevant things such as driver behaviour and vehicle condition, i.e. speeding and fuel levels.

5.3.1.5 Special Medical Equipment Tracking

Real time tracking of additional special medical equipment such as an incubator is also required so that they can be visible by the dispatcher at all times.

5.3.1.6 Geo Fencing

Geo fencing needs to be available whereby a geo fence is created around a geographic area and the dispatchers are informed when EMS vehicles enter that area. For instance if a vehicle from the districts is coming into the metropole area for a drop off, the dispatchers can be alerted and use the transport to pick up an out patient that needs to go back to the districts.

5.3.1.7 Visualisation of Healthcare Facilities

The dispatcher needs to be able to have a geographical view of the healthcare facilities available within his/her zone. Uniquely shaped and colour coded icons should provide as much visual information as possible for instance closest appropriate facility. Hovering over the healthcare facilities and further drill down should provide additional information such as bed status.

5.3.1.8 Navigation Facilities

When the dispatcher dispatches a resource, s/he will provide the resource with the location of the event. The driver needs to have accessed a GPS Navigator to navigate to their destination. The GPS Navigator needs to be updated with traffic information and road closures information to ensure that alternative routes are offered to the driver.


The emergency care practitioner needs to have access to protocols and SOPs on the MDT. Protocols can be medical protocols or incident protocols. The emergency care practitioner uses the protocols and SOPs to perform its role. For instance when administrating medication to a patient and the practitioner needs to confirm dosage and side effects, a medical protocol can be used.

5.3.2 Priorities and Statuses

This sub group relates to the determination of event priority and resource status during an event.


B201


The event needs to be prioritised based on the information captured by the call handler. If it is a priority 1 it needs to be assigned immediately to a despatch zone before requesting any further information. Priority 1 event needs to be differentiated from a lower priority event using colour code features. The dispatcher can also be alerted in that way that a priority 1 event was assigned to him/her. Resources can be auto dispatched where appropriate else the dispatch will dispatch a resource.

5.3.2.2 Mobile Data Terminals for Drivers

The driver of the emergency vehicle needs to be equipped with portable devices such as a mobile data terminal (MDT) and will be notified via the MDT that they are being dispatched. They will need to acknowledge the dispatch. This should be easy for the driver to do, for example s/he should be able to press a button to indicate acknowledgement of the dispatch. From that acknowledgement the EMS resource status should change to allocated (see Resource Status feature).

5.3.2.3 Mobile Data Terminals for Emergency Care Practitioners

The practitioner attending to the patient needs to keep the patient’s condition updated and the medical supplies used during the caring of the patient should be recorded. The update will be done via the MDT. The MDT will interface with the equipment on board to record the patient‘s condition. Protocols and formularies will also be available on the MDT.

5.3.2.4 Resource Status

The driver of the vehicle dispatched needs to notify the dispatcher via the MDT of their status. The MDT needs to have a status facility whereby predefined statuses are loaded and the driver can select the appropriate status. Once selected its status is changed to “allocated”. For instance, when the driver gets to the event location s/he needs to be able to select ‘At A’ and the system will update their status as at the location. This feature is also supported by the geo fencing feature (See 5.3.1.6) whereby the position of the vehicle within the geo fence is available and therefore the dispatcher should be able to see the resource at the location also.

5.3.2.5 Equipment Status

A list of the medical supplies available on the vehicle at the start of a shift needs to be available on the MDT. During the shift, the practitioner will indicate on the list which medical supplies are used, the equipment on board will also update the MDT accordingly. Stock control will be done by the MDT at the end of the shift and a request sent to the control centre for medical supplies replacement for the new shift. The medical supplies need to be given to the crew at the beginning of the new shift. The MDT will be updated with the new list of medical supplies.

5.3.2.6 Situation Report

The practitioner caring for the patient needs to constantly update the dispatcher with a situation report. The practitioner needs to be able to use the MDT to provide information about the event and the patient.


B201

The patient will be monitored by the equipment on board the vehicle and those equipments will updated the MDT so that the information can be transferred to the control centre. For instance the equipment will update the patient’s vital signs on the MDT.

5.3.2.7 Unique Identification of the Patient

The Triage tag is a tag that needs to be given to the patient based on the status of the patient once initial assessment completed. The triage tag will use a unique id for instance in the form of a barcode or RFID to uniquely identify the patient. The practitioner will use the MDT to scan the unique id to register the patient against this id. The unique id is then linked to the event. The control centre is then updated with this information.

5.3.2.8 Acknowledgement of Assigned Event

The call handler will assign an event to a despatch desk and rule based event assignment balancing will then assign the event to a specific dispatcher. The dispatcher needs to acknowledge receipt of the assigned event and take ownership of that event. This feature is supported by rules feature (See 5.1.3) whereby the rules will determine to which dispatcher to assign the event.


Using the visualisation of event and resources feature, the supervisor of the control centre needs to be able to redistribute the dispatchers accordingly if there is a high volume of priority 1 in one zone compared to the other. Dynamic resource utilisation capabilities needs to be available whereby resource capacity during a shift can be increased or decreased if required. For instance, the supervisor should be able to move dispatchers into a different zone to handle the increase in priority 1 events if necessary or transfer the responsibility of an event to another dispatcher.

5.3.2.10 Ability to Hand-over Events

The dispatcher needs to be able to hand-over events for which they are responsible for to another dispatcher. For example, a dispatcher might complete his shift and need to pass on the information about current events to another dispatcher who is taking over from him/her. Also a dispatcher might need to dispatch a resource for priority 1 whilst the resource is on its way to a priority 2 event. In this case, the dispatcher needs to hand over the priority 1 event to the dispatcher that dispatched the priority 2 so that s/he can redirect the resource accordingly to the priority 1 event. This feature is supported by the acknowledgement of assigned event (See 5.3.2.8) whereby a specific dispatcher is responsible for an event and not the despatch desk.

5.3.2.11 Priorities and Status Analysis

Statistics needs to be available for event priorities, resources and equipment status for trend analysis purposes. Current event status also needs to be available to evaluate the situation of the control centre. For instance, the below information needs to be available

List of priority 1 event received during a given period of time in a zone. List of priority 2 event per hour per shift.


B201

List of all events for a given zone or location to identify trends in that zone.

5.3.3 Dispatching

This function sub group explains the features required for the manual and the automated dispatching process.


The event needs to be prioritised based on the information captured by the call handler. If it is a prioirty1 it needs to be assigned immediately to a despatch zone before requesting any further information. Priority 1 event needs to be differentiated from a lower priority event using colour code features. The dispatcher can also be alerted in that way that a priority 1 event was assigned to him/her. This feature is also supported by the rules feature (See 5.1.3) to ensure that all the required parameters are available when processing the outcome.

5.3.3.2 Automated Dispatching

For priority 1 event, the estimated response time needs to be calculated using the available resources that can be dispatched. Once estimated response time determined, a resource can be dispatched without dispatcher intervention if appropriate. The driver of the vehicle will be notified of the dispatch via its MDT and needs to confirm acceptance by selecting the appropriate button on the MDT. This feature is also supported by the rules feature (See 5.1.3) to ensure that all required parameters are available when processing the outcome.

5.3.3.3 Manual Dispatching

For priority 1 event, the estimated response time needs to be calculated using the available resources that can be dispatched. The dispatcher will then decide from the outcome of the calculations which resource to dispatch. The dispatcher will notify the driver of the vehicle of the dispatch via its MDT and the driver needs to confirm acceptance by selecting the appropriate button on the MDT This feature is also supported by the rules feature (See 5.1.3) to ensure that all required parameters are available when processing the outcome.

5.3.3.4 Duplicate Event

Duplicate events needs to be visible to the dispatcher based on the information provided by the call handler if similar to a current event. The historical event information needs to be augmented if any additional information is available. The dispatcher needs to determine if resources have been dispatched already and make sure resources are not dispatched again.

5.3.3.5 Repeat Call

The call handler might receive a repeat call about an event whereby the caller advises the call handler that the patient condition is worsening for instance.


B201

The dispatcher need to see immediately from the colour coded events that the event has been augmented with updated information and s/he is able to take appropriate action. This feature is also supported by voice and text communication (See 5.1.15) whereby the call handler can advise the dispatcher that additional information about an event is available.

5.3.3.6 Dispatch Resources

After calculating the estimated response time for available resource, a resource can be dispatched automatically or the dispatcher might decide what to dispatch using the outcome of the calculation. In some cases, resources in available status might be on their way to a lower priority event but because they are the most appropriate resource to dispatch they will be re-dispatched to the emergency event. In such a case, the lower priority event will be reassigned to the dispatcher and another resource dispatched to that event.

5.3.3.7 Resource Status

The driver of the vehicle dispatched needs to notify the dispatcher via the MDT that they acknowledge the dispatch. The MDT should have a status feature whereby predefined statuses are loaded and the driver must select the appropriate status. Once selected the dispatcher is notified.

5.3.3.8 Exception Alerts

The supervisor needs to be prompt if the driver of the dispatched vehicle does not send acknowledgements on time. The driver of the dispatched vehicles needs to acknowledge the dispatch and thereafter acknowledge receipt of healthcare facility information. For instance if 3 times in a row the driver does not acknowledges the dispatch after 10 seconds, the supervisor needs to be alerted so that s/he can investigate the reason for slow response. This feature is also supported by the rules feature (See 5.1.3) whereby rules need to be defined to determine when to alert supervisor.

5.3.3.9 Ability to Change Event Allocation

A resource that is already dispatched to an event can be dispatched to another different emergency event if required. The dispatcher needs to be able to dispatch this resource to the emergency event and reassign the initial event to another resource. For instance, if an ILS resource is on its way to patient A and the dispatcher receives an emergency event, the dispatcher should be able to dispatch the ILS resource to the new event as it is a priority 1 and dispatch another resource to patient A. The driver of the vehicle needs to be able to update its status of the MDT accordingly to reflect the change between events. This feature is also supported by the rules feature (See 5.1.3) to ensure that all the parameters are available when dispatching the resource to a different event whilst on its way to another.

5.3.3.10 Ability to Change Event Location

A resource that is already dispatched to an event might need to be redirected if the event location has changed. The caller might provide further information that clarifies the event location or the resources


B201

might get to the location and advise that it is the incorrect location. For the latter, the call handler might have to call back the caller to clarify the event location information. In such cases, the call handler will update the current event information with the updated location details so that the dispatcher is aware of the change.


Dynamic resource utilisation needs to be available whereby a control centre needs to be able to load information about resources available in another control centre if those resources are required for further assistance. For instance during a delta incident, all resources need to be mobilised meaning that resources from the districts might be called to assist the metropole control centre. Information about those resources such as additional equipment status etc needs to be available to the metropole and visible on the maps.

5.3.3.12 Access to Information

The dispatcher needs to have access to information about healthcare facilities when required such as contact details, status, bed capacity, equipment capacity etc. The dispatcher also needs to have access to other information such as weather conditions, traffic conditions such as road diversions, hazardous material information etc.

5.3.3.13 Dynamic Zone Dispatching

The trend analysis results need to be used to determine the areas where EMS resources need to be positioned at a given time. This would be for two fold reasons: - to place the resources near where it is predicted they might be needed; - to place the resources in such a place that they will be least affected by traffic congestion or road

closures to get to a predicted area that they might be needed.

5.3.4 On Board Communication

This function sub group explains the features required for onboard communication.


The driver of the emergency vehicle needs to be equipped with portable devices such as a mobile data terminal (MDT) to communicate with the dispatcher. They will need to advise the control centre of their status and be informed with additional information, for instance the traffic conditions, road closures and impending weather conditions.


The practitioner needs to be equipped with portable devices such as a mobile data terminal (MDT) to communicate with the dispatcher. The practitioner will update the dispatcher about the event and patient’s condition. The MDT also needs to be used to get information about healthcare facilities.

5.3.4.3 Status Update

The driver of the dispatched vehicle needs to be able to press a button on the MDT to indicate its status. Status is updated when acknowledging a dispatch, arriving to the event location, leaving the event location


B201

etc. Predefined status needs to be available for this purpose. The status of the EMS resource will change accordingly when the button is pressed on the MDT.

5.3.4.4 Update of Patient Triage Category

The practitioner attending to the patients needs to update the dispatcher with the patient’s triage category. The dispatcher needs to know if patient is blue, red, yellow or green. Any change in the patient condition that results in a change in triage category needs to be communicated. For instance a patient condition might worsen causing a yellow patient to become a red patient. The MDT needs to accommodate for multiple patients from separate events during one transport and not group them as one. For instance if the vehicle is carrying 2 patients from 2 separate events, the EMS resource needs to capture triage information about both patients separately on the MDT. The dispatcher will be updated accordingly about each patient regularly.

5.3.4.5 Update of Patient Condition

The equipment on board will assist in updating the MDT with patient information such as vital signs. This information needs to be available to the dispatcher regularly to be passed on to the healthcare facility receiving the patient. The MDT needs to accommodate for multiple patients from separate events during one transport and not group them as one. For instance if the vehicle is carrying two patients from two separate events, the EMS resource needs to capture information about both patients separately on the MDT. The dispatcher will be updated accordingly about each patient regularly.

5.3.4.6 Sharing Patient Information

The patient might need to travel via several vehicles before reaching the healthcare facility; the patient information obtained during these transports must not be lost. The practitioners in the various ambulances need to be able to share the patient information with each other. For instance, a patient might be in an incident in the districts and needs to the transported to the metropole. The patient might be admitted to a healthcare facility in the district to stabilise the patient first and then needs to be moved. The patient will be transported in the first ambulance from the district to point A and in another ambulance from point A to the metropole. During transport from district to point A, the patient’s vital signs will be monitored, but once the patient is moved to the other ambulance the historical information about the patient needs to be transferred to the new ambulance so that the complete historical patient information is passed on to the healthcare facility.

5.3.4.7 Update of Medical Supplies

The practitioner attending to the patients also needs to update the stock of the medical supplies with the ones used during the caring of the patient. The equipment on board can also assist with this function and update the MDT. The MDT will check the stock at the end of the shift and the control centre will be advised if additional medical supplies need to be prepared for the next crew that will be using the vehicle in the next shift.


Both the practitioner and the driver needs to be able to access SOPs, formularies and protocols on the MDT.


B201

For instance the MDT needs to be loaded with formularies so that the practitioner caring for the patient needs to access information about dosage when medication needs to be given to patients.

5.3.4.9 Remote Control Warning Devices

The control centre needs to be able to remotely activate the availability of using the lights and / or siren in vehicles when those vehicles are dispatched. For instance, if an ambulance is in status available, the driver will not be able to use the lights and sirens as the control centre will not allow it. The ambulance driver can request permission from the control centre to activate the siren if required.

5.3.5 Traffic Light Pre-emption

The traffic lights need to be remotely controlled so that they can detect an emergency vehicle approaching and phase the signals accordingly to give the emergency vehicle right of way.

5.4 Directing Non-Emergency Resources

The next main functional group that the Emergency Control Centre needs to perform is that of Directing Non Emergency Resources. Non-emergency patients are patients that do not need immediate caring and the dispatcher will dispatch a resource when one becomes available. Non-emergency clients are clients that uses the scheduled transport to access the healthcare facilities. The features for this function has been grouped under Scheduled and Adhoc Transport sub group The features required are described here.

5.4.1 Scheduled and Adhoc Transport

This sub group describes the features required for the transport of client within a region or across regions. It is supported by the advance transport booking feature whereby the advanced bookings are captured against available slots and a schedule generated for the EMS resource to transport the client. The advanced bookings can only be made by healthcare facilities.


The driver of the vehicle transporting the client to the healthcare facility needs to have access to a GPS Navigator to navigate to its destination according to the predefined route. The GPS Navigator needs to be updated with traffic information and road closure information to advise the driver when s/he might need to divert from the route.


The vehicles need to be equipped with tracking devices so that they can be visible by the control centre. Real time tracking of vehicles is required to ensure that the information view by the dispatcher is current. The vehicle tracking facility should also include monitoring of additional features such as speeding. This feature also supports the arrival board at transit lounge feature (See 5.4.1.8) whereby the arrival time of the vehicle can be tracked and client notified on the arrival board.


B201

5.4.1.3 Geo Fencing

Geo fencing needs to be available whereby a geo fence is created around a geographic area and the dispatchers are informed when EMS vehicles enter that area. This feature will assist the dispatcher for outbound transport of patient where for instance if a vehicle from the districts is coming into the metropole region for a drop off, the dispatchers can be alerted and use the transport to pick up an out patient that needs to go back to the districts.

5.4.1.4 Visualisation of Resource

The dispatcher needs to be able to see where the resources are located for both inbound and outbound patient transport. Uniquely shaped and colour coded icons should provide as much visual information as possible. Hovering over the resource and further drill down should provide additional information about that resource, for instance pick up points and drop off points. All resources coming within the geo fence monitored by a control centre needs to be visible of the maps and the information about that resource be available. For instance a vehicle coming from the district needs to be visible via geo fencing by the dispatcher and its information available on the map. This feature is also supported by the vehicle tracking feature (See 5.4.1.2) whereby the devices will indicate the positioning of the vehicle.


The driver of the emergency vehicle needs to be equipped with portable devices such as a mobile data terminal (MDT) to communicate with the control centre. They will need to advise the control centre of their status and liaise with the control centre if for instance a client is not at a pick up point. The MDT will have the information about the clients that need to be picked up and the driver can use the list to ensure that all booked clients have been picked up accordingly. S/he can tick the client off on MDT once picked up.


The practitioner needs to be equipped with portable devices such as a mobile data terminal (MDT) to communicate with the dispatcher. The practitioner will update the dispatcher about the patient’s condition. The MDT also needs to be used to get information about healthcare facilities.

5.4.1.7 Ability to Divert From Scheduled Route

The non emergency patients transport needs to be able to divert from the scheduled route if the control centre receives adhoc request for non-emergency transport during the course of the day. If there are seats available in the transport, the driver can be requested to pick up additional clients that were not scheduled initially. S/he might then need to slightly divert from the route for this pick up. The rules need to cater for the cases whereby the driver is not allowed to divert from the route due to time critical transports. For instance for dialysis patients whereby the treatment needs to start at specific time, the driver needs to drop off the client exactly at that time and cannot be late as it will have a ripple effect on the other dialysis sessions. In this case, the vehicle needs to be ringed fenced so that the dispatcher is not allowed to dispatch the vehicle to another pick up. This feature is also supported by the rules feature (See 5.1.3) to ensure that the vehicles are ring fenced when required.


B201

5.4.1.8 Arrival Board at Transit Lounge

For transport of non-emergency clients between the districts and the metropole and vice versa, transit lounges are available whereby clients change transport depending on their destinations. Arrival boards need to be available where the client can view the arrival and departure times of their transport. The clients are then able to query the control centre using their reference number if the transport they are waiting is not listed.

5.4.1.9 Identification of the Client

Client using the advanced booking transport do not need to have a triage tag as they are all green. Their names will be available on the MDT for the driver of the transport to check when they are picked up. However if the transport is required to pick up a non-emergency patient that was not booked, the patient needs to be identified with a triage tag. For instance, the control centre might receive a call about someone that needs to be transported to a hospital casualty unit due to a broken arm. The transport can pick up the person but a triage tag will be given to him/her to indicate that it is a green patient.

5.5 Incident Command and Control

The next main functional group that the Emergency Control Centre needs to perform is that of Incident Command and Control. Incidents might require the assistance of several other emergency services centre such as the traffic department, fire department, weather centre and so forth. The incident may occur over a long period of time. This function can be broken into sub groups as per below:

Visualisation Of Information Raising Exception Alerts Transfer Of Control Emergency Communication Record Of Incident Timeline Protocols

The features required for each of these sub groups will be described further below.


This sub group relates to the visualisation of information feature discussed in the general features section but with emphasis on geographical visualisation of resources and medical facilities by a control centre for a given incident and also visualisation of other institutions assisting with the incident.

5.5.1.1 Visualisation of Incident

Various maps need to be available to identify where the incident is located. The appropriate map needs to be used based on the type and magnitude of the incident. Different views of the location need to be available. For instance topographical maps are required for airplane accidents, street maps are required for an incident involving a truck with hazardous material, and area maps are required for fire incidents.


B201

Uniquely shaped and colour coded icons should provide as much visual information as possible. For instance, resources have been dispatched to that incident. Hovering over the incident and further drill down should provide additional information. For incidents that are occurring over several days, historical information can also be available when hovering over the incident.

5.5.1.2 Visualisation of Vehicles

The control centre needs to be able to see where the available vehicles are located compared to the incident. Uniquely shaped and colour coded icons should provide as much visual information as possible. For instance the vehicle type or whether the vehicle has additional equipment such as hydrolic tools. Hovering over the vehicle and further drill down should provide additional information. Also hovering over the vehicle should show the estimated response time if the vehicle is assigned to an event. And if it has a patient(s) on board the estimated time of arrival at the destination health care facility. This feature is supported by the vehicle and equipment tracking feature whereby the devices will indicate the positioning of the vehicle.

5.5.1.3 Personnel Tracking

The personnel using the vehicles also need to be tracked so they can be located when they are not in their vehicles. Real time tracking of personnel is required to ensure that the information viewed by the dispatcher is current. For instance during mountain rescue and search and rescue operations where the vehicle might not be able to get close to the patients and the practitioner needs to leave the vehicle at a location and walk a few metres to the patient.


The vehicles need to be fitted with tracking devices so that they can be visible. Real time tracking of vehicles is required to ensure that the information viewed by the dispatcher is current. .

5.5.1.5 Visualisation of Healthcare Facilities

The dispatcher needs to be able to have a geographical view of the healthcare facilities available in the area where the incident occurred or the closest healthcare facilities available in the region. Uniquely shaped and colour coded icons should provide as much visual information as possible. Hovering over the healthcare facilities and further drill down, should provide additional information such as CAT scan equipment.


The driver of the vehicle dispatched needs to have access a GPS Navigator to navigate to their destination. The GPS Navigator needs to be updated with traffic information and road closures information to ensure that alternative routes are offered to the driver if required. For instance if the incident is heavy flooding with road closures, the driver needs to know what are the other alternative routes that can be used to reach the patients.


B201

5.5.1.7 Interactive Visual Map

The control centre needs to be able to position current resources and potential resources at and around the incident on an interactive map. Markers, both graphical and textual, need to be available to capture information about what is displayed on the map. The graphical markers can be icons that can be moved around on the map to indicate staging points for instance positioning of the fire department and the traffic department, hub for EMS services etc. Several types of icons can be available to describe the institutions visually. For instance an ambulance can indicate the EMS resource positioning. The textual markers can be used to capture annotations or link the icons diagrammatically. For instance contact information of the fire department. Hyperlinks to historical information can be included for incidents that are occurring over several days.

5.5.1.8 Recording of Event

The actions taken during the incident command needs to recorded and the recordings need to be available for replay for instance for analysis purposes. Each action needs to be time stamped.

5.5.1.9 Access to Traffic Department Video Feeds

The control centre needs to have access to the traffic department video feeds to have more visual information about an incident. This applies mainly to incidents involving vehicles accidents. The videos can also be kept as part of the incident information.

5.5.1.10 Access to Protocols & SOPs

The control centre needs to have access to updated protocols and SOPs to determine appropriate steps to follow. Incident protocols will assist the control centre in determining if it is a delta incident and what procedure to follow.

5.5.2 Raising Exception Alerts

This sub group describes the feature required to declare exception alerts during an incident.

5.5.2.1 Exception Alerts

The control centre needs to alert employees to be available. The control centre needs to have access to employee contact information to ensure that employees not on duty are also alerted. The control centre needs to alert other emergency services as per protocol if required. For instance the fire department and the traffic department need to be informed of the incident. The dispatchers need to be aware all the calls coming in relating to that specific incident. The calls can be colour coded and flashing to indicate the exception. The control centre also needs to contact the healthcare facilities to warn them about a high number of patients coming in. The media alerts needs to be activated to provide the media with regular updates on the incident. This feature is supported by the visualisation of information (See 5.5.1) sub group.


B201

5.5.3 Transfer of Control

This sub group describes the features required for the transfer of control during a disaster.

5.5.3.1 Command Structure

After notifying all employees when an incident or a disaster is declared, the command structure needs to be established. The bronze commander will be on site and responsible for activities at the incident. The bronze commander needs to provide feedback to the control centre via MDT. The silver commander will be the person responsible for the control centre or the control centre itself. The silver commander needs to be able to liaise with the bronze commander and the gold commander. Information between the three levels of command flows via MDT, teleconferencing, electronic messaging or radio. The gold commander is the directorate and will make the decisions and liaise with other services if required. The gold commander needs to have access to the information provided by the bronze commander and the visual maps to take the appropriate decisions.

5.5.3.2 Ability to Escalate Incident

Dynamic resource utilisation needs to be available whereby a control centre needs to be able to load information about resources available in another control centre if those resources are required for further assistance. For instance during a delta incident, all resources need to be mobilised meaning that resources from the districts might be called to assist the metropole control centre. Information about those resources such as additional equipment status etc needs to be available to the metropole and visible on the maps. Also control centres need to be able to transfer control to each other if required. The metropole control centre needs to be able to run the operations of the districts seamlessly from their control centre.

5.5.3.3 Access to SOPs

The control centre needs to have access to updated SOPs to determine appropriate steps to follow for transfer of control and establishing roles during incidents and disasters.

5.5.4 Emergency Communication

This sub group describes the features required for emergency communication between control centres, bases and facilities.

5.5.4.1 Emergency Services Prioritization

The cellular network used by emergency services need to be prioritised and controlled during disaster and major incidents so that they can communicate efficiently amongst themselves and all the other institutions involved. The cellular network needs to be robust to channel their resources and give priority to emergency services.


B201

5.5.4.2 Mobile Data Terminal

The mobile EMS employees need to be able to update the control centre via the MDT. Regular update about the incident and the patients need to be provided to the bronze commander so that the silver commander can be updated accordingly and take the appropriate decisions and consult the gold commander if required.

5.5.4.3 Inter Control Centre Communication

Control centres in the metropole and the districts need to be able to liaise with each other for routine communication. Metropole control centre might need some vehicles from the districts to assist with the incident for instance. This feature is supported by the ability to escalate incident feature (See 5.5.3.2)

5.5.4.4 Healthcare Facility Communication

The control centres needs to be able to communicate with the healthcare facilities in an efficient way via electronic messaging or a dedicated line so that they can enquire about their status and facilities but also update them on a regular basis about patient arrivals and information.

5.5.4.5 Mass Casualty Patient Registration

During an incident the tasks need to be distributed. The first attending resources at the scene of the incident need to ensure that they count the number of patients and assign a triage to those patients. The information needs to be communicated back to the control centre so that they can dispatch resources and advise healthcare facilities accordingly.

5.5.4.6 Media Alerts

Information about major incidents impacting the population of a region needs to be sent to the media via emails or SMS. The supervisor of a control centre needs to be able to have access to an advisory message template that can be used to distribute information about incidents to media agencies without them having to phone the control centre. The media agencies or other institutions interested in the information can register with the control centre to receive information and regular updated about an incident.

5.5.5 Record the Incident Timeline

This sub group describes the features required to obtain information about the incident.

5.5.5.1 Incident Logging

Information about major incidents needs to be logged promptly including the time the call came through. Each decision taken, implemented, each meeting about the incident etc needs to be logged and time stamped. Information obtained from the caller, voice, text and video as well as the actions and procedures followed by the dispatched resources need to be logged and time stamped. This information needs to be available for further analysis if required.

5.5.5.2 Recording of Incident

In addition to logging the information, the actions need to be recorded and time stamped. The recordings need to be available for further analysis if required.


B201

5.5.6 Protocols

This sub group describes the features required for identifying an incident and the actions to take thereafter.

5.5.6.1 METHANE Report

The METHANE report needs to be compiled and the information made available to the team working on the incident. Information about the Major incident, the Event location, the Type of incident, if Hazards materials are involved, Access and egress, Number and severity of patients and other Emergencies services on the scene needs to be compiled into a METHANE report.

5.5.6.2 Incident Protocols

Once the METHANE report compiled, the appropriate protocol needs to be retrieved and followed by all parties concerned. The dispatcher needs to be able to use the incident protocol to dispatch the appropriate teams (for instance the ambulance, the duty medic, the command vehicle etc) and inform the appropriate institutions (for instance disaster management). The protocol will also indicate if the incident is a delta incident and of what magnitude. For instance a commuter train accident will be a delta incident with code green for up to 50 patients, code Orange for between 50 and 200 patients and code red for 200 – 1000 patients.

5.5.6.3 Medical Protocols

The Medical protocols need to be available to assist the practitioner to attend to the patients. For instance formularies to provide medication to the patient needs to be available.

5.5.6.4 Re-classify According to Protocols

Once the METHANE report is completed and protocol followed, the situation report provided by the Bronze Commander during the incident is used to constantly monitor the incident. Information from the situation report needs to be used to re-evaluate the incident and re-classify the incident if required. The re classification may imply that the incident becomes a higher or lower priority incident and the protocol needs to be changed accordingly. For instance a delta incident can escalate from one class to a high priority class.

5.6 Healthcare Facilities Interaction

Healthcare facility interaction is an integral part of the operations process of the control centre. The dispatcher needs to interact with the healthcare facilities to determine if a patient can be taken to this facility and the EMS resource needs to interact with the healthcare facility when handing over a patient. The Healthcare facilities interaction function can be further broken down into sub groups below:

Capacity And Status Emergency Information Patient information

The features required for each of these sub groups will be described further below.


B201

5.6.1 Capacity and Status

This sub group describes the features required when the dispatcher enquires about a healthcare facility.

5.6.1.1 Visualisation of Healthcare Facility

The dispatcher needs to be able to have a geographical view of the healthcare facilities available within his/her zone. Uniquely shaped and colour coded icons should provide as much visual information as possible. Further drill down or hovering over the healthcare facility, should provide information about the healthcare facility bed status for instance or facilities such as cat scans etc.

5.6.1.2 Access to Healthcare Facilities Directory

A healthcare facility directory needs to be available so that the dispatcher can contact the healthcare facility for information. The information obtained about a healthcare facility needs to be published so that it can be accessed by other dispatchers if required.

5.6.1.3 Healthcare Facilities Availability

Information about the availability of a healthcare facility is needed. For instance whether they are open or closed needs to be available to the dispatcher. The information about a healthcare facility being closed needs to be published so that the other dispatchers are also aware of the situation.

5.6.1.4 Healthcare Facilities Capacity

Information about the number of beds available at a healthcare facility needs to be available to the dispatcher. The information can be published at regular intervals for other dispatchers to access.

5.6.1.5 Healthcare Facilities Services and Equipment

Information about the services offered by a healthcare facility needs to be available to the dispatcher. The information can be view when the dispatcher hovers over the map that displays healthcare facilities locations. The information needs to be used in determining if the healthcare facility is appropriate or not. For instance, does the healthcare facility have a trauma unit or a paediatric unit if children need to be transported? Does the healthcare facility have a maternity ward if the patient is in labour? The equipment available at the healthcare facility also needs to be published when available as this is also a determining factor when deciding on the appropriate healthcare facility. For instance does the hospital have a CT scan if the patient requires one at arrival? A helipad is also a hospital feature that needs to be published for cases where the patients need to be transported by air.

5.6.2 Emergency Information

This sub category describes the features required when the patient is on its way to the healthcare facilities.


B201

5.6.2.1 Update of Patient Triage Category

Once the EMS driver has acknowledged that the patient will be transported to a given healthcare facility, the dispatcher needs to advise the healthcare facility that the patient is on its way and send the triage category of the patient. The healthcare facility needs to know if they are expecting a red, yellow or green patient. Any change in the patient condition that results in a change in triage category also needs to be communicated. For instance a patient condition might worsen causing a yellow patient to become a red patient.

5.6.2.2 Update of Patient Information

The equipment on board will assist in updating the MDT with patient information such as vital signs. This information needs to be available to be passed on to the healthcare facility receiving the patient. The dispatcher can also update the healthcare facility with patient information such as medical aid no, name if available etc.

5.6.2.3 Arrival Board at Healthcare Facilities

The healthcare facilities need to be equipped with arrival boards so that they can have a list of the patients that are coming through and their estimated time of arrival.

5.6.3 Patient Information

This sub group describes the features required when the EMS practitioner interacts with the healthcare facility when handing over a patient and the follow up thereafter.

5.6.3.1 Mobile Data Terminal for Emergency Care Practitioner

The MDT used by the EMS practitioner caring for the patient needs to have the latest information about the patient status and condition when the patient arrives at the healthcare facility. The MDT will be updated via the medical monitoring equipment on board with vital signs, diagnostics, case type, triage category etc. The EMS practitioner needs to be able to share the information on the MDT with the healthcare facility so that the healthcare facility has the latest patient information. The information can be transferred to the healthcare facility over the WAN but for the districts for instance where they might not have connectivity everywhere, the information might need to be printed.

5.6.3.2 Access to Documents

Both the driver and the practitioner needs to have access to SOPs, policies and protocols on the MDT. In cases where the healthcare facility refuses the patient at arrival, the practitioner needs to be able to consult the policies and show the healthcare facility the rules whereby they need to accept the patient without having to liaise with the dispatcher.

5.6.3.3 Follow up On Patients

The control centre needs to be able to have access to the patient information at the healthcare facility after they have been handed over. It needs to be able to do a follow up on the patient to find out about the healthcare facility diagnostic, if the patient has been referred to another hospital etc.


B201

The information obtained can be used to augment the event file in the system.


B201

Annexure A – Features Priority Matrix All the features described in this document are required but they have been prioritised as per the list herewith. For each feature a priority was identified as follows:

- Priority 1 - Highest priority - Priority 2 - High priority - Priority 3 - Low priority - Priority 4 - Lowest priority

In addition it must be noted that the Resource Management features have been prioritised based on the requirements of the control centre and not on the fleet management and human resources management requirements. Section 6.1 shows the features priority matrix as they are listed in this document whilst Section 6.2 shows the features priority matrix in order of priority for each group. Features Priority Matrix – Ordered by Section Resource Management PRIORITY4.1.1 Ability To Access Historical Event Information 14.1.2 Access to Historical Information from Other Emergency Services 34.1.3 Scheduled Events 24.1.4 Route Planning 14.2.1.1 Ambulances Availability 14.2.1.2 Ambulance Crew Availability 14.2.1.3 Ambulance Crew Skills 14.2.1.4 Scheduling Ambulance and Their Crews 14.2.1.5 Dynamic Scheduling 34.2.1.6 Publishing and Distribution of the Schedules 34.2.2.1 Transport Availability 14.2.2.2 Transport Driver Availability 14.2.2.3 Scheduling Transport and Their Drivers 14.2.3.1 Tracking of Specialised Medical Equipment 14.2.4.1 Stock Control of Consumables 44.2.4.2 Consumables On Board The Vehicles 44.2.5.1 Other Forms of Transport Availability 14.3.1 Shifts Assignment And Sign On 14.3.2 Monitoring 34.3.3 Specialised Medical Equipment Assignment 34.3.4 Consumables Assignment 4 Control Centre Management PRIORITY5.1.1 Sign On 15.1.2 Remote Sign On 45.1.3 Rules 1


B201

5.1.4 Control and Replication 15.1.5 Recording of Event 15.1.6 Visualisation of Information 15.1.7 Escalation Facilities 15.1.8 Teleconferencing Facilities 15.1.9 Mobile Data Terminals For Drivers 15.1.10 Mobile Data Terminals For Emergency Care Practitioners 35.1.11 Management Operation Platform 25.1.12 Media Alerts 35.1.13 Dashboards 25.1.14 Reporting 15.1.15 Voice and Text Communication 15.1.16 Electronic messaging 15.2.1 Client Registration 45.2.2.1 Call Logging 15.2.2.2 Ability to Identify Telephone Number 15.2.2.3 Ability to Receive SMS 15.2.2.4 Ability to Receive MMS 35.2.2.5 Ability to Receive Panic Button Alerts 45.2.2.6 Ability to Receive Fax To Email 15.2.2.7 Ability to Identify Telephone Prefix 15.2.2.8 Ability to Differentiate Between Calls 15.2.2.9 Automated Call Back 35.2.2.10 Voice Recording 15.2.2.11 Simplified Call Taking Screen 15.2.2.12 Call Reference Number 15.2.2.13 Ability to Access Historical Call Information 25.2.2.14 Ability to Locate The Event 15.2.2.15 Access to Protocols and SOPs 15.2.2.16 Call Prioritisation 15.2.2.17 Assign to Dispatcher by Zone 15.2.2.18 Incoming Call Analysis 15.2.3.1 Schedule and Routes Definition 15.2.3.2 Online Booking 15.2.3.3 Simplified Call Taking Screen 15.2.3.4 Ability to Access Historical Client Information 35.2.3.5 Ability to Send SMS 35.2.3.6 Online Advanced Booking Log 15.2.3.7 Advance Booking Analysis 15.2.4.1 Dropped Calls 35.2.4.2 Ability to Contact Client Sending Panic Button Alerts 45.2.4.3 Ability to Contact Client Sending SMS 15.2.4.4 Ability to Call Back The Caller 1


B201

5.2.4.5 Voice Recording 15.2.5.1 Calls Monitoring 15.2.5.2 Resource Monitoring 15.2.5.3 Ability To Escalate Service Level 25.3.1.1 Visualisation of Event 15.3.1.2 Visualisation of Vehicles 15.3.1.3 Personnel Tracking 35.3.1.4 Vehicle Tracking 15.3.1.5 Special Medical Equipment Tracking 15.3.1.6 Geo Fencing 15.3.1.7 Visualisation of Healthcare Facilities 25.3.1.8 Navigation Facilities 15.3.1.9 Access to Protocols and SOPs 35.3.2.1 Call Prioritisation 15.3.2.2 Mobile Data Terminal for Drivers 15.3.2.3 Mobile Data Terminal for Emergency Care Practitioner 35.3.2.4 Resource Status 15.3.2.5 Equipment Status 45.3.2.6 Situation Report 45.3.2.7 Unique Identification of the Patient 45.3.2.8 Acknowledge of Assigned Event 15.3.2.9 Ability to Escalate Service Level 15.3.2.10 Ability to Hand-over Events 15.3.2.11 Priorities and Status Analysis 15.3.3.1 Call Prioritisation 15.3.3.2 Automated Dispatching 35.3.3.3 Manual Dispatching 15.3.3.4 Duplicate Event 15.3.3.5 Repeat Call 15.3.3.6 Dispatch Resources 15.3.3.7 Resource Status 15.3.3.8 Exception Alerts 15.3.3.9 Ability to Change Event Allocation 15.3.3.10 Ability to Change Event Location 15.3.3.11 Ability to Escalate Service Level 25.3.3.12 Access to Information 15.3.3.13 Dynamic Zone Dispatching 25.3.4.1 Mobile Data Terminal for Drivers 15.3.4.2 Mobile Data Terminal for Emergency Care Practitioner 35.3.4.3 Status Update 15.3.4.4 Update of Patient Triage Category 15.3.4.5 Update of Patient Condition 45.3.4.6 Sharing Patient Information 1


B201

5.3.4.7 Update of Medical Supplies 45.3.4.8 Access to Protocols and SOPs 35.3.4.9 Remote Control Warning Devices 35.3.4.10 Traffic Light Pre-emption 35.4.1.1 Navigation Facilities 15.4.1.2 Vehicle Tracking 15.4.1.3 Geo Fencing 15.4.1.4 Visualisation of Resource 15.4.1.5 Mobile Data Terminal for Drivers 15.4.1.6 Mobile Data Terminal for Emergency Care Practitioner 35.4.1.7 Ability To Divert From Scheduled Route 15.4.1.8 Arrival Board At Transit Lounge 45.4.1.9 Identification Of the Client 45.5.1.1 Visualisation of Incident 15.5.1.2 Visualisation of Vehicles 15.5.1.3 Personnel Tracking 35.5.1.4 Vehicle Tracking 15.5.1.5 Visualisation of Healthcare Facilities 25.5.1.6 Navigation Facilities 15.5.1.7 Interactive Visual Map 15.5.1.8 Recording of Event 15.5.1.9 Access to Traffic Department Video Feeds 35.5.1.10 Access to Protocols & SOPs 15.5.2.1 Exception Alerts 15.5.3.1 Command Structure 35.5.3.2 Ability to Escalate Incident 15.5.3.3 Access to SOPs 15.5.4.1 Emergency Services Prioritization 45.5.4.2 Mobile Data Terminal 35.5.4.3 Inter Control Centre Communication 15.5.4.4 Healthcare Facility Communication 25.5.4.5 Mass Casualty Patient Registration 15.5.4.6 Media Alerts 35.5.5.1 Incident Logging 15.5.5.2 Recording of Incident 15.5.6.1 METHANE Report 15.5.6.2 Incident Protocols 15.5.6.3 Medical Protocols 45.5.6.4 Reclassify According to Protocols 15.6.1.1 Visualisation of Healthcare Facilities 25.6.1.2 Access to Healthcare Facilities Directory 25.6.1.3 Healthcare Facilities Availability 15.6.1.4 Healthcare Facilities Capacity 1


B201

5.6.1.5 Healthcare Facilities Services and Equipment 25.6.2.1 Update of Patient Triage Category 15.6.2.2 Update of Patient Information 35.6.2.3 Arrival Board at Healthcare Facilities 25.6.3.1 Mobile Data Terminal for Emergency Care Practitioner 45.6.3.2 Access to Documents 45.6.3.3 Follow up On Patients 4

Features Priority Matrix – Ordered by Priority Resource Management PRIORITY4.1.1 Ability To Access Historical Event Information 14.1.4 Route Planning 14.2.1.1 Ambulances Availability 14.2.1.2 Ambulance Crew Availability 14.2.1.3 Ambulance Crew Skills 14.2.1.4 Scheduling Ambulance and Their Crews 14.2.2.1 Transport Availability 14.2.2.2 Transport Driver Availability 14.2.2.3 Scheduling Transport and Their Drivers 14.2.3.1 Tracking of Specialised Medical Equipment 14.2.5.1 Other Forms of Transport Availability 14.3.1 Shifts Assignment And Sign On 14.1.3 Scheduled Events 24.1.2 Access to Historical Information from Other Emergency Services 34.2.1.5 Dynamic Scheduling 34.2.1.6 Publishing and Distribution of the Schedules 3

4.3.2 Monitoring 34.3.3 Specialised Medical Equipment Assignment 34.2.4.1 Stock Control of Consumables 44.2.4.2 Consumables On Board The Vehicles 44.3.4 Consumables Assignment 4 Control Centre Management PRIORITY5.1.1 Sign On 15.1.3 Rules 15.1.4 Control and Replication 15.1.5 Recording of Event 15.1.6 Visualisation of Information 15.1.7 Escalation Facilities 15.1.8 Teleconferencing Facilities 15.1.9 Mobile Data Terminals For Drivers 1


B201

5.1.14 Reporting 15.1.15 Voice and Text Communication 15.1.16 Electronic messaging 15.2.2.1 Call Logging 15.2.2.2 Ability to Identify Telephone Number 15.2.2.3 Ability to Receive SMS 15.2.2.6 Ability to Receive Fax To Email 15.2.2.7 Ability to Identify Telephone Prefix 15.2.2.8 Ability to Differentiate Between Calls 15.2.2.10 Voice Recording 15.2.2.11 Simplified Call Taking Screen 15.2.2.12 Call Reference Number 15.2.2.14 Ability to Locate The Event 15.2.2.15 Access to Protocols and SOPs 15.2.2.16 Call Prioritisation 15.2.2.17 Assign to Dispatcher by Zone 15.2.2.18 Incoming Call Analysis 15.2.3.1 Schedule and Routes Definition 15.2.3.2 Online Booking 15.2.3.3 Simplified Call Taking Screen 15.2.3.6 Online Advanced Booking Log 15.2.3.7 Advance Booking Analysis 15.2.4.3 Ability to Contact Client Sending SMS 15.2.4.4 Ability to Call Back The Caller 15.2.4.5 Voice Recording 15.2.5.1 Calls Monitoring 15.2.5.2 Resource Monitoring 15.3.1.1 Visualisation of Event 15.3.1.2 Visualisation of Vehicles 15.3.1.4 Vehicle Tracking 15.3.1.5 Special Medical Equipment Tracking 15.3.1.6 Geo Fencing 15.3.1.8 Navigation Facilities 15.3.2.1 Call Prioritisation 15.3.2.2 Mobile Data Terminal for Drivers 15.3.2.4 Resource Status 15.3.2.8 Acknowledge of Assigned Event 15.3.2.9 Ability to Escalate Service Level 15.3.2.10 Ability to Hand-over Events 15.3.2.11 Priorities and Status Analysis 15.3.3.1 Call Prioritisation 15.3.3.3 Manual Dispatching 15.3.3.4 Duplicate Event 1


B201

5.3.3.5 Repeat Call 15.3.3.6 Dispatch Resources 15.3.3.7 Resource Status 15.3.3.8 Exception Alerts 15.3.3.9 Ability to Change Event Allocation 15.3.3.10 Ability to Change Event Location 15.3.3.12 Access to Information 15.3.4.1 Mobile Data Terminal for Drivers 15.3.4.3 Status Update 15.3.4.4 Update of Patient Triage Category 15.3.4.6 Sharing Patient Information 15.4.1.1 Navigation Facilities 15.4.1.2 Vehicle Tracking 15.4.1.3 Geo Fencing 15.4.1.4 Visualisation of Resource 15.4.1.5 Mobile Data Terminal for Drivers 15.4.1.7 Ability To Divert From Scheduled Route 15.5.1.1 Visualisation of Incident 15.5.1.2 Visualisation of Vehicles 15.5.1.4 Vehicle Tracking 15.5.1.6 Navigation Facilities 15.5.1.7 Interactive Visual Map 15.5.1.8 Recording of Event 15.5.1.10 Access to Protocols & SOPs 15.5.2.1 Exception Alerts 15.5.3.2 Ability to Escalate Incident 15.5.3.3 Access to SOPs 15.5.4.3 Inter Control Centre Communication 15.5.4.5 Mass Casualty Patient Registration 15.5.5.1 Incident Logging 15.5.5.2 Recording of Incident 15.5.6.1 METHANE Report 15.5.6.2 Incident Protocols 15.5.6.4 Reclassify According to Protocols 15.6.1.3 Healthcare Facilities Availability 15.6.1.4 Healthcare Facilities Capacity 15.6.2.1 Update of Patient Triage Category 15.1.11 Management Operation Platform 25.1.13 Dashboards 25.2.2.13 Ability to Access Historical Call Information 25.2.5.3 Ability To Escalate Service Level 25.3.1.7 Visualisation of Healthcare Facilities 25.3.3.11 Ability to Escalate Service Level 2


B201

5.3.3.13 Dynamic Zone Dispatching 25.5.1.5 Visualisation of Healthcare Facilities 25.5.4.4 Healthcare Facility Communication 25.6.1.1 Visualisation of Healthcare Facilities 25.6.1.2 Access to Healthcare Facilities Directory 25.6.1.5 Healthcare Facilities Services and Equipment 25.6.2.3 Arrival Board at Healthcare Facilities 25.1.10 Mobile Data Terminals For Emergency Care Practitioners 35.1.12 Media Alerts 35.2.2.4 Ability to Receive MMS 35.2.2.9 Automated Call Back 35.2.3.4 Ability to Access Historical Client Information 35.2.3.5 Ability to Send SMS 35.2.4.1 Dropped Calls 35.3.1.3 Personnel Tracking 35.3.1.9 Access to Protocols and SOPs 35.3.2.3 Mobile Data Terminal for Emergency Care Practitioner 35.3.3.2 Automated Dispatching 35.3.4.2 Mobile Data Terminal for Emergency Care Practitioner 35.3.4.8 Access to Protocols and SOPs 35.3.4.9 Remote Control Warning Devices 35.3.4.10 Traffic Light Pre-emption 35.4.1.6 Mobile Data Terminal for Emergency Care Practitioner 35.5.1.3 Personnel Tracking 35.5.1.9 Access to Traffic Department Video Feeds 35.5.3.1 Command Structure 35.5.4.2 Mobile Data Terminal 35.5.4.6 Media Alerts 35.6.2.2 Update of Patient Information 35.1.2 Remote Sign On 45.2.1 Client Registration 45.2.2.5 Ability to Receive Panic Button Alerts 45.2.4.2 Ability to Contact Client Sending Panic Button Alerts 45.3.2.5 Equipment Status 45.3.2.6 Situation Report 45.3.2.7 Unique Identification of the Patient 45.3.4.5 Update of Patient Condition 45.3.4.7 Update of Medical Supplies 45.4.1.8 Arrival Board At Transit Lounge 45.4.1.9 Identification Of the Client 45.5.4.1 Emergency Services Prioritization 45.5.6.3 Medical Protocols 45.6.3.1 Mobile Data Terminal for Emergency Care Practitioner 4


B201

5.6.3.2 Access to Documents 45.6.3.3 Follow up On Patients 4


B201

Annexure B – Storyline of the Future Operation Call taking The sequence of events starts with a call from a member of the public calling one of the emergency call centres, like 112. The operator will establish amongst other the cell/telephone number of the caller, the location of the event, the callers address and the type of emergency. The call centres database will be updated with the call data recorded. If the call is a Medical Emergency it will be transferred to the EMS call centre. At the same time the captured data will be transferred and a reference number given to the 112 call taker The EMS Call taker will start speaking to the caller and the data capture screen will already contain all the data already captured by the transferring call centre, this will allow him to verify any of that data without repeating any of the questions. The EMS Call taker can then immediately refocus on the emergency. The EMS Call taker will be assisted by a set of questions from a “Medical Dispatch Protocol Reference System” which has been customised for local conditions. Usually the questions are determined by the previous question’s answer, similar to a decision tree. The moment that the information captured indicates that a dispatch trigger has been activated an automatic message will go to the dispatcher and the auto dispatching subroutine which will suggest the most logical response unit available for dispatch. The EMS Call taker can continue with the questioning and provide advisory medical assistance with the aid of the protocols. It is important that the EMS Call taker can capture the information quickly. Most of the capturing should be based on the selection of items on a drop down list. If possible, free text capturing should be supported with voice recognition software that can be activated when needed. Dispatcher environment Dispatchers will be allocated resources on a geographical basis and/or by event types. Once this has been done the solution will allocate the event to the most appropriate resource for dispatching. The dispatcher will acknowledge all P1 calls allocated to her/him. All response units are dynamically allocated to the indicated event on a power shift basis. Each dispatcher can see all the location and status of all their events, response units and available medical facilities within their zones on a display. The display should also show changing road conditions to assist with the directing of resources. They should have the ability to zoom in and out of the display. They should be able to apply various filters to see more or less depending on the need. When they hover with the cursor over an object the solution should display the pertinent details momentarily. The main idea is that the dispatcher should be able to work pre-dominantly from his map display. The remaining information needed should be displayed on further monitors that give immediate access with the minimum navigation effort. In a single view access should be gained to maps, communication, list of events, response units, medical faculties, e-Mails/sms’s, trend and alerts. Most of the information should be pushed to the dispatcher. Dispatching Dispatchers should be able to drag and drop resources to events. Once dispatched in this way, the system will send the information to the response unit. It is expected that the response unit will acknowledge the assignment by the “push of a button” from the response unit. Should this not happen within a set time, the


B201

dispatcher will be alerted to this. In such a case the dispatcher will contact the response unit by radio in private mode. En-route to the scene All response units will have a combination of computing/communication equipment. These units will be securely affixed in the front (and back of the response units, if it is an ambulance”. The drivers unit will most probably be a (Mobile Data Terminal) MDT type unit. The unit in the back will probably a kind of laptop/small form computer with a fixed disc, like a “Toughbook”. If the driver of the response unit requires assistance with the navigation to the scene, they can “press a button” for a “Garmin” type navigation assistance. Depending on the priority rating of the event, the control centre will also automatically transfer control keys to the siren and special flashing light units on the response unit. As the response unit approach critical and busy intersections the units approach should reset the robot parameters to facilitate the safe crossing of the response unit. Arrival on the scene The tracking system should notice the arrival of the response unit at the scene and notify the control room/dispatcher. Once the crew has established that they are indeed on the scene and made contact with caller or patient they will notify the control room/dispatcher with a push of a “On scene” button. They will immediately proceed to treat the patient. They will contact the control centre should they require further information or assistance. The patient(s) will be loaded into the ambulance. The crew assisting the patient will capture case dependent minimalistic information through a keyboard. In the background the solution will check on the patients medical fund status. Critical patients will be attached to on-board medical equipment which will feed vital statistics to the on-board processor for onward communication to the control centre. The driver and the dispatcher will liaise about the most suitable medical facility, to which the patient should be transported, once the control room issues the instruction the response unit will proceed to the indicated medical facility. The solution will notify the medical facility accordingly. An arrivals display board will show the patients from EMS en-route to that medical facility. As the patient approaches the medical facility the tracking system will initiate a final set of vital statistics to be captured and relayed to the control centre for onward transmission to the medical facility. Please note that the control room may in emergency redirect the response unit to provide further assistance on another event before proceeding to their destination. Arrival at the Health facility The tracking system should notify the control centre when the response unit arrives at the designated Health facility. The crew member in the back of the response unit will prepare the hand-over patient information and submit this to the solution for onward communication to the Health facility. Each Emergency Centre will have a designated sister with an EMS “Toughbook” computer to receive the emergency patients and through which information and messages will be interchanged. Once clearance has been received from her the response unit can depart again. Later, once the patient has undergone assessment and treatment the patient record will be updated and returned to the solution as the final record of the event trail.