3. Recommendations for a Phase I National System

Building the ideal National System, described in the previous section, is an enormous undertaking and must therefore be implemented in phases. As soon as possible, the Federal government should fund development of a "Phase I" system. As described below, a Phase I system:

• would be a fully-functioning system that could be activated in the event of a national disaster.
• would contain location and health status data on patients/evacuees treated or housed at a limited number of locations.
• would contain information on the availability of a limited set of key medical and transportation resources that are critical for regulating patients and evacuees.
• would provide authorized users with access to patient, evacuee, and resource availability data in appropriate formats and levels of aggregations. 

Most importantly, the Phase I National System would be a platform on which the system can be expanded in subsequent phases (Section 4). 

The remainder of this section describes major recommendations and presents a 21-month implementation plan for the Phase I National System. 

Return to Contents

3.1. Patient/Evacuee Data Elements

While a comprehensive set of demographic and medical data would be extremely useful for tracking, regulating, and treating patients and evacuees, the project team and the steering committee recommend that, for the Phase I system, only a minimum set of data on patients and evacuees be included in the National System.  The project's steering committee agreed that the following eight data elements comprise this minimum data set: unique patient/evacuee identifier, name, gender, date of birth, health status, location identifier, arrival or departure indicator, and date and time of arrival or departure.¹⁰ 

In Section 3.2 we discuss our recommendation for how to obtain these data.  We recommend that these data be obtained electronically from existing "feeder" systems such as institutional records systems ("check in/check out" systems) and local- or agency-based tracking systems. 

Return to Contents

Minimum Data Elements

The following constitute the minimum data elements that should be collected at each location where a patient or evacuee is treated or housed:

• Unique identifier. It is essential that each individual being tracked have a unique identifying number, to avoid duplicates and confusion.  Existing patient tracking systems and institutional records systems (go to Appendixes C and D) use such numbers, but these systems use different algorithms for generating the IDs.  A key task in the Phase I implementation of the National System will be agreement on a common algorithm for creating unique patient or evacuee identifiers.  We recommend that the ID be created from the data elements in the minimum data set, namely:

  • Name.
  • Gender.
  • Date of birth (if not available, substitute age range: <1, 1-5, 5-10, 10-20, 20-30, etc.).

  If the local feeder system providing these data to the National System assigns a unique identifier to the patient or evacuee (using a bar code, for example), this number could also be incorporated into the minimum data elements. 

  We do not recommend the use of Social Security numbers (SSNs) because people may not recall their number, may use a fake number (SSN cards have no current photo), or may not have a SSN (as in the case of some children and many immigrants).  A driver's license or passport number could be used, but these can be lost and it must be possible to reconstruct the unique identifier using nothing more than information a person will know about themselves, without reference to documentation.

• Name, gender, date of birth.  The steering committee agreed that name, gender, and date of birth constitute the three most critical data elements for identifying a patient or evacuee.  Additional physical descriptors (e.g., height, weight, hair color, eye color, primary language spoken, hearing or sight impairment) should be considered following implementation of the Phase I National System.

   

• Health Status. The only medical information recommended for the Phase I National System is a single health status indicator.  The health status categories will vary depending on where the person is being assessed and whether medical personnel are making the assessment:

  1. Red/yellow/green triage color—for individuals assessed by medical personnel (emergency medical technicians [EMTs], triage nurses) prior to being transported to a hospital.  This is common practice for EMTs at accident scenes.
     • Red = emergent.
     • Yellow = urgent.
     • Green = no medical care needed.

     OR

  2. Intensive Care Unit (ICU)/floor/discharge ready, not yet admitted—for hospital patients being evacuated, who are assessed by medical personnel.  This will guide transportation to an appropriate receiving facility.
     • ICU = being evacuated from an ICU, needs transport to an ICU.
     • Floor = being evacuated from a hospital floor, needs to be admitted to a general hospital floor.
     • Discharge ready, not yet admitted = person can be relocated to a shelter or other non-medical setting.

     OR

  3. Acutely ill/well but with medical history/healthy—for evacuees being assessed by non-medical personnel, as at a shelter, bus station or other non-medical touch point. 
     • Acutely ill = needs emergency transport to a hospital.
     • Well with medical history = can be transported to a shelter but will need medical attention soon (e.g. medications, equipment for glucose monitoring).
     • Healthy = has no medical needs.
       
     
     

• Location identifier. A location identification number is needed so that the patient or evacuee is unambiguously linked to a location at a particular date and time. The location identifier must be unique to that location and, like the unique person ID, should be composed using a to-be-developed universal algorithm—for example, one based on type of location (from a list: hospital, shelter, airport, staging area, etc.), zip code of location, county, and State.

• Arrival or departure.  The minimum data set should include an indicator for whether the patient is arriving at or departing from the location.

• Date and time of arrival or departure.

Return to Contents

Secondary Data Elements

