Disc 3 IT health Admin

105

Chapter 5 System Selection and Implementation

Objectives

Assist in the system selection process.•

Assist in the system implementation.•

Participate in the implementation team.•

Develop training materials.•

Assist in the development review of the request for proposal.•

Assist in the system analysis process.•

Conduct training classes for users.•

Key Terms

Alpha site

Application service provider

(ASP)

Best of breed

Best of fit

Beta site

Chief information officer

Computer-assisted instruction

Data conversion

Escrow

Feasibility study

Force majeure

Functional requirements

Gantt chart

Go-live

Graphical user interface (GUI)

Information systems project

steering committee

Information systems strategic

planning

Interface

Interface engine

Middleware

Payment milestone

Project

Project definition

Project Evaluation and Review

Technique (PERT) chart

Project management

Project manager

Project team

Prototype

Reengineering

Report design

Request for information (RFI)

Request for proposal (RFP)

Scope creep

Screen design

Setting configuration

Site preparation

Site visits

Source code

System analysis

System development life cycle

(SDLC)

System evaluation

System implementation

System selection

Test environment

Testing

Train the trainer

User preparation

User task force

Weighted system

AB103409_ch05.indd 105AB103409_ch05.indd 105 2/1/10 1:20:38 PM2/1/10 1:20:38 PM

C o p y r i g h t 2 0 1 0 . A H I M A P r e s s .

A l l r i g h t s r e s e r v e d . M a y n o t b e r e p r o d u c e d i n a n y f o r m w i t h o u t p e r m i s s i o n f r o m t h e p u b l i s h e r , e x c e p t f a i r u s e s p e r m i t t e d u n d e r U . S . o r a p p l i c a b l e c o p y r i g h t l a w .

EBSCO Publishing : eBook Collection (EBSCOhost) - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS AN: 667498 ; Nanette B. Sayles, Kathy C. Trawick.; Introduction to Computer Systems for Health Information Technology Account: s4264928.main.edsebook

106 Chapter 5

Introduction

System selection and system implementation is the process of deciding on an informa- tion system (IS), preparing it, and training facility staff for use of the system in the health- care facility. The system selection and implementation process begins with the idea that the facility should consider obtaining a particular system such as the electronic health record (EHR), for example. The process continues until the system is in use and has been evalu- ated as to whether or not it meets the established objectives.

The complexity of the system selection and implementation process varies widely, from implementing Microsoft Office or other standard software products to the very complex implementation of an EHR system. The length of time required thus varies from a few days or weeks to months or even several years. The number of people involved will also vary based on who is impacted by the system and the complexity of the system to be implemented.

Systems selected should support the facility’s business objectives. The systems should be identified and prioritized during the information systems strategic planning process, as more systems are usually identified than the facility’s resources can handle. Strate- gic information system planning is defined as “the process of identifying and assigning priorities to the application of information technology that will assist an organization in executing its business plans and achieving its strategic goals and objectives” (Austin and Boxerman 2003, 259). For example, if a facility’s business objective is to meet a goal of improved quality of care, then the facility should look for information systems that would support this goal, such as the EHR or clinical provider order entry (CPOE). The EHR would improve the quality of care because of the immediate access to patient information as well as the use of alerts and other features. The CPOE would improve care because the orders would be immediately available to the ancillary department, and the healthcare pro- vider would be able to take advantage of reminders and alerts regarding contraindications, the need for laboratory tests to monitor blood levels, and so on.

Steps included in the system selection process are:

Planning•

Organization of the project•

System analysis•

Request for proposal•

Evaluation of systems•

Selection of a system•

Contract negotiation•

Steps included in the implementation process are:

Site/space preparation•

Installation of hardware/software/networks•

Programming modifications to software•

User configurations and settings•

Interface development•

Report design•

Screen design•

Testing•

Training•

AB103409_ch05.indd 106AB103409_ch05.indd 106 2/1/10 1:20:38 PM2/1/10 1:20:38 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

System Selection and Implementation 107

Go-live•

Evaluation•

Some of the system selection and implementation steps are linear, but others can be performed concurrently. For example, the contract has to be signed before the software can be installed, but the organization can design screens and reports at the same time. It is imperative to remember that throughout implementation and planning, the plan itself is a working document and will continuously change and evolve. Flexibility is necessary. Each of the system selection and implementation steps will be covered in this chapter.

Planning

Planning is critical to the system selection and implementation process. Planning for an information system is a complex process and includes many steps such as:

Conducting a feasibility study•

Setting the budget•

Setting the goals and objectives•

Identifying the project manager•

Identifying the project team•

Determining who will build and maintain the system•

Choosing between integrated and interfaced systems•

Obtaining buy-in from management and users•

Training•

Planning a major system implementation requires a lot of work by a lot of people. A lack of planning can and will cause problems with the system, which can cause the system to fail or delay the implementation date, thus costing the facility money. An example of poor planning is ordering hardware without evaluating the space. Insufficient space can lead to inability to install the hardware due to insufficient electrical wiring, inadequate space, or other problems with the physical plant.

Conducting a Feasibility Study

A feasibility study determines if a proposed information system is an appropriate option to meet the objectives of the organization (Englebardt and Nelson 2002). The study exam- ines the costs, the benefits, and any expected problems and determines whether or not to proceed with the proposed system. The benefits should be both tangible and intangible. Tangible benefits are easy to quantify (Austin and Boxerman 2003), such as elimination of duplicate tests. Intangible benefits, while critical, are not easy to quantify. An example of an intangible benefit would be to improve quality of care. If the benefits do outweigh the costs, then the project should be considered.

Setting the Budget

Developing the budget for a system implementation is important since cost is a key deter- mining factor in deciding whether or not to implement. The budget should be comprehen- sive and as accurate as possible because it is used in the decision-making process. The budget should include system selection and implementation expenses as well as the cost of maintaining the system for a specified period of time, such as 2 to 5 years. Additionally, the budget should include items such as cost of software, upgrading infrastructure, hardware, training, renovations to the physical plant, maintenance of the system, project manage- ment, and travel expenses for site visits.

AB103409_ch05.indd 107AB103409_ch05.indd 107 2/1/10 1:20:38 PM2/1/10 1:20:38 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

108 Chapter 5

Goals and Objectives

Goals and objectives for the system must be established as part of the planning process. The goals and objectives identify what the facility wants to accomplish with the implemen- tation of the proposed system and how these goals will be achieved. These system goals should be based on the facility’s business goals (Austin and Boxerman 2003). As with any goals, they should be measurable yet realistic and attainable. It never hurts to add on some cushion time for any unforeseen issues. Examples of goals are: to reduce the number of staff by five, to reduce the discharge not final billed (DNFB) report to $500,000, and to reduce the number of duplicate tests by 75 percent. Goals will be determined by the type of system and the needs of the facility. Once established, goals should be used to identify which information system best meets the desired outcomes.

Once the system is implemented, it should be evaluated regularly thereafter as to whether the system met and will continue to meet or exceed the stated goals and objectives. For example, the post-implementation evaluation will identify whether the duplicate tests were reduced by 75 percent or whether staffing was reduced by five.

Identifying the Project Manager and Project Team

The project manager and project teams are an important part of project management. Proj- ect management is “a formal set of principles and procedures that help control the activi- ties associated with implementing a usually large undertaking to achieve a specific goal, such as an information system project” (Amtayakul 2007, 467). Project Leadership includ- ing the project manager and the project team members should be identified before the project begins. The project manager leads the project, and therefore must have an under- standing of the system being implemented, knowledge of project management, leadership skills, and conflict management skills (Amatayakul 2007). A sample project manager job description is presented in figure 5.1. The project manager is responsible for ensuring that the project plan stays within the designated timeline, issues are resolved, desired outcomes are met, and customer satisfaction is achieved. A project team is a collection of multi- disciplinary individuals (that is, billing, clinician, administration, IT) assigned to work on a project. Their role is important because they are responsible for ensuring that the system implementation plan is carried out according to the project manager’s specifications. Their backgrounds will vary according to the needs of the project (Amatayakul 2007). For exam- ple, implementation of an EHR will require information system staff, health information management, physicians, nursing, and other clinical users of the system. The project team will be discussed in detail later in the chapter.

Determining Who Will Build and Maintain the System

One of the critical decisions to be made during the planning process is whether a facility should build the system itself, purchase it from a vendor, or use an application service provider (ASP) (Austin and Boxerman 2003).

An ASP is a third-party service company that delivers, manages, and remotely hosts (off-site, usually at the host location) standardized applications software via a network through an outsourcing contract based on fixed, monthly usage or transaction-based pric- ing (Amatayakul 2007).

With an ASP, a user simply logs into the system and accesses it exactly as if the data center were located in-house, although the data center may be located at a great distance from the facility. An ASP is similar to paying rent and can significantly reduce the capital expenditures up front, and monthly expenditures are a preapproved flat-fee structure so expenses are always known. This method is favored by facilities that do not have staff with the necessary skills to develop and maintain a system. A disadvantage to the ASP format is that the user may not have as much control over the system. For example, the scheduling of maintenance and upgrades is up to the host, and the client has no say in the matter. Another disadvantage is that since an organization is “renting” the system, it is not investing in its

AB103409_ch05.indd 108AB103409_ch05.indd 108 2/1/10 1:20:38 PM2/1/10 1:20:38 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

System Selection and Implementation 109

Position: EHR Project Manager

Reports to: Chief Science Officer

Key Functions and Responsibilities

Integrated Healthcare Information

1. Using an evidence-based approach, facilitate culture of having integrated healthcare information by screening clinical systems for appropriate fit, integration potential, and timing of projects based on EHR architecture. This will be done in partnership with the chief information officer and person(s) championing the specific clinical system.

Electronic Health Record System

2. Direct selection and implementation of EHR components to include: a. Enterprisewide master person index b. Clinical data repository c. Document imaging to include medical (for example, PACS) and administrative images d. Physician order-entry and electronic signature capabilities e. Patient care documentation f. Clinical decision support tools to include:

(1) Clinical alerts and reminders (2) Care management protocols

g. Other information systems and emerging technology as necessary and feasible

3. Lead break-through project team to deliver the following: a. Longitudinal record of patient care across the organization’s continuum of care sites b. Clinician utilization of EHR that facilitates and enhances patient care delivery processes at the point of care

and remotely as appropriate c. Patient interaction with clinicians, access to their personal health record of care at the organization, and quality

education d. Tools that facilitate cost-effective care management and respond to a growing number of managed care

contracts e. Capacity to perform large patient database searches and studies without impacting the performance of the EHR

in day-to-day activities f. Support for the organization’s training and research programs

Business Process Redesign and Information Protection

4. Coordinate reengineering of work flows and patient care documentation with clinical users to leverage and maximize organizational and personal productivity to improve patient care delivery processes.

5. Ensure that systems selected are compliant with all applicable laws, regulations, and standards, and that their storage, retention, authentication, accuracy, and transmission integrity support admissibility.

6. Develop processes for determining who has access to specific health information; how users will be educated, trained, and kept continually aware of patient privacy and security requirements to provide data confidentiality, integrity, and availability; and ensure that ongoing auditing of access is performed and supported by appropriate sanctions and disciplinary processes.

Budgetary/Operational Responsibility

7. Develop and account for operating and capital budgets for above processes.

8. Determine appropriate staffing and resource requirements for the EHR project.

9. Establish appropriate metrics and monitor benefits realization.

Skills/Experience Required:

• Knowledge of health information management and technology, clinical user needs, and healthcare work flow • Extensive and progressive healthcare management experience • Experience with the selection and implementation of healthcare information systems • Ability to enroll and build strong relationships with all levels of management, physicians, and staff • Ability to lead a project team through uncharted territory, shift paradigms, take risks, and bring ideas from concept

to reality • Relentless focus on outcomes

Figure 5.1. Project manager job description

Adapted from Job Description for Director, Integrated Healthcare Information, Central DuPage Health System, Ann

Ogorzalek, RHIA

AB103409_ch05.indd 109AB103409_ch05.indd 109 2/1/10 1:20:38 PM2/1/10 1:20:38 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

110 Chapter 5

own structure and therefore would have to make a large investment should it ever decide to bring the system in-house.

The second option would be for the facility to build the system. If a facility decides to build a system, it would be designed to meet the specific needs of that facility. The system would have the look and feel that is desired as well as the desired functionality. There are, however, disadvantages such as:

It could take longer to develop.•

The planning must be more detailed than if purchasing a system.•

If the facility loses the staff that developed the system, it may be difficult to • upgrade the system to meet the needs of the facility over time.

The final option mentioned here would be to purchase a predeveloped software system from a vendor. As with the other options, there are advantages and disadvantages to this option. A system purchased from a vendor may not be exactly what the facility wants, but it would be faster to implement, and the facility would benefit from extensive research and development conducted by the vendor. The design of the system would be less detailed, but the facility would have the use of the vendor’s customer support system to assist with upgrades and problems that arise.

When working with a vendor, the healthcare facility may have the opportunity to be an alpha site. An alpha site is the first healthcare facility to implement the information system. The facility generally receives a discount for the system in exchange for participation in the development of the system. Because the system is still being developed, the facility may face problems with the implementation that would not be encountered with a more mature version of the same system. It also takes more time than a typical implementation. The facility may also be asked to be a beta site. Beta sites are the next few healthcare facilities who subse- quently implement the system. Many of the problems with the system are resolved with the alpha site but these beta sites are likely to encounter numerous problems as well.

