An integrated EHR at Northern California Kaiser Permanente

Abstract

As legacy information systems age, transition to newer systems is inevitable, but at times fraught with challenge. This brief article addresses some of the pitfalls, challenges, and benefits we experienced at Kaiser Permanente as we transitioned several key clinical information systems to Epic Systems for our integrated comprehensive Electronic Health Record (EHR).

Introduction

Kaiser Permanente is the largest health maintenance organization in the San Francisco Bay Area with over 5000 shareholder physicians and serving a diverse population of over 3.2 million members. A decision was made to transition to Epic Systems for inpatient, ambulatory care, and billing/practice management at Kaiser Permanente in 2003. With a rich history of clinical electronic systems since 1994, we faced several expected and some rather unexpected challenges that needed to be addressed to make this transition acceptable to our clinicians. These challenges can best be categorized and defined as:

• •Technical challenges
• •Concerns over unexpected decreased usability or functionality as compared to existing systems,
• •Integration issues for those legacy systems that were not transitioned and needed to work smoothly within the Vendor EHR framework.
• •Expanded work burden of new and added functionality such as Evaluation and Management (E+M) coding, and the impact of secure patient messages and virtualization of what had traditionally been office based care,

How the deployment and technical teams overcame these obstacles, as well as my impressions and observations as the physician leading the ambulatory deployment are discussed in this review.

Discussion

Background

The first paperless charting and data systems went live at NCAL Kaiser Permanente in 1993. A comprehensive IBM DB2 Clinical Data Repository and a mainframe front end clinical system called CIPS (Clinical Information Presentation System) went live in 1995. At its peak, this system which included a wide variety of source system interfaces as well as charting tools for documentation and inbasket, was used by as many as 10,000 unique login clinical users daily, viewing over one million screens. This system was ubiquitous, available in over 25,000 personal computers and mainframe terminals in virtually all areas of the ambulatory clinics and hospitals. Improvements in the system were many, and with the addition of an electronic inbasket, and online documentation in 1999, all paper transcriptions, labs, and imaging reports were no longer printed. Order entry was confined to pharmacy orders, and was largely done in separate systems called “eRx” and “eRefill” which were developed by the Kaiser Permanente Pharmacy Informatics Team.

1. Technical challenges

As we began transition to the vendor in 2003, several technical challenges arose that were not present for our legacy systems.

Performance and redundancy

Performance of a “mission critical” clinical system is foundational and assumed by the end user [1]. Because of our size and scale, the vendor proposed a distributed architecture; with six instances (distributed databases based on patient location needed to scale the vendor system for an organization our size) running in the geographic regions of Kaiser Permanente. Each patient record needed to be “homed” at a particular instance (functionality initially called CareEverywhere and later called Inter-Connect by the vendor). When patients were seen outside their home instance, such as for a referral, urgent care appointment, or inpatient admission, charts were “synched” across those instances such that each record was complete even if they were homed in different instances. The performance of this in real time with patient care was initially not adequate, resulting in complaints from clinicians about delays in care, and as the size of the charts continued to grow, it became worse. Sometimes the synching or charts could take several minutes or longer. We worked with the vendor’s technical team as well as our own Kaiser Permanente IT organization to improve performance by software improvements as well prioritizing what information was most critical for immediate care.

In addition, as we had only paper downtime procedures which were later scanned into the electronic record, our availability was critical, and this ultimately led to the decision to have completely redundant citrix server farms in Napa and in Corona California, with the ability to switchover to read/write capability in minutes for a scheduled or unscheduled outage. As the first and only Epic client to accomplish complete redundancy, a number of technical and operational challenges were experienced and overcome in the course of this major effort, the description of which is beyond the scope of this brief review.

Back loading of legacy data

As others have written, backloading of clinical data and orders can be challenging [2]. Since we had electronic data going back to 1993 stored in our Clinical Data Repository which was felt by clinicians essential to the transition to the vendor system, we elected to backload data on lab, imaging files, clinical documentation, allergies, and all transcriptions including operative reports and discharge summaries. After analysis, medication list backload was felt too risky due to formatting and dispense/refill discrepancies. Also, because of the size of the files, it was elected to backload only 2 years of imaging studies. After extensive testing, this data was loaded into the vendor system in the 48 hours prior to our real time interface go-live in 2003.

One interesting back-story relates to the problem list in our legacy systems, which was clearly not well maintained and lacked “guidelines” as to what was an appropriate chronic condition. After go-live at our first site, clinicians, particularly in adult primary care (APC), insisted that the loading of the problem list was absolutely required for a smooth transition. After meeting with our Adult Primary Care Chiefs, we elected to backload a subset of ICD9 coded diagnoses that represented those in which there was general agreement by this clinician leadership group that they should always populate the problem list. A difficult issue shared with other organizations is the ongoing maintenance and cleanup of problem list in the electronic record. This continues to be a daunting challenge for our organization several years later, as it is with many other healthcare organizations now utilizing an electronic record. It is the topic of many papers and discussions at various national meetings [3].

