Electronic Health Records (EHRs) for Long-Term and Post-Acute Care A Primer on Planning and Vendor Selection

1. Purpose and Executive Summary
1.1 Purpose of White Paper
1.2 Executive Summary
1.3 Disclaimer
2. Definitions
2.1 Electronic Health Records (EHR)
2.2 Electronic Medical Record (EMR)
2.3 Personal Health Record (PHR)
2.4 Health Information Technology (Health IT)
3. Plan for and Implement an EHR System
3.1 Assess
3.1.1 Outline Vision and Strategic Plan
3.1.1.1 Software Applications
3.1.1.2 Hardware
3.1.2 Assess Organizational Readiness: IT Infrastructure, IT Staffing, Skills & Attitudes
3.1.2.1 Organizational Health IT Readiness Assessment
3.1.2.2 Health IT Attitudes Assessment
3.1.2.3 Computer Skills Survey
3.1.2.4 IT Staffing Inventory
3.1.2.5 IT System Inventory
3.1.2.6 Health Information Exchange Readiness Inventory
3.1.3 Assess Financials
3.1.3.1 Financing Resources
3.1.3.2 Sources of Funds
3.2 Plan
3.2.1 Set Goals
3.2.1.1 Importance of Goals
3.2.1.2 Writing Goals
3.2.1.3 Templates for Tracking Goals
3.2.1.4 Resources for Goal Settings
3.2.2 Map Chart Data
3.2.2.1 Chart Conversion Planning
3.2.3 Workflow and Process Redesign
3.2.3.1 Importance of Workflow and Process Improvement
3.2.3.2 Process Mapping as a Means to Manage Change
3.2.3.3 Workflow and Process Mapping
3.2.3.4 Mapping Current Workflow and Processes
3.2.3.5 Workflow and Process Redesign
3.2.4 Different EHR Models
3.3 Select
3.3.1 Vendor Selection
3.3.1.1 What Are You Buying?
3.3.1.2 The Marketplace
3.3.1.3 CAST 7-Stage EHR Adoption Model for Long-Term and Post-Acute Care (LPTAC)
3.3.1.4 Price Ranges
3.3.1.5 Total Cost of Ownership and Return on Investment
3.3.1.6 Interoperability, Integration, Integration Engines, and Certification
3.3.1.7 Suggested EHR Selection Approach
4. EHR Selection Matrix Components
5. Acknowledgements
5.1 EHR Workgroup
5.2 Participating EHR Vendors

1. Purpose and Executive Summary

1.1. Purpose of White Paper

This white paper updates our 2012, 2013, and 2014 white papers. The purpose of this paper is to aid LeadingAge members, CAST members, and other aging services organizations in choosing an Electronic Health Record (EHR) system that fits the needs of the organization, its providers, and its consumers, patients, and clients.

This paper helps aging services organizations plan for and choose the best EHR system for their needs.

LeadingAge Minnesota (formerly Aging Services of Minnesota) contracted with Stratis Health of Bloomington, MN, to develop Health Information Technology (health IT) Toolkits for nursing homes and home health agencies (no longer available). In addition, recently Stratis Health developed a new toolkit on behavioral health that may have relevance to providers that offer these types of services and/ or cater to individuals with intellectual disabilities. The purpose of these toolkits was to help organizations assess readiness, plan, select, implement, and make effective use of EHRs, as well as to exchange important information about the people they serve.

LeadingAge and CAST helped LeadingAge Minnesota to promote the original toolkits, which help organizations understand what they should look for in EHRs and the steps for implementation. These toolkits are now longer publicly available on the Stratis Health website. In 2013 -2014, Stratis Health updated the original toolkits to include more information about interoperability and health information exchange. It also added a template to help providers estimate total cost of ownership and return on investments in EHRs. Our update of this white paper reflects the updates Stratis Health performed even though the resources are no longer available.

This paper summarizes the important steps a provider should take while referencing the excellent Stratis Health toolkits (no longer available). The paper then hones in on the next step of examining the fit of EHR products to the organization, its processes, needs, and requirements, based on the functionalities these products offer. Next, the paper examines functionalities needed or desired in different lines of aging services within long-term and post-acute care (LTPAC), including the following:

LTPAC attending physicians.
Home health/home care.
Hospice.
Adult day care.
Assisted living facilities.
Acute rehab facilities.
Long-term acute care hospitals.
Long-term care rehab facilities.
Skilled nursing facilities.
Intermediate care facilities.
Intellectual disabilities/mental retardation/developmental disabilities (ID/MR/DD) facilities.
Continuing care retirement communities (CCRC).
Program of All-Inclusive Care for the Elderly (PACE).
Vendors offering EHR systems specifically for LTPAC.

CAST engaged experts from provider members and EHR vendor communities. We asked vendors to provide information in three areas:

Implemented interoperability standards.
Integration and health information exchange capabilities.
Certification status and/or plans.

You can also access companion EHR Selection Matrix, online Selection Tool, and case studies.

CAST collected, and will publish separately, case studies that highlight providers’ impacts and benefits of the following:

Clinical decision support systems, including those aimed at reducing inappropriate hospital admission and acute care transfers (such as INTERACT, On-Time Quality Improvement, etc.),
Interoperability and health information exchange with other care providers, either directly or through a health information exchange (HIE), and/or
Analytic tools embedded in EHRs.

This paper is available in a PDF format as well as a living HTML document with links. CAST updates the EHR Selection Matrix annually. We then use the matrix to update CAST’s online Selection Tool, which helps LTPAC providers choose an EHR system. Additional updates to the online Selection Tool take place as needed.

This white paper and the companion EHR Selection Matrix, online CAST Electronic Health Records Selection Tool, and case studies continue CAST’s efforts to produce hands-on tools that help LTPAC providers adopt appropriate aging services technologies. These technologies enable providers to deliver innovative care delivery models and position providers well for strategic partnerships and the future.

EHRs, particularly interoperable ones that can exchange information with other providers and technologies, were the first enabling technology identified in the CAST strategic Scenario Planning exercise (please see A Look into the Future: Evaluating Business Models for Technology-Enabled Long-Term Services and Supports). Please also review our Strategic Planning and Strategic IT Planning portfolio.

1.2. Executive Summary

Setting goals and measuring progress on goals are important steps.

The paper begins with definitions for Electronic Health Records (EHR), Electronic Medical Records (EMR), Personal Health Records (PHR) and Health Information Technology (health IT). It then explains the steps involved in planning for and implementing electronic records, summarized from Section 3 of the Stratis Health Toolkits (no longer available). Adopting technologies like these involves two steps:

Assessing hardware, software, and staffing needs, and
Assessing financial resources and sources of funds.

Planning and implementation stages include setting goals, moving towards those goals, measuring progress on, and ensuring that the organization is on track to meet those goals. Successful purchase and implementation involves the following:

Mapping chart data, a process that aligns currently used data elements with the features of an EHR,
Planning the conversion process, and
Reviewing the workflow for opportunities to improve processes.

These are essential to maximizing the benefits of health IT.

There are differences between several models of EHRs, including locally hosted software, Application Service Providers (ASPs), and Software as a Service (SaaS). Each option has clear positives and negatives depending on an organization’s needs.

The paper walks providers through the must-have attributes, functionalities, and features of an EHR system.

Another key aspect is understanding what the organization is actually purchasing or leasing, what is available in the marketplace, the price ranges, and whether the system can interoperate and integrate with other software systems. The Vendor Selection section of the Stratis Health Toolkits (no longer available) assists with this task.

The paper then walks providers through the must-have attributes, functionalities, and features they need to consider before using the CAST EHR Selection Matrix and online EHR Selection Tool. The paper concludes with an explanation of the main elements of the EHR Selection Matrix, which compares EHR products on 225 features and functionalities. The matrix looks at each system’s fit for different business lines, integration, interoperability capabilities, certification status, software/hardware requirements, legal/regulatory compliance, cyberliability, and the vendor’s experience.

Key information from the EHR Selection Matrix is used in an online EHR Selection Tool. With the tool, LTPAC organizations answer key questions to narrow their selections to a manageable list of EHR products that meet their business line, care applicability needs, and essential requirements.

1.3. Disclaimer

The information included in this paper is meant to assist in the understanding and selection of Electronic Health Record (EHR) systems. A few vendors elected not to participate. Functionalities and capabilities of listed EHR products are as reported by the vendors and have not been verified, tested, independently evaluated, or endorsed by LeadingAge or LeadingAge CAST. Products mentioned in this paper serve as illustrative examples. Please use this as a general guideline in understanding functionalities and examples of current EHR systems.

The EHR Selection Matrix may help providers identify potential EHR solutions that may meet their requirements, as well as target vendors to invite to submit a Request for Proposal (RFP). Where appropriate, provider case studies have been identified and published separately. However, providers are strongly advised to verify functionalities of the EHRs prior to final selection through demonstrations, site visits, reference checking, and other due diligence.

Learn the difference between Electronic Health Records (EHR), Electronic Medical Record (EMR), and Personal Health Record (PHR).

2. Definitions

2.1. Electronic Health Records (EHR)

