The Evolving Use of a Clinical Data Repository: Facilitating Data Access Within an Electronic Medical Record

Abstract

We demonstrate the integration of a longitudinal, internally-developed legacy clinical information system with a vendor-based electronic health record application. The expense of developing the interface across systems was minimal, and it was successfully incorporated within the vendor EHR. Users consistently used the legacy data view while using the EHR; usage reached up to 50% of accessed data. Data showing concurrent increases in the use of the legacy data view and adoption of the new EHR suggests the method may improve adoption of the new system.

BACKGROUND

The past decade has seen significant shifts in the architecture strategies of clinical information systems. Open architectures that interface multiple different software applications have been promoted by organizations with the resources and history to create such systems (1). At the same time, vendors have increased in the ability to deliver functional clinical information systems to institutions, with effective decision support. This has led to growth in successful implementation, adoption and utilization of electronic health records (EHRs) (2). This has fundamentally changed the acquisition debate for large systems regarding EHR strategies from a “build vs. buy” discussion to which vendor-based EHR system to purchase (3), even for health care systems with a long history of internal development (4).

One reason for this change is that basic capabilities that were key to the successful development of homegrown EHRs have become sufficiently developed to be generally available in vendor-based systems. Structured vocabularies and interfaces have become standardized, facilitating the integration of data from ancillary systems. Though initiatives for sharing decision rules have been limited, common decision rules for ordering and preventive care have been successfully integrated into vendor systems. Recent initiatives like health information exchange have seen leadership by the vendor community in the adoption and demonstration of exchange standards (5). Progress has been sufficient that the Certification Commission for Health Information Technology (CCHIT) was created to identify functional requirements of EHRs, with vendors voluntarily participating in the certification process, with over 90 systems being certified in the first round.

At the same time, reviews of the clinical literature show evidence is lacking that vendor-based EHRs can actually improve care, with almost all studies demonstrating benefits of EHRs coming from settings where systems are internally developed (6). One reason for this dichotomy may be that vendor-based systems have not been installed in institutions that have evaluated and documented their impact, though this alone does not fully explain the discrepancy in the evidence base. Another reason may be that vendor-based EHRs have traditionally focused more on the operational tasks rather than the use of the systems to improve quality of care. This is evident in the different architectures pursued by vendor-based and internally-developed systems. Vendor-based systems often focus on data collection (such as documentation for billing) to demonstrate a return on investment of their product, while internally-developed systems have focused on data access (7). The result has been vendor systems are often organized in more normalized, relational structures that facilitate data storage, while homegrown systems may be organized in event-based models that facilitate data retrieval from clinical repositories (7).

These relational structures specifically affect the ability of systems to exchange data between different care settings and providers. Even though vendor systems have actively participated in health information exchange (HIE) efforts and demonstrations, HIE can be a particular architectural challenge for such systems. Data from external systems may not fit the relational data models being used in the vendor systems. In some cases, data from other systems may not map to any structures at all. Even when the mappings between the data elements of different systems is possible, the context of the data may not be represented correctly in the receiving system.

Vendor-based EHRs show promise for improving quality by focusing on specific clinical workflows. For example, many existing initiatives for EHR adoption focus on order entry and documentation. Decision support has been developed within these order entry systems to assist improved ordering. Incorporating decision support within the clinical workflow can improve quality – a study by Kawamoto et al. demonstrated it is the most prominent characteristic associated with improved care for clinical decision support systems (8).

At the Columbia University Medical Center (CUMC) campus of NewYork Presbyterian Hospital (NYPH), we have been addressing the challenge of implementing a vendor-based EHR while still maintaining the benefits of the internally-developed clinical information system (CIS). We have directly experienced the dichotomies of the shifts in CIS architectural strategies. In this paper, we describe our strategy of integrating a repository-based legacy CIS with a vendor-based EHR, and demonstrate its effect on system adoption.

METHODS

Columbia University Medical Center has a long history of clinical information system development, use and innovation (9). The service-oriented architecture consists of a clinical data repository, with a decision support system (10) and language specification (11), a controlled medical vocabulary (12), natural language processor (13), and longitudinal electronic health record (EHR) (14). Historically, this longitudinal EHR was part of the WebCIS application (14), which was one of the original large-scale deployments of a web-based clinical information system. In 2003, NewYork Presbyterian Hospital contracted with Eclipsys to install their SunriseXA application throughout the hospital. The goals of installing SunriseXA were to provide a computerized physician order-entry system, a nursing charting system, and a physician documentation record. After some initial pilot studies, the application was approved for system-wide adoption and has followed an implementation plan to that end. The system was first implemented for inpatient nurse charting, but has since been implemented in both the inpatient and outpatient sites at NYPH.

Prior to the Eclipsys implementation, WebCIS was the most prominently used systems in the hospital, used by over 3,000 unique users to access data on over 13,000 patients per day. WebCIS displayed data that had been collected in the event-based clinical data repository, and therefore was the most complete display of information available in our hospital. This completeness of the WebCIS data affected the implementation of Eclipsys, because users required data elements that were not initially available in Eclipsys and were often unwilling to switch between systems.

To address this user inertia, we developed a module within Eclipsys to access WebCIS data directly (see Figure 1). This module was built using a custom application framework within the Eclipsys application called ObjectsPlus. ObjectsPlus allows the creation of custom content within the general EHR structure. We built an ObjectsPlus customized results display window, or application “tab”, that held a web browser ActiveX control. This web browser was then pointed to a streamlined version of WebCIS, with a modified authentication procedure for user login and patient selection. The streamlined version did not contain all the content of the main WebCIS application, but did contain the most commonly-accessed data types, including laboratory, data, notes, discharge summaries, operative notes, radiology reports, pharmacy and pathology data. Authentication was done by having the already-authenticated Eclipsys application send a secure token to the WebCIS server, which would then authenticate the access request based on the parameters in the token. For users without access to WebCIS, the tab would display a single screen indicating access was not allowed.

Figure 1:

Screen display of NYP’s Eclipsys medical record, with the WebCIS tab. This provides access through Eclipsys to data stored in external systems.

Patient selection was disabled within the WebCIS tab. The WebCIS tab used the Eclipsys patient header information to identify the patient to the user. The ObjectsPlus module provided context information to the WebCIS application when the patient context changed in the Eclipsys application. This ensured both applications displayed information on the same patient synchronously.

Since the WebCIS application was web-based, and because the ObjectsPlus environment did contain a standard web browser component, it was relatively simple from a development standpoint to incorporate WebCIS into Eclipsys. We estimate that the development of the tab took one programmer less than 3 months to develop it. After a testing period, we implemented the WebCIS viewer/tab in Eclipsys in February 2008.

We measured access to the WebCIS tab by analyzing audit logs indicating user, patient and application from January 2007 through February 2009 (15, 16). Using daily statistics of the number of users, patients and data elements accessed, we computed the proportion of Eclipsys users who accessed the WebCIS tab, and the proportion of patients and data that they accessed through the method. We computed similar statistics for the proportion of WebCIS users who used the application through Eclipsys. Finally, we computed the change in usage of both Eclipsys and WebCIS over this period.

RESULTS

Figure 2 shows the proportion of Eclipsys users who accessed WebCIS through the WebCIS tab from January 2008 through February 2009. The data are naturally spiked because there were differences in the access proportions on weekends and holidays compared with weekdays. We attributed this to decreased outpatient clinic use but steady state inpatient use during weekends and holidays. The proportion of WebCIS users, patients and records accessed through the WebCIS tab (not shown graphically) followed a similar curve and ranged from weekday-weekend as follows: users (20%–35%), patients (10%–25%), records (5%–9%).

Figure 2:

Proportion of users, patients, or records accessed through the WebCIS tab among all Eclipsys access. Weekend (primarily inpatient) patient access reached 50%, while the proportion of users was over 25%. This indicates significant adoption of the tab within Eclipsys.

Figure 3 shows the growth of the Eclipsys application, in terms of number of patients accessed, super-imposed with the proportion of patients accessed from Eclipsys through the WebCIS tab. WebCIS growth (not shown graphically) was measured in January 2007, 2008 and 2009. From 2007 to 2008, the users, patients and records access increased 5%, 4% and 10%. From 2008 to 2009, the users increased 3%, but the patients and accesses decreased 5% and 7% respectively.

Figure 3:

Proportion of patients accessed through the WebCIS tab (left axis) and Eclipsys growth (right axis). Growth of tab use and Eclipsys is concurrent.

DISCUSSION

We incorporated access to a legacy longitudinal record within a vendor-based EHR workflow application. This access was done through an easily-developed web-based browser included in the EHR application. The use of the WebCIS tab in Eclipsys was notable, ranging up to half of patients accessed for primarily inpatient settings. We interpreted the main reason for this use was that users who were increasingly required to use the system could now access data without requiring the use of a separate system and the associated tasks of authentication and patient selection. In addition, the use of the WebCIS tab was coincident with increased adoption of Eclipsys, while WebCIS access declined slightly.

Our results are important because they measure the usage of the linked legacy system and the possible effect on the adoption of the new system. The context passing functionality of the system is not new – Clinical Context Object Workgroup (CCOW) technologies have demonstrated the capability to pass context between different systems before. Our approach here is unique, however, in that we identify the workflow application (EHR) as the primary application, and the clinical data repository as the secondary system. Initially, such an approach is not intuitive, since internally-developed data repository applications are usually more comprehensive in the data available, and more flexible in the capabilities. In this case, the flexibility is an advantage as a secondary system. Since a primary component of decision support is workflow, we focus first on the workflow application, and use the repository application to reduce the interface and data requirements of that system.

A significant benefit of our system is its flexibility. We have already developed a similar system for another workflow application (our vendor-based ambulatory EHR for Columbia Doctors), and are expanding the data available in the repository to new systems. This benefit is important to our environment, where we have an institution that represents a combination of 2 distinct hospitals and 3 ambulatory services, with 3 different vendor-based EHRs among them.

CONCLUSION

We demonstrate the integration of a longitudinal, internally-developed legacy clinical information system with a vendor-based electronic health record application. The expense of developing the interface across systems was minimal, and it was successfully incorporated within the vendor EHR.