EDMG541Wk3

Koenig_and_Schultz_s_Disaster_Medicine_Ch_25.pdf

Patient Identification and Tracking

Darlene A. Gidley and Michael Ciraolo

OVERVIEW

Each year, many countries experience disasters including earth- quakes, floods, fires, storms, and tornadoes, among others. These disasters vary in scope and magnitude and help shape the field of disaster management across these countries. Disaster planning previously based on limited experience and supposition is transi- tioning to planning based on evidence acquired from these actual catastrophic events. For the United States, at the time of this writ- ing, the event that has most tested preparedness, response, and recovery is Hurricane Katrina along the Gulf coast in 2005. Hur- ricane Katrina provided disaster planners with first-hand experi- ence in the challenges that arise after a major disaster that destroys significant infrastructure components of multiple communities.

One of the key issues illustrated by the study of Hurricane Katrina is that families and loved ones can and do get separated. In some instances, rescue workers sought to transport children to safety first, expecting that they would be reunited with parents within a brief period of time. Instead, confusion arose as to who was taken to which shelter. The same held true for hospitals evac- uating patients or transferring patients to other locations. This created as much, or more, anxiety among hurricane victims than the destruction and loss of their property. As one news agency reported, “A centralized patient-tracking system did not exist. Without automated systems, it was almost impossible to know where evacuees were. Also, the federal government did not have a firm grasp on how many evacuees there were, and family reunifi- cation was difficult. . . . Data was spotty at command centers that state officials and organizations like the Red Cross set up.”1

The National Center for Missing and Exploited Children estimated that approximately 5,000 young people were reported missing or displaced. Concerned parents did not know which agencies to contact for assistance in locating their children. No registry was automatically assigned the responsibility of reuni- fying families. In some cases, children were separated from their families for months before they were reunited.2

Hurricane Katrina destroyed much of the New Orleans healthcare system. Hospitals and skilled nursing facilities were damaged and thousands of doctors, nurses, and other health- care workers were displaced. People lost access to their primary

healthcare providers. This particularly impacted individuals with acute exacerbations of chronic conditions. According to U.S. gov- ernment officials, 2,500 patients in Orleans Parish alone were evacuated.3 In addition, dialysis centers across Louisiana with caseloads of between 3,000 and 3,500 patients were destroyed, and only half of these patients could be located several weeks after the storm made landfall.4

Identifying a patient’s location may be very difficult, if not impossible, immediately after a major mass casualty event or dis- aster occurs. Most sick or injured persons will triage themselves to the closest healthcare facility with which they are familiar, particularly if the disaster is widespread and it is not possible to phone for emergency assistance. For large events in single loca- tions, it is more likely that victims will be triaged by emergency medical services (EMS) first responders. In this case, multiple first responder agencies may be involved, large numbers of ambu- lances from various companies (and possibly other jurisdictional areas) may be on scene, buses may be used, and many receiving hospitals may be utilized. Although each entity will probably document the care they provide, there may not be a single entity that amasses all patient encounter data in real time.

For typical emergencies requiring EMS assistance, determin- ing a patient’s location is generally not difficult. Communications systems exist – in one form or another – that allow EMS field personnel to notify receiving hospitals of a patient’s impending arrival. Although patient names are not communicated over the radio or telephone, determining where an individual was trans- ported may only require a phone call to the area’s EMS provider. Furthermore, under most circumstances, the following condi- tions exist

■ Family members, friends, or colleagues are often with the sick/injured person and field personnel advise them as to the receiving hospital

■ Individuals can call family/friends and inform them of their location

■ Hospital personnel can notify next-of-kin when the patient arrives and patient information is obtained

■ The receiving hospital is not likely to transfer the patient to another facility, but if a secondary transfer is

377 Koenig and Schultz's Disaster Medicine : Comprehensive Principles and Practices, edited by Kristi L. Koenig, and Carl H. Schultz, Cambridge University Press, 2009. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/apus/detail.action?docID=564432. Created from apus on 2018-03-08 07:38:16.

C op

yr ig

ht ©

2 00

9. C

am br

id ge

U ni

ve rs

ity P

re ss

. A ll

rig ht

s re

se rv

ed .

378 ■ DA R L E N E A. GI D L EY A N D MI C H A E L CI R AO LO

necessary, detailed information is maintained by the sending facility

■ The incident location is known ■ The telecommunications infrastructure is functional

This relatively informal system for tracking (finding) a patient seems to work sufficiently well, even in large cities and counties. As the number of patients, EMS response agencies, transport units, paramedic base hospitals, and receiving hospi- tals increases, however, the chances of losing track of patients also increases.

In a disaster, a number of factors are altered that make it difficult, if not impossible, to utilize the day-to-day informal system. Consider an earthquake scenario as an example

■ A large number of injuries and fatalities may occur, instantly stressing or exceeding capacity of the emergency medical system

■ Hospitals are not getting detailed (if any) information about the patients they are receiving

■ There are multiple incident locations ■ There are multiple jurisdictional EMS providers converging

into the affected region to provide mutual aid ■ Sick/injured patients may depart the incident location, leav-

ing EMS personnel with no record of the patient’s origin or destination

■ EMS personnel may transport patients to alternate care sites rather than hospitals

■ Family members may be unable to contact one another because of telephone/cellular site failure

■ Medical receiving centers may be too overwhelmed to com- municate patient location information to family members (at least in the immediate aftermath) or the telephone/cellular system may be inoperable or overloaded

■ Hospital facilities may themselves be damaged and undergo- ing their own patient evacuations

■ Medical records of patients treated and released may not be complete and computer systems might be inoperable

■ It may be necessary to transfer patients to medical receiving centers in other cities/counties/states/countries, depending on the magnitude of the disaster

Several victim-tracking systems designed for different popula- tions are in various stages of development with the common goal to ensure the timely reunification of family members following a disaster. A notable system is found on the American Red Cross’ “Safe and Well” website, which allows individuals to register themselves on the Internet.5 The U.S. National Disaster Medical System (NDMS) uses a system referred to as TRAC2ES, which tracks patients who are transferred to various NDMS hospitals throughout the country. U.S. EMS systems are exploring options for tracking sick and injured patients that would not be in the Safe and Well or TRAC2ES databases.6 This chapter will focus on the considerations that should be given for tracking victims who are not already easily located and identified through existing systems.

CURRENT STATE OF THE ART

Components of a Patient-tracking System

There are two components of a patient-tracking system. The first part is the initial collection of data and entry into a system. This