Choosing Between Integrated and Interfaced Systems

If the decision is made to purchase an information system from a vendor, the next decision is whether the product should be integrated or interfaced.

Integrated Systems Integrated systems are designed to work together. A good example of an integrated system is Microsoft Office. The user can share information among Microsoft Word, Microsoft Excel, and other products within the Office suite. Many healthcare vendors use this model to interface systems used by healthcare facilities. This type of system is much easier to manage than an interfaced system because of the lack of interfaces. Integrated systems collect, store, and retrieve information from the same database and, further, technologies allow that they support each other. The user is quickly able to move between systems because they have the same look and feel, which can also make it easier to use (Austin and Boxerman 2003). The decision to purchase software from a single vendor is frequently called best of fit (Amtayakul 2007).

Interfaced Systems In an interfaced system, the products are not designed to work together, but rather are linked through an interface. An interface takes data from one system and plugs that data into another system. In other words, an interface acts as a bridge between two systems/data- bases to translate data into each system’s respective language. Interfaces will be discussed in detail later in the chapter. An interface has to know what data to retrieve, where the data are located in the first database, whether any data manipulation has to be performed, what that manipulation is, and where the data are to be entered into the second database. If the interface is not working, the systems will not be able to share information until the prob- lems with the interface are resolved (Austin and Boxerman 2003).

AB103409_ch05.indd 110AB103409_ch05.indd 110 2/1/10 1:20:38 PM2/1/10 1:20:38 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

System Selection and Implementation 111

Although an interfaced system takes more effort to manage, many facilities choose this method because the facility’s users can choose the various products that they want instead of choosing a single vendor’s product, which may have a wonderful encoder but an inadequate laboratory information system, for example. Choosing the systems based on functionality rather than by vendor and interfacing them is frequently the option selected. Choosing the best product for your organization regardless of vendor is called choosing the best of breed (Amatayakul 2007).

Obtaining Buy-in from Management and Users

It is critical that the facility’s upper management support the project from the very begin- ning of the process. If management shows support for the system, the employees will fol- low suit and support it. However, if management displays discontent or lack of support, the employees will be most likely to resist the change. Support can be shown by attending meetings, talking about the system’s benefits to the organization, its employees, and its customers, and generally demonstrating that the system is valued. Communication is criti- cal here. Remember to keep staff and all those to be affected by the system updated to the decisions, the changes, and all expectations. The more the personnel are informed, the less likely for resistance to occur because they will know what to expect.

The Importance of Planning

The importance of planning becomes evident when the most common reasons for project failures are examined. According to Young (2000) these reasons are:

Lack of clear vision•

Inadequate resources•

Lack of planning•

Use of inappropriate resources•

Lack of experienced staff to complete assigned tasks•

Unrealistic expectations•

Other reasons for project failure include lack of training, poor communication, and an inadequate system.

If a facility spends more time and energy on the front end of a system implementation project, it will be better positioned to succeed. Adequate planning is demonstrated, in part, when the facility has from the outset of the project the necessary staff, money, and other resources, as well as an understanding of what is needed and what the desired outcomes are expected to be.

Organization of Project

Once the decision is made to implement a system, the project’s formal organizational struc- ture must be put in place. A project is a plan and course of action that will address a spe- cific objective, made up of a series of activities and tasks with a defined start and stop date. The plan has a targeted objective and deliverable to be accomplished. The project will need specific resources assigned to it in order to be completed (Abdelhak et al. 2007).

Project Team

Most, if not all, information system projects require a team of individuals to successfully implement the system. The number of individuals needed and the make-up of this team vary from project to project depending on the needs of the implementation (Austin and Boxerman 2003). For example, if the facility is implementing a chart deficiency system

AB103409_ch05.indd 111AB103409_ch05.indd 111 2/1/10 1:20:38 PM2/1/10 1:20:38 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

112 Chapter 5

for use only in the health information management (HIM) department, the team should include the appropriate people in HIM and information systems. The team would not need to include physicians, nurses, risk managers, or laboratory staff. If the facility is imple- menting an order entry system, the team would need representatives from the physician staff, as well as from the HIM, nursing, laboratory, and pharmacy departments to ensure that the system is properly planned and developed.

An HIM professional will frequently sit on the committee because the system may impact the HIM department indirectly, and having an HIM professional involved in the process can help ensure that the department’s needs are addressed. Additionally, the HIM professional can serve as a consultant and source of information for compliance, legal, and other concerns. For example, the HIM professional can assist with retention, privacy, security, and documentation issues, among many other considerations of the system, which may ultimately affect the HIM department.

The major participants in the project management team are the information systems project steering committee, the project manager, the user task force, the project team, the vendor, and, possibly, one or more consultants. These roles are described here:

The • information systems project steering committee is responsible for every information system acquisition project in the facility (Wager et al. 2005). Each project team will report back to the steering committee. The steering committee’s role is to ensure that the strategic information system plan is being efficiently and effectively implemented and that the project stays on target (LaTour and Eichenwald Maki 2006). This committee is frequently led by the chief information officer (CIO). The CIO is generally at the vice president level and is responsible for all information resource management functions at the facility. The information system, HIM, and other information management departments frequently report to the CIO. The CIO must be a visionary and have strong management skills. While the CIO is not a technical role, the individual must understand enough about information technology to ensure the proper management of the systems (Glandon et al. 2008). Other team members may be administrators, managers, project managers, and other leaders in the facility.

The project team works with the project manager to implement and manage • the project. This team will meet periodically, based on project needs, to discuss progress of the project and any issues that arise. The project team generally meets less frequently in the early stages of the project; the frequency increases as the implementation date gets closer. The team may even meet daily right before go-live. This team should be multidisciplinary. The makeup of the team will be determined by the type of system being implemented and its complexity. The team should include information system staff, clinicians, HIM personnel, and others as appropriate. It is important to include a representative from facility management if possible, to show support for the system.

The • project manager is responsible for coordinating the individual project, monitoring the budget, managing the resources, conducting negotiations, and keeping the project on schedule. These roles require the project manager to have both technical and analytical skills as well as people skills. The project manager should be skilled in conflict resolution, communication, and project management. Leadership skills are also important because the project manager must be able to develop a consensus and manage meetings for the project team.

The • user task force is a group of users, who will ultimately be using the system, that test the system and perform other project-related tasks for which the committee receives feedback. These users are generally on loan from various departments to assist in the project. Some members of the user task force may be deployed as needed for testing (performing an examination or evaluation) and other tasks, whereas others are pulled out of their department for the duration of

AB103409_ch05.indd 112AB103409_ch05.indd 112 2/1/10 1:20:39 PM2/1/10 1:20:39 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

System Selection and Implementation 113

the project. This reassignment may last a year or more depending on the project (Kreider and Haselton 1997).

The vendor representative is the expert on the system and so will be an • extremely valuable team member. This individual will be the liaison between the facility and the leadership at the vendor’s company. The vendor representative knows the product and can be a valuable resource with regard to how best to implement and use the system. Additionally, he or she can give the project team information on what has (and has not) worked for other facilities. This information can help the facility recognize and use best practices, and help it avoid costly mistakes. If not scheduled to be on site during a meeting, the vendor representative may need to meet via telephone conference due to their expertise (Kreider and Haselton 1997).

If the facility decides to hire a consultant, the consultant will be a valuable • member of the team as well. The consultant hired should not have ties to a particular vendor’s product, but rather be objective to help the facility obtain the product that best meets its needs. The consultant should have experience in system selection and implementation.

Project Identification

Before any decisions are made, the facility must define what the accomplished project is. The project definition is defined during the project planning process to tell the facility exactly what it is trying to do with the system being implemented and the expected out- comes (Kreider and Haselton 2003). The facility must identify:

The purpose of the system•

How the system links to the facility’s business strategy•

The goals for and scope of the project•

The scope of the project determines exactly what work is—and is not—to be included in the project based on resources available. Identifying the project’s scope is important to prevent scope creep. Scope creep happens when items not included in the original scope are added after the project has begun. The additions to the project will increase the time needed for the project and the money and resources required to accomplish it (Englebardt and Nelson 2002).

Once the facility knows what it plans to do, the project team can begin dividing the project into specific activities or tasks. The team may start out with a basic skeleton of a project plan and continue to add substance to it as they go along. This plan should describe each task to be completed, how it will be completed, who is responsible for its completion, when a task should begin, and when the task should be finished. The basic components of the plan are:

Feasibility study: This study defines the objectives and need for the project and • justifies the plan.

Resources: The resource plan identifies the resources needed in order to meet the • objectives of the plan. This includes money, time, staff, space, and other resources.

Design: In the design stage, the project team identifies the specific details required • to implement the plan. For every task identified, the plan must provide a start and end date and a person responsible. If the project requires programming, the team must establish the standards that will be used in writing the program.

Hardware and software procurement: This stage includes ensuring that the facility • has all of the hardware and software needed and that any missing components

AB103409_ch05.indd 113AB103409_ch05.indd 113 2/1/10 1:20:39 PM2/1/10 1:20:39 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

114 Chapter 5

arrive in a timely manner. Hardware delivery may take 6 weeks, for example, so ordering needs to be done early in the process.

Transition: The transition phase prepares the facility for the conversion from the • old system to the new. This stage includes not only the actual conversion of data, but preparing staff for the change.

Implementation: The implementation stage includes the steps to be taken to • prepare for the implementation and the actual conversion to the new system.

Postimplementation: The postimplementation stage begins immediately after • implementation is complete. The team must evaluate itself to prepare for the new project. It should also include an evaluation process to determine if the objectives of the project were met and how the process could have been improved (Kreider and Haselton 1997).

The level of organization for the project depends on the level of complexity of the system being implemented. If it is a small department system, it may only require two to three people to implement. Large systems that impact the entire facility can take hun- dreds of people. In large projects, there are frequently subcommittees that are responsible for small areas of the project. The subcommittees meet and work on their segment of the project. The chair of the subcommittee then reports back to the full project committee.

Project Tools

There are a number of tools that can be used to control the project. These tools include Gantt charts and PERT charts, project plans, trouble tickets, and status reports.

The project plan provides details for how to accomplish the project. It directs • and guides the team on activities, time, costs, and sequencing of activities. It also provides a narrative description of the project. The project plan could include project tools such as the Gantt chart and the PERT chart (Abdelhak et al. 2007).

The • Gantt chart (see figure 5.2) is a project management tool that records specific tasks, their start and end dates, the person responsible for the tasks, and any connections between tasks. The Gantt chart can easily show which tasks are behind schedule, which are on target, and which are ahead of schedule (Abdelhak et al. 2007).

A Project Evaluation and Review Technique • (PERT) chart (see figure 5.3) is a management tool that evaluates the tasks, dependencies on other activities, activity sequence, and the time required to complete the task. Because the PERT chart shows interdependencies between tasks, it will help determine whether the implementation date is slipping due to delinquent tasks (Abdelhak et al. 2007). This slippage is shown by review of the critical path. Because the critical path shows the longest amount of time to complete the project, if key tasks along the critical path are delayed, the critical path itself lengthens, thus lengthening the duration of the project.

Status reports are periodic updates on where the project is, what has been • accomplished, and what problems have been encountered. Solutions for the problems should be identified in the report. Status reports are typically directed to the information systems project steering committee to keep that group informed on the project’s progress. The status report is generally written by the project manager, but could be written by a designee.

The trouble ticket is a tool used during the implementation phase to document and • track problems encountered. The project manager keeps track of all trouble tickets turned in, assigns someone to be responsible for the resolution of the problems, and monitors the tickets for closure. Some of the issues recorded may be minor,

AB103409_ch05.indd 114AB103409_ch05.indd 114 2/1/10 1:20:39 PM2/1/10 1:20:39 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

System Selection and Implementation 115

Figure 5.2. Sample Gantt chart

whereas others may be major. Either way, all of the problems recorded by the trouble tickets should be resolved prior to implementation of the system.

Figure 5.2 shows an example of a Gantt chart, and figure 5.3 shows an example of a PERT chart.

Additionally, software such as Microsoft Project can be used to help manage a project. Project management software can create the Gantt and PERT charts as well as other types of tools for the project team to review. It can also track how much of each task is complete (0 to 100 percent), who has been given the responsibility for each task, the beginning and ending dates, the sequencing of tasks, and more.

AB103409_ch05.indd 115AB103409_ch05.indd 115 2/1/10 1:20:39 PM2/1/10 1:20:39 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

Identify project manager Start: 8/8/08 ID: 1 Finish: 8/8/08 Dur: 1 day Res: Chief Information Officer

Identify project team Start: 8/11/08 ID: 2 Finish: 8/15/08 Dur: 1 wk. Res: Project Manager

Conduct systems analysis Start: 8/18/08 ID: 3 Finish: 1/30/09 Dur: 6 mos. Res: Project Team

Write RFP Start: 2/2/09 ID: 4 Finish: 3/13/09 Dur: 6 wks. Res: Project Team

Distribute RFPs to vendors Start: 3/15/09 ID: 5 Finish: 3/17/09 Dur: 2 days Res: Project Manager

Meet with vendors Start: 4/5/09 ID: 6 Finish: 4/6/09 Dur: 1 day Res: Project Manager

Update network to accommodate increased traffic Start: 9/7/09 ID: 16 Finish: 9/24/09 Dur: 14 days Res: Network Administrator

