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

21 IV. ACQUISITION Thus far you have been introduced to the value and importance of an EHR, some of the general principles and issues to consider in successful implementation, and the importance of assessing your organization s readiness. The Organizational Assessment for Organization Driven versus Software Driven Re-engineering is the most important exercise leading to acquisition for it describes your organization s types of information, - the need, where it comes from, what it consists of, who uses it, and for what purpose. The more formal and rigorous this document, the better, as it becomes the basis for the selection process. The requirements for an EHR indeed for information technology in general are highly complex, and implementation will have a profound impact on your organization whether you approach it through organizational or software based re-engineering. The costs, the time, the potential disruptions for your staff, the potential impact on quality of care, are all such critical issues that we cannot overemphasize the need for due diligence. Whether you have already decided on a vendor or whether you are casting the net broadly for all possible qualified vendors/consultants, you must understand thoroughly the costs, alternatives and impacts of the EHR you plan to acquire. Not only must you understand such matters, you must communicate your concerns and limitations to your vendor as well if the project and relationship are to be successful. For most governmental organizations, a formal RFP is required, i.e. a highly structured document and process to guide the acquisition. For other organizations, an RFP might be expected by your governing bodies to assure responsible and transparent uses of funds. But a formal RFP can be expensive and time-consuming, and some organizations will use less formal methods. No matter how you approach it, you must employ adequate due diligence in choosing your vendor and must be able to communicate your needs clearly to that vendor. In the section that follows, we have described this process as an RFP. However, please read this in the broader sense as a structured approach to due diligence and communication and a way to evaluate objectively the disparate solutions from which you will have to choose. As a formal process, acquisition should entail four phases: 1. Learn what alternatives are available and which vendors could provide solutions appropriate to your organization. In a formal process, this is sometimes called the Request for Information (RFI). 2. Document your requirements and expectations clearly in detail, creating a basis for the acquisition and implementation project. In a formal process this would be the Request for Proposal (RFP). 3. Evaluate the proposal(s) from your selected vendor(s). 4. Negotiation and contracting. The RFI is a preliminary and simplified form of the RFP and is generally non-binding on vendors. Its purpose is to survey potential vendors for possible solutions. You would not expect the RFI to lead directly to vendor selection or contract. Although preparing an RFI is not always necessary, it can serve to pre-qualify potential vendors, determine whether a solution actually exists, and establish budgetary guidelines for the eventual purchase. Although the RFI may seem 20

22 useful, be aware that vendors generally do not like them because they require a thoughtful and careful (read: expensive) response much the same as an RFP yet may not result in any business. It is especially frustrating for vendors when the tentative project is abandoned following the RFI. (For a vendor, the cost of responding to a typical enterprise solution RFI is on the order of $15,000.) The more widely used RFP document also is distributed to potential vendors. It is a tool to communicate the customer s needs for an information system, to formalize the acquisition process, and to provide the best assurance that vendor selection will be as objective as possible. It also reflects the customer s criteria and priorities for making their decision. A survey of 1500 organizations queried the relative importance of various criteria in making their system selection decision. The following table compares the ranking given by corporations making their first system purchase with those organizations making a subsequent system purchase (excerpted from An Information Systems Source Book, from the series Rethinking the Behavioral Health Organization, by Ronald L. Ravneberg, 2005 by Health Systems Consulting): Rank Initial Purchase Criteria Subsequent Purchase Criteria 1. Price Support 2. Ease of Implementation Vendor 3. Ease of use Equipment 4. Software Fit Growth 5. Functionality Software Fit 6. Equipment Documentation 7. Growth Functionality 8. Support Ease of Implementation 9. Documentation Ease of Use 10. Vendor Price Your RFP, indeed the entire selection process, should ensure the greatest likelihood of success. We strongly recommend you consider the Subsequent Purchase Criteria in making your choice. The RFP process is a vital communication link between vendor and buyer. The buyer or buyer s consultant should clearly communicate their needs and constraints to the vendor and should design the RFP process to elicit the most useful information possible from the vendor. The RFP should: 1. Acknowledge that a major portion of resources is required after contracting, including implementation and on-going operation, and such information provided by the vendor should be weighted appropriately, 21

23 2. Clearly identify major goals to be achieved by the system being purchased and allow the vendor to address major goals in a consultative and descriptive manner. Response to major goals/issues should be weighted according to their importance. 3. Include information to enable a qualitative discussion of cost effectiveness with the vendor, 4. Require a sample implementation plan, including resources, milestones, timelines and tasks, 5. Clearly specify evaluation criteria weighted according to major goals, and 6. Incorporate an evaluation component that allows a second phase proposal for the vendor to correct perceived weaknesses in their original proposal. Make the RFP specific, clear and concise. If the RFP is confusing or incomplete, you will not receive high quality, comparable proposals. Ravneberg provides a list of valuable RFP recommendations that we endorse (Attachment A). The Contract The result of vendor selection will be a formal contract. Much like the buyer s RFP and vendor s proposal, the contract communicates and formalizes the intent of both buyer and vendor. It is important to negotiate carefully and to draft a contract that reflects what each party truly expects. However, a contract is no substitute for a healthy relationship. While it is a critically important vehicle for defining the expectations of both parties, the contract is only as good as the intent and understanding between the parties no matter how detailed it is. We recommend the following ten negotiation guidelines. They are not offered as legal imperatives but as important business considerations. Negotiation Guidelines 1. Know the Vendor: The low cost of entry to the technology industry is a double-edged sword. In certain areas, such as consulting, web design, and niche software products, competition is robust and innovative. Some competitors, however, are small, under-funded or inexperienced startups that may pose a substantial risk of project failure. Other well-funded and experienced companies have outstanding marketing capabilities that can disguise inferior or limited products. For any project of consequence it is recommended that the buyer perform an evaluation of at least three potential vendors. If the project is large enough to warrant a formal RFP, begin with a detailed description of what the software is expected to accomplish and how you expect to do business with the vendor. Discuss important contract terms with the vendor at the earliest opportunity to discover whether they can accommodate your needs. Important issues may include ownership of developed intellectual property and possible restrictions on resale of technology designs to competitors. Ideally, final negotiations will address important business issues and not minor legal points. 22

