b301 information requirements v1.1 - western cape
TRANSCRIPT
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 1 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
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 2 of 29
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.
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 3 of 29
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
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 4 of 29
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
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 5 of 29
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.
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 6 of 29
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.
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 7 of 29
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.
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 8 of 29
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.
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 9 of 29
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.
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 10 of 29
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
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 11 of 29
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
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 12 of 29
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
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 13 of 29
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
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 14 of 29
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
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 15 of 29
B301
5. Data Interfaces or Interchanges This diagram illustrates the various solution and external data interfaces. These are described further in this section.
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 16 of 29
B301
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 17 of 29
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
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 18 of 29
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
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 19 of 29
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.
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 20 of 29
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:
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 21 of 29
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
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 22 of 29
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:
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 23 of 29
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.
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 24 of 29
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.
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 25 of 29
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)
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 26 of 29
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)
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 27 of 29
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.
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 28 of 29
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
Document: B301 Information Requirements V1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential Page 29 of 29
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.