Develop training plan Start: 9/7/09 ID: 21 Finish: 10/30/09 Dur: 2 mons. Res: Project Team

Identify data conversion needs Start: 9/29/09 ID: 22 Finish: 10/3/09 Dur: 5 days Res: Project Team

Write program required for data conversion Start: 10/6/09 ID: 24 Finish: 10/31/09 Dur: 1 mon. Res: Programmer

Correct errors identified in testing Start: 1/26/10 ID: 27 Finish: 2/22/10 Dur: 1 mon. Res: Programmer

Test software Start: 12/1/09 ID: 26 Finish: 1/25/10 Dur: 2 mons. Res: Project Team

Receive RFP submissions Start: 4/7/09 ID: 7 Finish: 5/4/09 Dur: 1 mon. Res: Project Manager

Review RFPs Start: 5/5/09 ID: 8 Finish: 6/1/09 Dur: 1 mon. Res: Project Team

Site visits Start: 6/2/09 ID: 9 Finish: 6/29/09 Dur: 1 mon. Res: Project Team

Check references Start: 6/30/09 ID: 10 Finish: 7/6/09 Dur: 1 wk. Res: Project Team

Make decision on system Start: 7/7/09 ID: 11 Finish: 7/13/09 Dur: 1 wk. Res: Project Team

Sign contract Start: 7/14/09 ID: 12 Finish: 7/20/09 Dur: 1 wk. Res: Chief Information Officer

Order hardware for users and data center Start: 7/21/09 ID: 13 Finish: 7/27/09 Dur: 1 wk. Res: Project Manager

Install hardware in computer room and units Start: 9/7/09 ID: 15 Finish: 9/24/09 Dur: 14 days Res: Technology Support

Install software on file server Start: 9/25/09 ID: 17 Finish: 9/25/09 Dur: 1 day Res: Technology Support

Configure settings in system Start: 9/28/09 ID: 18 Finish: 10/23/09 Dur: 1 mon. Res: Project Manager

Write routine reports Start: 9/29/09 ID: 19 Finish: 12/18/09 Dur: 3 mons. Res: Project Team

Develop new screens Start: 9/29/09 ID: 20 Finish: 12/18/09 Dur: 3 mons. Res: Programmer

Write interfaces Start: 9/28/09 ID: 23 Finish: 11/20/09 Dur: 2 mons. Res: Programmer

Write user manual, training materials, and policies and procedures Start: 10/26/09 ID: 25 Finish: 4/9/10 Dur: 6 mons. Res: Project Team

Train the trainers Start: 4/12/10 ID: 28 Finish: 4/23/10 Dur: 2 wks. Res: Vendor

Conduct training Start: 4/26/10 ID: 29 Finish: 6/18/10 Dur: 2 mons. Res: Trainer

Go-live Start: 6/21/10 ID: 30 Finish: 6/23/10 Dur: 3 days Res: Project Team

Acceptance testing Start: 6/24/10 ID: 31 Finish: 8/18/10 Dur: 2 mons. Res: Project Team

Evaluation of implementation Start: 8/19/10 ID: 32 Finish: 9/1/10 Dur: 2 wks. Res: Project Team

Site preparation (add outlet, shift existing computers) Start: 7/21/09 ID: 14 Finish: 7/23/09 Dur: 3 days Res: Project Manager

Figure 5.3. Sample PERT chart

A B

1 0 3 4 0 9 _ ch

0 5 .in

d d 1

1 6

A B

1 0 3 4 0 9 _ ch

0 5 .in

d d 1

1 6

2 /1

/1 0 1

:2 0 :3

9 P

M 2 /1

/1 0 1

:2 0 :3

9 P

M EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

System Selection and Implementation 117

Check Your Understanding 5.1

1. True or False: The information systems project steering committee is responsible for the day-to- day implementation of new systems.

2. The process that outlines the cost, benefits, and disadvantages of the proposed systems is the:

A. feasibility study B. project plan C. trouble ticket D. status reports

3. The PERT chart shows if there is slippage in the implementation date. This slippage is shown by:

A. dependencies B. Gantt chart C. project plan D. critical path

4. The coding supervisor performs a monthly audit of coding quality. Is this a project?

A. Yes B. No

5. Differentiate between integrated and interfaced.

A. Integrated systems are designed to work together, and interfaced systems must be linked. B. Interfaced systems are designed to work together, and integrated systems must be linked. C. Integrated systems are designed to be embedded in your hospital information system, and

interfaced systems are part of your hospital information system. D. Interfaced systems are designed to be embedded in your hospital information system, and

integrated systems are part of your hospital information system.

System Analysis

System Development Life Cycle

Abdelhak (2007, 306) defines the system development life cycle (SDLC) as the “process used to identify, investigate, design, select, and implement information systems.” Generally the SDLC (illustrated in figure 5.4) has five steps:

Initiation•

Analysis•

Design•

Implementation•

Maintenance/evaluation (LaTour and Eichenwald Maki 2006)•

Benefits of the SDLC

The SDLC is an important part of the system selection process because it helps you under- stand your organization and its needs. The SDLC is a structured process that can be use- ful by identifying users’ needs and alternatives, selecting the information system, system

AB103409_ch05.indd 117AB103409_ch05.indd 117 2/1/10 1:20:39 PM2/1/10 1:20:39 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

118 Chapter 5

implementation, and other steps in managing information systems. SDLC requires the involvement of people throughout the organization including those who use the system (Johns 2006). The use of people throughout the organization who are impacted by the orga- nization ensures that the needs of all of the users and the organization are met.

SDLC Process

The SDLC is an ongoing process as demonstrated by the circular nature of Figure 5.4. There are a number of models used to describe the SDLC. Each of the four stages in the model used in this book is described below.

Initiation Initiation is where the facility decides to acquire a specific information system (Abdelhak et al. 2007). This decision may come about because of an information system strategic plan, the obsolescence of an existing system, or some other reason. In analysis, the facility deter- mines what users need from the proposed system. This stage reviews the current processes of the facility, the proposed processes, and the desired functional requirements. Func- tional requirements describe “what, not how, nor to what degree of accuracy, nor to what format” (Mikulski 1993). The design phase determines how the system will be selected or developed. It includes the specific design of a system to be developed by the facility or how the facility will identify the system for purchase. The implementation phase begins with the signing of the contract and ends when the system is operational. Some of the steps in this stage are installation of hardware or software, training, testing, and change manage- ment. The final stage is maintenance/evaluation of where the system is used, updated, and evaluated. The facility needs to know if the system meets the goals established for it and to conduct the day-to-day operations to keep the system up and running. This is a cyclical process; once the system no longer meets the needs of the users, the process begins again (LaTour and Eichenwald Maki 2006).

Systems Analysis Systems analysis is “the process of collecting, organizing, and evaluating data about IS requirements and the environment in which the system will operate” (Austin and Boxer- man 2003). Systems analysis is generally the first step in the SDLC after the decision to implement the system has been made. It helps determine the needs for data, storage, reporting, and functionality. To identify the needs of the facility, the team would look at the

Maintenance/ Evaluation

Implementation

Initiation

Analysis

Design

Figure 5.4. System development life cycle (SDLC) diagram

AB103409_ch05.indd 118AB103409_ch05.indd 118 2/1/10 1:20:39 PM2/1/10 1:20:39 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

System Selection and Implementation 119

existing systems and the needs of the users, and identify and evaluate alternatives. During systems analysis, users are asked questions such as:

What do you like about the current system?•

What problems do you have with the current system?•

What changes do you foresee that will impact this system?•

What information do you need from the system?•

Answering these questions helps the project team understand the current system and how it meets or does not meet the needs of the users. A system will be used by the facility for a long time and therefore must be adequate both at the time of go-live and in the foreseeable future.

To identify the needs of the facility for the foreseeable future, the team needs to under- stand the environment in which the system will operate. No one can see into the future with certainty, but internal and external environmental scanning can identify some issues that must be addressed. Internal scanning is identifying changes within the facility that will impact the information system. External scanning is identifying changes outside of the facility that will impact the information system. For example, if a facility was developing a new system that contained protected health information in 2002, it would have to ensure that the system would meet the strict Health Insurance Portability and Accountability Act (HIPAA) privacy rule that was implemented in April 2003. The facility may be aware of other pending legislation, trends, or other issues that may impact the system under consideration. Understanding the environment helps ensure that the system will work today and for the expected future.

Questionnaires, interviews, observations, flowcharts, and other data collection tools may be used to obtain the data needed to answer these questions (Austin and Boxerman 2003). The team should collect data from all levels and types of users. The needs of the clerical staff will be very different from the needs of management staff. Many managers think they know the needs of their staff, but many of these managers know what the policy states, not what is actually happening. The information gathered should include all aspects of the system such as data elements, reports, privacy, security, and overall functionality.

Questionnaires allow for a large number of users to provide input about the needs of the system (Austin and Boxerman 2003). This is especially true if closed-ended questions are used so that the responses can be tabulated quickly and easily. Closed-ended questions can be answered with yes or no, Likert type scales, and other limited choice responses. Likert type scales are great for obtaining the users’ beliefs regarding a statement. An example of a Likert scale begins with a statement such as: “On a scale of 1 to 5 with 1 being strongly agree and 5 being strongly disagree, rate the following statement.” An example of a belief could be “The new EHR will improve the efficiency of the facility.” An example of a typical closed- ended question could be, “Do you generate reports as a part of your job?” Obviously, the response to this question is limited to yes or no. Computerized tools such as Survey Mon- key and even machine-readable Scantron forms make the aggregation and analysis of the responses quicker. The downside of questionnaires is that the correct questions may not be asked, so there may be gaps in the data collected. The use of open-ended questions may help fill some of these gaps, but they slow down the aggregation of data and data analysis (Austin and Boxerman 2003). Open-ended questions allow the participants to expand on their response; however, the team must collect, read, and analyze each statement individu- ally. An example of an open-ended question is: “How does the current information system help you in your job?”

Interviews are powerful tools for obtaining information. There are three types of inter- views: structured, unstructured, and semi-structured. In the structured interview, everyone is asked the same questions. This improves analysis of the findings, but does not encourage the interviewee to talk openly about pertinent issues, thus taking the risk that important data will be overlooked. In the unstructured interview, the interviewer does not have a list of questions but rather gets the interviewee talking about their job, their data needs, and other issues related to the information system. The semi-structured interview is a combination of

AB103409_ch05.indd 119AB103409_ch05.indd 119 2/1/10 1:20:39 PM2/1/10 1:20:39 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

120 Chapter 5

the structured and unstructured formats. There are questions that interviewees are asked, but they are also encouraged to discuss in detail their job, data needs, and other issues related to their information system needs. The unstructured and semi-structured formats make it harder to identify trends and to analyze data, but major issues that could have been overlooked otherwise may be identified.

Typically, two members of the team are needed to conduct interviews because one per- son interacts with the interviewee and the other person takes notes (Abdelhak et al. 2007). Because of the increased staffing needs, the amount of time required to collect and analyze the data, and the need to meet with users individually, interviews are very time-consuming, which makes them costly. This means that the planning team may interview fewer indi- viduals than those who may respond to a questionnaire.

Observation is watching an action being performed. It is useful in determining what employees are actually doing. This is important because frequently supervisors or others may tell the interviewers what they think is happening but in reality something very dif- ferent is occurring. The use of observation is a way to validate what the interviewee has been told. If using observations, each observation session should be short—maybe 30 to 40 minutes—because the observer becomes bored and misses details (Abdelhak et al. 2007). Also, observation sessions should be scheduled throughout the day because differ- ent tasks may be performed at different times.

Flowcharts may be used to “provide a concise, logical, and standardized mechanism for depicting and analyzing current information flows” (Austin and Boxerman 2003) (see figure 5.5). The flowchart frequently uses geographic symbols to demonstrate the steps performed (McWay 2008). Problems and inconsistencies may be identified through the development and analysis of the flowchart. The process on the flowchart would depend on the type of system being developed but could represent the flow of the medical record in the HIM department, the flow of a physician query, or the steps in denial management. The flowchart would identify critical points in the process as well as problem areas. This

Move chart from magnetic disk to long-term storage

media

Complete chart processing

Code chart Quality indicator

monitoring Analyze chart

Scan chart

Charts are picked up from unit

Figure 5.5. Sample flowchart

AB103409_ch05.indd 120AB103409_ch05.indd 120 2/1/10 1:20:39 PM2/1/10 1:20:39 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

System Selection and Implementation 121

information can be used to improve new processes implemented along with the new infor- mation system.

Many facilities use a combination of questionnaires, interviews, observations, and other data collection tools to obtain the best information. The use of multiple tools also allows the team to involve more users and at the same time obtain detailed, validated information. The large number of participants helps to foster buy-in from the users. Buy- in refers to the acceptance of the system and recognizing its value to the user and to the facility. Users who buy-in to the system are supportive and less likely to resist using the system into their job role.

System analysis is a “process of studying organizational operations and determining information systems requirements for a given application” (Glandon et al. 2008, 75). It is frequently ignored or given only minimal attention during the system implementation pro- cess. This is a mistake. System analysis is critical because it forces the facility to evaluate itself and to look at how it does business. This understanding will help select the system that will best meet the needs of the facility.

Design In the design phase, the standards upon which the system will be evaluated and selected are identified (Abdelhak et al. 2007). This includes functionality, purchase vs. develop vs. ASP, and other attributes desired in the IS. This will be further described in the system selection section of this chapter.

