Nicohwilliam

Assignment : answer real world case 11.1questions; at least one

Page per case ; cite textbook

Please see chapter readings from textbook below if needed

Real World Case Study 11.1  

A diabetic patient, John, moves to a new city and uses the internet to select a local primary care physician (PCP), who is a generalist physician and will coordinate his overall care. He can select a PCP who appears to have strong outcomes in diabetes and positive patient satisfaction scores. John schedules an appointment via the physician’s website and is set up with a user ID and password to link the PCP with John’s PHR, which is a record he maintains himself by uploading copies of records from various providers he has seen over the years. This enables the PCP to view and retrieve pertinent information from other providers and information John has recorded about his diet, over-the-counter medications taken, and other information related to compliance with his diabetic treatment regimen.

John asks his former hometown physician to send information to his new PCP. The physician does so using standard content and format specifications for exchanging referral information ­between providers. With the information supplied by the PHR and his former PCP, the new PCP’s EHR is prepopulated with a current problem list, recent laboratory results, and other data. Additionally, the new PCP can add John’s medication history to the EHR by linking to information available from John’s health plan.

When John visits the new PCP, information from these various sources will be validated and updated. The new PCP can document all components of John’s visit at the time of the visit, including demonstrating medical necessity for lab work by applying ICD diagnosis codes and ­generating ­appropriate evaluation and management (E/M) codes for the level of service provided. The PCP decides to put John on a strict smoking-cessation program and exercise routine, with plans to adjust medications according to John’s vital signs and blood sugar levels, which will be monitored remotely through a medical device.

All is going well until John has an accident at work that requires a visit to the emergency department, subsequent admission to the hospital, and outpatient physical therapy. All his providers, however, are members of a health information organization (HIO). As a result, each provider has immediate access to the specific information needed to treat John throughout his care and for which John has provided a consent directive enabling him to opt in to the sharing of such information with all participants in the HIO.

At the hospital, the physician providing care can reconcile all of John’s medications in accordance with the Joint Commission requirements and select medications that have been screened against John’s known allergies. The hospital is also part of a health reform mechanism that ties reimbursement to quality metrics. This improves the quality of healthcare and reduces costs in an assigned population of patients. As a result, the hospital has access to John’s previous lab and x-ray results, so repeating these lab tests is not necessary—saving John time and potential health risks and reducing overall costs. In selecting the physical therapy referral, the hospitalist has access to John’s health plan benefits information, so no time is wasted in arranging for physical therapy to begin.

John’s PCP also continuously monitors the impact of the accident on John’s diabetes during his hospitalization and makes appropriate adjustments. After John is discharged and in physical therapy, the health plan can monitor whether he is following the prescribed exercise routine and can notify the PCP to follow up if necessary. John can access tailored discharge instructions that superimpose his picture on the exercise instructions so that it is clear how to avoid further injury. In addition, each provider John encountered throughout this ­episode of care follows up with him on the smoking-­cessation program he started with his PCP, motivating him to stop smoking.

Real world case 11.1 questions

1. What is the standards way John's hometown physician can send his new doctor a referral?  

2.         Why does John use a standalone personal health record (PHR) instead of one from his provider?  

            

3.         When John is hospitalized, what core EHR component enables medication allergy checking?  

HITT 1301 CHAPTER 11

Health Information Management Technology,

An Applied Approach

Nanette Sayles, Leslie Gordon

Copyright ©2020 by the American Health Information Management Association. All rights reserved.

Except as permitted under the Copyright Act of 1976, no part of this publication may be reproduced,

stored in a retrieval system, or transmitted, in any form or by any means, electronic, photocopying,

recording, or otherwise, without the prior written permission of AHIMA, 233 North Michigan Avenue,