24 If the project does not warrant an RFP, at least invite several vendors to demonstrate their products. Invite to the demonstrations representatives of all potential user departments to evaluate the products. Be sure to complete all demonstrations no matter how impressive the first vendor's product may be. Regardless of any relationship your organization already has with one vendor, and despite any enticing and seemingly favorable price offered for a sole source deal, multiple vendor demonstrations are recommended. 2. Don't Buy on Price Alone: It is not unusual for substantial price differences to exist among competing vendors. Price, however, should be just one factor in the decision-making process. Your primary goal is not to deliver the project on or under budget but to ensure a successful implementation. To sacrifice functionality, reliability or industry experience for a lower price is a big mistake. If the project fails, no one will value what a great deal it was. Keep in mind that price includes more than product license fees. Other cost factors include: a. Annual maintenance fee (typically 15 to 25 percent of the license fee), b. Hourly rates for services, c. Discounts on future products and services, d. Whether the amounts of these fees may increase over the life of the license, and e. Government product/service taxes that will increase the overall software cost. 3. Get Commitment from the Highest Levels: As we have elsewhere stressed, successful implementation of a software package depends on the knowledge and active involvement of senior executive management as well as a full-time project implementation team. If management does not provide sufficient time for people to work on the project, they should not expect the software to work optimally. Complex software and system integration projects require a dedicated team from both vendor and customer. Similarly, the vendor's executive management should determine what priority it will place on delivery and implementation for your organization. If their product is in high demand, the vendor may focus on its largest customers first. If your organization is not in that category, require your vendor to sign a project plan that specifies which people they will assign to the project and the dates of project kickoff and completion. In addition your contract should include the right for you to interview the vendor s project manager and key personnel in advance. At a minimum, you should have the right to request removal of any vendor representative whom you believe is inexperienced or under-performing. 4. Get Early Legal Advice: It is important to involve legal counsel at the very start of the acquisition process. Although it may be cost-prohibitive to have counsel actively negotiate all aspects of the deal, their involvement early on will assure that they are familiar with intent and strategy. Then when they are consulted, counsel will be able to react more quickly and knowledgeably. The role of legal counsel in a technology deal is not simply to review a boilerplate but to make sure the contract addresses all of your specific requirements and concerns. 23

25 5. Tie Payments to Milestones: Typically technology vendors will require a significant part of the payment up front with the balance payable as the project is completed. If the project can be divided into phases or milestones, remaining payments should be divided across the satisfactory completion of those milestones. It is also common to withhold final payment, perhaps as much as ten percent of the total, pending some period of successful operation following completion. A phased payment strategy depends on mutual agreement as to what constitutes successful achievement of each milestone. Also, in those cases where completion of a milestone requires action on the part of the customer, the vendor may insist that payment be made following a specified time period, even if the customer has not completed their responsibility. Be sure to reach a mutual understanding of the milestones you set and the objective criteria that will tell both parties that milestones have been accomplished. 6. Termination: In a licensing agreement (where the vendor is selling software licenses to the customer), a vendor should not have the right to terminate a software license unless the customer breaches its terms. In a services agreement (where the vendor offers services but not product licenses), the vendor should not have the right to cancel a project unless the customer fails to pay after appropriate notice. This protects the customer from the vendor having unwarranted leverage in a dispute. If the vendor can walk away from an implementation because the deal is losing money or there is a perceived problem with client relations, the customer will be at the vendor's mercy. Conversely, the customer should have the right to terminate a software license or a technology services agreement at will. In the case of a software license, the customer should be prepared to sacrifice previously paid license fees plus accrued but unpaid fees and expenses. If the customer s utilization plans change, software vendors seldom will give a refund. Neither do they offer money-back guarantees. In the case of a services agreement, the customer should always be able to fire the service provider for dissatisfaction (a measure short of a breach) or budget cuts. The vendor may negotiate for a termination charge; that kind of request would be handled on a case-by-case basis. Consider whether the vendor has legitimate costs to recover from the sudden termination or whether the vendor is trying to recover profits for services never rendered. If termination charges are not warranted, the customer should pay only for work performed. 7. Warranties and Indemnities: This is an increasingly difficult area for negotiation, as few software companies will warrant the performance of their software or system. Neither will they promise that their software or system does not infringe on the intellectual property rights of third parties. Negotiation in this area is made difficult by the risks inherent in warranties and indemnities. Software can and often does fail, so the vendor will not commit that it will perform error free or get fixed if it breaks. Similarly, intellectual property litigation, particularly with patents, has increased in the past few years, and some larger consulting firms will give only limited warranties for non-infringement. This is an area where the customer will rely heavily on legal counsel s risk assessment and prudent recommendations. 8. Performance Criteria: Software salespeople understandably emphasize the power and performance of their product. Getting the vendor to contractually commit to those levels of 24

26 performance (response time and reliability) is another story. The vendor should be prepared to agree to some base level of performance so that the customer can trust what they are buying. If the vendor offers a maintenance contract to support their software product, it should be tied to performance criteria. How quickly the vendor will fix bugs that disable the software may be vital to the customer s business. Ask the vendor to commit to certain time frames for problem solution and calculate a penalty (perhaps a percentage of the maintenance fee) to make sure the vendor performs. 9. Remedies for Failure: Although vendors won t give a money-back guarantee, they should be willing to refund fees paid if they breach the performance warranty because the software never worked. This is a complex area of the agreement but may be very important. Because software projects can and do fail, remedies for the customer typically are make whole remedies - a refund of all fees paid. A lesser remedy can allow the vendor to profit from a deal in which it over-committed or failed to perform. A middle ground is a partial refund based on the portion of the software package that does work or a discount if the product lacks promised functionality. Software licenses often will restrict the remedy for a failed software product to the specific failed portions. 10. Escrow the Code: Vendors may come and go, but you should not be stranded with a vital software package with no one to support it. Require that the vendor deposit the source code and documentation for the software with a reliable third-party escrow service. The cost is usually a few thousand dollars per year, and you can negotiate with the vendor to share that cost. Under an escrow arrangement the vendor will send the current source code (and update it with new releases) to a secure location. In the event the vendor files for bankruptcy, discontinues support of the product or breaches its maintenance obligations (i.e., refuses to fix the software), the third party will release the code to the customer. Then, assuming that your organization has sufficient technical resources available, it may be possible to maintain and repair the software without the vendor. You should negotiate for the vendor to escrow the names and contact information of the product developers as well. If the vendor goes out of business, you might be able to hire those developers to maintain the code. Fully realizing the benefit of an escrow arrangement can be difficult and expensive. Don t simply assume that the existence of an escrow agreement is sufficient protection. If there is an active User Group associated with the vendor, members may be a sympathetic source of technical assistance since they would be in similar circumstances if the vendor fails. Your New Business Partner The vendor you select should become your business partner. The relationship that began with successful selection may last many years, and the quality of that relationship can have a profound affect on the ultimate success and usefulness of the system. 25

27 Although information technology is an environment of electrons, bits and bytes, it s still managed by people fallible, imperfect people. An individual on either side of the customer/vendor relationship who is having a bad day can throw an implementation project off track and even damage the overall relationship. Each side must work to ensure that the human element enhances rather than derails the project. The success of the relationship indeed hinges on the basic concept of partnership. The vendor should expect to be successful and make a reasonable profit from the relationship, and the customer should expect to be successful and achieve their strategic information objectives. Buying software is not just about acquiring technology. It s also about realizing the potential that both customer and vendor envisioned. The customer has to understand the vendor s vision for the software. Similarly, the vendor must understand the customer s information strategy and expectations. Each must buy into the other s plans. Because of the need for integration with other products and processes and the natural evolution of the customer s needs over time, the technology has to evolve over time as well. Vendor and customer must recognize the fact that they are connected for the long haul. The selected product might perform as expected initially, but in a few years it s going to have to run faster and provide more functionality. You should partner with a vendor that is pushing their technology forward all the time. Modern information systems are highly complex beasts and are being built to last a very long time. In order to do so they have to evolve. Long-term product evolution requires trust and understanding on both sides and will take quite a bit of work on the front end. It will also require constant communication during and after product implementation. But it is well worth the effort. One thing that can differentiate an effective partnership from a one-night stand is how much risk a vendor and customer are willing to take. A simple risk/reward test is common. If a vendor achieves the mutually agreed-upon goals, it receives full compensation. If they don t, then some expense comes out of their pocket. If they go above and beyond the call of duty, if results surpass expectations, there s more money in it for the vendor. If both parties meet stated goals, the rewards are there. If the goals are not met, both lose and share a burden of the cost. For a successful implementation, the vendor may expect the customer to be a vocal reference to potential clients. The tone of the customer/vendor relationship should be set before the acquisition. The acquisition process will go on for months and will require the vendor s sales staff and other personnel to hammer out the project s scope and costs. In addition, as part of due diligence leading up to the contract, the vendor should know that the customer expects the best installation people on board for the implementation phase. It is reasonable for the customer to review the implementation team s résumés and even interview them briefly by telephone. In order to be most effective, members of the vendor team must not only be qualified and skilled but should fit the customer s culture. The customer s management should also be assured a clear line of communication with the vendor s executives. This can forestall potentially disastrous miscommunication and achieve a high level of trust within the partnership. 26

28 Coming Together - To enhance the customer/vendor partnership, the customer should explain up front and in very clear terms what they expect from the relationship. We recommend that the Chief Information Officer (CIO) and other top management meet directly with vendors and clarify what they are trying to accomplish by the software acquisition. Such discussions give both parties an opportunity to look for intersections where customer goals and vendor technologies come together. Vendors want a best practice reference site for their technology in an organization with the vision to benefit most from it. Exchanging strategic visions opens up conversations about how customer and vendor can best work together, where technology, strategy, and needs intersect. That s the stuff of successful partnerships. 27

29 V. IMPLEMENTATION Once the Electronic Health Record product has been purchased your organization begins the implementation phase. Regardless of how good an EHR product may be, it cannot simply be taken out of a box, loaded onto a computer and expected to work well at your organization. You must go through the laborious process of implementation. Implementation refers to the process of adapting the software to fit your organization. It is the process of turning the generic product you purchased into your organization s EHR, reflecting your organization s specific practices and methods. During the implementation phase you will carry out your earlier decision to adapt your organization s business practices to fit the software you purchased (Software Driven Reengineering) or modify the software to match your business practices (Organization Driven Reengineering). Be prepared to revisit that decision and modify it, as appropriate, given your team s growing knowledge about the product s potential and the vendor s growing understanding of your organization. Your implementation team must be prepared to identify, prioritize, order and synchronize a number of complex tasks. At a minimum, data elements and codes must be defined to fit your organization s lexicon and the demands of your particular reporting requirements. Software scripts must be written to link data on your EHR to required reporting forms and systems. Necessary equipment must be identified, acquired, tested and deployed. Screens and screen sequences must be evaluated to determine the degree to which they fit and support your preferred business practices; either your business practices or the screens/screen sequences may have to be modified. You will have to design staff training and support systems once the product is implemented. The importance of the implementation phase cannot be overstated. No matter how cautious and prudent you may have been in evaluating and selecting your EHR software, the quality of your implementation will be crucial to the overall success of the end product. A good product can perform poorly if it is poorly adapted, poorly set up, poorly deployed and/or poorly supported. On the other hand, a relatively weak product can be made to work satisfactorily if it is implemented well. The Importance of Strong Leadership As has been previously noted, strong, visible corporate leadership is central to the success of an EHR implementation. Research on IT implementations in general has found that executive management involvement or the lack of it is key to the success or failure of the project. In terms of the financial and human resources it will consume and the potential impact on mission-critical functions, the EHR may prove to be the most important project your organization ever undertakes. Initial conversion to an integrated EHR will be a revolutionary, not an evolutionary, force. Automating all client demographic, clinical and service information offers opportunities for fundamental changes in the business and clinical methods that will affect your entire organization. 28

30 The project will consume significant financial and staff resources and cause many traditional business methods and practices to be altered substantially. Staff will see the drain on scarce resources and feel the pressure of impending change. Consistent, clear communication to staff by executive management about the importance of the project, the reasons for taking it on and the nature of the changes to come will contribute to greater acceptance. Greater acceptance by staff will contribute greatly to the effective use of the product once it is deployed. As the ultimate leader of the project, the CEO should be prepared for problems to arise. This will be a complex project, and things can and will go wrong from time to time. Some of those problems will seem to signal the end of the world as you know it. Treat these problems like any other problem that develops in any other project your organization has undertaken. Do not overreact just because this is information technology, and do not let your staff overreact. Be prepared to talk about problems honestly and candidly with all involved parties. Providing steady, confident leadership will help your staff navigate those difficult times. The occasional reminder to staff that making these changes is not optional but a requirement of continued employment may also be a necessary part of that message. Establish a Project Management Team Implementation of an Electronic Health Record system should be considered one of the most significant projects your organization will ever undertake. The EHR will impact every facet of your organization s delivery and support of client care. Implementation of the product you purchased is not something that can be left to one or two staff to handle in addition to their other duties. Even the best information technology staff should not be expected to successfully implement EHR software on their own. This is a very complex project that, if done right, will take time and consume significant financial and human resources. It will include a large number of disparate tasks that must be coordinated effectively. One of the most important decisions will be the selection of a Project Leader. Your selection of the leader should be made with as much care as you would fill any critical senior management position. Select a leader who understands the potential of technology to positively impact operational efficiency and improve client care. They must be sensitive to the impact of these changes on the people who provide and support that care as well. The Project Leader is the person responsible for the project with regard to time, budget and quality. They must understand the vision set by executive management and be capable of translating that vision into the project plan. Their responsibilities generally include: management of the project scope throughout the process, day-to-day responsibility for running the project, monitoring the project plan, reporting plan progress to management and staff and resolving problems encountered by the implementation team. The Project Leader should possess the ability to manage and coordinate complex projects and enjoy the full confidence of executive management. It is of nearly equal importance to select a team that will work with that Project Leader to oversee the implementation project. The use of cross-functional teams to plan and implement EHR projects and motivate staff to embrace the eventual product is linked closely to eventual perceptions of success. Cross functional teams blend supervisory and line staff involved in the most critical functions affected by the EHR, which is to say most if not all the functions of your organization. Increasingly, as the implementation evolves, it will be important to gather ample, 29

