Planning Your EHR System: Guidelines for Executive Management

Transcription

1 Planning Your EHR System: Guidelines for Executive Management Prepared by: Information Technology Partners for the Behavioral Health and Human Services Community

2 ACKNOWLEDGEMENTS A Joint MHCA/SATVA Task Force worked together in to produce this paper. Mental Health Corporations of America (MHCA) is an alliance of select behavioral health organizations. It is designed to strengthen members competitive position, enhance their leadership capabilities and facilitate their strategic networking opportunities. [Website: The Software and Technology Vendors Association (SATVA) is a non-profit trade association representing the software companies who serve the behavioral health and human services community. [Website: The content grew out of the Task Force s previous conceptual work in that they then presented at several national conferences. The Task Force is uniquely constituted by leaders of treatment provider organizations who implemented and use electronic health record systems (EHRs), and leaders of software companies that supply EHRs and help support their implementation. The Task Force members co-authoring this paper are: Representing MHCA Frank Collins Director of Information Systems MHCA Tallahassee, Florida Rick Doucet, MA Chief Executive Officer Community Reach Center Thornton, Colorado Grady L. Wilkinson Chief Executive Officer Sacred Heart Rehabilitation Center, Inc. Memphis, Michigan Chris Wyre Chief Executive Officer Volunteer Behavioral Health Care System Murfreesboro, Tennessee Donald J. Hevey President/CEO MHCA Tallahassee, Florida Representing SATVA William R. Connors, MSW, President/CEO Sequest Technologies, Inc. Lisle, Illinois Michael Morris President Anasazi Software Phoenix, Arizona John Paton Chief Industry Strategist NetSmart Technologies, Inc. Dublin, Ohio Tom Trabin, PhD, MSM Executive Director SATVA El Cerrito, California Editor: Tara S. Boyter, Director of Communications, MHCA MHCA/SATVA, Permission is granted for the reproduction and distribution of this document in its complete version only and without amendment. 1

3 TABLE OF CONTENTS Section Page Background 3 I. Introduction 5 II. General Principles 7 III. Software vs Organization Driven Re-engineering 12...Organizational Assessment Tool 18 IV. Acquisition 20...Contract Negotiation Guidelines 22 V. Implementation 28 VI. Ongoing Use, Maintenance and Communication 38 Attachment A: Recommendations for a Request for Proposal to Acquire Information Technology Systems 2

4 BACKGROUND The application of information technology (IT) to support and improve the delivery of healthcare has evolved rapidly in the last several decades and now is considered an essential component of an effective business model. Its abilities to support tracking of patient information and coordination of human and capital resources to speed response times and to guide treatment are proving invaluable to administrators and care providers. The behavioral healthcare industry (in this paper, the term behavioral health is used to refer to services for both mental and substance abuse conditions) has not adopted and reaped the benefits of information technology at a similar pace for a number of reasons, many stemming from the financial realities of business. The size of the behavioral healthcare industry relative to general healthcare restricts investment dollars available for IT research and development. At the same time, financial pressures within individual behavioral healthcare providers further limit IT product development. Beyond financial restrictions are other factors that have slowed the IT revolution within behavioral health. The foundation of behavioral health care was built in community-based programs. Impassioned community volunteers often created these programs as storefront clinics that operated on very limited funds. The advent of the community mental health movement in the 1960s provided an organizational model and federal funding to provide clearer definition for these clinics. It stimulated additional state funding that further shaped the development of the system. Creation of the Medicaid program, development of managed care and the change to block grant funding were added as layers on top of what came before them, further defining and molding the delivery of behavioral healthcare. The result is an industry whose business is exceedingly difficult to automate. Each provider has attempted in its own way to preserve its local identity, its traditions and its ways of serving its community, making them inherently resistant to the application of standardized forms, practices and methods. Each state, in the absence of an over-riding central authority, has defined its needs and interpreted federal rules and regulations in its own way, resulting in vastly different and wide-ranging data reporting requirements. Compared to general healthcare, the scarcity of diagnostically based treatment protocols reduces the opportunities for the if this, then that scenarios that lend themselves well to automation. The industry s need for narrative clinical information further complicates the application of technology. To add to the difficulties noted above, the behavioral healthcare industry is riddled with negative experiences of IT applications. These negative experiences have further slowed the effective application of information technology to behavioral healthcare. Often providers believe that vendor products cannot meet their needs, and vendors believe providers do not maximize software capabilities. In spite of these obstacles, there is a growing body of experiential knowledge about the application of information technology to behavioral healthcare. The comprehensive type of application upon which this paper is focused is the Electronic Health Record (EHR) that includes functionalities to support both clinical and business operations. As defined by the Institute of 3

5 Medicine s Key Capabilities of an Electronic Health Record System (2003), an EHR System encompasses: 1) the longitudinal collection of electronic information pertaining to an individual s health and healthcare; 2) immediate electronic access by authorized users only to person- and population-level information; 3) provision of knowledge and decision support to enhance the quality, safety, and efficiency of patient care; and 4) support for efficient processes of healthcare delivery. What follows is an attempt to describe the EHR, distill the lessons learned from many EHR implementations, and propose a series of best practice guidelines. These guidelines are offered as suggestions for strategies and tactics that should contribute to the successful purchase, implementation and ongoing development of EHR systems, and for any specific business or clinical function that a purchasing organization might consider mission critical. 4

