Managing electronic health record systems: collaboration and implementation
Mary Alice Hanken and Gretchen F. Murphy
Objectives
• Develop a strong working relationship with information systems staff.
• Understand the difference between project activities and operational activities.
• Identify the necessary skills to bring an information systems project to completion.
• Recognize the value of training in project success.
• Differentiate between a training manual and a user manual.
• Evaluate the success of systems projects.
• Identify both measurable metrics and organizational values addressed by a system.
• Recognize that systems projects move into an improvement phase after implementation.
Key words
Business data
Collaboration
Downtime
Project
Stakeholder
System life cycle
System testing
Training Manual
User
User manual
Abbreviations
EHR—electronic health record
HIM—health information management
I/S—information systems
IT—information technology
MIS—management information systems
Student Study Guide activities for this chapter are available on the Evolve Learning Resources site for this textbook. Please visit http://evolve.elsevier.com/Abdelhak.
When you see the Evolve logo 
, go to the Evolve site and complete the corresponding activity, referenced by the page number in the text where the logo appears.
This is an adaptation of a chapter written by Ellen Anderson in “Electronic Health Records: Changing the Vision.”
The growth of electronic systems across all business settings redefines the way information is used for the delivery of products and services. Healthcare, while slower to embrace technology in all areas, is now firmly engaged in bringing electronic tools to delivering health services of all kinds. This book presents the evolution of technology from many health care perspectives including legal and regulatory frameworks, business process technological advances, patient care outcomes, more effective use of data and, threaded among all of them, a recognition of the value, roles, and essential nature of information systems users. To make change happen effectively, health care leaders must identify, engage, and appreciate the user community and customers of institutional health information systems.
Value of user perspective
The business community, or “user,” perspective of systems projects can help business communities identify and initiate high level system project sponsors and stakeholders as well as address fundamental roles for users at multiple levels. Appreciating user roles enables institutional sponsors to: (1) understand the dependencies and the work effort involved in systems implementations, (2) hold realistic expectations of process and outcome, and (3) become a much more sophisticated partner in systems development and implementation.
A natural dependence
Computer systems in the workplace are tools applied to business functions. They are the workhorses of business. On an equal plane, computer systems fail to perform if data structure and databases, operating systems, interfaces, and networks are not well planned, robust, and technically compatible. This business community–computer division dependence should be more than just recognized; it should be embraced.
Environmental basics is a term the original author, Ellen Anderson, has created to define the “human elements” that exist as a natural part of humans composing work teams intended to accomplish specific tasks. The eight environmental basics covered in this chapter include personal commitment, trust, respect, policy setting to manage human behavior, expectations, vocabulary, understanding, and knowledge.
A stakeholder is any individual who has a stake or real interest in the computerization project and implemented electronic health record (EHR), regardless of department, position, or functional role in the company (Table 9-1).
Table 9-1
USERS OF THE ELECTRONIC HEALTH RECORD
| Physicians | Pharmacists |
| Nurses | Pharmacy technicians |
| Nurse’s aides | Laboratory technicians |
| Physical therapists | Radiologists |
| Occupational therapists | Radiology technicians |
| Speech therapists | Data analysts |
| Health information staff | Quality improvement analysts |
| Medical records staff | Utilization review coordinators |
| Care/case coordinators | Business office personnel |
| Dieticians | Social workers |
| Decision support analysts | Mental health specialists |
| AND THE LIST GOES ON AND ON . . . | |
The information technology (IT) division of most organizations has a title that includes the word “information.” This is true in health care organizations as well. A few examples are management of information systems (MIS), information technology (IT), and information services or systems (I/S). The abbreviation I/S is used in this chapter when referring to either the department itself or the staff of individuals in this unit of work activity in any organization. It is not surprising to note that more than one work unit of an organization may use the word “information” in its title. Both the computer department and the health information department are in the business of managing information for the health care industry.
Webster’s New Twentieth Century Dictionary of the English Language1 defines collaboration as “to labor, especially in literary or scientific pursuits, as the associate of another or others.” In this chapter, the term is used to refer to the combined labor of users and I/S staff in the pursuit of EHRs. The important word here is, of course, together.
Project, in the context of this chapter, means a unit of work to acquire or build and implement a computer system (software, hardware, and all infrastructure) with a definitive start date, targeted stop date, steps, milestones, and outcome.
Project work is quite different from regular operations in any organization. Table 9-2 illustrates some comparisons. The nuances of projects make collaboration that much more important and that much more challenging.
Table 9-2
| Projects | Operations |
| Peaks and valleys work flow | Steady stream of work |
| No direct authority, full responsibility | Full authority, full responsibility |
| Ad hoc teams | Business-aligned teams |
| Done once | Done repeatedly |
| Highly time dependent | Function dependent |
| Defined start and end dates | Not “start date” and “end date” dependent |
| Product/service driven | Business function/process driven |
Environmental basics (required for true collaboration)
The system “life cycle” has been used in describing computer system development for many years. Simply put, the stages of a system can be expressed in simple verbs: define, design, develop or buy, do (or implement), and support. That system life cycle then recycles to redefine, redesign, and so forth, in a continuous fashion until the system is no longer used and another takes its place. (See Chapter 8 for more information on the system life cycle.)
Define, design, develop, implement, redesign, redevelop, and do are all action verbs that involve groups, and lots of them. Because EHR systems happen through groups, environmental basics that are group oriented must be in place before an EHR project is started. All these environmental basics must be intact for project success. These same principles apply to a working relationship to improve and expand systems within an organization or in a community setting.
Four shared environmental basics
Personal commitment
Commitment is not easy when resources are tight, especially if the capital costs are high, the risks are great, and the resources are limited. Yet personal commitment to a project produces the political will to make the system happen. Nothing goes farther than a user who truly believes. Commitment needs to come, however, from all sides of the collaboration equation—from organizational leaders, system users, and I/S. Personal commitment is more than verbalization. It is quite easy to verbalize commitment; it is quite another matter to stand behind that commitment.
If you are starting a major systems project, use focus groups, surveys, and interviews to assess the level of commitment. Study the positive and negative feedback from all focus groups, surveys, or interviews. Is there a strong personal commitment to this project? Is the positive or negative perception warranted? Is it based on correct or incorrect facts? If incorrect, how can you correct them? Will correcting the facts change the degree of personal commitment? If correct facts have created a negative perception, can conditions be altered to raise the level of commitment? If users show strong personal commitment to the project, are they grounded in reality?
Grounded champions
User leaders and managers make the best system and project champions. Sometimes, however, they need accurate resource information to be truly grounded in their commitment and genuine excitement. User managers can be very serious about the project but also blind to the resource commitment of their operational people and budget to ensure success. Test their commitment before beginning the project. They will usually underestimate resources in terms of both people and money—it is human nature to wish it done quickly and at a cost less than realistic.
I/S managers are another important group who must be personally committed to the project. They are faced with an overwhelming number of requests to automate or update existing automation from all business units within the organization. Setting a high I/S priority to a project is usually propelled by a combination of (1) a compelling business reason and (2) the right technology fit and direction. For example, it makes no sense to automate a business function when the desired technology is not ready for general usage.
If I/S leaders declare a project a high priority, you are halfway there. Are there true capital dollars behind it? Is it assigned a budget? Is it a shared budget among a number of departments, including I/S? Is the budget “assigned” realistic? Does I/S appear ready with pen in hand to sign initial project documents if you moved forward immediately?
Trust
It has been said that the worst of projects were successful because, even during the down-and-out periods, project members and business communities trusted each other. Together they pulled a project through the battles to victory. It has also been said that the best of projects and systems failed because no trust existed.2 When no trust exists, each source of irritation or project component failure brings the project closer to its knees. A baseline level of trust must be in place as a project begins. Trust develops more completely as a project’s work groups or teams grow comfortable in the natural dependencies between them. There are various levels of trust in any collective group of people; EHR systems are no exception. All levels within an organization must trust, and be trusted, for maximum use of group synergy.
Those who hold the corporate purse strings, or control the organizational finances, must trust the rest of the organization to be good stewards of the millions of dollars often required to get a system into production. They must also trust that the proposed budget reflects the true costs or costs as commonly computed within the organization. If they take the fiscal stewardship of the organization seriously, they will ask for a cost/benefit analysis or strong reasons about value to help in their prioritization of this capital expenditure relative to other capital expenditure requests.
Project steering committee members need to trust that their fight for the capital dollars will result in tangible computer systems. They also must trust that the people who will be empowered to select or create and implement the system have the talents and the will to do so. They may also trust that the potential system users have or will acquire the computer skills and aptitudes needed to use the system. Do they have these trusts?
User managers are the most trusting of all, especially if they are true champions of a potential system. They trust that the people above them will act on their commitment of resources. They trust that the users they supervise will embrace the system, or at least accept it and make it work. They trust that I/S staff know how to implement and support the desired system, have budgeted appropriately, and will supply resources when needed.
If a system will be purchased, the organization must trust vendor representatives who provide sales information about the product, help to configure the system for use, and support implementation at time of going live. Do they trust that the vendor will deliver the promised system? Will the vendor work to fit their product to the client’s environment or build only what sells in the marketplace?
The I/S staff must trust the user community to know what it wants and needs in system functionality. They must also believe that the users will deliver the human resources necessary to participate actively in the project that the user community will ultimately own. They must also trust that the business community stands ready to basically own and functionally support the system after implementation.
Users, then, must trust all of the above. Do users see the above groups as trustworthy? Do they perceive that the above groups will deliver? Is this particular project a “wise” use of the organization’s dollars in their minds? Will the various departments really support users through initial training, implementation, institutionalized training and retraining, and system support?
Through the focus groups, interviews, and surveys, distrust may appear. Has I/S “let down” the user community in the past on the basis of technical promises not kept or a cost that is three times the estimate? Has the business community ill defined a system and “wasted lots of I/S dollars” trying to define it while in the middle of system development? These are two very common distrust statements. Neither contributes to future project success.
The potential list of double-sided “done me wrongs” could go on and on. This is truly only project background garbage and needs to be cleaned up before a good working relationship can develop in the dynamics of working groups and team efforts. Distrust does not contribute to positive group synergy.
Respect
In information systems projects, the caste system that exists in most health care organizations can quickly disappear. The appointment clerk can be as important or more important than the physician in an appointment scheduling system implementation. This creates some interesting team membership. A baseline level of respect between project players can hasten the comfort level of multidiscipline, multibusiness unit project teams who have seldom worked side by side. Individuals need to feel respect, regardless of what role they play in the organization or in an automation project.
Equally critical factors in system implementation are two common problems with systems work: (1) resource tug-of-war and (2) timeline tag. Because there are so many components included with systems, planned people resources will likely get “shuffled” a lot, and unplanned resources will continually knock on managers’ doors for staffing. For example, a user manager may have planned to have two of the staff “free” in May for 2 weeks for user testing, but the user testing will be delayed 3 weeks because of a delay in receipt of equipment. The staff is now needed in June, possibly not a good time from the business unit’s perspective.
Using the delayed equipment example above, the project timeline has now leaped forward by at least 3 weeks. Project teams will be trying to play timeline tag to catch up or move the “go-live” date forward. If the “go-live” date is a “hard date” (which means it cannot be changed—perhaps it is a regulatory compliance date, for example), the pressure to play the tag intensifies.
Project teams and managers must be sensitive to user frustration resulting from this resource shuffling and the timeline movement, and the user community must be sensitive to what components of the project work are truly under the control of the project manager and teams.
It is also important to understand that the user community can cause the delays as well. Turning the tide, the user community can cause a delay because an operations activity suddenly “takes priority” or a consensus activity within the user community cannot be scheduled for when it was originally planned.
Gauge what mutual respect exists between the business units to be involved with the automation project and between the collective business units and the I/S staff. Does each appreciate the role and work effort of the other? Does each appreciate the time it takes to accomplish the designated work effort that contributes to the whole of the organization?
Policy setting
It has been appropriately said that policies and principles manage human behavior. These directives for human behavior guide both system development and the project teams developing them. In large measure, data access, data use, data content, data standards, authentication, electronic signature, data exchange standards, data release, and data security are focused subjects for policies and principles directly guiding EHR systems. For example, patient confidentiality will remain a major concern until appropriate policies are in place that address patient identifying data running through FAX lines, internal messaging software, the Intranet, the Internet, and today’s rapidly developing wireless technology, and any other technology that develops in the future. The same concern appears as a data warehouse or clinical data repository project kicks into gear because data are suddenly pulled from a transaction processing system where individuals have an easily established “need to know” and moved into the organizational hands of an entire enterprise. The warehouse or repository will create a need for new policies and procedures related to data access, use, and retention.
As the rate of technology advancement intensifies, policies and principles quickly become outdated and ineffective guides to human behavior amid exciting new automation. Project teams can become foes as one pushes ahead with no clear organizational directive while the other refuses to move without it. The users and I/S staff can quickly become antagonistic. Before this happens, the organization must create the appropriate behavioral framework for use in that organizational culture. Collaboration, then, is not hindered by lack of organizational directives for human behavior.
It takes real courage to develop such policies. Those who are pushing hard for the system can label policy makers a hindrance to automation because they anticipate that policy setting will result in a more complex system or a time delay. They may be right. Those who have this perception do not understand that this policy-setting work is as normal to system development as programming screens are. It is best to establish this policy through an enterprise-wide group that (1) takes the stewardship of data, especially patient identifiable data, to heart and (2) takes on the scope of “setting confidentiality criteria that would provide a basis for new applications and for new delivery system models.”4
Four unshared environmental basics
So far, we have talked about four shared environmental basics. There are four other environmental basics; however, that will not be initially nor automatically shared between I/S and the user community.
