Disaster Response in Health Care: A Design Extension For Enterprise Data Warehouse

August 29, 2005. Hurricane katrina made landfall and caused catastrophic damage along the coastlines of Alabama, Mississippi, and Louisiana killing at least 1,836 people.¹² Nearly 80% of the city of New Orleans and surrounding areas were ravaged. Katrina is estimated to be responsible for more than $80 billion in damages, making it the costliest hurricane in the U.S. history.¹² Katrina had a major impact on health care in the affected and surrounding areas. Thousands of evacuees, including many who had chronic conditions, needed immediate medical care.

The situation was perhaps the worst for those who left home without medical records, medications, and other criminal information. Clinicians and health care providers from the neighboring areas were forced to assess and treat unfamiliar patients without the help of electronic patients’ records.³

We believe that an enterprise data warehouse (EDW) is a solution to provide access to the information needed during the time of such disasters. An EDW is developed to meet the needs of strategic decision making that operational data sources and systems such as online transaction processing (OLTP), by design, cannot support.^7,8 Particularly, an EDW is considered a source of informational data to aid strategic decision making rather than operational data for supporting day-to-day business operations.^6,11 Over the last few years, EDW has become an important tool for most large organizations across different industries such as retail, health care, financial services, and manufacturing.¹¹ While EDW is traditionally developed for strategic decision making, we present an architectural extension for EDW that can potentially help health care providers continue their services during and in the aftermath of large-scale disasters, such as Katrina, by providing operational data when and where it is needed. We develop this extension based on our study of the Veteran Health Administration’s (VHA) information technology (IT) systems and responses during Hurricane Katrina.

Back to Top

Veterans Health Administration’s (VHA) Katrina Response

With an annual budget of over $26 billion, 193,000 employees, 158 medical centers, more than 850 outpatient clinics, and 137 nursing homes across the United States, the VHA, which is the health care arm of the Department of Veteran Affairs (VA), has one of the best known health care IT systems in the nation. Over the last two decades, the VHA developed a state-of-the-art suite of IT applications known as VistA (Veterans Health Information Systems and Technology Architecture).² There are 128 independent VistA systems available to the VHA hospitals and clinics to store, access, and process data pertaining to clinical, operational, administrative, and financial processes. To serve veterans seeking medical care at different VHA locations across the country, VistAWeb—a Web-based remote data view (RDV) that provides access to the medical records—has been developed recently. In 2005, the VHA began to implement an EDW based on a traditional EDW architecture^7,8,11 and serves as a centralized data repository. Overall, the IT systems of the VHA had far-reaching impact on the quality and efficiency of services provided to over five⁵ million veterans annually and have been frequently touted as the nation’s best health care IT systems.^1,2

A detailed account of how the VHA responded during and in the aftermath of Katrina is described elsewhere.³ Here, we provide a brief overview of the VHA’s response. Shortly after hurricane Katrina made landfall on Aug. 29, 2005, the Veterans Affairs Medical Center in New Orleans (VANW) lost power and communications and resorted to emergency backup systems. The VANW started rescue and evacuation operations and all the VANW inpatients, and staff, and family members were evacuated and relocated to other VA medical centers, within and outside the state. The VistA system at VANW was shut down on Aug. 30, 2005. All data current to that time were physically re-hosted from back-up tapes and integrated into the VistA system at Houston on Sept. 2, 2005. The VANW patient data were available nationwide through the Houston VistA system. Further, the VHA medical centers across the country were able to access the VANW data through VistAWeb. In order to continue the pharmacy services, the prescription data files from the VHA medical centers in Biloxi and Jackson were copied and installed in the VHA center at Houston. Prescription transmissions resumed immediately following the re-hosting of the VANW VistA system and all patient data were merged with the VistA system and made available for automated prescription fulfillment. Medical records of about 38% of VANW patients were accessed by the VHA providers from 48 states of the U.S. through Houston VistA systems and VistAWeb by the end of September and hundreds of displaced veterans were provided uninterrupted care.³ In contrast, the displaced non-veteran residents of New Orleans who needed constant medical attention were unable to get proper medical care that resulted in several deaths. Due to the lack of medical information about the evacuees, many hospitals around the country were forced to provide medication that, in fact, aggravated the conditions of many patients.

Back to Top

Disaster Scenarios and Learning

