Time Synchronization in Emergency Response Time Measurement

F. Jordan Srour

and Nabil Georges Badr

Department of Information Technology and Operations Management, Adnan Kassar School of Business,

Lebanese American University, Beirut, Lebanon

Grenoble Graduate School of Business, Grenoble, France

Keywords:

Emergency Medical Dispatch Systems, Computer Aided Dispatch, Emergency Response Times, Time Data,

Time Synchronization.

Abstract:

Emergency response time reporting requires data provided by multiple systems. Whenever more than one

system produces a time stamp, issues of time synchronization across systems manifest. As emergency response

time targets are often short (8 minutes or less) and critical to public perceptions of service, errors in reporting

these times are unacceptable. This article seeks to quantify the probability and magnitude of such errors

through an empirical study of one emergency medical dispatch system.

1 INTRODUCTION

One needs only to “google” the expression “ambu-

lance response times” to ﬁnd a plethora of govern-

ment agency and ambulance service provider reports

on both targets for and reported performance indi-

cators of response times. The most common def-

inition for response time proffered in these reports

is: “the period between when a call is recorded at

the emergency operations center to when the ambu-

lance arrives at the patient’s address.”, see eg. (New

South Wales Government, 2016; The Capital Region

of Denmark, 2016; Manitoba Canada, 2016). Im-

mediately striking in this deﬁnition is the implicit

recognition that at least two information system com-

ponents must interface to yield an accurate response

time – the operations center call recording system and

the mobile, ﬁeld reporting unit on-board the ambu-

lance specifying arrival to the scene. The potential

for time synchronization issues increases with each

additional information and communication technol-

ogy (ICT) that must interface in a system. This pa-

per examines the response time data from a computer

aided dispatch system with the aim of quantifying the

prevalence of time synchronization data errors in the

measurement of emergency response times.

The paper begins with a short review covering

emergency response time targets and computing stan-

dards on time data recording and synchronization.

Section 3 describes the case study setting. Sections

4 and 5 present the results and a conclusion with di-

rectives for improved time data management in emer-

gency medical dispatch (EMD) systems.

2 BACKGROUND

Emergency response time targets, while highly dis-

puted in the literature (Pons and Markovchick, 2002;

Pons et al., 2005; Blackwell et al., 2009; Wilde,

2013), are still considered the standard against which

ambulance services are measured. One of the most

prevalent targets is an 8-minute response time. The

National Health Service of the United Kingdom spec-

iﬁes that 75% of all top priority (Red level) calls

should be responded to within 8 minutes; for less ur-

gent calls the standard requires response within 19

minutes for 95% of all calls (Wankhade, 2011). Vi-

olations of response time service level standards can,

in some locations, lead to the revocation of ambulance

operating licenses (Clark County, IN, USA, 2014).

Despite these standards there is still wide variation

in ambulance response times. Much of this variance

can be attributed to the different systems of garner-

ing and reporting such data. This issue is not par-

ticular to the UK, in a June 2015 article on the EMS

World website, Dr. Bruce Moeller notes that “Time is

easy to measure – response times are not.” He con-

tinues by noting that a study in Florida found nine

different deﬁnitions of response time in use. Inter-

estingly, Dr. Moeller concludes that Pinellas County

overcame this problem for the 19 providers in their

Srour F. and Badr N.

Time Synchronization in Emergency Response Time Measurement.

DOI: 10.5220/0006096001990204

In Proceedings of the 10th International Joint Conference on Biomedical Engineering Systems and Technologies (BIOSTEC 2017), pages 199-204

ISBN: 978-989-758-213-4

199

system by using a regional computer-aided dispatch

(CAD) system and a ﬁxed deﬁnition of response time

as the time from agency dispatch until arrival on scene

(EMS World, 2015). This implies that the two requi-

site time stamps recorded by the CAD are considered

completely accurate. While there is some basis for

this assumption of accuracy as reported in a 1997 arti-

