3 EHR and HIE Vendor Selection and Understanding the Marketplace

Section3.3 Select

Section 3 Select—EHR and HIE Vendor Selection and Understanding the Marketplace - 1

EHR and HIE Vendor Selection and Understanding the Marketplace

This document provides a picture of the marketplace for electronic health record (EHR) and health information exchange (HIE), including the products that are available, how to navigate the marketplace, and buyer beware tips, as well as information on product certification.

What Are You Buying?

The first question you should ask in the process of acquiring an EHR and/or the services of an HIE Service Provider (HISP) 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 a document imaging system to a product that supports documentation in structured format, alerting functions, and HIE. In between, there are many “cool gadgets” that may or may not be useful. You may find that the range of HIE offerings are more limited than EHR offerings:

• Within your geographic area there may be a state-based HIE Service Provider. However, there also may be other, private HISPs to explore, including regional, specialty or vendor-based opportunities. The list of Minnesota State-Certified HIE Service Providers is at
• There are also national HIE offerings and services. The national eHealth Exchange is providing connectivity for providers, and there are vendors with a national presence (e.g. providing exchange for e-prescribing). Connections to services like these can be supported by an EHR. You will want to determine how you can gain access through the local or state HISP offerings.
• There may also be alternatives to using a formal HISP. It is important to consider the functionality desired and then determine who or what offers the support you need. For example, you do not need to use a formal HISP to use the Direct protocol for secure exchange of email (see 4.9 Using Direct for HIE).

EHR Certification

National EHR certification (not to be confused with Minnesota’s HIE Service Provider certification, which is described in the next section) is intended to assure a provider and provider organization that their EHR system has capabilities and functionalities comparable to other EHR systems. The list of Certified EHR products can be found at With certification, providers can have greater confidence that the electronic health IT products and systems they use are secure, can maintain information confidentially, can work with other systems to share information, and can perform a set of well-defined functions, focused primarily on functions needed to meet meaningful use objectives.

There is no specific certification of EHR products for Local Public Health (LPH) department EHRs at this time. However, you may be evaluating products certified under the federal incentive program for meaningful use (MU) of EHR program. The Office of the National Coordinator for Health Information Technology (ONC) supplies the standards EHRs must meet in order for users to earn the MU incentives under the Centers for Medicare & Medicaid Services (CMS). Two sets of criteria have been used to conduct this certification. The initial set of 2011 criteria reflects the requirements for Stage 1 of the incentive program. The second set of 2014 criteria reflects the requirements for Stage 2. The program, while designed to focus on primary care, does not distinguish between health care specialties and exclusions can be claimed for objectives and measures that may be out of scope for a provider’s specialty area. To learn more about how EHR technology may serve healthcare providers ineligible for Medicare or Medicaid incentive programs, see: To monitor the ONC certification program and to access a list of certified EHR products, visit