Implementation This stage of the SDLC addresses the steps required to implement the IS. This includes a comprehensive plan for the implementation process. (LaTour and Eichenwald Maki 2007). This will be discussed in the implementation section of this chapter.

Maintenance and Evaluation The maintenance and evaluation stage addresses the day-to-day operations of the IS after implementation. The system should be evaluated on an ongoing basis in order to ensure that the IS continues to meet the needs of the organization (LaTour and Eichenwald Maki 2007). This is discussed further in the implementation section of this chapter.

System Selection

Most facilities today decide to purchase a system from an IS vendor. The vendor has invested millions of dollars in research and development and has a support system to assist the facility in the implementation of the IS being purchased. The facility must identify what they demand from an IS. This information is used to determine which system best meets the needs of the organization.

Request for Information

The request for information (RFI) is a formal document requesting information on infor- mation systems. The RFI asks the information system vendor for basic information about the product and how their information system would meet the requirements outlined in the RFI (Abdelhak et al. 2007). The RFI can be used to select minor information systems, or the information gathered in the RFI can be used to determine who will receive the more rigorous request for proposal (RFP), which “details all required system functionality, including func- tional, technical, training, and implementation requirements” (Abdelhak et al. 2007, 343).

Request for Proposal

The RFP is a much more detailed document than the RFI and is critical to the selection process. The purpose of the RFP is to give the vendor all the information needed to propose an information system that meets the needs of the facility. The RFP describes what system

AB103409_ch05.indd 121AB103409_ch05.indd 121 2/1/10 1:20:40 PM2/1/10 1:20:40 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

122 Chapter 5

is needed, how many people will be using the system, and how the system will be used. Common components of the RFP are:

Letter of introduction•

Information for potential vendors, including:•

Information about bidders’ conference —

Description of facility —

Patient (or other) volume statistics —

Description of the proposed system, including:•

Technology requirements —

Functional requirements —

Required format of response —

Instructions for RFP•

Request for sample documentation•

Request for sample contract•

Vendor profile•

System testing requirements•

Sample résumés of implementation staff•

System selection criteria•

Training requirements•

References•

Appendix B shows a detailed template for an RFP (AHIMA 2007).

Letter of Introduction The letter of introduction is a cover letter that is sent to the vendor along with the RFP. The letter introduces the vendor to the RFP, and identifies who the vendor should contact at the facility. It may also provide some information that did not make it into the RFP. The infor- mation on the bidders’ conference gives the date, time, location, and other information.

The bidders’ conference is a meeting for vendors to come to the healthcare facility to ask questions about the RFP, the facility, and more. This meeting enables all of the potential vendors to hear the same information and to get all of their questions answered so that they can completely respond to the RFP.

Information for Potential Vendors The description of the facility section provides the vendor with enough information about the facility to enable the vendor to properly respond to the RFP. This information includes the size of facility, number of employees, number of employees who would use the system, and number of locations that would use the system (Austin and Boxerman 2003). This sec- tion also should describe the facility’s existing systems so the vendor can respond as to how they can work with the existing system.

It should also include patient (or other) volume statistics that would be related to the system (see table 5.1). The statistics may include number of discharges, number of surger- ies, number of emergency department visits, and the number of outpatient visits—whatever is needed for the proposed system (Abdelhak et al. 2007).

Description of the Proposed System In the proposed system section, the vendor describes the system that it is proposing to meet the needs of the facility. The vendor should describe the infrastructure required, licensing, the capabilities of system, the benefits that would be realized, and more.

AB103409_ch05.indd 122AB103409_ch05.indd 122 2/1/10 1:20:40 PM2/1/10 1:20:40 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

System Selection and Implementation 123

The functional requirements identify the desired functions of the IS, which makes this a significant part of the RFP. This document is developed during the system analysis pro- cess and outlines all of the functions expected of the system. The functions should include all aspects of the information, including but not limited to, individual data elements, data entry methods, reporting, management of the system, functionality, and technical issues. Technical issues can include topics such as the type of database used and the ability to work with a certain operating system or interface with existing products.

Each functional requirement is listed. The vendor indicates whether the function is available, is available with customization, will be available in the future, or is not available (Hebda et al. 2005). The facility will take this same list of functional requirements and use it to evaluate the RFP. There are at least two ways to classify each functional requirement. The first is that each functional requirement should be designated at least as mandatory or desirable (Austin and Boxerman 2003). Some RFPs use three categories: mandatory, desir- able, and luxury. Each functional requirement is categorized into one of the designations. A numeric rating system can be used as well; in other words, “scoring” each func- tion based on its importance. For example, each function is rated on a scale of 1 to 5, 1 = unimportant, 5 = highly important. The functional requirements with the available, not available, and other categories are part of the RFP, but the version with the evaluation ratings is not. The functional requirements are used in the system evaluation to determine if a vendor has all of the functionality, and also to determine if the missing functionality is important. For example, if there is a functional requirement to combine duplicate medical record numbers, and it is missing from one of the products under review, the rating would help the reviewer determine whether this is a serious gap.

Other RFP Requirements The required format of response tells the vendor what the facility requires regarding the RFP. For instance, the facility might require a specified number of paper copies and an electronic copy in Microsoft Word or Portable Document Format (PDF). The facility may also limit the number of pages, or the look of the document. The facility may even provide an electronic template for the vendor to complete. The instructions for RFP may include rules regarding whom the vendor can talk to at the facility, the deadline for submission, and a statement that the vendor assumes responsibilities for the expenses to complete the RFP as well as the expenses for any on-site demonstrations, along with expenses for RFP preparation.

The request for sample documentation and request for sample contract is simply that— a request for a copy of the documents. The vendor profile is a description of the vendor

Table 5.1. Sample of requested volume

Imaging System Statistics Facility Findings Number

Average number of discharges per day 45

Average number of emergency department visits per day 60

Average number of outpatient surgeries per day 25

Average number of outpatient visits per day 125

Average number of pages—inpatient discharge 100

Average number of pages per emergency department visit 12

Average number of pages per outpatient surgery record 40

Average number of pages for each outpatient visit 2

Average number of release of information requests per day 21

Average number of pages copied for release of information/day 475

Number of forms utilized in medical record 325

Number of forms already having barcodes 200

Percentage of medical record to be entered into the imaging system via COLD technology 40%

Projected number of change in workload over the next 5 years 10%

AB103409_ch05.indd 123AB103409_ch05.indd 123 2/1/10 1:20:40 PM2/1/10 1:20:40 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

124 Chapter 5

and is designed to ensure that the company is financially sound and capable of meeting the needs of the facility for years to come (Abdelhak et al. 2007). The RFP asks for informa- tion on the number of installations of similar systems the vendor has performed, financial viability of vendor, and the number of years the product has been available.

System testing requirements would outline the expectations the facility has regarding testing. The RFP would provide the types of testing to be performed and the role of the vendor in that testing.

Many facilities request sample résumés from the vendor’s staff, which provide details of the experience and qualifications of the staff who could be assigned as consultants to that particular project. These sample résumés are used to ensure the vendor has experienced staff members who can support the facility throughout an implementation. It is not a guar- antee that any of the individuals represented would be assigned to the project, but rather a sample of the experience that the vendor’s employees have.

The system selection criteria are used to select the system. This would include major steps such as findings of the demonstration, findings of site visits, review of the RFP, costs, expected benefits, and reliability of vendor’s products. It would not include rankings of importance and other details that the project team will utilize to make the final decisions.

Finally, the RFP should request the training requirements for the system, including the number of people trained by the vendor, cost of training, the estimated time it should take to train each user, types of training required, and other recommendations regarding the training process.

Check Your Understanding 5.2

1. I am configuring settings. This falls into what stage of the system development life cycle?

A. Analysis B. Design C. Implementation D. Maintenance/evaluation

2. I am collecting data as part of the system analysis function. If I want to get the most system users involved as possible, which would be the BEST method of data collection?

A. Observation B. Questionnaires C. Interviews D. Flowchart

3. I have asked a vendor for detailed written information on their product. This would be:

A. RFI B. RFP C. flowchart D. vendor profile

4. I am calling six hospitals that use XYZ’s EHR. This is an example of:

A. reference check B. site visit C. demonstration D. RFP review

5. What problems do you encounter with the existing hospital information system? Is this an open or closed question?

A. Open B. Closed

AB103409_ch05.indd 124AB103409_ch05.indd 124 2/1/10 1:20:40 PM2/1/10 1:20:40 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

System Selection and Implementation 125

Evaluation of Proposed Systems

The evaluation process used to select a system should be established during the planning process. The process should include multiple components including:

On-site demonstrations•

Site visits•

Review of RFP•

Reference checks•

On-Site Demonstrations In an on-site demonstration, the vendor brings its product to the healthcare facility, either as a demonstration version or a full version of the product. Project team members and other users gather to view the product and to ask questions of the sales team. The idea is to have as many people as possible watch the demonstration to see what the product can and can- not do. All attendees should come to the demonstration with situations they encounter in their daily tasks and ask how the system would handle it. The on-site demonstration allows for multiple user involvement and is an important method to learn about the product. This may be the only chance for some team members or other users to see the system before implementation; not everyone can go to site visits to see the system in a live environment (Abdelhak et al. 2007).

Site Visits Site visits are a great way to view the products in a live environment. A site visit usually consists of a small group of team members (usually key players) visiting a facility, pref- erably similar in size and characteristics, which has the product implemented, to observe the system in use. During the visit, the team asks questions of the site visit facility’s staff involved in the system. The salesperson for the product will attend the site visit as well to answer questions and ensure that the project team obtains the information needed to make a decision. It is recommended that the project team ask the vendor’s staff to step outside the room for a few minutes. The philosophy behind this is that the facility staff may be more open about problems with the system if the vendor is not in the room. See- ing the system operating in a real environment is quite different from a demonstration environment and thus gives the project team a much more realistic view of the system and how it works.

Reviewing RFP Responses The vendor spends a lot of time responding to an RFP, so the RFP should only be sent to the vendors who are seriously being considered (Abdelhak et al. 2007). It is also very expen- sive (Wager et al. 2005). The number of RFPs submitted is typically limited to three to five vendors. The healthcare facility also spends hours reviewing the RFP responses because for major information systems purchases, the responses could fill a 3- or 4-inch binder. A spreadsheet is frequently developed to assist in the analysis of the RFPs, and this enables the decision makers to compare key information between products more easily when mak- ing their decision.

Some of the information that could be included in the spreadsheet includes:

Cost•

Compatibility with existing system•

Level to which the system meets functional requirements•

Reaction to site visits•

A sample comparison is shown in table 5.2.

AB103409_ch05.indd 125AB103409_ch05.indd 125 2/1/10 1:20:40 PM2/1/10 1:20:40 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

126 Chapter 5

Reference Checks The facility should contact several facilities where the product under consideration is in use. These reference checks are a great way to learn if other facilities are satisfied with the product without the expense and time it takes to go on site visits. The vendor will provide a list of references, and the evaluating facility should try to obtain a complete list of client sites from the vendor or independently identify client facilities that are not on the reference list (Amtayakul 2007). Best practices recommend that the evaluating project team contact facilities from the vendor’s reference list, as well as facilities that are clients of the vendor but are not included on the reference list. The reference list may only contain customers who are satisfied with the product and leave off the unsatisfied ones. Facilities not on the list may be identified through the corporate offices, network- ing, or cold calls. Notes from these reference checks should be collected and used as part of the decision-making process.

Making the Decision

It is the responsibility of the project team to review the responses to the RFP and other evalu- ation tools to determine which system will best meet the needs of the facility. To prevent arguments over which system to choose, there should be a quantifiable means of evaluat- ing the systems. One way is to assign points to the RFP review, site visits, observations, and other evaluation methods. If a point system is used during the evaluation process, then the system with the highest number of points should theoretically be the best system and therefore the one that is chosen. However, this is not always the case, because a vendor may have the overall highest score but have low scores in key functions; not only should the total points be used, but each individual task should also be considered. A weighted system is one method of a point system that can be used (see table 5.3) (Abdelhak et al. 2007). With the weighted system each function would be listed along with a score showing how important the functionality is. The project team would give each function a score and the score would be multiplied by the weight. The weighted scores would then be totaled. There should also be a tiebreaking process, just in case. Examples of tiebreakers could be cost, site visit findings, or other evaluation criteria. As an example of the importance of a complete evaluation system, one corporate entity had all of their HIM directors critique an information system and vote on

Table 5.2. Sample of comparisons between vendors responding to RFP

Comparison of Vendor Systems

System Capabilities System A System B System C

Works with existing

hospital information

system

Yes Yes Yes

One-time costs $654,000 $498,500 $576,000

Ongoing costs (3 years) $65,000 $89,000 $79,000

Hardware needed File server, PCs

throughout facility,

barcode scanners, and

printers

File server, PCs

throughout facility,

barcode scanners, and

printers

File server, PCs

throughout facility,

barcode scanners, and

printers

Works with existing

database

Yes Yes Yes

Number of years vendor

in existence

31 12 6

Number of installations 123 26 2

RFP shows financial

viability

Yes Yes Yes

AB103409_ch05.indd 126AB103409_ch05.indd 126 2/1/10 1:20:40 PM2/1/10 1:20:40 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

System Selection and Implementation 127

the one they wanted. There was a tie and none of the directors would change their vote. The project was cancelled because of the inability to select a system.