cle on measuring response intervals in a 911 dispatch

system, current time format standards have changed

since that time (Campbell et al., 1997).

The International Organization for Standardiza-

tion’s standard ISO 8601 speciﬁes a complete set of

date and time formats (ISO, 2004). This standard

is based on the Gregorian calendar and is ﬂexible in

that it allows one to represent time as both calendar

dates and as ordinal dates. The standard also speci-

ﬁes a representation protocol for time zones – again

with ﬂexibility as one can specify local time, univer-

sal time, or an offset from universal time. Finally,

ISO 8601 allows for the representation of time inter-

vals as well. Of course, any standard as ﬂexible as the

ISO 8601 can also lead to complexity when used in

speciﬁc settings. To that end, the Internet Engineer-

ing Task Force approved RFC 3339 which simpliﬁes

time stamp notation for Internet use limiting the for-

mat to yyyy-mm-ddThh:mm:ssZ or +/-hh:mm, where

y stands for year, m for month, d for day, T is a char-

acter separating date from time, h stands for hour, m

for minutes, and s for seconds; the Z is for universal

(or Zulu) time or one can specify an offset from uni-

versal time (Klyne and Newman, 2002). The World

Wide Web Consortium adopts a similar standard for

web-based time and date stamps (W3C, 1997).

With regards to EMD, the critical elements to the

time stamp standards noted above are the clear use

of the yyyy-mm-dd protocol for dates. If one ICT

within a system uses the American style yyyy-dd-mm

format while another uses the yyyy-mm-dd protocol,

then 12 days out of the year would yield reasonable

but incorrect time intervals and an additional 11 days

worth of data out of every month would yield illogi-

cally long intervals. Furthermore, specifying the time

zone is also important in emergency medical services

as changes between daylight savings time and stan-

dard time will inﬂuence the calculation of time inter-

vals that span such clock changes. If the components

of an EMD system are located in different time zones

(eg. a remote server is used to capture and time stamp

records), then having the ability to bring all times into

one zone for time calculations is critical.

Due to the relative nature of time intervals (eg. a

year may be 365 or 366 days depending on a leap

year), the ability to accurately perform time related

arithmetic is more complex than one might expect.

As response time is ultimately the difference between

two time stamps, being able to make that subtrac-

tion accurately and correctly is important. This cal-

culation is generally performed outside of the ICT or

EMD system. Nevertheless, the analytics tools that

take possession of the data in order to produce the re-

sponse time performance indicators should use state

of the art time calculation protocols such as those rec-

ommended with the lubridate package of the soft-

ware R (R Core Team, 2016; Grolemund and Wick-

ham, 2011).

Regardless of the time stamp format used, the re-

sulting response time calculation will only be as ac-

curate as the time stamps themselves. Even when

initially set accurately, real clocks will differ after

some amount of time due to clock drift or skew,

caused by clocks counting time at slightly different

rates. Thus, clock skew in a distributed system must

realize the same global time. Clock or time syn-

chronization is a central topic in computer science

and engineering that aims to coordinate otherwise in-

dependent clocks (Cristian, 1989) especially in dis-

tributed systems (Lamport, 1978). The oldest proto-

col for time synchronization in a network is the Net-

work Time Protocol (NTP) which has been under con-

tinual development and updating since 1979 (Mills

et al., 2010). The NTP works based on a hierarchical,

peer-to-peer structure of computers and servers orga-

nized into strata with the top level strata containing

a set of high-precision reference clocks. In contrast,

the Institute for Electrical and Electronics Engineers

also speciﬁes a time synchronization protocol for net-

worked measurement and control systems. Speciﬁ-

cally, the Precision Time Protocol, encapsulated in

standard, IEEE 1588, operates using a master-slave

framework with corrections for both clock offsets and

network delays (IEEE, 2008). To ensure the integrity

of time stamps within EMD systems, synchronizing

all computers to the same clocks using the same syn-