could occur at the incident site where the EMS first responders record the data or at a healthcare facility or other alternate care site. The second component is the data portal that will receive, aggregate, and disseminate data that EMS or healthcare person- nel collect.

In selecting or designing each component of a patient- tracking system, the following factors should be considered.

■ For what groups is the “system” being designed? Is it strictly a local system, or is it meant to collect and share data with multiple communities, the state, national, or international levels? Who are the stakeholders?

■ What local systems (if any) are already in place? Are these systems compatible with others that exist within the larger jurisdictional area?

■ What information does the jurisdictional area deem critical? What are the basic data elements that must be collected and what are the additional elements that are desirable but not mandatory?

■ What are the budget constraints?

System design should also consider the following functions.

■ Provide a unique identifier for every patient entered into the system. (An approach is needed to prevent using the same unique patient identifier twice. The main approaches are to use location-specific accession numbering or to develop unique patient identifiers based on a combination of patient- specific data, such as date of birth, name, and sex.)

■ Use a process of tagging or affixing the unique identifier to each patient so it is easily displayed.

■ Collect at least some, if not all, of the following patient data: last name, first name, date of birth, sex, race/ethnicity, unique identifier number, triage tag number (Figure 25.1), social security number or equivalent, home address, and phone numbers (e.g., mobile, home).

■ Track patients lacking complete identification information (e.g., unconscious female without her wallet).

■ Enter patient data at multiple points in the sequence of care (i.e., the EMS response; field assessment and treatment sites; field triage; emergency department triage; inpatient wards and units; intermediate care facilities; postdischarge; and medical examiner/mortuary care).

■ Enter patient status data, which could include time-stamped triage status, time-stamped location, and time-stamped patient disposition (with the ability to track sequential locations).

■ Update patient status data by multiple users, while preserving previously entered data unchanged.

■ Plan disposition for patients. ■ Capture additional patient status data such as Glasgow Coma

Scale score, chief complaint, or baseline vital signs (desirable but not required).

■ Track multiple patients at multiple locations for multi- ple incidents simultaneously without compromising data integrity or system performance.

■ Update and view the same data at multiple locations simul- taneously.

■ Perform inquiries using multiple parameters, such as searches for individual patients, all records of patients with specific characteristics, and all records of patients at specific locations.

Koenig and Schultz's Disaster Medicine : Comprehensive Principles and Practices, edited by Kristi L. Koenig, and Carl H. Schultz, Cambridge University Press, 2009. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/apus/detail.action?docID=564432. Created from apus on 2018-03-08 07:38:16.

C op

yr ig

ht ©

2 00

9. C

am br

id ge

U ni

ve rs

ity P

re ss

. A ll

rig ht

s re

se rv

ed .

PAT I E N T ID E N T I F I C AT I O N A N D TR AC K I N G ■ 379

Figure 25.1. Original triage tag, with unique numeric identifier but no barcode. Copyright California Fire Chiefs Association. Reprinted with permission. See color plate.

■ Allow users at multiple locations to view data in real-time (to the extent that real-time data are entered).

■ Protect the privacy and confidentiality of patient data, in compliance with the health authority requirement, for exam- ple, in the U.S., the government’s Health Insurance Portability and Accountability Act guidelines.7

■ Secure data (e.g., with password protection and encryption) on any device where protected patient information is stored. ■ Any system relying on radio transmission, regardless

of active or passive technology, must protect against threats to data interception, such as radiofrequency iden- tification (RFID) “skimming.” This practice involves the unauthorized use of a radiofrequency identification reader to interrogate any RFID chips in the vicinity, with the goal of recovering data from these elements. RFID devices are used as triage tags and contain patient-specific data.

■ Patient information stored on laptop computers must contain provisions to secure data against information theft should the laptop be stolen (e.g., encryption within the database).

■ Ensure that all data collected by the system are handled and stored in a manner that protects them from corruption, even when the system is deployed in rugged, primitive field condi- tions. (Any system relying on radio transmission, regardless of active or passive technology, must protect against threats to data manipulation or corruption).

■ Comply with health applicable authority standards, for example, in the U.S. the capability of managing data for at least 500 patients per million population per the U.S. Department of Health and Human Services guidelines for mass casualty care.

■ Maintain the ability to export data in a common industry format, such as .csv or HL-7.

Who Should Be Included in a Patient-tracking System

Although an ideal system would track all patients who present to a medical facility following a disaster, this may be impractical because of the burden of data entry. From a pragmatic stand- point, the most important patients to track would be those who might otherwise be difficult for families to locate following a disaster. If however, government officials or researchers want to use the tracking system for quantifying the medical effects of a disaster, this would require that all patients be entered into a data system. Essential elements of a national, statewide, or regional patient-tracking system include all patients

■ transported via the EMS system to a hospital or other medical treatment site

■ admitted to a hospital who had illnesses/injuries/medical conditions that were a direct or indirect result of the disaster

■ receiving care at a field treatment site ■ evacuated from a hospital or skilled nursing facility

C op

yr ig

ht ©

2 00

9. C

am br

id ge

U ni

ve rs

ity P

re ss

. A ll

rig ht

s re

se rv

ed .

380 ■ DA R L E N E A. GI D L EY A N D MI C H A E L CI R AO LO

Figure 25.2. Medical all risk triage tag – Note the “1-d” barcode on the front. Copy- right California Fire Chiefs Association. Reprinted with permission. See color plate.

■ transferred from one facility to another ■ received or transferred through the U.S. NDMS or equivalent

in other countries ■ who died (either on arrival to a medical treatment site or

subsequently)

Additionally, it would be desirable to include all individuals in a disaster patient-tracking system who sought medical care at a clinic. This is based on the assumption that following a disaster, clinics might provide care to patients who would normally have presented to a local hospital. From a practical standpoint, however, clinics could be operating with fewer staff members caring for excess numbers of patients and, therefore, be unable to accomplish the necessary data entry. If a new track- ing system is being implemented, it may be prudent to focus on perfecting a system that tracks more critically injured or ill patients seen at the other venues. Clinic patients could be added once a system has been thoroughly tested and perfected in exercises.

Where Data Are Entered

Every system has points of entry for patient data. Ideally, the entry point is the first place where the patient receives medical care. This could be at the incident location, at an alternate care site, clinic, or hospital. If a very basic patient-tracking system is adopted that only tracks EMS-transported patients and those patients admitted to a hospital, data entry could be initiated at the hospital site only. This would likely limit recorded patient information to data relevant to their current location only. It would not lend itself to tracking a patient’s previous locations. Within the U.S., patients treated and released, without hospital- ization, could be encouraged to register on the Red Cross’ Safe and Well website.

