b301 information requirements v1.1 - western cape

Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential of 29

B301

B301 Information Requirements

Enterprise Information Model

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

METRO EMS Confidential


B301

Document History

Document Location

The diagrams have been created using open source drawing tool, Dia v0.97, see Annexure B. Each individual diagram has been embedded in this document, Annexure B, and has also been stored individually at the same location as this document.

Revision History

Revision Number

Revision Date

Summary of Changes Changes marked

1.1 2010-01-28

Final 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.


B301

Contents 1. Introduction........................................................................................................................... 4

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

2. High Level Enterprise Information Model............................................................................ 6 3. Reporting Requirements ....................................................................................................... 7

3.1 Reporting Environment ..................................................................................................... 7 3.1.1 Reporting self-sufficiency........................................................................................... 7 3.1.2 Intuitive user interface ................................................................................................ 7 3.1.3 Rapid learning ............................................................................................................. 7 3.1.4 Support all reporting requirements ............................................................................. 7 3.1.5 Reporting portal .......................................................................................................... 7 3.1.6 Drill down capability .................................................................................................. 8 3.1.7 Relational OLAP/cube based ...................................................................................... 8 3.1.8 Web interface and thin client ...................................................................................... 8 3.1.9 64 bit in-memory processing....................................................................................... 8 3.1.10 Access to multiple data platforms............................................................................... 8 3.1.11 Strong compression capabilities.................................................................................. 8 3.1.12 Data warehousing........................................................................................................ 8 3.1.13 Result in a decreased need for printing....................................................................... 8 3.1.14 Active directory type security ..................................................................................... 9 3.1.15 Support messaging ...................................................................................................... 9

3.2 Reporting Dimensions ..................................................................................................... 10 4. Management Information Requirements ............................................................................ 11

4.1 KPA’s and KPI’s ............................................................................................................. 11 4.2 Dashboards ...................................................................................................................... 11 4.3 Views/reports................................................................................................................... 12

5. Data Interfaces or Interchanges........................................................................................... 15 5.1 Solution Services ............................................................................................................. 17 5.2 External services.............................................................................................................. 17 Annexure A: Data Entities......................................................................................................... 19 Annexure B: Key Performance Areas and Indicators................................................................ 25


B301

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 Information Requirements of the solution required to enable the Emergency Medical Services (EMS) “To-Be” operational process [1] and in support of the functions and application features [2]. It incorporates a high level Enterprise Information 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


B301

1.3 Document Description

This document incorporates a high level Enterprise Information Model (EIM), the EMS reporting requirements, management information requirements and the envisaged data interfaces between modules as well as to third parties. This EIM is to identify all the business entities and relationships that are needed to support the EMS operational processes of the Business Process Model (BPM) [1] and business functionality as per the Application Function Model (AFM) [2]. The EIM comprises of diagrams of logical entities (or information subject areas) and their definitions as well as the relationship definitions between them. Only those relationships that are the most meaningful between the business entities have been drawn and described. The most meaningful relationships are those that are reflected in the BPM and AFM. The logical entities were determined by reflecting on the business entities discovered whilst determining the “To-Be” operational process (i.e. BPM). The reporting requirements were determined during workshops with key EMS personnel. The management information requirements were also determined from workshops and from other documentation from previous work done by EMS. This document was referred to Emergency Medical Services Subject Matter Experts for input and their feedback was considered. Thereafter this was reviewed by the approver before being signed off.

1.4 Purpose

This document is used: - To provide a strategic overview and understanding of the major high-level groups of information

needed to manage the business and support the processes in the process definitions. - To provide architectural parameters and boundaries for subsequent data analysis and data design

activities. It sets the baseline. - To provide high-level planning constructs with respect to the data / information needs of the

enterprise. - To enable and support a proper alignment between the key information requirements of the

business and its partners, with the goals and objectives of the enterprise. - To enable consultants and senior management to explore the constraints on the business and

opportunities for, and implications of change.

1.5 References

This document is based on and refers to the following documents: [1] A104 To-Be Process v1.1 (Business Process Model) [2] B201 Features v1.1 (Application Function Model) These are found in the same document location as this document.


B301

2. High Level Enterprise Information Model The following diagram shows a high level view of the structure and content of the key categories, or "subject areas” of persistent data that need to be managed by the enterprise.