chronization protocols is a must.

The remainder of this paper uses a prototype EMD

system to understand the extent of time synchroniza-

tion related data corruption on response time data

when only limited synchronization protocols are im-

plemented.

3 CASE STUDY SYSTEM

To achieve time synchronization over the network,

our case used the NTP. As a time source, the Global

Positioning System (GPS) is used for central clock

synchronization. Although GPS time signals are ac-

curate, clock skew still introduces time stamp issues

HEALTHINF 2017 - 10th International Conference on Health Informatics

200

Figure 1: Overview of Case Study EMD.

into database records. The more computers involved

in a system, the more likely that skew will be reﬂected

in the data.

Speciﬁcally, in the emergency response system

that we studied, the call center consists of a few (6-14)

workstations taking calls and logging them into a sys-

tem. The workstations at the call center are physically

in a different location than the corresponding servers

for data entry. The workstations and data entry servers

are separated by a set of ﬁrewalls and connected via a

Virtual Private Network (VPN), these two end points

may incur delay in synchronizing their time. The sys-

tem is depicted in Figure 1.

In order to follow the process of time stamping

and its relationship to the process of time synchro-

nization, Table 1 speciﬁes the component, the time

reference to which that component is synched, and

a time stamp id associated with the component. As

shown in Table 1, at regular intervals, the applica-

tion and database servers set their clock to the ref-

erence time tS1 of the NTP Time Server. When a

user/agent logs into a workstation session, the time

stamp is reset to the Application Server time, thus at

the workstation t = tS3. When opening a new call

on the system, a key database record is created with

a time stamp of tR1 which is equal to the database

clock time at that instance, tS2. In this case, if the

server clock is skewed when the record is created, but

gets reset subsequently, then a timing error could be

introduced. As the call progresses, all statuses and

subsequent records are stamped with the workstation

time tRn as it is the workstation that initiates the data

entry request, tRn = t.

In the case study system, tRn could drift based

on the internal workstation clock. If the workstation

is not cycled at every shift, to synchronize its inter-

nal clock with the system, the absolute difference be-

tween tS3 and t will increase inducing errors in time

measurements. For example, within 5 minutes a clock

could drift 280 milliseconds. If the clock synchro-

nization occurs on a 24 hour basis, then a total of

80 seconds of drift may occur between the system

and workstation clock. As a result, time stamp er-

rors arise. These errors could manifest themselves in

“events happening in the past” (i.e. tRn < tR1 = tS2)

based on the inaccurate time stamp. Furthermore, due

to the number of computers used in creating any one

record the drift is not conﬁned to that of one computer.

As such, measuring and correcting drift from log ﬁles

is an untenable task.

4 RESULTS

The system described in Section 3 was used to mon-

itor the calls made to a nation-wide ambulance re-

sponse service between 1 January 2016 and 30 June

2016. For each call a time stamp in yyyy-mm-

ddThh:mm:ss+hh:mm format was recorded for the

time the record was created (eg. call received), the

time the mission was scheduled (eg. assigned to an

ambulance), the time the ambulance departed, the

time the ambulance arrived to the case, the time the

ambulance departed the case, the time the ambulance

arrived to the transport destination, the time the mis-

sion was deemed complete, and the time the ambu-

lance was available for service again. For the pur-

pose of this study, we are interested only in the ﬁrst

four time stamps as these are the time stamps required

to calculate ambulance response time following the

commonly used deﬁnitions of response time – divided

into the three intervals: record created to scheduled;

call scheduled to ambulance departure; and time from

departure to arrival at the case.

Within the six month study period a total of

35,527 calls were recorded. In February, a data ex-

traction error led to the rounding of the time data to

exclude the seconds. As such, the data from Febru-

ary were excluded yielding a total of 29,606 records.

Of these calls, any record with any of the ﬁrst four

time stamps missing was excluded. Of note is the fact

that no records were missing an entry for the created

on time stamp; 102 records were missing the mission

scheduled time stamp; 1039 were missing the ambu-

lance departure time stamp; and 4450 records were

missing the arrival to case time stamp. Each of the

three time stamp types with missing entries requires

that the ambulance crew report the time back to the

dispatch center; when the crew fails to report the time,

then the entry is missing. Once the records with these

missing entries were culled, the data set had 24,391

records that were considered useable for this study.

Within the 24,391 valid records, time synchro-

Time Synchronization in Emergency Response Time Measurement

201

Table 1: Time Synchronization and Flow of Time Stamps in Case Study System.

Component Time Reference Time Stamp

NTP Server Time Source (GPS) tS1

Database Server NTP Server tS2

Application Server NTP Server tS3

Workstation Session Time Stamp Application Server t set to tS3; reset at login

Database Key Record Time Stamp Database Server tR1 = tS2 at initiation of the call; ie.

when the user creates the record

Time Stamp of Remaining Records

Related to the Initial Key Record

Workstation Time tRn = t* based on workstation’s cur-

rent time

nization errors were identiﬁed on the basis of nega-

tive time progressions when moving logically through

the data. For example, if the time stamp associated

with the mission being scheduled was before the time

stamp associated with the creation of the record, then

the difference between these two time stamps would

yield negative time. Negative time intervals were con-

sidered to be a function of time synchronization is-

sues. Had these errors been ignored then the average

response time would be incorrectly reduced. Alter-

natively, if the negative intervals were accommodated

in absolute terms, the impact on the average response

time would likely show an inconsistent bias.

Of the 24,391 records, the vast majority of nega-

tive time intervals (21,716 records) occurred relative

to the mission scheduled and created on records; the

scheduled to departure interval had only 442 time syn-

chronization errors; and the departure to arrival on

scene interval had 187 time synchronization errors.

The percent of negative time interval records appor-

tioned by time interval type can be seen in Table 2.

While a time synchronization error rate of nearly 90%

for the ﬁrst interval of the response time period may

seem shocking, it is logical as the created on time

stamp is generated by the call center server while the

remaining time stamps are generated on the worksta-

tion terminals. It is these ICT component links that

are most prone to time synchronization issues.

Having identiﬁed the intervals with time synchro-

nization issues, we turn to the magnitude of those

errors. Table 3 provides a summary of the mean,

standard deviation, minimum, maximum, and ﬁrst

through third quartiles for the time synchronization

errors in seconds. The data exhibits an extreme range

within all time intervals. The maximum value within

the created to scheduled interval reﬂects an error of

24 hours. This is likely due to poor synchronization

between computers at the moment of the change from

standard time to daylight savings time. Despite the

extreme tail within the distribution of time synchro-

nization errors, 75% of all errors are less than 106, 70,

and 70 seconds for the created to scheduled, sched-

uled to departure, and departure to arrival at case in-

Table 2: Percent of records with negative time intervals by

time stamp type.

Time Interval Percent of Records

with Negative Time

Created to Scheduled 89.04

Scheduled to Departure 1.81

Departure to Arrival at

Case

0.77

Time on Scene 0.57

Time to Destination 0.48

Time at Destination 0.39

Time from Mission

Complete to Unit

Available

1.05

Time from Unit Avail-

able to At Station

0.56

tervals, respectively.

5 CONCLUSIONS

The issue of proper handling of time related data is

signiﬁcant in the management of an information sys-

tem. The issue becomes even more signiﬁcant when

the time data is intended for use in time critical set-

tings such as EMD services. This paper serves to

highlight the potential magnitude of time synchro-

nization errors within a prototype EMD system.

A straight forward solution to this issue has not

yet been devised. Some initiatives have tackled algo-

rithms that may reduce clock skew (Gusella and Zatti,

1989). Other methods impose requirements of mini-

mal delays on the network and are not suitable for dis-

tributed VPN based environments (Rentel and Kunz,

2005). “Skewless” clock synchronization is still a fa-