Some jurisdictional areas may desire a patient-tracking sys- tem with capabilities that exceed the “basics” described previ- ously. In this case, patient tracking could be initiated by EMS responders at incident locations. The tracking system could then “follow” the patient to the hospital and through discharge.

C op

yr ig

ht ©

2 00

9. C

am br

id ge

U ni

ve rs

ity P

re ss

. A ll

rig ht

s re

se rv

ed .

PAT I E N T ID E N T I F I C AT I O N A N D TR AC K I N G ■ 381

Although this would be a more comprehensive tracking system, it would require additional training and equipment.

How Data Are Entered

An initial patient record could be created by completing the infor- mation on a standardized triage tag such as the one adopted by the California Fire Chiefs Association (Figure 25.2).8 The basic patient identification information and patient location can be entered manually into a database and the barcode on the triage tag scanned. If scanning equipment is not available, staff can also manually enter the triage tag’s corresponding unique numerical identifier. This number acts as an important identifier for track- ing the patient throughout the course of hospitalization and possible secondary hospital transfers. Alternatively, a patient’s location could be physically tracked by activating an RFID tag. Although this is useful for locating a patient within a hospital or at a field treatment site, it is less effective in identifying a patient’s location in a wide geographical area.9 In addition, the cost of such a strategy is significant.

Existing systems such as EMTrack, ReddiNet, and WebPCR (already in place in California) have specific data entry require- ments and will create local databases.10,11 It is important that data do not reside solely at the local level because, in a disas- ter, patients may be transferred out of local jurisdictional areas. The challenge for local systems will be to develop a process that transfers the information from local databases (such as hos- pital sites) to a regional/state/national portal that aggregates the data and makes them available to system participants. The regional/state/national data portal must allow patient tracking by unique identifiers regardless of where they are physically located.

The Regional/State/National Data Portal

Assuming each jurisdictional area should have the flexibility to select or maintain an existing system that best meets its respective needs, then the statewide or regional (or national for smaller countries) patient-tracking system must have a secure Internet portal that can collect, aggregate, and disseminate a large amount of data from a variety of sources. One strategy is to identify and explore data systems already in place in a state or region to deter- mine whether they can be expanded to include patient tracking.

Who Performs Data Entry

A critical element to the success or failure of a patient-tracking system is the data entry itself. All systems require human inter- face. It is unrealistic to expect that healthcare providers will assign staff to data entry functions when their resources are severely stretched following a disaster. The likelihood of cooper- ation increases if the data can be easily collected, are limited in volume, and the function of data entry can be assigned to trained volunteers.12 The following are essential considerations.

1) Do not require real-time data because this would be too labor intensive. Rather, require update of information every 24 hours.

2) Limit data collection to easily obtainable information such as ■ Name ■ Sex

■ Date of birth or age ■ Most current address/telephone number ■ Present location ■ Location to which patient is being transferred (if appli-

cable) ■ Triage tag number (if available) ■ Initial diagnosis ■ Patient permission to share information with persons

seeking to find the individual13

Possible additional information could include

■ Treatment date (arrival date) ■ Status (inpatient vs. outpatient) ■ Initial diagnosis ■ Patient condition ■ Admission note ■ Date of departure from hospital ■ Disposition ■ Transportation ■ Contact information ■ Social Security number or equivalent ■ Home zip code or postal code

3) Ensure that any data entry requirements are as simple as possible so that anyone can be assigned the responsibility and perform the task with little or no training in a minimal amount of time.

4) Consider training and using hospital volunteers or members of established organizations (e.g., in the U.S., the Disaster Service Workers and the Medical Reserve Corps) to perform data entry functions to minimize the workload of already overburdened staff. Volunteer availability would likely be higher following a traumatic event than a biological or radi- ological incident, when individuals might perceive a greater risk to their personal safety.

Driven by federal mandates and the experience of hospi- tal evacuations associated with the Northridge earthquake and hurricanes Katrina and Rita, more patient-tracking systems are emerging in the U.S.14,15 This marketplace is well developed with many patient-tracking-specific vendors using proven technolo- gies, as well as veteran system integrators. There is, however, a lack of overall standardization or consolidation of vendors. Characteristics of this current marketplace include

■ A lack of standardization regarding data interchange or even basic agreement on a minimum data set (patient name and date of birth vs. social security number vs. driver’s license data vs. medical condition information and field treatment activities)

■ The strong presence of vendors with previous experience in the tagging/identification/inventory markets, as well as system integrators

■ Many vendors with few proven systems. Few fully deployed and tested patient-tracking systems exist from which to gen- erate a track record for each vendor

■ Reliance on public or nonproprietary technologies (dis- cussed later)

Overall, the science of patient tracking is in its infancy and suffers from ambiguity over the very concept of patient tracking.

C op

yr ig

ht ©

2 00

9. C

am br

id ge

U ni

ve rs

ity P

re ss

. A ll

rig ht

s re

se rv

ed .

382 ■ DA R L E N E A. GI D L EY A N D MI C H A E L CI R AO LO

As is often the case in market-driven rather than purely evidence- based initiatives, different offerings are defined by the vendor, so that one vendor’s version of patient tracking may be very different from their competitors. This underscores the impor- tance of emergency managers with purchasing authority dili- gently researching and understanding their own specific require- ments, goals, and systems issues. Government agencies have also initiated development of recommendations for patient tracking that are more evidence based, such as those found in the 2009 publication from the U.S. Agency for Healthcare Research and Quality.16

Despite a lack of standardization, there are some common components to patient-tracking systems, with shared technol- ogy platforms. Planners should consider four technology-related areas when procuring a patient-tracking system

■ The tagging, or identifying technology ■ Field data tools, both for data capture and for interfacing

between the tagging technology and a database ■ The field data communication technology (or technologies,

as many vendors use multiple infrastructures for redundant systems) by which the field data tools pass information to a database

■ A main application comprising the following: 1) a database (the “back end”); 2) some form of user interface viewable in many locations (the “front end,” typically a web-based interface); and 3) a network to link viewers of the data (typ- ically the public Internet). Additionally, consideration must be given for user access permission structures, interfaces for data exchange, disaster recovery, security, and privacy pro- tection

Tagging Approaches to tagging include triage tags with machine-

