Adopting Health Information Systems

System Acquisition Learning Objectives To be able to explain the process a healthcare organization generally goes through in selecting a healthcare information system. To be able to describe the systems development life cycle and its four major stages. To be able to discuss the various options for acquiring a health care information system (for example, purchasing, leasing, contracting with vendors for cloud computing services, or building a system in-house) and the pros and cons of each option. To be able to discuss the purpose and content of a request for information and request for proposal in the system acquisition process. To gain insight into the problems that may occur during the system acquisition process. To gain an understanding of the healthcare IT industry and the resources available for identifying healthcare IT vendors and learning about their history, products, services, and reputation. To gain insight into the importance of understanding IT architecture. By now you should have an understanding of the various types of healthcare information systems and the value they can bring to health care organizations and the patients they serve. This chapter describes the typical process a healthcare organization goes through in acquiring or selecting a new clinical or administrative application. Acquiring an information system (IS) application can be an enormous investment for health care organizations. In addition to the initial cost, there are a host of long-term costs associated with maintaining, supporting, and enhancing the system. Health care professionals need access to reliable, complete, and accurate information in order to provide effective and efficient health care services and to achieve the strategic goals of the organization. Selecting the right application, one that meets the organization's needs, is a critical step. Too often information systems are acquired without exploring all options, without evaluating costs and benefits, and without gaining sufficient input from key constituent user groups. The results can be disastrous.

This chapter describes the people who should be involved, the activities that should occur, and the questions that should be addressed in acquiring any new information system. The suggested methods are based on the authors' years of experience and on countless case studies of system acquisition successes and failures published in the health care literature.

System Acquisition: A Definition In this book system acquisition refers to the process that occurs from the time the decision is made to select a new system (or replace an existing system) until the time a contract has been negotiated and signed. System implementation is a separate process described in the next chapter, but both are part of the systems development life cycle. The actual system selection, or acquisition, process can take anywhere from a few days to a couple of years, depending on the organization's size, structure, complexity, and needs. Factors such as whether the system is deemed a priority and whether adequate resources (time, people, and funds) are available can also directly affect the time and methods used to acquire a new system (Jones, Koppel, Ridgley, Palen, Wu, & Harrison, 2011).

Prior to arriving at the decision to select a new system, the health care executive team should engage in a strategic IS planning process in which the strategic goals of the organization are formulated and the ways in which information technology (IT) will be employed to aid the organization in achieving its strategic goals and objectives are discussed. We discuss the need for aligning IT plans with the strategic goals of the organization and for determining IT priorities in Chapter Twelve. In this chapter, we assume that a strategic IT plan exists, IT priorities have been established, the new system has been adequately budgeted, and the organization is ready to move forward with the selection process. We also assume that the organization has conducted a readiness assessment and is well equipped to move forward with the health IT project or initiative. The AHRQ National Resource Center for Health IT has available a number of tools publicly available that can be helpful to health care organizations in assessing their readiness for health IT projects such as EHR implementations and for ensuring that they have in place the personnel, technical, and financial resources to embark on the initiative. These tools can be found at https://healthit.ahrq.gov/health-it-tools-and-resources. Additionally, the Office of the National Coordinator for Health Information Technology (ONC) has readiness tools available and implementation blueprints that serve as excellent resources at https://www.healthit.gov/providers-professionals/ehr-implementation-steps. Systems Development Life Cycle No board of directors would recommend building a new health care facility without an architect's blueprint and a comprehensive assessment of the organization's and the community's needs and resources. The architect's blueprint helps ensure that the new facility has a strong foundation, is well designed, fosters the provision of high-quality care, and has the potential for growth and expansion. Similarly, the health care organization needs a blueprint to aid in the planning, selection, implementation, and support of a new health care information system. The decision to invest in a health care information system should be well aligned with the organization's overall strategic goals and should be made after careful thought and deliberation. Information systems are an investment in the organization's infrastructure, not a one-time purchase. Health care information systems require not only up-front costs and resources but also ongoing maintenance, support, upgrades, and eventually, replacement.

The process an organization generally goes through in planning, selecting, implementing, and evaluating a health care information system is known as the systems development life cycle (SDLC). Although the SDLC is most commonly described in the context of software development, the process also applies when systems are purchased from a vendor or leased through cloud-based computing services. Cloud computing is a general term that refers to a broad range of application, software, and hardware services delivered over the Internet. Regardless of how the system is acquired, most health care organizations follow a structured process for selecting and implementing a new computer-based system. The systems development process itself involves participation from individuals with different backgrounds and areas of expertise. The specific mix of individuals depends on the nature and scope of the new system. Many SDLC frameworks exist, some of which employ an incremental approach, but most have four general phases, or stages: planning and analysis, design, implementation, and support and evaluation (Wager & Lee, 2006) (see Figure 5.1). Each phase has a number of tasks that need

to be performed. In this chapter we focus on the first two phases; Chapter Six focuses on the last two.

The SDLC approach assumes that this four-phase life of an IS starts with a need and ends when the benefits of the system no longer outweigh its maintenance costs, at which point the life of a new system begins (Oz, 2012). Hence, the entire project is called a life cycle. After the decision has been made to explore further the need for a new information system, the feasibility of the system is assessed and the scope of the project defined (in actuality it is at times difficult to tell when this decision making ends and analysis begins). The primary focus of this planning and analysis phase is on the business problem, or the organization's strategy, independent of any technology that can or will be used. During this phase, it is important to examine current systems and problems in order to identify opportunities for improvement. The organization should assess the feasibility of the new system—is it technologically, financially, and operationally feasible? Furthermore, sometimes it is easy to think that implementing a new IS will solve all information management problems. Rarely, if ever, is this the case. But by critically evaluating existing systems and workflow processes, the health care team might find that current problems are rooted in ineffective procedures or lack of sufficient training. Not always is a new system needed or the answer to a problem.

Once it is clear that a new IS is needed, the next step is to assess the information needs of users and define the functional requirements: What functions must the system have to fulfill the need? This process can be very time-consuming. However, it is vital to solicit widespread participation from end users during this early stage—to solicit and achieve buy-in. As part of the needs assessment, it is also helpful to gather, organize, and evaluate information about the organization in which the new system is to operate. Through defining system requirements, the organization specifies what the system should be able to do and the means by which it will fulfill its stated goals. Once the team knows what the organization needs, it enters the second stage, the design phase, when it considers all its options. Will the new system be designed in-house? Will the organization contract with an outside developer? Or will the organization purchase a system from a health information systems vendor or contract with a vendor for cloud-based services? A large majority of healthcare organizations purchase a system from a vendor or at least look first at the systems available on the market. Contracting with the vendor to host the applications, software, hardware, and infrastructure via cloud computing is also growing in popularity in health care (Griebel et al., 2015). System design is the evaluation of alternative solutions to address the business problem. It is generally in this phase that all alternatives are considered, a cost-benefit analysis is done, a system is selected, and vendor negotiations are finalized.

After the contract has been finalized or the system has been chosen, the third phase, implementation, begins. The implementation phase requires significant allocation of resources in completing tasks, such as conducting work-flow and process analyses, installing the new system, testing the system, training staff members, converting data, and preparing the organization and staff members for the go-live of the new system. Finally, once the system is

