Array ( ) Array ( )


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 Software Applications Hardware
3.1.2 Assess Organizational Readiness: IT Infrastructure, IT Staffing, Skills & Attitudes Organizational Health IT Readiness Assessment Health IT Attitudes Assessment Computer Skills Survey IT Staffing Inventory IT System Inventory Health Information Exchange Readiness Inventory
3.1.3 Assess Financials Financing Resources Sources of Funds
3.2 Plan
3.2.1 Set Goals Importance of Goals Writing Goals Templates for Tracking Goals Resources for Goal Settings
3.2.2 Map Chart Data Chart Conversion Planning
3.2.3 Workflow and Process Redesign Importance of Workflow and Process Improvement Process Mapping as a Means to Manage Change Workflow and Process Mapping Mapping Current Workflow and Processes Workflow and Process Redesign
3.2.4 Different EHR Models
3.3 Select 
3.3.1 Vendor Selection What Are You Buying? The Marketplace CAST 7-Stage EHR Adoption Model for Long-Term and Post-Acute Care (LPTAC) Price Ranges Total Cost of Ownership and Return on Investment Interoperability, Integration, Integration Engines, and Certification 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:

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

You can also access companion EHR Selection Matrixonline Selection Tool, and case studies

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

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 Matrixonline 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:

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:

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.  Software Applications

Within health IT there are many types of information system applications. These include the following:  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.  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.  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.  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.  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  IT System Inventory

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

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.  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  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.  Sources of Funds

The following are possible 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 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. 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.  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.  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.   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:

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

3.2.3. Workflow and Process Redesign 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.

To overcome resistance to change, demonstrate computer systems’ quality, efficiencies, and patient safety.  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.  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. Mapping Current Workflow and Processes

The following steps should be used to map current workflow and processes:  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:

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:

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

3.3. Select

3.3.1. Vendor Selection 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 Interoperability and Integration for more information.  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.  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:

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:

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:

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:

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:

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:

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:

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.  Price Ranges

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

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. 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. 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:

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:

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:

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. 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:

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 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:

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:

CAST Business Associate participating in the portfolio included:

Other participating vendors included: