Development of a clinical information tool for the electronic medical record: a case study

Abstract

Question:

What is the process of developing a clinical information tool to be embedded in the electronic health record of a very large and diverse academic medical center?

Setting:

The development took place at the University of Pittsburgh Health Sciences Library System.

Method:

The clinical information tool developed is a search box with subject tabs to provide quick access to designated full-text information resources. Each subject tab offers a federated search of a different pool of resources. Search results are organized “on the fly” into meaningful categories using clustering technology and are directly accessible from the results page.

Results:

After more than a year of discussion and planning, a clinical information tool was embedded in the academic medical center's electronic health record.

Conclusion:

The library successfully developed a clinical information tool, called Clinical-e, for use at the point of care. Future development will refine the tool and evaluate its impact and effectiveness.

INTRODUCTION

Quick access to accurate knowledge-based information to answer clinical questions at the point of care is a key component of health care quality. Yet research has shown that physicians often fail to find the answer to many of their clinical questions [1, 2]. The most cited obstacle is lack of time to consider the question and search for the answer [1–7]. Other barriers include uncertainty about where to look for the answer and failure of the chosen resource to provide the answer [1, 8]. Some studies note the lack of access to information resources and poor searching skills in using information resources as additional reasons why clinicians have difficulty in meeting their information needs [5, 8].

The results of a study by McKibbon and colleagues showed that when physicians were given a choice of information resources to answer their questions, they did not always select the resource that would best support their answer [9]. In separate studies, Magrabi and Coiera and colleagues compared the outcomes of clinical searches performed on disparate information resources to those performed using a meta-search filter or profile on the same set of resources [10, 11]. The meta-search filters included etiology, diagnosis, treatment, drug information, and patient education. One resource was chosen for each profile, such as MEDLINE, and automatically generated keyword filters were added to the search. The results of this study indicated that it took clinicians less time to find an answer using the meta-search filters and that the answers retrieved were more accurate than those retrieved using the individual resources without the filters.

Cimino and colleagues have published extensively on clinicians' information needs at the point of care and the need to embed links to knowledge-based information resources within the electronic medical record [12–15]. Cimino's group developed and implemented Infobuttons, and more recently Infobutton Manager (IM), to link information resources within their institution's clinical information system [13]. Studies of IM use have shown that more than half of the questions asked by clinicians could be answered using IM. Results also show that the use of knowledge-based information resources increased after IM was available, compared to the baseline use of these resources.

In an article about the future of medical libraries, Lindberg and Humphreys suggested that electronic health records in the future will include access to “customized information when and where it is needed” [16]. This case study describes the process of developing a clinical information tool, implementation of this information tool into the institution's electronic medical record, and challenges faced during this process.

BACKGROUND

The University of Pittsburgh Health Sciences Library System (HSLS) supports the educational, research, clinical, and service activities of the health sciences community of the University of Pittsburgh and the University of Pittsburgh Medical Center (UPMC), through developing and providing innovative information resources and services. UPMC includes 15 tertiary, specialty, and community hospitals; 400 outpatient sites; and doctors' offices, as well as rehabilitation and long-term care facilities. HSLS receives budget support from UPMC to provide system-wide access to licensed online resources. At the time of this study, the UPMC electronic medical record, called eRecord, had over 3 million unique patient records and more than 22,000 active users, including more than 5,000 physicians employed by or affiliated with UPMC. It also included 200 clinical applications from more than 120 vendors, including EPIC and Cerner.

In June 2004, the library director was invited to participate in the UPMC-wide Physician Advisory Committee (PAC) to the eRecord. PAC is chaired by the chief medical information officer, and its membership includes physicians and other health professionals, together with representatives from information services and health information management. Updates on eRecord activities are provided at the quarterly meetings, and national speakers are featured to discuss recent advances in health information technology and related fields. In his invitation to the library director, the PAC chair wrote that he “viewed the information that it takes to best care for patients in two broad categories…patient specific and problem specific.” He went on to state that it made “perfect sense” to combine the library's problem- or disease-specific information resources with the eRecord.