put into operation, the support and evaluation phase begins. It is common to underestimate the number of staff and resources needed to effectively keep new and existing information systems functioning properly. No matter how much time and energy were spent on the design and build of the application, you can count on the fact that changes will need to be made, glitches fixed, and upgrades installed. Likewise, most mission-critical systems need to be functioning 99.99 percent of the time—that is, with little downtime. Sufficient resources (people, technology, infrastructure, and upgrades) need to be allocated to maintain and support the new system. Moreover, maintaining and supporting the new system is not enough. Health care executives and boards often want to know the value of the IT investment, thus the degree to which the new system has achieved its goals and objectives should be assessed. Eventually, the system will be replaced and the SDLC process begins again.

With this general explanation of the SDLC established, we begin by focusing on the first two phases—the planning and analysis phase and the design phase. Together they constitute what we refer to as the system acquisition process. System Acquisition Process To gain an understanding of and appreciation for the activities that occur during the system acquisition process, we will follow a health care facility through the selection process for a new information system—specifically, an electronic health record (EHR) system. In this case the organization, which we will call Valley Practice, is a multi physician primary care practice.

What process should the practice use to select the EHR? Should it purchase a system from a vendor, contract with a vendor for cloud-based services, or seek the assistance of a system developer? Who should lead the effort? Who should be involved in the process? What EHR products are available on the market? How reputable are the vendors who develop these products? These are just a few of the many questions that should be asked in selecting a new IS.

Although the time and resources needed to select an EHR (or any health care information system) may vary considerably from one setting to another, some fundamental issues should be addressed in any system acquisition initiative. The sections that follow the case study describe in more detail the major activities that should occur (see Exhibit 5.1), relating them to the multi physician practice scenario. We assume that the practice wishes to purchase (rather than develop) an EHR system. However, we briefly describe other options and point out how the process may differ when the EHR acquisition process occurs in a larger health care setting, such as integrated health systems. Exhibit 5.1 Overview of System Acquisition Process Establish a project steering committee and appoint a project manager. Define project objectives and scope of analysis. Screen the marketplace and review vendor profiles. Determine system goals. Determine and prioritize system requirements. Develop and distribute a request for proposal (RFP) or a request for information (RFI).

Explore other options for acquiring systems (e.g., leasing, hiring system designer, building in-house). Evaluate vendor proposals. Develop evaluation criteria. Hold vendor demonstrations. Make site visits and check references. Prepare vendor analysis. Conduct cost-benefit analysis. Prepare a summary report and recommendations. Conduct contract negotiations. Establish a Project Steering Committee One of the first steps in any major project such as an EHR acquisition effort is to create a project steering committee. This committee's primary function is to plan, organize, coordinate, and manage all aspects of the acquisition process. Appointing a project manager with strong communication skills, organizational skills, and leadership abilities is critical to the project. In our Valley Practice case, the project manager was a physician partner. In larger health care organizations such as hospitals, it would likely be a CIO involved in the effort and that person might also be asked to lead it.

Increasingly, clinicians such as physicians and nurses with training in informatics are being called on to lead clinical system acquisition and implementation projects. Known as chief medical informatics officers (CMIOs) or chief nursing informatics officers (CNIOs), these individuals bring to the project a clinical perspective as well as an understanding of IT and information management processes. (The roles of CMIOs and CNIOs are described more fully in Chapter Eight.) Regardless of the discipline or background of the project manager (for example, IT, clinical, or administrative), he or she should bring to the project passion, interest, time, strong interpersonal and communication skills, and project management skills and should be someone who is well respected by the organization's leadership team and who has the political clout to lead the effort effectively. Case Study Replacing an EHR System Valley Practice provides patient care services at three locations, all within a fifteen-mile radius, and serves nearly one hundred thousand patients. Valley Practice is owned and operated by seven physicians; each physician has an equal partnership. In addition to the physicians, the practice employs nine nurses, fifteen support staff members, a business officer manager, an accountant, and a chief executive officer (CEO).

During a two-day strategic planning session, the physicians and management team created a mission, vision, and set of strategic goals for Valley Practice. The mission of the facility is to serve as the primary care “medical home” of individuals within the community, regardless of the patients' ability to pay. Valley Practice wishes to be recognized as a “high-tech, high-touch” practice that provides high-quality, cost- effective patient care using evidence-based standards of care. Consistent with its mission, one of the practice's strategic goals is to replace its legacy EHR with an EHR system that adheres to industry standards for security and interoperability

and that fosters patient engagement, with the long-term goal of supporting health fitness applications.

Dr. John Marcus, the lead physician at Valley Practice, asked Dr. Julie Brown, the newest partner in the group, to lead the EHR project initiative. Dr. Brown joined the practice two years ago after completing an internal medicine residency at an academic medical center that had a fully integrated EHR system available in the hospital and its ambulatory care clinics. Of all the physicians at Valley Practice, Dr. Brown has had the most experience using EHR applications via portable devices. She has been a vocal advocate for migrating to a new EHR and believes it is essential to enabling the facility to achieve its strategic goals. Dr. Brown agreed to chair the project steering committee. She invited other key individuals to serve on the committee, including Dr. Renee Ward, a senior physician in the practice; Mr. James Rowls, the CEO; Ms. Mary Matthews, RN, a nurse; and Ms. Sandy Raymond, the business officer manager.

After the project steering committee was formed, Dr. Marcus met with the committee to outline its charge and deliverables. Dr. Marcus expressed his appreciation to Dr. Brown and all of the members of the committee for their willingness to participate in this important initiative. He assured them that they had his full support and the support of the entire physician team.

Dr. Marcus reviewed with the committee the mission, vision, and strategic goals of the practice as well as the committee's charge. The committee was asked to fully investigate and recommend the top three EHR products available in the vendor community. He stressed his desire that the committee members would focus on EHR vendors that have experience and a solid track record in implementing systems in physician practices similar to theirs and that have Office of the National Coordinator for Health Information Technology (ONC)–certified EHR products. He is intrigued with the idea of cloud-based EHR systems provided they can ensure safety, security, and confidentiality of data; are reliable and scalable; and have the capacity to convert data easily from the current system into the new system. The vendor must also be willing to sign a business associates' agreement ensuring compliance with HIPAA security and privacy regulations. Dr. Marcus is also interested in exploring what opportunities are available for health information exchange within the region. He envisions that the practice will likely partner with specialists, hospitals, and other key stakeholders in the community to provide coordinated care across the continuum under value-based reimbursement models. Under the leadership of Dr. Brown, the members of the project steering committee established five project goals and the methods they would use to guide their activities. Ms. Moore, the consultant, assisted them in clearly defining these goals and discussing the various options for moving forward. They agreed to consider EHR products only from those vendors that had five or more years of experience in the industry and had a solid track record of implementations (which they defined as having done twenty-five or more). Dr. Ward, Mr. Rowls, and Ms. Matthews assumed leadership roles in verifying and prioritizing the requirements expressed by the various user groups.