6 I. INTRODUCTION You have come to the realization that you want to add an Electronic Health Record (EHR) to your arsenal of corporate tools to survive and compete in this ever-changing behavioral healthcare environment. You ve already read several articles, papers, and maybe even a book, looking for the Holy Grail. You ve heard horror stories from your friends and colleagues about the almost insurmountable challenge that faces you. Yet deep down you know that if you re going to stay viable and maintain or grow market share this is a direction you have to pursue. Now you ve run across this paper and are wondering, What tidbits of enlightenment does this paper offer that I don t already know? What insight do these authors have that makes what they say credible? There was, and probably still is, considerable frustration within the provider community about choosing, working with, and understanding software vendors and their products. At the same time there is an equally high frustration level within the vendor community regarding providers. In 2004 a representative group of CEOs from MHCA (Mental Health Corporations of America) and SATVA (Software and Technology Vendors Association) began working together to identify areas in which both industries could improve to make EHR selection, implementation and conversion more successful. MHCA is a non-profit trade association of leading community behavioral health centers who purchase and implement EHRs and related software. SATVA is a non-profit trade association of major software companies who supply EHRs and other software to the behavioral health and human services community. After numerous meetings and conference calls we leading purchasers and suppliers of behavioral health software - finally came to consensus on what we want to say and how we want to say it. So what can we tell you that is different from what you may have heard or already read? Some of what is said here has been reported in great detail in a number of other publications. On the other hand, we think we ve added a little bit different twist that you might find interesting and helpful. You can be assured that each issue has been discussed in great detail from both the provider and vendor perspective and that there is consensus among this CEO working group that the issues contained in this document are agreed to by the two associations represented. This paper was written by and for executive-level management. With that said, and in very simple terms, here is what you as an executive of a treatment provider organization - will find. There is no easy way to move from a paper system to an EHR, but you have it within your power to make the implementation smooth and positive. Without CEO/executive management support and involvement chances for success drop dramatically. Despite your perception on the front end, your business processes will change, and they will change for the better as a result of EHR implementation. Compliance with HIPAA and other regulatory requirements will be much easier to manage and maintain with an EHR than with a paper record. You will have more data, especially real time data, available to you. The system you choose will be only as good as the effort you and your staff invest in its implementation. 5

7 The culture of your organization will change significantly. Resistance to that change in culture will probably be greater than you anticipate. There is tremendous potential for the EHR to enable and facilitate significant improvements in clinical practice, client safety and client outcomes. The clinical and economic justification, or the Return On Investment (ROI), will become evident. In the following pages much more is said about each of these topics. It is our sincere hope that you are intrigued enough with what we have said thus far to read further. The authors commitment to provide clarity to these issues is huge because we realize that failure in implementing an EHR represents failure not only for the provider but also for the vendor, and too many of these double failures may doom both industries. Providers and vendors agree that the process of implementing an effective behavioral healthcare IT system, and specifically an EHR, is difficult and truly complicated. We have found that once you have seen one implementation, you have seen one implementation. It is clear, however, that there are some core guidelines or principles that can make the process significantly easier and more cost effective for both provider and vendor. 6