vored research subject, but unfortunately without any

real ﬁeld implementations in the context of distributed

networks (Mallada et al., 2015). To date, the usage

of internet based time synchronization has prevailed

(Sherman and Levine, 2016). Ultimately the daunt-

ing task of keeping track of the cause-effect relations

HEALTHINF 2017 - 10th International Conference on Health Informatics

202

Table 3: Descriptive Statistics of Time Synchronization Errors in Seconds.

Time Interval n Mean Std. Dev. Min. Q1 Median Q3 Max.

Created to Scheduled 21,716 92 927 1 46 70 106 86102

Scheduled to Departure 442 586 5819 1 17 37 70 86400

Departure to Arrival at Case 187 646 3645 1 15 30 70 40534

Table 4: Summary of errors found in study – their sources and recommended solutions.

Source of Error Error Recommendation

Human Inconsistent time formats Time formats should be decided on

prior to implementation and used

consistently in both time stamping

and data extraction scripts.

Human Time rounding Rounding of seconds should never

be done in a time critical environ-

ment.

Human Adherence to time synchronization

protocols

Establish work checklists that en-

sure regular checking and synchro-

nization of clocks.

Design Large intervals between synchro-

nization lead to signiﬁcant clock

drift

Time synchronization should be in-

voked every ﬁve minutes as opposed

to every 24 hours.

Design VPNs over long distances can intro-

duce clock drift as a result of latency

Components of an EMD system

should be co-located on a fast local

network.

System Misuse of time formats Ensure that all computers are set

to produce time stamps follow-

ing standard protocols: yyyy-mm-

ddThh:mm:ss+/-hh:mm

System Mishandling of time changes due to

inter-location differences, daylight

savings time regulations, and leap

years

Ensure that the offset from universal

time is properly set and maintained

across all system components.

among different data manipulations continues to oc-

cupy engineers and scientists who seek to develop a

way to increase the accuracy of time tracking in dis-

tributed systems (Bravo et al., 2015).

At a minimum, a set of primary recommendations

for EMD systems emerge from this research. A sum-

mary of the time related errors encountered in this

research and the corresponding recommendations are

listed in Table 4. These recommendations are critical

as many response time targets are on the order of sec-

onds, but time synchronization related problems can

yield errors that are on the order of minutes.

This study is not without limitations. The time

synchronization errors studied in this paper were

found by identifying time intervals with “negative”

time. Thus, the errors reported here potentially re-

ﬂect only half of the errors actually present in the data.

Unfortunately, it is impossible to identify time inter-

val related errors when the intervals reﬂect a logical

progression within time.

Furthermore, the results are based on a system for

which limited time synchronization was performed in

order to yield a worst case analysis scenario. Future

work includes studying the same system after the rec-

ommendations noted in Table 4 have been adopted.

Subsequent studies should also seek to sample from

multiple dispatch systems in operation with different

conﬁgurations in order to determine a realistic range

of potential time related errors.

ACKNOWLEDGEMENTS

The authors gratefully acknowledge the Lebanese

Red Cross for their interpretation of and comments

on the ﬁndings in this paper.

Time Synchronization in Emergency Response Time Measurement

203

REFERENCES

Blackwell, T. H., Kline, J. A., Willis, J. J., and Hicks, G. M.

(2009). Lack of association between prehospital re-

sponse times and patient outcomes. Prehospital Emer-

gency Care, 13(4):444–450.

Bravo, M., Diegues, N., Zeng, J., Romano, P., and Ro-

drigues, L. E. (2015). On the use of clocks to en-

force consistency in the cloud. IEEE Data Eng. Bull.,

38(1):18–31.

Campbell, J. P., Gridley, T. S., and Muelleman, R. L. (1997).

Measuring response intervals in a system with a 911

primary and an emergency medical services secondary

public safety answering point. Annals of Emergency

Medicine, 29(4):492 – 496.

Clark County, IN, USA (2014).

