Vendor Selection and Understanding the Marketplace

Vendor Selection and Understanding the Marketplace



Section1.3Adopt – Select

Section 1.3 Adopt – Select – Vendor Selection and Understanding the Marketplace-1

Vendor Selection and Understanding the Marketplace

(See accompanying handouts and Webinar)

This tool provides a picture of the marketplace for health information technology (HIT), especially electronic health records (EHR)—what is available, how to navigate, and buyer beware tips(1.1 HIT Visioning and Strategic Planning). It also describes the typical process for approaching vendor selection. The Adopt-Select section of the toolkit supplies a number of specific tools to support vendor selection.

What Are You Buying?

The first question you 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, despite considerable progress being made on standards, certification, and incentives.Many hospitals still believe that if they have an electronic document management system that enables them to scan and index all paper documents and merge them with digital documents, such as lab results and transcribed reports, that they have an EHR.This is useful way to improve access to documents, but it is not an EHR.Likewise, some physician offices use spreadsheets to track their diabetic patients for follow up. While useful for this one purpose, spreadsheets are time consuming for staff to abstract from the paper charts, and they do not constitute an EHR.

Undertake a thoughtful and thorough vendor selection process to ensure you meet your needs, as well as a buy a product that enables you to grow into additional HIT as desired or it becomes available.Some EHR vendors may suggest replacing your financial/administrative system so these functions are more integrated with the EHR. While an integrated system is ideal and often the incremental price is not as much as if you were acquiring two separate systems, you obviously need to consider the cost/benefit (1.2 Total Cost of Ownership and Return On Investment). 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 have no choice in the vendor you will be implementing. In this case the tools in Adopt-Select may not be applicable to you unless you are a part of the corporate selection process or if you go to market to acquire a module that you have special need for and is not included in the standard system.

The definition of an EHR, according to the Health Level Seven (HL7) EHR System Functional Requirements standard and the Certification Commission for Health Information Technology (CCHIT) is a system that collects data from multiple sources used to support clinical decision making at the point of care.

EHRs have multiple components. Hospitals have patient accounting systems, laboratory information systems, pharmacy information systems, and many other systems that contribute data to the EHR. The more data sources, the more components in the EHR. Ambulatory care has fewer sources of data but may have more challenges in receiving data from more remote and disparate systems. While interoperability standards exist, vendors have tremendous option in how they are applied. Vendors can build highly proprietary systems that integrate with other systems, but do not easily interface, including with some of their own acquisitions. In addition, a source system that may work well for the department operations it is intended to address, may not necessarily include all the functionality necessary to integrate with new, clinically focused modules such as computerized provider order entry (CPOE), electronic medication administration records (EMAR), and point of care charting (POC). So when the question is asked—what are you buying?—the response may need to be modules or systems that prepare us to achieve an EHR in the future.

Clinical decision making support depends on capturing not only data from multiple sources, but capturing discrete data that can be processed by a computer. Scanned images, narrative notes keyed into comments fields, digital dictation, transcribed documents, print files, etc. all enhance access to information, but do not provide discrete, or structured data that can be processed in clinical decision support rules. Getting to the collection of discrete data and using clinical decision support are perhaps the biggest hurdles in achieving the full value of EHR. Such systems require considerable software sophistication—which also costs more money. Small and rural communitiesmay need faith in the vendor that existing components are strong enough to support initial value and they have vision of clinical computing and resources to support developing system upgrades that help achieve your longer term goals.

Point of care use requires sophisticated software, ideal input devices, and willingness to make changes in workflows and processes by clinicians—no small undertaking. The answer to your buying question may be support for the people, policy, and process changes that will help you make progress on your migration path.

The Marketplace