While the VHA’s response to Hurricane Katrina was timely, we believe that it could have been faster and more proactive if the VHA was able to use the clinical data from the EDW—known as Corporate Data Warehouse (CDW)—for operational purposes. The VHA’s CDW had the most up-to-date patient data that was loaded less than twelve hours before the Katrina landfall. Further, the CDW was located in Austin, Texas, which was not affected by Katrina. However, clinical data from the CDW were not available to clinicians because there was no readily available interface in the CDW to provide access to patients’ clinical records. Such an interface would require an operational data source because the EDW architecture traditionally does not support operational data access.¹¹ This prompted us to develop a design extension for an EDW that we present in this paperarticle.

We first discuss how an EDW can help in different scenarios in the aftermath of a large-scale disaster such as Katrina. From a health care perspective, there are four possible disaster scenarios as shown in Table 1. In some cases, patients (in- or out-patients and other individuals that may need medical attention) may be displaced and have to get health care services from new providers, outside the network of previous providers. In other cases, patients may not be displaced but operational systems of the local providers may be inaccessible due to various reasons such as a power failure or other constraints (for example, extreme weather conditions). Therefore, the EDW should not only support the within-network providers but also provide data access to the out-side-network providers. In three of the four possible scenarios shown in Table 1, we suggest than an EDW developed following our design extension can provide patient data to within- or outside-network providers. In the event that the operational systems are available and patients are not displaced to a new location, the EDW design extension proposed here may not be as essential.

Back to Top

Traditional EDW Architecture

Figure 1 presents a traditional EDW architecture.^7,9,11 The figure shows that an EDW has four major architectural components: (a) data sources; (b) data extraction, transformation, and loading (ETL) infrastructure; (c) enterprise data store (EDS); and (d) end-user applications. Data sources typically depend on organizational IT architecture and operational structure. Organizations with geographically dispersed operations and decentralized IT architecture such as the VHA typically have operational systems that are maintained regionally. These distributed heterogeneous systems may not be interoperable from a data sharing point of view and an EDW is needed for interoperability. Data from these different operational sources are extracted, transformed, and then loaded to the EDW through the ETL processes. Most commercial database systems have customizable ETL processes that help load data from different operational systems. Typically, data are loaded once a day, but some organizations may prefer to load data real-time. To access the data for strategic decision making, users use various analytic and business intelligence tools. In some cases, specialized data marts are created for important subject areas (or functional areas of a business) to provide faster data retrieval for specific decision making.

Figure 2 presents the VHA’s EDW architecture.¹ It is based on the traditional EDW architecture shown in Figure 1. The VHA’s EDW was not implemented as a vehicle to support operational activities.¹ This is evident in the figure as the architecture does not have the capability to support day-to-day clinical operations. Further, the architecture does not offer an explicit mechanism to support clinical processes in the time of disasters.¹

Back to Top

Data Warehouse Architecture for Disaster Response

The design extension presented here is not an alternative to traditional EDW architecture, but rather a feature extension to traditional EDW that offers greater flexibility and an ability to respond quickly and proactively during large-scale disasters. There are several requirements that have to be supported by the proposed design extension. First, as noted earlier, the EDW should be able to provide clinical data to health care providers that may be outside the network of a focal provider. This is the most likely scenario because, unlike the VHA, a majority of providers have only a regional presence. Therefore, the displaced patients may seek medical services from other external providers. Second, the EDW should have a platform-independent interface so that health care providers, irrespective of their existing IT platform, can access patient records. Third, the EDW should be part of organizational operational environment (not just a business intelligence and analytic environment). Finally, the EDW should support hybrid communication channels: landline, wireless, satellite, and the Internet. In keeping with these requirements, the extension that we offer here is based on the principle of service-oriented architecture (SOA) that focuses on a loose-coupling of IT systems and service delivery to heterogeneous IT systems.⁴ The proposed extension, shown in Figure 3, has the following major components:

1. Operational data store (ODS): While it is possible to wrap an EDW with SOA technologies to provide data services to heterogeneous operational systems, we suggest that building an operational data store (ODS) within an EDW is a better solution for at least two reasons. First, if the EDW had to be used in an operational environment, there is a need to perform data manipulation functions (for example, insert, update, and delete) on the data. It is not recommended for performance and data integrity reasons to perform these functions on an EDW. An ODS, because of its relational architecture as opposed to a dimensional architecture used in most EDWs, will provide non-aggregated data to operational systems and support these functions efficiently. Second, an ODS will reduce the load of data warehouse by supporting the operational needs and freeing the resources for analytical decision making needs which are the primary reasons for developing EDW.