The five project goals were based on Valley Practice's strategic goals. These project goals were circulated for discussion and approved by the CEO and the physician partners. Once the goals were agreed on, the project steering committee appointed a small task group of committee members to carry out the process of defining system functionality and requirements. Because staff time was limited, the task group conducted three separate focus groups during the lunch period—one with the nurses, one with the support staff members, and a third with the physicians. Ms. Moore, the consultant, conducted the focus groups, using a semi-structured nominal group technique.

Concurrently with the requirements definition phase of the project, Mr. Rowls and Dr. Brown, with assistance from Ms. Moore, screened the EHR vendor marketplace. They reviewed the literature, consulted with colleagues in the state medical association, and surveyed practices in the state that they knew used state-of-the-art EHR systems. Mr. Rowls made a few phone calls to chief information officers (CIOs) in surrounding hospitals who had experience with ambulatory care EHR to get their advice. This initial screening resulted in the identification of eight EHR vendors whose products and services seemed to meet Valley Practice's needs. Given the fairly manageable number of vendors, Ms. Moore suggested that the project steering committee use a short-form RFP. This form had been developed by her consulting firm and had been used successfully by other physician practices to identify top contenders. The short-form RFPs were sent to the eight vendors; six responded. Each of these six presented an initial demonstration of its EHR system on site. Following the demonstrations, the practice staff members completed evaluation forms and ranked the various vendors. After reviewing the completed RFPs and getting feedback on the vendor presentations, the committee determined that three vendors had risen to the top of the list.

Dr. Brown and Dr. Ward visited four physician practices that used EHR systems from these three finalists. Mr. Rowls checked references and prepared the final vendor analysis. A detailed cost-benefit analysis was conducted, and the three vendors were ranked. All three vendors, in rank order, were presented in the final report given to Dr. Marcus and the other physician partners. Dr. Marcus, Dr. Brown, and Mr. Rowls spent four weeks negotiating a contract with the top contender. It was finalized and approved after legal review and after all the partners agreed to it. Pulling together a strong team of individuals to serve on the project steering committee is also important. These individuals should include representatives from key constituent groups in the practice. At Valley Practice, a physician partner, a nurse, the business officer manager, and the CEO agreed to serve on the committee. Gaining project buy-in from the various user groups should begin early. This is a key reason for inviting representatives from key constituent groups to serve on the project steering committee. They should be individuals who will use the EHR system directly or whose jobs will be affected by it.

Consideration should also be given to the size of the committee; typically, having five to six members is ideal. In a large facility, however, this may not be possible. The committee for a hospital or health systems might have fifteen to twenty members, with representatives from key

clinical areas such as laboratory medicine, pharmacy, and radiology in addition to representatives from the administrative, IT, nursing, and medical staff.

It is important to have someone knowledgeable about IT serving on the project steering committee. This may be a physician, a nurse, the CEO, or an outside consultant. In a physician group practice, having an in-house IT professional is not always possible. The committee chair might look internally to see if someone has the requisite IT knowledge, skills, interests, and also the time to devote to the project, but the chair also might look externally for a healthcare IT professional who might serve in a consultative role and help the committee direct its activities appropriately. Define Project Objectives and Scope of Analysis Once the project steering committee has been established, its first order of business is to clarify the charge to the committee and to define project goals. The charge describes the scope and nature of the committee's activities. The charge usually comes from senior leadership or a lead physician in the practice. Project goals should also be established and communicated in well-defined, measurable terms. What does the committee expect to achieve? What process will be used to ensure the committee's success? How will milestones be acknowledged? How will the committee communicate progress and resolve problems? What resources (such as time, personnel, and travel expenses) will the committee need to carry out its charge? What method will be used to evaluate system options? Will the committee consider contracting with a system developer to build a system or outsourcing the system to an application service provider? Or is the committee only considering systems available for purchase from a health care information systems vendor?

Once project goals are formulated, they can guide the committee's activities and also clarify the resources needed and the likely completion date for the project. Here are some examples of typical project goals: Assess the practice's information management needs and establish goals and objectives for the new system based on these needs. Conduct a review of the literature on EHR products and the market resources for these products. Investigate the top-ten EHR system products for the ambulatory care arena. Visit two to four health care organizations similar to ours that have implemented an EHR system. Schedule vendor demonstrations for times when physicians, nurses, and others can observe and evaluate without interruptions. As part of the goal-setting process, the committee should determine the extent to which various options will be explored. For example, the Valley Practice project steering committee decided at the onset that it was going to consider only EHR products available in the vendor community and ONC-certified. Users can be assured that certified EHR products meet certain standards for content, functionality, and interoperability.

The committee further stipulated that it would consider only vendors with experience (for example, five or more years in the industry) and those with a solid track record of system

installations (for example, twenty-five or more installations). The committee members felt the practice should contract with a system developer only if they were unable to find a suitable product from the vendor community—their rationale being that the practice wanted to be known as high-tech, high-touch. They also believed it was important to invest in IT personnel who could customize the application to meet practice needs and who would be able to assist the practice in achieving project and practice goals. Screen the Marketplace and Review Vendor Profiles Concurrently with the establishment of project goals, the project steering committee should conduct its first, cursory review of the EHR marketplace and begin investigating vendor profiles. Many resources are available to aid the committee in this effort. For example, the Valley Practice committee might obtain copies of recent market analysis reports—from research firms such as Gartner or KLAS—listing and describing the vendors that provide EHR systems for ambulatory care facilities. The committee might also attend trade shows at conferences of professional associations such as the Healthcare Information and Management Systems Society (HIMSS) and the American Medical Informatics Association (AMIA). (Appendix A provides an overview of the healthcare IT industry and describes a variety of resources available to healthcare organizations interested in learning about health care IT products, such as EHR systems, available in the vendor community.)

Determine System Goals Besides identifying project goals, the project steering committee should define system goals. System goals can be derived by answering questions such as, What does the organization hope to accomplish by implementing an EHR system? What is it looking for in a system? If the organization intends to transform existing care processes, can the system support the new processes? Such goals often emerge during the initial strategic planning process when the decision is made to move forward with the selection of the new system. At this point, however, the committee should state its goals and needs for a new EHR system in clearly defined, specific, and measurable terms. For example, a system goal such as “select a new EHR system” is very broad and not specific. Here are some examples of specific and measurable goals for a physician practice. Our EHR system should do the following:

Enable the practice to provide service to patients using evidence-based standards of care. Aid the practice in monitoring the quality and costs of care provided to the patients served. Provide clinicians with access to accurate, complete, relevant patient information, on-site and remotely. Improve staff member efficiency and effectiveness. More fully engage patients in their own care by providing patients with ready access to their test results, immunization records, patient education materials, and other aids. Enable the practice to manage chronic disease patient care more effectively. These are just a few of the types of system goals the project steering committee might establish as it investigates a new EHR for the organization. The system goals should be aligned with the strategic goals of the organization and should serve as measures of success throughout the system acquisition process.