8 II. GENERAL PRINCIPLES The behavioral healthcare environment represents a unique and complex culture. Behavioral health organization staffs are composites of professionals and non-professionals. They are acutely aware of cultural issues related to those they serve and in most cases are knowledgeable of their own cultural complexities. Their employees, clients, processes and practices are seldom automated. The business of helping people remains primarily a process supported and delivered by many individuals via a paper system. While for-profit companies have pressed to automate and reduce human resources through computerization, non-profit organizations are at least ten years behind in the use of technology. This slow evolution toward automation may be the result of funding, lack of competition or possibly a symptom of organization/market resistance. As organizational culture profoundly affects technology implementation, so in turn will technology profoundly change organizational culture. We have identified seven general principles that we believe will facilitate selection, purchase, implementation and use of an Electronic Health Record. The remaining portions of this paper address these principles as they apply throughout different phases of the project: (1) Executive management support is essential. (2) Project management leads the way. (3) Corporate culture will play an important role. (4) Resistance to change should be expected. (5) The impact on financial and human resources is significant and continuing. (6) The customer/vendor partnership must be nurtured. (7) Clinical value is at the heart of the project. Executive Support Selection and implementation of an Electronic Health Record is a large-scale, long-term project involving investment of significant financial and human resources. It requires active Executive Management interest, participation and commitment throughout all phases of the project. Quite likely the idea, vision or desire for an EHR emanated from the executive offices. When it s time to move the idea forward, management must become part of the project, beginning with product evaluation and selection and carrying right on through to implementation. Wide-ranging projects, such as conversion to an EHR, should not be new to the organization s Chief Executive Officer (CEO) or Chief Operating Officer (COO). These executives are entrusted with a global view of the organizational system they oversee. By definition as well as job description they should be comfortable with complex, multi-system projects. CEOs and COOs are asked regularly to think through issues in multiple dimensions across a variety of systems. No set of projects envelopes as many resources and systems as does the EHR. Selection and 7

9 implementation of an EHR system will be both a long term (strategic) and annual (operational) goal. Perhaps the first task for executive management is to establish this project as an organizational goal, rather than an information technology (IT) directive and to define the project as one of selection and implementation. This will set the stage for both executive support/oversight as well as organization-wide support (user involvement). Executive management dictates organizational culture and must determine, Are we culturally ready to deal with the changes that come with implementing an Electronic Health Record system? Many organizations feel pressured to adopt an EHR, but few take the time to assess their readiness, and most do not take into consideration the dramatic change that will be brought about by this new technology. An organization must review business processes, clinical needs vs. clinical desires, reporting requirements and resources as objectively as possible in order to prepare for an EHR. It is a difficult, tedious and introspective task. Many erroneously believe that the software vendor will deal with these issues during implementation. Failure to assess organizational readiness will be devastating, and assuming that the software vendor will solve readiness problems is irresponsible. Readiness assessment should be conducted with the same care and skill taken with assessing patients. Exploration of EHR goals and objectives should be discussed and documented from the start. Project Management Although there are many valid methods of management, we suggest readers adopt a standard project management philosophy to help achieve their new EHR goal. The objective of a project management philosophy and methodology is to provide a standard method and guidelines to ensure that IT projects are conducted in a disciplined, well-managed, and consistent manner that promotes delivery of quality products resulting in projects that are completed on time and within budget. There are many educational resources on the Internet for this form of management. One good source for all aspects of this type of project is provided by the Software and Technology Vendors Association (SATVA) at Leadership should begin to understand what EHR possibilities are available, where others have succeeded as well as failed, and what colleagues recommend. Executive management should assume the role of Project Sponsor. The sponsor ensures that the project is funded and that necessary resources are in place to guarantee project success. In addition they confirm management support, approve project scope, appoint the Project Leader, make resources available, contribute to timeline, maintain communication with software vendor management, participate in review meetings and approve the project s end result. The Project Sponsor should present the EHR project to the organization. Initial presentation of the project sets the tone for organizational acceptance and communicates its importance to stakeholders (staff, board, funding organizations and clients) right from the beginning. Executive management should explain to their staff how they envision a comprehensive, integrated clinical software system to be a vital organizational resource that will allow data collection, maintenance, management and utilization to support multiple functions and fulfill related compliance requirements. A fully empowered Project Team should lead the entire EHR project from product evaluation through implementation. The Project Sponsor should establish visibility at the project start and 8

10 maintain it throughout the project s life cycle. A project timeline of 18 months may require attendance at project kickoff and status reports on a monthly basis for the first year and more frequently in the final months. It should be understood that implementation of an EHR is not the same as a word processing installation. Instead it is a project that will create powerful systemic change. It will be a key tool that your organization uses to fulfill its mission providing efficient and effective service to your clients. Impact on Corporate Culture Expect implementation of the EHR to be profoundly affected by existing corporate culture. Likewise, know that the EHR itself will create changes in corporate culture once implemented. Your implementation plan will contain the framework for physical tasks associated with the EHR project. You need to adopt a plan/vision for the subsequent organizational change as well. Automation of many work processes is inevitable. The impact will be extensive, affecting business processes, work responsibilities, time management, methods of reporting, and record keeping. The benefits of centralized electronic data storage will greatly enhance the work of your staff and their ability to fulfill your organization s mission. However, such system-wide change does not come without difficulty. It is important to understand that there will be organizational challenges to the implementation of an EHR outside the technical aspects of your project. Examination of current business processes will undoubtedly bring opportunity for change. Organizations have policies and procedures to frame their data collection and information processes, but the implementation of an EHR will bring those policies to the desktops and charts of professionals as well as supporting staff. This is a profound shift for people. It will promote change from a flexible, individual interpretation of documentation to a standardized, detailed process of clinical information collection. Resistance to Change Do not assume that all of your staff is enthusiastic about the EHR project. Resistance to change is normal human behavior, but it can be managed effectively and overcome. Ignoring it or believing that you can simply impose the product on staff will prove far more damaging and costly than taking the time to address potential resistance early and constructively. Unlike administrative and financial staff, clinical staff has not dealt with technology as part of their dayto-day routines. By endorsing an Electronic Health Record you are claiming that standardization is ideal for the patient record. That opinion contrasts with some professionals belief that their art is rooted in the creativity of the clinical process. Here exists a key cultural shift for healthcare professionals. Standardized record keeping will support automated record checks for compliance and mandated data. Assimilating this change, along with learning new tools for their trade in an already overscheduled day, is challenging and seldom embraced happily by clinical staff as they are introduced to the EHR. Utilization of an EHR in behavioral health clinical settings is relatively new. Though many other aspects of your organization are most likely automated to some extent, care deliverers (social workers, psychologists, psychiatrists, nurses and other licensed professionals) have 9

