3.3 Select

Center Post

3.3.1 Vendor Selection

3.3.1.1 What Are You Buying?

The first question your organization should ask in the process of acquiring HIT is—what are we buying? This may seem like a strange question, 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 HIT 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 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.4 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.

3.3.1.3 Price Ranges

  • Very 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, 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 don’t have the same flexibility or support. These are frequently offered in ASP 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).

 

3.3.1.4 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 will not work with any other vendor’s product without specialized interfacing. Products with modules and components for different clinical and administrative needs may
save considerable money in managing interfaces and is 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 Health Information Exchange (HIE) entities.

When a single vendor system does not meet the required needs, the options are to 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.

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 smart phones, tablets and other mobile devices.

Integration engines allow changing applications as needed and interfacing with telehealth monitors and other telemedicine devices.
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 allow the Integration engine to transform and filter data from source applications, route transactional data, filter user defined
demographic elements and generate standard HL7 transactions.

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 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 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 has a certification program dedicated for LTPAC EHRs;
the program has certification criteria for EHRs for nursing homes as well as home health agencies. CCHIT 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. Many CCHIT Certified products are also certified in the ONC-ATCB EHR certification program.

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 HHS criteria and standards. It is modular so the technology inspected may not meet all of the requirements. The Certification Facts™ label tells you which of the criteria are met. You are responsible for assuring that your certified EHR technology meets all of the requirements if you wish to demonstrate meaningful use and achieve incentives. No site verification or usability testing is done under this program. 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.