Most of thecertified products include more functionality than you typically need for LPH, and some functionality you mayneed or want will not be present. A useful reference to help describe the functionality desired in an EHR for LPH is the HL7 EHR-System Public Health Functional Profile (January 2013). Compilation of this Functional Profile was supported by the Centers for Disease Control and Prevention/National Center for Health Statistics and the Public Health Data Standards Consortium ( Another resource that may help identify functionality applicable for LPH is the Certification Committee for Health Information Technology (CCHIT). Although this organization has dropped out of the ONC certifying business, it continues to maintain its previously developed certification criteria anda list of products certified by specialty type as of 2011 on its website, at Products previously certified include those for ambulatory care, inpatient use, emergency departments, enterprise systems, behavioral health, long term and post-acute care, cardio medicine, child health, women’s health, and dermatology.

Most of these certified products include more functionality than you typically need for LPH, and some functionality you do need will not be present. While LPH is not one of the most common settings covered by MU, careful examination of the population served and the provider offerings delivered to that population may indeed qualify an eligible professional working in a LPH agency for MU. Any EP participating in the MU program needs to determine if any of the objectives or measures (where an exclusion does not exist) lie outside the scope of practice, thereby disallowing achievement of MU.

In Minnesota, if a provider does not have a certified EHR available for their setting, then the provider must have a “qualified EHR.” The “Minnesota 2015 Interoperable EHR Mandate” defines this as an electronic record of health-related information on an individual that includes patient demographic and clinical health information, and has the capacity to:

• provide clinical decision support;
• support physician order entry;
• capture and query information relevant to health care quality; and
• exchange electronic health information with, and integrate such information from, other sources.

Minnesota providers are also encouraged to have an EHR with the capacity to securely:

• incorporate clinical lab test results as structured data;
• support transitions of care, population health and quality improvement; and
• allow patients or their representatives access to view online, download and transmit their health information.

The EHR marketplace is very dynamic with vendors that come and go. Some take more time than others to become certified. For a list of all certified products, visit

HIE Service Provider Certification

Certification of HIE Service Providers is relatively new. Some state departments of health are certifying HISP capabilities in vendors. There are emerging HIE certification organizations (e.g. EHNAC) that are setting certification guidelines for HIE Service Providers nationally.

Minnesota has an “HIE Oversight Process”. Under this law, an entity providing health information exchange services for clinical meaningful use transactions must apply for a certificate of authority to conduct business in Minnesota as an HISP. In Minnesota, to meet the 2015 Interoperable EHR Mandate providers must use a State-Certified HIE Service Provider. More information about Minnesota’s “HIE Oversight Process” and the 2015 Interoperable EHR mandate can be found at the links provided at the bottom of this document.

The Marketplace

The marketplace for EHRs in LPH should include products designed for LPH client services documentation. However, depending on how you are searching, you may come across surveillance systems, immunization registries, and other health information technology that is more suitable for state public health departments.

The marketplace for HIE Service Providers, and other forms of HIE vendor support, is generally state-specific, although there are some regional HISPs and some HISPs that span multiple states across the country. More information about Minnesota’s “State-Certified HIE Service Providers” and their offerings and capabilities can be found at the link provided at the bottom of this document.

Price Ranges

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

• You may find some very inexpensive products that may be based on a variety of technologies and have minimal decision support, workflow, or customization capability. Similarly, there are inexpensive products that only scan paper documents and make them accessible. These are typically referred to as scanning systems. These offerings are not considered comprehensive “EHRs”.
• Another tier of products may have substantial functionality, but are lower cost because they are offered in an application service provider (ASP) or software as a service (SaaS) mode. These products provide an alternative to outright purchase through the use of recurring service charges, and reduce the costs of maintaining servers and internal IT staffing needs. These products may suit an organization very well unless extensive customization or implementation support is desired.
• A final, and generally more expensive, tier of products includes those that are highly customizable and may have more specialty functionality. The level of interoperability within these product suites, with other vendors’ products and with an HISP is variable. Vendors are making concerted efforts to become more interoperable. Service levels, implementation support (including attention to workflow and process support, testing, and training), and customer service responsiveness are generally stronger in this tier of products. There are few products for LPH in this tier.

• Costs for interoperability through health information exchange can vary greatly, depending upon the reach and scope of the interoperability desired. Increasingly, EHRs are embedding Direct services within their product, enabling the provider to exchange information directly with other specific providers or to connect to an HIE Service Provider. Some HISPs are offering economic offerings to enable Direct services. Providers must understand that some of these Direct options may require them to take on responsibility for maintaining aspects of their interoperability solution (e.g. perhaps establishing and maintaining a “directory” of other providers to exchange with). SomeHISPs offer richer and more comprehensive solutions that deliver more functionality (such as a patient “record locator service), but will likely charge more for data exchange/access and use of those advanced capabilities. Service fees for use of an HISP are in addition to the costs of acquiring, implementing and operating an EHR.

Product Interoperability

Interoperability means that two or more systems or components are able to exchange information and to use exchanged information accurately, securely and verifiably. 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 product components fully achieves.

Interoperability can be achieved in various ways. When components are integrated, they generally are built by the same group that did the original development and programming, have similar design characteristics and components that are able to exchange most data. In general, the components in highly integrated suites of products work well together, but will not work with any other vendor’s product without specialized interfacing. Interfaces are software programs that help two disparate systems or components interoperate. The interfaces rely upon the fact that the software in both systems and components has been written to conform to interoperability standards.

An important indicator of interoperability is the ability to send and receive a Summary of Care record for transitions of care. Sending the Summary of Care record is a requirement for Stage 2 of Meaningful Use for Eligible Hospitals, Critical Access Hospitals, and Eligible Professionals. In order to be Certified EHR Techology (CEHRT), the EHR must be able to produce the Summary of Care record and transmit it electronically using the Consolidated Clinical Document Architecture (C-CDA) standards.

A summary of care record must include the following elements if available:

• Patient name.
• Referring or transitioning provider's name and office contact information (EP only).
• Procedures.
• Encounter diagnosis
• Immunizations.
• Laboratory test results.
• Vital signs (height, weight, blood pressure, BMI).
• Smoking status.
• Functional status, including activities of daily living, cognitive and disability status
• Demographic information (preferred language, sex, race, ethnicity, date of birth).
• Care plan field, including goals and instructions.
• Care team including the primary care provider of record and any additional known care team members beyond the referring or transitioning provider and the receiving provider.
• Reason for referral
• Current problem list (EPs may also include historical problems at their discretion).
• Current medication list, and
• Current medication allergy list.

LPH departments may seek product components from a single vendor. This saves considerable money in managing interfaces and can be a very good strategy. However, you may find that attempting to interoperate with a hospital, physician practice, commercial laboratory, state public health department, or other provider with an EHR from a different vendor is more challenging. In these cases, the options are:

• 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 some organizations may not warrant full interfacing or integration. For example, if you want to be able to trend lab values, it is necessary to have lab results in structured data format that can be processed by a computer. However, if you merely need the ability to gain access to view or retrieve lab results (or other information), it may not be necessary to have an interface.
• Use a secure portal to gain access to view information. Viewing usually allows you to capture a screen shot or download a PDF version of the information. In some cases, a portal will enable you to retrieve structured data if your EHR conforms to standards for interoperability (see Section 1.3 Interoperability for EHR and HIE).
• Use the services offered by an HIE Service Provider whose solution supports secure lectronic sending and receiving of health information in ways that can be understood by both the sender and the receiver.

For additional information on interoperability, HIE, and exchanging clinical summaries and other health information using the Consolidated-Clinical Document Architecture (C-CDA), see the following tools in this Toolkit:

• Interoperabiity for EHR and HIE
• HIE Technology Readiness Inventory
• Using Direct for HIE
• Using CONNECT for HIE
• Exchange of Clinical Summaries and Other Health Information (CCR – CCD – C-CDA)

Clinical Integration

One other caveat should be mentioned regarding vendor selection. Vendors that have primarily sold PMS (practice management system) may have little clinical experience to design a robust EHR. But the market is changing and many such vendors are now developing EHRs that are so tightly integrated with the PMS systems that they are almost impossible to tell apart. In fact, some organizations are finding little incentive to stick with an old financial/administrative system when such an offering is available from their EHR vendor.

HIE in Minnesota

More information about HIE in Minnesota can be found at:

A Practical Guide to Understanding HIE, Assessing Your Readiness and Selecting HIE Options in Minnesota, at:

Minnesota's 2015 Interoperable Electronic Health Record Mandate can be found at

Copyright © 2014 Stratis Health.Updated 06-24-14

Section 3 Select—EHR and HIE Vendor Selection and Understanding the Marketplace - 1