11 worked successfully in a paper system until recently. These same highly skilled and successful care deliverers often are resistant to an EHR. It is important to understand that all change is awkward and uncomfortable, especially when it has potential impact on one s livelihood. An organization s ability to work with their staff in order to understand the hesitance and fear associated with the EHR is central in effecting change. Introduction of computers into the clinical setting will necessitate allocation of additional resources for basic and ongoing computer training and supportive materials to assist novices. Eventually the EHR will become part of the care-giving process, but people will always provide care delivery. This is an important truth to remember. Impact on Resources There are significant one-time expenses associated with acquiring computer hardware and software and developing staff skills to use them. Sticker shock should be expected. Be prepared also for the significant ongoing operational expenses associated with maintaining and enhancing what you eventually build. Information technology costs should be factored into your budget just as any other essential operational expense. Executive management must focus continually on the fact that EHR implementation is an organizational goal and work to align organizational resources to that goal. As if that is not enough of a challenge, it must be understood that your EHR project should evolve with your business needs, your technology capabilities and your understanding of how and where technology and your business needs can meet. Initial EHR implementation will bring an extensive amount of knowledge to your organization. This can and should become the impetus for future technology projects, enhancements or additional automation. Try as you might to determine your organization s specific needs and to evaluate the ability of software solutions to address those needs, it is only after you start the implementation that you will begin to understand that what you really need is not necessarily what you thought you wanted and that the automation of specific organizational processes will produce some new needs and eliminate many old ones. Importance of Partnership You should recognize from the beginning that you will be entering into a long-term relationship with a vendor. This is not just the purchase of a product. It is a decision to work together with a vendor to assist your corporation in automating the delivery and support of mission-critical functions, now and into the future. In personal relationship terms, this is not a date you are proposing; it is a marriage. As such, it will have its ups and downs, but it should be founded on the assumption that a healthy relationship is in the best interest of both parties. Understanding the importance of the customer/vendor relationship will impact all phases of your EHR project. As you evaluate products, one consideration should be how you feel about the vendor s potential to be an effective partner in the future development of your organization. As you implement the product you purchase, you will need to be prepared to nurture that relationship through difficult times and model appropriate partnership behaviors for staff. As 10

12 your organization uses the implemented EHR you will find things you wish you had done differently. A healthy relationship with your vendor partner will allow continued development of the program to enhance your operation and advance patient care. Clinical Value Information technology is too often viewed solely as an efficiency tool or a billing system. In fact, it can also serve as a powerful tool to improve clinical practice. By recognizing the EHR s potential to manage clinical information right from the beginning of your project and maintaining that focus through set-up and implementation, you will improve your chances of maximizing the value of the EHR for your organization. There is tremendous potential within the EHR to improve patient safety by suggesting courses of action tied to the data entered into clients files. For example, tracking and analyzing patterns of medication use by diagnosis or physician or any number of other variables and comparing those trends to client outcomes can enhance the role of pharmacotherapy. Warnings of contraindications, product warnings or other potentially harmful interactions or side effects can also be automatically raised by the EHR. The EHR can further development of clinical pathways and best practice protocols for your organization by linking a client s assessment to recommended services or service programs. It can speed the acceptance and use of evidenced-based protocols and practices by serving as the primary trainer, guiding staff to interventions suggested by the protocols your organization uses. While you should expect to achieve greater efficiencies in the management of information and in the billing of client services, keep a sharp focus on how you can put the power of the clinical information being stored in the EHR data base to work to support the delivery of client care. Work with your vendor from the very beginning to maximize the clinical value of electronic client information management. 11