A longitudinal electronic record of patient health information generated by one or more encounters in any care delivery setting. Included in this information are patient demographics, progress notes, problems, medications, vital signs, past medical history, immunizations, laboratory data, and radiology reports. The EHR automates and streamlines the clinician’s workflow. The EHR has the ability to generate a complete record of a clinical patient encounter – as well as supporting other care-related activities directly or indirectly via interface – including evidence-based decision support, quality management, and outcomes reporting (Source: HIMSS).

2.2. Electronic Medical Record (EMR)

An electronic record of health-related information on an individual that can be created, gathered, managed, and consulted by authorized clinicians and staff within one health care organization (Source: The National Alliance for Health Information Technology Report to the Office of the National Coordinator for Health Information Technology on Defining Key Health Information Technology Terms, released on April 28, 2008).

An EMR is an application environment composed of the clinical data repository, clinical decision support, controlled medical vocabulary, order entry, computerized provider order entry, pharmacy, and clinical documentation applications. This environment supports the patient’s electronic medical record across inpatient and outpatient environments, and is used by healthcare practitioners to document, monitor, and manage health care delivery within a care delivery organization (CDO). The data in the EMR is the legal record of what happened to the patient during his or her encounter at the CDO and is owned by the CDO (Source: HIMSS).

2.3. Personal Health Record (PHR)

A universally accessible, layperson comprehensible, lifelong tool for managing relevant health information, promoting health maintenance and assisting with chronic disease management via an interactive, common data set of electronic health information and e-health tools. The PHR is owned, managed, and shared by the individual or his or her legal proxy(s) and must be secure to protect the privacy and confidentiality of the health information it contains. It is not a legal record unless so defined and is subject to various legal limitations (Source: HIMSS). Some EHRs offer patients/consumers the ability to view their records through web portals or the ability to export data to a PHR.

2.4. Health Information Technology (Health IT)

Health IT encompasses a broad array of technologies involved in managing and sharing patient information electronically, rather than through paper records. Health IT performs information processing using both computer hardware and software for the entry, storage, retrieval, sharing, and use of health care information (Source: Alliance for Health Reform). EHR, EMR, and PHR are examples of health IT.

3. Plan for and Implement an EHR System

LeadingAge Minnesota contracted with Stratis Health, a non-profit organization based in Bloomington, MN, to develop two Health Information Technology (health IT) Toolkits: one for nursing homes and one for home health agencies. In addition, Stratis Health recently developed a new toolkit on behavioral health that may have relevance to providers that offer these types of services and/ or cater for individuals with intellectual disabilities. These Toolkits are no longer available online.

The Stratis Health IT Toolkits focus on nursing homes, home health agencies, and behavioral health.

The purpose of these toolkits was to help providers assess readiness, plan, select, implement, make effective use of, and exchange important information about the people they serve. The toolkits, which are publicly available on Stratis Health’s website and were promoted by LeadingAge, CAST, and LeadingAge Minnesota, helped organizations understand steps they need to take in planning for implementing an EHR, and what to look for in an EHR. Stratis Health updated the original toolkits in 2013-2014 to include more information about interoperability and health information exchange. It also added a template to help providers estimate total cost of ownership and return on investments in EHRs. These toolkits are no longer available online.

This paper summarizes, organizes, and adapts the most important steps a providers need to take, pointing them to the most useful tools and templates, to help providers make the most of the Stratis toolkits. This paper then hones in on the next step, examining the fit of existing EHR products to the organization, its processes, needs and requirements, all based on the functionalities these products offer. The following subsections present the most important steps in planning for and implementing an EHR from the Stratis Health Toolkits (no longer available).

3.1. Assess

3.1.1. Outline Vision and Strategic Plan

Health IT refers to the broad class of information technology that aids health care organizations in achieving efficient and effective care delivery. Health IT encompasses software applications and hardware, as well as requisite people, policies, and processes. Getting true value from health IT comes from the organization’s ability to understand its operational needs, set strategic goals, set its own course, communicate expectations, engage all stakeholders, and celebrate success.

Clinical Information Systems support health care professionals in direct care delivery.

3.1.1.1. Software Applications

Within health IT there are many types of information system applications. These include the following:

Financial and Administrative Systems: These include resident/client registration-admission, discharge, transfer (R-ADT), resident/client financial services, and billing systems. Departmental, or ancillary, systems support the operations of various departments or types of staff; examples include nutrition and food services (N&FS) and therapy services (e.g., rehabilitation, physical therapy, and respiratory therapy). In addition these systems include management functions such as quality management, materials management, and executive decision support.
Clinical Information Systems: These support health care professionals in direct care delivery. When these clinical systems work together, they are often described as an EHR system. These systems often include several distinct modules such as the applications used for nursing documentation, nurse assessments, interdisciplinary care plans, clinical pathways, vital signs documentation, and workflow support.
Other applications include those for imaging and laboratory results retrieval and medical device data integration. More sophisticated clinical systems include computerized provider order entry (CPOE), electronic prescribing (ePrescribing), electronic/barcode medication administration records (eMAR/BC-MAR) that depend heavily on robust pharmacy information and automation, and other point-of-care (POC) charting. Clinical decision support systems (CDS) are advanced applications that usually work in conjunction with the EHR, CPOEs, and ePrescribing.
- Clinical data repository (CDR) is the means by which data from the various applications come together for various forms of processing.
- Electronic document management system (EDMS) is often used where a bridging strategy is needed to achieve a paperless environment when clinical systems are being implemented.
- Portals are another important application to connect different providers to one another, such as physicians to a long-term or post-acute care facility, or to provide patients or family access to their information. In general, a portal is a web interface that serves as a secure door to related sets of data and services.
- Data warehouse, on the other hand, is also a database, but one that has been optimized to collect and manage data on which complex queries and analyses, such as data mining, can be performed.
- Telehealth, personal health records (PHR), and health information exchange (HIE) services are yet other forms of health IT that are rapidly evolving and being adopted by large and small health care delivery organizations.
- Middleware is a final type of software that is important to include in health IT. While often not a concern to end users, various report writing applications, presentation layer utilities, interfaces, database management systems, and other software are required to make all of the end-user applications work.

3.1.1.2. Hardware

Information system applications require computer hardware. Hardware includes the various processing devices and servers needed to run the software applications. If an organization is using a hosted application, application service provider, software as a service (SaaS), or an on-demand application, the organization will not need to acquire servers in house; the vendor maintains these, and the organization pays a monthly fee for their use.

In some cases, you may not need to have in-house servers for your EHR systems.

The organization must have sufficient speed and bandwidth, and have some form of redundancy, or backup, in the event the organization’s primary network connection fails. For instance, the organization will very likely need a dedicated high-speed Internet line from an Internet service provider, but may also keep a commercial consumer Internet account for emergencies.

3.1.2. Assess Organizational Readiness: IT Infrastructure, IT Staffing, Skills & Attitudes

Data entry requires various input devices (e.g., desktop computers, laptops, tablets, personal data assistants [PDAs], speech microphones, etc.) and output devices (monitors, display screens, printers, fax machines, speakers, etc.); they are all hardware elements your organization will need. Data also must be archived, so storage functionality is needed. This may be part of your remote hosting, or something the organization needs in-house.

As health IT becomes more mission critical, backup storage and redundant processing devices are necessary, often with middleware applications to provide automatic failover. All of these devices must connect to one another in a network, so various network devices and their associated media (including various forms of cable for wired networks and wireless network capability) must be acquired and maintained. If the organization is using any form of hosted application, internal IT network capabilities will be critical.

There is a wide-ranging set of assessments necessary for effective planning for health IT. While the list may seem overwhelming, and the temptation may be to skip some or all of these steps, experience shows that a thorough understanding of the current state of organizational readiness is the single most critical factor in subsequent success in health IT adoption, implementation, and use.

Assessments help you learn if your organization is ready for an HIE, EHR, or health IT.

3.1.2.1. Organizational Health IT Readiness Assessment

One example of an effective assessment and planning tool includes Stratis Health’s Organizational Readiness Assessment for EHR and HIE survey developed for LeadingAge Minnesota. The tool, which is completed by an organization’s leadership team, assesses an organization’s readiness to implement an HIE, EHR, and health IT. The Stratis tool is no longer available, however, please consider using this assessment.

3.1.2.2. Health IT Attitudes Assessment

It’s important to understand an organization’s readiness for adopting an EHR and other health IT, including HIE. Understanding early attitudes and beliefs of both administrative and clinical staff (physicians, nurses, etc.) can help organizations plan, provide the right training, and encourage sustained use.

3.1.2.3. Computer Skills Survey

A computer skills survey will help the organization identify training needs and the available skills needed to plan for implementing an EHR and other health IT. The survey should cover basic computer skills as well as more advanced skills, such as the use of devices like handhelds, point of care (POC) technologies, and specific clinical applications. Consider using this template to conduct a survey of general computer skills.

3.1.2.4. IT Staffing Inventory

An IT Staffing Inventory will help the organization determine what IT staffing skills may be needed to implement specific health IT. It assesses the skills of existing staff, clinicians, and third parties and helps organizations plan for adding the needed skills. This IT Staffing Inventory sample instrument may be helpful

3.1.2.5. IT System Inventory

The IT System Inventory will allow you to do the following:

Identify and document all existing IT hardware and
Assess and budget for hardware required for each health IT application acquired.

It will guide you to look at servers (if available/applicable), operating systems, CPU type and speed (GHz), RAM size (GB), hard disk size, type and configuration, storage type and capacity, client servers, peripherals (e.g., wireless cards, speech recognition microphones), networks (LAN/WAN), routers/switches, firewalls, VPN, Internet Service Provider (ISP), broadband capability, wireless access points, transmission standards, encryption type, network monitoring tools (available or conducted by third party), storage, and other peripherals including mobile devices and POC technologies used by staff. It also covers software, licenses (general purpose), application provisions, database management systems, report writers, and storage management system.

Please note that the optimal hardware system requirement will depend on the EHR model you prefer—locally hosted on your own servers, or offered as a service (please see section 3.2.4 Different EHR Models). You may also want to consider the IT Infrastructure section of the CAST Strategic IT Planning Tools.

3.1.2.6. Health Information Exchange Readiness Inventory

Health Information Exchange (HIE) cannot be an afterthought. It should be considered in the early stages of the Health IT assessment, planning, and technology selection. This inventory will help you understand HIE definitions and technology. Furthermore, using the suggested tools, you can assess your organization’s readiness to utilize the HIE Service Provider that meets your needs. Consider using this instrument to assess HIE readiness.

Various funding sources may be available for health IT implementation.

3.1.3. Assess Financials

3.1.3.1. Financing Resources

Making a major investment in health IT is challenging for every organization. Of course, the size of the investment will depend on the scope of your project and choices the organization makes during planning and product/vendor selection. Reassess financing as you continue planning and implementing your health IT project.

The following provides a description of the various sources of funds that may be available for health IT implementation. While not every source is applicable to every organization, the list may generate ideas not previously considered.

The ASP or SaaS models are like renting an apartment, while the licensure model is like owning a home.

3.1.3.2. Sources of Funds

The following are possible sources of funds:

Cash Flow from Operations.
Use of Reserves.
Philanthropy: Although few organizations consider philanthropy, it can be an important source of funds, products, services, or in-kind contributions and should not be discounted. There are various forms of philanthropy including charitable contributions and grants from foundations. A few foundations that may fund projects in technology and aging are listed on the CAST website.
Grants: Obtaining grants requires skills and experience in writing grant proposals or completing grant applications, and in preparing reports to funders. You may hire or contract with a grant writer to help; just be aware of the associated costs. A few foundations that may fund projects in technology and aging are listed on the CAST website.
Local Businesses, Religious Organizations, Charities.
Malpractice Premium Relief: If your facility/operation carries malpractice insurance, the insurer may be willing to provide a discount or not increase premiums when certain health IT investments are made.
Tax Advantages: An accountant can help identify tax advantages for providers that are for-profit.
Group Purchasing Discounts: These discounts can be significant. Check LeadingAge Savings and Solutions Center.
Vendor Financing Options: Many vendors offer an application service provider (ASP) or software as a service (SaaS) model that is both a form of financing of the software as well as management of IT operations. The ASP or SaaS models are like renting an apartment, while the licensure model is like owning a home. The ASP/SaaS models require little or no down payment, generally demand less staffing, have lower hardware costs, and allow your organization to pay as you go. But they may offer less control and customization capability and the long-term cost may end up being higher.
Remote Hosting or Outsourcing: This option is similar to the ASP model, but it typically refers only to management of the data center (remote or local) and hardware/telecommunications, not the software. Although outsourcing can help reduce the cost of IT staffing and may make it more reliable with a strong service level agreement, organizations may also find it more expensive than having only one full-time equivalent staff member. Local markets and availability of employees can make a difference as well.
Leasing: This option generally applies only to the hardware you acquire and that you manage yourself or include in an outsourcing arrangement.
Debt and Equity Financing: Bank loans and lines of credit are frequently tapped to support health IT purchases.
Open Source Products: Consider evaluating health IT based on open source code, like VistA, the Department of Veterans Affairs EHR, which was made available by the federal government in fall 2005 through the Freedom of Information Act. There are licensing fees associated with open source systems for the database systems the software runs on, various subscriptions to support code sets and other utilities, vendors who help implement the system and potentially help maintain it, and development/customization of any needed interfaces with existing billing or other systems.
Medicare and Medicaid EHR Incentive Program: Under Medicare, eligible professionals (EP), which include physicians and nurse practitioners, may choose to assign their incentive payments to their employer or to an entity with which they have a contractual arrangement. In exchange, certified EHR technology (CEHRT) will be available to them. Under Medicaid, EPs also can choose to assign their incentive payments to their employer or to other state-designated entities. For more information, please see the CMS EHR Incentive Program website and the Frequently Asked Questions on the EHR Incentive Program. For more information about Meaningful Use, applicability to LTPAC settings, and eligibility of LTPAC providers for Meaningful Use incentives, please see the following CAST FAQ article.

S.M.A.R.T. goals are best—Specific Measurable, Attainable, Realistic, and Trackable.

3.2. Plan

3.2.1. Set Goals

3.2.1.1. Importance of Goals

An important step in health IT planning is for all stakeholders to identify and commit to achieving specific, measurable goals. These goals establish the expectations for learning about health IT, preparing for change, selecting a suitable product, ensuring a solid implementation, and optimizing the technologies used.

3.2.1.2. Writing Goals

Many organizations recognize the importance of S.M.A.R.T. goals. The acronym has taken on many meanings to fit specific organizations’ needs.

Specific: Goals should identify who, what, where, when, and why. They should be well defined and clear to anyone who has a basic knowledge of the workings of the organization. Some also suggest that the goals not only need to be Significant enough to make the investment in achieving the goal but Stretching for the organization to push itself to continuously strive for improvement.
Measurable: Goals should answer the questions “How much?” and “How many?” to determine when a goal has been accomplished. To be measurable, goals must contain specific Metrics, be Meaningful, and be Motivational.
Attainable and Agreed upon: Although the most common citations of S.M.A.R.T. goals refer to the need to develop attitudes, abilities, skills, and financial capacity to reach the goals being set, gaining consensus on Acceptable goals and commitment to Achieving the goals are critical as well.
Realistic, Relevant, Reasonable, Rewarding, and Result-oriented: Goals must reflect the availability of resources, knowledge, and time so they can be achieved.
Timely, Tangible, and Trackable: Enough time must be given to acquire and learn to use health IT in support of achieving goals. Once adequate time has been determined, specific target dates should be assigned to key deliverables to incite a sense of urgency while giving the organization a transparent way to track its progress towards meeting the goals.

3.2.1.3. Templates for Tracking Goals

LTPAC provider organizations may be concerned about writing S.M.A.R.T. goals because they do not have baseline data, or because they fear results will be difficult to achieve. These issues are actually a part of the problem—not a reason for inaction. If baseline data are not available today, now is the time to start collecting current data for the most important functions. Cultivating a culture of quality measurement, reporting, and improvement is often more important than implementing the health IT. It is essential to engage the end users in setting expectations, providing the commitment and support to achieving the expectations, and then measuring, reporting, and celebrating success.

Record results periodically until your target date so that you know if you are on course.

Start out with a general statement, such as the example in the column labeled Objective in the above-referenced documents. As you dissect the organization’s goal to determine how health IT can help achieve it, you will be describing the intended action. Identify the sources of data and which application within health IT or EHR will enable you to make improvements. Define the metrics so you have a clear understanding of what data to collect. Record your current baseline data. Then set your goal by summarizing the improvement you think can be made within a realistic timeframe and target dates when possible for using the new health IT or EHR application.

You might also want to record the rationale for setting the goal and any obstacles to achieving it that you see. For instance, some expected outcomes may be set for you by regulations or contract. An obstacle may be that the pharmacy you work with is not yet up on ePrescribing so you may not be able to fully achieve your goal until they adopt the technology.

Finally, record results periodically until the target date for achieving your goal is reached. If you wait until the targeted time, you will not know whether you are on course to meet the goal and you will not be able to implement corrective action to meet your deadline. While the deadlines are self-imposed, timeliness is a key motivator. In the example from an actual nursing home in the template referenced above, the goal to “eliminate Adverse Drug Events (ADEs)…” may sound impossible, but nursing homes that set this goal expected to achieve it, and got very close within the first six months of implementing an ePrescribing system.

3.2.1.4. Resources for Goal Settings

Identifying all the goals for a given health IT project may take some time. To help structure your goals, consider the major functions your facility/operation performs. Examples are provided in the tables included in the Stratis Health Goal Setting templates for home health agencies. These tables list many of these functions for the respective settings as well as some of the complementary functions relevant to HIE. Add or delete descriptions in the table to fit the functions of your facility or operation. Focus on the functions that need health IT support.

3.2.2. Map Chart Data

Mapping resident/client chart data is a process that aligns currently used data elements with the features of an EHR.

A chart conversion tool helps you move information from paper charts into EHRs.

3.2.2.1. Chart Conversion Planning

Although chart conversion should not be performed until after EHR implementation and immediately prior to going live, careful planning in advance can help in both selecting a product and making the chart conversion process go smoothly when applied. The two primary means to convert chart content are abstracting data and scanning documents to be stored in the EHR. The goal of an EHR implementation should be to convert as much as possible to a paperless record.

Starting this process with chart analysis in the planning phase of your project helps you identify data elements that are currently kept in the chart, their source, their format, and how frequently they are needed, accessed, and by whom. During this process you can determine data essential to have in your EHR, how the data are processed, and other EHR requirements. These data generally need to be abstracted from existing charts. You can also identify documents that you will scan and store in the EHR, as well as ones that will remain in paper form.

After vendor selection and EHR implementation, the process of chart conversion pre-populates the new EHR with select resident/client information, making adoption easier for staff. Consider what support the vendor can offer in this process. If you are selecting an EHR vendor, your preference for one chart conversion method over another becomes an important consideration. Consider using and/or adapting this sample instrument for chart conversion/abstraction.

You need to consider the following:

Whether to scan all documents to free the chart room and use the space differently.
Cost on all factors.
Quality control on abstracting. Some vendors will provide a special template for abstracting for chart conversion.
Will paper be destroyed, warehoused, or miniaturized? Do you currently have a retention schedule and destruction policy? Does it have special legal requirements? Do not destroy any records where there may be potential litigation.
What policies and procedures will ensure that hybrid records (i.e., part electronic/part paper) will not be created?

Finally, the EHR capabilities in managing scanned document should be weighed when settling on an EHR.

3.2.3. Workflow and Process Redesign

3.2.3.1. Importance of Workflow and Process Improvement

Change due to health IT needs to be managed not only to help individuals overcome their concerns and adopt the technology well, but also to ensure that the change brought about by the technology is the right change for the organization.

Workflow and process changes must be understood and managed. Workflow and process changes should be made to take advantage of health IT, but must also point out the control points that must be present or should be added to the systems for optimal results.
Professional judgment must be applied when using any tool, including all forms of health IT. Computers can crunch data tirelessly and remind humans who may be forgetful in the rush of their everyday lives. However, they are not substitutes—no matter how well-programmed—for the experience that trained workers bring to health care. Workflow and process changes should aid professionals, but are not substitutes for them.

To overcome resistance to change, demonstrate computer systems’ quality, efficiencies, and patient safety.

3.2.3.2. Process Mapping as a Means to Manage Change

Process improvement experts suggest that the best way to help potential new users of information systems overcome resistance to the change is to demonstrate the quality efficiencies and patient safety of computer systems and to engage users in making their own changes.

3.2.3.3. Workflow and Process Mapping

Process mapping is a fairly well-defined science, with a number of tools and techniques that can be deployed to understand current workflows and processes as well as identify opportunities for improvement.

3.2.3.4. Mapping Current Workflow and Processes

The following steps should be used to map current workflow and processes:

Identify processes to be mapped, those that will be impacted by the health IT being acquired.
Use individuals who actually perform the process; they know it best and they need to own the impending change.
Instruct persons on process mapping, why it is being done and how it is done.
Map current processes. Avoid identifying opportunities for improvement now, because critical controls built into current processes may be overlooked.
Validate maps to ensure they reflect current processes, all variations, and all the information needed. This is the time to be candid about how processes and workflow really occur in the current state, including workarounds, so that the new health IT-supported processes can be developed in ways that are most productive and helpful.
Collect all forms and reports that are part of processes to be automated through health IT.
Obtain benchmark data to define expectations for change and for use in benefits realization studies.

3.2.3.5. Workflow and Process Redesign

Map how the workflows and processes will be performed with health IT. Identify potential problems in current workflows and processes and determine their root cause. Things to look for include bottlenecks, sources of delay, rework due to errors, role ambiguity, unnecessary duplications, unnecessary steps, long cycle time, lack of adherence to standards, lack of information, and lack of quality controls.

3.2.4. Different EHR Models

Not all EHRs are the same. As with all enterprise solutions, there are options for the organization that include the following:

Locally Hosted Software: Option to own the hardware and purchase the EHR software and host it on servers local to the organization.
Hosted: Outsource the hosting of purchased/licensed application to a third-party hosting service provider that manages the hardware, communications, and data center on behalf of the organization.
Software as a Service (SaaS): Applications are hosted remotely by the vendor.

With SaaS and hosted services, you will need to have a reliable Internet connection in order to access data; however, a real benefit is that the information is already being backed up offsite. With local, self-hosted software, you have it all onsite, but that also means that any system upgrades must be done locally, whereas you may not even notice the small tweaks that may occur on the backend with SaaS.

Price can also play a factor, where purchasing software can be more expensive from the onset, but less expensive over time as the software is bought and owned outright. SaaS may be less expensive to initially get up and running; however, the lease payments may go on indefinitely.

The table below provides a quick comparison among the three models:

Other things to consider include the following:

IT staffing: skills and availability/staffing levels.
Downtime.
Data backup.
Data security.
Power outage.
Internet connectivity: reliability/outage and speed.
System’s ability to work offline (if SaaS or 3rd party hosted).

A thoughtful and thorough vendor selection process ensures you get what you need.

3.3. Select

3.3.1. Vendor Selection

3.3.1.1. What Are You Buying?

The first question an organization should ask in the process of acquiring health IT is this: What are we buying? This question may seem strange, but you may set out to acquire an EHR and find great variation—including everything from an automated system to document minimum data sets (MDS) to a robust product that supports all aspects of documentation, communication across the continuum of care, and clinical decision support. As a result, you need to undertake a thoughtful and thorough vendor selection process to ensure you get what you need, as well as a product that will enable you to grow into additional health IT as it becomes available.

You may find that some EHR vendors will suggest replacing your financial/administrative system so that these functions are more integrated with the EHR. Based on your strategic plan, you may first need to acquire some source systems that your EHR will communicate with, such as a laboratory information system. You may wish to follow a migration path that enables you to acquire modules one at a time in some sequence that is logical for your organization. If you belong to a corporate structure that supplies a standard system, you may be going to market to acquire a module that you have special need for, but that is not included in the standard system. So what are you buying? The most important thing about this question is to answer it for your organization.

Please see section 3.3.1.5 Interoperability and Integration for more information.

3.3.1.2. The Marketplace

The marketplace for EHR vendors in LTPAC providers includes products designed for nursing homes as well as assisted living providers, durable medical equipment providers, home care providers, pharmacy, rehabilitation providers, and continuing care retirement communities offering services at different levels of care. This market is highly volatile: vendors come and go, merge and get acquired, and fail to respond to surveys or regulatory changes. Many claim that they have an EHR when by most definitions they do not.

More costly products may provide more functionality, robust decision support, and customization.

3.3.1.3. CAST 7-Stage EHR Adoption Model for Long-Term and Post-Acute Care (LPTAC)

The CAST 7-Stage EHR Adoption model is generalized model that provides a framework to assess the level of adoption and sophistication of use, as opposed to just the overall rate of adoption, of EHRs in long-term and post-acute care.

The model draws from HIMSS 7-Stage EMR Adoption Model, PointClickCare’s 7-Stage LTC EHR Adoption Model, and Gutkind-Savage’s 10-Stage International EHR Adoption Model. The model was reviewed and approved by the EHR Workgroup.

This 7-stage model is generic and is based on the types of functionalities, their sophistication and focus, as opposed to rigid specific functions. This approach makes the model amenable to be adapted for and applied to multiple LTPAC settings and business lines, unlike previous EHR adoption models, which mostly focused on inpatient settings; namely hospitals and nursing homes.

The 7-stages of the model and the corresponding functionalities are described below.

Stage 1-Basic Information System

Stage 1 is a basic information system that should not be even called an electronic health record (EHR) as it does not have the clinical elements of an EHR. This stage allows the provider to complete basic business functions like accepting/admitting a new patient/resident/client into an LTPAC setting. This stage includes the following functionalities:

Basic patient demographic information for Admissions, Discharge, and Transfers (ADT); – Mandatory
Regulatory, Standard, or Common Assessment (like MDS, OASIS, IRF-PAI, InterRAI, etc.) or other information that the provider needs to collect; – Mandatory
Care/ Service Delivery Documentation by direct care/service staff primarily for accounting and billing purposes; –Mandatory
Electronic submission of assessment and care documentation data to regulatory agencies (if applicable). – Mandatory

This stage may or may not include electronic Point of Care (laptop, tablet, kiosk, hand-held), and/or Billing component/integration. Theclient has to have all Mandatory functionalities implemented to qualify for this stage.

While some providers/ vendors start with this stage, many choose to implement this stage along with stage 2.

Stage 2-Basic EHR

Functionalities included in this stage make the information system qualify for a basic electronic health record (EHR). This stage includes the following functionalities:

Clinical Patient/Resident/Client History; – Mandatory
Lists (Diagnoses, Problems, Medications, Allergies); – Mandatory
Clinical Charting and Documentation; – Mandatory
Care Plan; and – Mandatory
Interdisciplinary Notes (e.g., Physician, Nurse, Therapist, Pharmacist, etc.). – Optional

This stage may or may not include Point of Care (laptop, tablet, kiosk, hand-held, medication carts, etc.), and/or Billing component/integration. The client has to have all Mandatory functionalities implemented to qualify for this stage.

Stage 3- Ancillary & Clinical Administration (Non-Integrated)

This stage extends the EHR beyond its basic setting-specific functionalities to other ancillary areas, and adds efficiency capabilities. This stage includes the following functionalities:

Orders (Medications, Lab., Radiology, Diagnostic Tests, Therapy, Referrals); – Mandatory
Electronic Medication Administration/Treatment/Adherence Record (if applicable) (not at Point of Care); – Mandatory
Point of Care Assessment/ Service Documentation (Laptop, Tablet, Kiosk, etc.); – Mandatory
Workflow Engine (Workflow Sheets, Next Step Prompts, Alerts, Reminders, and Tasks); and – Optional
Results (e.g., Medications, Lab., Radiology, Diagnostic Tests, Therapy, etc.). – Optional

The client has to have all Mandatory functionalities implemented to qualify for this stage; having any of the optional functionalities is an added bonus.

Stage 4- Advanced EHR (Internal Quality-Focused)

This stage adds functionalities and capabilities that allow providers to use their EHR to improve care quality inside their organization. This stage includes the following functionalities:

Clinical Decision Support (CDS) Capabilities (e.g., INTERACT, Reducing Hospitalization, Medications, Falls Prevention, Pressure Ulcers Prevention, Pressure Ulcer Treatment, Wound Care, Reducing Acquired Infections, Catheterizations, Chronic Disease Management, etc.); – Mandatory
Electronic Medication Administration at the Point of Care (eMAR/eTAR, Unit Dispensing, Closed Loop Verification, Home Medication Dispensers (if applicable)) at Point of Care; – Mandatory
Quality Reports, Analytics, and Dashboards (e.g., Hospital Readmission, Quality Measures, Length of Stay (if applicable), etc.); – Mandatory
Therapy Documentation at the Point of Care (if applicable); – Optional
Decision Support at the Point of Care; and – Optional
Integration with Devices, including Point of Care Vital Sign Devices, Telehealth and Remote Monitoring (RPM), Medication Dispensers, Activity Monitoring, etc. (if applicable). – Optional

Note 1: Items a, b, d, and f are care setting/business line dependent.

Note 2: The client has to have all Mandatory functionalities implemented to qualify for this stage; having any of the optional functionalities is an added bonus.

Stage 5- External Ancillary Services Integration

This stage focuses on basic integration between the EHR and other external and ancillary systems. This stage includes the following functionalities:

Pharmacy Integration; – Mandatory
Electronic Referral and Discharge Systems of hospitals or other care providers; – Optional
Lab. Integration; – Optional
Diagnostics Integration; – Optional
Radiology Integration; – Optional
Eligibility/Coverage Checking (if applicable, especially for systems with integrated billing/ financials); and – Optional
Formulary Checking. – Optional

The client has to have all Mandatory functionalities implemented to qualify for this stage; having any of the optional functionalities is an added bonus.

Stage 6- Engagement & Basic Information Exchange

This stage focuses on tools and capabilities that aim to engage different members of the care team, including the physician and possibly the patient/resident/client, as well as basic information exchange capabilities. This stage includes the following functionalities:

Physician Portal and eSignature; – Mandatory
Prescribing and Computerized Physician Order Entry (CPOE); – Mandatory
Sending and/or Receiving Clinical Care Documents (CCD), Summaries, SBAR, Care Plans, and other information electronically as in human and machine-readable format (txt, pdf) (e.g., ONC Project Direct, eHealth Data Solution’s CareWatch Connect, etc.) directly to/from other providers; – Mandatory
Patient/ Resident Portal or exporting data to a Personal Health Records (PHRs); – Optional
Family/ Caregiver Portal or integration with such tools; – Optional
Care Planning Portal or integration with such tools; – Optional
Care Navigator/Care Coordinator Portal or integration with such tools; – Optional
Secure Messaging between care team members; and – Optional
Public Health Reporting. – Optional

The client has to have all Mandatory functionalities implemented to qualify for this stage; having any of the optional functionalities is an added bonus.

Stage 7- Interoperability & Health Information Exchange

This stage represents the ideal full interoperability stage the sector strives for that allows the exchange of information in a standards-based data format that other EHRs cannot only understand, but can also consume. This stage includes the following functionalities:

Sending/Receiving information to/from other EHRs (including Physician and/or Hospital EHRs) electronically through an HIE or exchange entity in a standards-based consumable data format (e.g., XML, HL7, FIHR); – Mandatory
Sending/Receiving information to/from EHR Repository in a standards-based consumable data format (e.g., XML, HL7, FIHR); and – Optional
Sending/Receiving information to/from other EHRs (including Physician and/or Hospital EHRs) electronically directly in a standards-based consumable data format (e.g., XML, HL7, FIHR). – Optional

The client has to have all Mandatory functionalities implemented to qualify for this stage; having any of the optional functionalities is an added bonus.

The figure below illustrates CAST’s Generic 7-Stage LTPAC EHR Adoption Model.

3.3.1.4. Price Ranges

little information is publicly available concerning the price of products for the LTPAC market. A few generic cautions apply:

Very inexpensive products may be based on Microsoft Office products—such as Word, Excel, or Access—and have minimal processing capability. They primarily make information more readily accessible.
The next tier of products may be somewhat more robust in their functionality but do not yet have all the sophisticated clinical decision support or other functionality of a top tier product, do not interface (or do not interface well) with other systems, and often are not very customizable.
This tier of products may also include electronic document management systems (EDMS) that only provide scanning and indexing functions for paper documents and other information in digital form. Being “digital” does not mean the data within the digital structure are discrete. For example, a transcribed document may be digital because it can be electronically loaded into a repository and retrieved for viewing from multiple sites. An electronic signature may be able to be affixed to this document. You may even be able to index the document to highlight allergy information or certain other standard information. This information can only be viewed; specific data cannot be retrieved by the computer for reports.
Another tier of products may be EHR-lite versions of more robust products. They look and feel like their more expensive counterparts, but they don’t have the same flexibility or support. These are frequently offered in hosted or SaaS mode, which provides a source of financing support as well as reduces the cost to the organization for maintaining its own servers.
More expensive products generally provide greater levels of functionality, include more robust decision support, and are more highly customizable. The vendor spends considerable money on research and development to continuously provide new functionality. The level of interoperability within these product suites and with other vendors’ products is variable. Vendors are making concerted efforts to become more interoperable. Service levels, attention to workflow and process support, testing and training, and customer responsiveness are generally stronger in this tier of products.

In this paper, we attempted to get pricing information from vendors who contributed information about their products, as well as sample contracts. The majority of vendors would be willing to provide such information during the Request for Proposals (RFP) phase or under a Non-Disclosure Agreement (NDA).

For examples of the cost of different EHR systems, please see the CIO Consortiums EMR Cost Study Report.

Various resources help you calculate costs and return on investment.

3.3.1.5. Total Cost of Ownership and Return on Investment

Developing a business case helps determine the readiness for making a specific investment, creates a value proposition, and describes how an investment will be recouped. For an investment EHR or HIE, the business case identifies the costs and benefits to plan for in acquiring such technology. The business case can serve as a means to evaluate how products will meet expectations and fit your financial resources, serves as a budget during implementation, and helps evaluate whether you are achieving your return on investment (ROI).

Stratis Health developed an excellent Business Case template that can help you calculate the total cost of ownership and estimate ROI.

3.3.1.6. Interoperability, Integration, Integration Engines, and Certification

Interoperability means that two disparate systems are able to communicate with one another to exchange data. To end users and many in the industry, interoperability means every product works together seamlessly. Unfortunately, this is an expectation that not even the most highly integrated suite of components in a product fully achieves yet.

When modules or components are integrated, they generally have been built by the same group that did the original development and programming, have similar design characteristics, and most data are able to be exchanged. In general, the components or modules in highly integrated suites of products work well together, but they will not work with any other vendor’s product without specialized interfacing.

Choose and work with EHRs that implement interoperability standards, and consider CAST’s additional recommendations below.

Products with modules and components for different clinical and administrative needs may save considerable money in managing interfaces and are a very good strategy. However, you may find that these products do not offer what you need. EHR products that implement interoperability standards facilitate exchanging information between systems and make system integration easier. Moreover, such EHRs facilitate health information exchange with other care providers either directly, point-to-point, or via a regional or state-level health information exchange organization like Regional Health Information Organizations (RHIOs) and state HIE entities.

Recommendations: CAST highly recommends that you do the following:

Choose and work with EHRs that implement interoperability standards.
Seek opportunities to participate in state and regional HIE entities.
Consider utilizing third-party solution providers, like eHealth Data Solution’s CW Connect, to receive and send continuity of care documents (CCD) or consolidated clinical document architecture (CCDA).(Page no longer available)
Consider exchanging health information through the Direct project, administered by the Office of the National Coordinator for Health Information Technology.
Consider using the KeyHIE Transform Tool to send functional assessment data (MDS, and OASIS) to other providers, even when you don’t have an EHR.
HIE involves working on communications to reach agreement about critical data elements to exchange, workflows, protocols, and expectations regarding follow up.
Consider working with integration engines.

When one vendor does not meet your needs, find a complementary product, wait, or adapt a different product.

When a single vendor system does not meet the required needs, three options are available:

Acquire a complementary product that meets the more critical needs (e.g., an acute care EHR for clinical and health information exchange needs),
Wait because the state of affairs has been improving for the last several years and products that implement interoperability standards and certification are expected, or
Acquire a different product altogether and adopt one or more of the following strategies:
- Work with the vendors of the different components on integration and interoperability.
- Attempt to interface with other organizations for exchange of minimum essential information. Health care organizations that want to interface directly with another organization should also consider whether this is necessary or only desirable. The volume and type of data that actually needs to be exchanged between most organizations may not warrant full interfacing or integration, but merely the ability to gain access to view or retrieve print files.
- Use a secure portal to provide access to view information and in some cases to use one or more of the hospital’s applications directly.