Determine and Prioritize System Requirements Once the goals of the new system have been established, the project steering committee should begin to determine system requirements. These requirements may address everything from what information should be available to the provider at the point of care to how the information will be secured to what type of response time is expected. The committee may use any of a variety of ways to identify system requirements. One approach is to have a subgroup of the committee conduct focus-group sessions or small-group interviews with the various user groups (physicians, nurses, billing personnel, and support staff members). A second approach is to develop and administer a written or an electronic survey, customized for each user group, asking individuals to identify their information needs in light of their job role or function. A third is to assign a representative from each specific area to obtain input from users in that area. For example, the nurse on the Valley Practice project steering committee might interview the other nurses; the business office manager might interview the support staff members. System requirements may also emerge as the committee examines templates provided by consultants or peer institutions, looks at vendor demonstrations and sales material, or considers new regulatory requirements the organization must meet.

The committee may also use a combination of these or other approaches. At times, however, users do not know what they want or will need. Hence, it can be extremely helpful to hold product demonstrations, meet with consultants, or visit sites already using EHR systems so that those who will use or be affected by the EHR can see and hear what is possible. Whatever methods are chosen to seek users' information system needs, the end result should be a list of requirements and specifications that can be prioritized or ranked. This ranking should directly reflect the specific strategic goals and circumstances of the organization. The system requirements and priorities will eventually be shared with vendors or the system developer; therefore, it is important that they be clearly defined and presented in an organized, easy-to-understand format. For example, it may be helpful to organize the requirements into categories such as software (system functionality, software upgrades); technical infrastructure (hardware requirements, network specifications, backup, disaster recovery, security); and training and support (initial and ongoing training, technical support). These requirements will eventually become a major component of the RFP submitted to vendors or other third parties (discussed next).

Develop and Distribute the RFP or RFI Once the organization has defined its system requirements, the next step in the acquisition process is to package these requirements into a structure that a third party can respond to, whether that third party be a development partner or a health information systems vendor. Many health care organizations package the requirements into a request for proposal. The RFP provides the vendor with a comprehensive list of system requirements, features, and functions and asks the vendor to indicate whether its product or service meets each need. Vendors responding to an RFP are also generally required to submit a detailed and binding price quotation for the applications and services being sought.

RFPs tend to be highly detailed and are therefore time-consuming and costly to develop and complete. However, they provide the health care organization and each vendor with a comprehensive view of the system needed. Healthcare IT consultants can be extremely resourceful in assisting the organization with developing and packaging the RFP. An RFP for a major health care information system acquisition generally contains the following information (sections marked with an asterisk [*] are completed by the vendor; the other sections are completed by the organization issuing the RFP): Instructions for vendors: Proposal deadline and contact information: where and when the RFP is due; whom to contact with questions Confidentiality statement and instructions: a statement that the RFP and the responses provided by the vendor are confidential and are proprietary information Specific instructions for completing the RFP and any stipulations with which the vendor must comply in order to be considered Organizational objectives: type of system or application being sought; information management needs and plans Background of the organization: Overview of the facility: size, types of patient services, patient volume, staff composition, strategic goals of organization Application and technical inventory: current systems in use, hardware, software, network infrastructure System goals and requirements: goals for the system and functional requirements (may be categorized as mandatory or desirable and listed in priority order). Typically this section includes application, technical, and integration requirements. Increasingly, health care providers are interested in assessing and testing system usability. Incorporating scripted scenarios in the requirements section of the RFP that are based on existing workflow and business processes can provide meaningful information during the selection process (Corrao, Robinson, Swiernik, & Naeim, 2010; Eisenstein, Jurwishin, Kushniruk, & Nahm, 2011; IOM, 2011). Vendor qualifications: *general background of vendor, experience, number of installations, financial stability, list of current clients, standard contract, and implementation plan Proposed solutions: *how the vendor believes its product meets the goals and needs of the health care organization. Vendors may include case studies, results from system analysis projects, and other evidence of the benefits of its proposed solution. Criteria for evaluating proposals: how the healthcare organization will make its final decisions on product selection General contractual requirements: *warranties, payment schedule, penalties for failure to meet schedules specified in contract, vendor responsibilities, and so forth Pricing and support: *quote on cost of system, using standardized terms and forms The RFP may become the basis for a legally binding contract or obligation between the vendor and the solicitor, so it is important for both parties to carefully consider the wording of questions and the corresponding responses (AHIMA, 2007). RFPs are not the only means by which to solicit information from vendors. A second approach that is often used is the request for information. An RFI is less formal, considerably shorter than an RFP, and less time-consuming to develop. It is often used as part of the fact-finding process

to obtain basic information on the vendor's background, product descriptions, and service capabilities. Some health care organizations send out an RFI before distributing the RFP in order to screen out vendors whose products or services are not consistent with the organization's needs or to narrow the field of vendors to a manageable number. The RFI can serve as a tool in gathering background information on vendors' products and services and providing the project steering committee with a better sense of the health IT marketplace. How does one decide whether to use an RFP, an RFI, both, or neither during the system acquisition process? Several factors should be considered. Although time-consuming to develop, the RFP is useful in forcing a healthcare organization to define its system goals and requirements and prioritize its needs. The RFP also creates a structure for objectively evaluating vendor responses and provides a record of documentation throughout the acquisition process. System acquisition can be a highly political process; by using an RFP the organization can introduce a higher degree of objectivity into that process. RFPs are also useful data collection tools when the technology being selected is established and fully developed, when there is little variability between vendor products and services, when the organization has the time to fully evaluate all options, and when the organization needs strong contract protection from the selected vendor (DeLuca & Enmark, 2002). However, not all vendors may wish to submit a response to an RFI or RFP because of costs or suitability. There are also drawbacks to RFPs. In addition to taking considerable time to develop and review, they can become cumbersome and so detail oriented that they lose their effectiveness. For instance, it is not unusual to receive three binders full of product and service information from one vendor. If ten vendors respond to an RFP (about five is ideal), the project steering committee may be overwhelmed and find it difficult to wade through and differentiate among vendor responses. Having too much information to summarize can be as crippling to a committee in its deliberations as having too little.

Therefore a scaled-back RFP or an RFI might be a desirable alternative. An RFI might be used when the healthcare organization is considering only a small group of vendors or products or when it is still in the exploratory stages and has not yet established its requirements. Some facilities use an even less formal process consisting primarily of site visits and system demonstrations.

Regardless of the tool(s) used, it is important for the healthcare organization to provide sufficient detail about its current structure, strategic IT goals, and future plans so that the vendor can respond appropriately to its needs. Additionally, the RFP or RFI (or variation of either) should result in enough specific detail that the organization gets a good sense of the vendor—its services, history, vision, stability in the marketplace, and system or product functionality. The organization should be able to easily screen out vendors whose products are undeveloped or not yet fully tested (DeLuca & Enmark, 2002). Explore Other Acquisition Options In our Valley Practice case, the physicians and staff members opted to acquire an EHR system from the vendor community. Organizations such as Valley Practice often turn to the market for products that they will run on their own IT infrastructure. But there are times when they do not go to the market—they choose to leverage someone else's infrastructure (by contracting with an

application service provider or vendor who offers cloud computing services) or they build the application (by contracting with a system developer or using in-house staff members).

