As technology consumers, we have come to expect a high level of functionality on the computerized systems we have come to depend on for our everyday tasks such as banking, tracking of parcels, and airline ticketing. Unfortunately, that same functionality that is typified by those systems does not extend into healthcare, which is often hobbled by technical problems such as fragmented source databases.

This is especially true of larger healthcare systems and academic hospitals, where there is a general lack of integration between these multiple unique source databases. Indeed, most databases were built on legacy systems that are not designed to integrate with other software systems. While this lack of integration was initially the result of project-driven systems, the problem of “database silos” has remained, and continues largely because of commercial interests.

Recently, the concept of a fully integrated electronic medical record (EMR) has opened up the possibility of breaking down those silos. Underlying the idea of an integrated EMR is the need to address multiple unique medical informatics needs, all which strive to integrate the various source systems and technologies into a single-window EMR.

While these efforts have occasionally been quite successful, they almost always have been operation-oriented. As a result, these newly integrated systems generally still lack of reporting and research capabilities. These remaining problems are particularly important in time-sensitive data rich environments such as the operating room and intensive care unit, where the intensity of care is high and the needs for understanding both healthcare delivery processes and patient outcome are substantial. In this setting, a traditional data warehousing approach is inefficient to provide optimal results.

INTEGRATED DATABASE: A SPECIAL REQUEST

About five years ago, Ognjen Gajic, M.D., a critical care physician and researcher from Mayo Clinic, Rochester, Minn., had an important research question to be answered. Specifically, he was interested in evaluating the association between blood transfusion and a respiratory complication known as acute lung injury (ALI). In order for his research to move forward, he needed to be alerted about patients who had a blood transfusion order issued and who were at risk of ALI.

This seemingly straightforward task was complicated by the large number of transfusions administered at the participating institution. Moreover, the data needed to be extracted from multiple source databases to allow adjudication of the outcome of interest. Specifically, the detection of ALI required interrogation of the radiology reporting system, as well as laboratory results from the hospital's laboratory reporting system. Ultimately, the alert system required three separate data feeds from the EMR system. At that time, this was neither technically nor practically feasible.

The proposed solution to this study's unique informatics needs was a concept termed the “ICU data mart,” which would be an integrated database where all pertinent data regarding critically ill patients would be stored in near real- time. In addition, the data within this ICU data mart would be able to be queried readily. The integrated nature of the data mart would allow complex queries, including data from multiple non-integrated source databases.

When this concept was proposed to a group of our information technology colleagues, their response was a rather straightforward: “Impossible.” Soon after, we began to build this integrated relational database ourselves “one brick at a time.” It has become a highly functional near real-time database servicing dozens of investigator-initiated data requests, quality improvement initiatives, and administrative needs. Moreover, it has been developed with minimal resources and at a very low cost.

We believe that the success of this project is in large part due to its “non-IT approach.” This doesn't mean that we avoided the use of computers and databases. Quite the opposite, the ICU data mart is physically a Microsoft structured query language (SQL) database. However, our approach was based on three key concepts-Legos, UNIX, and Matrix-that often run contrary to traditional informatics approaches.

CONCEPT 1: ‘LEGOS’

No, this doesn't imply that the database was built from our children's Lego sets. Rather, it is the concept of building a project one piece at a time while maintaining a vision of what the final project will look like and, equally importantly, what the next piece will add to the whole. An important benefit of this piece-by-piece approach was that it allowed the existing data to be used before the final version of the database was completed.

Our initial piece for the ICU data mart was the reference table based on admission and demographic information. This was an essential starting point, because it allowed us to define a specific event: the ICU length of stay. Indeed, without a defined time interval, everything else becomes a mess. We then used a combination of the patient identification number and admission time as key links to other tables of interest.