One goal for integration engines is a user-friendly interface for multiple Health IT systems that may also be compatible with mobile devices.

Additional Considerations:

Integration Engines: Integration engines add flexibility to EHRs and assist with connecting data from various applications and typically non-integrated systems. The goal is for the interface to be user friendly and based on modern technology so that there is compatibility with smartphones, tablets, and other mobile devices. Integration engines allow changing applications as needed and interfacing with telehealth monitors and other telemedicine devices. Integration engines can be either built into the EHR software or stand-alone.
Integration engines have the capability to interface with data entry points that replicate to all other fields that require the information, obtain data from source applications, collect resident/client clinical data, accept non-standard data transmission (Excel, text, etc.), support Electronic Data Interchange (EDI) formats for exchanging data (ANSI X12), and identify, prioritize, and escalate uncompleted tasks.
Mapping Functions: Mapping functions allow the Integration engine to transform and filter data from source applications, route transactional data, filter user-defined demographic elements, and generate standard Health Level 7 (HL7) transactions.
Clinical Analytics: Clinical analytics enable the development of clinical and business rules, tracking occupancy and utilization on a daily basis, and generating reports automatically as well as making the data accessible without running the reports.
External Integration: External integration may include integration with ePrescribing systems, lab orders and results, public health reporting, eReferrals (electronic referrals), and HIE as well as inventory management and other provider management information systems.
Interoperability Certification: Interoperability certification testing is important for EHR users, particularly for exchanging health information with other EHR systems, other providers, and HIE organizations. The Certification Commission for Health Information Technology (CCHIT®) is a nonprofit 501(c)(3) organization with the public mission of accelerating the adoption of health IT. CCHIT is the only certification body that had a certification program dedicated for LTPAC EHRs; the program had certification criteria for EHRs for nursing homes as well as home health agencies.
CHIT Certified® EHR certification is an independently developed, rigorous inspection of integrated EHR functionality, interoperability, and security. As part of the process, successful use is verified at live sites and product usability is rated. It is intended to serve providers looking for greater assurance that a product will meet their complex needs. However, CCHIT announced that it will no longer certify EHR technology and their certification as it relates to the meaningful use program expired in 2014. Consequently, we removed this type of certification from the CAST EHR Selection Matrix and the Online Selection Tool.
The Office of the National Coordinator for Health Information Technology – Authorized Testing and Certification Bodies (ONC-ATCB), on the other hand, signifies to eligible professionals, hospitals, and critical access hospitals that an EHR technology has the capabilities necessary to support their efforts to meet the goals and objectives of Meaningful Use. ONC-ATCB certification inspection is limited to the Health and Human Services (HHS) criteria and standards. It is modular so the technology inspected may not meet all of the requirements. The Certification Facts™ label shares which of the criteria are met. Providers are responsible for assuring that certified EHR technology meets all of the requirements in order to demonstrate Meaningful Use and achieve incentives. No site verification or usability testing is done under this program.

Summary of Interoperability: In this paper, we gathered information about interoperability standards implemented in the EHR products as well as whether these products are certified for interoperability by one of the bodies that certify interoperability of EHR products. Moreover, we identified EHRs that have integrated ancillary clinical, financial, and human resources systems, EHR that are capable of integrating with third-party ancillary systems, as well as integration engines that facilitate integration between different information systems. Finally, we identified the certification status for EHRs included.

It’s important for an EHR system to document services delivery for Medicare certification.

3.3.1.7. Suggested EHR Selection Approach

Develop a Set of Requirements. Once an organization has completed the visioning and strategic planning exercise, assessed organizational readiness, assembled the project team, set the project’s goals, mapped workflows and prepared for process redesign, then the team needs to develop a set of requirements to use as criteria to review and select the appropriate EHR that can help achieve desired goals and meets an organization’s needs. These include the care setting(s) where you want to deploy the EHR (Home Health, Skilled Nursing Facility, etc.).

Important Functionalities:

Documentation: An important feature is whether the EHR system provides documentation of services delivery for Medicare certification/ recertification. Other important functionalities include the various aspects of clinical documentation capabilities including physician documentation, nurse practitioner/physician assistant (NP/PA) documentation, history and physical, other professional and consultation notes/records, resident/client diagnoses, final progress note/discharge note, pharmacist drug review capability, MD/NP/PA Physician Quality Reporting System (PQRS) reporting, physician place of capture (SNF vs. NF), and summary of care document to patient/family.
Drug Therapy: Moreover, EHR functionalities relevant to drug therapy are also important. These functionalities include bidirectional electronic prescribing (ePrescribing) that allows three-way communication among the prescribing physician, the long-term or post-acute provider and the pharmacy, electronic medication administration records (eMAR), electronic treatment records (eTAR), closed loop verification of patient and medication (using bar code systems, for example), interfacing to medication adherence records (from medication dispensers, for example), and medication reconciliation capabilities.
Discharge Summary Report: Another important selection factor is the EHR’s ability to generate and exchange a discharge summary report.
Clinical Decision Support Systems (CDSS): Some of the increasingly important factors in narrowing down potential vendors include clinical decision support systems (CDSS) capabilities that implement best practices, help guide clinicians’ decisions, and affect quality outcomes and indicators. Common clinical decision support system functionalities to consider include CDSS for the reduction/ prevention of falls, medication management (drug-drug and drug-allergy interactions), prevention and treatment of pressure ulcers, CDSS for reducing inappropriate transfer to ED/hospital or interventions to reduce acute care transfers tool (INTERACT), reduction of heath care-acquired infections, and CDSS for the reduction of antipsychotics.
Full Integration: The EHR system’s ability to offer a fully integrated system that includes financial, ancillary clinical systems, and human resource management modules/components is also an important selection factor. Alternatively, the EHR system should have the ability to integrate with other third-party financial (billing/accounts receivable/accounts payable/general ledger, etc.), human resources management (scheduling, time and attendance, payroll), and/or ancillary clinical systems (pharmacy, labs, radiology, etc.). Another important integration feature is the EHR’s ability to integrate information across multiple sites, which is important especially for multi-site organizations.
Electronic Health Information Exchange Capabilities: Electronic health information exchange capabilities are gaining significant importance for purposes of care coordination, especially around shared care and transitions of care. Important interoperability modalities include Interface with HIE/Regional Health Information Exchange (RHIO), Direct Provider-Provider Transfer of Care or Direct Provider-Provider Shared Care/Care Coordination Interoperability, Interface with Hospital/Discharge System, Interface to Consultant Pharmacy Systems, the ability to send and receive documents via ONC’s DIRECT Project (Interim Interoperability), and the ability to export information to PHR and/or Resident/Client Portal (e.g., Human-Readable Blue Button) or Provider-Consumer/Consumer-Provider Interoperability.
Certification: As mentioned above, certification provides added assurance of interoperability. Providers are encouraged to determine if they need a certified her. The preferred type of certification includes the 2014 ONC-ATCB certification, which is focused on Meaningful Use.
Hardware and Software Requirements: Finally, hardware and software requirements that could be important to the selection process include whether the software is offered as
- A local model, which means that it needs to be installed on servers local to the care provider, or
- Third-party hosted/Software as a Service Model (SaaS), where the software is hosted somewhere else and the provider pays licensing and hosting fees or pays for usage, as opposed to maintaining local servers’ infrastructure.

Other important hardware and software requirements include remote access functionality support, off-line functionality support (when running third-party hosted or SaaS software), mobile device support (i.e., smartphones and tablets) and remote access to the EHR.

Use the CAST EHR online Selection Tool to narrow your selection.

You can use the CAST EHR online Selection Tool to narrow down your selection to a few shortlisted candidate systems/ vendors that meet your must-have high-level requirements.

In the CAST EHR Selection Matrix that follows, we outline many additional options and detailed features and functionalities that will help drill down into these shortlisted products further and narrow the selection to a list of two to three vendors that can be invited to submit request for proposals. Stratis Health has developed a Vendor RFP Process Tool that providers may find helpful.

During the RFP process, providers are encouraged to interview prospective vendors, engage front staff as well as nursing and medical directors and representatives from management, finance, and IT teams in the interviews and product evaluation. We encourage you to check provider case studies with the vendors, including those collected by CAST, and to conduct appropriate due diligence and check references. In addition, providers may want to use the LeadingAge CAST/ Technology Listserv to ask peers about the shortlisted products and their experience with these vendors. LeadingAge members can sign-up for the CAST Listserv on https://my.LeadingAge.org web site. Stratis Health developed an EHR-HIE Vendor Selection Due Diligence tool that providers may find helpful.

4. EHR Selection Matrix Components

CAST’s EHR workgroup, consisting of providers, vendors, and consultants, compiled a list of EHR products that serve the LTPAC market, as well as a list of functionalities and capabilities that would help providers choose the EHR product that best fits their business line and functional requirements. Each of the EHR vendors was then invited to complete a self-review of the workgroup’s pre-determined questions. Some of these vendors chose not to participate. Those who did participate were then invited to nominate a case study from a provider’s perspective on the use of the vendor’s EHR product.