EQUIPMENT

RESPONSE UNITTRANSPORTER PERSON

PERSONTYPE

SQUAD

TRANSPORTTYPE

EVENT

INCIDENT PATIENT HEALTHCAREFACILITY

PROTOCOLHEALTHCARE

SERVICE

CALLCALLER

REGISTEREDCALLER

SCHEDULEROUTEROUTE LEG

LOCATION

MAP

The diagram depicts the main data entities and their relationships. In the Annexure A of this document this logical view of these entities is described in terms of what these entities are and some key attributes. In addition only those relationships that are the most meaningful between the business entities have been drawn and described. The most meaningful relationships are those that are reflected in the operational process [1] and the features document [2]. Essentially a call about an event is received, which gives rise to a response unit and crew being dispatched to attend to a patient, who is then transported to a healthcare facility for treatment. In support of this main line activity, many other actions are required which involves additional information aspects. The “storyline” Annexure B in the features document [2] describes how the operational process interlocks with the features and the information aspects involved.


B301

3. Reporting Requirements Please note that the solution provided should have a fair number of already developed reports which meet some or most of the requirements outlined in this document. Due to personal preferences on reporting, it is expected that existing reports will be further customised to EMS needs. Additional reports will be defined and developed by the implementation team. Trained users will continue to augment these reports by developing their own reports as and when the need arises.

3.1 Reporting Environment

The following is a list of the main requirements for the reporting environment.

3.1.1 Reporting self-sufficiency

While product specialists will set up the reporting environment, it is expected that all the reporting operations, maintenance and enhancements can be done by trained users.

3.1.2 Intuitive user interface

The reporting tool(s) will have an intuitive interface, so that users will find all the dashboards, views and reports simple and easy to use.

3.1.3 Rapid learning

The reporting tool(s) and environment will be easy to understand and use. Training of developers and users should not exceed two weeks and two days respectively.

3.1.4 Support all reporting requirements

The reporting environment should take care of all the requirements for the development, production and publishing of information to the user community and stakeholders.

3.1.5 Reporting portal

It is envisaged that users can go to a web portal from where all their information needs can be satisfied in a self-help environment.


B301

3.1.6 Drill down capability

The reporting environment will allow for users to drill drown from summarised information all the way to the lowest levels of detail.

3.1.7 Relational OLAP/cube based

The reporting environment will be supported on relational data through the use of OLAP or cube technologies.

3.1.8 Web interface and thin client

The reporting portal should be accessible through a web interface and/or thin client platforms.

3.1.9 64 bit in-memory processing

Typically all the report processing should take place in memory using 64 bit processing capabilities.

3.1.10 Access to multiple data platforms

The reporting tool should be able to access data from multiple data platforms on the network.

3.1.11 Strong compression capabilities

The reporting tool should have industry standard compression capabilities to condense large volumes of data into manageable data stores for communication and processing efficiency.

3.1.12 Data warehousing

If possible we prefer that operational data be drawn directly from production or replicated data, but not from data warehouses. This is to avoid the cost of the development and constant maintenance of the data warehouse.

3.1.13 Result in a decreased need for printing

The reporting environment should over a period of time reduce the need for users to print reports.


B301

3.1.14 Active directory type security

The reporting environment should be secured to only give access to authorised users in an “Active Directory” type fashion. A single signon allows access to only the registered services.

3.1.15 Support messaging

It would be a bonus if the reporting tools also allow for the distribution of alerts and messages to the user and stakeholder communities, based on set triggers.


B301

3.2 Reporting Dimensions

The following reporting dimensions have emerged during the process of gathering the reporting requirements. They are merely an indication of the types of dimensions used within the business and are neither conclusive nor exhaustive. Time Shift, day, week, month, year, YTD Geographical District, region, division Business activity Call handling, dispatching, and delivery Resource type Transporter, staff, facility Events Criticality - Emergency, incidents, scheduled Types - Inter hospital, medical, maternity, MV accidents, and trauma Transport types Baby in arms, stretcher, walker, wheelchair


B301

4. Management Information Requirements This section deals with the Key Performance Areas/Indicators, Dashboards, Management and Operational reporting.

4.1 KPA’s and KPI’s