31 realistic input on the way your organization handles its day-to-day client care operations. Direct involvement of staff supervising and performing these functions will contribute to an implementation that effectively automates these functions. The Project Sponsor and Project Leader will function as part of a collaborative team with the software vendor implementation team. Take assertive steps to assure that your team and the vendor s representatives see themselves as inter-connected entities with a common goal. You will find the vendor eager to embrace this form of partnership. The vendor works for you but knows its product and its product s potential to help your organization far better than your team does. However, your team knows your organization, its vision and its values better than the vendor s team. The two must work together to implement the EHR in a manner that best supports your organization s operations. All organizations are resistant to change. The team will act as ambassadors for change and communication. The team will be well positioned to contribute ideas and promote changes needed for a successful software implementation. Emphasize the EHR as a Clinical Tool As has been stated previously, the EHR has significant potential for improving the quality of your clinical practice, patient safety and treatment outcomes. By focusing on using the EHR as a clinical tool, as opposed to an administrative tool, you are more likely to derive value in these areas. Too often the emphasis in implementation is on achieving administrative efficiencies, billing system enhancements or accountability improvements. While these are all significant impacts of the EHR on your organization s operations, they can easily over shadow the impact on clinical practices. Do not allow the clinical functionality of the EHR to get lost during implementation. Work with the vendor to identify the clinical impacts that have been derived by other customers of the vendor. Visit other organizations that have substantial experience with the implementation and use of an EHR and find out how they have applied their EHR to improve clinical practice. Make sure that clinical staff are well represented on your project team. Establish a subcommittee devoted to applying the EHR to clinical practices and provide them with an extensive introduction to the software so they can inform the Project Team about possible clinical impacts to be realized. If you have adopted evidence-based practices or developed clinical pathways for your staff, make sure the rules underneath them are built into the software, enabling the software to become a significant tool for staff training in these practices or pathways. Establishing the EHR as an essential tool to support clinical practice from the beginning will shorten the learning curve for your organization and further increase the return on your significant investment. Nurture the Relationship Developing and maintaining a relationship with your software vendor s corporate leadership is an important element of effective leadership. Highly problematic issues may arise such as unacceptably slow software performance, difficulties with ancillary system vendors, missed project timelines, perceptions of inadequate support, contractual interpretations, etc. Often responsibility cannot be clearly pinpointed to one side or the other. As the pressure for 30

32 implementation increases there may come a time when it seems as if your staff is pitted against the vendor s support staff instead of working together in a productive partnership. These issues are really no different than contractual issues you would have with other service contractors. A strong relationship with the critical decision-maker at the vendor corporation will convey your commitment to the EHR project and help in constructively resolving problems that arise. The first project meeting is a great indicator of whether the relationship is starting off in the right direction. If the vendor's sales representative is not at that kickoff meeting, for example, and the implementation team leader doesn t seem to be singing from the same score, there is cause for concern. A customer s CEO said recently, If the sales rep is not there, that tells me a lot about a company. It means that the people I have dealt with to this point are stepping aside, and I'm going to have to repeat myself to a new group of people. This may sound inconsequential, but in my experience it's not. Vendors make so many human errors along these lines, and they are costly errors for them and us. Common sense would dictate we keep our communication channels open and establish continuity in our relationship, but common sense seems to escape some vendors. While some vendors might think these human errors matter little in the course of a relationship, they send a message and set the stage. If communication lines don t stay open from one contract stage to the next, it may indicate how the entire company operates, which may not bode well for the difficult implementation stages yet to come. The vendor s staff must view the contract as an interactive and long-term process, with careful continuity throughout. Neither customer nor vendor should be content with a one-night stand. When the customer gains the technology they need and the vendor benefits through future reference sales, we have a win-win situation. Beyond the simple reference, customers who demonstrate appreciation to vendor s staff (through notes of appreciation and other gestures) can achieve a greatly strengthened partnership. Where vendor personnel feel they are valued and appreciated, they generally work harder and are more responsive. It s human nature. The partnership between the customer and their vendor will sustain vital trust and help achieve longterm value for both parties. It has already been noted that strong leadership at the highest levels of the organization is a predictor of successful EHR implementation. Establishing and articulating a clear vision of and rationale for the EHR and keeping your Project Team and your staff focused on that vision will reveal the depth of the corporation s commitment to necessary changes. Develop a Comprehensive Project Plan First-time conversion to a comprehensive, integrated Electronic Health Record can have fundamental impact on corporate culture, dramatically changing how you collect, move, store, access and report client information. In short, it will significantly affect and change how you provide, support and account for client care. Few if any mission-critical functions are left unaltered by an EHR. Organizing and coordinating such a wide range of activities and resources requires sound planning. 31