In the weighted score example, system B has the highest score and does beat system A in every criteria except one. The one function where it is lower is “EHR can easily access knowledge-based resources on the Internet,” where its score is substantially lower than that of System B. The weight of this function is higher than the other functions so decision makers would have to determine what is more important, a higher score or the ability for providers to access knowledge-based materials quickly and easily.

Contract Negotiation

Once the decision on which system to purchase has been made, the contract negotiation process begins. Some hospitals start negotiations with more than one vendor. Based on the initial meetings, the facility chooses one vendor to continue on with negotiations. Typi- cally, a contact team, not the project team, negotiates the contract. The negotiating team should include at least the CIO and an attorney; however, with a minor implementation, the HIM director may work with a member of administration. A minor system might be a chart location system that is used only by the HIM department and is quickly and easily implemented and has a simple contract. A major implementation would involve multiple areas of the healthcare facility, a significant period of time to implement, and a complex contract. The goal of the contract negotiations is a win-win situation. Obviously, the health- care facility wants a good product at a reasonable cost that is implemented in a reasonable time period. The facility should not try to secure the product under such strict requirements that the relationship with the vendor is negatively impacted from the beginning. With many of these installations, the facility will be working with the vendor for 10 years or longer; therefore, it is in the facility’s best interest to create a good working relationship. The facil- ity should not accept the sample contract provided by the vendor because this contract is written in favor of the vendor. The negotiation team is responsible for working with the vendor to develop a contract that works for both parties.

Some of the clauses covered by the contract include:

Delivery dates•

Licensee grant•

Warranties and guarantees•

Table 5.3. Sample weighted scores for system selection

Weighted Scores for System Selection

Functionality Weight Vendor A

Score Vendor B

Score

Vendor A Weighted

Score

Vendor B Weighted

Score

System is user friendly 3 4 6 12 18

EHR can easily access

knowledge-based

resources on the

Internet

3 10 6 30 18

EHR allows patient to

view PHR information

2 4 6 8 12

EHR allows patient to

enter PHR information

1 2 5 2 5

Total 52 53

AB103409_ch05.indd 127AB103409_ch05.indd 127 2/1/10 1:20:40 PM2/1/10 1:20:40 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

128 Chapter 5

Responsibilities of each party•

The state whose laws govern the contract•

Cost•

Milestones for payment•

Force majeure•

Software in escrow•

Version of software•

Penalties•

Cancellation of contract•

Acceptance testing•

Maintenance and updates•

Training•

Documentation (Austin and Boxerman 2003)•

A licensee grant is the section of the contract that controls what the healthcare organi- zation can do with the software. It controls the locations that can use it, who can use it, and how it can be used (AHIMA 2006).

Delivery dates are the dates that the software and hardware will be delivered to the healthcare facility. The inclusion of these dates in the contract is important because noth- ing can be done until the software is available and installed at the facility. Warranties and guarantees are affirmations the vendor makes that if broken, they can be held accountable. Samples of warranties are:

Vendor has the legal right to sell software.•

If it is found that the vendor does not have the right to sell the software, then the • vendor is legally responsible.

Information systems will be available 99.9 percent of the time.•

Information systems will perform query within 3 seconds.•

Response time for technical support.•

Contract law varies by state; therefore, the contract must specify which state’s laws cover the terms of the contract. The vendor generally asks for the laws of their state and the hospital asks for their state, so negotiation is required.

It is important to detail the responsibility of each party in the contract (see table 5.4). This helps ensure that no problems will arise later over whom is responsible for what. This information will be used in the negotiation of the price. Obviously, the more participatory a vendor is during implementation, the more the vendor should be paid.

The cost of the system is one of the last clauses negotiated. The amount of money paid to the vendor will be based on the responsibilities of the vendor, the number of users specified in the contract, and other clauses. The facility should require a fixed price so they know exactly what the cost of the system will be. Healthcare facilities should never pay the entire negotiated amount or a large percentage of the cost up front. The contract should establish payment milestones (see table 5.5) (Mikulski 1993). A payment mile- stone is an action that once occurring triggers payment to the vendor. This payment is a specified percent of the total cost of the system. This must be negotiated and spelled out in the control. Typical milestones include delivery of software, go-live, and acceptance

AB103409_ch05.indd 128AB103409_ch05.indd 128 2/1/10 1:20:40 PM2/1/10 1:20:40 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

System Selection and Implementation 129

testing. A significant percentage of the payment should be held until acceptance testing is complete. Failure to do so could result in the vendor moving to the next installation and not responding in a timely manner to any outstanding issues. If there is a significant amount of money involved, the vendor is more likely to be responsive to the needs of the facility.

Force majeure is a legal term that refers to an “act of God” (Merriam-Webster 2009). This contract clause is designed so that the parties of the contract cannot be held accountable to a deadline if there was an “act of God” that prevented compliance. For example, say there was a hospital in New Orleans implementing a computer system and the vendor was responsible for a task due in the middle of Hurricane Katrina. In this case, the vendor would not be held accountable for any penalties as specified in the contract.

Healthcare facilities have the need to protect themselves in the event the vendor goes bankrupt. One way of doing this is to place a clause in the contract that requires the vendor to place the source code in escrow (Dolan 2006). Source code is the programming code that was used to develop the system. Escrow is a situation in which a third party holds a copy of the software in case the vendor goes bankrupt (AHIMA 2006). This means that if the vendor goes out of business, the healthcare facility can obtain access to the code behind the software so they can maintain the system themselves or hire someone else to do so. Both parties prefer to use escrow rather than obtaining access up front. The vendor prefers this method as well because it does not want its trade secrets to be widely available.

Cancellation of the contract becomes important if for some reason the product or ven- dor does not meet the needs of the facility. This clause allows the vendor or healthcare facility to void the contract with appropriate notice. There should also be a period of time in which the contract is in force unless cancelled earlier by either party. This clause may require a 30- or 60-day notice to the other party in the event of a cancellation (Austin and Boxerman 2003).

The version of software that will be delivered to the facility should be specified in the contract. The vendor will know when the next version is scheduled for release. Depending on the time frame of implementation, the facility may receive the current version or the new

Table 5.4. Sample allocation of responsibility list

Task Responsible Party

Train the trainer Vendor

Train end users Facility

Develop interfaces Facility and vendor

Design screens Facility

Testing Facility and vendor

Table 5.5. Sample milestones for payment

Milestones for Payment

Milestone Percent of Vendor’s Payment

Signing of contract 20 percent

Delivery of software 10 percent

Commencement of testing 10 percent

Go-live 30 percent

Completion of acceptance testing 30 percent

AB103409_ch05.indd 129AB103409_ch05.indd 129 2/1/10 1:20:40 PM2/1/10 1:20:40 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

130 Chapter 5

version. The contract may also state that the facility will install the current version but will receive the upgrade to the new system as part of the contract or at a reduced cost (Austin and Boxerman 2003).

The contract should specify penalties for both the vendor and the facility for failure to meet the dates specified in the contract. Penalties vary widely and can be monetary or in the form of free training, free software modules, or other forms. The penalties should be serious enough to keep the parties on target, but not so punitive they would seriously risk the financial stability of the facilities. One facility had negotiated such a tight time frame with major penalties that the information systems department essentially did not do anything other than implement the new system and keep the current systems operational for an entire year. If departments needed assistance with the information system, they were told to hire someone to do it for them. Placing this amount of pressure on the vendor or the project team is not the purpose behind the penalties in the contract. The purpose is to keep everyone on task and on target.

Acceptance testing is a critical part of the information system implementation because it establishes whether the terms of the contract have been met regarding performance and functionality. The contract must spell out what outcomes are acceptable. These outcomes will be used to determine when the acceptance testing is complete and the vendor can receive payment (Austin and Boxerman 2003).

Information systems are constantly changing. Maintenance must be an ongoing respon- sibility for both the vendor and the facility. The contract should spell out the responsibili- ties of both parties. The contract should also specify if upgrades to the information system are included in the contract and the costs for those upgrades. These upgrades will assist the facility in remaining compliant with accreditation, regulations, and other mandates. The system updates also repairs any problems found in the system and keeps the system operational (Austin and Boxerman 2003).

Training responsibilities of the vendor, including issues such as the number of people to be trained, where they will be trained, the cost of the training, and the length of the train- ing, should be spelled out in the contract (Austin and Boxerman 2003).

The contract should include the type of documentation provided by the vendor to the facility. This documentation generally includes technical manuals for technical support as well as user manuals (Austin and Boxerman 2003).

System Design

As discussed earlier in the chapter, a decision will be made during the planning phase in which a facility will purchase a system, use an ASP, or design a system. The requirements identified in the system analysis phase are used to create specifications for the system. The specifications will be used for programming the system in-house or for evaluating vendor systems. If the facility is designing its own system, the facility could create a formal system design or use a prototype. Creating a prototype is a way to quickly design and develop a system (Abdelhak et al. 2007). With prototyping, programmers quickly develop a system, show it to the users, obtain feedback, make revisions to the program, and continue until the system is developed. Although this is an option for system design, most system designs are much more formal and detailed.

The design should include system objectives, output specifications, input specifica- tions, database design, and expected costs of the system. The objectives are the goals the facility wants to achieve with the implementation of the system. The output specification would be reports and screens to be produced in detail. Input specifications identify the data needed to accomplish the goals and produce the outputs. The design should specify what data are collected, from where the data will originate, and in what format the data should be stored. The design should specify the size of the database and amount of activity expected. Once the specifications are developed, administration must approve them before proceed- ing with the project (Abdelhak 2007).

AB103409_ch05.indd 130AB103409_ch05.indd 130 2/1/10 1:20:40 PM2/1/10 1:20:40 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

System Selection and Implementation 131

Check Your Understanding 5.3

1. Our new system is operated on a computer that is physically located at a remote location for our facility. We pay a monthly fee to the company that owns the computer and in return they manage our system for us. This is:

A. vendor product B. ASP C. facility developed product D. site visits

2. The vendor will be paid 20 percent of the negotiated amount of the contract at the time of the contract signing. This is an example of:

A. warranty B. force majeure C. escrow D. payment milestone

3. Evaluate this statement: A hospital should be tough in contract negotiating and insist on obtaining the software code.

A. This is a true statement. B. This statement is true only if there is staff to make changes. C. This statement is not true. The hospital does not need or want access to the code. D. The hospital would be best served by escrow.

4. True or False: In a point-based evaluation system, the information system selected should always have the highest score.

5. True or False: System design must be more detailed for evaluation of software for purchase than for an in-house developed product.

System Implementation

There are many tasks involved in system implementation. Some of these steps can be com- pleted concurrently, whereas others must have one or more of the previous steps completed before proceeding. If any of these tasks are omitted or given little attention, the project will fail. The plan should implement the information system in such a way as to have the least impact on the facility. For example, the new system can be implemented at midnight when the activity in the hospital is low.

Hardware/Software

Because it may take a long time to receive hardware (that is, computers, monitors, and servers), staff needs to plan accordingly and place the order early. The most critical piece of hardware is the file server or other computer storage component that will house the applica- tion software. System implementation may be delayed if the file server or other hardware is not available according to the project plan.

The application software will be provided to the healthcare facility by the computer vendor based on the date specified in the contract. The version of the software provided will also be controlled by the contract. If the vendor is late in sending the software for installation, the implementation of the system will be delayed.

Site Preparation

Site preparation is making any needed changes to the physical location where the com- puter, workstations, printers, or other hardware will be installed (Abdelhak et al. 2007). Site

AB103409_ch05.indd 131AB103409_ch05.indd 131 2/1/10 1:20:40 PM2/1/10 1:20:40 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

132 Chapter 5

preparation needs vary widely, from construction of a new building, to renovations of an old one, to use of existing structures and upgrades to the infrastructure. Modifications needed may require the installation of special air conditioning and/or floors designed to run cables under it, added security measures, or more electrical outlets to name a few. However, site preparation may be as simple as moving existing hardware around to make room for the new. The nursing units, the HIM department, and other locations may need to be renovated to add space for computer terminals, barcode printers, network printers, and other hardware, but the data center must be completed first because the nursing units and other departments will not use the system until go-live. In addition to the physical plant, the facility network may need to be updated to accommodate the extra traffic resulting from the new system.

Failure to properly prepare the site and infrastructure will result in delays in the instal- lation of hardware and software, which will in turn delay the entire implementation plan of the system. One facility learned this lesson when they attempted to plug in the hardware and did not have an available electrical outlet.

User Preparation

User preparation is providing the users with enough information about the system being implemented so that they are prepared both psychologically and through training to use the system. It is important for system users to be notified and updated throughout the system selection and implementation process. The users need to know that the system is being implemented and should have an accurate understanding of what to expect from the system and what is expected of them. Many people have doubts about their job security or fear computers when new systems are installed; therefore, these fears must be addressed. Management must be open and honest with the users regarding expectations, downsizing, changes in job descriptions, and other concerns. The information must be accurate; oth- erwise, users will lose trust in the manager’s word. Sometimes a new system is promoted so intently that users expect more from the system than it can provide. These unrealistic expectations lead to disappointment and, in turn, a lack of support from the users. There should be as many users involved in the system as possible to obtain their support. Their involvement can be through the system analysis function, being part of the implementation team, assisting in testing, and other ways. Even those users not involved in the selection and implementation need to have realistic expectations. Their expectations can be managed through training, articles in the facility newsletter, updates at department meetings, and other formal and informal means of communication (Abdelhak et al. 2007).