Management Information is needed for the Key Performance Areas (KPA’s) of the EMS operations in the delivery of their services. Those KPA’s are monitored by means of one or a combination of Key Performance Indicators (KPI’s). Please see Annexure B for more details about the proposed Provincial and National and other possible KPA’s and KPI’s.

4.2 Dashboards

As per the features required to enable the EMS operations, various Management and Operational Dashboards are required, these are described in this section. Management should have easy access to the following types of information graphically displayed on dashboards.

Call volumes Pick-up efficiency Average call duration Events awaiting dispatching Status of dispatched calls Status of available vehicles Geographical view of events, vehicles and facilities (positions and status) View by facility Arrival board by facility Status of facilities Vehicles by type event ratio's Event trend graph by criticality

Systems administration staff should have access to a dashboard showing the health of technical environment


B301

4.3 Views/reports

Also needed are various Management and Operational reports, these are described in this section. The users need access to the following broad categories of information by entity type whether through graphs on a dashboard, enquiry screens, a portal view of an electronic report or printed reports. The requirements are stated at a high level to avoid the tendency to get lost in the specific details. The exact content detail, layout and presentation can be determined at implementation time. (1) Response

Average dispatch time Response times by criticality All calls first time response Average mission times Average on scene times

(2) Events

Audit trail by event Total incidents by category HealthNET response Mission elapse time decomposition:

o Call to dispatch o Dispatch to acknowledge o Acknowledge to scene o On scene time o Scene to hospital o At hospital

(3) Call handling

Call types by time Call trends

(4) Dispatching

Colour coded timelines Average distance between event and base station Average mission speed Breakdown of mission distances

(5) Patients/clients


B301

By surname Patients by status No of patients transported by type

o Inbound o Outbound

(6) Vehicles

Vehicle exception response times Vehicle average response times Vehicle performance reports By location Km in period No of missions Productive time Service history Exceeding set speed limits by route Accidents Due for a service Vital stats Age - 0 - 100,000km, to 200,000km, Above

(7) Staff

Attendance status Attendance history Events per crew Crew utilisation Crew performance Staff performance Skills

o BAA o AEA o ALS

Training record (8) Location

Event types by area/route/location Number of trips by route Wagon wheels from OS to scenes


B301

Wagon wheels from scenes to facilities Wagon wheels from scenes to target (15 minute) centre points

(9) Facility

Events by locality Status Services

(10) Equipment

On hand Location Status

(11) Requisites

On hand Consumption

(12) Access to Reference Documents

Standard Operating Procedures (SOP’s) Incident Protocols Treatment Protocols


B301

5. Data Interfaces or Interchanges This diagram illustrates the various solution and external data interfaces. These are described further in this section.


B301


B301

5.1 Solution Services

These data interfaces take place between the logical components of the solution. It depends on the technical solution architecture on how this will be achieved in reality. These data interfaces are shown and described to ensure that the chosen solution will indeed exchange this information. Telephone communication There is a requirement for the application to have information about the call and are able to redial dropped calls.

From: Call data To: Call request to redial dropped calls To and from: Messaging with clients

Radio communication The radio communication solution is a vital part in getting information from the application (control centre) to the MDT’s (Response units) and back.

To: Call request To and from: Messaging From: Status, acknowledgement From: Location

Vehicle tracking It is important for the operational efficiency and effectiveness that the location of all response units and known to the control centre.

From: Location and status

5.2 External services

These data interfaces take place between the solution and external services. Medical Aid When a patient requires medical services we need to establish his medical fund status to determine the appropriate medical facility to which we should transport her.

To: Member id From: Eligible facilities and services

Healthcare facility


B301

When we get to a Healthcare facility we need to provide them with patient and medical information. Once he has undergone evaluation a treatment we would like to get feedback on his condition.

To: Patient handover details From: Prognostic treatment

Telecoms SP It is vitally important to us to identify the location of the caller. By law the tele/cellphone providers are obliged to provide this information to us.

To: Caller no From: Caller location (Street name and number or GPS co-ordinates)

External call centres A significant number of our calls come to us through other emergency call centres. We need elegant ways in which to receive or transfer these calls and their related information.

From: Handover call data To: Reference no