13 III. SOFTWARE VS. ORGANIZATION DRIVEN RE-ENGINEERING Implementation of an Electronic Health Record in behavioral health organizations is an extraordinarily difficult task. Combine that notion with the fact that 30% to 40% of enterprise software implementations fail in all industries and the project you are considering becomes daunting. Yet the benefits of an EHR are so considerable that it is now likely a matter of when, not if, you will convert to electronic records. To understand the difficulties inherent in an EHR implementation let s contrast it with replacement of an automated billing system. When implementing a new billing system you are likely replacing one existing automated system with another. The discipline required for use of an automated billing system has already been instilled in your staff. There is consistency in use of billing forms, coding structures, and procedures across programs as well as locations. The staff directly interacting with the billing system are likely trained and skilled in automated systems and are highly motivated to implement the new billing system quickly to realize its benefits. Clinicians recording the source billing information were probably supervised to record the required information accurately and in a timely manner. Executive oversight of efficient billing and revenue management is a matter of course. Some of the staff are probably experienced in previous implementations of automated billing systems. In contrast to implementation of a replacement billing system, implementation of an EHR is much more complicated. Paper clinical records often have considerable variation not only between programs, but even within the same program at various physical locations or divisions. Furthermore there are likely to be variations in clinical practices and procedures even within the same treatment program, and this will be reflected in their clinical forms. Instead of the relatively few forms for billing functions, you may have a hundred or more approved clinical forms. Paper forms inherently are much more difficult to supervise for timeliness, completeness, and accuracy of information. Often there is no formal treatment protocol within the organization to assure that consistent problems, goals, objectives and interventions (or their equivalent) are followed in treatment plan development and administration. There is often significant variation among interventions identified on the treatment plan and among the services authorized and performed. Often clinicians are not expert in the use of computers and standard software, frequently not motivated to become so, and sometimes resistant to the use of computers or the structured treatment inherent in EHR systems. It is unlikely that a large percentage of your clinicians are expert in any EHR system, and it is common to have no clinical manager with experience in any previous EHR implementation. All these problems require major clinical management resources. So, what is the solution? Every behavioral health EHR software vendor is asked to consider the treatment provider organization s unique software requirements and expectations in order to accomplish a successful implementation. The vendor is rarely asked to assess the organization s capabilities for and depth of commitment to implementing the software until after the sale is made. It is critical for the treatment organization s leadership to assess the extent to which the organization wants and is prepared to work with the vendor on customization of the vendor s product. Your organization s EHR readiness - its combination of expectations, capabilities and commitment 12

14 will determine the extent to which your organization should attempt to customize standard EHR software and your eventual satisfaction with your EHR system. There are two basic approaches that represent the ends of a continuum of corporate readiness for software customization. One end of the continuum is what we call Organization Driven Reengineering, which works well in an organization that consistently and effectively follows defined and clinically managed best practices throughout its programs clinical and related business workflows. Under this approach you and the vendor will use the configuration and setup capabilities of the software to mirror those existing best practices. The alternative is what we call Software Driven Re-engineering. Many EHR vendors have used the consulting resources available to them combined with their experience with multiple EHR implementations to configure their EHR software so that it models best practices for clinical workflow, forms, treatment protocols, related billing practices, etc. Under the Software Driven Re-engineering model, the purchaser follows the clinical workflow best practices optionally with some modifications -- reflected in the vendor s model EHR software. To illustrate, if a startup organization that had no pre-existing clinical or business practices purchased an EHR system, they would in effect have an immediately built-in and standardized workflow designed by that vendor to reflect best practices. More commonly, if an organization with established but inconsistent forms and inefficient workflows chooses a Software Driven Reengineering approach, they will work with the vendor to make minor modifications to the software prior to implementation and will change their clinical and business operations to fit within the new and more standardized computerization system. Neither is an exclusive approach. They represent ends of a continuum that are intended to accommodate different combinations of need and readiness among treatment provider organizations. You may decide that some aspects of your clinical practice are already optimally designed and standardized and should be emulated by the software, while other aspects would benefit from an improved approach through Software Driven Re-engineering. For successful implementation we believe it is critically important that your organization first conduct a selfassessment to determine where on the continuum it should be. Organization Driven Re-engineering Model Under a pure Organization Driven Re-engineering model the vendor would completely adapt their software to meet the organization s needs. This would include building interfaces or forms that replicate the entirety of your paper-based clinical records, mirroring your existing clinical and administrative procedures and establishing all setup controls, coding schema, and menus to reflect your current standards. It also would include adopting your current format, process, and clinical model for treatment planning including incorporation of your existing structured problems, goals, objectives and interventions, problem identification methodology, goal resolution schema, and quality assurance oversight comparing treatment provided versus planned treatment. This is an extensive commitment for the vendor but generally within their capabilities. Keep in mind that extensive commitment equals considerable expense. 13