Option to Contract with Vendor for Cloud Computing Services In recent years, there has been a wider availability of high-speed or broadband Internet connections, more sophisticated vendor solutions, and a growing number of options for hosting software, hardware, and infrastructure via the Internet. These services are generally referred to as cloud computing, a general term that refers to the applications delivered as services over the Internet and the hardware and software in the data centers that provide those services. Vendors and companies may use different terms to describe cloud-based services. Common options include application service provider (ASP), software as a service (SaaS), infrastructure as a service, and platform as a service. The scope of services and payment methods also can vary considerably. However, cloud computing options generally require less upfront capital expenses, fewer IT staff members and resources, and greater scalability and access to analytic capabilities (Armbrust et al., 2010). Essentially the health care provider contracts with the vendor to host and maintain the clinical or administrative application and related hardware; the health care organization or provider simply accesses the system remotely over a network connection and pays the monthly or negotiated fees. Why might a healthcare organization consider contracting with a vendor in a cloud-based service arrangement rather than purchasing an EHR system (or other application) from a vendor? There are several reasons. First, the facility may not have the IT staff members needed to run or support the desired system. Hiring qualified personnel at the salaries they demand may be difficult, and retaining them may be equally challenging. Second, cloud-based options enable health care organizations to use clinical or administrative applications with fewer up-front costs and less capital. For a small physician practice, these financial arrangements can be particularly appealing. Because many vendors offer cloud-based services on fixed monthly fees or fees based on use, organizations are better able to predict costs. Third, by contracting with a vendor to host, manage, or support IT, the health care organization can focus on its core business and not get bogged down in IT support issues, although it may still have to deal with issues of system enhancements, user needs, and the selection of new systems. Other advantages are rapid deployment and 24/7 technical support. They also offer scalability and flexibility, so as the practice or organization grows or shrinks in size or volume, they pay only for the services used. Other benefits include upgrades that can be made once and applied across a network of users instantaneously; users can access services from any standardized device no matter their location; and a cloud-based network can easily accommodate changes in use (increase and decrease during certain periods). However, cloud computing services have some disadvantages and limitations that the health care organization should consider in its deliberations. Although rapid deployment of the application can be a tremendous advantage to an organization, the downside is the fact that the application will likely be a standard, off-the-shelf product, with little if any customization. This means that the organization has to adapt or mold its operations to the application rather than tailoring the application to meet the operational needs of the organization. A second drawback deals with technical support. Although technical support is generally available, it is unrealistic to think that the vendor's support personnel will have intimate knowledge of the organization and its

operations. Frustrations can mount when one lacks in-house IT technical staff members when and where they are needed. Third, health care providers have long been concerned about data ownership, security, and privacy—worries that increase when another organization hosts their clinical data and applications. How the vendor will secure data and maintain patient privacy should be clearly specified in the contract. Likewise, to minimize downtime, the vendor should have clear plans for backing up data, preventing disasters, and recovering data.

As the industry matures, we will likely see different variations and greater choices among organizations offering cloud-based services. A recent review of the literature found cloud computing used in six primary domains: (1) telemedicine and teleconsultation, (2) medical imaging, (3) public health and patients' self-management, (4) clinical information systems, (5) therapy, and (6) secondary use of data (Griebel et al., 2015). Additionally, cloud computing is designed to support cooperation, care coordination, and information sharing. The health care executive considering a move to cloud computing should carefully consider the type of application moving to the cloud (clinical, administrative) and the cloud service model that will be the most attractive economic option (Cloud Standards Customer Council, 2012). Health care executives should also thoroughly research the company and its products and consider factors such as company viability, target market, functionality, integration, implementation and training help desk support, security, pricing, and service levels. It is important to be able to trust the vendor and products and to choose systems and services wisely.

Option to Contract with a System Developer or Build In-House An alternative to purchasing or leasing a system from a vendor is to contract with a developer to design a system for your organization. The developer may be employed in-house or by an outside firm. Working with a system developer can be a good option when the health care organization's needs are highly uncertain or unique and the products available on the market do not adequately meet these needs. Developing a new or innovative application can also give the organization a significant competitive advantage. The costs and time needed to develop the application can be significant, however. It is also important to consider the long-term costs. If the developer leaves, how difficult would it be to hire and retain someone to support and maintain the system? How will problems with the system be addressed? How will the application be upgraded? What long-term value will it bring the organization? These are a few of the many questions that should be addressed in considering this option. It is rare for a healthcare organization to develop its own major clinical information system. Evaluate Vendor Proposals In the Valley Practice case, the project steering committee decided to focus its efforts at first on considering only EHR products available for purchase or lease in the vendor community. The committee came to this conclusion after its initial review of the EHR marketplace. Committee members felt there were a number of vendors whose products appeared to meet practice needs. They also felt strongly that in-house control of the EHR system was important to achieving the practice goal of becoming a high-tech, high-touch organization, because they wanted to be able to customize the application. Realizing this, the committee had budgeted for an IT director and an IT support staff member. Members felt that the long-term cost savings from implementing an EHR would justify these two new positions.

Develop Evaluation Criteria The project steering committee at Valley Practice decided to go through the RFP process. It developed criteria by which it would review and evaluate vendor proposals. Criteria were used to grade each vendor's response to the RFP. Grading scales were established so the committee could accurately compare vendors' responses. These grading scales involved assigning more weight to required items and less weight to those deemed merely desirable. Categories of “does not meet requirement,” “partially meets requirement,” and “meets requirement” were also used. RFP documents were compared item by item and side by side, using the grading scales established by the committee (see Table 5.1 for sample criteria). To avoid information overload, a common condition in the RFP review process, the project steering committee focused on direct responses to requirements and referred to supplemental information only as needed. Summary reports of each vendor's response to the RFP were then prepared by a small group of committee members and distributed to the committee at large. Table 5.1 Sample criteria for evaluation of RFP responses

Type of Application: Electronic Health Record System Vendor Name: The EHR Company Criteria Meets Requirement Partially Meets Requirement Does Not Meet Requirement 1. Alerts user to possible drug interactions x 2. Provides user with list of alternate drugs x 3. Advises user on dosage based on patient's weight x 4. Allows user to enter over-the-counter medications x (on different screen) 5. Allows easy printout of prescriptions x Hold Vendor Demonstrations During the vendor review process, it is important to host vendor system demonstrations. The purpose of these demonstrations is to give the members of the health care organization an opportunity to (1) evaluate the look and feel of the system from a user's point of view, (2) validate how much the vendor can deliver of what has been proposed, (3) conduct system usability testing, and (4) narrow the field of potential vendors. It is often a good idea to develop demonstration scripts and require all vendors to present their systems in accordance with these scripts. Scripts generally reflect the requirements outlined in the RFP and contain a moderate level of detail. For example, a script might require demonstrating the process of registering a patient or renewing a prescription. The use of scripts can ensure that all vendors are evaluated on the same basis or functionality. At the same time, it is important to allow vendors some creativity in presenting their product and services. When scripts are used, they need to be provided to vendors at least one month in advance of the demonstration, and vendors and health care organizations must adhere to them. It is also important to have end users carry out certain functions or procedures that they would usually do in the course of the day using the vendor's system. You might ask them to complete a system usability survey after they have had a chance to use the system and practice on several records. Figure 5.2 is an example of a system usability scale questionnaire in which end users are asked to respond to each item using a Likert scale of 1 to 5, from strongly disagree to strongly agree. Criteria should be

developed and used in evaluating vendor demonstrations, just as they are for reviewing vendor responses to the RFP. Figure 5.2 System usability scale questionnaire