Once the Phase I National System is operational, additional data elements should be included that describe in more detail the patient/evacuee's medical condition and needs. 

The following other data elements would be extremely helpful for service providers (rescue workers, physicians, shelter staff) who are assisting people during the evacuation process.  They will also be useful for managers trying to coordinate safe transportation to appropriate locations—especially for people with medical needs.

• Special transportation needs (e.g., advanced life support (ALS) or basic life support (BLS) ambulance, wheelchair), to assure safe transport (e.g. sending a wheelchair van to a location that needs to relocate wheelchair-bound evacuees).
• Special medical needs (e.g., ventilator, oxygen, dialysis, current medications), to assure that patients with these needs reach a location equipped to meet them, and to support resource allocation so that a location that has several patients needing medication will get necessary shipments.
• Contamination/radiation/contagion status, should exposed people need to be segregated/quarantined/decontaminated, to avoid putting others at risk.
• Security/supervision needs/status, for psychiatric patients, prisoners, domestic abuse victims who may require special security for their own protection and that of others.
• Family unification code, to link family members to each other; shelters commonly include a family indicator as part of the unique ID, to help reunite families who become separated.
• Attached files (medical records and images), to allow transfer of other electronic information, especially health records, to be accessed by service providers at each touch point.
• Special communication needs, to help arrange for translator services or services for hearing or vision impaired persons.
• Final "exit" status (e.g., left with relatives, went home, deceased, admitted to long-term nursing home).  Individuals who have been tracked during an evacuation will eventually leave the tracking system, either because the emergency has ended and they can return home or because they have reached a semi-permanent location and are no longer in need for evacuation/services.  Rather than letting people simply wander off, it would be helpful to know that they are no longer in need of assistance. In addition, should other relatives still be searching for someone who has left the system, a final address/location would be helpful.

Return to Contents

3.2. Obtain Patient/Evacuee Data From Existing Systems

The central challenge for the National System is obtaining complete and accurate location and health status data on patients and evacuees as they are treated at and transported to different locations during and after the disaster—specifically, the data elements described in the previous section.  In particular, any strategy that requires emergency responders and health care staff to enter additional data—especially into an unfamiliar system—in the midst of a disaster will fail.  Fortunately, much of the data needed to track the location and health status of patients and evacuees are already collected by existing systems at health care facilities, disaster shelters, and other locations.  For example, hospitals enter information on every patient who is admitted or discharged.  We refer to these systems as "feeder" systems.  We recommend that the National System obtain necessary locating and tracking data electronically from these feeder systems. Feeder systems will only transmit data to the National System if the system is activated. Given the importance of feeder systems in our recommendations for the National System, the project team invested considerable resources researching these systems (go to Appendixes C and D). 

Return to Contents

Feeder Systems

A complete discussion of feeder systems is in the appendix.  Briefly, we group feeder systems into two broad categories. The first are institutional records systems. These are "check in/check out" systems that contain the current location of persons but are not designed to track their movement from one location to another.  Homeless shelters, hospitals, nursing homes, and virtually any other facility that houses persons use automated systems to keep track of who is in their facility.

The second type of feeder systems are tracking systems—systems designed to record the movement of persons from one location to another.  (Note that we are distinguishing between the National Systems which, of course, serves a tracking purpose, and feeder tracking systems.)  Feeder tracking systems include tracking systems that cities, counties, or other government agencies have purchased to track patients or evacuees.  Most commonly, they are used to track patients being transported from a mass casualty site to hospitals. They include both commercially licensed systems and "home-grown" systems such as ReddiNet in Los Angeles.  The DoD uses tracking systems to track military casualties—TRAC2ES is used for transport and regulating purposes and the Joint Patient Tracking Application (JPTA) to track military casualties as they are treated at different U.S. military hospitals. As noted in Section 3.3, both DoD and the Department of Health and Human Services (HHS) are considering adapting existing or obtaining new tracking systems for use in civilian mass casualty or evacuation incidents.  

Return to Contents

Illustrative Data Flow Between Feeder Systems and the National System

The following sequence of events illustrates how we envision the relationship between feeder systems and the National System:

Event	Data Flow
Casualty triaged at the incident scene.	Patient logged into the jurisdiction's tracking system (i.e., the feeder tracking system), which transmits location and medical status data to the National System.
Patient arrives at hospital 1.	Patient arrival recorded in the jurisdiction's tracking system, which transmits patient location and medical status data to the National System. Patient arrival also recorded in hospital information system, which transmits patient location and medical status data to the National System.
Patient leaves hospital 1, bound for airport 1.	Patient departure recorded in the jurisdiction's tracking system, which transmits updated patient location and medical status data to the National System. Patient departure recorded in hospital information system, which transmits updated patient location and medical status data to the National System.
Patient arrives at airport 1; boards airplane; arrives at airport 2; boards ambulance bound for hospital 2.	Patient airport arrival, plane boarding, plane deplaning, and departure from airport 2 recorded in the feeder tracking system in use at these locations, which transmits updated patient location and medical status data to the National System.
Patient arrives at hospital 2.	Patient arrival recorded in the jurisdiction's tracking system, which transmits updated patient location and medical status data to the National System. Patient logged into hospital information system, which transmits patient location and medical status data to the National System.

