Health Care Information

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 an application service provider (ASP). An ASP is a company that deploys, hosts, and manages one or more clinical or administrative information systems through centrally located servers (generally via the Internet), often on a fixed, per-use basis or on a subscription basis. 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 7.1). Each phase has a number of tasks that need to be performed. In this chapter we focus on the first two phases; Chapter Eight focuses on the last two.

c7-fig-0001 — **Figure 7.1.** Systems development life cycle

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 environment 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, where 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 an ASP? A large majority of health care organizations purchase a system from a vendor or at least look first at the systems available on the market. 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 workflow and process analyses, installing the new system, testing the system, training staff, converting data, and preparing the organization and staff 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 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. Although support costs can vary widely from system to system, in most industries up to 80 percent of the IS budget is spent on maintenance (Oz, 2012). The major reason for this significant proportion is that support is the longest phase in a system’s life cycle.

Moreover, maintaining and supporting the new system is not enough. Health care executives and boards 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 multiphysician primary care practice.

What process should the practice use to select the EHR? Should it purchase a system from a vendor, contract with an application service provider, 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 the 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 (Exhibit 7.1), relating them to the multiphysician 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 a hospital.

CASE STUDY

Acquiring an EHR System

Valley Practice provides patient care services at three locations, all within a fifteen-mile radius, and serves nearly 100,000 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, 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 current paper-based medical record with an EHR system. Such a system should enable providers to care for patients using up-to-date, complete, accurate information, anywhere, anytime.

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 both the hospital and its ambulatory care clinics. Of all the physicians at Valley Practice, Dr. Brown has had the most experience using an EHR. She has been a vocal advocate for implementing an EHR and believes it is essential to enabling the facility to achieve its strategic goals. Dr. Brown contacted the Regional Extension Center (REC) in the community for assistance with the initiative.

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. Dr. Brown suggested that the committee work with the REC to guide committee members through the system acquisition process. The physician partners approved this request, and the committee made arrangements for a representative from the REC to work with them on the selection process.

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 expressed concern that there is a flurry of vendors offering EHR-type products without a solid track record.

Dr. Marcus felt strongly that the EHR system needed to enable providers to access patient information from any of Valley Practice’s three sites and from their homes. He also spoke of the need for the system to provide health maintenance reminders, drug interactions, and access to clinical practice guidelines or standards of care. The practice also intends to take advantage of the CMS EHR Incentive Program and achieve meaningful use. Dr. Marcus is interested in exploring what opportunities are available for health information exchange within the region. He envisions that the practice may eventually partner with specialists, hospitals, and other key stakeholders in the community to provide coordinated care across the continuum. 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 from only 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 upon, 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, and a third with the physicians. Ms. Moore, the consultant, conducted the focus groups, using a semistructured 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 an EHR system. 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 request for proposal (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.

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, where a CIO is employed, the CIO would likely be involved in the effort and 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 or nursing informatics officers, these individuals bring to the project a clinical perspective as well as an understanding of IT and information management processes. 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.

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, along with a representative from the Regional Extension Center. 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 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 staffs.

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 such as Valley Practice, having an in-house IT professional is rare. The committee chair might look internally to see if someone has the requisite IT knowledge, skills, and interests and also the time to devote to the project, but also might look externally for a health care IT professional who might serve in a consultative role and help the committee direct its activities appropriately. In this case, the REC specialist may be able to provide both the technical and system selection expertise to assist Valley Practice in the acquisition process.

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 certified by the ONC EHR. As discussed in Chapter Six, to achieve meaningful use, health care provider organizations must use certified EHR products. A listing of certified projects are available on the Office of the National Coordinator for Health Information Technology web site. 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 health care IT industry and describes a variety of resources available to health care 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

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 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). 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. 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 request for proposal (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 (RFP). 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. Health care 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 both 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 vendor believes its product meets the goals and needs of the health care organization. Vendor 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 health care organization will make its final decisions on product selection.
General contractual requirements: *such as 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 (RFI). 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 in providing the project steering committee with a better sense of the health IT market place. 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 health care 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 due to costs or suitability.

There are also drawbacks to RFPs. Besides taking considerable time to develop and review, they can become cumbersome, 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 health care 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 health care organization to provide sufficient detail about its current structure, strategic IT goals, and future plans 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 opted to acquire an EHR system from the vendor community. Organizations like 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 they build the application (by contracting with a system developer or using in-house staff).

Contract with an Application Service Provider

In recent years, with wider availability of high-speed or broadband Internet connections, more sophisticated vendor solutions, and a growing number of options for hosting software, the application service provider (ASP) approach has emerged as an alternative to buying, installing, and maintaining information systems. These services may be offered via “cloud” computing. Cloud computing is a general term that refers to both the applications delivered as services over the Internet and the hardware and software in the data centers that provide those services. An ASP is an organization with whom health care providers contract on a subscription basis to deliver an application and provide the associated services to support it. It’s somewhat analogous to the option of leasing rather than purchasing a car. ASPs are also similar in concept to the shared-systems option used by many hospitals in the 1960s and 1970s, when they could not afford or did not have the IT staff available in-house to run and support software applications and hardware. In essence, another organization houses and maintains 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. It is worth noting that some ASPs do not physically host the application but instead contract with a third-party data center to do so (Fortin & MacDonald, 2006). Health information exchange organizations could serve as ASPs as they mature and expand their capabilities.

Why might a health care organization consider contracting with an ASP 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 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, ASPs typically 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 ASPs offer fixed monthly fees or fees based on usage, organizations are better able to predict costs. Third, by contracting with an ASP, 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 to using ASPs 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.

ASPs also 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 from an ASP, it is unrealistic to think that the ASP’s support personnel will have intimate knowledge of the organization and its operations. Frustrations can mount when one lacks in-house IT technical staff 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 ASP will secure data and maintain patient privacy should be clearly specified in the contract. Likewise, to minimize downtime, the ASP should have clear plans for backing up data, preventing disasters, and recovering data.

First Consulting prepared a report for the California HealthCare Foundation outlining developments, benefits, challenges, issues, and concerns related to the ASP model for ambulatory clinical applications (Fortin & MacDonald, 2006). It suggests health care leaders ask themselves four important questions in deciding whether an ASP approach is the right choice for their organization:

How will the application fit into the organization’s overall IT plans?
To what extent can the organization support locally installed software?
How willing is the organization to have another organization host a clinical application?
What financial resources does the organization have (Fortin & MacDonald, 2006, p. 15)?

As the industry matures, we will likely see different variations and greater choices among organizations serving as ASPs. The health care executive considering whether an ASP is the right choice should 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 ASP and to choose one wisely.

Contract with a System Developer or Build In-House

A second alternative to purchasing 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. Should the developer leave, 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 health care 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 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 7.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 7.1.** Sample criteria for evaluation of RFP responses

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 both vendors and health care organization must adhere to them. It is also important to have end-users carry out certain functions or procedures that they would normally 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 7.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.

c7-fig-0002 — **Figure 7.2.** System usability scale questionnaire

*Source:* Brooke, 1996; Lewis & Sauro, 2009.

Criteria should be developed and used in evaluating vendor demonstrations, just as they are for reviewing vendor responses to the RFP.

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. The Regional Extension Center specialist also provided useful information to them.

How satisfied are the staff 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 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 7.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.

c7-fig-0003 — **Figure 7.3.** Cost-benefit analysis

*Source:* Partners HealthCare.

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

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 a time-consuming process, 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 between vendors, other language and nuances are not. Establish a schedule and a preimplementation 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.

CHAPTER 7
System Acquisition

SYSTEM ACQUISITION: A DEFINITION