readable numbers (requiring an optical character recognition system), or more commonly, a tag that utilizes a barcode. Bar- codes have two configurations; an older generation “1-d” for- mat (familiar from most Universal Price Codes), and the newer “2-d” format (which resembles a square composed of many irregularly spaced dots). The 2-d format contains more infor- mation; it is being used on driver’s licenses in some U.S. states to capture nearly all of the information printed on the driver’s license. Barcodes may be scanned quickly, rendering data entry fast, easy, and reliable. To avoid losing them, such tags may be affixed to a patient’s wrist in a bracelet similar to those used in hospitals.

RFID devices are also being used as a means of tagging patients. These are radio transponders containing an antenna and the integrated circuitry necessary to produce identifying information (such as a tracking numbers). Automated highway toll tracking devices and inventory tags are common applica- tions, and RFIDs have already found use in healthcare. RFID sys- tems are frequently used in hospital systems for tracking assets such as supplies, pharmaceuticals, and medical devices. Similarly, RFID systems have used bracelets to monitor and track patients in settings such as nursing homes or psychiatric facilities where elopement is a potential problem. RFID technology has also been used to track the locations of personnel such as physicians and nurses.17

RFIDs have the advantage that staff can record the data they contain at a greater distance than the barcode information on a conventional triage tag (up to approximately 1 m). Their disad-

vantages include cost and the illicit tracking of RFID informa- tion, a practice called “skimming.” The cost of an RFID tag is less than $1.00 U.S. per item, but this does not compare favor- ably with the cost of paper triage tags in the range of $0.01 U.S. per item. Skimming is easily accomplished and poses significant security and privacy concerns. This unauthorized retrieval of RFID information involves the use of an RFID radio receiver and a laptop computer to capture and read available data from any RFID within range, generally for nefarious purposes. How great a risk this poses to patient-tracking systems depends on the data contained on a patient RFID tag and the extent of security and encryption for related data communications. For example, a simple RFID (containing only a patient identification number) coupled with unencrypted data sent over a marginally secure WiFi connection would pose a risk to patient privacy.

A third approach to tagging avoids assigning the random (or sequential) number of a triage tag, and instead seeks to capture information directly from the patient. At least one system uses a field barcode scanner to capture information directly from a patient’s driver’s license via optical bar code scanning. This technology is limited to use for patients who have their driver’s licenses in their immediate possession and it does not solve the challenge of tracking others who may not have readily available identification, for example, children in many countries.

Field Data Tools and Field Data Communication Field data tools must serve as data entry devices and commu-

nication devices to perform data capture and data entry. Some will also provide access to the database, acting as field command post tools. At the simplest level, these data tools must scan, read, or otherwise collect identification information (e.g., via bar code scan or receiving the RFID signal), and they must permit the addition of other supplemental data. This might include an auto- matic time stamp or manual data entry option for patient name, medical condition, or other parameters.

The technology to do this is typically a durable mobile computer equipped with the appropriate scanning device and telecommunication system, e.g., the Symbol 9000 or MC50. Originally designed for warehouse and logistics operations that include scanning barcodes or reading RFID tags and sending the data to a local computer, these devices are well adapted to the inventory-related needs of patient tracking. Durable laptops may also be used in the field for data entry, data display, and command-and-control functions.

Most of these field data collection tools rely on various pub- lic infrastructures to transmit information back to a database, and many are enabled for multiple technologies. One system, for instance, offers wireless radio communication, satellite tele- phone, and transmission over the IEEE standard 802.11 b and g (commonly known as local area “WiFi”). These systems are all quasipublic infrastructure; they may be privately owned but during a disaster will be heavily stressed. In one strategy, the city of San Francisco, California is piloting a system that uses all three modalities in a tiered approach: if unable to establish a cellular telephone or WiFi connection, then the more expensive satellite telephone call is placed. All three technologies have limitations due to their use of the radio spectrum. The problems with cellu- lar radio are familiar: dropped calls, areas where the signal does not reach, and saturation of a given cell due to overuse (a likely scenario in a disaster). WiFi – wireless access to the Internet – is far from ubiquitous. Few cities – and no rural or mountainous regions – have wide area WiFi coverage. Furthermore, availability

C op

yr ig

ht ©

2 00

9. C

am br

id ge

U ni

ve rs

ity P

re ss

. A ll

rig ht

s re

se rv

ed .

PAT I E N T ID E N T I F I C AT I O N A N D TR AC K I N G ■ 383

Assign ID Associate Patient and Items

Update Locations

Discharge

View Reports

Update Record

Start Record

STORAGE

Users Events

Patient-tracking Database

Figure 25.3. Collaborative Fusion’s Community Response System’s Patient Tracking Module architecture. This graphic details one potential patient information path through the patient- tracking system. The beginning point of the patient’s journey may vary. A patient may present to the hospital independently and the ID would be assigned there or the patient may be transported from one hospital to another and have multiple record updates. Copyright 2007, Collaborative Fusion Inc., reprinted with permission.

of WiFi in urban areas is largely due to Internet cafes and private (and often secured) WiFi hubs. The signal range in such loca- tions is 30–50 m under ideal indoor conditions. WiFi 802.11 b and g frequencies also face interference from microwave ovens, cordless telephones, and Bluetooth devices. Even as more cities become WiFi enabled, it will be necessary for most WiFi hubs to have backup power sources to be functional in a disaster that disrupts the supply of electricity.

The Application Itself Once data are collected from the patient, the information

must be communicated, stored, viewed, and probably modified. Most systems utilize standard relational databases coupled with conventional web interfaces. Thus, emergency operations staff only need access to the Internet to enter and retrieve patient- tracking data. Understanding the specific requirements of the network and how a proposed system might function are impor- tant, whether it is locally hosted in the jurisdiction or remotely hosted as part of an application service provider arrangement. Figure 25.3 provides a schematic of the architecture of Collab- orative Fusion, Inc.’s Community Response System – Patient Tracking Module, which tracks both patients and materials. Figure 25.4 provides a schematic of Salamander Technology’s MedTrax system.

Considerations include

■ The database should be an industrial-strength database from an established vendor. It should be a database designed specifically to work with the volume and data complexity appropriate to the task, thus avoiding the common problem in emergency management systems of using a small database and an individualized simplistic application to provide func-

tionality in excess of its capability. Vendors should address such issues as whether or not their future product releases will be compatible with earlier releases, management of potential software obsolescence, and availability of support.