Source: Brooke (1996); Lewis and Sauro (2009).

Make Site Visits and Check References After reviewing the vendors' RFPs and evaluating their product demonstrations, it is advisable to make site visits and check references. By visiting other facilities that use a vendor's products, the health care organization should gain additional insight into what the vendor would be like as a potential partner. It can be extremely beneficial to visit organizations similar to yours. For instance, in the Valley Practice case, representatives from key practice constituencies decided to visit other ambulatory care practices to see how a specific system was being used, the problems that had been encountered, and how these problems had been addressed.

How satisfied are the staff members with the system? How responsive has the vendor been to problems? How quickly have problems been resolved? To what degree has the vendor delivered on its promises? Hearing answers to such questions firsthand from a variety of users can be extremely helpful in the vendor review process.

Other Strategies for Evaluating Vendors A host of other strategies can be used to evaluate a vendor's reputation and product and service quality. Organizational representatives might attend vendor user group conferences, review the latest market reports, consult with colleagues in the field, seek advice from consultants, and request an extensive list of system users. Prepare a Vendor Analysis Throughout the vendor review process, the project steering committee members should have evaluation tools in place to document their impressions and the views of others in the organization who participate in any or all of the review activities (review of RFPs, system demonstrations, site visits, reference checks, and so forth). The committee should then prepare vendor analysis reports that summarize the major findings from each of the review activities. How do the vendors compare in reputation? In the quality of their product? In quality of service? How do the systems compare in terms of their initial and ongoing costs? To what degree is the vendor's vision for product development aligned with the organization's strategic IT goals?

Conduct a Cost-Benefit Analysis The final analysis should include an evaluation of the cost and benefits of each proposed system. Figure 5.3 shows a comparison of six vendor products. Criteria were developed to score and rank each vendor's system. As the figure illustrates, the selection committee ranked vendor 4 the top choice. Figure 5.3 Cost-benefit analysis

The capital cost analysis may include software, hardware, network or infrastructure, third-party, and internal capital costs. The total cost of ownership should factor in support costs and the

costs of the resources needed (including personnel) to implement and support the system. Once the initial and ongoing costs are identified, it is important to weigh them against the benefits of the systems being considered. Can the benefits be quantified? Should they be included in the final analysis?

Prepare a Summary Report and Recommendations Assuming the capital cost analysis supports the organization in moving forward with the project, the project steering committee should compile a final report that summarizes the process and results from each major activity or event. The report may include these elements:

System goals and criteria Process used Results of each activity and conclusions Cost-benefit analysis Final recommendation and ranking of vendors It is generally advisable to have two or three vendors in the final ranking, in the event that problems arise with the first choice during contract negotiations, the final step in the system acquisition process.

Conduct Contract Negotiations The final step of the system acquisition process is to negotiate a contract with the vendor. This, too, can be time-consuming, and therefore it is helpful to seek expert advice from business or legal advisors. The contract outlines expectations and performance requirements, who is responsible for what (for example, training, interfaces, support), when the product is to be delivered (and vendor financial liability for failing to deliver on time), how much customization can be performed by the organization purchasing the system, how confidentiality of patient information will be handled, and when payment is due. The devil is in the details, and although most technical terms are common among vendors, other language and nuances are not. Establish a schedule and a pre-implementation plan that includes a timeline for implementation of the applications and an understanding of the resource requirements for all aspects of the implementation, including cultural change management, workflow redesign, application implementation, integration requirements, and infrastructure development and upgrades, all of which can consume substantial resources. Project Management Tools Throughout the course of the system acquisition project, a lot of materials will be generated, many of which should be maintained in a project repository. A project repository serves as a record of the project steering committee's progress and activities. It includes such information and documents as minutes of meetings, correspondence with vendors, the RFP or RFI, evaluation forms, and summary reports. This repository can be extremely useful when there are changes in staff members or in the composition of the committee and when the organization is planning for future projects. The project manager should assume a leadership role in ensuring that the project repository is established and maintained. Following is a sample of the typical contents of a project repository.

Perspective Sample Contents of a Project Repository Committee charge and membership (including contact information) Project objectives (including method that will be used to select system) System goals Timeline of committee activities (for example, Gantt chart) System requirements (mandatory and desirable) RFP RFI Evaluation forms for Responses to RFPs Vendor demonstrations Site visits Reference checks Summary report and recommendations Project budget and resources Managing the various aspects of the project and coordinating activities can be a challenging task, particularly in large organizations or when a lot of people are involved and many activities are occurring simultaneously. It is important that the project manager helps those involved to establish clear roles and responsibilities for individual committee members, set target dates, and agree on methods for communicating progress and problems. Many project management tools exist that can be useful here. For example, a simple Gantt chart (Figure 5.4) can document project objectives, tasks and activities, responsible parties, and target dates and milestones. A Gantt chart can also display a graphical representation of all project tasks and activities, showing which ones may occur simultaneously and which ones must be completed before another task can begin. Other tools enable one to allocate time, staff members, and financial resources to each activity. (Gantt charts and other timelines can be created with software programs such as Visio or Microsoft Project. A discussion of these tools is beyond the scope of this book but can be found in most introductory project management textbooks.) It is important to clearly communicate progress within the project steering committee and to individuals outside the committee. Senior management should be kept apprised of project progress, budget needs, and committee activities. Regular updates should be provided to senior management as well as other user groups involved in the process. Communication can be formal and informal—everything from periodic update reports at executive meetings to facility newsletter briefings to informal discussions at lunch.

Things That Can Go Wrong Managing the system acquisition process successfully requires strong and effective leadership, planning, organizational, and communication skills. Things can and do go wrong. Upholding a high level of objectivity and fairness throughout the acquisition process is important to all parties involved. Failing to do so can hamper the overall success of the project. Following is a list of some common pitfalls in the system acquisition process, along with strategies for avoiding them.