The EHR Selection Matrix includes the following information:

Business Line/Care Applicability: This illustrates the various business lines to which the EHR software is applicable, including Home Health/Home Care, Hospice, Adult Day Care, Attending LTPAC Physician, Assisted Living, Acute Rehab Facilities, Long-term Acute Care Hospitals, Long-term Care Rehab Facilities, Skilled Nursing Facilities, Intermediate Care Facilities, ID/MR/DD Facilities, CCRCs and PACE.
Provider Functional Requirements: These are the basic requirements that a user would look for in identifying an appropriate EHR. These include Resident/Client Demographics; Advance Directives; Resident/Client Medical History; Clinical Notes; Lists: Problems, Allergies, Medications; Resident/Client Scheduling; Staff Scheduling; Census; Single Medical Record Support; Customizable Templates; Workflow Management/Next Step Prompts; and Reminders; and Global Search Capabilities.
Regulatory Assessments: These include Resident Assessment Instruments such as Minimum Data Set (MDS), Care Area Assessments (CAA), Outcome and Assessment Information Set (OASIS), In-Patient Rehabilitation Facility-Patient Assessment Instrument (IRF-PAI), Preadmission Assessment, Admission Assessment, Fall Assessment, Skin Assessment, Bowel and Bladder Assessment, Physical Restraint Assessment, Self-Administration of Medication, Nutrition Assessment, Activities/Recreation/Leisure Interest Assessment, Social Service Assessment, Mental and Psychosocial Functioning Assessment, Restorative/Rehab Nursing Assessment and Rehabilitation Services Assessment. There are also opportunities for vendors to share Customizable Assessments and to List Additional Assessments they offer.
Medicare Documentation/Service Delivery Records: These are documentation records that include Skilled Nursing Charting, Therapy Charting, Supporting Documentation for the MDS, Therapy Treatment Time, ADL Charting, Mood and Behavior Documentation, Hospital Documentation, Medicare Certification/Recertification, Other Clinical Flow Records, Lab Orders, Lab Results, Radiology Orders, Radiology Results, Diagnostic Test Orders Other than Radiology and Labs, Diagnostic Test Results Other than Radiology and Labs, Public Health Reporting (e.g., Tuberculosis), Physician Documentation, Admission Orders, and Physician Order Recaps/Renewals.
Physician Progress Notes: These are specific documentation for clinicians and include NP/PA Documentation, History and Physical, Other Professional and Consultation Records/Notes, Resident/Client Diagnoses, Physician Documentation, Final Progress Note/Discharge Note, Pharmacist Drug Review Capability, MD/NP/PA PQRS Reporting, Physician Place of Services Capture (SNF vs. NF), and Summary of Care Document to Patient/Family.
Drug Therapy: This involves the various options available from EHR vendors for tracking and administering medications, including Evaluation of a Resident/Client’s Signs and Symptoms, Frequency and Monitoring of the Medication, Dose Reduction Schedules and Documentation, eMAR, eTAR, Med Orders, Closed-Loop Medication Verification (the ability to cross check that medication was properly administered from start to finish, using bar code scanning for patients and medications at administration), and ePrescribing – Bi-Directional.
Consents, Acknowledgements and Notices: These include Informed Consent for Use of a Restraint, Consent, Notice and Authorization to Use/Release Clinical Records, Notice of Bed Hold Policy and Readmission, Notice of Legal Rights and Services, Notice Before Transfer, and Notice Prior to Change of Room or Roommate.
Transitions of Care, Shared Care & Discharge Documents: These include Shareable Plan of Care (including Goals and Instructions), Summary Reports for Discharge, Transfers and Consults, Diagnostic Imaging Report (DIR), Operative Notes, Procedure Notes, Progress Notes, History and Physical Notes, Continuity of Care Document (CCD), Discharge Order, Discharge Note, Transfer Form, Physician’s Discharge Summary vs. Discharge Record, Patient Education Resources and Medication Reconciliation (hospital d/c list vs. facility or physician list).
Clinical Decision Support Systems (CDSS): These link health observations with health knowledge to influence health choices by clinicians for improved health care. The Selection Matrix breaks out CDSS for Falls, Medication Management (Drug-Drug and Drug-Allergy Interactions), Pressure Ulcers, Reduction of Health Care-Acquired Infections, Hospitalization/Hospital Readmission Prevention, Antipsychotic Reduction, and Interventions to Reduce Inappropriate Hospital Admission and Acute Care Transfers Tool (INTERACT Version 3). This year we expanded the section to include OnTime Falls Prevention, OnTime Prevention of Pressure Ulcers, OnTime Pressure Ulcer Healing, OnTime Preventable Transfer to ED/ Hospital, and Other CDSS Systems.
Provider Non-Functional Requirements: This is where the EHR Selection Matrix goes next. It begins with Interfacing, Integration and Add-ons that provide the ability to integrate or add on systems to the functionality of the EHR. These include Biometric Telehealth/Telemonitoring Technologies, Wellness Monitoring and Behavioral Monitoring Technologies, Safety Monitoring Technologies, and Medication Self-Adherence (Individual Med. Dispenser). This year, we expanded the matrix to include support for mobile/wearable devices for data input and output, support for voice recognition and support for a digital camera. We also asked vendors if their software functions as an Integration Engine. Finally, we asked vendors whether their EHR is a Fully Integrated System that includes Financial, Ancillary Clinical Systems, and Human Resource Management, or a modular system that has the capability to integrate with the following:
- Financial (Billing/AR/AP/General Ledger, etc.),
- Human Resources Management (Scheduling, Time and Attendance, Payroll),
- Third party Ancillary Clinical Systems (Pharmacy, Labs, Radiology etc.) and/or
- Other Management Software/Systems.
Third-Party Software/Interfaces: We also asked vendors the following question: “Does the EHR Require Third-Party Software/Interfaces for any Functionality Checked?” and asked them to list Third-Party Software/Interfaces Required for Checked Functionalities. The EHR’s ability to provide Multiple Site Integration was also asked. This year, we also added the following question: “Does your EHR interface with content/document management system/devices? (If so, please list).
Dashboard Views: We continue to ask vendors if they offer Dashboard Views, however, we expanded this question by asking if the Dashboard View Integration is Real-Time, Batch, Manual Transfer or Manual Manipulation. Furthermore, is a third-party integration platform required for the Dashboard View? The ability to integrate with an analytic tool, such as Population Health Management, MDS, OASIS, and Quality Report, was also addressed this year. Lastly, the ability to integrate with Consulting Pharmacy Software was also added.
Supportability: Supportability allows providers to understand what sort of support the EHR system offers that includes Phone Support (Yes; 24 hours, Yes; limited hours, No), Web Support (Yes; 24 hours, Yes; limited hours, No), Email Support, Listserv and/or Usergroup, Onsite Training, or Other forms of support.
Interoperability: Interoperability is the ability of applications to exchange data with other applications. These include Send via Fax (Interim Interoperability), Receive via Fax (Interim Interoperability), Send/Receive via ONC’s DIRECT Project (Interim Interoperability), Direct Provider-Provider Transfer of Care, Direct Provider-Provider Shared Care/Care Coordination, Provider-Consumer/Consumer-Provider, HIE/Regional Health Information Exchange (RHIO), ePrescribing and Medication Management, Intra-Provider System Interoperability, Interoperability/Health Information Exchange – Non-Standards-Based, Hybrid and Standards-Based, Exporting to PHR and/or Resident/Client Portal (e.g., Human Readable or Machine Readable Blue Button), Interface with Hospital/Discharge System, Interface to Consultant Pharmacy Systems, ability for the EHR Product to Exchange Data as Codes, Freeform Text, or Both, and whether the EHR has Application Program Interfaces (APIs), and for what data.
Interoperability Standards Implemented: These include ISO5 Consumer Empowerment and Access to Clinical Information via Portable Media Version 1, ISO6 Quality Version 1, NCPDP 10.6 or Higher, HL7 CCD, HL7 CDA, HL7 Consolidated CDA, HL7 CDA Personal Health Monitoring Report, HL7 CDA Framework for Functional Assessment Questionnaire, Other HL7 Standards, Blue Button Plus – Machine Readable, ICD-9 Diagnosis and Procedures (whether through billing clearinghouse or built in compatibility), ICD-10 Diagnosis and Procedures (whether through billing clearinghouse or built in compatibility), LOINC – Laboratory and Clinical results, HCPCS/CPT – Ancillary Services, Procedures and Modifiers, NDC- Medications (Manufacturers), RxNorm – Medications (Ordering), UNII – Allergies and Adverse Reactions, SNOMED CT – Reference Terminology for Clinical Data and Other Standards. Lastly, we added IHE BPPC–Basic Patient Privacy Consent Profile and EDI HIPAA Profile/ File Formats (Please List) to this year’s matrix.
2014 ONC-ATCB Certification Status: The certification status is included and enhanced to clarify whether certification is Complete EHR or Modular EHR with links for verification, and the vendors are asked if they intend to pursue ONC’s planned voluntary LTPAC certification.
Hardware and Software Requirements: These include Minimum Processor Speed, Hard Drive Storage, RAM requirements, if any applicable, Operating System compatibility, Mobile Support, Network Specifications, Wireless Specifications, Supported by Modern Browsers (CSS3/HTML5), Internet/Bandwidth Specifications, Miscellaneous Software/Applets Needed (i.e. Citrix), Miscellaneous Reporting Specifications (i.e., Crystal Reports), Scalability, Local Model, Hosted Model, Software as a Service Model (SaaS), Remote Access, Off-Line Functionality (Functions During Internet Outage for Hosted and SaaS Models), and Ability to Store/Handle Attachments (Insurance card, Historical Notes, etc.).
Legal/Regulatory/Cyberliability: These requirements include the capability to generate an acceptable representation of a legal health record, intellectual property rights, adherence to telecommunication requirements, and other features. This is a requirement of critical interest to health care organizations. The system must be able to support upgrades to any required data collection process, rules for regulatory review, and new code sets as they may become mandated (such as ICD-10-CM). Whether a vendor provides support for E-Signature for Beneficiary and/or support for E-Signature for Authorized User is included. This year we added whether a vendor is Audited and Approved for ePrescribing Controlled Substances.
Company’s Experience and Viability: This includes Number of Years in Business, Release Date of Current Version, Number of Facility/Site/Agency Installations and Core Customer Base, Focus of Line of Business. This year the KLAS static rating was added, which is based on satisfaction data provided by product users. We also added and asked vendors to provide a link to the KLAS dynamic rating if available.
Strengths, Areas for Improvement, Ongoing Development, and References: These also provide Links to Additional Case Studies.
CAST 7-Stage EHR Adoption Model: Includes the vendor’s perceived percentage of LTPAC clients they have in each stage along with an overall averages and weighted averages based on the number of installations for each vendor.