■ The user interface should be contemporary, incorporat- ing industry standard metaphors and conventions (i.e., Microsoft Windows or other commonly used software). Indi- vidualized and small-scale systems seldom reflect in-depth usability testing, and often rely on mechanisms such as pop-up windows. Such mechanisms often trigger pop-up blockers and antispam ware. A system designed for mass casualty incidents and large-scale disasters will be used infre- quently. Therefore, it should be as easy and intuitive to use as possible. “Intuitive” usability comes not from one developer believing a system is intuitive, but from adherence to con- temporary approaches and frequent customer/user testing and feedback.

■ The network providing data interchange between the various users in the field and in operations centers is typically the Internet, but a private network can also be employed. An Internet-dependent application is, however, only as robust and reliable as the network (and the public power grid) itself. A large earthquake, hurricane, or other event can disable the Internet in a given locale.

■ User retrieval of data should be secure and should offer mul- tiple tiers of access for different levels of data. Personnel entering data do not need exposure to all system information, whereas Emergency Operations Center staff require complete access.

■ Because there are no established standards for monitoring patient location and movement, different jurisdictions are likely to adopt different patient-tracking systems. To ensure

C op

yr ig

ht ©

2 00

9. C

am br

id ge

U ni

ve rs

ity P

re ss

. A ll

rig ht

s re

se rv

ed .

384 ■ DA R L E N E A. GI D L EY A N D MI C H A E L CI R AO LO

-- SYSTEM OVERVIEW --

OFF-SCENE

BACK OFFICE

ON-SCENE

MONITORING

OF DATA

CONSOLIDATION

OF DATA

DATA CAPTURE

TAG DATA

TAG DATA CREATED

FOR 1ST RESPONDERS

Public Health Web Sites

ON-SCENE BADGING FOR VISITORS - VOLUNTEERS - EVACUEES

AND MUTUAL AID

1ST RESPONDERS ON-SCENE BADGING FOR PATIENTS

EMA/EOC Web Sites Civil Support Web Sites

COMMAND

MOBILE UNITS

Figure 25.4. Data capture is performed via handheld units capable of scanning triage tags; these units then upload data to a local laptop, where data are consolidated, viewed, and sent to off-scene users (including hospitals and command centers). Reprinted with permission. See color plate.

interoperability, mutual aid, and movement of information through the regional level to the state (and possibly federal) government, a system should be capable of importing and exporting patient-tracking data. This can be managed with an interface. It is the responsibility of jurisdictions evaluat- ing patient-tracking systems to understand both their needs and the vendors’ capabilities. Interfaces may function in real time, or in delayed “batch mode.” They may require con- siderable effort by personnel to manage the data formats or perform these functions in a fully automated way. Such specific characteristics require investigation and testing.

■ Disaster recovery and application durability (including its servers) are of paramount importance for a patient-tracking system designed to function in a wide-area disaster that threatens power and other infrastructure. Disaster recov- ery is defined as the ability of an application to function continuously during, or recover from, such threats as power interruptions, damage to primary servers, damage to disk

drives, or impairment of other system components. The hosting environment should be protected from fire, water, flooding, and unauthorized entry. This supporting infra- structure should also have access to a stand-by power system with at least enough fuel (or battery power) to last as long as the longest probable scenario for that location. At a mini- mum, this should be for a period of at least 72 hours. Ideally the application is hosted in such a way as to obviate down- time due to equipment failure; the typical approach is to use dual systems with near-instantaneous fail-over from one sys- tem to the other. Jurisdictions using an application service provider agreement should require hosting at two geograph- ically disparate data centers, with at least one removed from the operational area.

■ Security and privacy concerns are of paramount importance and extend well beyond legislative requirements such as the U.S. Health Insurance Portability and Accountability Act. Gov- ernment agency credibility for the management of patient

C op

yr ig

ht ©

2 00

9. C

am br

id ge

U ni

ve rs

ity P

re ss

. A ll

rig ht

s re

se rv

ed .

PAT I E N T ID E N T I F I C AT I O N A N D TR AC K I N G ■ 385

and personal information has been challenged by historical federal incidents. Therefore, jurisdictions should treat infor- mation security and privacy as being equally important as the basic mission-critical function of patient tracking. This means evaluating any potential system’s data management from the point of collection to the viewing by any authorized user. Essential questions that should be addressed include: 1) what data are being collected, and are patient identi- fiers (such as name, social security number or equivalent, or other patient-specific information) included? 2) Are data encrypted when transmitted over WiFi, cell phones, or over the Internet? 3) Are data encrypted when stored on a field laptop computer? 4) What kind of log-in and user authenti- cation is required to access the system? 5) Is the hosting envi- ronment physically secure? 6) Is software that connects with public infrastructures (the Internet, WiFi, cellular phones) protected with intrusion countermeasures such as virus pro- tection and is that protection updated routinely?

■ Service provisions, whether part of an application service provider or part of a purchase agreement, should be evaluated in terms of support, maintenance, and upgrades.

■ Any system used for patient tracking should be fully tested. Testing by the purchaser should include user acceptance test- ing. The purchasing jurisdiction should also require, and review the results of, failure mode analysis (what are the weak points in a given system?), stress testing (impact on system function of increasing demands, such as multiple users, high data traffic, and storage of large data volumes), and security and intrusion testing.

An evaluation tool that builds on the considerations previ- ously outlined appears in the appendix to this chapter. System acquisition processes should examine not only capabilities (can a system perform a given function?), but should also explore how functions are performed. Even more importantly, the acquisi- tion process should rely heavily on an outcomes approach, using both examinations and demonstrations of working systems at reference sites (ideally under terms and conditions dictated by the purchaser, not the vendor).

Systematization Efforts There are at least three emerging mandates and standardiza-

tion efforts within the United States that could affect patient tracking. Each involves a mix of technology issues (such as data definitions) and other factors such as funding imperatives from the federal government. The first one is a federally driven approach to hospital bed availability monitoring, which has log- ical connections to patient tracking. The second one is a data interchange format. The last one is a more comprehensive indus- try vision for healthcare information interchange. Although each is unique, all three have the potential to affect patient-tracking systems and so are important.

The first involves the U.S. Health Resources and Services Administration’s (HRSA) promulgation of requirements for cur- rent and accurate bed availability. This HRSA mandate (backed by the imperative of compliance to maintain eligibility for federal funding) does not specifically require patient tracking, but there is a natural connection between patient tracking originating in the field and bed availability. In support of these requirements for bed availability systems, the U.S. Agency for Healthcare Research and Quality funded the HavBED project – the National Hospital Available Beds for Emergencies and Disasters. The HavBED data