Failing to manage vendor access to organizational leadership. The vendor may schedule private time with the CEO or a board member in the hope of influencing the decision and bypassing the project steering committee entirely. It is not unusual to hear that processes or decisions have been altered after the CEO has been on a golf outing or taken a trip to the Super Bowl with a vendor. The vendor may persuade the CEO or a board member to overturn or question the decisions of the project steering committee, crippling the decision process. Hence, it should be clearly communicated to all parties (senior management, board, and vendor) that all vendor requests and communication should be channeled through the project steering committee. Failing to keep the process objective (getting caught up in vendor razzle-dazzle). Related to the need to manage vendor access to decision makers is the need to keep the process objective. The project steering committee should assume a leadership role in ensuring that there are clearly defined criteria and methods for selecting the vendor. These criteria and methods should be known to all the parties involved and should be adhered to. In addition, it is important that the committee and other organizational representatives remain unbiased and not get so impressed with the vendor's razzle-dazzle (in the form, for example, of exquisite dinners or fancy gadgets) that they fail to assess the vendor or the product objectively. Consider the politics of a situation but do not allow the vendor to drive the result—take the high road to avoid the appearance of favoritism. Overdoing or undergoing the RFP. Striking a balance between too much and too little information and detail in the RFP and also determining how much weight to give to the vendors' responses to the RFP can be challenging. The project steering committee should err on the side of being reasonable—that is, the committee should include enough information and detail that the vendor can appropriately respond to the organization's needs and should give the vendor responses to the RFP appropriate consideration in the final decision. Organizations should also be careful that they do not assign either too much or too little weight to the RFP process. Failing to involve the leadership team and users extensively during the selection process. A sure way to disenchant the leadership team and end users is to fail to involve them adequately in the system acquisition process. There should be ample opportunity for people at all levels of the organization who will use or be affected by the new information system to have input into its selection. Involvement can include everything from being invited and encouraged to attend vendor presentations during uninterrupted time to being asked to join a focus group in which user input is sought. It is important that the project steering committee seek input and involvement throughout the acquisition process, not simply at the end when the decision is nearly final. Far too often information system projects fail because the leadership team and end users were not actively involved in the selection of the new system. Involving people from the very beginning helps them to be an integral part of the process and the solution. Turning negotiations into a blood sport. You want to negotiate a fair deal with the vendor and not leave the vendor's people feeling as though they have just been “beaten” in a contest. A lopsided deal results in a disenchanted partner and can create a bad climate. Understand what is required from all parties and establish performance criteria for payments and remedies for nonperformance. It is important to form a healthy, respectful long-term relationship with the vendor. These are just a few of the many issues that can arise during the system acquisition process that the health care executive should be aware of. Failing to appropriately address these issues

can interfere with the organization's ability to successfully select and implement a system that will be adopted and widely used.

Information Technology Architecture Congruent with the selection process, it is important for health care executives to have an understanding of the underlying IT architecture. In other words, how does the organization choose among different technologies and ultimately bring them together into a cohesive set of healthcare information systems? This section addresses this important question by examining health care information system architecture.

An organization's information systems require that a series of core technologies come together, or work together as whole, to meet the IT goals of the organization. The way that core technologies, along with the application software, come together should be the result of decisions about what information systems are implemented and used within the organization and how they are implemented and used. For example, the EHR system or the patient accounting system with which users ultimately interact involves not just the application software but also the network, servers, security systems, and so forth that all come together to make the system work effectively. This coming together should never be a haphazard process. It should be engineered.

In discussing IT architecture, we will cover several topics:

A definition of architecture Architecture perspectives Architecture examples Observations about architecture A Definition of Architecture A design and a blueprint guide the coming together of a house. The coming together of information systems is guided by information technology architecture. For the house, the development of the blueprint and the design is influenced by the builder's objectives for the house (is it to be a single-family house or an apartment building, for example) and the desired properties of the house (energy efficient or handicap accessible, for example). For an organization's information systems, the development of an architecture is influenced by the organization's objectives (EHRs that span multiple hospitals, for example) and the systems' desired properties (efficient to support and having a high degree of application integration, for example).

Following the design and the blueprints, the general contractor, plumbers, carpenters, and electricians use building materials to create the house. Following the architecture for the organization's information systems, the IT staff members and the organization's vendors implement the core technologies and application software and integrate them to create the information systems.

IT architecture consists of concepts, strategies, and principles that guide an organization's technology choices and the manner in which the organization integrates and manages these choices. For example, an organization's architecture discussion concludes that the organization should use industry standard technology. This decision reflects an organizational belief that standard technology will have a lower risk of obsolescence, be easier to support, and be available from a large number of IT vendors that use standard technology. Guided by its architecture decision, the organization chooses to implement networks that conform to a specific standard network protocol and decides to use the Windows operating system for its workstations. Two additional terms are sometimes used either as synonyms for or in describing architecture: platform and infrastructure. In this text, however, we adhere to accepted distinctions among these three terms. For example, you might hear IT personnel say that “our systems run on a Microsoft, HP, and Cisco platform.” Platforms are the specific vendors and technologies that an organization chooses for its information systems. You might hear of a Windows platform or web-based platform. Platform choices should be guided by architecture discussions. You might also hear IT personnel talk about the infrastructure of the healthcare information system. Infrastructure refers to the entire base of IT that an organization uses—its networks, servers, workstations, and so on. Organizations choose specific platforms from specific vendors to implement their infrastructure. An organization's infrastructure can have several platforms—CISCO for networks, Microsoft for workstations, and so on. Although infrastructure is not vendor or technology specific, it is not quite as broad a term as architecture, which encompasses much more than specific technologies and networks.

In creating an infrastructure, an organization will implement platforms and be guided by its IT architecture.

Architecture Perspectives Organizations adopt various frames of reference as they approach the topic of architecture. This section will illustrate two approaches, one based on the characteristics and capabilities of the desired architecture and the other based on application integration.

Characteristics and Capabilities Glaser (2002, p. 62) defines architecture as “the set of organizational, management, and technical strategies and tactics used to ensure that the organization's information systems have critical, organizationally defined characteristics and capabilities.” For example, an organization can decide that it wants an information system that has characteristics such as being agile, efficient to support, and highly reliable. In addition, the organization can decide that its information systems should have capabilities such as being accessible by patients from their homes or being able to incorporate clinical decision support. If it wants high reliability, it will need to make decisions about fault-tolerant computers and network redundancy. If it wants users to be able to customize their clinical information screens, this will influence its choice of a clinical information system vendor. If it wants providers to be able to structure clinical documentation, it will need to make choices about natural language processing, voice recognition, and templates in its electronic medical record.

Architecture choices are guided by organizational decisions about the capabilities and characteristics that are desired of its information systems.

Application Integration Another way of looking at information systems architecture is to look at how applications are integrated across the organization. One often hears vendors talk about architectures such as best of breed, monolithic, and visual integration. Best of breed describes an architecture that enables each department to pick the best application it can find and that then attempts to integrate these applications by means of an interface engine that manages the transfer of data between these applications—for example, it can send a transaction with registration information on a new patient from the admitting system to the laboratory system.

Monolithic describes the architecture of a set of applications that all come from one vendor and that all use a common database management system and common user interface.

Visual integration architecture wraps a common browser user interface around a set of diverse applications. This interface enables the user, for example, a physician, to use one set of screens to access clinical data even though those data may come from several different applications.

This view of architecture is focused on the various approaches to the integration of applications: integration by sharing data between applications, integration by having all applications use one database, and integration by having an integrated access to data. This view does not address other aspects of architecture, for example, the means by which the organization might get information to mobile workers. Architecture Examples A few examples will help illustrate how architecture can guide IT choices. Each example begins with an architecture statement and then shows some choices about core technologies and applications and the approach to implementing them that might result from this statement.

Statement. We would like to deliver an EHR to our small physician practices that is inexpensive, reliable, and easy to support. To do this we will

Run the application from our computer room, reducing the need for practice staff members to manage their own servers and do tasks such as backups and applying application enhancements Run several practices on one server to reduce the cost Obtain a high-speed network connection, and a backup connection, from our local telephone company to provide good application performance and improve reliability Statement. We would like to have decision-support capabilities in our clinical information systems. To do this we will

Purchase our applications from a vendor whose product includes a very robust rules engine

Make sure that the rules engine has the tools necessary to author new decision support and maintain existing clinical logic Ensure that the clinical information systems use a single database with codified clinical data Statement. We want all of our systems to be easy and efficient to support. To do this we will