Third party EMS We collaborate extensively with other emergency services from national departments, provincial departments and the City of Cape Town. To: Transfer call, event data

From: Transfer call, event data Traffic control Our work are very dependent on traffic conditions, we need ways to collaborate more easily with the traffic authorities.

To: GPS location to reset robot settings to allow safe passage to ambulances From: Selective video feed from them on request for major incidents only


B301

Annexure A: Data Entities

The following business entities have been identified. 1. Map Description: A map is grouping of data related to places and routes/roads connecting them. Usually this kind of information is best kept and displayed as a map showing all the places within an area and all the routes or roads available for road transport. These maps can be bought from map providers. They are regularly updated to show the latest changes. Relationship: Locations, routes and route legs are related to maps as described. Example: A map of a suburb will show all the roads and how they relate to one another. On the map landmarks can also be identified. 2. Location Description: A location is a place with a physical address a spatial point that can be indicated as GPS co-ordinates. In the context of EMS the entire operation is dependent on knowing and visualising the location of various elements of the business operation. To name just a few; the location of the response unit, event, Healthcare facility are vitally important to complete one event successfully. Relationship: Routes and route legs relate to a location, while locations relate to a map. Example:

A street address like no 12 Vergesig Road, Eversdal or GPS: 33° 51’ 02.00’’ S, 18° 41’ 18.60’’ E.

3. Route leg Description: A route leg is a specific portion of a route. To travel between two locations it is common practice to describe the route by breaking it up into logical sections. Usually a route leg is from a significant junction to another. Because routes are seldom identical, but route legs are more commonly used, standard travel times can best be expressed and tracked by route leg. Relationship: Routes are made up of one or more route legs. Example: From intersection of Old Oak and Durban Road to intersection of Durban Road and Wellington Road.


B301

4. Route Description: A route is the description of the roads that will take you from one location to another. As described above the route are often broken down into a number of route legs. It is quite possible that the sum of the route legs down make up the total of the distance to be travelled as certain portions of the route, especially at the start and end of the route are not parts of the recognised route legs. Relationship: A scheduled trip comprise of routes with their respective route legs. Example: Trip from Caledon to Tygerberg Hospital. 5. Schedule Description: A schedule is a timetable for a number of trips that needs to be done in order to collect and deliver patients for medical care. Relationship: A schedule comprise of several routes that needs to be travelled in a time period. One such a trip is also regarded as an event where several patients will be transported. Example: On Monday morning at 9:00 am the 7th December 2009 12 patients will be collected in Bredasdorp at the Spar pickup point Cnr. Jan Pienaar and Sarel Cronje Streets and transported to Tygerberg Hospital. 6. Event Description: We have chosen a collective word “event” to cover all calls that result in a transportation of a patient. An event is the most central entity. Almost every thing else revolves around an event. Relationship: An event usually requires a response unit to attend to it. Calls usually give rise to events. Incidents and patient emergencies are events. Almost every event will have a patient associated with it. An event can be a scheduled transport of a patient. Example: An incident of a motor vehicle accident on the N1 involving one patient that requires emergency medical services. 7. Transport type Description:


B301

Response units come in different types suited specifically for the job at hand. Patients can be transported by fixed wing aircraft, helicopter, ambulance or bus depending on the circumstances. Relationship: Each transporter belongs to a transport type. Example: Advance Life Support (ALS) Ambulance with two stretchers. 8. Transporter Description: A transporter is the unit in the fleet of available transport vehicles. Relationship: When called upon to undertake a mission a transporter become a response unit. Example: Ambulance A85 9. Equipment Description: Specialised equipment, like an incubator, is often needed in the rescue operations. Relationship: Such equipment is associated with a response unit when it is taken onboard for a rescue mission. Example: Incubator #1463 10. Response Unit Description: When one of the transporters is called upon to undertake a mission it becomes a response unit. This could be an EMS controlled Transporter or might be a 3rd party emergency services transporter. Relationship: A response unit has a crew that mans it consisting of trained persons. The response unit is related to the mission it undertakes. Example: Ambulance A85 with Incubator #1463 manned by Driver Jan Schwartz and Paramedic John Black. 11. Person Type Description: Persons are classified by the training they had and the work they do. Relationship: Each person has a person type Example: A paramedic


B301

