| Site Index |
|
|
         |
|
|
|
|
|
|
|
|
|
|
Health Systems IMPLEMENTATION
Epic's experience in implementing a wide variety of clinical, access, and financial systems extends back 25 years. As a growing company dedicated to changing the way health care is delivered for the better, much of what we encounter is necessarily new and challenging. There are, however, as in any field, certain constants and useful propositions that can be shared and employed to the same profit in new endeavors as well as they were in the old. Although the idea--and, even more so, the fact--of an enterprisewide health care information and automation system is relatively recent, successfully installing one depends on many of the same facts as other implementations. We would like to share with you what we have learned during the many years of implementation. The initial implementation of a health care automation and information system forms part of the foundation for the transformation of health care. It is not that transformation itself. Although it is important not to replicate inefficient workflows or poor data collection, the focus of the initial implementation should not be to explore brave new worlds but it should be on building the ship and learning to navigate. More concretely, the proper focus of the initial implementation should be on those things that will allow the greatest long-term benefits: achieving widespread use of the system across as many care settings, specialties, and departments as possible; standardizing data representations; and establishing long-term interaction and communication plans with the user community. If these three goals are achieved, an organization will be well poised to take advantage of sophisticated tools and techniques that will change the way health care is delivered. Three major areas of an implementation must be well understood in order to maximize the chances of its success: standardization, variations across care settings, and training strategies. Adaptation and Standardization The process of implementing a health care automation and information system begins with modeling the organization in software. The degree to which adaptation of the system to the organization is successful places an upper limit on the degree to which adoption will be successful. A mature and well-designed system will allow an organization to dictate how the software works rather than the other way around, and the system will allow for a great deal of variation in how different parts of the organization operate. Although that is the case, choices must be made about how detailed a model is necessary for a complex organization. In a very large organization, a precise model is far too expensive to be a realistic proposition. We can liken the software modeling phase of the implementation to making a map of a geographic region. The more details there are, the more topography represented, the larger the map must be, and the longer it will take to create it. Its size may make it impractical to wield as a tool; its expense in time and resources may make it impossible to afford. A pocket-sized map giving a general but accurate knowledge of the terrain is much more useful and can be created in a reasonable amount of time, making it also affordable. It won't indicate every tree root to step over or every stream to cross, but if you know how to step over roots and cross streams, you don't usually need that information anyway. With a health care software system, you don't need a specialized workflow or data collection form for every possible clinical presentation or registration situation. You need a few tools that encapsulate the variation in a majority of your work practices, some special tools for infrequent but important situations, and the ability to branch away from standard templates in the remaining situations. That means that you can model the large-scale features of the organization, mapping them to system functionality and tools, teach users how to handle unknown terrain, and get them using the system in a reasonable amount of time. The question inevitably arises--which organization to model, the existing one or an ideal one? This question leads to a discussion of standardization and rationalization. Standardization, improperly pursued, is often the rock on which good implementation founders. Two kinds of standardization deserve attention: that of workflow and that of data representation. Standardizing Workflow Workflow standardization simply means taking two or more similar parts of an organization and having them perform some work function in the same way. As a result, people in similar roles in the different parts of the organization perform the same tasks in the same sequence using the same tools and interact with users in other similar roles in the same way. Two kinds of motivation generally exist for standardizing workflows during an implementation. The first is that it is easier for an implementation team to design a system around one workflow for everybody rather than around everybody's individual workflows, even though a properly designed workflow automation system will allow for a great deal of practice variation. The second motivation exists when there is an agreed-upon best practice workflow that the organization would like to adopt or when there is reason to think that such a workflow might be discoverable. The ease-of-implementation motivation typically leads an organization to analyze workflows to find commonality in the component steps and wherever there is commonality to make it standard. The sum of these steps then becomes the standard around which a workflow system is modeled. In this form, workflow standardization can be highly artificial and abstracted from the concrete realities of the clinical workplace. Lacking any real motivation to comply with the standard, users of the system will find ways to subvert the standard to reproduce necessary pieces of the original workflow or pieces perceived as necessary. In many cases, this will lead to a breakdown in the standardization of data representation as well. The tradeoff in this method of standardization is between ease of implementation and risking the integrity of the design and the data generated during the execution of the workflows. The second motivation to standardize workflows assumes there is a best practice or that one is discoverable. Agreement on a best practice or even the necessary criteria in the organization is very rare prior to the implementation. The larger the organization and the more vague the criteria for what counts as a best practice, the more difficult it is to arrive at this level of agreement. A more difficult tradeoff is involved here: implementing best practices for clinical care, shorter registration times, or reduced billing cycle times are often key factors in deciding to implement a system. On the other hand, a requirement to implement best practices in a large organization, whatever the criteria, can easily increase the time to go live beyond an interval that will be considered acceptable, successful, or affordable. Epic's experience suggests that workflow standardization should play a minor role during the initial implementation. This isn't to say that there aren't some workflows that couldn't be standardized: if there is already general agreement on some key workflows, they should be standardized. In general, however, standardization, especially in the best-practice sense, is best addressed during subsequent optimization efforts rather than during the initial push to go live and rollout. Workflow standardization can usefully be contrasted with workflow rationalization. The latter involves analyzing a process into information and patient flows, analyzing these into their component steps, and then improving efficiencies or removing redundancies. Once this has been accomplished, system modeling should address the rationalized workflow. Rationalized workflows need not be the same across an organization. Although a good argument could be made that only rationalized workflows should be standardized, it does not follow that all rationalized workflows should be. There may well be defensible reasons behind workflow variations across the organization, but there is usually no justification for redundancies. Standardizing Data Representation Although workflow standardization serves a minor purpose during the initial implementation of a successful health care automation system, the standardization of data representation should occupy a large slice of the system modeling time. Data representation determines how information that is collected during patient care, registration, or other use of the system is stored and retrievable at a later time, how it can be compared with other data, and the ease with which both of these can be done. Let's take the example of a lab test. We'd like a red blood count value to be stored the same way in the information repository whether it was obtained in the hospital, in a clinic, in California, or in Ohio. Similarly, when we query the system for all of a patient's red blood count values, we'd like to retrieve them all--regardless of their origin--and be able to trend them over time. This task requires a common vocabulary for describing lab values. We would also like a common vocabulary for describing flowsheet rows, care plan interventions, diagnoses, and any number of other data elements. Standard vocabularies are available for same data elements, such as CPT codes for performed procedures or ICD for diagnoses. Many data elements, however, require standardization during the course of implementation. But data retrieval at the point of patient care is not the only purpose for standardizing vocabularies. A standardized vocabulary is also a prerequisite for sophisticated clinical studies, population management, solving billing problems, and a number of other transformational activities that can be pursued after the initial implementation and rollout are complete. Care Setting Variations Installing an enterprise typically involves two or more care settings, including hospitals, physician offices, or ancillary service departments. Many of the systems' users will work in more than one care setting. For example, physicians often work in their offices and one or more hospitals. Different care settings obviously have different workflow and data collection requirements. A well-integrated system will account for this variation by using similar pieces put together in different ways rather than as different pieces altogether, as you would find in a nonintegrated or interfaced system solution. Another variation to account for is that of the linearity of workflows. For example, a physician office visit is typically very linear, flowing from registration to check-in to collecting vital signs, placing orders, writing a note, and signing an encounter. During the course of a hospital admission, however, many caregivers and other users will interact with the patient in an unpredictable sequence. Nor will the data collection and data presentation requirements of these interactions be completely predictable. When analyzed, it is typical that component pieces of these interactions show themselves to be linear, even though the course of care may not be. An enterprise system should account for these variations in linearity by using similar workflow navigation tools as in linearized care settings but to allow for easy departures from linearity. For example, a rounding navigator can collect together all of the component pieces of system interaction required for a physician doing rounds (reviewing meds and vitals, placing orders, writing a progress note) while keeping I&O flowsheets, results review, and the interdisciplinary care plan for the patient one click away from the navigator. The rounding navigator will be instantly familiar to someone who sees patients in the office, having similar components but with the required variations in order and content. An enterprise system should also use similar data representation methods in different care settings. Even though the data originates in a variety of settings, it is often very similar data and should be represented comparably. For example, vitals taken at home, in the office, or in the ICU should all be represented in the enterprise information system in a way that allows their direct comparison. The same is true of lab values, allergies, and medications. A well-integrated enterprise automation and information system will reduce training time by using similar navigation and data collection tools across the variety of care settings and will allow viewing and interaction with data, regardless of its source, in a comparable fashion, thus improving patient care and the user experience. Training Strategies Different training strategies are suited to the nature of different care settings. In a typical physician office, the users are to some degree a captive audience. There is not a need to teach the users everything at once because you only have one shot at getting their time. Individual groups of physicians may come up on the system independently of their neighbors. In a hospital, on the other hand, there are many shifts of users, some of whom may only be in the hospital a few hours a week or even less. Furthermore, so many different clinicians and other potential system users interact with a patient that it becomes very important for all of them to be using the same system to document their patient care. The virtues of a well-integrated enterprise health care information system allow an organization to tailor the training experience to fit the needs of users in these different care settings. Importantly, a system that uses similar or identical tools and navigation methods regardless of care setting allows a user to become comfortable using the system in one care setting and then leverage that knowledge using the system in other care settings. For ambulatory sites, Epic has developed over several years a highly successful incremental training approach. During the course of three to four weeks, clinicians learn incremental sets of functionality. During the first week, basic navigation, chart and results review, and "In-Basket" tools are taught and used for the duration of the week. The following week, clinicians learn to place orders and document diagnoses. Finally, general charting and more advanced functionality are taught the third week. The training is typically a combination of classroom-based scenario development and one-on-one support. Computer-based training may also be a useful adjunct. In the hospital setting, it is important that clinical users in particular learn most of the basic functionality for a given phase of the implementation before seeing patients. Longer blocks of training are required to support this strategy, and large sections of a hospital typically go live all at once on a particular set of functionality. However, because tools are so similar across care settings, if clinicians go live first in their offices or clinics, the transition to using the same system in the inpatient setting is much easier. If it is possible to stage the rollout in this fashion, the benefits can be substantial--both with regard to training time as well as to ease of adoption by users. In any case, it is important to keep the scope of the training narrowed to the basics required for day-to-day patient care and related work. More sophisticated use of the system can be nurtured through regular user group meetings, online forums, or other forms of communication. Maintaining a manageable scope is just as important for training as it is for standardization and other aspects of the implementation. Setting and Managing Expectations and Scope Armed with this information about standardization, variation, and training practices, an implementing organization should spend some time thinking about what will and what will not be accomplished during the initial implementation and communicate that consistently to its user community. What will count as a successful implementation? This must be defined at the outset. Decide that, and then set the expectations to match the definition. Expectations set too low will result in employees asking pointed questions about the expense of the implementation and the scope of the changes they'll be asked to make in their work practices. Setting expectations too high will result in incredulity during the implementation (and unwillingness to be associated with it) as well as inevitable disappointment after the system is live. Although "internal sales" is an important activity during an implementation, it is possible to oversell the system being implemented, thus raising expectations beyond what is reasonable. The implementation's champions should publicly recognize the system's weaknesses as well as its strengths. For example, some tasks will definitely take longer using an electronic system (think CPOE). Acknowledge this, and also stress the workflow points where time will be gained, such as in locating clinical information, rather than downplaying justified worries about extra time spent placing orders. Managing expectations is inseparable from managing scope, which describes the schedule of modules and functionality as well as the breadth of user interaction expected at key points during the implementation timeline. It has been Epic's consistent finding that a successful implementation is one that defines a manageable scope for the initial implementation with the idea in mind that it will be the foundation for more sophisticated practices later. Focusing on the right kind and level of standardization and the encapsulation of variation across care settings will ensure that the implementation scope, in addition to being manageable, will also lead to success.
|
|
|
|
|
|
|
|
|
|
|
 |
|