Much progress in improving the marketplace has been made since the following events have occurred:

  • Health Level Seven (HL7) EHR System Functional Requirements standard ( This standard was developed based on works of the Institute of Medicine and has been adopted as an American National Standards Institute (ANSI) standard. Representing the ideal, it serves as a blueprint to drive ever more sophistication in EHR technology. HL7 is the predominant standards organization for health care information systems connectivity. Its primary focus is standardization for interface development. A product that is “HL7 compliant” has been designed with the data formats necessary to support writing of an interface; it does not relate to the EHR System Functional Requirements.
  • Certification Commission for Health Information Technology (CCHIT) ( This organization was officially recognized by the federal government in 2006 as a certifying body for EHR products. It started certifying ambulatory care EHR systems in 2006 and hospital EHR components in 2007. CCHIT has a roadmap to certify other types of EHR systems in subsequent years. It bases its criteria largely on HL7 EHR System Functional Requirements, andreferences other standards and documents as applicable.“Buyer beware” applies in evaluating CCHIT certified products.
  • The annual cycle of certification is May 1 to April 30, which means that a product certified in February 2008 meets the same criteria as a product certified in July 2007. Certification is good for three years; however, the year in which the product is certified is the year that represents which criteria were applied. Note the year of certification. A vendor selling a 2006-certified product in February 2009 is legitimately certified but only on the 2006 criteria.For example, ambulatory care products certified in 2006 were not required to have e-prescribing functionality; products certified in 2007 were to include it.
  • Hospital product certification began in 2007 and is focused only on foundational requirements and CPOE and EMAR. A vendor that is able to demonstrate such functionality is likely to have a suite of products that are highly integrated because of the level of support from source systems needed for CPOE and EMAR to be successful.
  • Certification criteria are published and available on the CCHIT Web site. Buyers should review these criteria thoroughly. Products certified by CCHIT are defined by the federal government as being interoperable, even though the criteria for 2006 and 2007 included minimal interoperability. While a certified product meets the functionality criteria, it may not meet the criteria in the manner you would wish for your organization. You must do your own due diligence to determine that the product will be suitable for your environment.
  • Incentive programs.Many incentive programs, especially for providers, may be doing more than either HL7 or CCHIT to promote adoption of EHR systems used at the point of care with clinical decision support. Many local malpractice insurance carriers, state-wide health plans, and federal programs have developed criteria for incentives that truly get at adoption of systems and quality improvement. Two examples areprovided below; there are many others.
  • The MMIC Group (the Minnesota malpractice insurance carrier, is providing an Electronic Medical Record Premium Credit to physicians and physician groups that have a CCHIT-certified product, have implemented the latest upgrades of the product, have at least 75 percent of the providers in the group using it for at least one full year, and have been using two of six key functions: medication allergy checking and current medication list, order status tracking and alerts, health maintenance alerts, manage consents and authorizations, external document scanning, and provider approvals. Depending on the number of functionalities in use, the physician or group may get two to five percent credit. Only an annual attestation is required to obtain the credit and the focus is on functionality rather than outcomes, the carrier is emphasizing the importance of use of the system in important ways.
  • Center for Medicare & Medicaid Services (CMS) Physician Quality Reporting Initiative (PQRI) was introduced in 2007 and expanded in 2008( requires reporting 119 measures of CPT Category II codes and/or G-codes. The measures include those that would most likely be performed in an ambulatory visit (e.g., influenza vaccination in patients with end stage renal disease) as well as those likely performed by providers in acute care settings (e.g., aspirin at arrival for acute myocardial infarction, screening for future fall risk). While such codes can be applied in a manual process, the need for reminders to alert the provider to take action is fundamental to having an EHR. Capturing the data to be coded is greatly facilitated by an automated system. Buyers looking for an EHR should consider whether the system has many of the reminders and alerts necessary to participate in PQRI.

Price Ranges

When the price per user of products ranges from hundreds to many thousands of dollars, you can be sure of equally big differences in the products. Not to suggest that lower priced products do not have their place, but youshould understand what youare buying.

  • 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 to the document to highlight allergy information or certain other standard information. This information can only be viewed, not processed by the computer.
  • Another tier of products may be EHR-lite versions of more robust products. They look and feel like their more expensive cousins, but don’t have the flexibility or support. These are frequently offered in an application service provider (ASP), which provides a source of financing support as well as reduces the cost to the organization for maintaining its own servers.
  • More expensive products provide greater levels of connectivity options, include more robust decision support, and are highly customizable. The vendorspends considerable money on research and development to continuously provide new functionality. The level of interoperability within these product suites and with other vendor products is variable. Vendors are making concerted efforts to become more interoperable, especially as the CCHIT 2009 certification will focus more on interoperability. Service levels, attention to workflow and process support, testing and training, and customer responsiveness are generally stronger in this tier of products.

Acute vs. Ambulatory

The acute care environment is very different from the ambulatory environment in workflow, processes, number and types of professional staff, and procedures performed. Vendors who have serviced one market often have difficulty making the transition to the other market. As vendors are becoming more aware of the need to service both acute and ambulatory markets in an integrated delivery network, they are addressing this need in a variety of ways.

  • A number of vendors are acquiring products from other vendors and building an interface to their core product. While the interface is generally solid, it is still only an interface. Over time, the vendor may chose to integrate the product more fully within its suite. When considering any productfrom a multi-use vendor evaluate its product history thoroughly. For example, a vendor that offers two different ambulatory EHRs as well as a number of hospital source systems has likely acquired two different ambulatory EHR companies. Look at the history of the product and its upgrades.
  • Some vendors are building products for markets they initially did not serve. These products need to be thoroughly evaluated. In which market did the vendor begin? If you are looking at the newer product line, some functionality may still be off the mark because of vendors’ lack of experience or because of the need to build the product differently to integrate with the another product that does not carry full functionality.
  • Vendors have not done well in integrating long term care, home health, dental, or other specialty product needs as yet, but some vendors indicate that this is a goal.Vendors are getting better at addressing the continuum of care, so the future holds more promise. This does not suggest that you should wait because you could be waiting a very long time for your particular area of interest to be addressed.

When considering what to buy, look not only at existing functionality and price, but the history of the company and its vision for the future.

Interoperability

Interoperability means that two systems are able to communicate with one another. If you have an existing billing system from Vendor A but buy an EHR from Vendor B (perhaps because vendor A does not offer an EHR), unless the two systems both have been created following the HL7 standard protocol, it is generally impossible for the two systems to exchange data, such as for the billing system sending demographic data to the EHR or the EHR sending charge data to the billing system.Systems that cannot communicate in any way with each other are considered standalone systems.

Ideally, interoperability suggests that every product works together seamlessly. Unfortunately, this is an expectation that often is not achieved. You can achieve interoperability in three ways: through integration, interfacing, and Web services architecture.

Integration. The integration form of interoperability means that components are developed by a single vendor, using the same programming and design characteristics. 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 interfacing. They also may not work with another organization’s implementation of the same products without interfacing because each implementation may have been customized in different ways. Those undertaking HIT vendor selection should also be aware that just because several modules or components are offered by a given vendor does not mean that the components are integrated. The vendor may have been acquired another company and has incorporated that company’s products into their own suite via interfacing.

Interfacing. An interface is a special program that reconciles differences in the data formats of two different systems. An interface works well when the vendors of the two systems have followed a standard protocol, such as HL7, or National Council for Prescription Drug Programs (NCPDP) for prescription information systems, X12 for claims and other financial transaction systems, or Digital Imaging and Communications in Medicine (DICOM) for picture archiving and communication systems that enable the exchange of digital diagnostic images.

In general, a limited set of data are able to be exchanged through an interface, sometimes only from one system to another and not back. Another issue with interfaces is that they require maintenance. Anytime one system gets upgraded, the interface needs to be checked to see that it will still work with the new upgrade.

Top View