12. Squad Description: A number of persons make up a squad Relationship: A number of persons form a squad for a shift. Example: Cape Town Metropole Northern Division afternoon shift. 13. Person Description: A person is a trained employee of the EMS organisation. Relationship: A selection of skilled persons makes up a squad that crew a shifts response units. Example: Joe Pietersen 14. Registered Caller Description: Some patients require emergency support on a regular basis. They are registered patients. Relationship: Registered patients are also callers that make calls. Example: Maxie Cupido, an acute and chronic asthma sufferer 15. Caller Description: Each person that calls an emergency service centre is a Caller. Relationship: All callers have made calls in connection to an event. Example: Maxie Cupido. 16. Call Description: A call is a voice conversation or a message from a caller for medical transportation assistance. Relationship:


B301

Callers make calls about events. Example: Maxie Cupido called for assistance on the 15th November at 12:05 from 021975 5555 which is at 123 Wellington Road, Durbanville. The call lasted 2 minutes 30 seconds. 17. Protocol Description: A protocol is a step-by-step list of instructions to be followed in dealing with an incident. Relationship: Protocols are required for incidents. Example: Follow protocol “1A Special Service and Multiple Casualty incidents, Motor Vehicle Accident – Persons trapped”. Do this, if this happens, then proceed as follows….. 18. Incident Description: An incident is usually a more involved situation than an event, like 3 hikers lost in the Drakenstein Mountains in winter that needs urgent medical attention and rescuing. Relationship: Incidents are a type of events. Example: The motor vehicle accident on the N1 where two persons where involved, one of the fatally injured. 19. Patient Description: Patients are persons at an incident or have an emergency medical situation that requires emergency medical assistance and transport to a healthcare facility for medical treatment. Relationship: Patients transported from events to healthcare facilities for medical treatment. Example: Maxie Cupido was transported from her house in Ottery to Groote Schuur Hospital for treatment. 20. Healthcare facility Description: A healthcare facility is typically a hospital where medical services are provided. Relationship: Patients are taken to Healthcare facilities where medical services are provided. Example: Groote Schuur Hospital.


B301

21. Healthcare Service Description: A healthcare service is a specialised medical service sometimes associated with trauma conditions. These services have a specific capacity. Relationship: Healthcare Facilities usually offer a selected number of healthcare services for which they are staffed and equipped. Example: Trauma treatment with capacity of 20 emergency patients.


B301

Annexure B: Key Performance Areas and Indicators

EMERGENCY MEDICAL SERVICES AND PATIENT TRANSPORT SERVICES PROPOSED PROVINCIAL INDICATORS STRATEGIC GOAL: To render effective and efficient pre-hospital emergency services including inter-hospital transfers and patient transport in the Western Cape.

Strategic objective

Measurable objective Performance indicator Source

‘Dashboard’

Increase the number of all responses in less than 30 minutes.

Percentage of all emergency responses in less than 30 minutes (See DB 1b)

Increase the percentage of telephone calls answered within 12 seconds to 70% by 2010.

Percentage of telephone calls answered within 12 seconds

E.C.C. DASHBOARD

(DB4)

No. of Kilometres travelled per month

No. of clients transported per month Evaluate the performance and utilization of HealthNET

No. of HealthNET cases expressed as a percentage of the total population

HEALTHNET DASHBOARD

(DB5)

No. of missions completed on the rotor-wing program - Cape Town No. of patients transported by rotor-wing - Cape Town Efficiency of rotor wing program - Cape Town (= no. of patients / no. of missions) No. of missions completed on the rotor-wing program - Oudtshoorn No. of patients transported by rotor-wing - Oudtshoorn Efficiency of rotor wing program - Oudtshoorn (= no. of patients / no. of missions) No. of missions completed on the fixed-wing program No. of Kilometres flown by the fixed - wing program

No. of patients transported - fixed-wing program

Improve response times to emergency scenes in all

areas. (Provincial)

Ensure the provision of an effective and efficient aero-medical service

Efficiency of fixed-wing program (= no. of patients / no. of missions)

AERO-MEDICAL

DASHBOARD (DB8)


B301

EMERGENCY MEDICAL SERVICES AND PATIENT TRANSPORT SERVICES PROPOSED NATIONAL INDICATORS STRATEGIC GOAL: To render effective and efficient pre-hospital emergency services including inter-hospital transfers and patient transport in the Western Cape.