5. Acknowledgements

We would like to thank Stratis Health for their original work on the toolkits. We also would like to thank Jennifer Lundblad, CEO, Stratis Health; Dr. Paul Kleeberg, CMIO, Stratis Health; Stratis Health Nursing Home team; tool builders; and their health IT consultants for updating the toolkits and completing a review of this paper.

5.1. EHR Workgroup

Majd Alwan, LeadingAge CAST
Scott Code, LeadingAge CAST
Bob Bardach, Jewish Home at Rockleigh
John Becker, Baptist Retirement Homes of North Carolina
Eva Bering, Landis Homes
Brandon Busch, St. Paul’s
Peter Carcia, Renaissance Technology Consultants Group
Jenny Copeland, VorroHealth
Jennifer D’Angelo, Christian Health Care Center
Audrey DeFeo, Jewish Geriatric Services, Inc.
Dusanka Delovska-Trajkova, Ingleside at King Farm
Carrina Ekvall, American HealthTech
David Dring, Selfhelp Community Services, Inc.
Celma Dumaguing, Providence Rest
Josephine Felicilda, Providence Rest
Michael Gillmer, Moravian Hall Square
Colleen Goodwin, Goodwin House Bailey’s Crossroads
Bob Hendrix, Episcopal Senior Communities
Fran Hinckley, Hebrew SeniorLife
Linda Jansen, Shell Point Retirement Community
Linda Kleinfeld, Health Care Software, Inc.
Rick Mallia, Francis E. Parker Memorial Home
Travis Masonis, Jewish Senior Life
Lori Meyer, LeadingAge Minnesota
Tom Mottl, Renaissance Informatics Group
Carrie O’Connell, Health Care Software, Inc.
John Passe, Jennings Center for Older Adults
Vannia Posada, Morningside House
Lynne Seligman, Workflow Analytics
Darrell Shreve, LeadingAge Minnesota
Bill Southerland, Yardi/ALMSA
Kevin Stagg, Christian Health Care Center
Nancy Stoddard, Jewish Home Lifecare
Sunghee Tak, University of Memphis
Anne Veno, Episcopal Church Home
Billy Waldrop, VorroHealth
Kristal Wood, PointClickCare
Scott Zacks, Medical Business Solutions

5.2. Participating EHR Vendors

Twenty-six vendors, including 7 CAST Partners, Supporters and Business Associates, participated in developing the EHR Portfolio. These included:

LeadingAge Gold Partner with CAST Focus, PointClickCare, Heath Odom, Jayne Warwick
LeadingAge Silver Partner with CAST Focus, MatrixCare, Ben Malakoff
CAST Supporter, Netsmart, Jeremy Mercer

CAST Business Associate participating in the portfolio included:

American HealthTech , Carrina Ekvall, Cheryl Turk-Peterson
Cantata Health (formerly NTT Data), Robert Skinner, Kim Allen, Susan Dryden
Health Care Software, Thomas Fahey, Linda S. Kleinfeld
LG CNS, Robert Baker and Jay Lee

Other participating vendors included:

ADS Data Systems, Beth Scovill
American Data, John E. Eder
BlueStrata EMR, Phil Paspalas
CareMerge, John Studzinski
Cerner Extended Care, Nick Fink
gEHRiMed, Rod Baird
LINTECH, Doron Gutkind
MED e-care Healthcare Solutions, Inc., Cynthia Hood
Momentum Healthcare, Rod Kamins
SigmaCare by MatrixCare
SOS Corp., Sean Garner
VorroHealth (Formerly BlueStep), Jeremiah Johnson
Yardi/ALMSA, Bill Southerland, Sharon Ashcraft

Electronic Health Records (EHRs) for Long-Term and Post-Acute Care A Primer on Planning and Vendor Selection

Contents

1. Purpose and Executive Summary

1.1. Purpose of White Paper

This paper helps aging services organizations plan for and choose the best EHR system for their needs.

You can also access companion EHR Selection Matrix, online Selection Tool, and case studies.

1.2. Executive Summary

The paper walks providers through the must-have attributes, functionalities, and features of an EHR system.

1.3. Disclaimer

Learn the difference between Electronic Health Records (EHR), Electronic Medical Record (EMR), and Personal Health Record (PHR).

2. Definitions

2.1. Electronic Health Records (EHR)

2.2. Electronic Medical Record (EMR)

2.3. Personal Health Record (PHR)

2.4. Health Information Technology (Health IT)

3. Plan for and Implement an EHR System

The Stratis Health IT Toolkits focus on nursing homes, home health agencies, and behavioral health.

3.1. Assess

3.1.1. Outline Vision and Strategic Plan

Clinical Information Systems support health care professionals in direct care delivery.

3.1.1.1. Software Applications

3.1.1.2. Hardware

In some cases, you may not need to have in-house servers for your EHR systems.

3.1.2. Assess Organizational Readiness: IT Infrastructure, IT Staffing, Skills & Attitudes

Assessments help you learn if your organization is ready for an HIE, EHR, or health IT.

3.1.2.1. Organizational Health IT Readiness Assessment

3.1.2.2. Health IT Attitudes Assessment

3.1.2.3. Computer Skills Survey

3.1.2.4. IT Staffing Inventory

3.1.2.5. IT System Inventory

3.1.2.6. Health Information Exchange Readiness Inventory

Various funding sources may be available for health IT implementation.

3.1.3. Assess Financials

3.1.3.1. Financing Resources

The ASP or SaaS models are like renting an apartment, while the licensure model is like owning a home.

3.1.3.2. Sources of Funds

S.M.A.R.T. goals are best—Specific Measurable, Attainable, Realistic, and Trackable.

3.2. Plan

3.2.1. Set Goals

3.2.1.1. Importance of Goals

3.2.1.2. Writing Goals

3.2.1.3. Templates for Tracking Goals

Record results periodically until your target date so that you know if you are on course.

3.2.1.4. Resources for Goal Settings

3.2.2. Map Chart Data

A chart conversion tool helps you move information from paper charts into EHRs.

3.2.2.1. Chart Conversion Planning

3.2.3. Workflow and Process Redesign

3.2.3.1. Importance of Workflow and Process Improvement

To overcome resistance to change, demonstrate computer systems’ quality, efficiencies, and patient safety.

3.2.3.2. Process Mapping as a Means to Manage Change

3.2.3.3. Workflow and Process Mapping

3.2.3.4. Mapping Current Workflow and Processes

3.2.3.5. Workflow and Process Redesign

A thoughtful and thorough vendor selection process ensures you get what you need.

3.3. Select

3.3.1. Vendor Selection

3.3.1.1. What Are You Buying?

3.3.1.2. The Marketplace

More costly products may provide more functionality, robust decision support, and customization.

3.3.1.3. CAST 7-Stage EHR Adoption Model for Long-Term and Post-Acute Care (LPTAC)

3.3.1.4. Price Ranges

Various resources help you calculate costs and return on investment.

3.3.1.5. Total Cost of Ownership and Return on Investment

3.3.1.6. Interoperability, Integration, Integration Engines, and Certification

Choose and work with EHRs that implement interoperability standards, and consider CAST’s additional recommendations below.

When one vendor does not meet your needs, find a complementary product, wait, or adapt a different product.

One goal for integration engines is a user-friendly interface for multiple Health IT systems that may also be compatible with mobile devices.

It’s important for an EHR system to document services delivery for Medicare certification.

3.3.1.7. Suggested EHR Selection Approach

Use the CAST EHR online Selection Tool to narrow your selection.

4. EHR Selection Matrix Components

5. Acknowledgements

5.1. EHR Workgroup

5.2. Participating EHR Vendors