In the fall of 2006, library collaboration with PAC accelerated as the library identified a “key physician.” The key physician was willing to devote time to this project and serve as its champion, providing the much-needed bridge between the library and PAC. This key physician, the medical director of the ambulatory eRecord, had a vision that the eRecord could improve practice by delivering not only patient-specific data directly to the physician, but also context-specific, knowledge-based information. The key physician believed this would “raise the standard of care and improve patient safety and satisfaction.”

To design the best solution, a library development team was initiated to work with the key physician to learn more about the eRecord and clinical information needs at the point of care and to identify full-text information resources and appropriate technology. The five-person development team included reference librarians with expertise in clinical information needs and computer services librarians with programming experience, along with the library director.

CLINICAL INFORMATION TOOL DEVELOPMENT

The library development team met several times with the key physician to discuss what types of information would be most useful to clinicians at the point of care. Initial discussions focused on pre-populating a search box with specific patient information or International Classification of Diseases Clinical Modification (ICD-9) codes. The development team felt that this was a worthy long-term goal, but that their small group did not have the resources or skills to build a tool of this complexity at the outset. It was ultimately decided to start with a more attainable pilot project and build from there.

The team aimed to develop a clinical information tool that would take advantage of the library's wide variety of full-text licensed resources, thus minimizing dependence on any one resource. If a resource changed, or if the library chose not to renew the license for a particular resource, a comparable resource could be substituted. To minimize repetition and redundancy, the tool needed to search the fewest number of resources that would answer the questions.

The Velocity search platform from Vivisimo was chosen as the search interface. Velocity is a meta-search engine that combines results from multiple sources into a single results list, allowing users to search several resources at once. It is a web- and file-crawling system that can either query an existing search function or crawl a series of documents such as hypertext markup language pages, portable document format files, or Microsoft Office files. The search engine groups commonly occurring words and phrases from the results and creates “on the fly” clusters. Clusters help narrow the results of a broad subject search by organizing the results into subcategories. The development team identified designated fields, such as a title or a text snippet, to create the clusters. Users can expand the clusters to find more focused information. Because the HSLS website already included several Velocity-based search boxes, library staff had considerable expertise in developing applications for this technology.

As a result of discussions between the key physician and the development team, it was initially decided that the tool should focus on three subject areas: diagnosis, therapy, and patient education. A tab-based search box was designed to allow users to search each of these areas. A mix of resources was identified for each search tab. The resources included licensed textbooks such as Interpretation of Diagnostic Tests, drug resources such as Micromedex, and patient education information from resources such as MedlinePlus. Clustered results of test searches were analyzed, and resources were removed and new ones added, depending on the results. For example, if the search resulted in a small number of clusters or items retrieved, an additional resource was added to increase the retrieval and the number of clusters. Similarly, if results were overly repetitive, the mix of resources searched was reviewed and sometimes altered. This remix occurred for each search tab until the key physician and development team were satisfied with the results.

The tool was named Clinical-e, and demonstrations to physician groups began at the end of 2007. In February 2008, Clinical-e was demonstrated to the medical center's information technology (IT) physicians' cabinet members, a subgroup of PAC, and received positive feedback. At this group's suggestion, an evidence-based medicine (EBM) tab was added to Clinical-e to search resources such as the American College of Physicians Pier and practice guidelines in PubMed. As a result, the Clinical-e tool now contained four subject search tabs: diagnosis, therapy, EBM, and patient education.

In the summer of 2008, this revised version of Clinical-e was introduced to the full PAC. Feedback from this demonstration led to the addition of a drug search tab. In the initial development phase, the library team and key physician had decided not to include a tab for drug searching, because they believed that drug information was already easy to locate. From the discussions during this PAC meeting, it became clear that if physicians were to accept this tool, it should include a broad range of useful subject areas in one interface. Subsequently, a “drug search” tab was added to Clinical-e, the therapy tab was changed to “diseases,” and resources were once again changed. The tool now had five subject search tabs: diagnosis, diseases, drugs, EBM, and patient education.

Structured usability testing of this version of Clinical-e was conducted using a volunteer group from PAC. This process included both an online survey and focus groups. The twelve-question survey, designed to be taken after searching Clinical-e, had a low response rate, as the participants apparently preferred direct communication with the key physician or in the focus group setting. The focus groups, consisting of IT physicians' cabinet members and PAC volunteers, began with librarian demonstrations of navigational and design elements, such as tab searching and results clustering. Group discussion followed, with participants volunteering what they considered to be meaningful keywords and search phrases.