Strategic objective

Measurable objective Performance indicator Source

‘Dashboard’ Total number of rostered ambulances

Rostered ambulances per 1,000 people

Percentage of hospitals with patient transporters

Average kilometres travelled per ambulance (per annum)

Provide target number of ambulances and patient transporters by 2010.

Total kilometres travelled by all ambulances

FLEET MANAGEMENT

DASHBOARD (DB6)

Percentage locally based staff with training in BAA Percentage locally based staff with training in AEA

Provide target number of appropriately trained operational emergency staff.

Percentage locally based staff with training in ALS (paramedics)

TRAINING DASHBOARD

(DB7)

Percentage of P1 calls with a response time of < 15 minutes in an urban area Percentage P1 calls with a response time of < 40 minutes in a rural area Percentage P2 calls within 30 minutes in an urban

Achieve normative response times in metro and urban areas.

Percentage of all calls with a response time within 60 minutes

P1 RESPONSE DASHBOARD

(DB 1a/b)

P2 RESPONSE DASHBOARD

(DB 2a/b)

Adhere to the prescribed staffing of ambulances.

Percentage of operational rostered ambulances with single person crews

Percentage of ambulance trips used for inter-hospital transfers Percentage of green code patients transported by ambulance

EMS emergency cases as % of total population

Cost per patient transported by ambulance

Percentage ambulances with less than 200 000 kilometres on the odometer

Number of EMS emergency cases - total

Ensure the provision of

sufficient resources for

the rendering of an effective and

efficient emergency and

patient transport service.

Ensure the effective and efficient utilisation of resources.

EMS referral cases

P1 MISSIONS DASHBOARD

(DB 3)


B301

KPA’s The following additional Key Performance Areas (KPA’s) could be identified as possible areas of focus:

(1) Optimal and dynamic re-positioning of Ambulance bases and staging points (2) Finding optimal routes for patient transport, quick, safe and convenient (3) Optimising the transport schedules (4) Having enough of the right vehicles to service the medical needs of patients (5) Optimising the availability of skilled crews to man the available vehicles (6) Availability of skilled staff to form the crews (7) Ensuring that Critical equipment is available when required (8) Knowing at all times where all the available vehicles are and their status (9) Knowing the right location of the reported event

(10) Knowing the medical emergency of each event (11) Knowing the shortest route to the event location (12) Keeping control at all times on all open events (13) Knowing the status of the closest available medical facilities (14) Knowing the correct medical protocols to follow (15) Matching resources to the changing event rates (16) Inputs to the optimal placement of future public medical facilities (17) Inputs into the moving of medical services closer to where the patients in need are

Please note that these KPA’s are merely an indication of the operational aspects that could be considered as areas of focus.


B301

KPI’s The following Key Performance Indicators (KPI’s) have been identified as some of measure that can be used to evaluate performance: (1) Optimal usage of resources Vehicles

Emergencies Vehicles per emergency events Vehicles per population

Incidents Vehicles per incidents

Scheduled Actual vs. scheduled missions

Crews % of on duty time engaged on missions Average hours on duty per week % of operational rostered ambulances with crews

(2) Call pick-up efficiency

% of calls within target time Dropped calls below target

(3) Mission efficiency

Emergencies % of urban missions within target % of rural missions within target % of missions over target

Incidents % of urban missions within target % of incidents within target

Scheduled Deviation from estimated time of arrival % of scheduled patients transported

(4) Transport efficiency

Emergencies Total mission time as % of total available time % green code patients transported by ambulance


B301

% of ambulance trips used for inter hospital transfers Incidents

Total mission time as % of total available time Average mission kilos

Scheduled Travelled vs. Route distances No of clients transported/Km Clients as % of population

(5) Cost per mission

Emergencies Cost per patient transported by ambulance

Incidents Average cost per incident

Scheduled Cost per patient transported by HealthNET

Please note that this list is not intended to be prescriptive nor exhaustive. It merely serves as a point of departure for the kinds of measurements available to track the performance of some of the operational activities. It is expected that the solution will have a number of KPI reports, but that workshops will be required to evaluate these, customise some and to specify new views/reports.