33 The guiding document in many projects is the project plan or timeline. The timeline should include most of the discrete tasks required to get from start to end. It should assign resources, set time expectations and target dates for completion. The plan will need to be agreed upon by both partners - software vendor and customer. It should be realistic and achievable. Development of this plan should be taken seriously and not adopted until all questions, concerns or disagreements are resolved. The nature of this partnership will require candid discussion on valid business tasks. Communication is essential to your partnership and project. A key point in any project is that it has a clear start and a definitive end. This is especially true of software implementations where so many projects seem never-ending. Your implementation may be extensive, lasting over a year; it should be segmented into palatable timelines with definitive end points. Early on you should have discussed with your vendor their recommended template for product implementation. You should now come back to that template and determine the degree to which you want to lead your own implementation or have the vendor take charge. In either case, do not let this decision be driven by the relative cost of either alterative. The price you have paid to evaluate and purchase the software was significant. The last thing you want to do now is scrimp on the critical step of implementation planning. Your decision should be based on your sense of the adequacy of available internal resources. If you think you have the staff expertise and are willing to commit the time, you may want to take the lead role to assure that the project moves at your chosen pace. If you doubt the ability of your staff to lead such a complex process or do not believe you can devote adequate staff time to the project, you may want to contract with the vendor to take the lead role. In either case you will want to work closely with the vendor representatives assigned to assist your Project Team. Again, the vendor may not understand the inner workings of your organization, but they know their product and how it has worked in other organizations similar to yours. Take advantage of their knowledge and experiential learning, all the while filtering that input with your Project Team s knowledge of your organization, its values and its vision for the EHR. Regardless of who leads the project, you will want to have a detailed project plan with clear delineation of tasks, responsibility assignments and timelines. This plan should be used routinely to guide and monitor progress. The plan does not need to be overly complicated, but it does need to be formalized and recognized by your Project Team as a serious instrument of accountability. Some successful organizations have used their project plan as their team meeting agenda, reviewing each relevant task and its connection to other tasks farther down the timetable. You should be prepared to recognize this plan as firm but flexible. No matter how good your team is, it will experience problems in execution of the project plan causing some slippage in the timeline. The team will also learn more about how your operations really work and how the software can be of assistance as it goes through the steps of implementation. At times it will serve the team well to review and modify the plan and the timelines. The team will need to 32

34 balance the timeline with the importance of producing an end product that maximizes its value to the organization. Do Not Rush the Implementation Timetable While the slow pace of implementation may be a source of concern, do not rush the set-up and/or implementation itself. The more the Project Team is prepared for the implementation process and understands the potential of the product to augment or modify your business methods, the better the implementation will be. This will take good leadership, good people, good cooperation with the vendor, good planning and adequate time. As you proceed to implement your project plan, you will need to be firm but flexible with critical deadlines. Be prepared to learn that your initial deadlines for some tasks underestimated the degree of difficulty. There will be other times when you learn that critical resources or activities controlled by others have slipped, negatively impacting your plan. You will also find that on occasion your team will lose focus and let deadlines slip unnecessarily. Knowing when to press your team for faster progress and when to allow them to reset timelines will be a critical test of your leadership. Above all, resist the temptation to ram the go-live date down your team s throat. A good implementation cannot be accomplished through sheer force of will. Some of the most successful EHR implementations have taken longer than planned. It is difficult, if not impossible to fully comprehend what you are getting your organization into until you have entered the implementation phase. A rushed implementation is a good predictor of eventual frustration with the final product. Allocate Adequate Resources EHR implementation requires significant financial and human resources and impacts all missioncritical functions. One of the most critical indicators for implementation success or failure is the adequacy of resource allocation. Leadership must commit the human and financial resources necessary to get this complicated project done right. Successful implementations take time, whether they are first-time EHR projects or replacement projects. Scrimping on implementation usually leads to dissatisfaction with the end result. Your Project Team needs to understand the scope of the project and be empowered for success. Many organizations have made a concerted effort to introduce their Project Teams to the great potential in EHRs before setting them to work on planning and overseeing their own organization s implementation. To foster creative thinking, these organizations have encouraged their Project Teams to study what other companies have done both successfully and unsuccessfully. Stimulating early discussions within your team regarding EHR possibilities within your organization will increase its eventual value. Including vendor representatives in these discussions will add even greater value. Some have used consultants to educate their teams. Having an outsider inform your staff how electronic records have been successfully implemented in other treatment provider organizations and what their impact has been will help your staff shape your project plan. The consultant can also assist in team-building activities to strengthen and prepare them to take more ownership for the project they are leading. Exercise the same kind of caution in your selection of a consultant 33

35 as you did when you selected the product itself. Poor consultation can wreak significant havoc within your team and your organization. Other organizations have used field trips and users groups to prepare their Project Team. Visiting with companies that have successfully implemented or converted an EHR offers your project staff a chance to learn how the EHR has affected those organizations. It may be helpful to visit those that are using the same product you have chosen, but it is not necessary as implementation is a process that looks very similar from one product to another. The field trip or user group can also create bonding opportunities to draw your team together. Take Advantage of Re-engineering Opportunities This is also the time to implement your decision about the degree to which you will re-engineer your clinical practices and business methods. If you are moving to an Electronic Health Record for the first time, this is an opportunity to gain significant administrative efficiencies not possible in paper-based record systems. If you are moving from one EHR to another, there are opportunities to enhance efficiencies you may have gained previously. You will already have a working knowledge of the power inherent in an EHR; you can now focus on using its power to enhance the quality of clinical practices. Implementation of an integrated EHR enables data that is currently collected multiple times and usually entered some time after actual collection to be gathered once and entered as it is being captured. While this may take a bit longer at the front end, careful re-engineering of your system to accommodate real time data entry can eliminate many functions currently being performed by staff in a back office supportive role. The potential savings to your organization is far greater than it may seem when you first evaluated the product for purchase. You and your staff must come to understand the software s power and functionality and the intricacies of your current data collection/entry systems to fully appreciate how much savings your organization can achieve and how you can maximize that savings by the way you implement the product. You should not assume that your staff really grasps the potential of the product even if they were part of the evaluation team. Nor should you assume that they fully understand your organization s current business practices. Your team should work with vendor representatives to use the product in a test environment to develop the depth of knowledge they will need as they plan implementation. Expect surprises as they map your clinical and business practices in anticipation of applying the EHR. Implementing the EHR will reveal inconsistencies and inefficiencies in the ways policies and procedures are actually applied in day-to-day operations across your organization. This revelation should lead to resolution. Pilot Test Developmental Stages Wherever you have changed significant processes, take advantage of controlled tests conducted in protected environments. Whether you are making modifications in your business practices to fit the software or revising the software to better fit your practices, do not overlook the value of testing these changes before implementing them. Your team may find that it has missed a critical step in the targeted business processes, or it may identify other processes that need to be 34