This illustration assumes that a number of different feeder systems exist and are capable to transmitting data to the National System, including tracking systems in the jurisdiction where the incident occurs, tracking systems at the airport, and admission and discharge systems at both hospitals. As described in our implementation plan, we envision that, over time, more and more feeder systems will become linked to the National System, starting with the systems that are described in Section 3.3.  

It should be noted that the above description assumes that one-way data exchange occurred between feeder systems and the National System. A more sophisticated two-way exchange could be considered for Phase II or III.  With two-way data exchange, when a feeder system transmits location and medical information on a patient or evacuee to the National System, the National System could return to the feeder system either (1) an acknowledgment that this particular person has been added to the National System, or (2) a list of possible "John Does."  In this latter case, the feeder system would need to present the "possibles list" to the user and prompt the user to select which, if any, of the John Does is the person at their facility.  This two-way communication would increase the accuracy of the National System (in particular, by increasing the instances in which a patient/evacuee record is correctly associated with an existing record for that same person). At the same time, from the perspective of the feeder systems' owners, the cost to effect two-way communication in the feeder systems would be significantly higher than the costs required to effect one-way communication.

Return to Contents

Implications of Relying on Feeder Systems

There are a number of important implications of relying on feeder systems to transmit patient and evacuee tracking data to the National System. 

First, the National System will not require line staff or emergency responders to enter additional data during the disaster. As noted above, the alternative to linking the National System with feeder systems is to develop a new data collection system that staff at institutions treating or housing patients and evacuees would use to enter patient and evacuee data. While developing the information technology (IT) components of such a system would take less time and resources than the approach we are recommending, project staff and the steering committee believe that the likelihood is very low that a new and unfamiliar system would actually be used during a catastrophic incident. 

Second, activating the National System will not involve deploying and transporting assets to an incident scene in the manner that activating the Strategic National Stockpile does.  Instead, owners of feeder systems (that have completed a certification process that ensures that the feeder system can correctly transmit patient/evacuee data to the National System) will need to "flip a switch" that activates the process for transmitting data from the feeder system to the National System. 

Third, a central repository is needed to receive patient and evacuee data from feeder systems.  The repository also must provide authorized users with access to person- and aggregate-level data, guard against unauthorized attempts to access data, and facilitate various administrative tasks, such as creating users, archiving data, etc. Development and testing of this central repository is an important part of the Phase I Implementation Plan (Section 3.6.)

Fourth, for the feeder system concept to work standards are needed for communicating with the National System.  Early in Phase I detailed protocols and procedures need to be developed that specify how data are transmitted between feeder systems and the National System. Broad acceptance of these requirements is critical to the success of the project, as is adherence to existing standards and related initiatives.  In particular, any standards and protocols in the National System should be compatible with the Emergency Data Exchange Language (EDXL) protocol overseen by the Organization for the Advancement of Structured Information Standards (OASIS), as well as the initiatives of the Office of the National Coordinator for Health Information Technology. 

In addition to developing a procedure to "flip the switch," owners of feeder systems also will need to develop and test the process (based upon to-be-developed data standards) that gathers and transmits the patient/evacuee data from their system to the National System.¹¹ In discussions with health care providers and health IT vendors, we have confirmed that from a technical perspective, the changes that need to be made are not difficult—the level of effort is similar to that required for repackaging extant data and periodically submitting it to a regulatory agency. In the case of hospitals with vendor-supplied IT systems, the IT vendor would develop the process, the hospital system would test the process on a test server, and then the hospital system would install the patch on their production server.

A final implication is that rollout of the National System will be similar to the rollout of other national data collection systems (e.g., those operated by the Centers for Disease Control and Prevention [CDC] and the Federal Bureau of Investigation [FBI]), in the sense that reporting entities will begin participating in the National System over a long period of time.  As a consequence, a patient or evacuee initially will be entered into the National System whenever s/he encounters a feeder system that is linked to the National System.  Similarly, the frequency with which a patient's or evacuee's location and health status data are updated also depends on whether feeder systems at the locations where s/he is treated or transported to are linked to the National System. 

---

10. By coincidence, a Department of Defense (DoD)-Department of Veterans' Affairs (VA) patient tracking working group independently developed the same list of minimum data elements just days before the project's final steering committee meeting.

11. We envision that a "batch process will be run (say, hourly) against the feeder system's database that extracts the necessary data elements and pushes these data to the National System, as opposed to a "real-time transfer of data to the National System immediately after the transaction occurs in the feeder system. The latter option, while providing more timely data, would be significantly harder (i.e., time-consuming) to develop within the feeder systems.

---

Return to Contents
Proceed to Next Section