definitions constitute a de facto federal standard for bed avail- ability data interchange. The HavBED project also considered patient tracking. The project team concluded:

“The first question which must be answered is to deter- mine at what point the identification and tracking pro- cesses begin. The ideal answer is for this activity to be initiated at the actual incident site. Unfortunately, past experiences clearly indicate that casualties do not nec- essarily remain at a disaster scene. If they are capable of ambulating, most victims will not await the arrival of public safety agencies, including EMS, but rather will seek alternative transport modalities to obtain medical care. In fact, prior incidents suggest as many as 80% of casualties will make their own way to the hospital. There- fore, any patient identification and tracking system must be flexible and be capable of permitting data entry about recognized victims at various points in the medical treat- ment point-of-entry chain. This includes such locations as the incident scene, receiving hospitals (both near and distant) and points in-between, as patients who attempt to get to a hospital, but are unable to do so, enter the EMS or healthcare delivery system at locations remote from the actual disaster scene.

To date, all patient identification and tracking sys- tems are associated with significant cost, both financial and in personnel, for data entry. Systems such as the Raytheon Patient Tracking System partially automate the initial data entry process and provide for FedEx-style patient (package) tracking using scannable barcoded armbands. This system has significant associated fixed costs and ultimately still requires personnel to acquire and enter personal identifying data for each patient. New York State includes a less robust patient identification and status system in HERDS (Health Emergency Response Data System) for purposes of being able to track what victim is being treated at a particular hospital. This func- tions more as a patient locator system and also requires expenditures for personnel for data entry.

In the development of any patient-tracking system, decisions will also need to be made about the definition of a victim, the time frame in which they present for care and other similar issues. A consensus will need to be reached about who should be included and identified as a victim as well as how open-ended the time period will be for including victims in such a database.

In addition, for any patient identification and track- ing system to work effectively, it must either be extremely easy and intuitive to use or it must be used on a routine basis. If routinely used, on-going costs associated with such a system become an issue.

In summary, a “patient-tracking” system is currently technologically feasible, however, the implementation, sustainability and manpower costs present significant fis- cal challenges.”18

Although beds alone do not equate with patient care capac- ity, staffed and equipped beds can be considered a component. Therefore, it is useful for emergency managers to monitor HRSA mandates for bed availability tracking systems as a possible connection to patient-tracking requirements and (eventually) systems.

C op

yr ig

ht ©

2 00

9. C

am br

id ge

U ni

ve rs

ity P

re ss

. A ll

rig ht

s re

se rv

ed .

386 ■ DA R L E N E A. GI D L EY A N D MI C H A E L CI R AO LO

The second effort to improve patient tracking is a straight- forward data interchange format known as EDXL, shorthand for the Emergency Data Exchange Language. A schema-based standard for data interchange over the Internet, EDXL is a spe- cialized version of Extensible Markup Language (XML) designed to promote interoperability between different jurisdictions and different vendors. The development of EDXL is an initiative of the United States Department of Homeland Security in conjunc- tion with an industry-based consortium. Once the EDXL data definitions are accepted, interchange of patient data, jurisdiction- specific data (e.g., hospitals, transfer definitions), and incident command parameters can be easily accomplished via XML inter- faces between different vendors.19 This is important, because the easier it is for different patient-tracking system vendors to exchange information, the easier it is to implement local patient- tracking systems without being burdened by information shar- ing with neighboring jurisdictions. Government entities seek- ing patient-tracking systems might be more inclined to adopt one system, without waiting for state or federal standardization, knowing that data transfer is a relatively easily solved problem. The HavBED data schema is consistent with EDXL.20

Finally, it is worth briefly discussing Comcare’s Integrated Patient Tracking Initiative. Comcare (Comcare.org) is a 100+ member national advocacy organization in the U.S. dedicated to advancing emergency communications. The Integrated Patient Tracking Initiative (IPTI) sponsored a national patient-tracking summit to develop definitions for required components and has plans to further define optimal patient-tracking systems. The Comcare effort also showcases local patient-tracking projects, provides a directory of vendors, and is a useful source of infor- mation regarding patient tracking.21 However, the overall vision of smooth data interchange across disparate jurisdictions and vendors, all in compliance with requirements generated via Com- care’s IPTI conferences, is unlikely to reach fruition in the near future. Nonetheless, the IPTI has the potential to improve the field of patient tracking and will continue to play a role.

RECOMMENDATIONS FOR FUR THER RESEARCH

The development of a patient-tracking system is a worthwhile endeavor. Once fully implemented, it will give officials a way to locate patients, reunite families, and track general data such as the number of patients treated, their dispositions, and the types of illnesses and injuries being treated. It provides the state, region, and local jurisdictions with another tool to manage effectively a disaster.

However, patient tracking is not as simple or streamlined as tracking packages by the United Parcel Service or similar com- panies. Although it appears analogous, the United Parcel Service sends packages to its own hubs, trains its own people, uses its own transportation vehicles, and has common equipment through- out the package handling process. In contrast, in many countries, patients are treated by a myriad of healthcare providers who operate independently of each other and are not bound by com- mon data systems, training, or equipment.

There are a number of companies that are developing hard- ware and software for tracking patients. Bar-coding and RFID technology is popular but should not be considered a tracking system per se. These are simply tools that assign unique identi- fiers to patients that will help to connect various records. They do not indicate who the patients are.

For local jurisdictions that already have patient-tracking capability or are currently developing this capability, it is highly improbable that these entities would be willing to switch to entirely different systems for the sake of having a consistent approach throughout a state. Rather than requiring utilization of a specific hardware/software method for patient tracking, it is more important to ensure that systems used by local juris- dictions can gather certain data elements and that the data are entered into a common secure database that is developed and maintained by the state or equivalent entity and can be accessed by select individuals and organizations.

Also, in consideration of stakeholders that operate on a very small budget, it may not be necessary to invest in specialized equipment (e.g., scanners) for tracking patients. It is entirely feasible that a simple spreadsheet could be completed by health- care providers and sent to a secure Internet portal.

There are sophisticated patient-tracking systems available that are capable of tracking patients and capturing the data ele- ments suggested in this chapter. Even though it is technologically possible, there may be inherent challenges that may be difficult to overcome. For example

■ Implementation and maintenance costs combined with ongoing costs for training and retraining

■ Unfamiliarity of end users with devices that are not needed, or practical, to use on a daily basis