36 addressed. Implementing routine testing will greatly reduce the number of surprises your team will find when you finally roll out the product. The testing concept also produces significant secondary benefits. As concepts are tested in a controlled environment, more staff are exposed to the EHR. As they see positive benefits, they will become powerful advocates for and champions of the new system. As they provide feedback that is digested by your team and turned into business process changes or staff training methods, they also will become more heavily vested in the eventual success of the product. The visible use of controlled testing can become a significant force in reducing staff resistance to the EHR. Define the Scope of the Roll-Out As your team plans for the actual roll-out of the Electronic Health Record (the go live date), it will need to carefully consider the appropriate scope. There are several ways to introduce the EHR to your organization. One is to determine the date when your entire corporation simultaneously will move from the old system to the new system. A second method is a sequenced roll-out of specific organization functions. The third alternative is a program/site based roll-out wherein specific programs or service sites are converted from manual to electronic record keeping in a planned sequence. Corporate Roll-out: There are pluses and minuses inherent in each of these alternatives. Choosing the corporate-wide roll-out means that one day your entire organization is using a paper-based record system and the next day the entire organization switches to an electronic record system. Initially this option may be tempting because it concentrates the impact of the change into a shorter period of time. It also switches all service billing/reporting onto the same platform using the same database. However, it will also stretch and greatly increase demand on the resources you have identified for support, particularly in the first few weeks. Further, if there is a fundamental problem in the software s set-up or performance that is not discovered until it becomes heavily used, the impact will be felt by the entire organization. Functional Roll-out: The functional roll-out is more contained, identifying specific business functions such as scheduling, admission, treatment, billing, etc., for sequential conversion. Functions targeted for implementation can be selected for maximum or minimum impact to allow for a greater or smaller margin of error. For example, the scheduling function can be targeted for initial implementation and be disconnected from service documentation or billing with little impact on those functions. However, as more and more functions are implemented, the electronic system will demand that the other functions be added quickly. For example, implementing an electronic assessment without implementing the treatment planning function or implementing the treatment planning function without the assessment function will make it more difficult for clinical staff to tie those two processes together. Site or Program Roll-out: The third option is to introduce the system site-by-site or program-byprogram. This type of phased implementation is easier on your technical support staff and allows any damage from problems identified in implementation at one site to be contained at that site until they are corrected. However, this requires the maintenance of two record systems, 35

37 which can be problematic if clients are engaged in services at multiple sites. It may also cause billing/reporting systems to maintain both electronic and manual data input, possibly into multiple databases. Your Project Team should carefully consider staging the roll-out to maximize damage control, make the most cost effective use of support resources and minimize disruption to mission-critical systems. Most successful implementations include a period of elevated costs and reduced reimbursements as the learning curve and comfort levels rise. Your Project Team and corporate leadership team will need to consider roll-out strategy carefully to manage these downside risks. Keep the Staff Informed Communicate frequently to all levels of the organization. Staff resistance will increase if they are surprised by the product or do not understand reasons for the organization s commitment to it. Frequent communication will give them a sense of involvement, give the Project Team a potential source of valuable input and demonstrate the commitment and support of executive management. Articulate the vision for the EHR. Do not assume that your staff will understand why it is important to automate the clinical record. Some will see the expense of the system and question its relative value. Others will resent the changes that will be required of them. Communicating clearly and frequently the reasons behind the project will help frame staff expectations. It will also serve to inform them of the organization s commitment to successful implementation. You must let staff know that conversion to Electronic Health Record-keeping is not a choice but a condition of continued employment. Communication should flow two ways. Letting staff get glimpses of the EHR system as it is being designed will enable feedback for your Project Team. There are many ways to involve staff in the design of the system they will use. Seeking review and comment on screen design, pre-defined content, drop-down list development, perceived training needs, etc. will give your team valuable insights into what staff want to see in the system. Incorporating that feedback will increase the general sense of staff ownership of the end product. It is important to generate an air of positive excitement among staff for the EHR. There are numerous examples of methods organizations have used to achieve this end. Many carve out time at routine staff meetings to allow the Project Team to report its progress. This not only keeps staff informed but also reminds them that it is a team of their peers that is involved in designing and implementing the EHR. Periodically displaying pieces of the new system as they are being designed and demonstrating how they would be used will enable staff to get a better sense of what is coming. At the same time this allows your team to gauge staff reactions before committing beyond the point of change to specific screen designs or screen sequences. Project Teams at some organizations have created marketing sub-committees to promote the EHR. These sub-committees increase staff engagement with the Project Leadership and at the same time generate curiosity and enthusiasm for the work of the team. 36

38 Prepare, Train and Support Your Staff A significant predictor of implementation difficulty is lack of adequate end-user training and support. Depending on your particular organization and its staff, training may need to address the entire spectrum of computer usage, from basic use of a mouse to specific use of that mouse to navigate your EHR. If you are bringing up an internal system simultaneously, you might want to consider basic training since it is likely that at least a small minority of your staff will not be computer literate. If you already have an internal system that is your preferred means of corporate communication, your staff may be familiar with the basics, and you can concentrate on developing an EHR-specific training curriculum. There is no clear, right way to assess your staff s readiness for the EHR, but an assessment of their computer skills should be made early in implementation planning. This could be done informally using an all-staff meeting to see how many are active users at home. Or, it could be accomplished through use of a formal survey instrument. A third alternative is to simply create a computer lab and allow staff unfamiliar with the use of a computer to seek instruction/practice time voluntarily. Once staff realize that use of the system is not a choice, those ill prepared for the use of computers will begin to identify themselves as willing to learn or unwilling to learn. You are likely to deal with the former differently than you deal with the latter. Creation of a formal EHR training program is a must for your Project Team. The dip in your productivity that is likely to occur in the early days after going live with the EHR can be minimized by proper training. Training should cover likely functions the end-user will need to perform and allow for real data entry practice time. This training program must become a mandatory part of new staff orientation. Many successful organizations have created EHR specialists among their staff. Referred to by such names as Super Users, Wizards, etc., these specialists are provided with extra training and practice time to familiarize themselves with actual use of the product. At the point of EHR roll-out, these specialists are dispersed throughout the organization for a period of time to be available for on-site, rapid response support. Once the product is rolled out it will be important to provide constant access to a real-time helpdesk. Access to immediate support will not only speed the learning curve for your staff but will be a strong source of reassurance for them. The helpdesk team should have clear response and resolution time goals to ensure accountability for this function. The helpdesk team should develop a database to enable categorization, aggregation and analysis of problems presented to them. Reports from the helpdesk should shape the ongoing training curriculum, which in time will reduce calls for assistance. In some organizations, the EHR helpdesk function has been blended with the clinical supervisory system. Calls for help all go to a single number and are routed to the appropriate technical or clinical staff for response. This affords staff instant access to help regardless of the nature of their inquiry. 37