Feedback from the focus groups led to changes to the tab arrangement, automatic appearance of a cursor in the search box, and further refinement of the resources searched. Initially, Clinical-e was designed to save the search terms in the query box as users changed tabs. The development team thought this would allow users to easily progress from one tab-based search to another without reentering the search terms. Focus group results suggested that users did not like this feature, and it was removed. Figure 1 shows this version of Clinical-e, and Table 1 lists the resources chosen for each subject tab.

Figure 1.

Clinical-e

Table 1.

Resources in each subject tab

RESULTS

In the fall of 2008, Clinical-e was linked into the eRecord. At that time, the key physician described this at a PAC meeting as “the marriage of patient information and disease information.” The library team decided on a soft rollout to identify problems and track user searching patterns.

Figure 2 illustrates the number of searches by subject tab for the first six months after Clinical-e was linked into the eRecord. The use of Clinical-e was steady in these first six months but less than anticipated. The diagnosis tab was the most used, with drug information a close second. The diseases, EBM, and patient education subject tabs had very low use. The team also observed that tabs were searched with diminishing frequency from the left side to the right side of their arrangement over the search box. Initial usage analysis indicated that clinicians searched the diagnosis tab most often, probably because it was the default search tab when Clinical-e was opened. As a result, the number of tabs was reduced by combining the diagnosis, disease, and EBM into one tab.

Figure 2.

Number of searches by subject tab for the first six months of Clinical-e

DISCUSSION

The challenges in this process were many. There was no additional funding for the development of this clinical tool. The library team worked on this project in addition to their regular job responsibilities, which meant that often progress on the project slowed due to a team member's other commitments.

The scope of UPMC's eRecord initiatives dwarfed the library project. Because of the complexity and fast pace of eRecord development and roll out, it was often difficult to identify technical and clinical partners and keep their attention. Once the key physician stepped forward to champion this project, the development process moved along more smoothly.

This process involved working across two different institutions, as the library is part of the university, and the eRecord and PAC are UPMC. Because the library team did not include clinicians, the team had no direct access to the eRecord. After Clinical-e was linked into the eRecord as an embedded search box, the library team was not able to directly demonstrate Clinical-e or to teach physicians and residents how to locate or use the tool from within the eRecord.

In retrospect, the development team may have been too quick to change Clinical-e in response to feedback after presentations to groups of potential users. Because the team did not have a planned revision schedule or a well-designed process in place to analyze feedback, the result was continual changes to Clinical-e. This problem was exemplified by the addition of new subject tabs and the subsequent re-combining of these same subject tabs. A further undesirable outcome of these frequent changes was that Clinical-e was not stable enough over time to conduct an extensive evaluation. The next phase of development will include an evaluation component and a planned revision schedule.

The positive outcomes of this project greatly outweigh its challenges, however. The library is clearly positioned as a partner in the development of the eRecord. Evidence-based clinical care is enhanced as the library's knowledge-based information resources are accessible at the point of care. Clinicians can easily search multiple resources with one click, thus broadening their information horizons by introducing them to new information resources that may provide better or more direct answers than their familiar information standbys. The development process benefitted the library as it brought together team members with varying perspectives (e.g., reference, computer services, management, programming) to collaborate on a single objective. The team spent considerable time studying the content, structure, strengths, and weaknesses of its licensed full-text resources from the clinical viewpoint, thus developing more informed cost-benefit analyses for renewal decisions.

CONCLUSION

This case study described the lengthy development process to build an information tool that directly searches knowledge-based library resources from the institution's electronic medical record. The development team chose to begin with a relatively small pilot project to gain credibility and to build from there. As this paper was written, the team was changing its approach from an embedded, tab-based search box to a web portal linked from the eRecord and from the library's public home page. The team has also begun collaborating with the eRecord interoperability group that is tasked with creating a single unified patient record incorporating data from the eRecord's multiple information systems, formats, and sites. It is hoped that this new partnership will lead to implementing a mechanism to pre-populate the search box with patient-specific information from the eRecord.