21st Floor, Chicago, Illinois 60601-5809 (http://www.ahima.org/reprint).

ISBN: 978-1-58426-720-1

AHIMA Product No.: AB103118

The Office of the National Coordinator (ONC) for Health Information Technology is the agency within the federal government tasked to be the health information technology (typically referenced as health IT) resource to the nation. In 2015, the ONC issued the Federal Health IT Strategic Plan 2015–2020 in which it describes a vision and mission for the United States’ use of health information technology (IT):

Vision: High-quality care, lower costs, healthy population, and engaged people.

Mission: Improve the health and well-being of individuals and communities through the use of technology and health information that is accessible when and where it matters most (ONC 2015).

In addition, the Federal Health IT Strategic Plan identified four overarching goals for health IT, which are both sequential as enumerated below, and interdependent as shown in figure 11.1. The following goals ultimately focus on improving the health and well-being of the nation:

Figure 11.1 Federal Health IT Strategic Plan 2015–2020

Source: ONC 2015

Advance person-centered and self-managed health

Transform healthcare delivery and community health

Foster research, scientific knowledge, and innovation

Enhance the nation’s health IT infrastructure

Dissemination of knowledge is stated as a goal in the Federal Health IT Strategic Plan. Knowledge is more than information; knowledge is the application of experience to information that provides value to the information beyond only serving as evidence of actions taken. Data are raw facts and figures without context or meaning; information is data that have been processed in a useful and meaningful manner.

This chapter discusses the scope of health information systems, the importance of standards, and the need to take a systems approach to planning, selecting, implementing, and managing health information systems so that the ultimate result meets the national vision and mission for healthcare and the goals for each healthcare provider (hospital, physician, nursing home, and others). The role health information management (HIM) professionals play in acquiring, implementing, gaining adoption, and optimizing use of health information systems is also discussed in this chapter.

Health Information Systems

The term health IT, or health information and technology, is used by the ONC because of its focus on information technology for healthcare. Information technology used by healthcare entities includes computer hardware and software to enable the collection and processing of data into useful information. Information technology includes communication and network technologies that enable data and information to be exchanged across various computers. Such technology, however, would apply in any environment. In addition, technology alone does not achieve the ultimate goal of gaining benefits from its use. People, policy, and process elements must be addressed for healthcare professionals to learn how to use and make the most effective use of the hardware, software, communications, and network technologies.

Health information system is used to describe the full scope of adopting health information technology. The term system refers to components that work together to accomplish a goal. The term health information system may be considered to include technical components and people, policy, and process components that work together to support the goal of improving the health and well-being of the nation.

Health information systems may be considered narrowly or broadly. For example, a laboratory information system (LIS) in a hospital is a health information system with a narrow focus on receiving and processing orders for laboratory testing, collecting and processing specimens, and documenting, delivering, and storing results. LISs also support department management, including staffing, equipment maintenance, supplies, and compliance.

As such, a health information system for a hospital laboratory includes the following:

· Hardware: computers, printers, laboratory devices

· Software: computer programs designed to process orders for lab tests, produce specimen collection lists for hospitalized patients, produce labels for specimen containers, produce test results, and conduct quality assurance on lab testing processes

· Communications and network technologies (connections with a computerized provider order entry [CPOE] system), used by providers to enter orders for lab tests as well as medications and other procedures, laboratory testing devices, pharmacy systems to obtain drug information that may impact test results, and destination systems, such as the electronic health record (EHR) system to convey results to providers and billing systems to capture charges for the lab tests

· Operational and cultural adaptations necessary to use the technologies in performing diagnostic studies (all diagnostic services of any type, including history, physical examination, laboratory, x-ray and others that are performed or ordered pertinent to the patient’s reasons for the encounter) on various specimens collected from patients and applying professional judgment in evaluating the quality of the data representing the results

· Policies and standards from the local healthcare organization in which the information system is housed as well as accrediting and licensing bodies that must be followed for design of the technology and its use. For example, policies and standards for a LIS may include use of certain terminologies, such as the Logical Observations, Identifiers, Names, and Codes (LOINC), which is federally mandated for ordering and reporting lab results. The Clinical Laboratory Improvement Amendments (CLIA) of 1988 are federal regulatory standards that ensure quality laboratory testing. They were modified in 2014 to ensure patients may have direct access to their test results, even prior to review by their ordering provider (Federal Register 2014).

· Workflow and process designs ensure the most efficient and effective use of the technology (chapter 17, Management, covers workflow in more detail).

An EHR system is broader in scope than a LIS. An EHR supports physicians, nurses, and other healthcare professionals in their documentation and communications concerning patients within the healthcare enterprise. An EHR has connection points to many focused health information systems in a healthcare organization. These health information systems include the LIS, pharmacy information system, radiology information system, nursing information system, dietary information system, emergency department system, and many others. There are also an increasing number of connections with other healthcare and related organizations, such as physician offices, health plans, public health departments, immunization registries, ambulance services, quality measure registries, vendors, and others. Healthcare organizations are using EHRs to connect with patients in multiple ways. Connections may be available through portals (windows into information systems), personal health records (PHRs), personal medical devices, apps on smart phones, and telehealth services that assist in providing remote diagnosis and treatment through telecommunications technology.

Another health information system that may be either narrow or broad is afforded by health information exchange (HIE) services. HIEs enable sharing of health information across disparate entities. While EHRs are accessible within a given healthcare entity, the primary purpose of an HIE is to support authorized exchange of health data across entities that subscribe to the service. This function extends data sharing more broadly than an EHR but is often relatively narrow in scope. It may serve only to share where an EHR for a patient is located; or it may maintain a repository of limited data, such as lab results and medication lists that can be accessed by subscribers. In this narrow context, the HIE maintains patient and provider directories and provides consent management and security services. To support such basic services at low or no cost to providers, many HIEs provide additional services. These broader services vary by HIE. Some HIEs offer clearinghouse services for revenue cycle management. Others may offer data mapping to reconcile differences between coding systems or versions of coding systems. Increasingly, many HIEs offer data aggregation and analysis, quality measure data collection and reporting, and business intelligence services (HealthIT.gov. 2018; HIMSS 2012a; AHIMA 2013).

Perhaps the broadest possible health information system is one that does not exist, but could be viewed as a virtual system of all EHRs (encompassing all of the narrow systems within an organization), all HIEs (to support exchange across organizations), and potentially other information systems, such as ancestry and genomic systems and others. While such a broad health information system is not likely to exist as a single entity, the goal is to ultimately support the sharing of health information to achieve the best possible healthcare and experience of care at a reasonable cost.

As suggested by the many health information systems that exist and which may continue to be developed or enhanced as new information technology emerges, it is important to recognize that many health information systems need to be periodically updated and expanded, or even phased out and replaced with new technology. The sections that follow will discuss the current state of health information systems and their scope—including source systems, core EHR applications, specialty systems, HIE systems, automated medical devices, supporting infrastructure, and connectivity systems.

Current State of Health Information Systems

Health information systems for lab, pharmacy, and other ancillary services are not new. Physicians and nurses have relied on these information systems as an important means to exchange diagnostic reports, medication, and other information since the early 1970s. EHRs were initially conceived around this time, but did not become a primary focus for healthcare providers until 2009 with the passage of the Health Information Technology for Economic and Clinical Health (HITECH) Act legislation. HITECH provided eligible hospitals and professionals with financial incentives, in terms of healthcare payment adjustments, to make meaningful use of EHRs. This incentive program is commonly referred to as the Meaningful Use (MU) program (now known as promoting interoperability) and describes an EHR that is qualified for earning incentives as one that:

includes patient demographic and clinical health information, such as medical history and problem lists; and has the capacity to provide clinical decision support, support physician order entry, capture and query information relevant to healthcare quality, and exchange electronic health information with and integrate such information from other sources (HealthIT.gov. 2016).

While most hospitals and many healthcare professionals have implemented an EHR within their healthcare organizations, the MU program started winding down in 2016. Since then, requirements for using an EHR have been incorporated into alternative payment models (APMs), which are new ways the federal government is paying for care. Such payment models are used in what is now being referred to as value-based care (VBC) strategies to improve the quality of care and drive down its cost. In this context, value refers to improving the quality of care to achieve a healthier nation, which can result in reducing the cost of care overall. For example, for physicians to be paid under Medicare, they must supply data to the federal government via their EHR for quality measurement. Different payment models are then applied based on provider factors, including the level of risk a provider is willing to assume (QPP,CMS.gov/apms. 2018; Feeley and Mohta 2018). (Reimbursement is discussed in chapter 15, Revenue Management and Reimbursement.)

The degree to which EHRs are used by healthcare professionals varies significantly. As a result, EHRs are “never done” (Gue 2018); they require continuous updating and improvement. The terms and definitions that describe the various stages in which any new information system may exist in healthcare, include the following:

· Implementation refers to technology having been installed and configured to meet the basic requirements of the healthcare organization. Demonstration to end users has taken place. End users are those persons who will use the information system in the course of their daily processes and procedures.

· Use refers to the fact that those who are supposed to apply the technology to their daily work have been trained and are starting to apply the technology at a simple level. For example, nurses may enter data into nurse assessment templates (a guide for documentation) and document medication administration using the technology. Physicians may use an EHR to review lab results and other information collected by other healthcare professionals. Often “use” has not addressed workflow and process changes that enable intended users to seamlessly incorporate the technology into their everyday operations. Simple usage should begin immediately after implementation, but within a few months users should be moving to adoption.

· Meaningful Use, as noted above, is a term used by the federal government for the program designed to incentivize use of EHRs. The term meaningful was chosen to reflect the purposeful desire to go beyond simply using the EHR as a search tool. There were two components to the MU program. One component was managed by the ONC and specified the functionality an EHR must have in order for a provider to qualify to earn the incentives. The other component of the MU program was the degree of use providers should make of the qualified EHR as specified by CMS (CMS 2014). CMS supplied monetary incentives through its Medicare and Medicaid reimbursement systems. Three stages were initially planned, with two stages fulfilled and the third stage moved to CMS’s VBC programs (QPP.CMS.gov/mips. 2018).

· Adoption is a term frequently associated with the intent of MU. Adoption of health information systems reflects that the healthcare organization has implemented all the major components of technology, although there may be some available technology that is more specialized, costly, and time-consuming to implement that has not yet been implemented. Adoption with respect to the EHR requires users to rely on technology to enter and retrieve most information, and where decision support is included to use it when appropriate. Adoption of EHRs demonstrates effective integration into the daily routines of healthcare. Adoption also should indicate it generally takes no more time to use an EHR than the paper health record, and generally yields greater value to the user than the paper health record. Unfortunately, adoption of EHRs has yet to be fully achieved, as many healthcare professionals find that EHRs are more time-consuming than paper and some find them to be distracting during patient care. In general, hospitals find them more helpful than not, and have supported physicians in using medical scribes (an assistant who gathers information and documents care into the EHR) and other workarounds that enable them to achieve EHR benefits. Some physician offices delayed implementation, others have abandoned the EHRs they implemented, and a number of them are in the process of replacing initially acquired systems with newer and improved systems (Spitzer 2018).

· Optimization is the state that demonstrates not only effective adoption of health information systems for routine operations, but also an understanding and appropriate use of the technology’s features with workflow and process improvements that can improve clinical efficiency (Monica 2018) and improve a healthcare entity’s bottom line (Siwicki 2018). At this state, the healthcare organization implements all or almost all the technology available to it. The user who optimizes health information systems has fully embraced the standard vocabularies supported by the technology, pays attention to alerts and reminders, is able to generate various reports that meet unique needs, frequently tailors the system to further take advantage of documentation aids, and may be considered a power user. Power users, people whose expertise in the information system is above others, are able to use technology to significantly improve their productivity and will likely see healthcare quality and cost benefits as well (HIMSS Analytics 2017).

Scope of Health Information Systems

Health information systems have evolved over time to automate an increasing number of information processing functions. Figure 11.2 summarizes health information systems in the sequence in which they have generally been adopted within hospitals. This sequence started with various administrative and financial systems, then departmental clinical systems, and subsequently some or all specialty clinical systems and “smart” peripherals (such as clinical equipment with electronic components that support information collection and alerts). Collectively, these are referred to as source systems because they are the source of basic data for the core clinical systems that comprise the EHR. Many core clinical systems have been implemented with the help of the MU program. Both source systems and core clinical systems depend on supporting infrastructure technology (various types of input/output devices and databases) and connectivity systems (network technology and standards). The major types of health information systems are summarized in more depth and variations between hospitals and physician practices are described after figure 11.2.

Figure 11.2 Overview of health IT systems in hospitals

Source: © Margret\A Consulting, LLC. Reprinted with permission.

Source Systems

Source systems capture and supply the EHR and other broad health information systems with data. Source systems may include administrative and financial applications, ancillary/clinical departmental applications, specialty clinical systems, and “smart” peripherals.

Administrative and Financial Applications

Administrative and financial applications are usually managed by specific departments, such as admitting, patient financial services, revenue cycle management, business intelligence, and health information management. However, they are not considered departmental systems because they manage patient-specific data needed for all other applications, and do not process data that aid in management of the departments as do ancillary, or departmental systems (see the next section). In general, administrative and financial applications include the following:

· Registration-admission; discharge transfer (R-ADT) systems (in hospitals)

· Practice management systems (PMS) (in physician offices)

· Master patient index (MPI)

· Patient financial systems (PFS)

· Revenue cycle management (RCM) systems

· Quality measurement, reporting, and improvement systems (Quality)

· Health information management (HIM) systems

· Human resources, physician compensation, procurement, and many others

Increasingly, healthcare organizations are adopting business intelligence (BI) systems, which integrate, analyze, and supply financial and clinical data to support both administrative/financial and clinical decision-making. (Chapter 6, Data Management, describes the specifics on business intelligence.)

Registration, Admission, Discharge, Transfer Systems Registration-admission, discharge, transfer (R-ADT) systems in hospitals register patients for inpatient admission or outpatient services. The R-ADT captures demographic and insurance data and supplies this data to other applications as needed. An R-ADT system tracks when patients are admitted to the hospital and opens an account for them. It also tracks all patient transfers within the hospital, such as a patient moving from an intensive care unit to a cardiac unit. Finally, the R-ADT system closes the account when a patient is discharged, transferred to another healthcare ­organization, or dies. Other related information systems keep track of the healthcare organization’s census, track who is in what bed, compile length of stay information, and maintain an MPI. In a physician practice, an equivalent system might be a practice management system, although in some cases only a scheduling system is in place.

Patient Financial Systems Patient financial systems (PFSs), frequently called billing systems in a physician practice, serve to check patient insurance eligibility, capture charges for services (including codes for office visits), compile and send claims to payers, receive payment and remittance advice, and identify unpaid or denied claims for which other collections efforts must be made. Revenue cycle management (RCM) system is a term that often refers to the broader process of not only creating, submitting, analyzing, and obtaining payment for healthcare services, but also negotiating contracts with health plans, coding and clinical documentation integrity, conducting utilization review, and other functions. The full scope of RCM is enumerated in figure 11.3 (Amatayakul 2017a). (Chapter 15, Revenue Management and Reimbursement, covers the revenue cycle management in more detail.)

Figure 11.3 Scope of Revenue Cycle Management

Source: © Margret\A Consulting, LLC. Reprinted with permission.

The RCM functions that exchange data between providers and health plans are referred to as transactions. Each transaction, such as eligibility verification, claims status inquiry, and so forth have mandated standards for use under the Health Insurance Portability and Accountability Act of 1996 (HIPAA). The standards specify in what format the data should be compiled and what data should be exchanged with payers. These standards are developed by the American National Standards Institute Accredited Standards Committee X12 (ASC X12). For example, the ASC X12 837 standard specifies the data and format for a claim. Also required are standard operating rules that further explain the standards, so their use is consistent across health plans. Figure 11.4 illustrates the HIPAA transactions and their relationship to clinical data.

Figure 11.4 HIPAA transactions and clinical data

Source: © Margret\A Consulting, LLC. Reprinted with permission.

Capturing, reporting, analyzing, and using clinical quality measure data is an important application to comply with governmental and private health plans. It is becoming increasingly important for information from quality measure reporting to be used at the point of care. Quality measure reporting required by Medicare is aided by CMS providing electronic Clinical Quality Measure (eCQM) specifications. Data required for the eCQMs must be downloadable from an EHR. When data are documented only in narrative form, they cannot be automatically downloaded to the eCQM collection system; these data must be manually abstracted from the EHR. Some health plans may require quality measures data be collected from other source systems, for example healthcare costs, instrumentation, or other elements not typically documented in an EHR. HIM and nursing professionals generally perform quality data capture. Quality data may be sent directly to the entity requiring the data, such as Medicare and other health plans. Many providers also find it valuable to send their quality data to commercial services that can aid in assuring its accuracy and completeness and provide analytical services for comparative information.

Increasingly claims data (data supplied on a claim for reimbursement purposes) are being integrated with clinical data (namely, the data documented about a patient’s health status and treatment) for alternative payment initiatives and to aid in strategic planning for the overall healthcare organization. As claims data and clinical/quality data, which is discussed in chapter 4, Health Record Content and Documentation, are used together, healthcare quality and cost improvements can be made. This integration of financial and clinical data provides BI that helps support business decisions by both the administrative and clinical leadership of healthcare organizations. For example, with more complete clinical information available at the time of admission, a hospital is better able to verify a patient’s eligibility for health plan benefits so that it is not faced with a denied claim later. Information that shows the hospital how many and what type of patients are readmitted within 30 days of discharge for the same condition is another example of BI that will enable a hospital to take proactive measures to monitor these patients more closely after discharge. Physicians are also starting to use integrated claims data and clinical data to evaluate medical necessity for repeat diagnostic studies, assess the value of costly drugs, and help patients make informed decisions about their healthcare options (Horstmeier 2017).

Health Information Management departments typically do not have a specific departmental information system but do manage and use several separate applications that assist in performing various tasks within the department. As noted above, HIM departments may manage some of the RCM functions such as coding of diagnoses, procedures, and professional services and clinical documentation integrity to ensure the documentation in the EHR supports the diagnoses, procedures, and professional services identified. HIM departments may also support some of the applications that complement the EHR. Complementary systems include document imaging systems (when used only to scan paper forms), electronic document management systems (EDMS) (when scanning is coupled with workflow tools), or electronic document/content management (ED/CM) systems (when both documents and the data in a document have XML [eXtensible markup language] tags applied for ease of searching for content). Also included may be speech dictation systems that enable speech to be translated directly into a ­narrative document and discrete reportable transcription (DRT) systems that combine speech dictation with natural language processing (namely, the ability for a computer to not only convert speech to words, but apply sophisticated computer processes to put the words into appropriate context). Today, DRT can populate predefined templates with structured data. Consent management systems are those that help maintain patient preferences about who may have access to their health information. These may be managed in conjunction with release of information (ROI) systems, the EHR, and HIE services. HIM applications vary by how far the healthcare organization has progressed in implementing its EHR applications. For example, if the healthcare organization continues to retain some paper health records, the HIM department may have a chart tracking system to manage location of paper records (or to manage archived paper records). HIM systems are discussed in more detail in chapter 3, Health Information Functions, Purpose, and Users.

Health Information Technology departments are similar to HIM departments with respect to not necessarily having departmental management systems but having responsibility for supporting the information technology infrastructure and connectivity systems to enable effective use of all of an entity’s information systems.

Clinical Departmental Applications

Clinical departmental applications, also called ancillary systems, serve primarily to manage the department in which they exist, while at the same time providing key clinical data for the EHR. There are three main departmental systems that are necessary for an EHR to function in a hospital. They are the following:

· The Laboratory information system (LIS) will receive an order for a lab test; generate a work list for specimen collection, labels for specimen containers, and accession numbers to track specimens; retrieve results from an auto-analyzer (device that analyzes the specimen); perform quality control; maintain an inventory of equipment and supplies needed to perform lab tests; and manage information on departmental staffing and costs. The LIS supplies the lab results to the user, either as a paper copy printout or an electronic print file, which is structured data (data able to be processed by the computer) to an EHR. The blood-banking and clinical pathology systems are often separate from the LIS.

· The Radiology information system (RIS) performs functions similar to the LIS—receiving an order for a procedure; scheduling it; notifying hospital personnel or the patient if performed as an outpatient; tracking the performance of the procedure and its output (that is, images in analog or digital form); tracking preparation of the report; performing quality control; maintaining an inventory of equipment and supplies; and managing departmental staffing and budget. Radiology departments also obtain picture archiving and communication systems (PACS), which digitize the results of radiological modalities, such as x-rays, computerized tomography (CT) systems, and others, and provide special viewing capabilities of these images via a computer. Standardization for PACS is established by the Digital Imaging and Communications in Medicine (DICOM) organization. Some PACS also can connect directly with a RIS, thereby providing the ability to integrate images with data.

· The Pharmacy information system receives an order for a drug in a hospital; aids the hospital’s pharmacist in checking for contraindications (situations that should be avoided as potentially harmful to a patient); directs staff in compounding any drugs requiring special preparation; assists in dispensing the drug in the appropriate dose and for the appropriate route of administration; maintains inventory (documenting medications in stock using the National Drug Codes (NDC), the terminology maintained by the Food and Drug Administration (FDA) for use in identifying FDA-approved drugs; supports staffing and budgeting; and performs other departmental operations.

Other clinical departments in a hospital, such as dietary and nutrition, have information systems that are similar to LIS, RIS, and Pharmacy. They receive orders and supply results (or services) to users, as well as manage the respective department operations.

Specialty Clinical Systems

Specialty clinical systems are acquired to support the unique needs of specialty services. Examples of systems used primarily in hospitals or specialty organizations are intensive care units, perioperative and surgical services, labor and delivery services, and emergency departments. In addition to these information systems that serve to aid in management of a department as well as to support documentation of services provided to patients, various clinical specialties may also have unique functionality, ideally as part of the healthcare organization’s EHR (such as cardiology, nephrology, and many others). Other clinical system needs may be unique to the services being provided and those systems are often stand-alone systems. These include long-term and post-acute care (LTPAC), dentistry, behavioral health (BH), and various therapy services (such as physical therapy, respiratory therapy, occupational therapy).

Population health is defined as “the science and art of preventing disease, prolonging life, and promoting health through the organized efforts and informed choices of society, organizations, public and private communities, and individuals” (cited in Health Catalyst 2019). As such, population health management (PHM) is the aggregation of data across multiple health information system resources and the analysis of that data into actions providers can use to improve both clinical and financial outcomes (Phillips 2018). PHM information systems are less a separate system than a repurposing of existing information systems (especially Quality and BI) and use more advanced supporting infrastructure (such as analytics and artificial intelligence) to aid in managing healthcare most effectively in general, and patients in a value-based care environment. The most common functions of PHM systems are those to support care coordination, care transformation, patient engagement, and care analytics to reduce practice variation while accounting for social determinants of health which are believed to account for 80 percent of what affects health outcomes outside of the traditional boundaries of healthcare delivery (Health Catalyst 2019).

“Smart” Peripherals

Automated medical devices (also called smart peripherals), until recently, have generally not been considered information systems, even though they have generated data as well as information—for example a measurement of a person’s blood pressure on a display screen is a data point as well as information for the provider and patient. A smart system can also be a continuous feed of data such as a fetal monitoring strip or blood sugar level. Other examples of automated medical devices include vital signs monitors, cardiac output monitors, defibrillators, electrocardiographs, infusion pumps, physiologic monitors, and ventilators (HIMSS Analytics 2010). Increasingly, these medical devices not only collect and report data, but they use the data to provide “smart” services, such as monitoring response to medications and making adjustments, or alerting nursing staff. Many healthcare organizations are also connecting these devices to their EHR via medical device integration (ECRI Institute 2014).

Core Clinical EHR Systems

There are generally five main applications that define an EHR. These include the following and are illustrated in figure 11.5, as a closer look at the EHR section of figure 11.2.

1. Results management

2. Point-of-care (POC) clinical documentation

3. Medication management encompassing CPOE and bar code medication administration recording (BC-MAR) systems

4. Clinical decision support (CDS) systems (CDSS) (of various types)

5. Analytics and reporting

Figure 11.5 Core clinical EHR systems

Source: © Margret\A Consulting, LLC. Reprinted with permission.

The EHR applications include the basic functionality required for earning incentives in the MU program and now for participation in alternative payment models. To earn MU incentives and to participate in alternative payment models, an EHR application must have certification from an ONC-designated certifying body indicating that the EHR meets all of the required functionality criteria for the program. The criteria, however, do not require all possible EHR functionality that is available, some of which is critical for most providers. For example, program requirements do not include support for charge capture even though most healthcare providers find this an essential part of their EHR that needs to link to their patient financial services and revenue cycle management systems.

It is also important to note that there are some variations in the core EHR applications as they are used in a hospital or in a physician practice. One main difference is that in a hospital, the EHR applications are often implemented separately; whereas in a physician practice, EHR applications tend to be more integrated. Other differences are noted as each of these core applications is described more fully in the following sections.

Results Management

Results management is an EHR application that enables diagnostic study results (such as lab results) to be reviewed in a report format and for the data within the reports to be processed. Users can compare, trend, and graph the results. Depending on their level of sophistication, results management systems may also be able to compare lab results with other clinical data. For example, a graphic display could depict lab results as a function of medications administered or be compared with a patient’s vital signs. Lab results can also be extracted directly from the EHR for use in quality measurement studies, clinical research, and BI systems. For a healthcare organization to have results management, all data to be processed must be in structured format and ideally stored within a clinical data repository (see Supporting Infrastructure below).

The importance of results management cannot be emphasized enough, as 70 percent of the ability to reach a diagnosis for a patient depends on lab results (Wians 2009). Similarly, as medications are increasingly powerful in their impact on the human body, monitoring vital signs and lab results in association with medication administration is critical to appropriate medication management.

Point of Care Documentation

Another EHR component is point-of-care (POC) documentation. The intent of these applications is to inform the user what data needs to be recorded for the patient and to use that data to supply clinical decision support (CDS), including alerts and reminders, at the time when the clinician is able to be most responsive to alerts and reminders. POC documentation systems supply templates to the user to be completed primarily via point-and-click, drop-down, type-ahead, and other data-entry tools. Usually the EHR has a library of templates. The user may choose the appropriate template, or the user’s dashboard may display the appropriate template based on the user’s profile as indicated via the log-in or by the patient’s admitting diagnosis or chief complaint at the time of a physician’s office visit. Some templates are extremely sophisticated and as the user enters data, the data fields adjust accordingly. As a simple example, a template for conducting a history and physical exam for a male patient would not display data fields applicable to females. If the information system detects that the patient’s condition involves heart disease, additional data fields may be displayed for associated signs, symptoms, and potential complications. The result is structured data that the computer is essentially processing into clinical documentation. More information on dashboards can be found in chapter 12, Healthcare Information.

POC documentation systems include support for documentation of all patient care administered by healthcare professionals. While ideally all such documentation should be integrated, frequently such documentation is compartmentalized, especially in hospitals. This is often the case because the nature of the data to be collected and volume varies considerably. Nursing staff may have separate screens for nurse admission assessments, nursing problem lists, nurses’ notes, vital signs (which may also be captured directly from patient monitoring systems), intake and output records, and other nursing documentation. Medication administration is also a nursing documentation requirement, but such systems are typically grouped under medication management systems, as described in the next section.

A nursing information system is generally considered a departmental system, not a clinical documentation system. Similar to LIS, RIS, and pharmacy information systems, a nursing information system manages the nursing department, including staffing, credentialing, training, budgeting, and other managerial functions. Clinical data may be combined with department operations data in a nursing information system to provide patient acuity staffing levels, where the number of staff needed for any shift or day is determined by how acutely ill the current patients are.

In a hospital, physicians are expected to document a problem list, history and physical exam, consults, operative reports, and a discharge summary. These are largely dictated and electronically fed as an image into the EHR. Physician progress notes may be handwritten and scanned into the EHR. Medical scribes may be used to support direct data entry into the EHR. According to the American Health Information Management Association (AHIMA) (2012), a medical scribe is an individual who enters clinical documentation into the EHR to reduce administrative burden. Scribes may also assist providers in navigating EHRs, respond to messages on behalf of physicians as directed, locate information, or perform research. An American Medical Association study has determined that scribes can cut physician documentation time in half, and with their additional roles can increase revenue to offset their cost (AMA 2017). The Joint Commission provides guidelines recognizing scribe usage; and, in 2017 the American Healthcare Documentation Professionals Group announced it would offer a scribe certification (Bresnick 2017).

The problem list is increasingly managed through a combination of sources including the admission order for the admitting diagnosis and directly from a drop-down menu for discharge diagnoses and procedures. The MU program ­required that the problem list ultimately be automated and coded with either ICD or SNOMED-CT codes. Physician orders are documented in a CPOE system (discussed later in this chapter).

In physician practices, physicians (and their scribes) and nurses often enter clinical documentation directly into the EHR as structured data. Structured data refer to data elements that are uniquely captured by the computer in fields that can then be processed. An example is drug–lab checking, where it may be necessary to have lab data (such as the results of a liver function study) before ordering a certain type of drug that may adversely affect the liver. Drug–lab checking can be performed in a CDS system, however such CDS depends on the selection of a specific drug programmed into the information system and lab data results also programmed into the computer that are available to the CDS system. The CDS system then can compare what drug is ordered against a patient’s lab values to determine if there are contraindications. Structured data is contrasted with unstructured data, or narrative information not able to be uniquely processed by a computer. For example, a lab value posted to a specific field can be compared with other such lab values. A lab value simply documented in a note, comment field, or as a scanned image of paper cannot be processed by the computer in the same way as structured data.

Medication Management

Medication management refers to the use of certain information systems that help ensure patient safety, or preventing harm to patients, learning from errors, and building a culture of safety (Hughes 2008). These are often referred to as closed-loop medication management systems because they automate the processes from the point a drug is ordered to the point it is administered. These systems include CPOE, e-prescribing (e-Rx) as a special type of CPOE, BC-MAR, medication reconciliation systems that compare drugs ordered against drugs dispensed and administered, and automated drug dispensing machines, as well as the policies, procedures, and workflows associated with ensuring proper drug ordering, dispensing, administering, and monitoring of reactions. Although there is no recommended sequence for implementing these information systems, many hospitals in the past implemented CPOE last because it is difficult to get physicians to use such information systems in the hospital. This is changing as MU incentives require use of a CPOE system first, then medication administration record systems. In the ambulatory setting, e-Rx has sometimes been implemented as a stand-alone system before an EHR (and its CPOE functionality) because some insurers and Medicare were providing incentives for its use. Physicians also found great value in the CDS for drug choices and in managing prescription refills and renewals.

CPOE Systems CPOE systems can be used for entering all orders such as patient admission, laboratory tests, x-rays and other diagnostic studies, dietary and nutrition, therapies, nursing services, consults, discharge of patient, referrals, and even building personal task lists, as well as entering orders for medications. In the past, these orders were usually handwritten by the physician and were either internally faxed to various departments as applicable or transcribed by nursing personnel (such as ward secretaries or unit clerks) into an order communication system. This type of system, however, included no CDS. While some physicians prefer not to have to enter their own orders or pay attention to CDS alerts, it is believed that such support ultimately will improve the quality of healthcare.

CDS in CPOE systems initially provided many alerts that may not have been specific or relevant to a given patient, resulting in alert fatigue, or the ignoring of alerts due to their volume and irrelevancy. For example, reminding a provider to check for an allergy to a drug should not be necessary if a comprehensive medication history is being obtained and documented by a nurse or pharmacist. Such an allergy alert should only appear if the physician is ordering a contraindicated medication. Appropriate alerting to drug–allergy and drug–drug contraindications (situations that should be avoided as potentially harmful to a patient) is a complex process that requires not only accurate data from the patient and throughout the patient’s care, but an up-to-date drug knowledge database (namely, a subscription service that provides current information about drugs and is accessible to users and the CDS).

Another concern with CPOE systems is that they are often based on standard order sets. Standard order sets are lists of specific diagnostic studies and treatments as appropriate for specific diagnoses or procedures to be performed. These order sets reflect the current knowledge about patient care from research, experts, and other sources of evidence-based medicine (EBM). A standard order set is frequently used for patients with common conditions. For example, a standard order set is ­often used for admissions for normal pregnancies, where the obstetrician only needs to approve of the standard items or make applicable changes rather than having to document the entire set of items normally required. However, although EBM may reflect the best scientific evidence on how to treat a patient with a specific condition, one size does not always fit all human beings. Even a woman with a normal pregnancy may have certain preferences, allergies, or additional conditions that must be taken into account when using the standard order set for normal pregnancy. As a result, most standard order sets need to be modified for each patient. In haste, a physician may accept the standard orders or may make an error in modifying them—which may result in unintended consequences (AHRQ 2011). An unintended consequence is an unanticipated and undesired effect of implementing and using an EHR (Rollins 2012). While these often have been attributed to the EHR software itself as early as in 2006 (Campbell et al. 2006) and continue to be cited today (Vanderhook and Abraham 2017), they often reflect that a user may not have applied professional judgment or due diligence in using the EHR.

CPOE systems also generate the patient’s medication list. The medication list is required under the MU program to be coded using one of the code sets standardized under RxNorm, which is a system maintained by the National Library of Medicine to normalize drug names across disparate vocabularies. Caution must be applied here, as the medication list will only be as accurate and complete as all systems contributing information to it. For instance, if a medication is ordered prior to surgery, suspended during surgery, reinstated after surgery but then changed before administration, not only must the CPOE and BC-MAR contribute correct medication information, but the surgery information system may also need to interface with the medication management systems, which is not always the case.

E-Rx E-Rx is a special type of CPOE used exclusively to write a prescription and transmit it electronically to retail pharmacies. The format and content of the prescription transmitted is standardized by the National Council for Prescription Drug Programs (NCPDP), a standards development organization that sets standards for the pharmacy industry. The NCPDP SCRIPT standard is the standard developed for electronically transmitting a prescription. As such, the SCRIPT standard is used in ambulatory settings, including not only the physician practice but when a patient is discharged from the hospital or emergency service with a prescription and in hospital outpatient departments or clinics. The e-Rx system includes medication alerts and reminders just as the hospital-­based CPOE system, but also includes formulary information that identifies whether the patient’s health plan covers the cost of a drug and what co-pay may be required. Physicians can then work with their patients to find the most cost-­effective as well as clinically suitable drug. Because e-Rx systems are able to transmit prescriptions directly to retail pharmacies, physicians benefit from fewer calls from pharmacies not able to read their handwriting or needing to advise the physician that a drug ordered is not going to be covered by the patient’s insurance because it is not on the list (formulary) of covered drugs; that is, it is considered “off formulary.” Physicians are also able to receive electronic communications from ­retail pharmacies, such as for renewal approvals that can significantly save time in a practice. In 2010, the Drug Enforcement Administration (DEA), which previously banned use of e-prescribing for controlled substances (EPCS) such as narcotics, set special requirements allowing for use of EPCS. These requirements include use of a product that provides identity proofing (authentication credentials used to electronically sign such prescriptions) and two-factor authentication—a signature type that includes at least two of the following three elements: something known, such as a password; something held, such as a token or digital certificate; and something that is personal, such as biometrics (fingerprints, retinal scan, or other) to enable such use. Digital certificates are issued by a certificate authority, an organization that verifies a person’s credentials (such as the provider’s DEA number for EPCS) and can revoke the certificate if the credentials are revoked.

BC-MAR Bar code medication administration recording is the documentation of administering medication to a patient and is a function performed by nurses in a hospital. Nurses use a bar code reader to positively identify the patient and the medications to be administered to the patient. Bar codes are parallel arrangements of dark elements, referred to as bars, and light elements, referred to as spaces, that represent information, such as the patient name, drug name, and other data. The frequency and care that must be taken to ensure a nurse administers the right drug, in the right dose, through the right route, at the right time, and to the right patient (the medication five rights) is critical to avoid medication errors. As a result, computerized systems have been created. Early medication administration systems were simply electronically generated paper lists of medications from the pharmacy information system after it processed physician orders. Later, the lists were retained on the computer and nurses were expected to post the date and time of medication administration to the computer. Any exceptions or issues with medication administration, however, were still included in handwritten nurses’ notes. Most importantly, these systems, while providing a legible list of medications did not fully address the medication five rights.

BC-MAR systems require the hospital to have each patient identified with a bar code (usually on a wrist band) and to package (or buy prepackaged) drugs in unit dose form, each with a bar code or radio-frequency identification (RFID) tag that identifies the drug, dose, and intended route of administration. (An RFID tag serves the same function as a bar code but enables wireless transmission of the data rather than requiring a bar code to be read with a scanner.) At the time the drug is to be administered to a patient, the nurse logs into the BC-MAR system and scans the patient’s wrist band and unit dose package. The ­information system automatically dates and time stamps the entry made through this process. As a result, the medication five rights have been followed. Most BC-MAR systems also enable notes to describe exceptions; for example, that the patient was in surgery at the time the next dose was to be administered. BC-MAR systems provide some CDS as do CPOE systems, often including links to additional information about drugs. BC-MAR systems also generate reports on timely administration of drugs.

There are some issues with using BC-MAR systems. One is that the bags that are specially compounded with multiple drugs administered intravenously require labels to reflect all the drugs in the compound. Not all hospital pharmacy information systems can produce such labels. In this case, special care must be taken to manually check and enter the medications being administered. The other important issue associated with using BC-MAR systems is bringing the computer, bar-code wand, and medication to the patient bedside. Some hospitals use wireless workstations on wheels (WOWs). Because WOWs can become heavy with their various devices plus a long-life battery, an alternative is to carry (sometimes by wearing a sling) a tablet computer that may be outfitted with a wand device and the medication. Walking around all day with such equipment, however, is also not comfortable. Finally, it is important for the hospital to fully define what constitutes a medication administration error—a wrong time, for instance, may or may not be due to an error but rather the availability of the patient.

Medication Reconciliation The medication reconciliation process can be automated, although not as easily as the other elements of medication management. Each time a patient is transferred across levels of care, such as when admitted, transferred into an intensive care unit, or sent to surgery, the medications the patient should be administered need to be reviewed. Often certain medications must be discontinued, or a dose altered as a result of the change in level of care. Because the clinicians who work with the patient are different at each different level of care, connecting all the information systems at the different levels of care has been a challenge, and only a few hospitals have been successful.

Automated Drug Dispensing Machines Finally with respect to medication management, automated drug dispensing machines, which are technically smart peripherals, are available that both secure and make drugs more readily available to nursing staff. These machines are typically filled by pharmacy department staff based on the physician orders.

Clinical Decision Support

Clinical decision support (CDS) is a key component of the EHR and sets it apart from simply automating paper documents. CDS functionality in the EHR helps physicians, nurses, and other clinical professionals—collectively referred to as clinicians—as well as patients themselves make decisions about patient care. Some examples of CDS as previously discussed include alerts about potential drug contraindications, out-of-range lab results, and standard order sets in CPOE. In addition, CDS templates can help determine what documentation of clinical findings is necessary; provide suggestions for prescribing less expensive but equally effective drugs; supply protocols (specification of appropriate processes, based on expert best practices and clinical research findings) for certain health maintenance procedures; and alert that a duplicate lab test is being ordered. There are countless other decision-making aids for all stakeholders in the care process.

CDS may be built into each of the core EHR ­applications. However, CDS is also acquired as separate information systems that work in conjunction with the EHR applications. In general, the CDS found in the core EHR applications is rudimentary because it typically can only process data within the given application. More sophisticated CDS ­requires the convergence of different types of data from the various EHR components. As a result, separate applications are used to help integrate and analyze these data.

Separate CDS applications may be fully integrated with the core EHR applications or employed in a stand-alone fashion. An example of a separate CDS application is one that provides drug–lab checking, such as whether a drug is contraindicated for a patient with poor liver function. This is not a routine function of CPOE or LIS but requires the combination of data from both sources and the ability to deliver the alert back to the appropriate system(s). This is commonly referred to as a separate clinical decision support system (CDSS), even though it may be fully integrated into the core EHR applications through supporting infrastructure. Other examples of separate CDSSs that are integrated into the EHR include the templates used in clinical documentation, standard order sets used in CPOE, and clinical pathways that guide nursing services. While some EHR products build a basic set of templates directly into their clinical documentation systems, others require a separate CDSS to generate the templates, or provide more sophisticated and customizable templates than exist in the basic clinical documentation applications.

CDSSs that are used in a stand-alone fashion are often those specific to a unique function. For example, a CDSS that is used in a stand-alone manner in a hospital includes an information system to alert infection control nurses of a potential hospital-acquired infection. It provides advice on which medication may be most effective in combating the infection given the causative agent. Such an information system compiles data from clinical documentation (such as documentation of a high temperature), lab results (such as the strain of bacteria that is causing the infection), ­x-ray ­results (such as a finding of pneumonia), and other sources processed against automated clinical reference information to produce the specific findings.

An example of a CDSS used in a stand-alone fashion by physicians is a differential diagnosis system. This system may compare diagnostic images against a library of images and their known conditions, which is especially useful for radiologists, dermatologists, pathologists, and others. Other differential diagnosis CDS systems compare data from clinical documentation, especially the history of present illness and review of systems, with a library of known signs and symptoms for specific diagnoses. Some of these are used only when the differential diagnosis is obscure. Others may be a routine part of a protocol, such as for assessing a patient presenting to the emergency department with chest pain. Still another CDSS can aid in identifying whether a patient’s symptoms are due to a new condition or are the result of an adverse reaction to a medication. Figure 11.6 summarizes the different forms of CDS and CDSS.

Figure 11.6 Types of clinical decision support

Source: © Margret\A Consulting, LLC. Reprinted with permission.

CDS is an increasingly important tool in value-­based care, as it helps healthcare professionals encourage healthy lifestyles – thereby improving the overall health of the individual and lowering costs. For example, an alert that a patient is a smoker could trigger a suggestion for smoking cessation. Another example might be the ability of the information system to calculate the ­patient’s body mass index (BMI) for recommending weight counseling. Caution must be applied in displaying and using some of these alerts, such that they should be able to be tailored to the patient. This may mean that an alert is turned off or frequency reduced for a given patient. Many ambulatory EHRs include reminders for preventive or chronic care services, such as dates when a vaccine, cancer screening, diabetes care, or other services are due.

Analytics and Reporting

Analytics and reporting are the final core EHR application. Analytics refers to statistical processing of data to reveal new information. Reporting is supplying the results of analytics to the intended recipient.

Analytics goes beyond the simple use of descriptive statistics, such as how many patients were seen for a specific condition, to questions such as which form of treatment for the specific condition had the best outcomes. The ability to produce such reports is increasingly important as there is ever more pressure to improve quality and reduce the cost of healthcare. Analytics, however, entail sophisticated processes to be performed on data—such as data mining, forecasting, neural networks (mathematical modeling that makes connections between data to discover relationships).

In healthcare, analytics has been primarily performed in academic and research institutions, by health plans, at pharmaceutical manufacturers, and for public health departments. Analytics has produced many clinical benefits for the healthcare industry, such as in genomic research and personalized medicine (also known as precision medicine) that tailors treatment to the individual, given not only comorbidities but genomic characteristics and predispositions (SAS n.d.). Analytics are also used to create BI, such as in predicting prescribing patterns of physicians or the impact of a disaster on local emergency services (Strome 2013). For more specifics on analytics, refer to chapter 12, Healthcare Information.

Although most information systems can generate some data for analysis and reporting, there has been strong interest for the EHR to provide more robust analysis of data. Unfortunately, the nature of the type of database required for POC documentation and CDS, referred to as a clinical data repository (CDR), does not support complex analytics and reporting. The purpose of a CDR is primarily online transaction processing (OLTP), where each access, entry, or other process performed on data is a transaction. Often it is necessary to move data from the CDR to a separate database that has been optimized to perform analytics and reporting (online analytical processing [OLAP]). This type of database is referred to as a clinical data warehouse (CDW). In addition, healthcare organizations that want to perform sophisticated analytics need staff highly skilled in such statistical techniques. It may be that a given hospital or physician practice cannot perform the analytics and reporting itself, but it sends data to a vendor who performs the analytics. An increasing number of EHR vendors are supplying such services, often aggregating data from many customers to enlarge the pool of data, making the results of analysis on the data more valid and reliable. When this data pool has a large volume of data, it is ­referred to as big data. Big data offers greater reliability and validity. Big data analytics implies massive amounts of data that can be analyzed quickly in near real time to return new information to users at the POC. When data are collected from active patient health records, the data reflect current experience and analytics is then able to produce new knowledge as well as new information.

Another trait of big data in addition to its volume and velocity is that all the data do not need to be structured. Unstructured data can be analyzed and parsed into structured data as part of processing big data. It is still important to ensure the quality of unstructured data being captured in health information systems so that the results of analysis can be as accurate as possible. Data quality refers to adherence to standard data definitions and metadata (that is, data about data) requirements. Data models that organize data to depict relationships among data help ensure the quality of data collected by health information systems. Standard vocabularies (the compilation of terms formally adopted for use in health information systems) are used for data exchange across different health information systems. This exchange capability is referred to as semantic interoperability, or the ability to share common meanings for data across systems. Another important element that improves data quality in health information systems is a data dictionary that lists all data elements used in a health information system with their definitions and characteristics. For example, a data dictionary for a given health IT system would include the term temperature and specify that it must be documented in centigrade. AHIMA developed a data quality management model to illustrate these characteristics (AHIMA 2015).(The data dictionary and the AHIMA Data Quality Management Model are explained in chapter 6, Data Management.)

Health plans have analyzed data from healthcare claims for a long time, and now they are receiving additional data from commercial labs, claims attachments, patient-entered data, and other sources to perform even more sophisticated analytics. Such information may impact whether the hospital or physician practice receives a favorable discount rate on its fees for services. Quality benchmarking depends on analytics. (Benchmarking is discussed in chapter 18, Performance Improvement.) Consumers are beginning to look at which hospital excels in cardiac care or has a center of excellence for orthopedics. Having aggregated data to understand why one healthcare organization is ahead in its quality metrics over another can help poorer performers improve. Analytics and reporting are not only used for retrospective quality or research studies; an important set of reports include rule-based lists for patient follow-up. Patient follow-up lists have not been easy to generate in the past, as much of the data had to be manually abstracted from paper records, transcription, or scanned images of documents. However, the ability to identify all patients requiring follow-up after discharge, for chronic disease care, to notify them of a drug or device recall, to send preventive care reminders, or any of many other similar types of reports or lists is integral to quality patient care.

Most analytics implementations are still retrospective. However, it can be anticipated that the use of big data analytics in near real time, especially when coupled with artificial intelligence (AI) (which is the application of algorithms that analyze data and make applicable recommendations [Pearl 2018]) will help providers at the POC improve clinical decision-making. Examples of such improved decision-making include the ability to select affordable therapies (Chaiken 2011) and make earlier diagnoses of complex conditions such as rheumatoid arthritis and multiple sclerosis (Kalatzis et al. 2009).

Supporting Infrastructure

Supporting infrastructure (see figure 11.2) refers to the technology that allows the various applications to work. This includes hardware and software of various forms and sophistication. Hardware includes human computer interfaces (HCI), which are any form of input device used by humans, including monitors, keyboards, printers, scanners, and many other devices that enable human interaction with computing technology. Hardware also includes all the computer servers and associated cabling and other tools for processing and storage.

A key component of supporting infrastructure is the need to provide interoperability. Interoperability is the term used to describe the ability of one information system to exchange data with another information system in a way that the data exchanged are usable to each part of the exchange. Interoperability comes in several forms. For example, with semantic interoperability, the terminology used carries the same meaning to all parties to an exchange.

Technical interoperability is the most basic form of interoperability. Technical interoperability refers to the exchange of any data element across information systems. In healthcare, many basic applications were developed before the internet and World Wide Web (WWW) were widely available. As such, application software was written using message format standards to structure the format of the data that are processed by the applications and which could only support point-to-point communications. The ASC X12 standard for exchanging claims and other administrative and financial data and the NCPDP standard for exchanging prescriptions between an e-prescribing system and a retail pharmacy previously described are examples of message format standard. Diagnostic study results data, POC documentation, medication management data, and other such clinical documentation are exchanged among applications using similar standards from the Health Level Seven (HL7) standards development organization. The HL7 is a not-for-profit, standards-developing organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery, and evaluation of health services.

As a result of the early development of health information systems software, most technical interoperability today requires an interface, which is software that serves as a translator between different applications which may have different structures for data or may use different vocabularies to encode data. For example, if the R-ADT system needs to send patient demographic data to the LIS, an interface will identify what data should be sent from what fields in the R-ADT system to the fields in the LIS. In the software used by most health information systems today, interfaces are required because communications may also be used to exchange data between one organization and another, such as between a physician’s office and a commercial laboratory. Interfaces, however, are costly to write and maintain. Every exchange between two applications requires an interface. Since there are many applications in any given entity, many interfaces are required. Furthermore, anytime one information system is upgraded or modified in some way, the interface between it and all other applications with which it exchanges data must be adjusted. It also must be noted that each application in any given entity is unique to that entity. As a result, interface engines are often required to manage all the interfaces for a given entity, and with a very limited number of external entities.

Because applications, and hence their interfaces, are unique to a given entity, interfacing is not an effective way to exchange data across many different organizations. For example, a physician’s office likely needs to exchange prescription information with many different retail pharmacies. Today for such exchanges to occur, a go-between that can manage the translation process is used, for which entities pay a fee each time an exchange takes place. The go-­between is a vendor, typically called a clearinghouse. Some health information exchange organizations also serve this purpose for other forms of health information (see Connectivity Systems in the next section).

Over time, health information systems software was written or modified to encompass many of the applications needing to exchange data within a given healthcare organization. As such, computer servers were configured to support the larger volume of data across the various applications. (A server is a “master” computer that “serves” the needs of many end-user computers.) The differences between two major server functions were previously described: a CDR (typically used to house and process the broader range of LIS, RIS, EDMS, EHR, and many other applications being brought together) and a CDW (to integrate at least some of the data from the CDR and perform analytics). A registry is another type of application that typically houses and performs analysis and data reporting on a subset of clinical data. A common example is a tumor registry. When quality measurement data are submitted to a vendor, the vendor is essentially compiling a registry. The server that supports a registry is something of a cross between these two server functions.

There are also special servers. Examples are the interface engine previously described and an inference engine (also called a rules engine), which supplies the rules that govern clinical decision support. An example of such a rule might be: If a patient is allergic to penicillin, generate an alert when a physician orders any medication with the same active ingredients as in penicillin. Such servers need to have access to knowledge sources, which are resources that provide information about the properties of drugs, the latest research about new surgical procedures, and other information needed to support clinical decision-making. Because knowledge sources must always be kept up to date with new information about drugs, surgical protocols, and much other information, they are generally provided through a vendor that operates through a subscription service.

While this description of many interfaces and unique server types paints a rather bleak picture for interoperability in healthcare, progress is being made to take advantage of web services architectures (WSA) that utilize tools to aid in exchanging data in a one-to-many (rather than point-to-point) manner. WSA refers to the use of web-based forms of interfaces—such as XML structures—to enable sharing across multiple parties.

Another important element of supporting infrastructure, however, is management of the ­infrastructure. As such, a plan describing what technology will be adopted, how the technology will be procured, and how the technology will work together is needed. This plan is often in the form of an enterprise architecture (EA). An EA is needed because large hospitals may have nearly a thousand applications, with hundreds of applications being common in medium-sized hospitals. Physician practices may have only one combined PMS and EHR, but frequently have some ancillary and specialty systems—potentially accumulating 10 to 20 or more information systems. An EA helps keep track of all the applications and how they work together. Drilling down further, a data governance framework (DGF) provides a logical structure for managing all of the healthcare organization’s data. A DGF addresses data governance and stewardship, data quality management, specifications of terminologies for data, roles and responsibilities for collection and use of data, metadata management, data storage and warehousing, and data security. The EA and DGF are vital for managing the different applications necessary for today’s health information needs.

Infrastructure also must consider the processes and policies for using applications. These are increasingly being referred to as process interoperability and policy interoperability. Process interoperability refers to the use of workflows and procedures that best support use of technology. Some process interoperability can be aided by software. For example, if there are a series of steps to be taken by different people, in different departments, with different information systems, software can be supplied to direct the sharing of data in the appropriate sequence as each person, department, and system completes its work. In other cases, process interoperability may be a human factor to be addressed in training and optimization. Policy interoperability refers to the rules that govern exchange of data. These rules are incorporated into software development. For example, access controls are security rules built into information systems to ensure only the ­appropriate access is afforded. In fact, virtually every aspect of computer use is impacted by some form of policy.

Acquiring these information systems is also a key part of infrastructure, requiring a strategic plan and project management. A project management office (PMO) (in a larger healthcare organization) or project manager aids in compiling a project’s budget, allocating resources, maintaining a task list, identifying dependencies among tasks, establishing timelines, and managing a schedule. The PMO may focus only on health information systems or may be broader in scope to encompass other major projects, such as building construction, mergers and acquisitions, and others.

Supporting infrastructure also must address security. Healthcare is facing increasing security threats – both internal and external. Security processes can take time and attention that is often thought to detract from the primary purpose of healthcare, which is highly time sensitive. Until recently, it has also been thought that healthcare data carry little monetary value and hence are “safer” than other data. This is not true, and theft of healthcare data can carry much more severe ramifications for individuals whose information is compromised. Data security is discussed in chapter 10, Data Security.

Connectivity Systems

Connectivity systems (see figure 11.2) help support the exchange of data across separate information systems within a healthcare organization and across organizations, and also with individuals.

To exchange data among health information systems, computers must be networked together. When exchanging data within the organization, the network is referred to as a local area network (LAN), and when exchanging data across organizations, such as from a provider to a payer, the network is referred to as a wide area network (WAN). WANs need a secure connection, which is often a virtual private network (VPN), which is an encrypted private connection over the internet.

Increasingly, both hospitals and physicians not only exchange information among providers and with patients for treatment and payment, but also move data for operational functions, such as for supplying quality data to a registry as previously described, and to store data. Various data storage management (archiving data organized for retrieval) techniques exist. These may include a storage area network (SAN) that supports the ability to retrieve data from any storage location for use in the EHR. Some SANs may be local to the healthcare organization. Others may use cloud computing, which refers to using computing services remotely over the internet, often through a vendor or vendors to archive data and in some cases to provide application software, including an EHR (Knorr 2018).

In addition to operational needs for connectivity systems, there is also a growing need to exchange health information with disparate providers and patients for care purposes. There are essentially three general forms of connectivity processes used today in healthcare—telehealth, patient-­exchanged information, and health information exchange.

Telehealth and Newer Forms of Healthcare Delivery

The oldest form of exchanging health information is telehealth—a process that uses telecommunications to send voice, still pictures, and video between a remote location (where the patient is) and a base location (such as a hospital) for the purposes of diagnosis and, in some cases, treatment. Some might not consider telehealth to be a form of health information system because its primary purpose in providing remote healthcare is so often conveyed in sound or picture, though most telehealth conducted today does include the exchange of health information.

Telehealth, however, has many challenges, some of which are only now being addressed. For example, connectivity is a challenge because telehealth is so often used to reach remote parts of the country, on a battlefield, and across the world. Telecommunications technology is not always the best in such areas. Broadband, for example, is still not available, or at least reliable, in all parts of the US. Physician licensure has been another major challenge, where a physician may not be licensed to practice in another state, hence precluding the ability to cross state lines when conducting telehealth. Reimbursement for telehealth is not always provided by health plans, or only under certain, limited conditions. Specialized equipment must also be brought to the site where the patient is located. All these challenges are being addressed where there is high need. For example, robots have been developed to reach injured soldiers. The Veterans Administration (VA) has constructed all its telehealth services to rely solely on dial-up telephone connections because many veterans needing telehealth are in remote areas. Telehealth is experiencing increasing interest to reach prison inmates, inner city communities where there are safety issues, and in various care coordination activities where patients have transportation limitations. Medicare reimbursement for telehealth services continues to expand.

In addition to telehealth, new forms of healthcare delivery are being adopted. Some are very “low-tech” such as e-visits (telephone communications between patient and provider) and others such as hospital-in-the-home (where new connectivity mechanisms help monitor patients at home) have more technology requirements (Carollo 2018). What is also new relating to these technologies is the level of reimbursement for such services, the recognition that keeping people outside of a physician’s office waiting room or even a hospital bed may reduce spread of infection, and make people more comfortable and happier which can also contribute to health improvement.

New technologies that have an information system component to them include new medical procedures, prosthetics, and machine learning. New medical procedures include techniques such as liquid biopsies that monitor tumors noninvasively. 3D printing is creating new prosthetics and ways to improve organ and tissue repairs (Das 2016). It was previously described that AI is the ability for software algorithms to analyze data and make applicable recommendations (including to 3D printers). Extending beyond AI is machine learning, in which AI applications adjust the algorithms supplied in the software based on additional data, potentially providing ever more sophisticated clinical decision support (Garbade 2018).

Patient-Exchanged Health Information

Another form of exchanging health information is to use the patient as the go-between. This might be considered even older than telehealth when considering the patient—or patient’s family member or caregiver—has always been the knowledge base for history of present illness and other information. However, from a technology perspective, portals, electronic personal health records, and the continuity of care document are technologies that are newer than telehealth.

A patient portal is special software that enables patients to log on to a website from home or a kiosk (special form of input device geared to people less familiar with computers) in a provider’s waiting room to have access to some of their health information and other services. In many cases, the portal is used primarily for administrative functions, such as to request an appointment and even directly schedule an appointment, pay bills, obtain patient educational material, sign informed consents, exchange email with a provider, and request release of information. Under the MU program, the portal has been a common way for patients to access their health summary information. In some cases, the portal only provides health summary information. In other cases, it may provide a view into parts of the EHR or even the entire EHR. A portal may also be a way to access a personal health record supplied by a provider. (However, the MU program does not require a PHR.) In some cases, patients are starting to enter their own health history using a template that directs them to enter specific information via the portal that is then available to providers during the visit. Some providers are supporting e-visits through a portal, where existing patients can exchange email in lieu of visiting the physician’s office for follow-up or recurring care needs. E-visits are now reimbursable by some insurance companies. Portals are also used by providers to connect from their office to a hospital or other healthcare organization, and to health plans, such as for eligibility verification or for submitting prior authorization requests.

The personal health record (PHR) has been defined by AHIMA as an electronic or paper health record maintained and updated by an individual for himself or herself; a tool that individuals can use to collect, track, and share past and current information about their health or the health of someone in their care. Although use of an electronic system for PHRs is encouraged by AHIMA, many more patients use a paper-based file folder as their PHR rather than an electronic offering. Whether electronic or paper-based, patients are expected to own and manage the information in the PHR, which comes from both healthcare providers and the individual. The PHR is maintained in a secure and private environment, with the patient determining rights of access. It is separate from and does not replace the legal health record of any provider or their EHR.

Today, PHRs are in a state of transition. The PHR may be provided through a portal offered by a provider or may be a stand-alone system offered via a vendor, employer, or affinity group that may be managed by the stand-alone entity or by the patient. A PHR offered by a healthcare provider is an excellent tool if there is only one PHR for all who treat the patient, and especially if it enables more than minimal functionality. If a patient has multiple healthcare providers, however, it is likely that the patient will also have multiple PHRs. Today, there is little connectivity between the PHRs. The patient might as well have a paper-based record system of their own if they wish to have any integration of data across these PHRs. PHRs offered by many healthcare providers also do not allow patients to enter data, rather they can only view lab results and other summary health information. This somewhat defeats the purpose of having a centralized place that can be used to document changes in personal health status or communicate in real time with providers about changes in a patient’s health status, such as high blood sugars or weight gain in a patient with congestive heart failure.

PHRs have been most popular with patients who have chronic illnesses or with caretakers of elderly patients having to manage multiple providers, many drugs, and other data.

The continuity of care document (CCD) is yet another effort to supply patients with more information about their healthcare. The CCD is essentially a set of summary data about an episode of care. It uses the Clinical Document Architecture (CDA) standard developed by HL7 that aids in the creation and exchange of XML documents between health information systems. When the CCD is rendered as an XML document, the CDA provides structure (including a description of document content for users and discrete data for computer processing), vocabulary standards, and codes for sharing clinical documents in XML ­format. Subsequently, HL7 has created a transport mechanism not only for the CCD, but for a number of other healthcare documents. These document templates are collectively referred to as the Consolidated Clinical Document Architecture (C-CDA).

The C-CDA may be transmitted electronically via HL7 standard messages, in attachments to emails, or via standard internet file transfer protocols, such as file transfer protocol (FTP).

Because the traditional HL7 (and other healthcare information standards) only enable point-to-point exchange of data rather than seamless, on-demand information exchange such as is performed on the WWW, HL7 has created a new standard it is calling the Fast Healthcare Interoperability Resource (FHIR). FHIR is a set of resources that address common use cases in exchanging health information. They are based on application program interface (API) technology, which provides a set of tools for building software applications. FHIR ­resources each have a tag that acts as a unique identifier, much like the URL of a web page. A FHIR resource can support the exchange of text (including documents from the C-CDA), structured data elements, and metadata across a wide variety of devices from computers to cell phones (Bresnick 2016).

Another set of technologies that are supporting patient-exchanged health information are those from other industries. Non-healthcare companies merging with healthcare organizations or even planning to offer new forms of support for patients are lending considerable knowledge and skills to healthcare, including new applications for typically non-healthcare information systems. Something as simple as customer relationship management (CRM) systems (which serve as a database of customers [patients] and relationships they may or could have with service providers, such as transportation companies, home health agencies, meals-on-wheels, and others) can be helpful. For example, care coordinators and patient navigators could use a CRM system as they attempt to arrange transportation services for patients to get to their physician offices for follow-up visits (Auer 2015). CRM systems can also aid in provider networking tasks and patient engagement.

Health Information Exchange

Health information exchange (HIE) is another way to exchange information across multiple organizations and individuals. HIE is most often managed by an organization referred to as a health information organization (HIO). The HIO typically provides governance, fee structure, and policies and procedures for exchanging health information; it is a business associate under HIPAA. HIOs have struggled financially, as paying for exchanging health information when generally provider-to-provider exchange has been free of charge—albeit a slow process—has not been accepted as well as expected.

In general, an HIO provides several key services, shown in figure 11.7. These include:

Figure 11.7 HIO services

Source: © Margret\A Consulting, LLC. Reprinted with permission.

· Patient identification, usually using an identity matching algorithm in which specified patient demographic information is ­compared to select the patient for whom information is to be exchanged. The algorithmic process is determined by the vendor supplying the service but uses sophisticated probability equations to identify patients.

· The record locator service (RLS) is a process that seeks information about where a patient, once identified, may have a health record available to the HIO.

· Identity management (IdM) (not to be confused with patient identification) provides security functionality, including determining who (or what information system) is authorized to access information, authentication services, audit logging, encryption, and transmission controls.

· Consent management is yet another HIO service. In consent management, patients have opt in/opt out privileges for having their health information exchanged. As noted previously, the patient will often provide a consent directive for this purpose.

In addition to these basic services, each HIO establishes what type of data exchange it will support. For example, there are some that only conduct ­e-prescribing—exchanging prescriptions between providers who write prescriptions and retail pharmacies. Some states sponsor an HIO; if so, the HIO helps support public health activities (for example, immunization registry reporting) and often some basic exchange of emergency information. Because such HIOs must help exchange information across many disparate types of health information systems, usually only a limited amount of information is able to be exchanged. To exchange more comprehensive information (and perhaps also to gain market share), EHR vendors have started to support exchange of health information across all organizations using the same EHR vendor.

HIE is developing across the nation. Initially referred to as the nationwide health information network (NHIN), the federal government wants such a network to be grounded in both federal and private sector needs. Today this is referred to as the eHealth Exchange. It includes federal agencies involved in healthcare and nonfederal organizations coming together (with assistance from a federal contractor) to offer a secure, trusted, and interoperable health information exchange service (The Sequoia Project 2018). Today, the eHealth Exchange connects all 50 states and is used by the Department of Defense, VA, CMS, and Social Security Administration as well as 30 percent of all US hospitals, 10,000 medical groups, 8,200 pharmacies, and more than 900 dialysis centers—essentially connecting more than 100 million patients. Participants sign a Data Use and Reciprocal Support Agreement (DURSA), participant agreement, and testing agreement. There are both testing and exchange fees for use.

There are two ways to connect using the eHealth Exchange. They are the following:

1. Direct exchange uses an initiative called the Direct Project for securely pushing ­patient health information to a known, trusted receiver using secure email technology (HIMSS 2013).

2. CONNECT is an alternative way to connect with the eHealth Exchange. CONNECT is open-source software that implements health exchange specifications. It enables discovery of where there may be information as well as directly retrieving it from the source (HIMSS 2012b).

Systems Development Life Cycle

As described, health information systems include both technology (hardware and software) and operational elements addressing the needs of people (users), required policies, and process improvement. Health information systems also reflect a life cycle. This life cycle demonstrates the need to manage changes so the system continues to produce the desired results.

The systems development life cycle (SDLC) refers to the steps taken from an initial point of recognizing the need for a desired result, through the steps taken to ensure all components needed for the system to achieve the desired result are ­addressed. This cycle is repeated whenever the system fails to continue to produce the desired ­result (NIST 2008). Failure of an information system to produce the desired result may be due to internal or external changes. For example, if a health information system was acquired a number of years ago and there is a new federal mandate for adoption of new standards, the healthcare organization must address needed changes in the system, or obtain a replacement, to continue to produce desired results. The general nature of an SDLC is illustrated in figure 11.8.

Figure 11.8 Systems development life cycle

Source: © Margret\A Consulting, LLC. Reprinted with permission.

There may be variations in how the steps in the SDLC are described depending on the context in which it is used. For example, a hardware or software developer may go through an SDLC when creating a new product. The vendor may identify the need for a new product, then determine the feasibility of creating the new product with specifications that would satisfy the new product needs, design the product, develop it for mass production, maintain the product as small changes in the environment impact it, and monitor sales to justify continued maintenance or sunsetting (that is, no longer selling or supporting) the product. In a healthcare provider setting, the SDLC helps identify a need for health information systems support. The healthcare provider will then specify requirements needed to achieve the need, acquire a new information system, implement the new information system, maintain it, and monitor that it continues to meet needs over time. Sometimes a health information system may need to be replaced, in which case the SDLC of acquiring a new product is repeated.

While the SDLC is most often applied when information systems are being developed or acquired, it can be applied as part of a continuous improvement process to ensure that any system meets ­ongoing and new needs. For example, taking a systems view and applying the SDLC can be a useful process when planning any new service offerings. A hospital may be considering developing a center of excellence in orthopedics or acquiring small community hospitals. A physician’s office may be considering a merger or expansion of services into retail offerings. An integrated delivery network may be evaluating the usefulness of spinning off long-term care facilities it operates. The key value of the SDLC is to apply a formal logical process to ensure all components needed for a system to optimally achieve its value are in place. Each of the components in the SDLC is discussed next.

Identify Needs

Needs for a healthcare organization that a health information system should address arise from various activities conducted by the healthcare organization or may be mandated by the federal government, health plans with which the healthcare organization contracts, or other external sources. Commonly referred to as needs identification, a healthcare organization may periodically conduct strategic planning that identifies a need; for example, more timely data available to infection control nurses, or that the surgical suite needs to improve communications with other departments. A hospital may find that its major commercial health plan has decided to promote VBC, wherein access, price, quality, efficiency, and alignment of incentives, rather than volume alone factor into payment for care. Negotiating a VBC contract will necessitate significantly more integration of financial and clinical data.

Needs are most commonly expressed as goals. Goals for what and how health information systems will achieve desired results reflect current and anticipated needs and should drive all elements of planning for the systems. Ideally, these should be written as SMART goals, or statements that identify results that reflect the following:

· Specific

· Measurable

· Attainable

· Relevant

· Time-based

Figure 11.9 is an example of a SMART goal for a hospital performing strategic planning for a health information system.

Figure 11.9 Example of a SMART goal

Source: © Margret\A Consulting, LLC. Reprinted with permission.

Any given organization will have several SMART goals for its health information system. For example, a clinic may include the following goal in its planning:

· Physicians will reduce unnecessary diagnostic studies tests by 10 percent (measurable) over the next two years (time-based) using the interoperability capability of the system (realistic) that, when a test ­order is placed, makes available (attainable) the results from previous tests performed across the continuum of care for the patient specific to type of test and patient needs (specific).

SMART goals should address all system components, including desired functionality, specific technology requirements to support the desired functions, and the expectations for people to adopt new policies and processes to ensure achievement of goals and, therefore, provide value back to the organization for its investment (Amatayakul 2017b).

Specify Requirements

Once needs are identified, a healthcare organization will want to specify detailed requirements for how the needs can be met. For health information systems, most healthcare organizations convene a steering committee that will identify and document a detailed set of specifications, often referred to as a requirements specification.

A steering committee may be an overarching committee comprised of key stakeholders to health information systems in general, or, less commonly, a steering committee will be convened for each specific health information system project and include only stakeholders associated with that project. The latter is normally not advisable because of the systems nature of health IT. For example, a BC-MAR will be impacted by CPOE and a pharmacy information system. Ultimately, it will also need to be integrated with a medication reconciliation system and may need to interoperate in the future with a home medication administration system.

The broadest possible set of stakeholders in a steering committee will ensure that all needs for a specific health information system are met. Members of the steering committee for health information systems should include heavy representation from physicians, nurses, and other health professionals, including a physician champion. The physician champion is a well-respected physician who can informally help the physician community adapt to and ultimately adopt health information systems. The position of chief medical informatics officer (CMIO) is being created in hospitals and large clinics. The CMIO is a salaried physician (most often part time so that he or she retains credibility with other practicing physicians) who is heavily involved in policy development, workflow and process improvement, and ongoing maintenance of CDS and other systems requiring significant physician input. Both the physician champion and CMIO help achieve a clinical transformation—a fundamental change in how medicine is practiced using health information systems to aid in diagnosis and treatment.

In addition to the healthcare professional representation, IT representatives, the health information management professional, key operational staff, the procurement officer, and potentially others will round out the steering committee membership.

Guided by the SMART goals that define the overall need, the steering committee will seek input from the specific health information system’s key stakeholders to enumerate specific requirements. For example, when planning for a BC-MAR system, nurses, pharmacists, IT staff, physicians, and quality assurance professionals may be the key stakeholders. They will review the literature, consult with peers in other healthcare organizations, and perhaps attend a trade show or visit another healthcare organization with a BC-MAR system to understand more about it and what users like and do not like.

Design or Acquire

Today, most healthcare organizations acquire health information systems from a commercial vendor. There are few healthcare organizations left in the US that have and continue to support a home-grown, or self-designed information system—these are gradually being discarded in favor of commercial systems.

Commercial systems have several important ­advantages. First, they are generally cheaper in the long term because they offer economies of scale by selling the same product to many others. Second, they can be more interoperable. Vendors know they will have to do some integration with systems from other vendors in any given healthcare organization. In addition, with federal goals for interoperability (including changing the name of the program requiring an EHR from MU to Promoting Interoperability in its alternative payment models [CMS 2019]), vendors know they will not survive in the marketplace if their systems do not support interoperability. Third, the unique configurations that are often the hallmark of home-grown systems are feasible with many commercial products. These products offer toolkits that allow a user organization to tailor the information systems to their needs, while not impacting the underlying product’s architecture—thus assuring both customization for users and interoperability with other information systems. Finally, vendor longevity in the marketplace is more assured than that of the custom programmer hired for a specific job for one organization who then moves on to another custom job for another organization—leaving the first organization without ongoing support for maintenance of the system.

Acquiring a health information system may be performed in one of two ways. If a healthcare organization already has many health information system components from one vendor (often described as a best-of-fit environment), the healthcare organization likely will acquire additional components from the same vendor. A small amount of due diligence (steps taken to confirm various facts about the product) may be performed to ensure the healthcare organization that it does not need to go to another vendor to acquire the product, thus moving toward a best-of-breed environment where different components are acquired from different vendors. Much like home-grown systems, best-of-breed environments started disappearing during the MU program era, but may be returning as a result of the HL7 FHIR standard that supports much easier interoperability, thus enabling acquisition of more specialty products.

Whatever their status, healthcare organizations should acquire health information systems through a formal vendor selection process. The steps in vendor selection are the following:

1. Needs identification. This step entails understanding and documenting the goals for the information system being acquired.

2. Requirements specification. This involves determining and documenting the detailed features and functions desired in the information system in order to meet the healthcare organization’s specific goals.

Requirements specification must also describe the way the healthcare organization will acquire the health information system. Client/server systems are those where commercial software is installed on servers housed and maintained within the healthcare organization itself, housed within the healthcare organization and managed by an outsourced company, or housed and maintained by a contractor for the healthcare organization. The benefit to ­client/server systems is the ­extent to which the software can be configured to meet the special needs of the healthcare ­organization. The primary disadvantage is that the healthcare organization must manage the IT infrastructure or hire a contractor to do so. An alternative is an application service provider (ASP) or Software as a Service (SaaS) arrangement. There are both similarities and differences between these two. Both essentially offer health information systems on a subscription basis, with the software and servers housed remotely. In an ASP arrangement, only a moderate amount of custom configuration is feasible, and the healthcare organization pays for 100 percent usage time, but it does not have responsibility for managing the technology infrastructure. Functionality is delivered to the user via dedicated communications technology. The SaaS arrangement is similar to the ASP, but there is generally less custom configuration ability. The SaaS offers a pay as you go model, where you only pay for the actual time using the information system. This may work well for physician offices, but generally not for hospitals that have 24-hours a day, 7-days a week, 365-days a year use requirements. The SaaS model may be delivered via dedicated communications technology or cloud computing.

3. Request for Proposal (RFP). An RFP includes developing and disseminating a description of the healthcare organization, its goals for the information system, its requirements specification, and a statement of how the vendor should respond to the request for proposal. In recent years, an RFP was considered too much work both for organizations to compile and vendors to respond to. Many healthcare organizations were so new to health information systems that they did not know what requirements they wanted met. However, with more experience, many are realizing that it is probably the only way to ensure a comprehensive understanding of requirements and their availability in a product. Dissemination of the RFP was also challenging in the past with so many vendors. Small providers often relied on their specialty society recommendations or “friends,” who may have been biased and too narrow in scope should the practice expand beyond the one specialty. Today, the consumer is more informed and has had an opportunity to learn about a variety of vendors. Sending the RFP to four to six vendors is realistic and doable.

4. Analysis of RFP responses. This is a formal review of the responses to the RFPs against the requirements specification. This process should be done as objectively as possible. Often the requirements analysis is used as a score sheet to help identify gaps or potential issues. While it cannot be expected that any one vendor will be able to fully address every requirement, prioritizing the requirements and determining which vendors should be further considered is a key step. At this point the four to six vendors should be narrowed to three or four at the most.

5. Due diligence. This involves requesting a product demonstration, checking references, and potentially conducting site visits to see the product in actual use. Depending on the size and location of the healthcare organization, a product demonstration might be conducted on-site or via a webinar. However, it is conducted, there should be plenty of time set aside to fully put the product through its paces. Because most vendors will spend a lot of time before the actual product demonstration discussing the values and history of the company, the healthcare organization needs to take charge of the demonstration and set timelines for how much time should be spent on such introductory information, how much should be spent with the vendor conducting a demonstration, and how much time should be allowed for further discussion and even more in-depth review of certain features and functions. Demonstrations may range from a two-hour webinar to a full day or even longer on-site for large organizations. At least half of the time allotted should be spent on a detailed review of features and functions. At the conclusion of all forms of due diligence, a vendor and one backup should be chosen.

6. Contract negotiation. This may be the most critical, and often not well-performed, step in the vendor selection process. If money is to be spent on the vendor selection process, a consultant who knows the marketplace should be hired and legal counsel should be involved. Vendor contract offerings are notoriously one-sided. Recently, many small providers have realized that they did not negotiate that federally regulated updates to information systems must occur on a timely basis and at no cost to the healthcare organization. Many contracts also include payment schedules that require between 50 percent and 90 percent of the cost upfront—which should be far less. Contracts must also recognize the responsibilities of the vendor under HIPAA. The best form of contract negotiation is for the healthcare organization or organization representative to prepare a list of issues to be addressed, present it to the vendor, and then hold a series of conversations to address each issue. Price should be the final negotiation step. An important caveat in contract negotiation, however, is that the result should be a win-win situation, not a win-loss, where the vendor loses so much money on the deal that they are unwilling or become unable to deliver on their promises. Implementation should not begin with an adversarial relationship between the vendor and the organization.

Develop and Implement

Once a commercial product has been acquired, there are development and implementation steps to be taken by the healthcare organization and vendor. A large part of acquiring a commercial product is associated with the implementation of the product. The vendor installs the software on specified hardware. Usually the vendor is also contracted for managing the implementation and appoints a project manager to do so. During implementation, system configuration (sometimes called system build) is conducted. This process provides customization of templates, review and customization of decision support, and other functions; in addition, master files and directories are loaded, and potentially some data conversion is performed. For example, a physician’s office would want to have their logo displayed on the system, a list of all their patients made available to the application, fee schedules loaded, and data conversion to move their current accounts receivables to the new information system. Depending on whether there was a previous EHR, either EHR data must be moved to the new information system (data conversion), typically by a vendor or other contractor; or key parts of the paper health record content must be entered (chart conversion). This entry may be done by staff, a contractor, or new users as patients are seen. While new users usually do not want to do this, it is an excellent way to learn the information system and reduce unnecessary chart conversion steps.

Training is also a critical element of implementation. Some vendors will include, or sell for a separate price, training on using the information system, and may use a contractor for this. Other vendors supply a CD or webinar as their training option. This is usually insufficient for most new users, even when the user has experience with a different vendor’s information system. In addition, training is not a one-time event—there needs to ongoing orientation, introduction to principles, training, reinforcement, sometimes certification of users, and re-training or focused training. When the system is upgraded, modified, or enhanced, training is needed again. Most of such training is left to the healthcare organization. For additional information on training, see chapter 20, Human Resources Management and Professional Development.

Other implementation steps for which the healthcare organization is responsible are management of the vendor and elements of implementation related to people, policy, and processes. Most healthcare organizations find it necessary to also appoint a project manager who is responsible for managing vendor relations, including issues management where any issues that arise during the implementation are documented, brought to the attention of the vendor, and hopefully resolved or escalated so that resolution is accomplished. Most (but not all) vendors typically do not perform change management that helps new users become acclimated to the significant change in not only documentation but the practice of medicine that results from using health IT, (additional) training, go-live (first use of the information system in actual practice) support, monitoring usage post implementation, workflow and process analysis and redesign, and policy development. Experience has shown that these elements may be more critical to the success of a health information system than the hardware and software. Change management is discussed in chapter 17, Management.

Workflow, process analysis, and redesign are often acknowledged by a vendor as important, but most vendors do not have time to provide such services. Those vendors who are at the top of the pricing scale do provide workflow and process analysis and redesign—and their results demonstrate the value of this. Unfortunately, many healthcare organizations are so overwhelmed by the amount of effort required in an implementation that they either do not have the energy or overlook this critical step. As noted previously, unintended consequences can occur from use of health IT and most have been related to lack of training, lack of policy surrounding appropriate use of the information systems, and lack of attention to workflow and process changes (Amatayakul 2011).

Testing of the software to guarantee it works with the hardware selected, has been configured properly, and users understand how to use the information system is also challenging. Many vendors will claim that their system has already been tested by virtue of their numerous customers, but each customer will have a unique information system build so this argument is not fully valid. Testing is often left to either super users using the information system in advance of go-live and finding issues the vendor must address, or by the end users themselves as they start to use the information system. The latter is not desirable, as the end users are already fearful of the change. Unfortunately, time often runs out and users want to begin using the system before it can be fully tested by super users.

Maintain

System maintenance refers to numerous tasks that keep the health information system running smoothly. Some tasks are routine in nature, such as preventive maintenance including the application of security patches or upgrades as delivered by vendors; others are corrective, modifying, or enhancing and performed based on calls to the help desk with issues or change requests for a modification or enhancement. Any changes to the fundamental system should be documented in a formal change control program. A change control program ensures there is documented approval for the change to be made and evidence that all elements of implementation, testing, rollout, training, and such are performed.

In a client/server environment, routine and some corrective system maintenance is left to the healthcare organization’s staff or contractors; while other corrective, modifying, or enhancing maintenance may require consultation or direct work performed by the original vendor. Whoever performs system maintenance should provide regular reports on what maintenance has been done and this should be compared with policy, issues logs, and change requests. In an ASP or SaaS environment, most system maintenance will be performed by the vendor except for maintenance on local hardware and any software not covered by the ASP or SaaS vendor. Healthcare organizations are advised to keep track of issues they ­report to the ASP or SaaS vendor and confirm they are appropriately addressed.

Monitor Results

To complete the SDLC, monitoring results is an essential element that ensures health information systems continue to meet the healthcare organization’s goals and identify when there are new needs. A formal monitoring program should begin immediately after go-live. The project manager or a compliance officer (or both) may be responsible for monitoring. The monitoring program should include formal processes such as user surveys, ­observations, benefits realization studies, and results analysis, as well as informal processes like the proverbial bagel breakfasts, pizza lunches, or milk and cookie breaks. During and immediately after go-live, it is helpful to have a break room set up where new users can unwind and talk about the system. Food is always inviting and often eases tensions when there are issues. Other forms of celebration for getting through the go-live day and reaching other milestones are also helpful. As time passes to more routine use, informal feedback mechanisms may move to weekly, monthly, or quarterly opportunities, but should continue indefinitely. Feedback from both formal and ­informal methods should be documented and addressed. Users must see that their concerns are given attention.

Although results monitoring is improving, many healthcare organizations do not monitor results well. Staff complaints, technology issues, and low levels of use are often known, but not tracked in any formal manner. Often changes are not made until a crisis occurs or the next federal mandate is enforced. Monitoring use, however, can result in achieving full adoption and even optimization, which leads to goals being achieved more quickly and comprehensively.

HIM Roles

Health information professionals’ roles will continue to evolve as health information systems enhancements occur. Health information systems is very dynamic today. Constantly, new information technologies are being developed and new applications are being adopted for use in healthcare. In addition, there are many changes in regulations, standards, accreditation requirements, and practices that can significantly alter the course of health information systems. HIM professionals are able to identify new applications that are coming about as a result of new technology in general and in particular from mergers, acquisitions, and ventures of non-healthcare businesses (such Amazon, JPMorgan, and Berkshire Hathaway). It can be anticipated that in the next few years, significantly more changes will come about that impact healthcare. Examples of those changes may include the following:

· Use of CRM applications for care coordination

· Just-in-time delivery of services

· Increasing number of retail clinics and other delivery mechanisms to overcome access issues

· Consumer (patient) empowerment

· Analytics and artificial intelligence