15 The primary benefit of Organization Driven Re-engineering is that it can improve the potential for successful EHR implementation because staff will be more familiar and thus comfortable with the forms and processes. Greater staff involvement tends to generate a higher sense of ownership and acceptance. If your organization follows a truly unique and well-defined treatment model, Organization Driven Re-engineering may be the only approach because standard EHRs are based upon somewhat common treatment models and workflow needs across many treatment organizations. If, as is more likely, your organization shares some aspects of clinical workflow and treatment models in common with other organizations, then the Organization Driven Re-engineering may still be an acceptable approach, but only if you have a very well defined clinical model and well designed clinical forms. You must also closely adhere to that clinical model and its related forms process in all programs and at all physical sites and have good quality assurance that demonstrates this adherence. Often all of these criteria are not in place. One valuable goal, almost a necessity for automated EHR, is consistency among all like programs within the organization. A single program operating in multiple locations, with each location following different clinical practices and using different forms and treatment protocols is a very difficult environment to clinically manage and to automate. It is reasonable to have different clinical models for different programs, but it is beneficial for like programs to have like treatment models with consistent clinical and administrative forms and their related procedures. The more variety you have within your like programs, the more difficult and costly it is for the EHR to support them. Another virtual necessity for automating treatment plans is a well defined and established treatment planning protocol of closely monitored problems, goals, objectives, and interventions (or their like). If your organization has not already adopted structured treatment planning of this nature, then just coming to agreement on appropriate problems, goals, objectives and interventions is a significant task. As noted earlier, it is not uncommon for there to be a hundred or more paper forms approved by an organization s Medical Records Forms Committee (if they even have one). There may even be additional forms in use without leadership s knowledge, let alone approval! By definition, a paperless EHR is comprised of only formally approved forms and will cause elimination of unapproved forms. Having excessive paper forms usually indicates poor design, in which case the vendor might recommend taking implementation of an EHR as an opportunity to eliminate duplicative and/or poorly designed processes and forms. Under the pure Organization Driven Re-engineering model you must replicate at your own cost the configuration or setup of scores of custom clinical and administrative forms. You must record all your own setup and table controls. You must refine your existing problem, goal, objective, and intervention treatment protocol to be compliant with the requirements of the software, and you must customize the implementation process for the software. Planning, preparing and applying that custom implementation method will often require considerable additional cost over using the vendor s implementation method reflecting the Software Driven Re-engineering model. It is possible that certain capabilities required of your current processes are not available in the software and will require enhancements. All these steps increase the time, cost and complexity of implementation and must all be done well for a fully successful 14

16 EHR implementation. Almost anything that increases time, effort and complexity of an EHR implementation increases risk as well. Even if your organization has a well-documented and consistent clinical model that is religiously followed, there remains a level of process re-engineering that must be performed to realize the full benefit of an EHR. Numerous paper processes exist solely as oversight to overcome the weaknesses of the paper system. In Organization Driven Re-engineering this merits close attention; many existing paper forms should be modified or eliminated. Anyone who has attended a Forms Committee Meeting for two hours while it was debated whether a particular question should be placed at the bottom or middle of a form will appreciate how much time this might take. Full efficiency in an EHR system is only realized by eliminating redundant and widowed processes. The vendor s model Software Driven Re-engineering system will have already purged these processes. Generally your company is a candidate for Organization Driven Re-engineering only if it has: 1. a well documented, consistent, well managed clinical model that you do not wish to change substantially; 2. a structured treatment planning process with predefined problems, goals, objectives and interventions from which the clinician can select for each patient; 3. adequate executive, project management and staff resources to manage the re-engineering process; 4. the willingness and ability to invest the additional time, effort, and money required, and 5. the willingness and ability to accept the additional risk involved. As mentioned previously, another qualification for Organization Driven Re-engineering is if your organization has a truly unique treatment environment. In that case Software Driven Reengineering can be unworkable, and your only option might be Organization Driven Reengineering. Whatever the criteria may be prompting the selection of an Organization Driven Re-engineering approach, you will need a very skilled Project Leader who has the time and ability to closely manage a process that will likely span 18 months to three years. The choice of approach taken by your organization has important consequences for the vendor s ongoing support of the EHR post-implementation. Your vendor will release periodic routine upgrades and new versions to its product to add functionality and/or improve product performance. As the vendor issues these upgrades it is possible the configuration of the Organization Driven Re-engineering may be impacted. Extensively customizing or modifying critical linkages in the standard product may with some types of products make these routine upgrades more difficult and potentially disruptive for your organization. You should ask the vendor to address their method for ongoing support for an Organization Driven Re-engineering as part of your selection process and when determining your implementation method. Software Driven Re-engineering Model The primary basis of Software Driven Re-engineering is that the vendor has used experiences with multiple EHR implementations and consulting services to develop a specific model of their 15

