3.3. Link a Limited Number of Feeder Systems to the National  System

During Phase I, only a limited number of feeder systems should be linked to the National System in order to demonstrate that the overall approach for the Phase I system is feasible, to develop guidelines to assist in linking other feeder systems in subsequent phases, and to build support for broader implementation of the National System. Selection of the Phase I feeder systems should consider the likelihood that patients or evacuees would encounter a particular feeder system during an actual incident. Priority should therefore be given to feeder systems that operate in higher-risk areas of the country.  Another consideration is the likelihood that the owners of the feeder system will be able to link their feeder system to the National System according to the Phase I schedule (go to Section 3.6).  During Phase I, the Phase I feeder systems would need to be modified so that the Phase I data elements would be transmitted to the National System.  These systems would then need to undergo a to-be-defined certification process to verify that data are transmitted according to specification.  The links between these feeder systems and the National System would also be tested during the pilot test scheduled near the end of Phase I (Section 3.6). 

We recommend that the Phase I feeder systems include (1) any available Federal (e.g., Department of Defense [DoD] and/or Department of Health and Human Services [HHS]) patient and evacuee tracking systems and (2) hospital admission and discharge systems at one (or possibly two) hospital systems that are affiliated with a major health information technology vendor. Federal tracking systems are included in Phase I because they are intended to be used nationwide, rather than at just a single location.  As a result, in a multi-jurisdictional incident, patients and evacuees are very likely to encounter staff who use these systems.  A hospital system is included because it is critical to start the process of getting hospital systems linked to the National System, and starting with a hospital system that is affiliated with a major health information technology (Health IT) vendor—as opposed to a small vendor or a hospital with a "home grown" system—increases the likelihood that the number of hospitals linked to the National System can be increased rapidly in subsequent phases.

Return to Contents

Federal Tracking Systems

The Phase I implementation plan assumes that either the DoD or HHS (or both) will develop, test, and implement a system (or systems) that agency employees and/or National Guard personnel will use to track patients and evacuees that they treat and/or transport.  The implementation plan makes no assumptions about the particular system developed, only that the system(s) be able to serve as feeder systems to the National System and that they will undergo a certification process for the National System during Phase I. Options for DoD and HHS include "civilianizing" the Joint Patient Tracking Application (JPTA), which the DoD currently uses to track patients at military hospitals; further developing the Emergency Tracking Accountability System (ETAS), which currently exists as a prototype; expanding use and access to TRAC2ES; or obtaining a new system. (JPTA, TRAC2ES, ETAS, and other tracking systems are discussed in Appendix C.)  Independent of the timeline for the National System (or whether it is implemented at all), the Federal government should commit to implementing at least one of these systems. 

Return to Contents

Information Systems at Hospital Systems

During Phase I, the admission and discharge system used by a network of hospitals that is affiliated with a major health care information technology (Health IT) vendor will be linked to the National System. At the beginning of Phase I, a major health care system (or two such systems) should be recruited to participate in the project.  This health system should have hospitals in at-risk areas for disasters and, as noted above, use systems purchased from a major Health IT vendor.  As noted in the previous section, the vendor would have to develop a computer program that would be run (if the National System is activated) at a pre-specified interval that would extract the required data elements on patients who were admitted or discharged from the hospital because of the disaster and then transmit that data file to the National System.  IT staff at the network of hospitals would have to test this procedure on a test server and then install it on their production server. 

The experiences linking this feeder system to the National System will benefit other health care providers who will link their systems to the National System in subsequent phases of the project. In particular, Phase II will link the Phase I health IT vendor's other major hospital and nursing home clients to the National System, as well as work with other major health IT vendors.  The groundwork for this expansion—establishing contacts with other health care systems, developing a detailed implementation guide, etc.—will be laid in Phase I.

The hospital systems with whom the project staff have spoken have indicated that their willingness to participate in Phase I depends on:

• whether participation will interrupt day-to-day operations at their facility.¹²
• whether linking to the National System will be voluntary or a requirement.
• the anticipated costs (primarily IT staff time) of modifying their system and whether they will be reimbursed for their costs. 

Return to Contents

Disaster Shelter Registration Systems