39 VI. ON-GOING USE, MAINTENANCE AND COMMUNICATION Successful implementation of your new EHR is hopefully just the beginning of a long and satisfying journey. Hardware and software technology evolution and your growing awareness of the power of the EHR will combine to enable continuous transformation and improvement of your business practices. However, to take full advantage of these opportunities, you will need to regard information technology as an ongoing operational function to be as well planned and budgeted for as human resources or accounting or building maintenance. Understand that as you apply the power of the EHR to your operations you will identify additional ways that the system can add value to your organization. Be ready to take advantage of them. When it comes to computer systems and information technology, the issue for many organizations is one of understanding and expectations. Too often we treat computer purchases as a one-time expense. That is to say, you buy it, and you forget about it. This ignores the fact that computer systems require continuing maintenance and support. Take care of your computers. If you neglect them, they will end up costing you more money over time. A strategy that includes preventive budgeting and maintenance will help to ensure the success of your computer systems and your organization. An appropriate analogy might be the purchase and maintenance of a car. Regular maintenance and minor repairs are necessary -- and expected -- to keep a vehicle operating smoothly. Repairs and tune-ups are needed to avoid a serious breakdown. In the long run, investing in ongoing maintenance will cost less than a complete engine overhaul. Budget to Support Ongoing Use and Development Develop a budget that accurately reflects not only the initial cost of an Electronic Health Record system but all related expenses. To make certain your EHR remains an efficient tool for your organization, it is necessary to gain a basic understanding of technical and economic realities and create a financial plan for the system s continuing development that reflects those realities. Computer hardware should be classified as a yearly budgeted expense. As technology evolves you will be presented opportunities to upgrade your hardware and/or software to improve the system s performance. As your EHR holds more and more client information, you will also find that you need to expand the system s capacity to manage that data efficiently. Expect to replace your hardware at least every three years. However, not all of the workstations in your system need to be replaced at the same time. Some will merely need maintenance. Therefore, if you annually allocate money (ex. $ ) for each workstation, you will be able to purchase new computers for about a third of the office each year. An alternative to purchasing your hardware is leasing. Both options offer advantages and disadvantages and should be explored to determine which better fits your organization s needs. Preventive budgeting and maintenance can help keep these costs at a reasonable level. There are additional ways to keep costs down as well. With the ever-increasing rate of change in technology, a state-of-the-art machine today will represent cutting-edge equipment for only a 38

40 few months and will become nearly obsolete in two to three years. Keeping up with technology is undeniably expensive, but there are strategies to minimize expenses and prevent surprises from decimating your budget. One should consider the Total Cost of Ownership (TCO) when purchasing computer systems. Consider the 70/30 Rule. Only 30 percent of the total cost of owning a computer system is the initial purchase of hardware, software and peripherals. Seventy percent of the ownership cost goes to technical support, repairs, training and upgrades. As systems grow larger and include networks, , Internet access and more complex databases, the yearly cost for just one computer can run close to $10,000 (including technical support staff salaries and lost productivity due to breakdowns). Therefore, if a computer system costs $3,000, maintenance may cost you at least $7,000 and possibly more. Money Can Change the Relationship - Because of the increasing need for software integration and increasing complexity of applications, especially in the clinical setting, CIOs depend on long-term relationships with their vendors. Realistically those relationships will wax and wane over time depending on the spending profile of an organization. When a customer is ready to spend money, vendors will be close by, ready partners. When the money is spent, however, relationships can change. For that reason, some organizations find that being an ongoing technology test site ( Beta ) can be an effective way to ensure strong, long-term relationships with vendors. By remaining an active development partner with the vendor, the organization can continue to add value to the relationship even if budgetary constraints limit spending. Serving as a development partner, testing the latest software and being a best of breed, best of class IT facility can be exciting and valuable. However, to become one is not a trivial decision. Not all organizations want that much excitement! Being a Beta Site - It is tempting to ensure access to the newest software technology by becoming a beta test site for the vendor. But test software is just what the name implies. Can your organization s unique requirements influence the next generation of technology through the beta testing process? Will your organization benefit in efficiency or capability from the new software? While new software might be attractive, the process of testing can be expensive and stressful. Do staff members have to be retrained? If the test version fails, could client data be lost? Will the vendor s development team be ready to help diagnose problems? For an organization to benefit from becoming a beta test site it must form a strong partnering relationship with their vendor. Similarly the vendor depends on a strong site for effective testing and will expect the organization to spend necessary resources to fulfill their part of the bargain. It can be both beneficial and expensive. Your organization needs to evaluate carefully whether the cost and risk are worth the potential benefit. 39

41 Train, Train, Train Knowing how to use computer hardware and software correctly will improve your staff s daily productivity. Staff training is essential to effective use of technology and should be an integral part of your technology implementation plan and budget. Without it staff will waste substantial time and money. There are many training options available including a wide range of classes, customized individual and group training, as well as do-it-yourself books, videos and CDs. If staff are inadequately prepared, uncomfortable, or lack confidence in the end product, you risk inappropriate data entry and extraction. In addition to training users on the areas of the record they use regularly, make sure staff understand the whole process. It is helpful to appreciate the big picture, such as how data elements successfully entered by front-line staff lead to reliable aggregated data reports to funders. Training at the top is important as well. Being knowledgeable about your computer system s capacity and potential will enable executive management to respond confidently to IT related questions from your board of directors and other stakeholders. The following are some training recommendations to keep in mind: Identify who will conduct the training. Will it be led by staff, the software vendor, a consultant or some combination of these? Training provided by the vendor might seem expensive, but they know their product best. During the first phase of staff use, provide additional on-site support and coaching for users even if they have had pre-implementation training. Regularly check on the quality of data being entered into the database. Provide user manuals and database documentation. Identify and regularly train super users who can help support other users. Assume that actively participating in your vendor s users group is simply part of doing business. Encourage your staff to participate in user group meetings and through list serves. This will become increasingly important and helpful as your organization continues to develop your EHR. Have a Disaster Plan Keep a backup copy of your most valuable data off-site. If there is a disaster (flood, fire, etc.) and your computer hardware is damaged, it can be replaced easily - your data cannot. Make a backup, take it home, and get a fresh backup at least once a week. If you are not backing up, you're asking for trouble. Recovering a crashed hard drive can cost $3,000 or more, and it may be impossible to save that report it took you months to complete. Evaluate and Communicate How Client Care Is Enhanced Difficult as it may be, quantifying how your organization's programs and services impact the community you serve is one of your most important and challenging ongoing tasks. You want to 40