Adopt industry standard technology, making it easier to hire support staff members Implement proven technology—technology that has had most of the bugs worked out Purchase our application systems from one vendor, reducing the support problems and the finger-pointing that can occur between vendors when problems arise Observations about Architecture Organizations will often bypass the architecture discussion in their haste to “get the IT show on the road and begin implementing stuff.” Haste makes waste, as people say. It is terribly important to have thoughtful architecture discussions. There are many organizations, for example, that never took the time to develop thoughtful plans for integrating applications and that then discovered, after millions of dollars of IT investments, that this oversight meant that they could not integrate these applications or that the integration would be expensive and limited.

As we will see in Chapter Thirteen, the organizations that have been very effective in their applications of IT over many years have had a significant focus on architecture. They have realized that thoughtful approaches to agility, cost efficiency, and reliability have a significant impact on their ability to continue to apply technology to improve organizational performance. For example, information systems that are not agile can be difficult (or impossible) to change as the organization's needs evolve. This ossification can strangle an organization's progress. In addition, information systems that have reliability problems can lead an organization to be hesitant to implement new, strategically important applications—how can they be sure that this new application will not go down too often and impair their operations?

Organizational leadership must take time to engage in the architecture discussion. The health care executive does not need to be involved in deciding which vendor to choose to provide network switches. But he or she does need a basic understanding of the core technologies in order to help guide the formation of the principles and strategies that will direct that decision. In the following example, the application integration perspective on architecture (choosing among best of breed, monolithic, and visual integration) illustrates a typical architecture challenge that a hospital might face. Perspective Choosing the System Architecture A hospital has adopted a best-of-breed approach and, over the course of several years, has implemented separate applications that support the registration, laboratory, pharmacy, and radiology departments and the transcription of operative notes and discharge summaries. An interface engine has been implemented that enables registration transactions to flow from the registration system to the other systems.

However, the physicians and nurses have started to complain. To retrieve a patient's laboratory, pharmacy, and radiology records and transcribed materials, they have to sign into each of these

systems, using a separate username and password. To obtain an overall view of a patient's condition, they have to print out the results from each of these systems and assemble the different printouts. All of this takes too much time, and there are too many passwords to remember.

Moreover, the hospital would like to analyze its care, in an effort to improve care quality, but the current architecture does not include an integrated database of patient results.

The hospital has two emerging architectural objectives that the current architecture cannot meet:

Provide an integrated view of a patient's results for caregivers. Efficiently support the analysis of care patterns. To address these objectives, the hospital decides to implement a browser-based application that will do the following:

Gathers clinical data from each application and presents it in a unified view for the caregivers Supports the entry of one user ID and password that is synchronized with the user ID and password for each application In addition, the hospital decides to implement a database that receives clinical results from each of the applications and stores this data for access by query tools and analysis software.

To achieve its emerging objectives, the hospital has migrated from best-of-breed architecture to visual integration architecture. The hospital has also extended to visual integration architecture by adding an integrated database for analysis purposes.

In analyzing what would be the best architecture to meet its new objectives, the hospital considered monolithic architecture. It could meet its objectives by replacing all applications with one integrated suite of applications from one vendor. However, the hospital decided that this approach would be too expensive and time-consuming. Besides, the current applications (laboratory, pharmacy, and radiology) worked well; they just weren't integrated. The monolithic architecture approach to integration was examined and discarded. Summary Acquiring or selecting a new clinical or administrative information system is a major undertaking for a healthcare organization. It is important that the process be managed effectively. Although the time and resources needed to select a new system will vary depending on the size, complexity, and needs of the organization, certain fundamental issues should be addressed in any system acquisition project.

This chapter discussed the various activities that occur in the system acquisition process. These activities were presented in the context of a multi physician group practice that wishes to replace its current paper record with an EHR system by acquiring a system from a reputable vendor. Key activities in the system selection process are (1) establishing a project steering committee and appointing a strong project manager to lead the effort, (2) defining project

objectives, (3) screening the vendor marketplace, (4) determining system goals, (5) establishing system requirements, (6) developing and administering an RFP or RFI, (7) evaluating vendor proposals, and (8) conducting a cost-benefit analysis on the various options. Other options such as contracting with a vendor for cloud computing service arrangements or a system developer were also discussed. This chapter presented some of the issues that can arise during the system selection process and outlined the importance of documenting and communicating project activities and progress. Finally, the chapter concluded with a general overview of IT architecture and its relevance in making IT investment decisions.

References American Health Information Management Association (AHIMA). (2007). The RFP process for EHR systems (updated). Retrieved February 2013 from http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_047961.hcsp?dDocName= bok1_047961 Armbrust, M., Fox, A., Griffith, R. Joseph, A. D., Katz, R., Konwinski, A., . . . & Zaharia, M. (2010). A view of cloud computing. Communications of the ACM, 53(4), 50–58. Brooke, J. (1996). SUS: A “quick and dirty” usability scale. In P. W. Jordan, B. Thomas, I. L. McClelland, & B. A. Weerdmeester (Eds.), Usability evaluation in industry (pp. 189–194). London, UK: Taylor & Francis. Cloud Standards Customer Council. (2012). Impact of cloud computing on healthcare. Retrieved from http://www.cloud-council.org/deliverables/CSCC-Impact-of-Cloud-Computing-on-Healthcare.pdf Corrao, N. J., Robinson, A. G., Swiernik, M. A., & Naeim, A. (2010). Importance of testing for usability when selecting and implementing an electronic health or medical record system. Journal of Oncology Practice, 6(3), 120–124. DeLuca, J., & Enmark, R. (2002). The CEO's guide to health care information systems (2nd ed.). San Francisco, CA: Jossey-Bass. Eisenstein, E. L., Jurwishin, D., Kushniruk, A. W., & Nahm, M. (2011). Defining a framework for health information technology evaluation. Studies in Health Technology and Informatics, 164, 94–99. Glaser, J. (2002). The strategic application of information technology in health care organizations (2nd ed.) San Francisco, CA: Jossey-Bass. Griebel, L., Prokosch, H., Kopcke, F., Toddenroth, D., Christoph, J., Leb, I., Engel, I., & Sedlmayr, M. (2015). A scoping review of cloud computing in healthcare. BMC Medical Informatics and Decision Making, 15, 17, 1–16. Institute of Medicine (IOM). (2011). Health IT and patient privacy: Building safer systems for better care. Washington, DC: National Academies Press. Jones, S. S., Koppel, R., Ridgley, M. S., Palen, T., Wu, S., & Harrison, M. I. (2011, Aug.). Guide to reducing unintended consequences of electronic health records. Rockville, MD: Agency for Healthcare Research and Quality. Lewis, J. R., & Sauro, J. (2009). The factor structure of the system usability scale. In Proceedings of the Human Computer Interaction International Conference (HCII 2009), San Diego, CA.

Oz, E. (2012). Management information systems: Instructor edition (6th ed.). Boston, MA: Course Technology. Wager, K. A., & Lee, F. W. (2006). Introduction to healthcare information systems. In M. Johns (Ed.), Health information management technology: An applied approach (2nd ed.). Chicago, IL: American Health Information Management Association.