■ Battery failure; inability to obtain fresh batteries quickly in a disaster

■ Insufficient numbers of equipment devices ■ Obsolescence of equipment purchased, but not used, needing

periodic replacement ■ Complex data entry (as opposed to completion of a triage

tag) slowing down the rapid disposition of patients in the field setting

■ Data entry devices that are too labor intensive for the field setting and probably difficult to use in a moving vehicle

■ Reliance on cellular telephones, computers, and the Internet – all of which may be inoperable in the immediate aftermath of a disaster.

■ Reliance on satellite communication systems that are scarce and not used with sufficient regularity to ensure user com- petence

Another issue is that most of the patient-tracking systems being developed are designed for multicasualty events where all patients are initially located in the same incident location. At sin- gle locations, it is conceivable that barcode readers, laptop com- puters, cellular phones, and satellite capabilities may be available at a command post. Whenever a disaster is widespread over many locations, it is not likely that the specialized equipment will be available to all first responders deploying to incidents in which a command post is not established. Consequently, it is more real- istic to track only those patients who are transported via EMS to hospitals or field treatment sites as well as those patients who self-triage to these locations.

If it is accepted that each jurisdictional area should have the flexibility to select or maintain an existing system that best meets its respective needs then a statewide or regional patient- tracking system requires a secure Internet portal that can process a large amount of data from a variety of sources. Whether using high-tech or low-tech solutions for collecting patient-tracking data, it may be prudent to reduce the amount of information

C op

yr ig

ht ©

2 00

9. C

am br

id ge

U ni

ve rs

ity P

re ss

. A ll

rig ht

s re

se rv

ed .

PAT I E N T ID E N T I F I C AT I O N A N D TR AC K I N G ■ 387

being collected. This recommendation is made for the following reasons

■ The more data that is collected, the more labor-intensive is the data collection effort and the less compliant jurisdic- tions are likely to be. Following a disaster, EMS and hospitals are generally managing a higher volume of patients than at baseline. The goal should be to expedite patient care and dis- position, not create a bottleneck. (Triage tags were designed to take the place of a comprehensive patient record and to collect a succinct body of information.)

■ The more data fields required, the slower data will be trans- mitted.

■ Patients’ information should be contained in their medical care records, which should accompany them when they are transferred from one healthcare facility to another.

■ A very limited amount of data is needed to track a given patient. A good example is the Safe and Well website imple- mented by the American Red Cross. In this case the only data elements that are needed are a person’s name, current address and/or telephone number.

Even if the amount of data is reduced, the critical point estab- lishing the success of a patient-tracking system is the selection of individuals to perform data entry. Serious consideration should be given to identifying and training volunteers to handle this important function and to developing automated systems that reduce or eliminate personnel needs.

Another issue that needs clarification is the duration emer- gency managers should track patients following a disaster. This is a difficult question to answer because the recovery phase of a disaster can be prolonged, lasting for years. This point is exem- plified by Hurricane Katrina, where people were displaced for months following the storm.

All of these issues are tractable and should be the focus of in situ research efforts. Research should evaluate pilot systems during both routine and emergency use. In summary, the patient- tracking systems are widely variable from those that are simple and inexpensive (such as the manual completion of a triage tag and manual entry of a few data elements into an Internet por- tal) to a more expensive and sophisticated processes (such as use of computerized equipment that electronically sends real- time information to disaster managers and hospitals). The cost of implementation and maintenance of these systems (includ- ing personnel training) is directly correlated to their level of sophistication.

System dependability during a disaster may, in fact, be inversely proportional to the sophistication of the system being utilized. The greater the reliance on handheld computer devices, functional power supplies, telecommunications, and training, the greater is the chance for system failure. If more sophisticated systems are used, a back-up simpler system should be available. One promising sophisticated electronic system known as the Wireless Internet Information System for Medical Response in Disasters (WIISARD) is being funded in part by the National Institute of Health. This electronic network is designed for rapid implementation after a disaster and facilitates recording of med- ical data, aids in the monitoring and tracking of patients, and facilitates communication of field data to hospitals. Researchers at the Veterans Affairs Medical Center in San Diego concluded that a wireless electronic system improved documentation and tracking of triage status, changes in patient condition, treatments,

destination, and transporting units compared with a traditional paper system.22

The tracking systems currently under development have not been tested under actual disaster conditions. Nevertheless, their ongoing development and refinement should be encouraged as it is likely to improve future disaster management. The more feedback manufacturers receive from end users, the better the resulting product is likely to be.

APPENDIX A: PATIENT TRACKING VENDOR EVALUATION TOOL

Jurisdictions, EMS managers, and others evaluating the acqui- sition of a patient-tracking system should engage in a formal evaluation process. The following questions comprise an eval- uation tool that may be readily adapted to formal Request for Information or Request for Proposal formats. Vendor responses may be narrative or Yes/No/Not Apply. Vendors responding to requests for proposals typically answer “yes” to most questions. Therefore, vendors should be pressed for detailed explanations of how various tasks are accomplished, for in-person product demonstrations, and for references from current customers using the product under consideration. It is particularly important to ascertain whether vendors of patient-tracking systems can demonstrate a current working model with a given set of fea- tures. Many such vendors are system integrators only and may not have actually built a functioning entity.

1. Is your system designed for routine operational use (i.e., all the time, daily), for local mass casualty incidents, and/or for large-scale disasters?

2. Does your system provide on-site casualty entry? 3. Does your system allow initial medical assessment entry?

a. How is this done (drop-down list vs. free text; entry on a portable device vs. laptop computer)?

4. Does your system allow real-time notification and com- munication between EMS, incident command, and hos- pitals?

5. Does your system have the ability to add walk-in patients from an incident at a variety of scene locations? https:// disastersafe.redcross.org/

6. Does your system record patient age/sex? 7. Does your system have the capability of locating patients

involved in an incident? Does your system allow the identifi- cation of associated evidence or property?

8. Does your system have the capability of recording critical vital signs? How many sets? Are entries time-stamped?

9. Does your system track ambulance status and end destina- tions? How?

10. Does your system keep a record of on-scene treatment? How? (Free text, pick list, and so forth) What treatment data are supported? (Please provide a copy of a full record.)

11. Does your system record treatment status? How? (What data elements? Are they customizable?)

12. Does your system allow critical information sharing between multiple response agencies across the EMS system? How?

13. Does your system have the ability to communicate casualty and resource information to command centers and hospitals? How?