2. User acceptance and functionality

Inbasket

Our mainframe legacy system had a robust inbasket for labs, imaging results, and editing/signing transcriptions. The mainframe “3270” reports of the lab data as well as the imaging and transcription reports presented a very clean and easily read display, even with the ASCII text and formatting. As we went live with the vendor system, we chose to expand the inbasket functionality to include a number of “folders” that were not present in our legacy application. In addition to this, the display of the lab data especially when there were several labs resulted together, caused many complaints of scrolling excessively, not being able to see a display of all the results in a single screen, and not being able to “flow sheet” prior results as was present in our legacy display. In response to this, shortly after go-live we chose to deactivate the vendor inbasket functionality, and worked with them to develop “print groups” (the vendor’s term for custom reports) that were more tabular in display and incorporate the “component” link that enables the “flow sheet” of all prior results presented in a clean graphical display.

Additionally, we developed several standardized “view only” flow sheets (for example an Adult Primary Care view or a diabetes view that in a single screen table format displayed all relevant labs, vital signs, weights, etc). For refills, a legacy system called “eRefill” developed by our pharmacy informatics team at Kaiser Permanente had several features that were lacking in the vendor refill functionality. We worked with our pharmacy team as well as the vendor to develop an “EZ refill” single click function that replicated the legacy features. Another example described by some as the challenge of controlling “information overload” [4] was a policy of automatically copying (cc'ing) a Primary Care Physician (PCP) on all hospital discharge lab results. This caused concern from busy PCPs with inbasket “clutter” and difficulty in trying decipher what was “noise” (fyi information) and what was “signal” (actionable and essential). It was felt that the hospitalist should either make an active decision after reviewing the result to forward it to the PCP after discharge, or manage the result themselves. The automation of sending cc’s from our legacy lab system was stopped. We continue to try to limit the “folders” that clinicians see in the inbasket and try to balance important information from “FYI’s” and what is perceived to be information overload and “inbasket spam” as it is called by our clinicians.

E+M coding

After deployment of the ambulatory system, an Executive Leadership decision was made to require Evaluation and Management (E+M) coding on office encounters. Although this has been done for years because it is needed for billing in the fee for service model, because of our capitated model at Kaiser Permanente it was not required. As more members enrolled in plans with high co-pays and deductibles requiring a bill to be generated, and as the need to present data of care acuity was requested by our purchasers, we needed to require that our clinicians include E+M coding. In an effort to make this as easy and non-intrusive as possible, we developed custom code within the vendor application that enabled analysis of the documentation and orders, as well as complexity of medical decision making, to provide a suggested E+M code. This automated approach greatly improved our clinicians acceptance of the added work burden needed to calculate an E+M code, and has proven to provide a very high degree of accuracy of the recommended code to the documentation.

Training

A well known transitional issue that we needed to address was how to maintain access and service during our deployment [5]. We chose to initially do 12 hours of classroom training (three- four hour -sessions) and reduce patient schedules for the first 2–4 weeks after go-live. This significantly and adversely impacted patient access in both primary and specialty care. We also used large numbers of go-live support people we had trained in the vendor system in both the clinic and in the hospital to supplement the classroom training. Web based training was also developed and used primarily to familiarize clinicians with the content of the classroom training prior to the actual session. Feedback some years later continues to reinforce that having experts (either trainers or “super user” clinicians) in the clinic setting at the time of real patient care is more effective than time spent in the classroom, and we continue to modify how we do new hire as well as new release and functionality training. Training the workflow, instead of training the functionality, has also become a key mantra based on years of feedback from users for our training team as well.

Alerts and reminders

At go-live, one of the perceived benefits of the vendor system over our legacy applications was the ability to provide real time and robust decision support. We quickly discovered that exposing busy clinicians to Best Practice Advisories (BPA’s) in large numbers generated a lot of complaints [6]. Busy clinicians felt they were intrusive and not specific nor granular enough, nor were they actionable, to be helpful in a large majority of cases. We chose shortly after go-live at our first sites to expose only the severity level one First Data Bank (FDB, the pharmacy expert system widely used by EHR vendors as middleware) drug/drug interactions. Level one severity in FDB represented those that were felt to be very significant and a patient safety concern. In addition we limited to a total of 75 alerts for alternative medications (largely non formulary reminders) to alleviate some of the volume of alerts clinicians were experiencing. We also began to monitor data that reflected the user behavior to all BPA’s to see if they were effective in achieving the desired goals. If they were largely ignored, we initiated a communication and training effort to see if that would impact the use of the alerts, and reviewed the data on our goals to see if we could impact them in other ways, such as additional educational sessions, if the BPAs continued to be ignored. Also if the goal was achieved and stable (a good example was a BPA for women over age 25 to not do routine chlamydia screening) the alert was removed so as to limit the intrusiveness and number of alerts when the clinicians were already acting at a level that was acceptable in achieving the quality goal. Fine tuning the balance of alerts in terms of numbers and specificity to make them useful and as important easily actionable continues to be a challenge.

3. Integration of legacy systems with the vendor

If we could not match in essential functionality with the vendor to that of our legacy systems, we chose to take the path of continuing to use our legacy systems and attempt to provide integration within the EHR. Our mainframe scheduling system developed internally at Kaiser Permanente (called “PARRS”) and also our referral system called “eConsult” were not discontinued at the vendor transition. The ability to integrate key functions of these systems into the comprehensive EHR however proved more challenging than we anticipated. With our patient scheduling system, we created an interface to the vendor “Cadence” registration system, and by using encounter mapping from the scheduled appointment were able to point the patient on the provider schedule to the appropriate vendor visit navigator.

Appointments that were not correctly booked, however, proved difficult to re-register and have the appropriate vendor visit navigator and tools in a way that was seamless to the provider and registration clerk. Also seamless integration with the patient facing web portal (called kp.org) without using the native vendor scheduling system has limited our ability to automate the sending of questionnaires at the time an appointment is booked.

With our legacy referral system, we encountered billing issues when imaging tests such as MRIs and CTs were referred in “eConsult” but no order was placed in the vendor system and no ICD9 diagnosis was associated. Ultimately, we developed an automated web service that enabled a generic “modality” order to be pended in when a referral was placed, and this was changed to the specific CPT 4 coded procedure in the radiology dept, and then associated with the existing diagnostic code, so that the diagnosis was linked to the procedure for billing. Unexpectedly however, we discovered that when there were existing orders in the encounter that were neither pended nor signed, the web service did not work because of the “orders lock” from the vendor’s software, and the pended order was not placed. We continue to struggle with the issue and are looking at innovative ways to overcome the order lock function of the vendor in this specific workflow scenario. In summary, integration of existing legacy systems into a comprehensive electronic record can prove more challenging than thought and unroof sometimes hidden consequences that are difficult to overcome.

4. Changing the nature of the work by enabling electronic systems

Shortly after go-live of the kp.org secure messaging system (i.e. the vendor’s “MyChart”) it became increasingly apparent that the work could and in some cases should be shifted from the office encounter to more virtual encounters [7]. As the enrollment in kp.org surged to over 60% of all Kaiser Permanente members in the years after go-live, and the number of secure messages increased to over 6 million annually, clinicians found ways to modify their management of patients to include secure messaging. The addition of the ability for patients to attach jpg images and later pdf documents to their messages also changed the way clinicians could gather and manage patient information.

We recently launched smart phone versions of kp.org that enables key functions such as viewing lab results, secure messaging, viewing preventive health needs, and creating appointments. This is in keeping with the well documented shift from the desktop to the laptop to now mobile untethered smart devices (mHealth) [8]. The impact of “virtualizing” care from the office to electronic is still to be determined, but what is clear is that patients and clinicians both see this as a very appealing and useful alternative to the traditional office encounter or to telephone messaging.

Conclusions

In deploying the world's largest private clinical information system, Kaiser Permanente experienced a number of issues related to the transition. This brief review discusses some of these issues such as the impact on access, technical challenges that impacted performance and availability, perceptions of decreased functionality in the new system from that found in older legacy systems, added work burdens and changes in documentation required as a result of E+M coding, and still evolving changes such as the impact of enabling increasingly virtual and mobile care.

We were able to address these challenges through discussions and agreements with clinicians and leaders on what was needed in the new system. We pursued enhancements that were both technical in the case of performance and redundancy, and functional in the case of automated tools for E+M coding and reducing the number and relevance of alerts and reminders. Overall, as the Physician leading the ambulatory deployment my impression is that the acceptance of the Kaiser Permanente’s HealthConnect system has been remarkable with both our clinicians as well as our patients. At our go-lives, I often would show the slide below from the vendor “collection” at their training center that shows an evaluation that says... “you will have to peel my cold dead fingers off my mouse before I will go back to paper” (Fig. 1). Although not every end user would agree, our focus on user acceptance and improving the performance and functionality of the system was very successful in gaining user approval in this difficult transition.

Fig. 1.

Slide used at deployment „kickoff“ meetings

Conflict of Interest

The author has no conflicts of interest in this paper.

Human Subjects Protections

Human subjects research was not conducted or reported in the preparation of this paper.