Installing Hardware/Software

Once the hardware arrives, it will need to be set up and installed in the data center. Com- puters will also need to be installed in the nursing units, training rooms, and all locations decided upon according to the project plan. The printers, network, scanners, and all of the other hardware will also need to be installed according to the project plan.

The software will then need to be loaded onto the file server, mainframe, or other com- puter in the data center. Some applications require software to be used on the individual user computers. If this is the case, the software has to be loaded on to each individual com- puter to be used in development and testing. The software on the user computers will have to be installed on all authorized computers prior to implementation. Any failures in the site preparation will be identified in this stage.

Setting Configuration

Most computer software purchased by hospitals or other healthcare facilities provides the facility with at least some flexibility in the implementation of the system. This flexibility is allowed through setting configuration. Setting configuration is the entry of the desired behaviors of the system into tables or setting fields. For example, if the computer system will keep track of the patient type, the hospital gets to determine if patients will be classi-

AB103409_ch05.indd 132AB103409_ch05.indd 132 2/1/10 1:20:41 PM2/1/10 1:20:41 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

System Selection and Implementation 133

fied as inpatient, outpatient, emergency department, testing, outpatient surgery, or another patient type. The facility may even be able to determine that an “I” means inpatient.

The project team sets up the specifications by filling in tables and other fields with the desired setup. They will also be able to update tables that provide their reimbursement rates, tax identification number, national provider identifier, or other appropriate values. Other settings may include time frame before bills drop, data/format of claims submitted to fiscal intermediary, and what fields are required. The settings will ensure that the system works according to the needs of the healthcare facility.

It can take minutes or months to get all the specifications and tables updated, depending on the complexity of the specifications and the system. For example, each user’s information must be entered into the system, including their username, initial password, location, type of access, and permissions as to what they can perform within the system. For example, Mary Smith may have access to the laboratory results, but she can only view these results—not delete or modify them. Determining who has access to what and what they can do with it, especially if the sys- tem’s security controls screens and individual data elements, is a time-consuming task.

Programming and Customization

There may or may not be programming required depending on the type of system, complex- ity of the system, and whether the facility is purchasing a system or programming one them- selves. If the system interfaces with other systems to share information such as demographic or other information, the interfaces will have to be programmed. If the facility is converting data from another computer system, programming will have to be done to perform data conversion. Data conversion is the process where data is copied from the existing system, manipulated into the format required by the new system, and entered into the new system.

The facility may want to have some changes made to the software to better meet the needs of the facility. This customization of the system can be completed by either the facil- ity or the vendor. Although customization may better prepare the system to meet the needs of the facility, there are reasons why the facility should not customize the software beyond what is already built into the system by the vendor. Some of these reasons are:

If the facility makes changes to the software and then has trouble with the system, • the vendor can blame the modifications. The vendor may then refuse to work on the system.

The vendor may not give the facility a service agreement.•

Every time that the facility receives a software update from the computer vendor, • the information system staff will have to check the modifications to see if they are affected by the new update. Because the facility may receive several updates a year, this can be an onerous task (Rollins 2006).

Screen Design

The information system may allow the facility to make changes to the computer screen so that it works the best for the facility. Screen design is developing screens of an informa- tion system to meet the needs of the user and to promote job efficiency. To accomplish this goal, team members involved in this process must be aware of the needs of the users and the work they perform. Reasons why the facility may want to change the computer screen include:

No single screen contains the data needed to make data entry or viewing efficient.•

The vendor’s screens do not have data elements in a logical order for the • workflow of the users.

The existing screens are too cluttered for the users’ preference.•

AB103409_ch05.indd 133AB103409_ch05.indd 133 2/1/10 1:20:41 PM2/1/10 1:20:41 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

134 Chapter 5

The screen design may include designing computer views for various types of users. This flexibility would allow nurses to see new orders, care plans, or other information first; the cardiologist and neurologist would have first access to cardiac and neurologic tests, respectively.

When designing screens, the fields should be in a logical flow to facilitate data entry. The flow of data entry should be from left to right and top to bottom. Screen design is very different from form design. Screens have about one-third of the view that a paper form has (Rhodes 1997). Screens, like paper, should have a title and/or a control number to manage the screen. Screens should be simple to use and have a standardized terminology across screens to facilitate data entry, training, and data quality. For example, the data element medical record number should be called that on all screens—not medical record number on one and patient identifier on another. Screens should also have the same look and feel so that the user can easily move from screen to screen. Instructions can be posted on the screen where necessary to assist users. Color, blinking, and reverse video can be used to draw the user’s attention to important data such as allergies. Special features such as color should be used sparingly so the user’s attention is drawn to the information displayed. The color of the screen and text should be pleasing to the eye and comfortable for users to view for long periods of time.

A graphical user interface (GUI) is a method of screen display that uses icons, menus, and other tools to assist in the use of the system (Hebda et al. 2005). These icons are shown on a toolbar. Icons provide shortcuts to functionality within the system, along with buttons and menus, allowing the user to command the software to perform specific tasks and pro- viding shortcuts to functionality within the system (Williams 2006). The most common and recognized GUI interface is the Windows GUI.

Report Design

Report design is the process of creating and formatting a report. This design includes the content of the report, the order of the data on the report, and any desired formatting specifi- cations. The system may come with standard reports, but most likely will not have all those needed by the facility. In addition, the reports provided will probably not be presented the way users want them to look. Because of this, the facility will need to design new reports and/or alter existing “canned” reports to make sure that users have all of the information routinely needed. This does not mean that the implementation team has to write every report the facility will ever need now. The report design discussed here is for the standard reports that users will need daily, weekly, monthly, quarterly, semiannually, or annually. Ad hoc reports, which are one-time reports, can be created as needed. Many information systems have a report writer built into them. Many allow data to be exported into various reporting systems such as Crystal Reports, Cognos, and Microsoft Access.

Typical characteristics of reports are report title, the date and time that the report was run, the time period that the data covers, the page number where appropriate, appropri- ate column headings, and data. These reports may be in a multitude of formats, some of which can be changed or manipulated and others that cannot. For example, a report may be generated in Microsoft Excel format, which would allow the user to sort data, run cal- culations, group, and perform other data manipulations. Other reports may be in Adobe Acrobat format, which is generally used for the display of data only. A sample report is shown in figure 5.6.

Interfaces

According to AHIMA (2010, 155), an interface is “the zone between different computer systems across which users want to pass information (for example, a computer program written to exchange information between systems or the graphic display of an applica- tion program designed to make the program easier to use).” Interfaces link two or more systems together, enabling them to share data such as demographics. In other words, an interface acts as a bridge between systems transporting and translating data into each

AB103409_ch05.indd 134AB103409_ch05.indd 134 2/1/10 1:20:41 PM2/1/10 1:20:41 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

System Selection and Implementation 135

system’s respective programmed language. Interfaces can be one-way or two-way. One- way interfaces send data from one system to another without any data returning. In a two-way or bidirectional interface, data is exchanged between systems regularly.

Writing interfaces is a difficult and time-consuming process because a program has to be written and maintained for sending and receiving data. Representatives from both computer vendors must be involved in the process. If one system has the insurance type Medicare stored as MED and the other system has it stored as MCR, this information must be converted. This conversion can be performed by an interface engine. An interface engine allows “two applications to exchange information without having to build a custom- ized interface for each application” (Abdelhak et al. 2007, 280). The interface engine has to convert the data so that it can be accepted by the system receiving the information. The interface must know where the insurance type is stored in the originating system, retrieve the data, convert the data, and then plug the converted data into the correct field in the new system. As a tool, the interface engine has made interfaces easier to work with, but there is still a lot of work to do. An interface engine is a type of middleware. Middleware is software and hardware that connects applications (Abdelhak et al. 2007). The interface engine does not eliminate the work necessary to transmit data between systems, but, rather, reduces it. If the interface engine goes down, no data can be transmitted, which can cause issues especially with patient care and the need for current information. Figure 5.7 illus- trates interface engine connectivity.

Figure 5.6. Sample report

Macon General Hospital Admission Register

March 31, 20XX

Encounter Number MR Number Patient Name Admit Date Admit Time Attending MD Bed

123456812 1123568 Benson, Mary 3/31/08 19:22 Scott, A 264

123456800 0568745 Johnson, Claude 3/31/08 13:26 Wilson, J 547

123456789 1234567 Smith, Amanda 3/31/08 01:23 Scott, A 246

123456806 0984562 Thomas, Frank 3/31/08 17:47 Jones, X 534

Number of admissions 4

Chart locator systemTranscription

Release of information system

Chart deficiency system

Interface engine

Hospital information system

Figure 5.7. Example of interface engine connectivity

AB103409_ch05.indd 135AB103409_ch05.indd 135 2/1/10 1:20:41 PM2/1/10 1:20:41 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

136 Chapter 5

Conversion

With most new information systems, a facility is converting from one system to another— even if the first system is paper. The facility cannot ignore the historical data but, rather, must bring some (if not all of it) to the new system. In a paper system, the historical data must be captured through abstracting, scanning, or other data entry methods. In an information system implementation, conversion is transferring data from one computer system to another while simultaneously making any necessary changes in format or content. A conversion is more difficult than it sounds because systems frequently store data very differently or the facility may be making changes to how it wants data to be collected. During conversion planning, the implementation team has to determine how much data is being converted and what data fields will need to be converted from one format to another. The amount of data transferred is a decision that must be made by the facility. The decision will be influenced by the type of system, laws and regulations, whether or not the old system will remain operational, and other issues. Sometimes facilities decide to transfer data from a specified time period only into the new system. For example, they may decide to convert only the last 2 years. Other conversions require all data be transferred. The facility may also choose to enter data for all time periods, but only selected data elements rather than all data collected.

Planning is critical to ensure the quality of data in the new system. Once the conversion planning is finished, a program needs to be written that will make the necessary changes. A formal testing plan is required to determine how the implementation team will test the conversion to work out any problems before go-live.

Reengineering Processes

Reengineering, also known as business process reengineering, is reevaluating the way the facility does business in order to improve efficiency. Reengineering is a task that is fre- quently overlooked in the efforts to implement the IS. Every task and every preconceived notion must be challenged. The question “why” should be asked over and over. There are no exemptions from being subjected to evaluation and change—everything is subject to change. This is challenging to employees who are comfortable with the status quo. Some of the tasks performed by the employees have been performed for years. The reason behind the task may be outdated, but the task continues because the employee is afraid to stop. At one facility, an employee received a report generated by the information system department every day. The report was filed away and never reviewed. When asked how the report was utilized, the employee stated that it was never reviewed. The employee balked at the idea of stopping the report—just in case it was ever needed. The implementation of a new informa- tion system is a perfect time to critique the tasks performed to try and improve efficiency, costs, and effectiveness (Abdelhak et al. 636).

The employees may feel threatened and afraid because of the changes impacting their job, but reengineering is a necessary part of the information system process. The facil- ity cannot implement a computer system and expect the work processes to remain the same. The facility will need to change procedures, update the policy and procedure manual, change workflow, eliminate unnecessary tasks, and add new tasks. Failure to do so can decrease efficiency rather than maximize on the benefits the system affords. The informa- tion system changes the way a facility conducts business and impacts the manual processes and workflow as well as their overall interaction with the computer. The documentation tested during the testing phase should contain the revised processes.

Policy and Procedure Development/Documentation

After the reengineering is completed, the policy and procedure manual must be updated to reflect the new way of doing business (Abdelhak et al. 2007). Policies and procedures should blend together the manual processes and decision-making processes. Management

AB103409_ch05.indd 136AB103409_ch05.indd 136 2/1/10 1:20:41 PM2/1/10 1:20:41 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

System Selection and Implementation 137

and maintenance of the system itself must also be clearly outlined. Examples of system policies are backups, downtime policies for routine maintenance, upgrades, testing of upgrades, and disaster planning.

The policies and procedures need to address how the system will be used by the various users throughout the facility such as coders, admission clerks, and other staff. In addition, the healthcare facility must create training manuals and user guides for reference. These materials will be available to the users as resources on how to use the system, how to incor- porate it into their job, and how to identify how their job has changed.

Check Your Understanding 5.4

1. An interface engine is an example of:

A. system analysis tool B. functional requirements C. setting configuration D. middleware

2. The type of testing where both the old system and the new system are operating at the same time is:

A. interface testing B. application testing C. parallel testing D. conversion testing

3. The form used to report problems with the new system is frequently called:

A. trouble ticket B. request for proposal C. functional requirements D. testing plan

4. The implementation stage that looks at the way the business does business is called:

A. testing B. reengineering C. conversion D. system analysis

5. True or False: Volume testing tests the amount of data stored on the computer.

Training

Training is crucial to the success of the implementation process. There needs to be a well- designed training plan that addresses the timing and methods used to train the users (Engle- bardt and Nelson 2002). The plan must be properly executed or negative repercussions can occur. Users may be concerned they are reverting back to being a novice employee after being an expert in their position. They may also be concerned about whether or not they will be able to keep their job if they are unable to learn the new computer system. Individu- als who are most concerned with the new computer systems are those who are not comfort- able with computers at all. Communicating with employees and keeping them informed of changes, impact, and expectations of their position will help prepare them for training.

Each person learns differently. Learning ability is impacted by their age, maturity level, and experience, so their preferred learning style may change over time. Because of these