42 invest your resources in those programs and services that best meet your clients needs. Similarly, funders and supporters want to know their investment in your work is being well spent. It can be a struggle to provide proof of your healing impact on individuals, children, and families in the form of numbers, analysis, and evaluation. But when technology is used as an integral part of service delivery, it can address some of these challenges and even uncover new opportunities. Client management and outcomes tracking databases can help your organization achieve maximum effectiveness with limited resources. In the best cases, these tools increase service capacity and improve program effectiveness so you can better support those you serve and better understand and quantify your impact. Your EHR will: Capture information consistently and effectively. Software applications that record information in a database make data capture more useful and efficient. Staff can be required to complete specific tasks when entering data, assuring that critical service and client information is always there. Assist in the analysis of capacity, effort, and program effectiveness. Information collected in electronic form can be viewed, sorted and analyzed with far greater ease than manually collected data. The ability to view and manipulate information in different ways provides organizations with an in-depth understanding of what is working and what is not and allows them to direct their efforts where they will do the most good. However, numbers don't tell the whole story. There's a personal and unique story about every human being who interacts with your organization. Numbers alone cannot tell background stories or paint the whole picture of client/clinician interaction. It may not be in the best interest of one client to place her in a particular job situation due to her unique family situation. It may be counterproductive to place a child in a certain after-school program. Your staff will always have to make judgment calls about individual clients and situations so allow for clinical judgment-based alternatives to pick list options generated by the EHR. Computers in general and Electronic Health Records in particular are simply tools to assist those decisions. As you communicate with funders, government regulators and other organizations doing similar work, always focus on your true, client care mission rather than the beauty of your enhanced data. 41

43 ATTACHMENT A Recommendations for a Request for Proposal to Acquire Information Technology Systems (excerpted from An Information Systems Source Book, from the series Rethinking the Behavioral Health Organization, by Ronald L. Ravneberg, 2005 by Health Systems Consulting): 1. Purpose of the RFP Explain the reason you are making the procurement in the first place. 2. Project Coordinator Identify the individual who will be coordinating the RFP process. 3. Project Timetable Outline a timetable for the key steps in the procurement process and any subsequent system implementation. 4. Method of Bid Presentation Describe the type of vendor presentation you require (e.g., number of copies, sealed bid). 5. Oral Presentations and Demonstrations If you plan to require vendor presentations, say so and provide an approximate timeframe. 6. Site Visitations If you plan to conduct visits to any of the vendor s customers, say so. 7. Level of Effort Expected Clearly explain what you expect the vendor to include in his response. 8. Type of Cost Proposal Desired Identify the type of bid you expect (e.g., fixed price, cost plus, purchase, lease). 9. Economy of Presentation Don t ask for more than you need to make a procurement decision. Identify for the vendor the minimum acceptable response. 10. Incurring Costs If you don t expect to underwrite any vendor costs in the preparation of a response, clearly say so. 11. Statement of the Task Briefly describe what you are trying to achieve through the RFP (e.g., acquire a turn-key behavioral information system). Be sure to describe which applications you want to install (e.g., clinical, financial, operational). 12. Current Hardware/Software Inventory If you have existing computer equipment that might be useable in a new system, be sure to list it. 13. Type of System Envisioned Describe what you want to achieve with the new system and indicate any preferences you might have (e.g., enterprise-wide implementation, single vendor preferred, no developmental software). 14. Equipment Specifications If you have specific preferences about equipment, state them here. Be conservative when stating your preferences. Quite frequently organizations arbitrarily define specific technologies and thereby preclude otherwise qualified vendors from bidding on their projects. You may be familiar with or prefer a particular operating system or reporting capability, but don t state it as a required specification unless you simply cannot accept anything else. A vendor may have a better approach to your problem but won t be able to tell you about it because he doesn t meet your specifications. 42

44 15. Vendor Company Background This is the section of the RFP where you want to get some idea of who the vendor is and whether he qualifies as a potential business partner for your organization. Ask for the vendor s organizational structure and number of staff in each department, annual sales/budget, number, size, and type of customers where the proposed product is installed, and references from those installed customers. 16. Software This section of the RFP is where you capture information about the software being proposed by the vendor. 17. Proposed Software Functionality What application functionality is included in the proposed solution? 18. Application Packages What application software package(s) does the vendor propose to meet the customer needs outlined in the RFP? 19. Third Party / Database Software Required What software is required by the application that must be acquired from a third party, such as utilities, interface applications, translators, database management systems, etc. 20. Software Support Provisions What software maintenance and support does the vendor propose? 21. Software Enhancements & Upgrades What are the vendor s methods and guidelines for enhancement and upgrading of the proposed system? 22. Training & Implementation Support This is the section of the RFP where you want to get an understanding of the vendor s training and implementation support provisions. 23. Staffing What staffing levels does the vendor maintain for training and support of the proposed system? 24. Customer Training What types of staff training are available and what are the associated costs? 25. Implementation Support What types of implementation support does the vendor provide? 26. HIPAA Compliance How and at what level does the vendor s proposed application comply with HIPAA? 27. Hardware If the vendor is proposing or specifying server, network, or workstation hardware, ask for a description of the hardware maintenance and support services the vendor provides, or where it can be acquired if the vendor does not provide the service. 28. Software Functionality Checklists In this section of the RFP, provide a detailed list of the system/application functions you require, and specify which are mandatory and which are desired. Ask the vendor to respond whether each item is: Currently available (and installed somewhere) in the standard software, Available but not yet installed, Under development to become part of the standard application, Capable of being developed as a custom application at added cost, Not available, development not proposed. 43

45 29. Organization of the Proposal This is the section of the RFP where you define the structure of the vendor proposals. Having a defined content and order will greatly assist you when you are evaluating competing proposals from multiple vendors. An appropriate order might be: Letter of Transmittal Vendor Background Proposed Software Descriptions Training and Support Hardware Descriptions Hardware Maintenance Additional Services Cost Proposal Sample Contract Form 30. Proposal Due Date Set a fixed date and time when all vendor proposals are due. If the due date and time are to be rigidly enforced, be sure to say so. If extensions will be allowed or considered, say so. Remember that the goal of the RFP is to acquire the best possible system from the best possible vendor. Enforcing a strict due date without considering extensions may not contribute to this goal. 31. Bid Opening State a specific date and time that you will open vendor proposals and begin the evaluation process. Indicate whether vendors are permitted to attend the bid opening. 32. Rejection of Proposal You should reserve the right to reject any and all proposals and/or to award a contract to the proposal that is in your organization s best interest. Be aware that rejecting all bids and contracting with another vendor will probably generate a formal complaint from one or more vendors. 33. Proposal Duration State the period for which you expect vendor proposals to remain valid (e.g., 90 days after proposal submission). 34. Contract Negotiations You should reserve the right to negotiate an acceptable contract with the selected vendor. If you intend to require penalty payments for late delivery of hardware and/or software, state it here. You might also state your expectation that the prices quoted in the vendor s proposal are the lowest and best prices offered on the equipment and supporting application programs. 35. Bid Evaluation Describe the process you will use to evaluate vendor proposals, and whether different sections carry different weights in the evaluation. 36. Vendor Confidentiality It is appropriate for you to acknowledge that all proposals, documents and other materials submitted by vendors are for your organization s use only and will not be released to individuals not involved in the evaluation unless required by public domain or freedom of information statutes. 44