17 system that embodies best practices for clinical workflow, forms, billing procedures, etc. That system will then be delivered with predefined administrative and clinical forms that work effectively in most programs for most clinical environments. It is normally faster, easier, less costly and less risky to implement that model with minor changes than to try and adapt that system to the treatment organization s forms and procedures if they are not well standardized, The vendor may also offer an integrated billing system designed to work seamlessly with their model EHR. The vendor will have previously established all setup and coding schema related to both EHR and billing requirements as appropriate. They often have experience with common payer requirements in your state or region and can incorporate those into the setup controls. They will have an implementation plan tuned to this system, and can therefore provide required implementation services at a minimal cost with fairly accurate estimates of time frames, staff commitments, and implementation costs. If your organization opts for Organization Driven Re-engineering without being a good candidate for it, you will likely be making major modifications to your clinical forms and procedures to prepare for automation that will prove to be costly, challenging, and time consuming. You would in that situation save time and money and reduce risk by adopting the clinical forms and processes inherent in the vendor s model for Software Driven Re-engineering. Blended Approach to Re-engineering Rarely will the choice between Organization Driven versus Software Driven Re-engineering be completely clear-cut or totally one approach. Virtually all organizations require some refinements to the vendor s standard Software Driven Re-engineering model. You can expect to have certain programs, contracts or special treatments that require modification. Unless modifications are considerable, this approach is typically simpler than making the investment required of Organization Driven Re-engineering. Even if you opt for the Organization Driven model, you may want to implement the EHR in phases, borrowing an approach from the Software Driven model. First automate those forms and processes that can be supported readily by the vendor s model. Then start a new phase to automate the non-mission critical forms. The exception is structured treatment planning. If structured treatment planning is not already in place prior to implementation of the EHR, doing so has such a major clinical impact and requires such extensive clinical training and support that it is best to defer implementation of structured treatment planning until the second phase. Interestingly the forms and processes that are the most pristine, well documented, consistent and well managed often are also the mission-critical forms and processes (service provision and progress notes, for instance, or intakes, registration, diagnosis, etc.). A valuable byproduct of this approach is that the clinical forms that are most important to your operations are the first to be automated. You can build on the success of the first phase of implementing mission critical forms, improving the opportunity for success of the second larger and more complex phase that involves implementing the non-mission critical forms. The experience gained from the first will be invaluable for the second. 16

18 Awareness During Software Selection If you have determined that Organization Driven Re-engineering is your best option, it is important in the Request for Proposal (RFP) and selection process to evaluate the vendor on more than system features and functionality. You will want to conduct an in-depth evaluation of the vendor s capabilities to provide consulting and technical assistance throughout the process. You should also evaluate the vendor s ability to work with you to develop a custom implementation plan reflecting your needs. During the selection process you should continue to highlight that consideration. You might request a site visit at a company that has implemented under Organization Driven Re-engineering and learn about their experiences. Understand that the reference organization has implemented their system based upon their own specific conditions that you would not exactly mirror. Consequently you need not select a site to visit that is highly similar to your own. You are evaluating the vendor s ability to show success with the Organization Driven Re-engineering process as well as their product s ability to perform in a clinical environment. With Software Driven Re-engineering you must also pay special attention to the vendor s Software Driven Re-engineering model. You must closely evaluate the model to evaluate how effective it would be for your organization. You may find that you like the software s features and functionality, but the vendor s Software Driven re-engineering model is not workable for you or that the vendor does not provide such a model. You may then find that the capabilities of the software are such that you are willing to purchase the software and perform an Organization Driven Re-engineering. It is important to ask in any RFP if the vendor offers a Software Driven Re-engineering model and to request enough information about it to be able to evaluate whether it would work in your clinical environment. You might request the vendor show not only their features and functionality in a product demonstration but show their Software Driven Reengineering model. You would also want to conduct site visits at locations that had implemented an EHR using the Software Driven Re-engineering approach and ask about their successes and difficulties. Make the Right Choice for Your Organization One of the major factors contributing to the success of EHR implementations is making the right choice between Organization Driven and Software Driven Re-engineering. Organizations often overlook the importance of determining a vendor s ability to assist in Organization Driven Reengineering or to provide a viable model for Software Driven Re-engineering. It is important to approach the selection process with this in mind and to devote adequate attention to determining the best approach for your organization during the RFP, selection and implementation processes. 17