AB103409_ch05.indd 137AB103409_ch05.indd 137 2/1/10 1:20:41 PM2/1/10 1:20:41 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

138 Chapter 5

factors, instructors should use a variety of methods that will reach all learning styles. Typi- cal learning styles are:

Sensory: Is the learner auditory (prefers to listen), visual (prefers to read), or • kinesthetic (prefers to practice)?

Personality: Various personality traits shape our orientation to the world.•

Information processing: People differ in how they receive and process information.•

Instructional and environmental preference: Sound, light, structure, and learning • relationships affect perceptions. (LaTour and Eichenwald Maki 2007, 717)

Instructors and trainers should have a basic understanding of adult learning principles and practice them in the development of training and its implementation. Some key adult learning principles are:

Adults like being responsible for their own decisions: They resent not having • control, so the instructor should let the learners have a say in the program. This can take the form of helping to set the agenda, deciding which of two or three activities to do, and so on (Bryant and Reimer 2007).

Adults are experienced: Adult learners come to the training session with a lot • of experience and knowledge upon which they can draw. Not all adults have the same knowledge and experience. The instructor and students can learn from each other. The varied backgrounds and knowledge can make for an interesting discussion and an improved learning experience (Bryant and Reimer 2007).

Adults need to know why: Instructors should get into a habit of telling the adults • why they need to do or learn what they are being taught. They need to know why something is important just as much as they need to know how to do something (Bryant and Reimer 2007).

Adults need to see relevance: Adults do not want to waste their time. They want • to learn what they need to know for the immediate future. The instructor will need to tie the material in the class to what the individuals in the course will be doing. In other words, do not teach nurses how to do something with the computer system that only the HIM department will be doing in the future. The nurses need to know what they will be doing. If an adult learner does not see relevance to themselves, they will not be motivated to learn (Bryant and Reimer 2007).

The adult needs to be ready to learn: Training sessions may be mandatory and the • learners may show up physically to the session, but they cannot be made to learn. The instructor must engage the learner and encourage the desire to learn (LaTour and Eichenwald Maki 2006).

The learner has to be motivated to learn: Some healthcare facilities have motivated • learners by making them take a competency test at the end of the training session. This test makes the learner use skills they learned in class. The motivation comes in because the healthcare facility usually ties the future of their job to successfully completing this test. These tests are generally very easy, but there are people who cannot pass them. These users are usually given a second or third chance before they are terminated. The threat of termination is not the best motivation because motivation to learn should come from within; however, the facility must know that the users are competent to use the systems (Bryant and Reimer 2007).

Planning for Training

There should be someone on the project team who is responsible for planning the complete training process. This trainer has a wide range of responsibilities including developing objectives, developing the training plan, and implementing the training.

AB103409_ch05.indd 138AB103409_ch05.indd 138 2/1/10 1:20:41 PM2/1/10 1:20:41 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

System Selection and Implementation 139

The trainer would attend implementation team meetings in order to keep up with the status of the project. The trainer needs to know when training will be needed, the type of training needed, and also be a superuser (or expert) on the new system. With this knowl- edge, the trainer will be prepared to develop the training program necessary to teach others to use the system. The trainer is responsible for sharing and providing the necessary knowl- edge needed to prepare other trainers to teach as well.

The trainer will also work with the training staff from the vendor. The vendor’s staff knows the product well and will be able to offer the team suggestions on different teach- ing methods directly related to the system. The vendor should provide the trainers with resources that can be customized for the facility.

Keep in mind, that as the trainer, he or she will be working with both management and end users during the training planning and training implementation stages. These interac- tions make the trainer an excellent liaison between the two groups. The trainer will be able to communicate expectations of administration to users as well as communicate the fears and concerns of the users back to administration.

Contents of the Plan The project team should create a training schedule that allows everyone who needs training to participate (Englebardt and Nelson 2002). The schedule should include sessions for all work shifts. This may mean training sessions are conducted for the day, evening, night, and weekend shifts. The training plan should contain learning objectives providing both trainer and trainees with information about what will be accomplished throughout the training sessions. The training plan should also outline the agenda, which describes the functions of the computer system that will be covered, how they will be covered, and how much time will be spent on each topic (Englebardt and Nelson 2002). The “how it will be covered” section includes teaching tools such as PowerPoint, hands-on training, demonstrations, and computer-assisted instruction to be used during training.

The training plan should also address the content that will be covered. These may include topics such as rollout schedule, policies and procedures, confidentiality, and secu- rity. When planning content, trainers need to determine the level of computer literacy each trainee possesses before determining what training is needed. For example, have they ever used a mouse? Do they need to learn Windows? The trainer will need to determine how many students will attend each session so that the number of trainers and training sessions can be determined. The planners will also have to determine the resources that will be needed such as a training room, computers, Internet access, training database, data projec- tor, and handouts.

Another decision to be made is how the training will be divided into sessions, because not all users need the same training. Two examples for the division of sessions are by department (such as nursing) or by function (such as order entry). In other words, the plan- ner needs to decide whether the session will teach all nurses together or will the session teach people how to look up test results and have everyone who needs to know how to do this included in the same session. The division of the training will impact the number of teachers, the schedule, and the training materials.

Selecting the Training Location Not every trainer is fortunate enough to have a dedicated training facility. Trainers may be forced to reserve computer classrooms throughout the facility. If so, the rooms need to be reserved early. Whether there is a dedicated room or not, the trainer should make sure the room is physically comfortable. This means that the room is at a comfortable temperature, has appropriate lighting, and the workstations are ergonomically sound. Cellular phones and beepers should be turned off in order to prevent distractions.

Scheduling the Training Scheduling can be a very tricky task because trainers have to conduct different training classes required by patient care providers, administrative office staff, and other groups of users. Many healthcare facilities are open 24 hours, 7 days a week, thus employees work a

AB103409_ch05.indd 139AB103409_ch05.indd 139 2/1/10 1:20:41 PM2/1/10 1:20:41 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

140 Chapter 5

variety of shifts. Because of this, training must be offered on all shifts including weekends. Issues to consider are as follows:

If there is more than one class required, the team must make sure that they are • offered in a logical format. Breaking modules down into separate classes is wise because otherwise the students become confused. For example, the trainers would need to teach an introduction to computers class before the trainers teach Windows, and the trainer would need to teach Windows before they can teach people to use a Windows-based application.

This is further complicated by the fact that the trainers need to schedule the • classes as close as possible to go-live while starting training early enough to get everyone trained in time. Completing training too early is also problematic because the users can forget what they learned before the system is implemented, thus making the transition difficult for the user and the facility.

Length of a session matters. Short sessions tend to work better because most • healthcare professionals are used to being on their feet while working. They are unaccustomed to sitting down and may become frustrated by inactivity (Abdelhak et al. 2007).

The training sessions should not be scheduled during holidays because many people • take time off, which causes scheduling problems with getting everyone trained.

Physicians should be scheduled for one-on-one training sessions. The reason for • this is that physicians do not like to appear less than competent in front of peers. Some physicians do not know how to use the computers and do not want others to know about their lack of knowledge. Physician training is scheduled at the convenience of the physician, which is basically any time. It could be early in the morning, at lunch, late in afternoon, the evening, or on weekends in order to avoid interfering with physicians’ schedules.

Resources Needed Each user should be provided a handout at the training session to take back to their work area. Training materials are excellent resources to be utilized by users to look up how to do some task that may have been forgotten. Several days, weeks, or even months may pass between the initial training session and the implementation of the computer system. During that time, it is likely for users to forget much of the material learned. To help users retain the knowledge acquired in training, the facility may also want to make the system available (in test mode) to users for practice throughout this interim period.

Content suggestions to the development of educational materials provided to the stu- dents are as follows:

The objectives should be clearly outlined.•

The agenda for the course should be sent to the scheduled attendees ahead of time. • The agenda is subject to change, but acts as a guide to help keep trainers on track.

Train the Trainer “Train the trainer” is a phrase used to describe a group of one or a few people sent to the vendor to be trained on how to use the new system and then go back to the facility to train more trainers (Wager et al. 2005). These people are generally called “superusers.” Super- users return to the healthcare facility and train other trainers who will in turn help conduct training sessions (Englebardt and Nelson 2002).

The trainer is the one person whom the user associates with knowledge of the system and its uses, so the trainer is very likely to receive calls from former students about it. This visibility will make the trainer a key player in the hours and days following go-live. It will likely be the trainer that users turn to with questions and fears.

AB103409_ch05.indd 140AB103409_ch05.indd 140 2/1/10 1:20:41 PM2/1/10 1:20:41 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

System Selection and Implementation 141

Conducting the Training

Now that all of the work planning the training is finished, it is time to conduct the class. Instructors should be prepared to enter the classroom to make sure it is ready for training. Trainers should use a variety of instructional methods during the session as this has been found to improve learning. Students should be provided with handouts, policies and proce- dures, and other materials that they can keep (Hebda et al. 2005).

Evaluating the Training

Trainers must be evaluated on their delivery, impact, and knowledge of the application to make sure objectives of the training are being met.

LaTour and Eichenwald Maki (2007) identified four outcomes of training that should be critiqued. These are:

Reaction: What is the reaction of the trainees immediately after the program? Are • they excited about what they learned?

Learning: What have the trainees actually learned? Can they now use a new • software program?

Behavior: Have supervisors noticed a change in employee behavior? Has morale • improved?

Results: How does the actual level of performance compare with the established • objectives? Can the employees assign codes more accurately? (LaTour and Eichenwald Maki 2007, 731)

A valuable method for obtaining feedback is to have each trainee complete a written evaluation at the completion of the session, answering questions about the overall training and the ability of the trainer. These evaluations can help to identify what is and is not working. Findings may identify needed improvements such as in the handouts, poor instructors, or not enough time for hands-on activities. Findings from the trainee evaluations should be shared with the instructors anonymously so that any needed modifications can be identified, and to just evaluate the overall training plan performance. Evaluation results should be used to improve the quality and method of training where needed. There is always room for improvement.

The overall training program should also be evaluated on an ongoing basis to ensure that goals of training are met. A formal plan for evaluation should be developed prior to the start of the training sessions.

Additional and Ongoing Training

After the training phase and before go-live, the facility eventually won’t need the same number of trainers or frequency of class sessions. Training needs should be reassessed to determine fre- quency and structure of needs. Training may be reorganized to be in conjunction with the facil- ity’s human resources department new employee orientation program or it may be separate. Training may be required before the employee is issued a user identification and password.

In a perfect world, the system on which users are trained would remain the same as the one implemented. However, changes to the system will be made and are necessary for technology advances, resolving glitches, and other issues. Therefore, training does not end with go-live of the system. When significant changes are made, training may have to occur to update and prepare users for the changes. Also, existing employees may need additional training to learn advanced capabilities, reinforce what they’ve already learned, or if they transfer jobs or their job changes over time.

Computer-Assisted Instruction

Computer-assisted instruction (CAI) will not be used by most healthcare facilities, but it is a viable option. CAI is a software program designed to use multimedia and interactive

AB103409_ch05.indd 141AB103409_ch05.indd 141 2/1/10 1:20:41 PM2/1/10 1:20:41 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

142 Chapter 5

technology to teach a topic. A good example of CAI is the CD that comes with many medi- cal terminology textbooks. Multimedia can use audio, video, simulation, self-quizzes, and other tools to engage the student. Drill and practice CAI reinforce material that the learner already knows, whereas problem-solving addresses issues that the learner may face in his or her discipline (Kreider and Haselton 1997).

The benefit to CAI is that it has been proven to increase learning while decrease learn- ing time (Hebda et al. 2005). Students are able to work at their own pace and on their own schedule. They are able to receive immediate feedback on whether or not they do some- thing right (Kreider and Haselton 1997). CAI also reduces costs, provides standardized training, and is designed to use multiple learning styles. The student is actively engaged in the training (Hebda et al. 2005).

Documenting the Training

Documentation of all training provided is critical. Students should sign into each training session to provide proof of attendance for both employee’s and employer’s benefit. If a competency test is given, documentation of the results also should be maintained. Copies of all training materials and objectives for the training also should be retained.

Testing Plan

All components of the information system will need testing before the go-live. The purpose of testing the computer system is to ensure that everything is functioning properly (Aus- tin and Boxerman 2007). Testing helps the implementation team identify any bugs (prob- lems) with the system. This is a cyclical process so the team will test the system, identify problems, fix problems, and test the system again. The test cycle will continue until all problems have been resolved. Testing requires careful and detailed planning to ensure that complete and accurate testing is carried out in a timely manner.

Types of Testing

There are many types of testing that must be performed in preparation for a system imple- mentation. The types of testing include:

Interface Testing: Ensures that the interfaces function properly. The facility must • test to confirm that data from the feeder system are transferred into the new system in the correct field and in the right format. Data to be transferred varies by system but commonly include the patient’s name, medical record number, date of birth, and other demographic information. Other types of data that may be transferred include laboratory tests, radiology results, or any other data that are collected.

Hardware Testing: Ensures that all hardware, including computers, printers, and • scanners, work together as they should. Examples of testing to be performed include the ability to scan documents, print a report, or scan barcode. Some computers may have limitations placed on their abilities for privacy, security, or other reasons. For example, the facility may choose not to print laboratory results on the nursing units to protect confidentiality, thus forcing users to look up the most current results available.

Application Testing: Ensures that every function of the new computer system • works. Application testing also ensures that the system meets the functional requirements and other required specifications in the RFP or contract. Application testing should also ensure that every conceivable situation that the computer will be used to address can be handled. The team must also test the reports to ensure that the data and statistics contained therein are correct.