14. Does your system allow analysis of patient disposition status and flow throughout an incident to the final disposition to

C op

yr ig

ht ©

2 00

9. C

am br

id ge

U ni

ve rs

ity P

re ss

. A ll

rig ht

s re

se rv

ed .

388 ■ DA R L E N E A. GI D L EY A N D MI C H A E L CI R AO LO

allow tracking of patients across agencies and jurisdictions (e.g., city, county, and state)? If so, how is data interchange accomplished, and at what cost?

15. Does your system provide compliance with HPP-critical benchmark requirements for patient tracking? How and to what extent?

16. Is your system capable of collecting and reporting informa- tion required by the U.S. Federal Emergency Management Agency?

17. What tagging or ID technology does your system use? 18. What field data collection tool(s) does your system use? 19. What patient data does the system collect? 20. Does your system handle unidentifiable patients?

a. If so, how? b. How is accession numbering or tracking of multiple

unidentified patients from multiple locations managed? 21. Does your system allow the entry of patient information at a

variety of locations (e.g., hospital, field treatment site)? 22. How does your system track patient status? Specifically,

what patient categories are used (e.g., ambulatory, deceased, injured), and how are these categories updated?

23. How does your system identify locations, destinations, and other geographic information? Free text or controlled list?

24. How does your system handle multiple updates from multi- ple locations to the same patient data?

25. How many incidents and patients can your system accom- modate simultaneously without performance degradation?

26. How many users can use the system simultaneously without performance degradation?

27. Describe your system’s search/query functionality. 28. Can your system function in the field? With what limitations? 29. Describe your system’s architecture, with specific focus on:

field data capture, where data are stored, how data are made available to command posts and others such as hospitals.

30. What restrictions govern data communication between field data capture and centralized system access? What technol- ogy links the field to the central database? Radio? Satellite? WiFi?

31. What telecom/data communication infrastructure is re- quired to implement your system?

32. What measures does your system employ to protect patient data and privacy?

33. Describe your system’s user access permission scheme and structure. How are user IDs and passwords assigned?

34. Does your system automatically identify the healthcare provider? The incident location? The patient location? How is this information entered or captured?

35. What measures does your system use to ensure data integrity, including back-up systems?

36. Please describe your system’s compatibility with other enti- ties and identify them. What data interchange approaches are used?

37. Describe your implementation/deployment approach. 38. Describe your approach to training.

REFERENCES

1. Jones J. Katrina highlights holes in emergency health care sys- tem 2005. Available At http://www.federalcomputerweek.com/ article91600–12–05–05-Print Federal Computer Week maga- zine’s archive site, accessed June 7, 2006.

2. Roberts S. FEMA’s forgotten of the Gulf Coast and Katrina chil- dren. July 1, 2006, Available at: [email protected]. Accessed July 6, 2006.

3. Nossiter A. 2005, as cited in Zuckerman S, Coughklin TA. Ini- tial Health Policy Responses to Hurricane Katrina and Possi- ble Next Steps. Available at: http://www.urban.org/publications/ 900929.html. Accessed February 27, 2009.

4. McCarthy MJ. 2005, as cited in Zuckerman S, Coughklin TA. Initial Health Policy Responses to Hurricane Katrina and Possi- ble Next Steps. Available at: http://www.urban.org/publications/ 900929.html. Accessed February 27, 2009.

5. American Red Cross Safe and Well website. https:// disastersafe.redcross.org. Accessed July 6, 2009.

6. Geogoux, Theodore, Regional Coordinator for National Disaster Medical System, personal communication, June 12, 2006.

7. U. S. Dept. of Health and Human Services Offices for Civil Rights, Hurricane Katrina Bulletin: HIPAA Privacy and Disclo- sures in Emergency Situations, September 2, 2005 available at www.hhs.gov/ocr/hipaa/EnforcementStatement.pdf.

8. Cleveland, Darryl, Corona Fire Department, personal commu- nication, June 16, 2006.

9. Ortiz, Dennis, Disaster Management System, personal commu- nication, June 20, 2006.

10. Petrie, Michael, San Francisco Emergency Medical Services Agency, personal communication, July 12, 2006.

11. Winens, Catherine, Healthcare Association of Southern Califor- nia, personal communication, August 11, 2006.

12. Richter, Roger, California Hospital Association, personal com- munication, July 26, 2006.

13. Department of Health and Human Services, 2005. 14. This section draws on the July 2006 market and technol-

ogy survey developed for the State of California’s Emergency Medical Services Authority. See Gidley, Darlene and Ciraolo, Michael, “California EMS Patient Tracking System Project,” completed for the California Emergency Medical Services Authority through Global Vision Consortium, August 30, 2006. Report available by request from emsa.ca.gov.

15. Schultz CH, Koenig KI, Lewis RJ. Implications of hospital evacu- ation after the Northridge, California earthquake. N Engl J Med. 2003;348:1349–1355.

16. Recommendations for a National Mass Patient and Evacuee Movement, Regulating, and Tracking System. Available at: http://www.ahrq.gov/prep/natlsystem/?zbrandid=3032& zidType=CH&zid=1651203&zsubscriberId=750816690. Accessed March 9, 2009.

17. For more background on RFID, see www.rfidjournal.com/faq and www.en.wikipedia.org/wiki/RFID.

18. National Hospital Available Beds for Emergencies and Dis- asters (HAVBED) System: Final Report. AHRQ Publication No. 05–0103, December 2005. Agency for Healthcare Research and Quality, Rockville, MD. Available at: http://www.ahrq.gov/ prep/havbed/. Accessed February 27, 2009.

19. Emergency Data Exchange Language (EDXL). Available at: http://xml.coverpages.org/edxl.html. Accessed February 27, 2009.

20. Ibid, and National Hospital Available Beds for Emergencies and Disasters (HAvBED) System: Final Report. AHRQ Publication No. 05–0103, December 2005.

21. Integrated Patient Tracking Initiative. Available at: http://www .comcare.org/Patient Tracking/IPTI Index.html. Accessed Feb- ruary 27, 2009.

22. Buono, JL., Lyon J., Huang, R., Brown S., Liu F., Vilke G., Killeen J., Chan T., Kirsh D., Lenert L. “Does Wireless Tech- nology Improve Patient Tracking in Mass Casualty Incidents?” https://wiisard.org/.

C op

yr ig

ht ©

2 00

9. C

am br

id ge

U ni

ve rs

ity P

re ss

. A ll

rig ht

s re

se rv

ed .