Public safety plan ordinance.

http://www.clarkhealth.net/pdf/public safety plan

ordinance adopted 1-2014.pdf.

Cristian, F. (1989). Probabilistic clock synchronization.

Distributed Computing, 3(3):146–158.

EMS World (2015). Should response

time be a performance indicator?

http://www.emsworld.com/article/12071652/response-

time-expert-opinions.

Grolemund, G. and Wickham, H. (2011). Dates and times

made easy with lubridate. Journal of Statistical Soft-

ware, 40(3):1–25.

Gusella, R. and Zatti, S. (1989). The accuracy of the clock

synchronization achieved by tempo in berkeley unix

4.3bsd. IEEE Trans. Softw. Eng., 15(7):847–853.

IEEE (2008). 1588-2008 - ieee standard for a precision

clock synchronization protocol for networked mea-

surement and control systems. Standard ieee 1588,

Institute for Electrical and Electronics Engineers.

ISO (2004). Data elements and interchange formats – in-

formation interchange – representation of dates and

times. Standard ISO 8601:2004(E) 01.140.03, In-

ternational Organization for Standardization, Geneva,

Switzerland.

Klyne, G. and Newman, C. (2002). Date and time on the

internet: Timestamps. Standard rfc 3339, Internet En-

gineering Taskforce.

Lamport, L. (1978). Time, clocks, and the ordering

of events in a distributed system. Commun. ACM,

21(7):558–565.

Mallada, E., Meng, X., Hack, M., Zhang, L., and Tang,

A. (2015). Skewless network clock synchronization

without discontinuity: Convergence and performance.

IEEE/ACM Transactions on Networking, 23(5):1619–

1633.

Manitoba Canada (2016). Statisti-

cal and response time information.

http://www.gov.mb.ca/health/ems/stats.html.

Mills, D., Martin, J., Burbank, J., and Kasch, W. (2010).

Network time protocol version 4: Protocal and algo-

rithms speciﬁcation. Standard rfc 5905, Internet En-

gineering Taskforce.

New South Wales Government (2016). Response

times. http://www.ambulance.nsw.gov.au/Our-

Performance/response-times.html.

Pons, P. T., Haukoos, J. S., Bludworth, W., Cribley, T., Pons,

K. A., and Markovchick, V. J. (2005). Paramedic re-

sponse time: does it affect patient survival? Academic

Emergency Medicine, 12(7):594–600.

Pons, P. T. and Markovchick, V. J. (2002). Eight minutes

or less: does the ambulance response time guideline

impact trauma patient outcome? The Journal of emer-

gency medicine, 23(1):43–48.

R Core Team (2016). R: A Language and Environment for

Statistical Computing. R Foundation for Statistical

Computing, Vienna, Austria.

Rentel, C. H. and Kunz, T. (2005). A clock-sampling mu-

tual network time-synchronization algorithm for wire-

less ad hoc networks. In IEEE Wireless Communi-

cations and Networking Conference, 2005, volume 1,

pages 638–644. IEEE.

Sherman, J. A. and Levine, J. (2016). Usage analysis of

the nist internet time service. Journal of Research of

the National Institute of Standards and Technology,

121:33.

The Capital Region of Denmark

(2016). Ambulance response times.

https://www.regionh.dk/english/Healthcare-

Services/Emergency-Medical-Services/Copenhagen-

Emergency-medical-services/Pages/Ambulance-

response-times.aspx.

W3C (1997). Date and time formats. Standard, World Wide

Web Consortium.

Wankhade, P. (2011). Performance measurement and the

uk emergency ambulance service: Unintended con-

sequences of the ambulance response time targets.

International Journal of Public Sector Management,

24(5):384–402.

Wilde, E. T. (2013). Do emergency medical system re-

sponse times matter for health outcomes? Health eco-

nomics, 22(7):790–806.

HEALTHINF 2017 - 10th International Conference on Health Informatics

204