19 Organizational Assessment for Organization Driven versus Software Driven Re-engineering Rank each question on a 1 to 10 scale where 10 means that you strongly evidence the factor being evaluated and 1 means you have no compliance at all with the factor being evaluated. For each question in the second section record a Weight factor on a 1 to 5 scale where 5 means this is a very important concern for you and 1 means it is of little concern. Multiply each Rank by its Weight and record the product as each question s Score. To what extent is the treatment model your company provides truly unique? Are there no organizations providing similar treatment that have effectively implemented an EHR? Are there no other companies that have the same funding streams such that certain clinical and administrative requirements are dictated by those payors? Is there very little similarity of your clinical treatment model to other organizations receiving funding from your primary payors? Are there no generally accepted definitions of structured treatment planning, including Problems, Goals, Objectives and Interventions that you find acceptable in your practice? If the answer to this particular Question is ranked at a 7 or higher, you should strongly consider Organization Driven Re-engineering and the rest of the assessment is not required. If not, complete the remainder of the assessment and start scoring again at zero. 1. To what extent does your company follow best practices in your clinical model? Have you made a concerted effort in the past to flowchart all clinical and administrative processes to assure they reflected best practices, were well designed, and that the forms recording each clinical event reflected the clinical process itself? Did you make a conscious effort to eliminate redundancy in recording information and to eliminate widowed, redundant and obsolete clinical and administrative forms? Did you make a conscious effort to seamlessly interweave the clinical forms with billing requirements, defining the events and related information in clinical terms as opposed to billing? 2. To what extent does your company follow structured treatment planning forms and processes? Have you developed a set of Problems, Goals, Objectives and Interventions reflecting your particular treatment environment? Have the clinical staff been trained in their use? Is this part of your New Employee Orientation for clinical staff? Is there close adherence to these in actual use? Do you audit for this adherence as one of your standard quality assurance requirements? How effectively do your structured treatment planning forms and processes reflect your actual treatment requirements? 3. To what extent do the services actually provided follow the requirements of the treatment plan? Do you audit for this as part of your quality assurance processes? Do you have a process for reconciling conflicts between third party authorized services and treatment plan interventions? Do you have a process to assure only services matching the treatment plan are scheduled? Do you have a formal process for interim treatment plan revisions? 4. To what extent do like programs use like clinical and administrative procedures and forms? Do all physical locations for all programs performing the same type of treatment use the same intake, administrative, treatment planning, assessment, discharge and other clinical procedures and forms? Are there certain programs that have close adherence to this and others that do not? Are there one or more model locations for particular programs that have well designed clinical forms and procedures that other like programs could be modeled after? Rank (1 10) Weight (1 5) Rank (1 10) Score (1 50) 18

20 5. To what extent can your company manage a major project spanning up to three years? Can you afford to devote the majority of the time of both a clinical and (to a lesser extent) an administrative manager to the project? To what extent can you be involved for that time frame? How much experience does your top management tier have with managing projects of this scope? What other conflicting priorities are there for these managers that would impact the time they can devote to this implementation? What previous experience does your staff have with successful EHR implementations? What training or mentoring do they have with structured project management? 6. To what extent can your company afford the additional cost of Organization Driven Re-engineering? The total implementation cost, including the cost of your staff, of Organization Driven Re-engineering can be double or more the implementation cost of Software Driven Re-engineering. What in your mind is the cost benefit of retaining your current procedures and related forms as opposed to adopting those inherent in the Software Driven Re-engineering model? 7. To what extent can you accommodate the additional risk of Organization Driven Re-engineering? If the risk factors resulted in additional project management requirements, do you have the available resources to devote to it? If the risk factors resulted in an increased time frame for implementation, can you accept that? If the risk factors resulted in conflict with your vendor can you manage that? If the risk factors resulted in poor acceptance by the clinical staff, can you support ameliorating retraining and assistance? If the risk factors resulted in a reduced Return on Investment, can you accept that or devote the additional resources needed to improve on that ROI? Total Weights and Scores Average Rank Add up the total Weights and Scores of all but the first (unique treatment environment) question and divide the Total Score by the Total Weight to get the Average Rank. If the Average Rank is 3 or less you should consider Software Driven Re-engineering. If the Average Rank is 7 or more you should consider Organization Driven Re-engineering. If the Average Rank is from 4 to 6 then you should consider a blended approach. A blended approach should also be followed in any case where there are outlier values. For example, if your Rank indicates you should follow an Organization Driven Re-engineering approach, with the exception that you do not yet have structured treatment planning in place, then use Software Driven Re-engineering for that aspect only. If your Rank indicates you should follow Software Driven Re-engineering but the Rank of (for example) question 4 is 7 or greater then you should follow a blended approach such that as little cultural, procedural and organizational change as possible is required. 19