Chapter 4 Information Systems to Support Population Health Management
To be able to understand the data and information needs of health systems in managing population health effectively under value-based payment models.
To be able to discuss key health IT tools and strategies for population health management including EHRs, registries, risk strati�ication, patient engagement, and outreach, care coordination and management, analytics, health information exchange, and telemedicine and telehealth.
To be able to discuss the application and use of data analytics to monitor, predict, and improve performance.
The enactment of the Affordable Care Act (ACA) brought about sweeping legislation intended to reduce the numbers of uninsured and make health care accessible to all Americans. It also ushered in an era in which changing reimbursement and care delivery models are driving providers from the current fragmented system focused on volume-based services to an outcomes orientation. As a result, the health care system now taking shape is one in which value-based payment models �inancially reward patient-centered, coordinated, accountable care.
Against this backdrop, providers’ increasing use of evidence-based medicine and growing capabilities in managing volumes of clinical evidence through sophisticated health IT systems will mean that treatments can be tailored for the individual and interventions can be made earlier to keep patients well. Furthermore, patient engagement is fast becoming a critical component in the care process, particularly in the area of population health management (PHM).
Health care providers’ interest in improving population health appears to be increasing because of the sudden ubiquity of the phrase, because many are participating in accountable care organizations (ACOs), and because even hospitals not participating in an ACO increasingly have incentives to reduce their number of potentially unavoidable admissions, readmissions, and emergency department visits (Casalino, Erb, Joshi, & Shortell, 2015).
In this chapter we’ll not only seek a common understanding of PHM but also explore how the advent of shared accountability �inancial arrangements between providers and purchasers of care has created signi�icant focus on PHM. We’ll also review the core processes associated with accountable care and examine the strategic IT investments and data management capabilities required to support population health management and enable a successful transition from volume-based to value-based care.
4.1 PHM: Key to Success Although the ACO model is still new and evolving, approximately 750 ACOs are in operation today, covering some 23.5 million lives under Medicare, Medicaid, and private insurers. Although not all ACOs have demonstrated success in delivering better health outcomes at a lower cost, many have achieved promising results (Houston & McGinnis, 2016). As such, signi�icant ACO growth is expected. In fact, it is predicted that upward of 105 million people will be covered by an ACO by 2020 (Leavitt Partners, 2015).
Similarly, although the industry’s move to value-based payment is also in its early stages, value-based contracts are expected to substantially increase throughout the next decade. CMS has a stated goal that 50 percent of Medicare payments will be tied to alternative payment models by the end of 2018 (US DHHS, 2015). In fact, the projected impact of MACRA, which we discussed in Chapter One (c01.xhtml) , on the adoption of value-based payment models is expected to rival the impact of Meaningful Use on adoption of EHRs. In addition, the substantial payment reform activity at the federal level is paralleled by private insurers’ efforts to support value-based payment and new models of care. For example, Aetna expects that 75 percent of its contracts will be value-based by 2020 (Jaspen, 2015).
These trends will accelerate the demand for services and technology that enable health systems and other organizations (health plans, Medicaid, community-based organizations, employers, and so forth) to jointly manage the health and care of populations—either as an ACO or in an ACO-like fashion. Although diverse, these organizations will all have a common need to improve operational ef�iciency, drive better patient outcomes while reducing the overall cost of care, and effectively engage consumers in managing their health and care.
Although the new reimbursement system is still taking shape, it’s clear that population health management will become a required core competency for provider organizations in a post fee-for-service payment environment (Institute for Health Technology Transformation, 2012).
Understanding Population Health Management Population health as a concept �irst appeared in 2003 when David Kindig and Greg Stoddart (2003) de�ined it as “the health outcomes of a group of individuals, including the distribution of such outcomes within the group” (p. 380).
It is important to note that medical care is only one of many factors that affect those outcomes. Other factors include public health interventions; aspects of the social environment (income, education, employment, social support, and culture); the physical environment (urban design, clean air and water); genetics; and individual behavior (Institute for Health Technology Transformation, 2012). “Improving the health of populations” was later identi�ied as one element in the Institute for Healthcare Improvement’s triple aim for improving the US health care system, along with improving the individual experience of care and reducing the per capita cost of care (Berwick, Nolan & Whittington, 2008, p. 759).
Today, population health management comprises the proactive application of strategies and interventions to de�ined groups of individuals (e.g., diabetics, cancer patients with tumor regrowth, the elderly with multiple comorbidities) to improve the health of individuals within the group at the lowest cost. PHM interventions are designed to maintain and improve people’s health across the full continuum of care—from low-risk, healthy individuals to high-risk individuals with one or more chronic conditions (Felt-Lisk & Higgins, 2011). PHM also seeks to minimize the need for expensive encounters with the health care system, such as emergency department visits, hospitalizations, imaging tests, and procedures. This not only lowers costs but also rede�ines health care as an activity that encompasses far more than sick care, because it systematically addresses the preventative and chronic care needs of every patient—not just high-risk patients who generate the majority of health care costs (Institute for Health Technology Transformation, 2012).
Although population health can also mean the health of the entire population in a geographic area, the population health efforts most health systems and ACOs are undertaking are aimed at providing better preventive and medical care for the “population” of patients “attributed” to their organizations by Medicare, Medicaid, or private health insurers (Casalino et al., 2015).
New Care Delivery and Payment Models: The Link to PHM As we know, historically, there has been a lack of accountability for the total care of patients, the outcomes of their treatment, and the ef�iciency with which health resources are used. The fact that health care services are paid primarily on a fee-for-service basis has contributed to the fragmentation and lack of accountability. Fee-for-service emphasizes the provision of health services by individual hospitals or providers rather than care that is coordinated across providers to address the patient’s needs. Providers are rewarded for volume and for conducting procedures that are often more complex, when simpler, lower-cost, better methods may be more appropriate (Guterman & Drake, 2010).
Value-based care is emerging as a solution to address rising health care costs, clinical inef�iciency and duplication of services, and to make it easier for people to get the appropriate care they need. As the federal government continues to test and implement several new payment models designed to achieve optimal health outcomes at a sustainable cost, commercial insurers are also partnering with health care providers in various arrangements that similarly seek to reward value rather than volume of services.
As discussed in Chapter One (c01.xhtml) , two popular models of delivery system reform are the patient-centered medical home (PCMH) and the ACO. The PCMH emphasizes the central role of primary care and care coordination, with the vision that every person should have the opportunity to easily access high-quality primary care in a place that is familiar and knowledgeable about his or her health care needs and choices. The ACO emphasizes the urgent need to think beyond patients to populations, providing a vision for increased accountability for performance and spending across the health care system (Patient-Centered Primary Care Collaborative, 2011). Both models rely on health care organizations and physicians providing coordinated and integrated care in an evidence-based, cost-effective way. This, of course, has signi�icant implications for an organization’s ability to manage information effectively.
In conjunction with new models of care are new or modi�ied forms of payment for health care services, which are being piloted in various communities around the nation. These include bundled payments, pay for performance, shared savings programs, capitation or global payment, and episode-of-care payments.
Bundled payments may take different forms such as making a single payment for hospital and physician services instead of separate payments, bundling payments for inpatient and post-acute care, or paying based on diagnosis instead of treatment. Bundled payments are often applied to surgical procedures such as hip replacements. Pay-for-performance (P4P) programs reward hospitals, physician practices, and other providers with �inancial and non�inancial incentives based on performance on select measures. These performance measures can cover various aspects of health care delivery: clinical quality and safety, ef�iciency, patient experience, and health information technology adoption. Most P4P programs, however, are still a bonus to a fee-for-service model (Miller, 2011). An integral part of the ACA, shared savings programs are intended to reward providers by paying them a bonus that is explicitly connected to the amount by which they reduce the total cost of care compared to expected levels. Capitation or global payment places full risk with the provider organization; the provider is responsible for the costs of all care that a patient receives. An episode-of-care payment system would pay the provider organization a single payment for all of the services associated with a hospitalization or other episode of acute care, such as a heart attack, including inpatient and post-acute care (Miller, 2011).
The revised payments associated with these programs signal the federal government’s most all-encompassing effort thus far to distribute risk and hold providers �inancially accountable for the quality of care they deliver. Although an in-depth discussion of these and other proposed payment reform systems is beyond the scope of this book, the following resources can provide a wealth of detailed information on health care payment reform initiatives:
Centers for Medicaid & Medicare Services (www.CMS.gov (http://www.CMS.gov) )
Healthcare Financial Management Association (www.hfma.org (http://www.hfma.org) )
American College of Healthcare Executives (www.ache.org (http://www.ache.org) )
Progress to Date: PCMHs Growing support for the PCMH has arisen across the vast majority of the US health care delivery system to include commercial insurance plans, multiple employers, state Medicaid programs, numerous federal agencies, the Department of Defense, hundreds of safety net clinics, and thousands of small and large clinical practices nationwide (Grundy, Hacker, Langner, Nielsen, & Zema, 2012). Private and public payer initiatives together have grown from eighteen states in 2009 to forty-four states in 2013, and they now cover almost twenty-one million patients. These heterogeneous initiatives overall are becoming larger, paying higher fees, and engaging in more risk sharing with practices (NCQA, 2015).
Because the patient-centered medical home is foundational to ACOs—with ACOs often described as the “medical neighborhood”—the PCMH is likely to gain even greater prominence as ACOs continue to develop in the marketplace (Grundy et al., 2012). Moreover, a growing body of scienti�ic evidence shows that PCMHs are saving money by reducing hospital and emergency department visits, mitigating health disparities, and improving patient outcomes. Examples of speci�ic outcomes achieved by various PCMHs include the following:
Lower Medicare spending
More effective care management and optimized use of health care services
Improved care management and preventative screenings for cardiovascular and diabetes patients
Reduced socioeconomic disparities in cancer screening (NCQA, 2015)
Additionally, more than nine thousand primary care practices and forty-three thousand clinicians (doctors and nurse practitioners) across the country have earned the PCMH designation from the National Committee for Quality Assurance (NCQA), the nation’s largest credentialing organization. The designation is earned by demonstrating achievement of goals related to accessible, coordinated, and patient-centered care (Olivero, 2015).
Progress to Date: ACOs In the value-based care world, ACOs are expected to play a leadership role in improving population health—whether participating in contracts with Medicare, Medicaid, or managed care organizations (MCOs) or health plans. These arrangements are often complex and may differ widely, including elements such as governance requirements, payment structures, quality metrics, reporting requirements, and data sharing (Houston & McGinnis, 2016).
Several different ACO models, including the Pioneer ACO program and the Medicare Shared Savings Program (MSSP), are testing and evaluating various risk-sharing agreements. In December 2011, CMS signed agreements with thirty-two organizations to participate in the Pioneer ACO model, designed to show how particular ACO payment arrangements can best improve care and generate savings for Medicare. As of May 1, 2016, there are nine Pioneer ACOs participating in the model for a �ifth and �inal performance year (CY2016). The MSSP is a key component of the Medicare delivery system reform initiatives included in the Affordable Care Act and is designed to facilitate coordination and cooperation among providers to improve the quality of care for Medicare fee-for-service (FFS) bene�iciaries and reduce unnecessary costs. Eligible providers, hospitals, and suppliers may participate in the MSSP by creating or participating in an ACO.
Although there has been considerable debate among policymakers as to the success of the ACO model, some of these ACOs are already reporting positive results for improving patient outcomes and controlling costs, as shown in Table 4.1 (http://content.thuzelearning.com/books/Wager.8743.17.1/sections/c04anchor-2#c04-tbl-0001) (Houston & McGinnis, 2016).
Table 4.1 (http://content.thuzelearning.com/books/Wager.8743.17.1/sections/c04anchor-2#backT1) Key attributes and broad results of current ACO models
Source: R. Houston and T. McGinnis. January 2016. “Accountable Care Organizations: Looking Back and Moving Forward.” Center for Health Care Strategies. Used with permission.
Attribute MSSP Pioneer ACO Commercial ACOs Medicaid ACOs
333 ACOs in 47 states 18 ACOs in 8 states
528 commercial contracts 66 ACOs in 9 active state- based programs
Key model features
Shared savings payment methodology 33 quality metrics
Designed for large hospital systems Shared savings system with higher risk and reward potential than MSSP Same 33 quality metrics as MSSP
Often independent contracts between ACOs and MCOs Many feature narrow provider networks.
Various approaches to payment including shared savings and capitation Various approaches to quality measurement
Results to date
CMS has reported results for different cohorts of MSSP ACOs based on start date, which have shown signi�icant savings, but it is dif�icult to aggregate these results, though only 26% of ACOs received shared savings payments ACOs consistently improved on 27 of 33 quality metrics. Increases in patient satisfaction relative to patients not enrolled in ACOs
$304 million in savings over three years ACOS consistently improved on 28 of 33 quality metrics. Increases in patient satisfaction relative to patients not enrolled in ACOs Began with 32 participants; 14 have left program
Not many publicly reported results available across programs due to proprietary information and dif�iculty comparing results
CO, MN, and VT have collectively reported $129.9 million in savings. ED visits in OR decreased by 22%.
ACO Challenges Now with years of observation and learnings to draw from, several key challenges facing ACOs have been identi�ied, including dif�iculties working across organizational boundaries, building the requisite infrastructure for effective data sharing, and truly engaging patients in the care process. One of the more notable challenges currently being worked on is the alignment and consolidation of myriad quality measures being used in public and private programs.
Effective quality measures are imperative to accountability in organized systems of care, especially when performance affects the ability of the provider to share in savings or determines whether a provider avoids penalties or receives bonus payments (Bipartisan Policy Center, 2015). However, the notion of “measurement fatigue” and the increasing administrative burden it places on providers is a legitimate concern (Buelt, Nichols, Nielsen, & Patel, 2016). Another challenge with quality metrics is that although they tend to capture performance on speci�ic outcomes, such as lower avoidable readmissions, or processes, such as screening for depression, they may not accurately measure the overall health of the patient, making it dif�icult to assess the true impact and ef�icacy of ACO arrangements (Houston & McGinnis, 2016).
Implications for Health Care Leaders Through the combination of changing health care business models and payment mechanisms, we are witnessing transformational change in the nature of health care delivery. It is evolving from one of reactive care with fragmented accountability and a dependence on full beds to a model of health management, care that extends over time and place and rewards for ef�iciency and quality. This transformation poses potent challenges for providers and has enormous implications for today’s health care leaders, particularly by placing greater emphasis on these issues:
Keeping patients well and managing and preventing disease
Establishing more ef�icient organization and utilization of care teams and venues of care
Creating a care culture that is comfortable with change and ongoing automation
Engaging patients in managing their care and overall health
Ensuring the most cost-effective care is provided and that clinical processes are streamlined and follow the best evidence
More speci�ically, accountable care and the move to population health management will require industry perspectives and health care delivery practices to shift from
Care providers working independently to collaborative teams of providers
Treating individuals when they get sick to keeping groups of people healthy
Emphasizing volumes to emphasizing outcomes
Maximizing the use of resources and assets to applying appropriate levels of care at the right place
Offering care at centralized facilities to providing care at sites convenient to patients
Treating all patients the same to customizing health care for each patient
Avoiding the sickest chronically ill patients to providing special chronic care services
Being responsible for those who seek services to being responsible for the needs of the community
Putting forth best efforts to becoming high-reliability organizations (Glaser, 2012b)
Additionally, accountability will bring new performance and utilization risks to providers as the focus shifts from optimizing business unit performance to optimizing network performance. At the same time, instead of maximizing the pro�itability of care, organizations will increase the volume of desired bundled episodes while controlling costs. At an operational level, organizations must change their structure as well as work�lows to implement PHM and adopt new types of automation tools and reporting. This will require setting clear goals, the active participation of leadership— including physician leaders, an assessment of technology requirements, and an effective rollout strategy (Institute for Health Technology Transformation, 2012).
Health IT clearly plays a vital role in the success of new models of care and payment reform and should be an integral part of the organization’s planning process. Whether participating in an ACO or not, all health care organizations should be thinking about building a population health management strategy and addressing related gaps in their information technology (IT) capabilities. Minimally, this would include acquiring the capabilities and tools to do the following:
Know, characterize, and predict the health trajectory that will happen within a population.
Engage members, families, and care providers to take action.
Manage outcomes to improve health and care.
4.2 Accountable Care Core Processes Accountable care frameworks are based on risk and reward, with providers and organizations agreeing to share the �inancial risk for a population in return for the opportunity to access rewards on meeting health care quality and cost goals. ACOs are responsible for tracking and measuring speci�ic quality metrics to indicate that patient outcomes are improving or evidence-based processes are being used. Some, but not necessarily all, metrics may be tied directly to the payment methodology, meaning that performance on these metrics will trigger either a quality incentive (such as an increased percentage of shared savings) or a disincentive (such as not receiving any shared savings) (Houston & McGinnis, 2016).
To accomplish the goals of PHM, a provider must deliver proactive preventive and chronic care to its attributed patient population. As such, the care team must maintain regular contact with patients and support their efforts to manage their own health. At the same time, care managers must closely monitor high-risk patients to prevent them from deteriorating or developing complications. The use of evidence-based protocols to diagnose and treat patients in a consistent, cost-effective manner is also central to PHM efforts. In many respects, success in population health management depends largely on a provider’s ability to manage several core processes in an accountable care environment. We’ll review these core processes in the next sections.
Identifying, Assessing, Stratifying, and Selecting Target Populations To manage population health effectively, an organization must be able to track and monitor the health of individual patients, while also stratifying its population into subgroups that require particular services at speci�ied intervals. ACOs typically stratify their patient population by common care needs, conditions, and expenditure levels and then deploy tailored interventions based on these characteristics (Houston & McGinnis, 2016). For example, a high-risk pregnancy may require more frequent interventions (of�ice visits, fetal heart monitoring, etc.) than standard prenatal care warrants.
Strati�ication also involves the ability to identify a patient or cohort at risk for a negative health event (e.g., myocardial infarction, stroke, mental health crisis) or preventable health care utilization (e.g., surgical procedure or hospitalization) (Gibson, Hunt, Knudson, Powell, Whittington, & Wozney, 2015). The Agency for Healthcare Research and Quality (AHRQ) describes another method of strati�ication as being able to identify subpopulations of patients who might bene�it from additional services. Examples of these groups include patients needing reminders for preventive care or tests, patients overdue for care or not meeting management goals, patients who have failed to receive follow-up after being sent reminders, and patients who might bene�it from discussion of risk reduction (Institute for Health Technology Transformation, 2012).
Although there are numerous ways to identify and segment patients, having the ability to identify risk, alert appropriate stakeholders, and intervene in the care process at the right time is a key component of population health management.
Providing High-Quality Care and Care Management Interventions across the Continuum A key tenet of accountable care is to ensure that the health and wellness of a population is managed, the most cost-effective care is provided, clinical processes are streamlined and follow the best evidence, the necessary reporting is in place, and payments and reimbursement are appropriate. Although this is an obvious goal for all providers, ACOs must facilitate cross-continuum medical management of patients for active episodes and acute disease processes or for any patient outside of the de�ined goals of a target population. An ACO must demonstrate, in a variety of ways, its commitment to being patient centered and to engaging patients in their care and overall health.
To effectively care for populations, care management involves the patient-centered management and coordination of care events and activities in multiple care settings by one or more providers (e.g., �ine-tuning coordination among care team members, identifying care gaps and situations requiring additional interventions, as well as managing care transitions). For example, research indicates that poorly executed transitions of care between different locations (e.g., from hospital to primary care) are associated with increased risks of adverse medication events, hospital readmissions, and higher health care costs. Determining which transitions present the greatest risks and targeting care management services to patients undergoing those transitions should conserve resources and lead to better cost and quality outcomes (AHRQ, 2015).
Additionally, lack of follow-up care after hospital discharge can result in complications, worsening of patients’ conditions, and a higher chance of readmission (Nielsen & Shaljian, 2013). Therefore, another example of a care management intervention is ensuring that hospitals notify primary care practices when patients are discharged and that primary care teams follow up with patients shortly thereafter.
The overall aim of care management is to manage the most complex patients through the health care system, as well as managing the overall health of a select population (e.g., diabetics and elderly), taking their preferences and overall situation into consideration. Care management ensures that all patients from the lowest risk level to high-risk “super users” receive care at the right time, in the right place, and in a manner best suited for the patient. This requires proactive care, communication, education, and outreach.
Managing Contracts and Financial Performance Under new payment models, proactively understanding patient coverage and �inancial responsibility will be more critical than ever. Financial teams must have a solid handle on estimating reimbursement and associated payment distributions, carrying out predictive modeling for reimbursement contracts, measuring performance against contracts and predicting pro�itability, as well as integrating with other key processes to share information.
For example, pro�it maximization under a shared savings-risk model requires a shift away from revenue-focused strategies to cost-containment strategies (Houston & McGinnis, 2016). To effectively manage costs, health care executives will need tools and data to support different types of �inancial modeling, such as modeling the implications of moving patient care to settings other than the hospital or physician’s of�ice. ACOs will also need actuarial cost and utilization predictors to effectively manage the care of a de�ined population.
These changes represent a signi�icant cultural shift for provider organizations that must be prepared to handle a complex mix of public and private sector payment mechanisms.
Measuring, Predicting, and Improving Performance Data analytics is an integral part of PHM. ACOs typically measure quality and outcomes data against national guidelines or peer groups, and they seek to demonstrate longitudinal improvements. They might also measure costs, utilization, and patient experience on a population-wide basis, and they may use these reports as the basis for quality reporting to payers and other outside entities.
With payment so tightly linked to quality and outcomes, predicting, monitoring, and measuring system performance in key areas becomes paramount in an accountable care environment. Under value-based payment programs, there will be real rami�ications for poor care and rewards for improved care. In fact, even low-performing areas can qualify for high payments if they demonstrate year-over-year improvement.
Therefore, providers must have the ability to forecast which patients are likely to become high-risk so they can intervene before a patient’s condition worsens. They must also understand in real time if they are complying with a certain set of measures and monitor their continual performance. For example, ACOs will want to measure the effectiveness of care protocols, such as exercise compliance, for a population of diabetic patients. Surgical services providers will need to understand the costs and quality of proposed procedure bundles. Understanding what works and what does not is key to ensuring reimbursements, controlling costs, and, most important, providing the best care for patients (Glaser, 2012a).
Equally important is retrospective monitoring—�inding out what didn’t happen and why. For example, if a care provider failed to respond to an alert in a timely fashion or deviated from a given standard of care process, they can use these data to determine if new care interventions are necessary or if they need to alter an individual’s plan of care. Likewise, knowing that a patient failed to keep an appointment or was unexpectedly seen in the emergency room will enable the care team to engage patients in new ways to better manage chronic disease. With providers facing penalties for readmission, it will be more important than ever to understand if it’s the treatment that failed, the discharge plan that failed, or the patient who did not follow through on the post-discharge plan (Chopra & Glaser, 2013).
Preparation and Automation Is Key Overall, the accountable care movement demands that providers be more focused and aggressive in managing their organization and their patients. Among other challenges, changes in reimbursement will require providers to predict which patients will need extra care, more intensively engage and manage high-risk patients, model the �inancial implications of delivering sub-par care, assess the performance of core organizational processes such as transitions of care, determine conformance to medical evidence, and report quality measures to purchasers of care.
The long-term success of the transition to value-based payment models and PHM relies largely on health care providers investing in the IT tools and infrastructure—as well as acquiring the data management and analysis expertise—needed to automate and support these core processes. In addition, as with any IT endeavor, expertise in change management and work�low redesign is also a core requirement.
Even for providers that may not be participating in an ACO, building the organizational and IT competencies to support accountable care is critical to staying competitive. Organizations that fail to develop and demonstrate accountable care capabilities may not ful�ill their obligations to the community they serve—in fact, they may not survive.
Yet, organizations embracing the transformation from traditional fee-for-service to value-based PHM are �inding signi�icant gaps in their IT capabilities (Gibson et al., 2015). In the following section we examine the core IT building blocks and capabilities necessary to support accountable care and the move to PHM.
4.3 Data, Analytics, and Health IT Capabilities and Tools As more providers and health systems evolve into ACOs, they are becoming increasingly aware of what it takes to manage care from a population health perspective. As we know, this includes establishing new partner networks, targeting populations, aligning providers and contracts, developing cross-continuum protocols for care management, and enabling ef�icient data sharing.
It’s All about the Data For a PHM program to be effective there is a critical need to focus on the data and information that will increasingly power clinical decisions. This includes aggregating and normalizing clinical data, claims data, administrative data, and self-reported patient data to create a holistic view of the patients within a health care network. These data enable the network to identify populations of patients whose conditions can be managed through evidence-based care plans that are coordinated across care settings.
For example, the risk of progression from glucose intolerance to diabetes mellitus can be in�luenced by diet and exercise. Individuals within this “rising risk” population are at different stages of readiness to change and consequently at different stages of modi�iable risk. Having this insight enables providers to offer services at the appropriate level and time (AHRQ, 2015).
However, for many organizations, obtaining population health data can be dif�icult because it must be collected and organized from many disparate sources (e.g., laboratory information systems, EHRs, practice management systems, and home-monitoring devices). Data types that require aggregation and normalization include labs, radiology reports, medications, vital signs, diagnoses, demographic information, and more. Returning to our diabetes example, although a diabetic’s blood glucose result is discrete data that can be found in an EHR, the results of the same patient’s foot or eye exam may be found only in text format within a practice management system.
Data management for PHM purposes is also challenging because there’s no guarantee the various IT systems talk to each other, and each provider and health plan may have a different system for patient identi�ication and provider attribution. An important �irst step in connecting patient data across different care settings is to establish master patient indices (Glaser & Salzberg, 2011). Patient indices can serve as a crosswalk among the different medical record numbers and identi�iers that may be used by various provider organizations to correctly identify patients. In addition, a record locator service may be used to determine which patient records exist for a member and where the source data is located. The key concept behind having a record locator service is that a patient’s health information is housed on computers at the various sites of his or her care and this information is queried and aggregated from these sites at the time of a request.
Beyond the EHR: Core PHM Solution Components Although a certi�ied EHR certainly provides the necessary foundation for effectively responding to new payment models, population health requires a range of IT applications, PHM solution components, and analytical capabilities. In fact, early adopters of PHM solutions are already seeing the need for next-generation capabilities to support the following transitions:
From management of the sickest patients to management of all patients
Static risk categorization to risk categorization that follows a patient’s evolving risk
Focus on a single disease or condition based on simple data values and events to a focus on multi-disease or condition using evidence-based care plans
“List” generation with signi�icant manual work for care managers to signi�icant process automation
Loosely connected care “actors” to a care team that includes the patient and family
Retrospective analysis to concurrent analysis (Glaser, 2016a)
As organizations look to enhance their population health management strategies, they should make investments that enable the IT platform to do the following:
Collect data from multiple, disparate sources in near–real time, including any EHR, devices used in the home and at work, and other data sources, such as pharmacy bene�it managers or insurance claims.
Support organizations in not only aggregating but also transforming and reconciling data to establish a longitudinal record for each individual within a population.
Identify and stratify populations to pinpoint gaps in care, enabling providers to act on information and match the right care programs to the right individuals (Glaser, 2016a).
In addition to having an EHR that spans the continuum of care, providers pursuing PHM might invest in a PHM platform that sits above the EHR and other sources of data and must be EHR agnostic. In general, the following key technologies will enable the core accountable care processes.
Revenue Cycle Systems and Contract Management Applications
One could argue that the revenue cycle system forms the foundation of a provider’s response to accountable care and payment reform. As the reimbursement environment becomes more complex, revenue cycle systems must evolve to support payments based on quality and performance, requiring new capabilities such as these:
Aggregating charges to form bundles and episodes, with the aggregation logic enabling different groupings for different payers
Managing the distribution of payment for a bundle to the physicians, hospitals, and non-acute facilities that delivered the care
Streamlining transitions between disparate reimbursement methodologies and contracts when billing and collecting
Providing tools for retrospective analysis of clinical and administrative data to identify areas for improving the quality of care and reducing the cost of care delivered
These new capabilities must complement routine activities such as registering patients, scheduling appointments, and administering patient billing.
Care Management Systems
Used by care managers and discussed previously, care management systems enable proactive surveillance, automation, coordination, and facilitation of services for many different subpopulations across the care continuum. Speci�ic capabilities might include helping to facilitate transitions of care more ef�iciently, use of automated campaigns (e-mail, text, phone) to better manage high-risk patients, and supporting care teams in delivering evidence- based interventions to reduce high-cost utilization.
According to time-motion studies published in the journal Population Health Management by Prevea Health, automation of routine care management tasks enables care managers to manage two to three times as many patients as they can with manual methods (Handmaker & Hart, 2015).
Rules Engines and Work�low Engines
Processes that are ef�icient, predictable, and robust enable an organization to thrive in an accountable care environment. Work�low and rules engines can monitor process performance, alerting staff members to missed steps, sequence issues, or delays.
Work�low engines specialize in executing a business process, not just decisions made at a discrete point in time. The technology can greatly assist in clinical decision making by not only presenting clinicians with alerts and reminders, such as a rules engine, but also by encouraging teamwork in clinical decisions, assisting with the time management and task allocation in process delivery, stating changes in patient or operational conditions, and creating behind-the-scenes automation of process steps.
In a value-based purchasing world where each core measure needs to be associated with what’s happening today, performance improvement interventions must occur in real time—that is, while the patient is still in the acute care cycle. Therefore, sophisticated IT tools such as work�low and rules engines that push information to the front lines, guiding decisions at the point of highest possible impact, will be required.
Data Warehouse, Analytics, and Business Intelligence
Analytics will facilitate proactive management of key performance metrics, because accountable care creates a greater need to assess care quality and costs, examine variations in practice, and compare outcomes.
An enterprise data warehouse will fuel a wide range of analytic needs and provide intelligence to enable continual care process improvement initiatives. For example, it will be imperative that an organization can compare a hypertensive patient’s total cost of care relative to its peers and national benchmarks, and perhaps even more important, predict if those costs will signi�icantly increase because of comorbidities, complications, or gaps in care.
Applied to the data in registries or warehouses, predictive analytics tools can also help caregivers identify patients who are likely to present in the ER or be readmitted so they can tailor appropriate interventions and avoid penalties for excessive readmissions.
Although most providers lack experience with the tools and techniques associated with advanced data analysis, the application of business intelligence (BI) in health care will become the platform on which the organization not only monitors performance but also makes critical decisions to uncover new revenue opportunities, reduce costs, reallocate resources, and improve care quality and operational ef�iciency. Thus, enhancing an organization’s competency in data analytics and BI will become essential for success in population health management.
Health Information Exchange (HIE)
Essential to successful implementation of new models of care and payment reform is the exchange of clinical and administration information among different health care entities and between providers and patients. Although there has been some success in the regional health information exchange (HIE) movement, much of the focus now is on HIE capabilities at the integrated delivery system or ACO level. This enables providers to obtain a composite clinical picture of the patient regardless of where that patient was seen. By participating in an HIE or sharing health information, a number of potential important bene�its may be realized:
Serves as a building block for improved patient care, quality, and safety
Makes relevant health care information readily available when and where it is needed
Provides the means to reduce duplication of services that can lead to reduced health care costs
Enables automation of administrative tasks
Provides governance and management over the data exchange process
Facilitates achievement of meaningful use requirements (HIMSS, 2010)
The concept of HIE is not new. For nearly two decades organizations and collaborators have tried to facilitate HIE, but unfortunately a number of HIE initiatives have failed to be sustainable over the long term (Vest & Gamm, 2010). The HITECH Act placed renewed interest in the success of HIE by providing incentive payments to eligible providers for Meaningful Use of electronic health records, which includes having the ability to exchange information electronically with others in order to have a comprehensive view of the patient’s health and care (Rudin, Salzberg, Szolovitis, Volk, Simon, & Bates, 2011). However, despite investment at the national, state, and local levels, the increase in HIE utilization remains modest.
In fact, a recent survey of organizations facilitating health information exchange found that 30 percent of hospitals and 10 percent of ambulatory practices now participate in one of the 119 operational health information exchange efforts across the United States (Adler-Milstein, Bates, & Jha, 2013). Although this is substantial growth from prior surveys, the researchers also found that 74 percent of HIE efforts report struggling to develop a sustainable business model. These �indings suggest that despite progress, there is a substantial risk that many current efforts to promote health information exchange will fail when public funds supporting these initiatives are depleted. Adding to the challenge, HIE efforts have struggled to engage payers, and only 40 percent of HIE efforts in the country have one or more payers providing �inancial support (Adler-Milstein, Cross, & Lin, 2016).
Still, there is reason to remain optimistic, with more recent data showing that hospitals’ rates of electronically exchanging laboratory results, radiology reports, clinical care summaries, or medication lists with ambulatory care providers or hospitals outside their organization has doubled since 2008 (see Figure 4.1 (http://content.thuzelearning.com/books/Wager.8743.17.1/sections/c04anchor-4#c04-�ig-0001) ). Moreover, this exchange has signi�icantly increased annually since 2011 (Henry, Patel, Pylypchuk, & Searcy, 2016).
Figure 4.1 (http://content.thuzelearning.com/books/Wager.8743.17.1/sections/c04anchor-4#backF1) Percent of nonfederal acute care hospitals that electronically exchanged laboratory results, radiology reports, clinical care summaries, or medication lists with ambulatory care providers or hospitals outside their organization: 2008–2015
Source: Henry, Patel, Pylypchuk, and Searcy (2016).
Although there is still signi�icant progress to be made to improve the use of exchanged information and to address barriers to interoperability, HIE is critically important to the success of care transformation efforts nationwide. Thus, the industry must continue its efforts toward achieving sustainable HIE approaches to ensure that the massive national investment in health IT throughout the past decade delivers its intended return—higher-quality care, improved outcomes, and lower cost.
Registries and Scorecards
Serving as a kind of central database for PHM, registries can be used for patient monitoring, care gap assessment, point-of-care reminders, care management, and public health and quality reporting, among other uses. By integrating clinical, �inancial, and operational data across disparate sources into a single chronic condition and wellness registry solution, data can be normalized and turned into meaningful, actionable information.
For example, registries and scorecards enable providers to identify, score, and predict risks of individuals or populations to allow targeted interventions to be implemented. When applied to a population, the registry can show, for example, how all of a particular provider’s patients with type 2 diabetes are doing, which diabetic patients are out of control, or how well an entire organization is treating patients with that condition (Nielsen & Shaljian, 2013).
Longitudinal Record and Care Plan
As we know, even if a provider is diligently capturing patient information in an EHR, the data are valuable only in the world of collaborative, accountable care if the information can be integrated with patient data from other sources and harmonized to produce a single, consolidated record at the member level. The longitudinal record presents a complete picture of the patient’s medical history in an organized, coherent view.
Serving as the sister solution to the longitudinal record, a longitudinal care plan provides a consolidated, normalized view of indicators to be monitored, events due to happen, and actions to be taken to ensure that a patient maintains and improves his or her level of health.
Patient Engagement Tools
Medical interventions that occur solely through of�ice-based patient-provider interactions will no longer provide the level of monitoring and scrutiny needed to manage the health of individuals and populations. As such, providers must continue to harness the power of technology to engage patients in their care via tools such as home-monitoring devices, patient portals, and personal health records (PHRs), as well as through the use of social media, texting, and e-mail.
Portals and PHRs
Although patient portal use is still considered modest at best, given later-stage meaningful-use requirements and the anticipated bene�its of patient engagement in the value-based care world, many providers are ramping up their portal efforts and seeing adoption rates well above 20 percent (Buckley, 2015). Another recent study predicts that PHR adoption will exceed 75 percent by 2020, an optimistic projection that outpaces the PHR goals set under the Meaningful Use incentive program (Ford, Hesse, & Huerta, 2016). These consumer-centric technologies are designed to help patients and consumers better manage their own health and care, securely communicate with providers, pay bills, obtain test results, view doctors’ notes, re�ill prescriptions, schedule appointments, and so on.
Perspective The HIE Lessons
Despite the fact that the environment for building, creating, and developing an HIE organization has never been better, the concerns about long-term sustainability and the impact and value of exchanging health information persist. The National eHealth Collaborative (NeHC) conducted a comprehensive study of twelve fully operationally HIEs across the nation to �ind out from their leaders what factors have led to their success (NeHC, 2011). In-depth structured interviews were conducted with senior executives representing the business, clinical, and technical areas of each HIE. The key critical success factors these leaders identi�ied in sustaining an HIE are as follows:
Aligning stakeholders with HIE priorities in an intensive and ongoing effort. Create a shared vision that all stakeholders can embrace and that serves as the cornerstone to success. Foster an environment that is built on trust and that promotes learning and resolves differences when they arise. Make ongoing and effective stakeholder engagement a priority.
Establishing and maintaining consistent brand identity and role as a trusted, neutral entity dedicated to protecting the interests of participants. Data use and data integrity are two critical elements. The culture, policies, and procedures regarding the use of data must ensure that no entity will gain competitive advantage at the expense of others. Consent and security policies must meet the requirements of various stakeholders and regions or states. The HIE infrastructure must ensure that patient data are accurate, reliable, and trustworthy.
Ensuring alignment with vision in making strategic choices. Assess the stakeholders’ alignment with the initiative and congruence with the vision before deciding to pursue them. Regardless of how promising a source of funding may have initially appeared, some HIEs chose not to pursue it because the funding source did not have the full support of all stakeholders.
Considering structural characteristics and dynamics of the HIE market. The geographic location, composition of stakeholders, and resource capabilities are all factors to consider.
Understanding clinical work�low and managing change. The implementation of an HIE requires that clinicians and administrative staff members understand the impact of HIE applications on work�low and identify opportunities to improve ef�iciencies.
Different business models, governance structures, and strategies may be used to create value for the HIE participants.
Source: NeHC (2011).
Some patient portals and PHRs are integrated into a provider’s existing website, and others are extensions of the organization’s EHR system. For example, New York-Presbyterian (NYP) Hospital’s award-winning patient portal, myNYP.org (http://myNYP.org) , was built to expand on its existing EHR. Use of the portal led to a 42 percent increase of appointments scheduled using myNYP.org (http://myNYP.org) , and it lowered the no-show rated from 20 percent to 12 percent over a period of six months after it was made available in January 2012 (Glaser, 2013). Additional applications of the same appointment-alert technology can provide customized patient education material and personalized reminders to patients who �it a speci�ic clinical pro�ile, such as patients who missed an immunization.
Additionally, with one-third of consumers using online forums and social media sites such as Facebook, Twitter, and YouTube for health-related matters (PwC, 2012), many providers are actively engaged in using social media to communicate with patients and disseminate information on everything from emergency department wait times to new clinical offerings and research endeavors. They might also use social media channels to provide useful links to self-management tools and invitations to chronic care management programs. In fact, nearly 95 percent of hospitals have a Facebook page and just over 50 percent have a Twitter account (Grif�is et al., 2014).
Similar to social media, the use of automated messaging tools (via text, e-mail, or phone) can be equally bene�icial in urging patients to schedule necessary appointments, �ill their prescriptions, and comply with discharge orders. For example, one study showed that diabetic and hypertensive patients were two to three times more likely to attend a chronic care visit if successfully contacted using automated provider communications (Nielsen & Shaljian, 2013).
Perspective Top Tips for Portal Adoption
Given the modest adoption rates of PHRs and patient portals to date, research �irm KLAS asked providers what best practices for patient portal adoption they would pass along to other providers trying to improve their rates. The following are their suggestions:
“What contributes to adoption is educating our patients about the portal, helping them sign up, and encouraging them to use it. But education is key. Patients have embraced the portal and use it for much of our communication, bill pay, results review, and more.”
Educate patients—again and again.
“We ask patients on the phone whether they have signed up for the portal, and at their appointments we check to see whether they have �illed things out on the portal. Then the medical assistants who greet the patients ask whether they have put their information on the portal. We promote the portal �ive or six times. On their way out, the doctors tell the patients that they are going to send their results to the portal.”
Educate staff members as if they were patients.
“The patients get inundated and get tired of hearing it, but it was the kickoff that got everybody in the practice used to pushing the portal. We also made everyone here register on the portal to see what the patients would go through and so we could make changes and adjustments to �it our needs. It is an ongoing process, and we try to do contests every quarter. That is what contributes to our success, and it is pretty impressive.”
Give patients a reason to use the portal.
“We are apparently doing something right in encouraging patients to come to our portal. They come to the portal to �ill out the patient history and the medication list. I think that is because of the way our front desk staff members make new-patient appointments and the way they present the portal to the patients. They tell them that we can give them less waiting time when they come in if they get on the portal. We have an aggressive sign-up process. We give patients a Chromebook in the waiting room and help them sign up for the portal right away. We have a similar process in the ED and inpatient areas. We try to push as much content to the portal as possible.”
Talk to your vendor and physicians.
“We drove adoption from the top down. In our initial phase, the adoption didn’t go well because we thought we knew what we were doing and could do it ourselves. We went back and listened to Medfusion. We took the portal to the doctors who understand technology. They came back from a CMS meeting and said we had to do the portal. They said we might not like it, but we have to do it.”
Hold your vendor accountable.
“When we started to deploy Empower in our ambulatory area, we hit challenges and barriers with the physician group. The physicians really wanted to yank the product out; they didn’t want anything to do with it. They were beyond frustrated. We worked with MEDSEEK and the physicians, and in the last year and a half, we went from having a handful of patients on the portal to having sixty-�ive thousand. We were �inally able to leverage the solution in the ambulatory space after we made changes to the product and the interface. There were deal breakers in how the product looked and felt from a patient perspective, and we worked through those.”
Source: Buckley (2015). Used with permission.
PHM is most effective when a symbiotic relationship exists between human interventions and automation tools. Patient engagement tools and outreach programs enable providers to correspond with each person in their patient populations, with the goal of raising the percentages of patients receiving the recommended care as re�lected in the quality measures payers use to evaluate provider and health system performance. More important, such programs assist providers in keeping patients as healthy as possible for as long as possible, a core tenant of PHM.
Telemedicine and Telehealth
The growing use of telemedicine can make patient interactions more convenient, expand geographic horizons particularly where needed medical specialists are few in number, and make care more accessible to those with mobility issues.
Perspective Five Reasons to “Like” Consumers’ Use of Social Media
With an abundance of patient-generated health information now available through online patient communities, social media can play a vital role in improving our understanding of disease and accelerating new approaches to treatment. Consider the following ways patient and consumer use of social media is bene�iting health care.
Creates a Sense of Community
For those seeking emotional support and tips for coping with a disease, social media delivers on many fronts. It can enable the formation of communities regardless of member locations and enable members to communicate asynchronously.
Sites such as PatientsLikeMe and Inspire provide virtual medical communities focused on chronic diseases where patients can discuss their conditions, track key health information, share side effects of medications and therapies, and bond with others as they chronicle the highs and lows of their health care journeys.
In fact, a 2014 survey of PatientsLikeMe members found that the vast majority of adult social media users with health conditions embrace the idea of sharing their health information online if it helps clinicians improve care, assists other patients, or advances medical research.
Users of online health communities also frequently cite as reasons for their membership the accountability the sites provide them in managing their own health and reaching their health-related goals, as well as the motivation, support, and advice they receive from others. Online communities can also lessen the feeling of isolation that often accompanies those with rare conditions or parents with a critically ill child.
Delivers New Clinical Research Insights
As more and more patients use social media to track their health conditions and actively participate in their care, there is a greater opportunity to use this real-world data to better inform new treatments and treatment decisions, enhance symptom management, and ultimately improve outcomes.
For example, in analyzing the results of observational data housed on PatientsLikeMe, researchers found that lithium therapy had no impact on ALS disease progression, which was later con�irmed by subsequent randomized trials (Chretien & Kind, 2013).
Although PatientsLikeMe began as a social network enabling people to crowdsource the collective wisdom of others, it has developed into a powerful analytical platform for clinicians and researchers. In fact, the network is quite transparent with its members about how it makes money— by sharing the information members provide about their experience with diseases and selling it to their partners (companies that are developing or selling products to patients). This may include drugs, devices, equipment insurance, or medical services.
In addition to helping patients �ind and take advantage of clinical trials, health care social networks also provide an opportunity for participant-led research, in which members initiate new �ields of study. For instance, Inspire members with spontaneous coronary artery dissection (SCAD) persuaded researchers at the Mayo Clinic to launch new research about their condition, which led to the creation of a SCAD registry, a key step in the further study of this rare disease (Tweet, Gulati, Aase, & Hayes, 2011). Indeed, there is tremendous potential for online patient communities to contribute to the notion of a continuously learning health system.
Builds Awareness of Cause-Related Issues or Personal Health Care Crises
Social media can also serve as the birthplace for bene�icial social movements, as well as hubs for galvanizing emotional and �inancial support for a personal health care crisis.
The ALS Ice Bucket Challenge is a terri�ic example of social media’s power to deliver on the fund-raising aspect of the campaign and on the equally important goal of helping the public become more aware of ALS and efforts to �ind a cure.
The simple act of pouring ice on one’s head, capturing it on video, and calling out another person to do the same spread across social media channels like wild�ire. With everyone from schoolchildren to celebrities getting in on the act, the ALS Association raised $115 million in 2014, a staggering increase from its $23.5 million intake in 2013 (ALS Association, 2015).
On a smaller scale, sites such as GoFundMe and My Cancer Circle can help keep family and friends abreast of a loved one’s illness and treatment status, provide tools to coordinate meal deliveries and rides to medical appointments, as well as enable �inancial contributions to help offset personal health care expenses.
Provides Assistance with Treatment, Physician, or Hospital Selection
Although physician rating sites have been around for many years, social media has given health care consumers a more active voice and an ever- present tool set for broadcasting opinions on all things health care–related—from physicians and hospitals to medications, devices, and insurance plans.
Like it or not, social media is proving to be a vehicle that can help scale positive and negative attitudes about one’s health care experience at Internet speed. In fact, a 2012 survey by Demi & Cooper Advertising and DC Interactive found that 41 percent of people said social media would affect their choice of a speci�ic doctor, hospital, or medical facility.
Of course, the downside here is that the negative opinions of a vocal minority could cause unjust reputation management issues for providers.
With the viewpoints of those in online social networks playing such a key role in in�luencing health care decisions, providers ought to ensure they are optimizing their social media channels and actively participating in helping consumers share positive opinions online.
Complements Traditional Approaches to Measuring Patient Satisfaction
Beyond just randomly monitoring opinions shared on social media, savvy providers may want to turn to social media to supplement their traditional means of capturing patient satisfaction and feedback on inpatient experience.
In fact, researchers at Boston Children’s Hospital conducted a study to determine if Twitter could provide a reasonable form of complementary quality measurement, given the real-time nature of tweets. The team amassed unsolicited knowledge (versus data gleaned from very targeted survey questions) about what pleased or angered consumers by collecting more than 400,000 tweets directed at the Twitter handles of nearly 2,400 US hospitals between 2012 and 2013 (Ulrich, 2015).
Although certainly no replacement for patient satisfaction surveys, according to the researchers the data are suggestive and provide proof of principle that Twitter and the right analytical tools may provide a valuable means for complementing standard approaches to measuring quality. Moreover, the ability to correlate social media data points such as tweets with actual outcomes measures (e.g., patient length of stay in the emergency department or readmission rates) provides an interesting avenue for further exploration.
Source: Glaser (2016b). Reprinted from H&HN Daily by permission, April 11, 2016, Copyright 2016, by Health Forum, Inc.
The American Telemedicine Association de�ines telemedicine or telehealth as exchanging medical information via electronic communications to improve a patient’s clinical health status. Health care providers are embracing telemedicine because they see it as an ef�icient and cost-effective way to deliver quality care and improve patient satisfaction (Glaser, 2015a). Today’s telehealth framework spans the continuum of care and can include services such as the following:
Remote image interpretation (teleradiology, teledermatology)
e-Visits or televisits between providers and their patients
Video visits for semi-urgent care
Critical care (virtual ICU, telestroke)
Remote monitoring of a patient with a chronic disease
Cybersurgery or telesurgery
Let’s take a closer look at some of the more popular applications of telemedicine and telehealth. Two-way interactive video-conferencing or other web-based technologies can be used when a face-to-face consultation is necessary. In addition, a number of peripheral devices can be linked to computers to aid in interactive examination. For example, a stethoscope can be linked to a computer, enabling the consulting physician to hear the patient’s heartbeat from a distance. Electronic monitoring of physiological vital signs can be done through electronic intensive care unit (eICU) patient-monitoring systems, and telesurgery can enable a surgeon in one location to remotely control a robotic arm to perform surgery in another location.
Telehealth is also being used to capture and monitor data from patients at home. Examples include monitoring patient blood sugar levels through glucometers attached to cell phones and conducting teledermatology visits with the aid of cell phone cameras.
According to the American Hospital Association (AHA), 52 percent of hospitals used some form of telehealth in 2013, and another 10 percent were beginning to implement such services (AHA, 2015). Its growth potential is also notable. Business information provider IHS predicts the US telehealth market will grow from $240 million in revenue in 2013 to $1.9 billion in 2018—an annual growth rate of more than 50 percent (EY, 2014).
In addition to the growing demand for access and convenience, the need for telemedicine is driven by other factors such as the following:
Signi�icant increase in the US population
Shortage of licensed health care professionals
Increasing incidence of chronic diseases
Need for ef�icient care of the elderly, homebound, and physically challenged patients
Lack of specialists and health facilities in rural areas and in many urban areas
Avoidance of adverse events, injuries, and illnesses that can occur within the health care system
These factors become increasingly important as new health care delivery and payment models evolve and providers are challenged to better manage chronic diseases, avoid readmissions, improve quality, and remove low acuity care from high-cost venues. As we know, the long-term bene�its of population health programs are predicated in large part on managing high-cost, chronically ill patient populations more effectively. Furthermore, the rapid deployment of high deductible health plans, which make consumers more conscious and accountable for their health care consumption and spending, has added to the pressure on providers to provide low-cost, convenient options.
Despite all its promise, several major barriers must be addressed if telemedicine is to be used more widely and become available. Concerns about provider acceptance, interstate licensure, overall con�identiality and liability, data standards, and lack of universal reimbursement for telemedicine services from public and private payers are among the complex and evolving issues affecting the widespread use of telemedicine. Furthermore, its cost-effectiveness has yet to be fully demonstrated.
Nonetheless, the barriers are beginning to erode under mounting pressure from all health care constituents. Licensure portability will further ease the barriers to accessing services, whereas regulatory and payment policy changes in support of telehealth are widely expected in the coming years. For instance, on the private payer side, telemedicine use has been bolstered by a growing number of states enacting parity laws, which require health insurers to treat telehealth services the same way they would in-person services.
4.4 Transitioning from the Record to the Plan As we reviewed in this chapter, the profound changes in reimbursement and care models are altering the structure of care provision, requiring providers to make investments in a comprehensive IT portfolio—beyond the EHR—to support PHM and enable the core processes associated with accountable care. These changing business and payment models are leading not only to signi�icant changes in organization and practice but also to changes in the fundamental nature and design of the EHR itself. These changes can be characterized as a transition from the electronic health record to the electronic health plan (Glaser, 2015b).
The EHR does not disappear as a result of this shift. We will still need traditional EHR capabilities: providers need to review a radiology report and document a patient’s history and the care delivered. Problems must be recorded and medications reconciled. However, the strategic emphasis will move to technologies and applications that assist the care team (including the patient) in developing and managing the longitudinal, cross-venue health plan and assessing the outcomes of that plan.
For example, evidence-based pathways and decision-support logic have been embedded into EHRs to guide provider decisions according to a plan based on patient condition. EHRs can now include or be enhanced by the speci�ic PHM technologies we discussed that enable the organization to understand its aggregate performance in undertaking disease-speci�ic plans for multiple patients.
Provider organizations will not thrive in an era of health reform because they have a superb and interoperable EHR. They will thrive because the care they deliver consistently follows a plan designed to ensure desired outcomes. The EHR must evolve so it focuses on individual patients’ care plans— the steps required to maintain or create health.
Every patient’s EHR should clearly display the master care plan—a long-term care plan to maintain health integrated with short-term plans for transient conditions. The EHR should be organized according to this master plan: it should highlight the steps needed to recover or maintain health, list the expectations of every caregiver the patient interacts with, and include tools such as decision support and a library of standard care plans. Interoperability is a necessity, because various providers must be able to use the plan-based EHR.
Care Plan Attributes The care health plan has attributes that need to be present to ensure health and should be based on some fundamental ideas.
First, all people have a foundational plan. If the person is a healthy young man, the plan may be simple: establishing health behaviors such as exercise. If the person is a middle-aged man with high cholesterol and sleep apnea, the plan may be annual physicals, statins, a CPAP machine, and a periodic colonoscopy. If a person is frail and elderly with multiple chronic diseases, the plan may be merging the care for each chronic condition, ensuring proper diet, and providing transportation for clinic visits.
Second, plans are a combination of medical care strategies with goals to maintain health (such as losing weight) along with public health campaigns (such as immunizations).
Third, on top of foundational plans there may be transient plans. For the patient undergoing a hip replacement there is a time-bounded plan beginning with presurgery testing and ending when rehabilitation has been completed. A patient undergoing a bad case of the �lu has a time-bounded plan.
Fourth, people who have a common plan are members of the same population. These populations may be all patients undergoing a coronary artery bypass graft in a hospital, all patients with a certain chronic disease, or all patients at high risk of coronary artery disease. Moreover, a particular person may be a member of multiple populations at the same time.
Fifth, risk is the likelihood that the plan will not be followed or will not result in desired outcomes. A patient motivated to manage his or her blood pressure has a lower risk than a patient who is not motivated. A frail person with multiple chronic diseases is at greater risk that the plans will not keep him or her out of the hospital than a person whose health is generally good despite having multiple chronic diseases.
Sixth, not all care will be amenable to a prede�ined patient plan. Life-threatening trauma, diseases of mysterious origin, sudden complications—all require skilled caregivers to make the best decisions possible at the moment.
Seventh, plans should be based on the evidence of best care and health practices. And the effectiveness of a plan should be measurable, either in terms of plan steps being completed or desired outcomes being achieved (Glaser, 2015a).
The Plan-Centric EHR The EHR needs to evolve into plan-centric applications. Among others, these applications will have several key characteristics.
A Library of Plans That Cover a Wide Range of Situations
This library will include, for instance, plans for managing hypertension, removing an appendix, losing weight, and treating cervical cancer. There will be variations in plans that re�lect variations in patient circumstances and preferences, for example, plans that depend on whether the patient is a well- managed diabetic or plans that re�lect the slower surgical recovery time of an elderly person.
Algorithms to Form a Patient’s Master Plan
A master plan will combine, for example, the patient’s asthma, hysterectomy, depression, and weight-reduction plans into a single plan. These algorithms will identify con�licts and redundancies among the plans and highlight the care steps that optimize a patient’s health for all plans. For
example, if each of the �ive plans has six care steps, the algorithms can determine which steps are the most important.
The master plan will cover the steps to be carried out by a patient’s primary care provider, specialists, nurse practitioners, pharmacists, case managers, and the patient. Each team member can see the master plan and his or her speci�ic portion of the plan. Team members can assign tasks to each other (Glaser, 2015a).
Business Models in Other Industries Major changes in an industry’s business model invariably lead to major changes in the focus and form of the core applications used by that industry. For example, �inancial services, retailers, and music distributors, along with many other industries, have also experienced massive shifts in their business models.
Several decades ago, �inancial deregulation enabled banks to offer brokerage services. The business model of many banks shifted from banking (offering mortgages as well as checking and savings accounts) to wealth management. As banks shifted from transaction-oriented services to services that optimized a customer’s �inancial assets, their core applications broadened to include an additional set of transactions (buying and selling stocks) and new services (�inancial advisory services).
Prior to the web, most retailers’ business models focused on establishing a brand, offering an appropriate set of well-priced products, and building attractive stores in convenient locations. The web enabled retailers to gather signi�icantly richer data about a customer’s buying patterns and interests (and to use real-time logic to guide purchasing decisions). Retailers’ core applications broadened to include well-designed e-commerce sites and analytics of customer behavior.
In both examples, even though there was a signi�icant shift in the business model, applications needed for the previous model continued to be necessary. Banks still had to handle savings account and mortgage payment transactions. Retailers still needed to manage inventory. And advances in these legacy applications—expanding inventory breadth and reducing inventory-carrying costs—continue to be important. In each case, a critical new set of applications were added to the legacy applications. Often, these new applications were more important than legacy applications.
The business model changes in health care will lead to a shift from applications focused on the patient’s record to applications focused on the patient’s plan for health. This evolution in the nature of the EHR is a key component to achieving success in population health management.
Summary As the health care industry continues its transition from a fragmented, volume-based system toward one that embraces the notion of patient-centered, accountable care driven by value-based payment models, providers must consider what new relationships, processes, and IT assets and skills will be required to succeed—particularly when it comes to managing the health and care of attributed populations.
By implementing a PHM strategy, organizations have enormous opportunity to use data and analytics to improve inef�iciency and waste, thereby reducing costs, and monitor adherence to evidence-based protocols to drive better outcomes. Several PCMHs and ACOs are already showing promising performance in the emerging world of value-based payment and population health management.
In addition to having a robust EHR, organizations looking to enhance their PHM strategies should consider several key solution components. PHM technologies can help providers stratify and select target populations, identify gaps in care, predict outcomes and apply early interventions, and actively engage patients in their care. Moreover, they can enable an organization to understand its aggregate performance in undertaking disease- speci�ic plans for multiple patients and better manage contracts and �inancial performance.
Additionally, because value-based payment is based on conformance to chronic disease protocols, providers must have the ability to aggregate and normalize real-time, accurate, cross-continuum data from disparate sources illustrating how well the data conform to those protocols. As we know, many hospitals and health systems do not operate from a position of excess revenue, and as outcomes become increasingly tied to the reimbursement stream, it will become critical that providers can rely on their data and IT tools to detect and remedy variations in care.
Population health management solutions are intended to complement—not replace—the traditional EHR. They represent a shift from applications focused on documenting the patient’s record of care to applications focused on developing the patient’s plan for health.
Key Terms Accountable care organizations (ACOs)
Business intelligence (BI)
Health information exchange (HIE)
Patient-centered medical home (PCMH)
Population health management (PHM)
Telemedicine and telehealth
Learning Activities Interview a health care executive or CEO in your local community. To what extent is the organization involved in population health management? How is that person using health IT to further his or her PHM initiatives? To what extent does the organization’s health IT capabilities facilitate PHM? What other capabilities are needed?
Investigate the adoption and use of telemedicine and telehealth in your state. How is it being used? What bene�its have been realized? What challenges or obstacles still exist? How important is telemedicine and telehealth in providing access to care? In improving quality of care? And in reducing costs?
Explore the health IT products on the market that are designed to facilitate care management. What are their key features and functions? In what speci�ic ways do these tools facilitate communication among providers and patients and families?
Conduct a literature review on the use of social media in health care. How are consumers using social media to learn more about their health or health conditions? How are health care organizations using social media to connect with consumers? Where do you see the future of social media in health care evolving?
Evaluate different models of care within your local community or state. Did you �ind any examples of accountable care organizations or patient-centered medical homes? Explain. Working as a team, visit or interview a leader from a site that uses an innovative model of care. Describe the model, its uses, challenges, and the degree of patient coordination and integration. How is health IT used to support the delivery of care and the reporting of outcomes?
Explore the extent to which health information exchange is occurring within your community, region, or state. Who are the key players? To what extent is information being exchanged across organizations for patient care purposes? What challenges have they faced? How have they overcome them, if at all?
Visit a health care organization that uses an EHR system and provides patients access to their information via a patient portal. To what extent are patients using the portal? For what purposes are they using them? What are the demographic characteristics of the portal users and nonusers? What strategies might you employ to promote greater usage?
References Adler-Milstein, J., Bates, D. W., & Jha, A. K. (2013). Operational health information exchanges show substantial growth, but long-term funding remains a concern. Health Affairs, 32(8), 1486–1492.
Adler-Milstein, J., Cross, D., & Lin, S. (2016). Assessing payer perspectives on health information exchange. Journal of the American Medical Informatics Association, 23(2), 297–303.
AHRQ. (2015, April). Issue brief: Care management; Implications for medical practice, health policy, and health services research. AHRQ Publication No. 15-0018-EF. Retrieved May 2016 from http://www.ahrq.gov/professionals/preventionchroniccare/improve/coordination/caremanagement/index.html (http://www.ahrq.gov/professionals/preventionchroniccare/improve/coordination/caremanagement/index.html)
ALS Association. (2015). ALS ice bucket challenge—FAQ. Retrieved February 2016 from http://www.alsa.org/about-us/ice-bucket- challenge-faq.html (http://www.alsa.org/about-us/ice-bucket-challenge-faq.html)
American Hospital Association (AHA). (2015, Jan.). Trendwatch: The promise of telehealth for hospitals, health systems and their communities. Retrieved October 2015 from http://www.aha.org/research/reports/tw/15jan-tw-telehealth.pdf (http://www.aha.org/research/reports/tw/15jan-tw-telehealth.pdf)
Berwick, D., Nolan, T., & Whittington, J. (2008). The triple aim: Care, health, and cost. Health Affairs, 27(3), 759–769.
Bipartisan Policy Center. (2015, July). Transitioning from volume to value: Accelerating the shift to alternative payment models. Retrieved May 2016 from http://bipartisanpolicy.org/wp-content/uploads/2015/07/BPC-Health-Alternative-Payment-Models.pdf (http://bipartisanpolicy.org/wp-content/uploads/2015/07/BPC-Health-Alternative-Payment-Models.pdf)
Buckley, C. (2015, May). Patient portals adoption: From 5% to 20% and beyond. KLAS. Retrieved May 2016 from http://www.klasresearch.com/resources/klas-blog/klas-blog/2015/08/17/patient-portal-adoption-from-5-to-20-and-beyond (http://www.klasresearch.com/resources/klas-blog/klas-blog/2015/08/17/patient-portal-adoption-from-5-to-20-and-beyond)
Buelt, L., Nichols, L., Nielsen, M., & Patel, K. (2016, Feb.). The patient-centered medical home’s impact on cost and quality annual review of evidence 2014–2015. Patient-Centered Primary Care Collaborative. Retrieved May 2016 from https://www.pcpcc.org/resource/patient- centered-medical-homes-impact-cost-and-quality-2014-2015 (https://www.pcpcc.org/resource/patient-centered-medical-homes-impact- cost-and-quality-2014-2015)
Chopra, N., & Glaser, J. (2013, April 9). Ready, set, go: Performance-based reimbursement. H&HN Daily.
Chretien, K. C., & Kind, T. (2013). Social media and clinical care: Ethical, professional, and social implications. Circulation, 127, 1413–1421.
Casalino, L., Erb, N., Joshi, M., & Shortell, S. (2015, Aug.). Accountable care organizations and population health organizations. Journal of Health Politics, Policy and Law, 40(4), 821–837.
EY. (2014). Shaping your telehealth strategy. Health Care Industry Post. Retrieved October 2015 from http://www.ey.com/Publication/vwLUAssets/EY-shaping-your-telehealth-strategy/$FILE/EY-shaping-your-telehealth-strategy.pdf (http://www.ey.com/Publication/vwLUAssets/EY-shaping-your-telehealth-strategy/$FILE/EY-shaping-your-telehealth-strategy.pdf)
Felt-Lisk, S., & Higgins, T. (2011, Aug.). Exploring the promise of population health management programs to improve health. Mathematica Policy Research Issue Brief. Retrieved May 2016 from https://www.mathematica-mpr.com/our-publications-and- �indings/publications/exploring-the-promise-of-population-health-management-programs-to-improve-health (https://www.mathematica-mpr.com/our-publications-and-�indings/publications/exploring-the-promise-of-population-health-management-programs- to-improve-health)
Ford, E., Hesse, B., & Huerta, T. (2016). Personal health record use in the United States: Forecasting future adoption levels. Journal of Medical Internet Research, 18(3).
Gibson, R., Hunt, J., Knudson, S., Powell, K., Whittington, J., & Wozney, B. (2015). Guide for developing and information technology investment road map for population health management. Population Health Management, 18(3), 159–171.
Glaser, J. (2012a, Oct. 9). The growing role of analytics and business intelligence. H&HN Daily.
Glaser, J. (2012b, April 10). Six key technologies to support accountable care. H&HN Weekly.
Glaser, J. (2013, June). Expanding patients’ role in their care. H&HN Daily.
Glaser, J. (2015a, Dec.). Telemedicine hits its stride. H&HN Daily.
Glaser, J. (2015b, Aug. 11). From the electronic health record to the electronic health plan. H&HN Daily.
Glaser, J. (2016a, June 13). All roads lead to population health management. H&HN Daily.
Glaser, J. (2016b, April 11). Five reasons to “like” patients’ use of social media. H&HN Daily.
Glaser, J., & Salzberg, C. (2011). The strategic application of information technology in health care organizations (3rd ed.). San Francisco, CA: Jossey-Bass.
Grif�is, H. M., Kilaru, A. S., Werner, R. M., Asch, D. A., Hershey, J. C., Hill, S., Ha, Y. P., Sellers, A., Mahoney, K., & Merchant, R. M. (2014). Use of social media across US hospitals: Descriptive analysis of adoption and utilization. Journal of Medical Internet Research, 16(11), e264.
Grundy, P., Hacker, T., Langner, B., Nielsen, M., & Zema, C. (2012, Sept.). Bene�its of implementing the primary care patient-centered medical home: A review of cost & quality results, 2012. Patient-Centered Primary Care Collaborative. Retrieved May 2016 from https://www.pcpcc.org/guide/bene�its-implementing-primary-care-medical-home (https://www.pcpcc.org/guide/bene�its- implementing-primary-care-medical-home)
Guterman, S., & Drake, H. (2010, May). Developing innovative payment approaches: Finding the path to high performance. New York, NY: The Commonwealth Fund.
Handmaker, K., & Hart, J. (2015). 9 steps to effective population health management. Healthcare Financial Management, 69(4), 70–76.
Health Information Management and Systems Society (HIMSS). (2010). Overview of HIE in era of meaningful use. Retrieved February 2013 from http://www.himss.org/content/�iles/12_21_2010_HIE%20OverView%20in%20HITECH.pdf (http://www.himss.org/content/�iles/12_21_2010_HIE%20OverView%20in%20HITECH.pdf)
Henry, J., Patel, V., Pylypchuk, Y., & Searcy, T. (2016, May). Interoperability among US non-federal acute care hospitals in 2015. ONC Data Brief, No. 36. Washington, DC: Of�ice of the National Coordinator for Health Information Technology.
Houston, R., & McGinnis, T. (2016, Jan.). Accountable care organizations: Looking back and moving forward. Center for Health Care Strategies. Retrieved May 2016 from http://www.chcs.org/resources/?fwp_paged=4 (http://www.chcs.org/resources/?fwp_paged=4)
Institute for Health Technology Transformation. (2012). Population health management: A Roadmap for provider-based automation in a new era of healthcare. Retrieved May 2016 from http://iht2.ihealthtran.com/blast372.html (http://iht2.ihealthtran.com/blast372.html)
Jaspen, B. (2015, May). Value-based care will drive Aetna’s future goals. Forbes. Retrieved May 2016 from http://www.forbes.com/sites/brucejapsen/2015/05/15/value-based-care-may-drive-aetna-bid-for-cigna-or- humana/#3a9f829e6512 (http://www.forbes.com/sites/brucejapsen/2015/05/15/value-based-care-may-drive-aetna-bid-for-cigna-or- humana/#3a9f829e6512)
Kindig, D., & Stoddart, G. (2003). What is population health? American Journal of Public Health, 93(3), 380–383.
Leavitt Partners. (2015, Dec.). Projected growth of accountable care organizations. Retrieved May 2016 from http://leavittpartners.com/2015/12/projected-growth-of-accountable-care-organizations-2/ (http://leavittpartners.com/2015/12/projected-growth-of-accountable-care-organizations-2/)
Miller, H. D. (2011). Transitioning to accountable care: Incremental payment reforms to support higher quality, more affordable health care. Pittsburgh, PA: Center for Healthcare Quality and Payment Reform.
The National Committee for Quality Assurance (NCQA). (2015, June). Latest evidence: Bene�its of the patient-centered medical home. Retrieved May 2016 from https://www.ncqa.org/Portals/0/Programs/Recognition/PCMHEvidenceReportJune2015_Web.pdf? ver=2016-02-24-143948-347 (https://www.ncqa.org/Portals/0/Programs/Recognition/PCMHEvidenceReportJune2015_Web.pdf?ver=2016-02-24- 143948-347)
National eHealth Collaborative (NeHC). (2011, July). Secrets of HIE success revealed: Lessons from the leaders. Washington, DC: Author.
Nielsen, M., & Shaljian, M. (2013, Oct.). Managing populations, maximizing technology: PHM in the medical neighborhood. Patient-Centered Primary Care Collaborative. Retrieved May 2016 from https://www.pcpcc.org/resource/managing-populations-maximizing- technology (https://www.pcpcc.org/resource/managing-populations-maximizing-technology)
Olivero, M. (2015, March). Is a “medical home” in your future? US News & World Report. Retrieved May 2016 from http://health.usnews.com/health-news/patient-advice/articles/2015/03/09/is-a-medical-home-in-your-future
Patient-Centered Primary Care Collaborative. (2011, March). Better to best: Value-driving elements of the patient centered medical home and accountable care organizations. Retrieved May 2016 from https://www.pcpcc.org/guide/better-best (https://www.pcpcc.org/guide/better- best)
PwC. (2012, April). Social media likes healthcare: From marketing to social business. Retrieved February 2016 from http://download.pwc.com/ie/pubs/2012_social_media_likes_healthcare.pdf (http://download.pwc.com/ie/pubs/2012_social_media_likes_healthcare.pdf)
Rudin, R. S., Salzberg, C. A., Szolovitis, P., Volk, L. A., Simon, S. R., & Bates, D. W. (2011). Care transitions as opportunities for clinicians to use data exchange services: How often do they occur? Journal of the American Medical Informatics Association, 18(6), 853–859.
Tweet, M. S., Gulati, R., Aase, L. A., & Hayes, S. N. (2011). Spontaneous coronary artery dissection: A disease-speci�ic, social networking community–initiated study. Mayo Clinic Proceedings, 86(9), 845–850.
US Department of Health & Human Services (US DHHS). (2015, Jan.). Better, smarter, healthier: In historic announcement, HHS sets clear goals and timeline for shifting Medicare reimbursements from volume to value. Retrieved May 2016 from http://www.hhs.gov/about/news/2015/01/26/better-smarter-healthier-in-historic-announcement-hhs-sets-clear-goals-and- timeline-for-shifting-medicare-reimbursements-from-volume-to-value.html (http://www.hhs.gov/about/news/2015/01/26/better- smarter-healthier-in-historic-announcement-hhs-sets-clear-goals-and-timeline-for-shifting-medicare-reimbursements-from-volume-to-value.html)
Ulrich, T. (2015, October). What can patients’ tweets teach us about their health care experiences? Boston Children’s Hospital Notes. Retrieved February 2016 from http://notes.childrenshospital.org/twitter-as-a-patient-experience-measurement-tool/ (http://notes.childrenshospital.org/twitter-as-a-patient-experience-measurement-tool/)
Vest, J. R., & Gamm, L. D. (2010). Health information exchange: Persistent challenges and new strategies. Journal of the American Medical Informatics Association, 17, 288–294.
Part Two Selection, Implementation, Evaluation, and Management of Health Care Information Systems
Chapter 5 System Acquisition
To be able to explain the process a health care organization generally goes through in selecting a health care 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 vendor 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 health care IT industry and the resources available for identifying health care 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 health care information systems and the value they can bring to health care organizations and the patients they serve. This chapter describes the typical process a health care 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 ef�icient 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 bene�its, and without gaining suf�icient 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.
5.1 System Acquisition: A De�inition 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 (c12.xhtml) . 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 �inancial resources to embark on the initiative. These tools can be found at https://healthit.ahrq.gov/health-it-tools-and-resources (https://healthit.ahrq.gov/health-it- tools-and-resources) . Additionally, the Of�ice 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 (https://www.healthit.gov/providers-professionals/ehr-implementation-steps) .
5.2 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 speci�ic 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 (http://content.thuzelearning.com/books/Wager.8743.17.1/sections/c05anchor-3#c05-�ig-0001) ). Each phase has a number of tasks that need to be performed. In this chapter we focus on the �irst two phases; Chapter Six (c06.xhtml) focuses on the last two.
Figure 5.1 (http://content.thuzelearning.com/books/Wager.8743.17.1/sections/c05anchor-3#backF1) Systems development life cycle
The SDLC approach assumes that this four-phase life of an IS starts with a need and ends when the bene�its 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 de�ined (in actuality it is at times dif�icult 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, �inancially, 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 work�low processes, the health care team might �ind that current problems are rooted in ineffective procedures or lack of suf�icient 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 de�ine the functional requirements: What functions must the system have to ful�ill 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 de�ining system requirements, the organization speci�ies what the system should be able to do and the means by which it will ful�ill 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 health care organizations purchase a system from a vendor or at least look �irst 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-bene�it analysis is done, a system is selected, and vendor negotiations are �inalized.
After the contract has been �inalized or the system has been chosen, the third phase, implementation, begins. The implementation phase requires signi�icant allocation of resources in completing tasks, such as conducting work-�low 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 �ixed, and upgrades installed. Likewise, most mission-critical systems need to be functioning 99.99 percent of the time—that is, with little downtime. Suf�icient 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 �irst two phases—the planning and analysis phase and the design phase. Together they constitute what we refer to as the system acquisition process.
5.3 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—speci�ically, 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 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 (http://content.thuzelearning.com/books/Wager.8743.17.1/sections/c05anchor-4#c05-exe-1) ), relating them to the multiphysician practice scenario. We assume that the practice wishes to purchase (rather than develop) an EHR system. However, we brie�ly 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 (http://content.thuzelearning.com/books/Wager.8743.17.1/sections/c05anchor-4#backex1) Overview of System Acquisition Process
Establish project steering committee and appoint project manager.
De�ine project objectives and scope of analysis.
Screen the marketplace and review vendor pro�iles.
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 system (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-bene�it analysis.
Prepare summary report and recommendations.
Conduct contract negotiations.
Establish a Project Steering Committee One of the �irst 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 of�icers (CMIOs) or chief nursing informatics of�icers (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 (c08.xhtml) .) 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 �ifteen-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, �ifteen support staff members, a business of�icer manager, an accountant, and a chief executive of�icer (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 �itness 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 of�icer 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 Of�ice of the National Coordinator for Health Information Technology (ONC)–certi�ied EHR products. He is intrigued with the idea of cloud-based EHR systems provided they can ensure safety, security, and con�identiality 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 �ive project goals and the methods they would use to guide their activities. Ms. Moore, the consultant, assisted them in clearly de�ining these goals and discussing the various options for moving forward. They agreed to consider EHR products only from those vendors that had �ive or more years of experience in the industry and had a solid track record of implementations (which they de�ined as having done twenty-�ive 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 �ive 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 de�ining 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 de�inition 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 of�icers (CIOs) in surrounding hospitals who had experience with ambulatory care EHR to get their advice. This initial screening resulted in the identi�ication 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 �irm 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 �inalists. Mr. Rowls checked references and prepared the �inal vendor analysis. A detailed cost-bene�it analysis was conducted, and the three vendors were ranked. All three vendors, in rank order, were presented in the �inal 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 �inalized 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 of�icer 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 �ive 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 �ifteen 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, 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 health care IT professional who might serve in a consultative role and help the committee direct its activities appropriately.
De�ine Project Objectives and Scope of Analysis Once the project steering committee has been established, its �irst order of business is to clarify the charge to the committee and to de�ine 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-de�ined, 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- certi�ied. Users can be assured that certi�ied EHR products meet certain standards for content, functionality, and interoperability.
The committee further stipulated that it would consider only vendors with experience (for example, �ive or more years in the industry) and those with a solid track record of system installations (for example, twenty-�ive or more installations). The committee members felt the practice should contract with a system developer only if they were unable to �ind 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 Pro�iles Concurrently with the establishment of project goals, the project steering committee should conduct its �irst, cursory review of the EHR marketplace and begin investigating vendor pro�iles. 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 �irms 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 de�ine 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 de�ined, speci�ic, and measurable terms. For example, a system goal such as “select a new EHR system” is very broad and not speci�ic. Here are some examples of speci�ic 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 ef�iciency 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 speci�ic 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 of�ice 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 speci�ications that can be prioritized or ranked. This ranking should directly re�lect the speci�ic 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 de�ined 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 speci�ications, 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 de�ined 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. 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
Con�identiality statement and instructions: a statement that the RFP and the responses provided by the vendor are con�idential and are proprietary information
Speci�ic 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 work�low and business processes can provide meaningful information during the selection process (Corrao, Robinson, Swiernik, & Naeim, 2010; Eisenstein, Jurwishin, Kushniruk, & Nahm, 2011; IOM, 2011).
Vendor quali�ications: *general background of vendor, experience, number of installations, �inancial 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 bene�its of its proposed solution.
Criteria for evaluating proposals: how the health care organization will make its �inal decisions on product selection
General contractual requirements: *warranties, payment schedule, penalties for failure to meet schedules speci�ied 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-�inding 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 �ield 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 health care organization to de�ine 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 �ive is ideal), the project steering committee may be overwhelmed and �ind it dif�icult 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 suf�icient 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 speci�ic 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 health care 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 quali�ied personnel at the salaries they demand may be dif�icult, 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 �inancial arrangements can be particularly appealing. Because many vendors offer cloud-based services on �ixed 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 �lexibility, so as the practice or organization grows or shrinks in size or volume, they pay only for the services used. Other bene�its
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 speci�ied 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 �irm. 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 signi�icant competitive advantage. The costs and time needed to develop the application can be signi�icant, however. It is also important to consider the long-term costs. If the developer leaves, how dif�icult 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 �irst 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 (http://content.thuzelearning.com/books/Wager.8743.17.1/sections/c05anchor-4#c05-tbl-0001) 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 (http://content.thuzelearning.com/books/Wager.8743.17.1/sections/c05anchor-4#backT1) 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
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 �ield 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 re�lect 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 organization 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 (http://content.thuzelearning.com/books/Wager.8743.17.1/sections/c05anchor-4#c05-�ig-0002) 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 (http://content.thuzelearning.com/books/Wager.8743.17.1/sections/c05anchor-4#backF2) 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 bene�icial 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 speci�ic system was being used, the problems that had been encountered, and how these problems had been addressed.
How satis�ied 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 �irsthand 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 �ield, 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 �indings 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-Bene�it Analysis The �inal analysis should include an evaluation of the cost and bene�its of each proposed system. Figure 5.3 (http://content.thuzelearning.com/books/Wager.8743.17.1/sections/c05anchor-4#c05-�ig-0003) shows a comparison of six vendor products. Criteria were developed to score and rank each vendor’s system. As the �igure illustrates, the selection committee ranked vendor 4 the top choice.
Figure 5.3 (http://content.thuzelearning.com/books/Wager.8743.17.1/sections/c05anchor-4#backF3) Cost-bene�it 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 identi�ied, it is important to weigh them against the bene�its of the systems being considered. Can the bene�its be quanti�ied? Should they be included in the �inal 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 �inal report that summarizes the process and results from each major activity or event. The report may include these elements:
System goals and criteria
Results of each activity and conclusions
Final recommendation and ranking of vendors
It is generally advisable to have two or three vendors in the �inal ranking, in the event that problems arise with the �irst choice during contract negotiations, the �inal step in the system acquisition process.
Conduct Contract Negotiations The �inal 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 �inancial liability for failing to deliver on time), how much customization can be performed by the organization purchasing the system, how con�identiality 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, work�low redesign, application implementation, integration requirements, and infrastructure development and upgrades, all of which can consume substantial resources.
5.4 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)
Timeline of committee activities (for example, Gantt chart)
System requirements (mandatory and desirable)
Evaluation forms for
Responses to RFPs
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 (http://content.thuzelearning.com/books/Wager.8743.17.1/sections/c05anchor-5#c05-�ig-0004) ) 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 �inancial 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.)
Figure 5.4 (http://content.thuzelearning.com/books/Wager.8743.17.1/sections/c05anchor-5#backF4) Example of a simple Gantt chart
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 brie�ings to informal discussions at lunch.
5.5 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 in�luencing 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 de�ined 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 underdoing 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 �inal 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 �inal. 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.
5.6 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 health care 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 de�inition of architecture
Observations about architecture
A De�inition 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 in�luenced 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 ef�icient or handicap accessible, for example). For an organization’s information systems, the development of an architecture is in�luenced by the organization’s objectives (EHRs that span multiple hospitals, for example) and the systems’ desired properties (ef�icient 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 re�lects 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 speci�ic 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 speci�ic 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 health care information system. Infrastructure refers to the entire base of IT that an organization uses—its networks, servers, workstations, and so on. Organizations choose speci�ic platforms from speci�ic 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 speci�ic, it is not quite as broad a term as architecture, which encompasses much more than speci�ic 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) de�ines architecture as “the set of organizational, management, and technical strategies and tactics used to ensure that the organization’s information systems have critical, organizationally de�ined characteristics and capabilities.” For example, an organization can decide that it wants an information system that has characteristics such as being agile, ef�icient 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 in�luence 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.
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 �ind 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 codi�ied clinical data
Statement. We want all of our systems to be easy and ef�icient 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 �inger-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 (c13.xhtml) , the organizations that have been very effective in their applications of IT over many years have had a signi�icant focus on architecture. They have realized that thoughtful approaches to agility, cost ef�iciency, and reliability have a signi�icant impact on their ability to continue to apply technology to improve organizational performance. For example, information systems that are not agile can be dif�icult (or impossible) to change as the organization’s needs evolve. This ossi�ication 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 �low 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 user name 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.
Ef�iciently 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 uni�ied 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 these 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 health care 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 multiphysician 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) de�ining 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-bene�it 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.
Key Terms Acquisition process
Planning and analysis phase
Project steering committee
Request for information (RFI)
Request for proposal (RFP)
Support and evaluation phase
Systems development life cycle (SDLC)
Learning Activities Interview a health care executive regarding the process last used by his or her organization to acquire a new information system. How did that process compare with the system acquisition process described in this chapter?
Assume you are part of a project steering committee in a rural nonpro�it hospital. The hospital is interested in replacing its legacy EHR system. You offer to screen the marketplace to see what types of EHRs are available. Prepare a �ifteen-minute summary report of your �indings to the committee at large.
Conduct a literature review (including an Internet search) on various cloud-based computing services available in health care. What criteria might you use to compare them? How do they differ in terms of service, support, and �inancing arrangements?
Find and critique a sample RFP for a health care organization. What did you like about it? What aspects of it did you feel could be improved? Explain.
This chapter described a typical physician practice that wishes to select an EHR system. Using the information in the Valley Practice scenario, draft a script for vendors to use in demonstrating their products and services to Valley Practice staff members. Include a description of the process you used to arrive at the script.
Working with your classmates in small groups, assume that you are a Valley Practice committee member interested in obtaining user feedback on the EHR vendor demonstrations. Develop a survey instrument that might be used to solicit and summarize participants’ responses to each vendor demonstration. Swap the survey your group designed with another group’s survey; critique each other’s work.
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 (http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_047961.hcsp?dDocName=bok1_047961)
Armbrust, M., Fox, A., Grif�ith, 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 (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). De�ining 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.
Chapter 6 System Implementation and Support
To be able to discuss the process that a health care organization typically goes through in implementing a health care information system.
To be able to assess the organizational and behavioral factors that can affect system acceptance and use and strategies for managing change.
To be able to develop a sample system implementation plan for a health care information system project, including the types of individuals who should be involved.
To gain insight into many of the things that can go wrong during system implementations and strategies that health care manager can employ to alleviate potential problems.
To be able to discuss the importance of training, technical support, infrastructure, and ongoing maintenance and evaluation of any health care information system project.
Once a health care organization has �inalized its contract with the vendor to acquire an information system, the system implementation process begins. Selecting the right system does not ensure user acceptance and success; the system must also be incorporated effectively into the day-to-day operations of the health care organization and adequately supported or maintained. Whether the system is built in-house, designed by an outside consultant, or leased or purchased from a vendor, it will take a substantial amount of planning and work to get the system up and running smoothly and integrated into operations.
This chapter focuses on the two �inal stages of the system development life cycle: implementation and then support and evaluation. It describes the planning and activities that should occur when implementing a new system. Our discussion focuses on a vendor-acquired system; however, many of the activities described also apply to systems designed in-house, by an outside developer, or acquired or leased through cloud-based computing services.
Implementing a new system (or replacing an old system) can be a massive undertaking for a health care organization. Not only are there workstations to install, databases to build, and networks to test but also there are processes to redesign, users to train, data to convert, and procedures to write. There are countless tasks and details that must be appropriately coordinated and completed if the system is to be implemented on time and within budget—and widely accepted by users. Essential to the process is ensuring that the introduction of any new health care information system or work�low change results in improved organizational performance, such as a reduction in medication errors, an improvement in care coordination, and more effective utilization of tests and procedures.
Concerns have been raised about the potential for EHRs to result in risk to patient safety. Health care information systems such as EHRs are enormously complex and involve not only the technology (hardware and software) but also people, processes, work�low, organizational culture, politics, and the external environment (licensure, accreditation, regulatory agencies). The Institute of Medicine published a report that offers health care organizations and vendors suggestions on how to work collaboratively to make health IT safer (IOM, 2011). Poor user-interface designs, ineffective work�low, and lack of interoperability are all considered threats to patient safety. Several of the suggested strategies for ensuring system safety are discussed in this chapter.
Along with attending to the many activities or tasks associated with system implementation, it is equally important to manage change effectively and address organizational and behavioral issues. Studies have shown that over half of all information system projects fail. Numerous political, cultural, behavioral, and ethical factors can affect the successful implementation and use of the new system (Ash, Anderson, & Tarczy-Hornoch, 2008; Ash, Sittig, Poon, Guappone, Campbell, & Dykstra, 2007; McAlearney, Hefner, Sieck, & Huerta, 2015; Sittig & Singh, 2011). We devote a section of this chapter to strategies for managing change and the organizational and behavioral issues that can arise during the system implementation process. The chapter concludes by describing the importance of supporting and maintaining information systems.
6.1 System Implementation Process System implementation begins once the organization has acquired the system and continues through the early stages following the go-live date (the date when the system is put into general use for everyone). Similar to the system acquisition process, the system implementation process must have a high degree of support from the senior executive team and be viewed as an organizational priority. Suf�icient staff, time, and resources must be devoted to the project. Individuals involved in rolling out the new system should have suf�icient resources available to them to ensure a smooth transition.
The time and resources needed to implement a new health care information system can vary considerably depending on the scope of the project, the needs and complexity of the organization, the number of applications being installed, and the number of user groups involved. There are, however, some fundamental activities that should occur during any system implementation, regardless of its size or scope:
Organize the implementation team and identify a system champion.
Clearly de�ine the project scope and goals.
Identify accountability for the successful completion of the project.
Establish and institute a project plan.
Failing to appropriately plan for and manage these activities can lead to cost overruns, dissatis�ied users, project delays, and even system sabotage. In fact, during the industry rush to take advantage of CMS incentive dollars, a �lurry of EHR stories hit the news—with everything from CIOs and CEOs losing their jobs as a result of “failed” EHR implementations, to hospital operations screeching to a halt, to signi�icant �inancial problems arising from glitches in the revenue cycle. These high-pro�ile cases brought national attention to the consequences of a failed implementation. During system implementation, facilities often see their days in accounts receivable and denials increase while cash �low slows. By organizations anticipating risks to the revenue cycle prior to go-live and as part of EHR work�low, they are in a much better position to stay on track and maintain positive �inancial performance during the transition (Daly, 2016). In today’s environment, in which capital is scarce and resources are limited, health care organizations cannot afford to mismanage implementation projects of this magnitude and importance. Examining lessons learned from others can be helpful.
Organize the Implementation Team and Identify a Champion One of the �irst steps in planning for the implementation of a new system is to organize an implementation team. The primary role and function of the team is to plan, coordinate, budget, and manage all aspects of the new system implementation. Although the exact team composition will depend on the scope and nature of the new system, a team might include a project leader, system champion(s), key individuals from the clinical and administrative areas that are the focus of the system being acquired, vendor representatives, and information technology (IT) professionals. For large or complex projects, it is also a good idea to have someone skilled in project management principles on the team. Likewise, having a strong project leader and the right mix of people is critically important.
Implementation teams often include some of the same people involved in selecting the system; however, they may also include other individuals with knowledge and skills important to the successful deployment of the new system. For example, the implementation team will likely need at least one IT professional with technical database and network administration expertise. This person may have had some role in the selection process but is now being called on to assume a larger role in installing the software, setting up the data tables, and customizing the network infrastructure to adequately support the system and the organization’s needs.
The implementation team should also include at least one system champion. A system champion is someone who is well respected in the organization, sees the new system as necessary to the organization’s achievement of its strategic goals, and is passionate about implementing it. In many health care settings the system champion is a physician, particularly when the organization is implementing a system that will directly or indirectly affect how physicians spend their time. The physician champion serves as an advocate of the system, assumes a leadership role in gaining buy-in from other physicians and user groups, and makes sure that physicians have adequate input into the decision-making process. Other important qualities of system champions are strong communication, interpersonal, and listening skills. The system champion should be willing to assist with pilot testing, to train and coach others, and to build consensus among user groups (Miller & Sim, 2004). Numerous studies have demonstrated the importance of the system champion throughout the implementation process (Ash, Stavri, Dykstra, & Fournier, 2003; Daly, 2016; Miller, Sim, & Newman, 2003; Wager, Lee, White, Ward, & Ornstein, 2000; Yackanicz, Kerr, & Levick, 2010). When implementing clinical applications that span numerous clinical areas, such as nursing, pharmacy, and physicians, having a system champion from each division can be enormously helpful in gaining buy-in and in facilitating communication among staff members. The various system champions can also assume a pivotal role in ensuring that project milestones are achieved and celebrated.
Clearly De�ine the Project Scope and Goals One of the implementation team’s �irst items of business is to determine the scope of the project and develop tactical plans. To set the tone for the project, a senior health care executive should meet with the implementation team to communicate how the project relates to the organization’s overall strategic goals and to assure the team of the administration’s commitment to the project. The senior executive should also explain what the organization or health system hopes the project will achieve.
The goals of the project and what the organization hopes to achieve by implementing the new system should emerge from early team discussions. The system goals de�ined during the system selection process (discussed in Chapter Five (c05.xhtml) ) should be reviewed by the implementation team. Far too often health care organizations skip this important step and never clearly de�ine the scope of the project or what they hope to gain as a result of
the new system. At other times they de�ine the scope of the project too broadly or scope creep occurs. The goals should be speci�ic, measurable, attainable, relevant, and timely. They should also de�ine the organization’s criteria for success (Cusack & Poon, 2011).
Let’s look at two hypothetical examples from two providers that we will call Rutledge Retirement Community and St. Luke’s Medical Center. The implementation team at Rutledge Retirement Community de�ined its goal and the scope of the project and devised measures for evaluating the extent to which Rutledge achieved this goal. The implementation team at St. Luke’s Medical Center was responsible for completing Phase 1 of a three-part project; however, the scope of the team’s work was never clearly de�ined.
Rutledge Retirement Community
Rutledge Retirement Community in a Commission on Accreditation of Rehabilitation Facilities (CARF)–accredited continuum of care community offers residential, assisted living, and skilled care to residents in southern Georgia. An implementation team was formed and charged with managing all aspects of the EHR rollout. Rutledge’s mission is to be “the premier continuum of care facility in the region providing high-quality, resident- centered care with family engagement.” Considering how to achieve this mission, the team identi�ied the EHR as the building block needed to improve care coordination, reduce medication errors, and create communication channels with families of residents by offering a family portal. In addition to establishing this goal, the team went a step further to de�ine what a successful EHR implementation initiative would consist of. Team members then developed a core set of metrics—reduction in medication errors, reduction in duplicate services, and increased communication with family regarding residents’ health status. Family and caregiver satisfaction with communication were also assessed.
St. Luke’s Medical Center
St. Luke’s Medical Center set out to implement a digital medical record, planning to do so in three phases. Phase 1 would involve establishing a clinical data repository, a central database from which all ancillary clinical systems would feed. Phase 2 would consist of the implementation of computerized physician order entry (CPOE) and nursing documentation systems, and Phase 3 would see the elimination of all outside paper reports through the implementation of a document-imaging system. St. Luke’s staff members felt that if they could complete all three phases, they would have, in essence, a true electronic or digital patient record. The implementation team did not, however, clearly de�ine the scope of its work. Was it to complete Phase 1 or all three phases? Likewise, the implementation team never de�ined what it hoped to accomplish or how implementation of the digital record �it into the medical center’s overall mission or organizational goals. It never answered the question, How will we know if we are successful? Some project team members argued that a digital record was not the same as an EHR and questioned whether the team was headed down the right path. The ambiguity of the implementation team’s scope of work led to disillusionment and a sense of failing to ever �inish the project.
Identify Accountability for the Successful Completion of the Project Four roles are important in the management of large health care information system projects:
The business sponsor is the individual who holds overall accountability for the project. The sponsor should represent the area of the organization that is the major recipient of the performance improvement that the project intends to deliver. For example, a project that involves implementing a new claims processing system may have the chief �inancial of�icer as the business sponsor. A project to improve nursing work�low may ask the chief nursing of�icer to serve as business sponsor. A project that affects a large portion of the organization may have the CEO as the business sponsor.
The sponsor’s management or executive level should be appropriate to the magnitude of the decisions and the support that the project will require. The more signi�icant the undertaking, the higher the organizational level of the sponsor.
The business sponsor has several duties:
Secures funding and needed business resources—for example, the commitment of people’s time to work on the project
Has �inal decision-making and sign-off accountability for project scope, resources, and approaches to resolving project problems
Identi�ies and supports the business owner(s) (discussed in the next section)
Promotes the project internally and externally and obtains the buy-in from business constituents
Chairs the project steering committee and is responsible for steering committee participation during the life of the project
Helps de�ine deliverables, objectives, scope, and success criteria with identi�ied business owners and the project manager
Helps remove business obstacles to meeting the project timeline and producing deliverables, as appropriate
A business owner generally has day-to-day responsibility for running a function or a department; for example, a business owner might be the director of the clinical laboratories. A project may need the involvement of several business owners. For example, the success of a new patient accounting system may depend on processes that occur during registration and scheduling (and hence the director of outpatient clinics and the director of the admitting department will both be business owners) and may also depend on adequate physician documentation of the care provided (and hence the administrator of the medical group will be another business owner).
Business owners often work on the project team. Among their several responsibilities are the following:
Representing their department or function at steering committee and project team meetings
Securing and coordinating necessary business and departmental resources
Removing business obstacles to meeting the project timeline and producing deliverables, as appropriate
Working jointly with the project manager on several tasks (as described in the next section)
The project manager does just that—manages the project. He or she is the person who provides the day-to-day direction setting, con�lict resolution, and communication needed by the project team. The project manager may be an IT staffer or a person in the business, or function, bene�iting from the project. Among their several responsibilities, project managers accomplish the following:
Identify and obtain needed resources.
Deliver the project on time, on budget, and according to speci�ication.
Communicate progress to sponsors, stakeholders, and team members.
Ensure that diligent risk monitoring is in place and appropriate risk mitigation plans have been developed.
Identify and manage the resolution of issues and problems.
Maintain the project plan.
Manage project scope.
The project manager works closely with the business owners and business sponsor in performing these tasks. Together they set meeting agendas, manage the meetings, track project progress, communicate project status, escalate issues as appropriate, and resolve deviations and issues related to the project plan.
The IT manager is the senior IT person assigned to the project. In performing his or her responsibilities, the IT manager does the following:
Represents the IT department
Has �inal IT decision-making authority and sign-off accountability
Helps remove IT obstacles to meeting project timelines and producing deliverables
Promotes the project internally and externally and obtains buy-in from IT constituents
Establish and Institute a Project Plan Once the implementation team has agreed on its goals and objectives and has identi�ied key individuals responsible for managing the project, the next major step is to develop and implement a project plan. The project plan should have the following components:
Major activities (also called tasks)
Estimated duration of each activity
Any dependencies among activities (so that, for example, one task must be completed before another can begin)
Resources and budget available (including staff members whose time will be allocated to the project)
Individuals or team members responsible for completing each activity
Measures for evaluating completion and success
These are the same components one would �ind in most major projects. What are the major activities or tasks that are unique to system implementation projects? Which tasks must be completed �irst, second, and so forth? How should time estimates be determined and milestones de�ined?
System implementation projects tend to be quite large, and therefore it can be helpful to break the project into manageable components. One approach to de�ining components is to have the implementation team brainstorm and identify the major activities that need to be done before the go-live date. Once these tasks have been identi�ied, they can be grouped and sequenced based on what must be done �irst, second, and so forth. Those tasks that can occur concurrently should also be identi�ied (see Figure 6.1 (http://content.thuzelearning.com/books/Wager.8743.17.1/sections/c06anchor-2#c06-�ig-0001) .). A team may �ind it helpful to use a consultant to guide it through the implementation process. Or the health care IT vendor may have a suggested implementation plan; the team must make sure, however, that this plan is tailored to suit the unique needs of the organization in which the new system is to be introduced.
The subsequent sections describe the major activities common to most information system implementation projects (outlined in the “Typical Components of an Implementation Plan” box) and may serve as a guide. These activities are not necessarily in sequential order; the order used should be determined by the institution in accordance with its needs and resources.
Work�low and Process Analysis One of the �irst activities necessary in implementing any new system is to review and evaluate the existing work�low or business processes. Members of the implementation team might also observe the current information system in use (if there is one). Does it work as described? Where are the problem areas? What are the goals and expectations of the new system? How do organizational processes need to change in order to optimize the new system’s value and achieve its goals? Too often organizations never critically evaluate current business processes but plunge forward implementing the new system while still using old procedures. The result is that they simply automate their outdated and inef�icient processes.
Before implementing any new system, the organization should evaluate existing procedures and processes and identify ways to improve work�low, simplify tasks, eliminate redundancy, improve quality, and improve user (customer) satisfaction. In complex settings, it can be critically important to have informatics professionals such as CMIOs and CNIOs actively involved in the implementation team in analyzing work�low and information �low (Elias, Barginere, Berry, & Selleck, 2015). Although describing them is beyond the scope of this book, many extremely useful tools and methods are available for analyzing work�low and redesigning business processes (see, for example, Guide to Reducing Unintended Consequences of Electronic Health Records, by Jones, Koppel, Ridgley, Palen, Wu, & Harrison, 2011). Observing the old system in use, listening to users’ concerns, and evaluating information work�low can identify many of the changes needed. In addition, the vendor generally works with the organization to map its future work�low using �lowcharts or �low diagrams. It is critical that all key areas affected by the new system participate in the work�low analysis process so that potential problems can be identi�ied and addressed before the system goes live. For example, if a new CPOE application is to be implemented using a phased-in approach, in which the system will go-live unit by unit over a three-month process, how will the organization ensure orders are not lost or duplicated if a patient is transferred between a unit using CPOE and a unit using handwritten orders? What will downtime procedures entail? If paper orders are generated during downtime, how will these orders be stored or become part of the patient’s permanent medical record?
Figure 6.1 (http://content.thuzelearning.com/books/Wager.8743.17.1/sections/c06anchor-2#backF1) Project timeline with project phases
Typical Components of an Implementation Plan
Work�low and process analysis
Analyze or evaluate current process and procedures.
Identify opportunities for improvement and, as appropriate, effect those changes.
Identify sources of data, including interfaces to other systems.
Determine location and number of workstations needed.
Redesign physical location as needed.
Determine system con�iguration.
Order and install hardware.
Prepare data center.
Upgrade or implement IT infrastructure.
Install software and interfaces.
Test, retest, and test again . . .
Identify appropriate training method(s) to be used for each major user group.
Prepare training materials.
Train staff members.
Test staff member pro�iciency.
Update procedure manuals.
Establish communication mechanisms for identifying and addressing problems and concerns.
Communicate regularly with various constituent groups.
Preparation for go-live date
Select date when patient volume is relatively low.
Ensure suf�icient staff members are on hand.
Set up mechanism for reporting and correcting problems and issues.
Review and effect process reengineering.
System downtime procedures
Develop downtime procedures.
Train staff members on downtime procedures.
Involving users at this early stage of the implementation process can gain initial buy-in to the idea and the scope of the process redesign. In all likelihood, the organization will need to institute a series of process changes as a result of the new system. Work�low and processes should be evaluated critically and redesigned as needed. For example, the organization may �ind that it needs to do away with old forms or work steps, change job descriptions or job responsibilities, or add to or subtract from the work responsibilities of particular departments. Getting users involved in this reengineering process can lead to greater user acceptance of the new system.
Let’s consider an example. Suppose a multiphysician clinic is implementing a new practice management system that includes a patient portal for appointment scheduling, prescription re�ills, and paying bills. The clinic might wish to begin by appointing a small team of individuals knowledgeable about analyzing work�low and processes to work with staff members in studying the existing process for scheduling patient appointments, re�illing prescriptions, and patient billing. This team might conduct a series of individual focus groups with schedulers, physicians and nurses, and patients, and ask questions such as these:
Who can schedule patient appointments?
How are patient appointments made, updated, or deleted?
Who has access to scheduling information? From what locations?
How well does the current system work? How ef�icient is the process?
What are the major problems with the current scheduling system and process? In what ways might it be improved?
The team should tailor the focus questions so they are appropriate for each user group. The answers can then be a guide for reengineering existing processes and work�low to facilitate the new system. A similar set of questions could be asked concerning the re�ill of prescriptions or patient billing processes.
During the work�low analysis, the team should also examine where the new system’s actual workstations will be located, how many workstations will be needed, and how information will �low between manual organizational processes (such as phone calls) and the electronic information system. Here are a few of the many questions that should be addressed in ensuring that physical layouts are conducive to the success of the new system:
Will the workstations be portable or �ixed? If users are given portable units, how will these be tracked and maintained (and protected from loss or theft)? If workstations are �ixed, will they be located in safe, secure areas where patient con�identiality can be maintained?
How will the user interact with the new system?
Does the physical layout of each work area need to be redesigned to accommodate the new system and the new process?
Will additional wiring be needed?
How will the new system affect the work�low within the practice among of�ice staff members, nurses, and physicians?
Will the e-prescribing function with local pharmacies be affected by the change?
System Installation The next step, which may be done concurrently with the work�low analysis, is to install the hardware, software, and network infrastructure to support the new information system and build the necessary interfaces. IT staff members play a crucial role in this phase of the project. They will need to work closely with the vendor in determining system speci�ications and con�igurations and in preparing the computer center for installation. It may be, for example, that the organization’s current computer network will need to be replaced or upgraded. During implementation, having adequate numbers of computer workstations placed in readily accessible locations is critical. Those involved in the planning need to determine beforehand the maximum number of individuals likely to be using the system at the same time and accommodate this scenario. Vendors may recommend a certain number of workstations or use of hand-held devices; however, the organization must ensure the recommendations are appropriate.
Typically when a health care organization acquires a system from a vendor, quite a bit of customization is needed. IT personnel will likely work with the vendor in setting up and loading data tables, building interfaces, and running pilot tests of the hardware and software using actual patient and administrative data. It is not unlikely when purchasing a clinical application such as order entry from a vendor, for example, that the health care organization is provided a shell or basic framework from which to build the order sets or electronic forms. A great deal of customization and building of templates occurs. Thus, it is a good idea to pay physicians for their time involved in the project. For instance, if you need a physician’s time to assist in building or reviewing order sets for the cardiology division, factor that into the resources needed for the project, perhaps by allocating two hours per week to the project for a certain period of time. Otherwise, you may be pulling physicians away from seeing patients and revenue-generating activities. It demonstrates the value placed on the physician’s time and commitment to the project.
We recommend piloting the system in a unit or area before rolling out the system enterprise-wide. This test enables the implementation team to evaluate the system’s effectiveness, address issues and concerns, �ix bugs, and then apply the lessons learned to other units in the organization before most people even start using the system. Vendors will often offer guiding principles and strategies that they have found effective in implementing systems.
Consideration should be given to choosing an appropriate area (for example, a department or a location) or set of users to pilot the system. Following are some of the questions the implementation team should consider in identifying potential pilot sites:
Which units or areas are willing and equipped to serve as a pilot site? Do they have suf�icient interest, administrative support, and commitment?
Are the staff and management teams in each of these units or areas comfortable with being system guinea pigs?
Do staff members have the time and resources needed to serve in this capacity?
Is there a system champion in each unit or area who will lead the effort?
In migrating from one electronic system to another, such as from a legacy EHR to a new EHR, it may be more appropriate to go-live at once, instead of a more staggered or phased approach. For example, when Bon Secours Health System embarked on the implementation of an EHR system among fourteen hospitals, they decided after the second hospital EHR implementation to adopt the EHR vendor’s revenue cycle system along with the clinical application, and go-live with both systems at once (Daly, 2016). This enabled them to monitor clinical and �inancial indicators at the same time and ensure that the charge master and revenue cycle teams worked collaboratively prior to and following implementation.
Staff Training Training is an essential component of any new system implementation. Although no one would argue with this statement, the implementation team will want to consider many issues as it develops and implements a training program:
How much training is needed? Do different user groups have different training needs?
Who should conduct the training?
When should the training occur? What intervals of training are ideal?
What training format is best: for example, formal, classroom-style training; one-on-one or small-group training; computer-based training; or a combination of methods?
What is the role of the vendor in training?
Who in the organization will manage or oversee the training? How will training be documented?
What criteria and methods will be used to monitor training and ensure that staff members are adequately trained? Will staff members be tested on pro�iciency?
What additional training and support are available to physicians and others after go-live?
There are various methods of training. One approach, commonly known as train the trainer, relies on the vendor to train selected members of the organization who will then serve as super-users and train others in their respective departments, units, or areas. These super-users should be individuals who work directly in the areas in which the system is to be used; they should know the staff members in the area and have a good rapport with them. They will also serve as resources to other users once the vendor representatives have left. They may do a lot of one-on-one training, hand- holding, and other work with people in their areas until these individuals achieve a certain comfort level with the system. The main concern with this approach is that the organization may devote a great deal of time and resources to training the trainers only to have these trainers leave the institution (often because they’ve been lured away by career opportunities with the vendor).
Another method is to have the vendor train a pool of trainers who are knowledgeable about the entire system and who can rotate through the different areas of the organization working with staff members. The trainer pool might include IT professionals (including clinical analysts) and clinical or administrative staff members such as nurses, physicians, lab managers, and business managers.
Regardless of who conducts the training, it is important to introduce fundamental or basic concepts �irst and enable people to master these concepts before moving on to new ones. Studies among health care organizations that have implemented clinical applications such as CPOE systems have shown that classroom training is not nearly as effective as one-on-one coaching, particularly among physicians (Holden, 2011; Metzger & Fortin, 2003). Most systems can track physician use; physicians identi�ied as low-volume users may be targeted for additional training.
Timing of the training is also important. Users should have ample opportunity to practice before the system goes live. For instance, when a nursing documentation system is being installed, nurses should have the chance to practice with it at the bedside of a typical patient. Likewise, when a CPOE system is going in, physicians should get to practice ordering a set of tests during their morning rounds. This just-in-time training might occur several times, for example, three months, two months, one month, and one week before the go-live date. Its purpose is to enable users to practice on the system multiple times before go-live. Training might be supplemented with computer-based training modules that enable users to review concepts and functions at their own pace. Training has to be a priority and at least some of training should be in an environment free of distractions. Eventually staff members will want to use the system in a near-live or simulated environment. Additional staff members should be on hand during the go-live period to assist users as needed during the transition to the new system. In general, the implementation team should work with the vendor to produce a thoughtful and creative training program.
Once the details of how the new system is to work have been determined, it is important to update procedure manuals and make the updated manuals available to the staff members. Designated managers or representatives from the various areas may assume a leadership role in updating procedure manuals for their respective areas. When people must learn speci�ic IT procedures such as how to log in, change passwords, and read common error messages, the IT department should ensure that this information appears in the procedure manuals and that the information is routinely updated and widely disseminated to the users. Procedure manuals serve as reference guides and resources for users and can be particularly useful when training new employees.
Effective training is important. Staff members need to be relatively comfortable with the application and need to know to whom they should turn if they have questions or concerns. We recommend having the users evaluate the training prior to go-live.
Conversion Another important task is to convert the data from the old system to the new system and then adequately test the new system. Staff members involved in the data conversion must determine the sources of the data required for the new system and construct new �iles. It is particularly important that data be complete, accurate, and current before being converted to the new system. Data should be cleaned before being converted. Once converted, the data should run through a series of validation checkpoints or procedures to ensure the accuracy of the conversion.
IT staff members who are knowledgeable in data conversion procedures should lead the effort and verify the results with key managers from the appropriate clinical and administrative areas. The speci�ic conversion procedures used will depend on the nature of the old system and its structure as well as on the con�iguration of the new system.
Finally, the new system will need to be tested. The main purpose of the testing is to simulate the live environment as closely as possible and determine how well the system and accompanying procedures work. Are there programming glitches or other problems that need to be �ixed? How well are the interfaces working? How does response time compare to what was expected? The system should be populated with live data and tested again. Vendors, IT staff members, and user staff members should all participate in the testing process. As with training, one can never test too much. A good portion of this work has to be done for the pilot testing. It may need to be repeated before going live. And the pilot lessons will guide any additional testing or conversion that needs to be done. In some cases, it may be advisable to run the old and new systems in tandem (parallel conversion) for a period of time until it is evident that the new system is operating effectively. This can reduce organizational risk. Again, running parallel systems is not always feasible or appropriate. Instead, organizations may opt to implement the system using a phased approach over a period of time.
Communications Equally as important as successfully carrying out the activities discussed so far is having an effective plan for communicating the project’s progress. This plan serves two primary purposes. First, it identi�ies how the members of the implementation team will communicate and coordinate their activities and progress. Second, it de�ines how progress will be communicated to key constituent groups, including but not limited to the board, the senior administrative team, the departments, and the staff members at all levels of the organization affected by the new system. The communication plan may set up formal and informal mechanisms. Formal communication may include everything from regular updates at board and administrative meetings to written brie�ings and articles in the facility newsletter. The purpose should be to use as many channels and mechanisms as possible to ensure that the people who need to know are fully informed and aware of the implementation plans. Informal communication is less structured but can be equally important. Implementing a new health care information system is a major undertaking, and it is important that all staff members (day, evening, and night shifts) be made aware of what is happening. The methods for communication may be varied, but the message should be consistent and the information presented up-to-date and timely. For example, do not rely on e-mail communication as your primary method only to discover later that your organization’s nurses do not regularly check their e-mail or have little time to read your type of message.
Preparation for System Go-Live A great deal of work goes into preparing for the go-live date, the day the organization transitions from the old system to the new. Assuming the implementation team has done all it can to ensure that the system is ready, the staff members are well trained, and appropriate procedures are in place, the transition should be a smooth one. Additional staff members should be on hand and equipped to assist users as needed. It is best to plan for the system to go-live on a day when the patient census is typically low or fewer patients than usual are scheduled to be seen. Disaster recovery plans should also be in place, and staff members should be well trained on what to do should the system go down or fail. Designated IT staff members should monitor and assess system problems and errors.
System Downtime Procedures One thing that you can count on is that systems will go down. Both scheduled and unscheduled downtime exist, and downtime procedures need to be developed and communicated well before go-live. Any negative impact will be minimized if the organization has invested in a stable and secure technical IT infrastructure and backup procedures and fail-safe systems are in place. But everyone needs to know what to do if the system is down, from the registration staff members to the nursing staff members to the medical staff members and the transport team. How will orders be placed? If a paper record is kept during downtime, what is the procedure for getting the documentation in electronic form when the system is up again? How will scheduled downtime be communicated to units? And all staff members? If an organization relies heavily on computerized systems to care for patients, downtime should be minimal or near 0 percent. However, business continuity procedures must be in place to ensure patient safety and continuity of care.
6.2 Managing Change and the Organizational Aspects Implementing an informat ion system in a health care facility can have a profound impact on the organization, the people who work there, and the patients they serve. Individuals may have concerns and apprehensions about the new system: How will the new system affect my job responsibilities or productivity? How will my workload change? Will the new system cause me more or less stress? Even individuals who welcome the new system, see the need for it, and see its potential value may worry: What will I do if the system is down? Will the system impede my relationship with my patients? Who will I turn to if I have problems or questions? Will I be expected to type my notes into the system? With the new system comes change, and change can be dif�icult if not managed effectively.
Effecting Organizational Change The management strategies required to manage change depend on the type of change. As one moves from incremental to fundamental change, the magnitude and risk of the change increase enormously, as does the uncertainty about the form and success of the outcome.
Managing change has several necessary aspects:
Language and vision
Connection and trust
Planning, implementing, and iterating (Keen, 1997)
Leadership Change must be led. Leadership, often in the form of a committee of leaders, will be necessary to accomplish the following:
De�ine the nature of the change.
Communicate the rationale for and approach to the change.
Identify, procure, and deploy necessary resources.
Resolve issues and alter direction as needed.
Monitor the progress of the change initiative.
This leadership committee needs to be chaired by an appropriate senior leader. If the change affects the entire organization, the CEO should chair the committee. If the change is focused on a speci�ic area, the most senior leader who oversees that area should chair the committee.
Language and Vision The staff members who are experiencing the change must understand the nature of the change. They must know what the world will look like (to the degree that this is clear) when the change has been completed, how their roles and work life will be different, and why making this change is important. The absence of this vision or a failure to communicate the importance of the vision elevates the risk that staff members will resist the change and through subtle and not-so-subtle means cause the change to grind to a halt. Change is hard for people. They must understand the nature of the change and why they should go through with what they will experience as a dif�icult transition.
Leaders might describe the vision, the desired outcome of efforts to improve the outpatient service experience, in this way:
Patients should be able to get an appointment for a time that is most convenient for them.
Patients should not have to wait longer than ten minutes in the reception area before a provider can see them.
We should communicate clearly with patients about their disease and the treatment that we will provide.
We should seek to eliminate administrative and insurance busywork from the professional lives of our providers.
These examples illustrate a thoughtful use of language. They �irst and foremost focus on patients. But the organization also wants to improve the lives of its providers. The examples use the word should rather than the word must because it is thought that staff members won’t believe the organization can pull off 100 percent achievement of these goals, and leaders do not want to establish goals seen as unrealistic. The examples also use the word we rather than the word you. We means that this vision will be achieved through a team effort, rather than implying that those hearing this message have to bear this challenge without leadership’s help.
Connection and Trust
Achieving connection means that leadership takes every opportunity to present the vision throughout the organization. Leaders may use department head meetings, medical staff forums, one-on-one conversations in the hallway, internal publications, and e-mail to communicate the vision and to keep communicating the vision. Even when they start to feel ill because they have communicated the vision one thousand times, they have to communicate it another one thousand times. A lot of this communication has to be done in person, where others can see the leaders, rather than hiding behind an e- mail. The communication must invite feedback, criticism, and challenges.
The members of the organization must trust the integrity, intelligence, compassion, and skill of the leadership. Trust is earned or lost by everything that leaders do or don’t do. The members must also trust that leaders have thoughtfully come to the conclusion that the dif�icult change has excellent reasons behind it and represents the best option for the organization. Organizational members are willing to rise to a challenge, often to heroic levels, if they trust their leaders. Trust requires that leaders act in the best interests of the staff and the organization and that leaders listen and respond to the organization’s concerns.
Incentives Organizational members must be motivated to support signi�icant change. At times, excitement with the vision will be suf�icient incentive. Alternatively, fear of what will happen if the organization fails to move toward the vision may serve as an incentive. Although important, neither fear nor rapture is necessarily suf�icient.
If organizational members will lose their jobs or have their roles changed signi�icantly, education that prepares them for new roles or new jobs must be offered. Bonuses may be offered to key individuals, awarded according to the success of the change and each person’s contribution to the change. At times, frankly, support is obtained through old-fashioned horse-trading—if the other person will support the change, you will deliver something that is of interest to him or her (space, extra staff members, a promotion). Incentives may also take the form of awards—for example, plaques and dinners for two—to staff members who go above and beyond the call of duty during the change effort.
Planning, Implementing, and Iterating Change must be planned. These plans describe the tasks and task sequences necessary to effect the change. Tasks can range from redesigning forms to managing the staged implementation of application systems to retraining staff members. Tasks must be allotted resources, and staff members accountable for task performance must be designated.
Implementation of the plan is obviously necessary. Because few organizational changes of any magnitude will be fully understood beforehand, problems will be encountered during implementation. New forms may fail to capture necessary data. The estimate of the time needed to register a patient may be wrong and long lines may form at the registration desk. The planners may have forgotten to identify how certain information would �low from one department to another.
These problems are in addition to the problems that occur, for example, when task timetables slip and dependent tasks fall idle or are in trouble. The implementation of the application has been delayed and will not be ready when the staff members move to the new building—what do we do? Iteration and adjustment will be necessary as the organization handles problems created when tasks encounter trouble and learns about glitches with the new processes and work�lows.
Organizational and Behavioral Factors
The human factors associated with implementing a new system should not be taken lightly. A great deal of change can occur as a result of the new system. Some of the changes may be immediately apparent; others may occur over time as the system is used more fully. Many IT implementation studies have been done in recent years, and they reveal several strategies that may lead to greater organizational acceptance and use of a new system:
Create an appropriate environment, one in which expectations are de�ined, met, and managed.
Know your culture and do not underestimate user resistance.
Allocate suf�icient resources, including technical support staff members and IT infrastructure.
Provide adequate initial and ongoing training.
Manage unintended consequences, especially those known to affect implementations such as CPOE and EHR systems.
Establish strong working relationships with vendors.
Each of these strategies is described in the following sections.
Create an Appropriate Environment
If you ask a roomful of health care executives, physicians, nurses, pharmacists, or laboratory managers if they have ever experienced an IT system failure, chances are over half of the hands in the room will go up. In all likelihood the people in the room would have a much easier time describing a system failure than a system success. If you probed a little further and asked why the system was a failure, you might hear comments such as these: “the system was too slow,” “it was down all the time,” “training was inadequate and nothing like the real thing,” “there was no one to go to if you had questions or concerns,” “it added to my stress and workload,” and the list goes on. The fact is, the system did not meet their expectations. You might not know whether those expectations were reasonable or not.
Previously we discussed the importance of clearly de�ining and communicating the goals and objectives of the new system. Related to goal de�inition is the management of user expectations. Different people may have different perspectives on what they expect from the new system; in addition, some
will admit to having no expectations, and others will have joined the organization after the system was implemented and consequently are likely to have expectations derived from the people currently using the system.
Expectations come from what people see and hear about the system and the way they interpret what the system will do for them or for their organization. Expectations can be formed from a variety of sources—they may come from a comment made during a vendor presentation, a question that arises during training, a visit to another site that uses the same system, attendance at a professional conference, or a remark made by a colleague in the hallway. Furthermore, the main criterion used to evaluate the system’s value or success depends on the individual’s expectations and point of view. For example, the chief �inancial of�icer might measure system success in terms of the �inancial return on investment, the chief medical director might look at impact on physicians’ time and quality of care, the nursing staff members might consider any change in their workload, public relations personnel might compare levels of patient satisfaction, and the IT staff members might evaluate the change in the number of help desk calls made since the new system was implemented. All these approaches are measures of an information system’s perceived impact on the organization or individual. However, they are not all the same, and they may not have equal importance to the organization in achieving its strategic goals.
It is therefore important for the health care executive team not only to establish and communicate clearly de�ined goals for the new system but also to listen to needs and expectations of the various user groups and to de�ine, meet, and manage expectations appropriately. Ways to manage expectations include making sure users understand that the �irst days or weeks of system use may be rocky, that the organization may need time to adjust to a new work�low, that the technology may have bugs, and that users should not expect problem-free system operation from the start. Clear and effective communication is key in this endeavor.
In managing expectations it can be enormously helpful to conduct formative assessments of the implementation process, in which the focus is on the process as well as the outcomes. Speci�ic metrics need to be chosen and success criteria de�ined to determine whether or not the system is meeting expectations (Cusack & Poon, 2011). For example, if wide-scale use is a priority, collection of actual numbers of transactions or use logs may be meaningful information for the leadership team. Other categories of metrics that might be helpful are clinical outcome measures, clinical process measures, provider adoption and attitude measures, patient knowledge and attitude measures, work�low impact measures, and �inancial impact measures. The Agency for Healthcare Research and Quality published the Health Information Technology Evaluation Toolkit, which can serve as a guide for project teams involved in evaluating the system implementation process or project outcomes (Cusack & Poon, 2011).
Know Your Culture and Do Not Underestimate User Resistance
Before embarking on system implementation, it is critical to know your culture. Understanding the culture is important before you make the investment. For example, you might ask, How engaged and ready are the physicians and other clinicians for the new system? Are they comfortable with technology? Do you have hospitalists on staff? Or are you a community hospital in which the bulk of your medical staff members are physicians who have admitting privileges at several hospitals and make rounds only once a day? How engaged have the physicians been in the design and build of the new system? Is there strong support? If you don’t have suf�icient medical staff buy-in and support or hospitalists on staff who are committed to the project, you run the risk of encountering user resistance and system failure because of inadequate use.
During the implementation process it is also important to analyze current work�low and make appropriate changes as needed. Previously we gave an example of analyzing a patient scheduling process. Patient scheduling is a relatively straightforward process. A change in this system may not dramatically change the job responsibilities of the schedulers and may have little impact on nurses’ or physicians’ time. Therefore, these groups may offer little resistance to such a change. (This is not to guarantee a lack of resistance—if you mess up a practice’s schedule, you can have a lot of angry people on your hands!) By contrast, changes in processes that involve the direct provision of patient care services and that do affect nurses’ and physicians’ time may be tougher for users to accept. The physician ordering process is a perfect example. Historically most physicians were accustomed to picking up a pen and paper and handwriting an order or calling one in to the nurses’ station from their phones. With CPOE, physicians may be expected to keyboard their orders directly into the system and respond to automated reminders and decision-support alerts. A process that historically took them a few seconds to do might now take several minutes, depending on the number of prompts and reminders. Moreover, physicians are now doing things that were not asked of them before—they are checking for drug interactions, responding to reminders and alerts, evaluating whether evidence-based clinical guidelines apply to the patient, and the list goes on. All these activities take time, but in the long run they will improve the quality of patient care. Therefore, it is important for physicians to be actively involved in designing the process and in seeing its value to the patient care process.
Getting physicians, nurses, and other clinicians to accept and use clinical information systems can be challenging even when they are involved in the implementation. At times the incentives for using the system may not be aligned with their individual needs and goals. On the one hand, for example, if the physician is expected to see a certain number of patients per day and is evaluated on patient load and if writing orders used to take thirty minutes a day with the old system and now takes sixty to ninety minutes with the new CPOE system, the physician can either see fewer patients or work more hours. One should expect to see physician resistance. On the other hand, if the physician’s performance and income is related to adherence to clinical practice guidelines, care coordination, and patient health outcomes, using the system may be far more enticing. A recent study among six health care organizations found that more senior physicians often feel a loss of power by having junior physicians more comfortable with computers than they are and a loss in power in the physicians’ ability to shift work to others (McAlearney et al., 2015). That is, with the implementation of EHRs, the physicians were now required to use the computers and input their orders rather than delegate the tasks to junior physicians or nurses.
It perhaps goes without saying that user acceptance occurs when users see or realize the value the health care information system brings to their work and the patients they serve. This value takes different forms. Some people may realize increased ef�iciency, less stress, greater organization, and improved quality of information, whereas others may �ind that the system enables them to provide better care, avoid medical mistakes, and make better decisions. In some cases an individual may not experience the value personally yet may come to realize the value to the organization as a whole.
Allocate Suf�icient Resources
Suf�icient resources are needed during and after the new system has been implemented. User acceptance comes from con�idence in the new system. Individuals want to know that the system works properly, is stable and secure, and that someone is available to help them when they have questions, problems, or concerns. Therefore, it is important for the organization to ensure that adequate resources are devoted to implementing and supporting the system and its users. At a minimum, adequate technical staff expertise should be available as well as suf�icient IT infrastructure.
We have discussed the importance of giving the implementation team suf�icient support as it carries out its charge, but what forms can this support take? Some methods of supporting the team are to make available release time, additional staff members, and development funds. Senior managers might allocate travel funds so team members can view the system in use in other facilities. They might decide that all implementation team members or super-users will receive 50 percent release time for the next six months to devote to the project. This release time will enable those involved to give up some of their normal job duties so they can focus on the project.
Providing suf�icient time and resources to the implementation phase of the project is, however, only part of the overall support needed. Studies have shown that an information system’s value to the organization is typically realized over time. Value is derived as more and more people use the system, offer suggestions for enhancing it, and begin to push the system to ful�ill its functionality. If users are ever to fully realize the system’s value, they must have access to local technical support—someone, preferably within the organization, who is readily available, is knowledgeable about the intricacies of the system, and is able to handle hardware and software problems. This individual should be able to work effectively with the vendor and others to �ind solutions to system problems. Even though it is ideal to have local technical support in-house, that may be dif�icult in small physician of�ices or community-based settings. In such cases the facility may need to consider such options as (1) devoting a signi�icant portion of an employee’s time to training so that he or she may assume a support role, (2) partnering with a neighboring organization that uses the same system to share technical support staff members, or (3) contracting with a local computer �irm to provide the needed assistance. The vendor may be able to assist the organization in identifying and securing local technical support.
In addition to arranging for local technical support, the organization will also need to invest resources in building and maintaining a reliable, secure IT infrastructure (servers, operating systems, and networks) to support the information system, particularly if it is a mission-critical system. Many patient information systems need to be available 24 hours a day, 7 days a week, 365 days a year. Health care professionals can come to rely on having access to timely, accurate, and complete information in caring for their patents, just as they count on having electricity, water, and other basic utilities. Failing to build the IT infrastructure that will adequately support the new clinical system can be catastrophic for the organization and its IT department.
An IT infrastructure’s lifetime may be relatively short. It is reasonable to expect that within three to ten years, the hardware, software, and network will likely need to be replaced as advances are made in technology, the organization’s goals and needs change, and the health care environment changes. Downtime, scheduled and unscheduled, should be limited.
Provide Adequate Training
Previously we discussed the importance of training staff members on the new system prior to the go-live date. Having a training program suited to the needs of the various user groups is very important during the implementation process. People who will use the system should be relatively comfortable with it, have had ample opportunities to use it in a safe environment, and know where to turn should they have questions or need additional assistance. It is equally important to provide ongoing training months and even years after the system has been implemented. In all likelihood the system will go through a series of upgrades, changes will be made, and users will get more comfortable with the fundamental features and will be ready to push the system to the next level. Some users will explore additional functionality on their own; others will need prodding and additional training in order to learn more advanced features.
It is also critical to provide the type of training that works best for your users’ needs and learning preferences. Do not be afraid to have different training methods for different user groups (Holden, 2011). Memorial Sloan-Kettering Cancer Center is a perfect example. It is one of the world’s oldest private cancer centers in the world. All of its physicians are employees of the organization. When they were �irst implementing their CPOE, all clinical and administrative staff members underwent group training sessions (Sklarin, Granovsky, & Hagerty-Paglia, 2011). The system was not accepted by the physicians for a variety of reasons, and training was a critical issue. Once the leadership team realized this, they regrouped, changed tactics, and added three new approaches to working with the physicians: (1) they rolled out one service at a time with one hour of personalized training to each physician of that service (additional time did not seem to help); (2) support staff members were stationed at the clinical areas during the implementation period for individualized assistance; and (3) a physician champion was involved in work�low discussions and key in facilitating the placement of orders in the system and in helping ensure physician compliance (Sklarin et al., 2011). Understanding the culture and the physician training needs of the organization is vital when implementing a new system, as is a willingness to reevaluate the project. It is important to view the system as a long-term investment rather than a one-time purchase. The resources allocated or committed to the system should include not only the upfront investment in hardware and software but also the time, people, and resources needed to maintain and support it.
Manage Unintended Consequences
Management expertise and leadership are important elements to the success of any system implementation. Effective leaders help build a community of collaboration and trust. However, effective leadership also entails understanding the unintended consequences that can occur during complex system implementations and managing them. Unintended consequences can be positive, negative, or both, depending on one’s perspective. A decade ago, Ash and colleagues (2007) conducted interviews with key individuals from 176 US hospitals that had implemented CPOE. CPOE is one of the most complex and challenging of clinical applications to implement and a key function of EHR systems. From their work, they identi�ied eight types of unintended consequences that implementation teams should plan for and consider when implementing CPOE.
Con�licts can also occur between paper-based and electronic systems if providers who prefer paper records annotate printouts and place them in patient charts as formal documentation, in essence creating two distinct and sometimes con�licting patient records (Jones et al., 2011).
Health care executives and implementation teams should be aware of these unintended consequences, particularly those that can adversely affect the organization, and carefully plan for and manage them.
Establish Strong Working Relationships with Vendors
Developing strong working relationships with the vendor is key. The health care executive should view the vendor as a partner and an entity with which the organization will likely have a long-term relationship. This relationship often begins when the organization �irst selects a new information system and continues well after the system is live and operational. The system will have upgrades, new version releases, and ongoing maintenance contracts. It behooves both parties, the health care provider organization and the vendor, to clearly de�ine expectations, resource needs, and timelines.
It is important to have open, honest, and candid conversations when problems arise or differences in expectation occur. Equally important is for both parties to demonstrate a willingness to address needs and solve problems collaboratively.
Perspective Unintended Consequences of CPOE
More work or new work. CPOEs can increase work because systems may be slow, nonstandard cases may call for more steps in ordering, training may remain an issue, some tasks may become more dif�icult, the computer forces the user to complete “all steps,” and physicians often take on tasks that were formerly done by others.
Work�low. CPOEs can greatly alter work�low, sometimes improving work�low for some and slowing or complicating it for others.
System demands. Maintenance, training, and support efforts can be signi�icant for an organization, not only in building the system but also in making improvements and enhancements to it.
Communication. CPOE systems affect communication within the organization; they can reduce the need to clarify orders but also lead to people failing to adequately communicate with each other in appropriate situations.
Emotions. Clinician reactions to CPOE can run the gamut from positive to negative.
New kinds of errors. Although CPOE systems are generally designed to detect and prevent errors, they can lead to new types of errors such as juxtaposition errors, in which clinicians click on the adjacent patient name or medication from a list and inadvertently enter the wrong order.
Power shifts. Shifts in power may be viewed as less of a problem than some of the other unintended consequences, but CPOE can be used to monitor physician behavior.
Dependence on the system. Clinicians become dependent on the CPOE system, so managing downtime procedures is critical. Even then, while the system is down, CPOE users view the situation as managed chaos.
Source: Adapted from Ash et al. (2007). Reproduced with permission of American Medical Informatics Association.
6.3 System Support and Evaluation Information systems evolve as an organization continues to grow and change. No matter how well the system was designed and tested, errors and problems will be detected and changes will need to be made. IT staff members generally assume a major role in maintaining and supporting the information systems in the health care organization. When errors or problems are detected, IT staff members correct the problem or work with the vendor to see that the problem is �ixed. Moreover, the vendor may detect glitches and develop upgrades or patches that will need to be installed.
Many opportunities for enhancing and optimizing the system’s performance and functionality will arise well after the go-live date. The organization will want to ensure that the system is adequately maintained, supported, and further developed over time. Selecting and implementing a health care information system is an enormous investment. This investment must be maintained, just as one would maintain one’s home. In fact, health care organizations that have implemented EHR systems are now actively in the midst of optimizing use of the system in practice (Sachs & Long, 2016). Optimization can take the form of additional training, revised work�lows, adding new features or functionality, or using data from the system for quality improvement initiatives, as examples. Optimizing systems and assessing their value is discussed in Chapter Seven (c07.xhtml) .
As with other devices, information systems have a life cycle and eventually need to be replaced. Health care organizations typically go through a process whereby they plan, design, implement, and evaluate their health care information systems. Too often in the past the organization’s work was viewed as done once the system went live. It has since been discovered how vital system maintenance and support resources are and how important it is to evaluate the extent to which the system goals are being achieved.
Evaluating or accessing the value of the health care information system is increasingly important. Acquiring and implementing systems requires large investments, and stakeholders, including boards of directors, are demanding to know the actual and future value of these projects. Evaluations must be viewed as an integral component of every major health information system project and not an afterthought. Chapter Seven (c07.xhtml) is devoted to this topic.
Summary Implementing a new information system in a health care organization requires a signi�icant amount of planning and preparation. The health care organization should begin by appointing an implementation team comprising experienced individuals, including representatives from key areas in the organization, particularly areas that will be affected by or responsible for using the new system. Key users should be involved in analyzing existing processes and procedures and making recommendations for changes. A system champion should be part of the implementation team and serve as an advocate in soliciting input, representing user views, and spearheading the project. When implementing a clinical application, it is important that the system champion be a physician or clinician, someone who is able to represent the views of the care providers.
Under the direction of a highly competent implementation team, a number of important activities should occur during the system rollout. This team should assume a leadership role in ensuring that the system is effectively incorporated into the day-to-day operations of the facility. This generally requires the organization to (1) analyze work�low and processes and perform any necessary process reengineering, (2) install and con�igure the system, (3) train staff members, (4) convert data, (5) adequately test the system, and (6) communicate project progress using appropriate forums at all levels throughout the organization. Attention should be given to the countless details associated with ensuring that downtime and backup procedures are in place, security plans have been developed, and the organization is ready for the go-live date.
During the days immediately following system implementation, the organization should have suf�icient staff members on hand to assist users and provide individual assistance as needed. A stable and secure IT infrastructure should be in place to ensure minimal, ideally zero, downtime and adequate response time. The IT department or other appropriate unit or representative should have a formal mechanism in place for reporting and correcting errors, bugs, and glitches in the system.
Once the system has gone live, it is critical for the organization to have in place the plans and resources needed to adequately maintain and support the new system. Technical staff members and resources should be available to the users. Ongoing training should be an integral part of the organization’s plans to support and further develop the new system. In addition, the leadership team should have in place a thoughtful plan for evaluating the implementation process and assessing the value of the health care information system.
Beyond taking ultimate responsibility for completion of the activities needed to implement and support and evaluate the new system, the health care executive should assume a leadership role in managing change and the organizational and human aspects of the new system. Information systems can have a profound impact on health care organizations, the people who work there, and the patients they serve. Acquiring a good product and having the right technical equipment and expertise are not enough to ensure system success. Health care executives must also be attuned to the human aspects of introducing new IT into the care delivery process.
Key Terms Business owner
Train the trainer
Work�low and process analysis
Learning Activities Visit a health care organization that has recently implemented or replaced a health care information system. What process did it use to implement the system? How does that process compare with the one described in this chapter? How successful was the organization in implementing the new system? To what do staff members attribute this success?
Search the literature for a recent article on a system implementation project. Brie�ly describe the process used to implement the system and the lessons learned. How might this particular facility’s experiences be useful to others? Explain.
Physician acceptance and use of clinical information systems are often cited as challenges. What do you think the health care leadership team can or should do to foster acceptance by physicians? Assume that a handful of physicians in your organization are actively resisting a new clinical information system. How would you approach and address their resistance and concerns?
Assume you are working with an implementation team in installing a new nursing documentation system for a home health agency. Historically, all its nursing documentation was recorded in paper form. The home health agency has little computerization beyond basic registration information and has no IT staff members. What recommendations might you offer to the implementation team as it begins the work of installing the new nursing documentation system?
Discuss the risks to a health care organization in failing to allocate suf�icient support and resources to a newly implemented health care information system.
Assume you are the CEO of a large group practice (seventy-�ive physicians) that implemented an EHR system two years ago. The physicians are asking for an evaluation of the system and its impact on quality, costs, and patient satisfaction. Devise a plan for evaluating the EHR system’s impact on the organization in these three areas.
Read the executive summary of the Institute of Medicine’s (2011) report entitled Health IT and Patient Privacy: Building Safer Systems for Better Care. How can the introduction of health IT that is designed to enhance or improve patient quality and safety lead to patient safety concerns? Do you agree that patient safety is a partnership between the health care organization and health IT vendor when implementing health care information systems? Explain the role of each and your rationale.
References Ash, J. S., Anderson, N. R., & Tarczy-Hornoch, P. (2008). People and organization issues in research systems implementation. Journal of the American Medical Informatics Association, 15, 283–289.
Ash, J. S., Sittig, D. F., Poon, E. G., Guappone, K., Campbell, E., & Dykstra, R. (2007). The extent and importance of unintended consequences related to computerized provider order entry. Journal of the American Medical Informatics Association, 14(4), 415–423.
Ash, J. S., Stavri, P., Dykstra, R., & Fournier, L. (2003). Implementing computerized physician order entry: The importance of special people. International Journal of Medical Informatics, 69(2–3), 235–250.
Cusack, C., & Poon, E. (2011). Health information exchange evaluation toolkit. Agency for Healthcare Research and Quality. Retrieved February 2013 from http://healthit.ahrq.gov/portal/server.pt/community/health_it_tools_and_resources /919/health_information_exchange_(hie)_evaluation_toolkit/27870 (http://healthit.ahrq.gov/portal/server.pt/community/health_it_tools_and_resources/919/health_information_exchange_(hie)_evaluation_toolkit/27870)
Daly, R. (2016). The EHR evolution: New priorities and implementation changes. Healthcare Financial Management (Feb.), 45–50.
Elias, B., Barginere, M., Berry, P. A., & Selleck, C. S. (2015). Implementation of an electronic health records system within an interprofessional model of care. Journal of Interprofessional Care, 29(6), 551–554.
Holden, R. J. (2011). What stands in the way of technology-mediated patient safety improvements? A study of facilitators and barriers to physicians’ use of electronic health records. Journal of Patient Safety, 7(4), 193–202.
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.
Keen, P. (1997). The process edge. Boston, MA: Harvard Business School Press.
McAlearney, A. S., Hefner, J. L., Sieck, C. J., & Huerta, T. R. (2015). The journey through grief: Insights from a qualitative study of electronic health record implementation. Health Services Research, 50(2), 462–488.
Metzger, J., & Fortin, J. (2003). Computerized physician order entry in community hospitals: Lessons from the �ield. Oakland, CA: California HealthCare Foundation.
Miller, R. H., & Sim, I. (2004). Physicians’ use of electronic medical records: Barriers and solutions. Health Affairs, 23(2), 116–126.
Miller, R. H., Sim, I., & Newman, J. (2003). Electronic medical records: Lessons from small physician practices. Oakland, CA: California HealthCare Foundation.
Sachs, P. B., & Long, G. (2016). Process for managing and optimizing radiology work �low in the electronic health record environment. Journal of Digital Imaging, 29, 43–46.
Sittig, D. F., & Singh, H. (2011). De�ining health information technology-related errors: New developments since To Err Is Human. Archives of Internal Medicine, 171(14), 1281–1284.
Sklarin, N. T., Granovsky, S., & Hagerty-Paglia, J. (2011). Electronic health record implementation at an academic cancer center: Lessons learned and strategies for success. American Society of Clinical Oncology, pp. 411–415.
Wager, K. A., Lee, F., White, A., Ward, D., & Ornstein, S. (2000). Impact of an electronic medical record system on community-based primary care practices. Journal of the American Board of Family Practice, 13(5), 338–348.
Yackanicz, L., Kerr, R., & Levick, D. (2010). Physician buy-in for EMRs. Journal of Healthcare Information Management, 24(2), 41–44.