It may be possible ultimately for the Phase I feeder systems to include registration systems currently being explored at American Red Cross (ARC) disaster shelters. Evacuees would obviously encounter such as system during any incident in which the National System is activated. The ARC's long term goals include implementation of a client registration system for its disaster shelters, but such a system is unlikely to be available for Phase I.  Even when these systems are implemented, privacy considerations will likely preclude transmitting identifying person-level data to the National System.  Possible alternatives include providing only aggregate data (e.g., the number of evacuees at a shelter, by health status category) or allowing evacuees to voluntarily register themselves in the National System.  Another option is to explore whether systems used by the Coordinated Assistance Network (CAN) to coordinate benefits and other services for evacuees could be linked to the National System. CAN is a multi-organizational partnership that includes the ARC and some of the Nation's other leading nonprofit disaster relief organizations.¹³ 

Return to Contents

3.4. Focus on a Limited Number of Health Care and Transportation Resources

Timely and accurate information on the availability of key health care and transportation resources is essential for making sound regulating decisions—that is, to ensure that a patient is transported on a vehicle that is staffed and equipped appropriately and transported to a location that will have an available bed, staff, and equipment. 

The project team and the steering committee recommend that the Phase I system focus on assembling for the National System information on a limited number of key resources:

• Hospital beds (baseline number at each hospital).
• Nursing home beds (baseline number at each nursing home).
• Disaster shelter beds (baseline number at each disaster shelter).
• Ground ambulances (baseline number for major owners).
• Air ambulances (baseline number for major owners).
• Buses (baseline number for major owners).
• Airplanes (baseline number for major owners).
• Trains (baseline number for major owners).