AB103409_ch05.indd 142AB103409_ch05.indd 142 2/1/10 1:20:41 PM2/1/10 1:20:41 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

System Selection and Implementation 143

Documentation Testing: During the implementation process a number of documents, • including user guides, policies and procedures, and training materials, are created. These documents should be followed during the testing process to ensure that the instructions in the documents are accurate. In testing the documentation, the tester follows and tests the information system documentation that will be provided to the users. Errors in the documentation will be identified and corrected so that the user will have the proper instructions.

Conversion Testing: Ensures that the team is able to transfer data from the • old system to the new system. Conversion testing will confirm that the data conversion is performed correctly. Testing usually begins with a small amount of real data that have been copied. After the initial test has been run, the team would fix any problems, rerun the test, and then continue to add larger and larger amounts of data. This testing will continue until the team is sure that the problems have been resolved prior to the actual data conversion.

Training Testing: The team should train a group to see how well the training • materials, agenda, format of training, time allotted for training, and other attributes work. Changes are made to the training process as needed before real training begins.

Volume Testing: Most of the testing performed on the application is done with • a handful of people sitting at a computer system trying to identify problems. The system may work fine with a small group of people, but most systems are used by large groups of people simultaneously. To test the system in as real an environment as possible, volume testing should be performed. Volume testing gets as many people to use the system at one time as possible. Volume testing confirms that the computer system and the network can handle the large volume of users and data. The user task force as well as other users throughout the facility can be brought in for volume testing. The project team will need to recruit as many users as possible to use the system at the same time (Abdelhak et al. 2007).

Parallel Testing: Unlike most other testing, parallel testing occurs when the new • system is operational. This is not a required test, but can be a valuable one. Parallel testing is when the facility runs the old and the new system simultaneously and compares the reports and data from the two systems to validate both performance and synchronization. For example, the facility could compare the number of admissions for a specific date, the number of tests ordered, or the number of times that a test was ordered. Because of the extra resources needed to operate both systems, this test is frequently omitted. The benefit to parallel testing is that if the new system does not work as expected and the facility has to shut the system down, then the existing system is current, thus not impacting the operations of the facility.

Acceptance Testing: Like parallel testing, acceptance testing occurs after go-live. • It is a time to verify that the system is working as expected in a live environment. It gives the healthcare facility time to confirm that the new system meets response time, functional requirements, and other standards guaranteed in the contract (Amatayakul 2007).

Test Plan

The testing plan must cover areas such as what is to be tested, who will be involved in the testing, dates of testing, documentation of testing results, and types of testing. The testing must continue until all problems are fixed. The testing must include the documentation cre- ated for use with the system as well.

AB103409_ch05.indd 143AB103409_ch05.indd 143 2/1/10 1:20:41 PM2/1/10 1:20:41 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

144 Chapter 5

The testing plan should create a realistic testing environment. For example, the set- tings in the test system should be the ones that the facility will utilize during operation. The testing plan will identify a “laundry list” of functions that must be tested before the system is implemented. One way to test the functions is scenario or use-case testing, during which users bring real-life situations to be addressed by the system. These scenarios should be documented in the plan. The use of scenarios allows the user to think through how a situation will be handled by actually using the system. Scenario testing thoroughly tests the system because it addresses entries into the system, tasks, and output from the system (Amatayakul 2007).

Testing Documentation

Many healthcare facilities use what is frequently called a trouble ticket to report problems encountered during the testing phase. The trouble ticket is simply a form that is used to give specific information on problems encountered. The information provided may include: screen where problem occurred, function being performed, error message received, data entered, report with incorrect data, or other problems encountered. The information pro- vided must be as detailed as possible so that the problem can be replicated by the project manager or designee. The trouble ticket is logged into some type of tracking system when received, assigned a tracking number, and assigned to the appropriate person to solve. Once the problem has been resolved, the resolution is recorded, and the system testing begins again. The team cannot just test the part that was broken because the change that was made to fix the problem may have broken something else.

Conversion

Once the system is ready for use and the facility is ready for the system, the data con- version plan must be implemented to move the existing data into the new system in the appropriate format (Wager, Lee, and Glaser, 2005). If data conversion is successful, the facility is then ready to start using the new computer system. Facilities frequently capture the information available in the system at midnight so that they can determine what data are in the old system and what data are in the new system. A specific time period of transi- tion is useful in case the facility has to go back to the old system because the new system did not work.

Go-Live

Go-live is the official time and date that the facility begins using the new system. The go- live is generally scheduled for a time when the facility is the least busy. For example, a hos- pital will generally go-live during the night shift because there is less activity at that time.

Go-Live Models

There are four philosophies with regard to go-live: parallel, phased, pilot, and big bang (Young 2000).

Parallel Approach Although parallel start-up works well, it is labor intensive and therefore expensive. Because the old system is in place and current, this approach provides a safety net and has the least amount of risk involved.

Phased Approach Another method is the phased approach. In this method, the implementation starts with one module of the system, and then gradually other modules of the system are added. A module

AB103409_ch05.indd 144AB103409_ch05.indd 144 2/1/10 1:20:42 PM2/1/10 1:20:42 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

System Selection and Implementation 145

is a subset of an information system such as pharmacy orders in a clinical provider order entry system. All units, departments, and other entities utilize the system, but they only use it for one module at a time. For example, a hospital could start using their order entry system by ordering medications only. After the medication ordering is successful, then laboratory will be added and so on. With an optical disk system, hospitals frequently start scanning emergency department records, then outpatient surgery, and then other record types until they work their way up to inpatient records. The advantage of this method is that staff is not overwhelmed by trying to do everything at once and the impact on the staff is lessened. The disadvantage is that it seems to take forever to finish the start-up process.

Pilot Method The next philosophy is the pilot method in which only one nursing unit, department, or other entity starts using the new system at a time. Once consistently successful, the next group is implemented. For example, the 3W nursing unit starts ordering everything using the new system, but nobody else uses the system. The next unit scheduled would be unit 3E. Again, this method is designed to limit the impact on the facility.

Big Bang Method The last method, the big bang method which is also called the cutover method, is the most risky. With this method, the facility stops using the old system and starts using the new system. It is the riskiest because the facility no longer has the old system as a backup and the new system is being used all over the hospital, so there are a lot of scared people trying to use a computer system they are not comfortable with.

Planning for Go-Live

Whichever method is chosen, planning is critical because system implementation cannot interfere with patient care. There are some steps that should be taken no matter which plan is selected.

Initial Support First of all there needs to be a member of the implementation team in every unit or depart- ment when the system goes live. These team members should be highly visible. They could all wear the same t-shirts or buttons or some other means of identifying them as a member of the implementation team. Team members are needed to answer questions and generally ensure that the system start-up runs as smoothly as possible. Keep in mind that users will be scared and will want to see someone who can help them. Trainers play an important role not only in the training but during go-live, which means they are a key part of the imple- mentation presence throughout the facility.

Ongoing Support Initially someone must be available 24 hours a day, 7 days a week to assist users. The length of time that this intensive support is needed will depend on how major a system it is and how well the implementation is going. Generally this intensive support is needed no longer than a week (Englebardt and Nelson 2002). There should be a special help desk users can call for help when needed. The amount of coverage needed will eventually be reduced to the use of beepers and the regular help desk support. The implementation team must be prepared to go back to the old system if the new one does not work.

System Evaluation

After the system is implemented and functioning properly, the implementation team will need to evaluate how well the system implementation went. “The purpose of system evalua- tion is to determine whether the system functions in the way intended” (Abdelhak et al. 337). The team needs to learn what did and did not work and determine how they can improve

AB103409_ch05.indd 145AB103409_ch05.indd 145 2/1/10 1:20:42 PM2/1/10 1:20:42 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

146 Chapter 5

the next implementation. The team will also want to know if the facility met the goals that were established for the project and if the project came in on budget. This evaluation allows the team to learn from mistakes and from the experience. After a predetermined time period, the team will need to determine if the facility has realized all expected benefits (Johns 2007). Some examples include goals such as, did the number of staff get reduced, or did the facility save the money that was expected, or did it reduce the turnaround time on obtaining test results?

Post-Implementation

Post-implementation, or maintenance, is the final step of the implementation process. In this stage, the system is operational and the goal is to provide ongoing maintenance and improve the system where needed (Hebda et al. 2005). In the immediate post-implementation period, problems may be found that were not revealed during the system testing and will need to be resolved. Changes may need to be made to correct the problems and more testing will need to be done. Even after the system is working well, there will be periodic updates to ensure the system is current. There will also be routine maintenance and upgrades such as backing up data, increasing storage capacity, and upgrading hardware and software. As discussed earlier, major computer systems have what is called a test system or a test environment (Hebda et al. 2005). This is an exact duplicate of the system in use, exclud- ing data. In this test environment, changes can be made to the system and tested to see what happens.

Because it is in the test and not the production environment, the software changes can be tested without worrying about problems resulting from the changes. This will enable support staff to solve problems before the update is moved to the live. Once the system is working appropriately in the test environment, it can be implemented into the live one.

Check Your Understanding 5.5

1. True or False: The active learner prefers to learn by case studies rather than writing papers.

2. The go-live model where the old system is stopped and the new system used is:

A. phased B. pilot C. cutover D. parallel

3. Which of the following is an adult learning principle?

A. Adults need to see relevance B. Adults like to be told what to do C. Adults learn well even if not motivated D. Adults have the same knowledge and experience

4. True or False: System training should be broken into short sessions for healthcare professionals.

5. The implementation stage where the team determines what they could have done better is:

A. training B. post-implementation C. evaluation D. system analysis

AB103409_ch05.indd 146AB103409_ch05.indd 146 2/1/10 1:20:42 PM2/1/10 1:20:42 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

System Selection and Implementation 147

References

Abdelhak, M., S. Grostick, M.A. Hanken, and E. Jacobs. 2007. Health Information: Management of a Strategic Resource. St. Louis, MO: Saunders Elsevier.

Amatayakul, M.K. 2007. Electronic Health Records: A Practical Guide for Professionals and Organizations. Chicago: AHIMA.

American Health Information Management Association. 2006. Wordpower: A glossary of software licensing

terms. Journal of AHIMA 77(4):42, 44.

American Health Information Management Association. 2007. RFI/RFP template. Journal of AHIMA 78(6): web extra. http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_034278.

hcsp?dDocName=bok1_034278.

American Health Information Management Association. 2010. Pocket Glossary of Health Information Management and Technology, 2nd ed. Chicago: AHIMA.

Austin, C.J. and S.B. Boxerman. 2003. Information Systems for Healthcare Management. Chicago: AUPHA Press Health Administration Press.

Bryant, G. and J. Reimer. 2006. E-learning for HIM, theory and practice: A new world order or reinforcement

of existing (e-) learning theory. Proceedings of the American Health Information Management Association’s 79th National Convention and Exhibit.

Dolan, T.G. 2006. Contracting for ASP services: When signing for the benefits, remember to manage the

risks. Journal of AHIMA 77(5):48–50.

Englebardt, S.P. and R. Nelson. 2002. Healthcare Informatics: An Interdisciplinary Approach. St. Louis, MO: Moseby.

Glandon, G.L., D.H. Smaltz, and D.J. Slovensky. 2008. Austin and Boxerman’s Information Systems for Healthcare Management. Chicago: Health Administration Press/AUPHA.

Hebda, T, P. Czar, and C. Mascara. 2005. Handbook of Informatics for Nurses & Health Care Professionals. Upper Saddle River: Pearson Prentice Hall.

Johns, M.L., ed. 2006. Health Information Management Technology: An Applied Approach. Chicago: AHIMA.

Kreider, N.A. and B.J. Haselton. 1997. The Systems Challenge. Chicago: American Hospital Association.

LaTour, K.M. and S. Eichenwald Maki, eds. 2006. Health Information Management: Concepts, Principles, and Practice. Chicago: AHIMA.

McWay, D.C. 2008. Today’s Health Information Management: An Integrated Approach. Clifton Park, NY: Thompson Delmar Learning.

Merriam-Webster. 2009. Force majeure. http://www.merriam-webster.com/dictionary/force+majeure.

Mikulski, F.A. 1993. Managing Your Vendors. Englewood Cliffs, NJ: Prentice-Hall, Inc.

Rhodes, H. 1997 (March). Practice brief: Developing information capture tools.

Rollins, G. 2006. The perils of customization. Journal of AHIMA 77(6):24–28.

Wager, K.A., F.W. Lee, and J.P. Glaser. 2005. Managing Health Care Information Systems. San Francisco: Jossey-Bass.

Williams, A. Design for better data: How software and users interact onscreen matters to data quality. Journal of AHIMA 77(2):56–60.

Young, K.M. 2000. Informatics for Healthcare Professionals. Philadelphia, PA: F.A. Davis.

AB103409_ch05.indd 147AB103409_ch05.indd 147 2/1/10 1:20:42 PM2/1/10 1:20:42 PM

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use

AB103409_ch05.indd 148AB103409_ch05.indd 148 2/1/10 1:20:42 PM2/1/10 1:20:42 PM

This page intentionally left blank

EBSCOhost - printed on 6/14/2022 1:46 PM via UNIVERSITY OF MARYLAND GLOBAL CAMPUS. All use subject to https://www.ebsco.com/terms-of-use