2. Web-based safety net interface: In order to provide platform-independent data services to external entities, a Web-based safety net application using webWeb services and SOA technologies needs to be developed. This interface should be able to use standardized data and communication protocols (such as, XML and HTTP) to provide data services.⁴ The SOA and Web services technologies will help the service consumers (the organizations that need the data services) to locate the service providers (in this case the organization that implements the EDW design extension) from a service directory⁴ and request for data services. While we suggest that SOA-based safety net interface will be ideal to support both internal and external heterogeneous IT systems, we note that it is possible to develop a traditional HTML-based Web interface for the safety net application. One key drawback of such an implementation would be that the health care providers who access the interface may not be able to extract and load the data from the HTML-based Web interface to their local operational systems. An XML-based Web interface does not have this drawback.

3. Hybrid communications: We suggest two alternatives for physical locations of an EDW. First, an organization can host the EDW at a secure remote location. Second, if the organization decides to host the EDW locally, it is important to host a mirror copy at a secure remote location. Regardless of the physical location of an EDW, it is important to develop a hybrid communication channel to provide seamless access to the data. A hybrid communication channel consists of alternative modes of communication such as land line, wireless, satellite, and the Internet. But, a disaster of the magnitude of Katrina may destroy the infrastructure needed for such a mechanism to work. In such a situation, it may be necessary to physically re-host the backup tapes at a different location very much like what the VHA did during Katrina. However, it took 3 to 5 days for most organizations to restore data from the backup tapes and make it accessible after Katrina.^3,9 For the health care sector, unavailability of critical patient records for 3 to 5 days can be fatal, especially in the aftermath of a disaster when people need immediate medical attention as we discovered most painfully after Katrina. Therefore, health care providers should consider hosting their EDWs at multiple locations and develop a hybrid communication channel for seamless data access.

The design extension described here will provide several important benefits to health care providers. The providers who add this extension to their EDWs will be able to make patient data available during the disaster perio, ensure better patient care and potentially save human lives. The providers who access the patient data through the safety net application will be able to make a better assessment of patients’ condition and provide more accurate patient care. Depending on the requirement of the organization, the development and implementation of an ODS as part of the EDW can be complex and may require large data storage. If the sole purpose of the ODS is to support limited operations such as disaster response, we suggest that health care providers develop a volatile and thin ODS that can be populated from the EDW immediately before or after the disaster. Special data transformation services can be created between the dimensional EDW and relational ODS to perform the data loading only for the affected regions. This approach can reduce the complexity and cost of developing the ODS.

As noted earlier, in the aftermath of a disaster, patients may move to various locations and seek medical attention from different health care providers. These new providers should be able to access the SOA-based Web interface to get patient records. Because of the sensitive nature of the health care data, it is important to develop an access policy regarding how external providers can access the clinical data. Security and privacy of patients’ data can be a major concern for the architectural extension proposed here. This issue is even more important because of the regulatory requirements outlined in HIPAA (Health Insurance Portability and Accountability Act). It is important for health care providers to develop a comprehensive strategy to tackle the security issues and ensure patients’ privacy. Security issues can be addressed in two different ways: (1) data- and application-level security and (2) communication-level security. Data and application level security can be ensured through the development of an access policy for the potential users of the data and application. This access policy should include guidelines for both internal and external users of the data. The communication-level security can be ensured through different state-of-the-art security mechanisms such as key-based encryption such as secured socket layer (SSL) and virtual private network (VPN) protocols. A detail discussion of these security mechanisms is beyond the scope of this article.

Back to Top

Conclusions

While health care providers have come a long way in terms of implementing state-of-the-art IT applications, they still lack an effective IT infrastructure that would help respond to large-scale disasters as evidenced in various news and media reports in the aftermath of Katrina.⁵ It is important for the health care providers operating in the disaster prone areas to be more mindful while designing and implementing IT infrastructure. The ad-hoc nature of responses during Katrina by many organizations, clearly indicates the need for revisiting the IT architecture to improve the quality of disaster response.^5,9 We offered an EDW design extension as a solution to efficiently access patients’ records during large-scale disasters. We expect that health care providers will be able to respond well and provide better services during the period of disaster with the help of the design extension described here.

Back to Top

Back to Top

Back to Top

Back to Top

Back to Top

Back to top