Data collection procedures for the three types of beds already exist (hospital bed capacity, via the American Hospital Association's annual survey; nursing home bed capacity, via the Centers for Medicare & Medicaid Services' (CMS) Online Survey, Certification, and Reporting (OSCAR) System; and disaster shelter bed capacity, via the Red Cross's National Shelter System. 

By contrast, there are no existing procedures or systems for obtaining location-specific baseline data on other high priority resources identified by the steering committee—i.e., ground ambulances, helicopter ambulances, buses, and airplanes.  For these resources, we recommend that during Phase I a process be established for on-going collection of baseline capacity data from the major owners of the resources. Once this process is established, expanding it to include other owners of these resources can be considered for Phase II.

Additional background information on resource availability systems appears in Appendix E. 

Return to Contents

3.5. System Operation

Below we provide a brief, high-level, and illustrative overview of how the Phase I National System would operate, in terms of (1) pre-population of data, (2) system activation, (3) data exchange, (4) data access, and (5) system deactivation.  A key task during development and testing of the Phase I system is development of detailed operating procedures and data protocols. 

Pre-Population of Data

The goal of this stage is to minimize the amount of work necessary in the next stage (system activation) by populating the National System with as much data as possible prior to an incident.  As noted in the previous section, the Phase I system would be populated with baseline bed capacity data from all hospitals, nursing homes, and disaster shelters, and baseline capacity data from the major owners of ground ambulances, helicopter ambulances, buses, airplanes, and trains.  Other system configuration data—to be defined early in Phase I—would also be populated in the National system, such as facility locations and key user organizations (e.g., Emergency Operations Centers, public health agencies, Federal Emergency Management Administration [FEMA], HHS, Department of Homeland Security [DHS]).

System Activation

The decision to activate the National System will follow a predefined and to-be-developed protocol.  Once this occurs, the administrator of the National System ensures that a number of tasks are completed.  Most importantly, the system administrator ensures that owners of the Phase I feeder systems activate the processes that transmit data from their feeder systems to the National System.  Other tasks include creating an incident in the National System (so that all subsequent data can be linked to that incident), activating the National System's data access portal, alerting authorized users that the National System has been activated, and answering questions from the National System users.

Data Exchange

After system activation, feeder systems begin submitting patient and evacuee data to the National System.  The following scenario illustrates when and how patient/evacuee data will be transmitted to the National System. 

• John Doe is injured in a mass casualty incident.  The local emergency medical service (EMS) agency, using its own tracking system, logs John into their system.  For the purposes of this illustration, this local tracking system is assumed not to be linked to the National System, so information about John is not transmitted to the National System at this time.
• John is transported and admitted to a local hospital, which (for illustrative purposes) is assumed to have a feeder system that is linked to the National System.  A hospital administrator records information about John in the hospital admissions system.  According to a pre-determined interval (e.g., every 4 hours), a computer process that was developed and tested as part of the feeder system certification process runs and pushes the minimum data elements (go to Section 3.1) through the Internet to the National System. An initial record of John is now established in the National System.
• The next day John needs to be evacuated to a hospital in another State.  After John's departure is recorded in the first hospital's information system, a process (similar to the one described in the previous bullet) transmits the minimum data elements to the National System.  The National System now has two records for John: one indicating that he arrived at the first hospital and one that he departed that hospital. 
• John arrives at a airfield near the first hospital, where a Federal tracking system is operational and logs in arriving patients and evacuees.¹⁴ After John is logged into the Federal system, a process is run on that system which transmits the minimum data elements to the National System.  The Federal feeder system uses the same algorithm to produce a unique identifier as the first hospital's feeder system, thus enabling the National System to associate John Doe's arrival at the airfield with his previous arrival and departure at the hospital.  The National System now knows that John arrived at this airfield; if this same Federal tracking system were used at the airfield where the plane arrives, the National System would know that John arrived at this second airfield. 
• At the arriving airfield, John boards an ambulance and is taken to another hospital which, for the purposes of this illustration, does not have a feeder system linked to the National System.  Thus, to authorized users accessing the National System, the most current information on John Doe's location is that he arrived at the second airfield.

Data Access

A key task in Phase I (Section 3.6) is to determine policies regarding access to data in the National System. These policies must consider the needs of authorized users while at the same time adhering to privacy and confidentiality regulations that are in effect at the time of the incident.  Data access rules and access privileges will vary for different user groups.  Illustrative rules include:

• Allowing the hospital from which John Doe was evacuated to view where their (former) patient is located following the evacuation.
• allowing emergency health care providers to view patient identifiers and health status information of persons arriving via airplane and then to download the patient-level information into a local regulating system.
• Allowing emergency operations center personnel and public health officials to view aggregate data on the health status and location of patients and evacuees, as well as hospital, nursing home, and shelter bed capacities.

After logging on to the National System, authorized users will be presented with a list of available reports and query options that reflect the type of data that they are allowed to view.   Security access will be assigned so that only those with a need to see individual data can do so (e.g., physicians providing care), while others might only need to view aggregate data at the location, county, or incident level.

System Deactivation

Policies regarding system deactivation would be developed during Phase I  (Section 3.6).  Presumably, this would happen in stages.  First, the feeder systems that have been transmitting data to the National System would stop doing so.  At a later time, depending on National System policies, authorized users would no longer have access to data obtained during the incident. Deactivation policies would also cover the release of archived data for after-action reports or for future preparedness planning and research.

Return to Contents

3.6. Implementation Plan and Estimated Costs

An implementation schedule and 21-month task plan for the Phase I National System is shown in Exhibit 3.1. The 21-month time period does not include the time required to secure funding for the Phase I system. 

The proposed schedule is aggressive; in particular, it assumes that formal agreements can be reached quickly with Phase I partners, that oversight committees and subcommittees can be formed and convened quickly, and that the Phase I feeder systems are operational (but not linked to the National System) by month 10. 

The implementation plan is divided into five major tasks: project start up, system specification, system development and testing, pilot test, and documentation.

Return to Contents

Task 1: Project Start-Up

Task 1 includes four subtasks. At the start of the project, the recommendations here should be revisited, and if necessary revised, in light of developments occurring since the end of Abt Associates' AHRQ Task Order. 

Second, Phase I partners need to be identified and recruited as soon as possible, ideally even before the start of Phase I. This includes a private contractor that will oversee the entire project and an information technology contractor that will be responsible for developing the National System's central infrastructure. Working relationships with the organizations that control the Phase I feeder systems need to be formalized as well. As discussed earlier in Section 3.3, we recommend that these organizations include a major hospital system (or two) affiliated with a major health IT vendor and Federal agencies that will use tracking systems during a major disaster (e.g., DoD and HHS).

Third, oversight committees and subcommittees must be formed.  An oversight committee will be established to advise and bring broader perspective to the project.  Committee members will serve on subcommittees that will focus on specific critical issues, such as data protocols, data security, privacy concerns, user requirements, standard terms of reference, and IT development. Committee members should include representatives from the Phase I partners, major national health care associations, Federal agencies with ESF 8 responsibility, and other national associations whose member organizations will be asked to participate in the National System following completion of Phase I. 

Finally, legal, regulatory, and security issues related to the Privacy Act, Health Insurance Portability and Accountability Act (HIPAA) waiver, Health Information Exchange, and other related concerns need to be evaluated in terms of how they impact and constrain the Phase I work.  As discussed at length in appendix B, the exchange of identifying information presents various legal and regulatory issues, including protection of identifiable health information (HIPAA) and other privacy standards, patient information systems and retention of records, complaint and incident reporting, hospital requirements for discharge planning, reportable diseases, isolation and quarantine, and contact tracing.  The privacy subcommittee should also address the issue of whether and how the general public will be allowed to search the National System's list of patients and evacuees. 

Return to Contents

Task 2: System Specification

In this task, the subcommittees, under the direction of the project manager, will formulate system requirements, including those focusing on data protocols, functional requirements, and security requirements.  For example, detailed protocols and procedures need to be developed for invoking and disabling the system, effecting data exchange during an event, generating the common algorithm for unique ID numbers, providing data access both during and following an event, and archiving and retrieving data following an event.  Broad acceptance of these requirements is critical to the success of the project, as is adherence to existing standards and related initiatives, such as EDXL and the Office of the National Coordinator for Health Information Technology. 

The end product of this task is a system design and technical specification document.  This document will be provided to the IT firm that will develop the security, data receipt, storage, query, reporting, and archiving features of the central repository.  In addition, the document will be provided to the organizations that own the Phase I feeder systems, and guide their task of modifying their feeder systems so that they can transmit patient and evacuee data to the National System. 

Return to Contents

Task 3: System Development and Testing

During Task 3, the central infrastructure of the National System, which will receive data from certified feeder systems, allow authorized users to query the system and generate reports according to predefined data access rules, and provide tools to administer the system, will be developed and tested.  Options for completing this work, as noted earlier in Section 3, include developing an entirely new system or enhancing an existing system (e.g., a Federal tracking system). Both a development and a production environment (hardware, software, and connectivity) will need to be obtained and set up for this. 

Also during Task 3, the Phase I feeder systems will need to be modified (according to the system design and technical specifications document developed in Task 2), so that they can transmit patient and evacuee data to the National System. As noted earlier in Section 3, these changes are not, from a technical perspective, difficult.¹⁵  Once these modifications are completed, a formal certification process (also developed in Task 2) will be undertaken for each feeder system to ensure that the patient and evacuee data are correctly transmitted to the National System.

The Phase I schedule assumes that modifications to the feeder systems will occur during a 6-month period starting on month 11.  The schedule therefore assumes that these systems will be operational (but not linked to the National System) by month 10.  This is not an issue for hospital systems participating in Phase I (since they will already have working admission and discharge systems), but may be for other Phase I feeder systems, in particular, Federal tracking systems. 

Return to Contents

Task 4: Pilot Test

While system development is occurring, a pilot test using the Phase I system will be planned.  The pilot test is scheduled for month 19. 

Also during Task 4, the resource availability data that will be included in the Phase I system will be collected and made accessible to the National System (either by directly loading the data or by establishing automated links to existing databases).  As noted in Section 3.4, these resources include baseline numbers of hospital beds (at each hospital), nursing home beds (at each nursing home), disaster shelter beds (at each disaster shelter), ground ambulances (for major owners), air ambulances (for major owners), buses (for major owners), airplanes (for major owners), and trains (for major owners).

Return to Contents

Task 5: Documentation

Phase I documentation will include after-action reports on the pilot test, a National System policies and procedures manual, a guide for operating and maintaining the National System's central repository, and a "National System Participation Guide" for organizations that will participate in subsequent phases of the project. 

Return to Contents

Estimated Phase I Costs

The cost to implement the five tasks described above is estimated to be between $1 and $1.5 million.  At the conclusion of task 2 (System Specification), a more precise estimate of the costs of tasks 3 thru 5 can be made. 

Key assumptions in this estimate include:

• A private contractor, working collaboratively with Federal agencies, will oversee all aspects of the project.
• The Phase I partners, which will be identified and recruited in Task 1, will be reimbursed for their time and expenses for serving on working groups, modifying their feeder systems, and participating in the pilot test. 
• Five working groups, with representatives from the project management firm, Federal agencies, Phase I partners, and non-Federal officials hired as consultants, will be needed for Task 2. 
• The central infrastructure will need to be built (or, alternatively, major modifications and enhancements will need to be made to an existing system). 
• A test and production environment (system software and hardware) for the National System's central infrastructure will need to be purchased and maintained. 

---

12. In our proposed approach for Phase I, activating the National System will not affect day-to-day operations at locations with feeder systems linked to the National System because line staff will not be required to enter data into a separate system.

13. Go to http://www.can.org for more information.

14. The Federal tracking system could be a DoD-developed tracking system (e.g., a civilianized JPTA system or ETAS) or an HHS-developed tracking system.

15. From a technical perspective, the modifications are not difficult, because we propose that a "batch process" be developed and run against the feeder system's database. This batch process would not involve changes to the feeder system's core processing functions or user interface.

---

Return to Contents
Proceed to Next Section