1. Installation and Maintenance of Health IT Systems
System Selection –
Software and Certification
Welcome to Installation and Maintenance of Health IT Systems, This is System Selection – Software and Certification
This component covers fundamentals of selection, installation, and maintenance of typical Electronic Health Records (EHR) systems.
This unit, System Selection - Software and Certification, will discuss the differences in COTS (Commercial Off-The-Shelf) and in-house/homegrown systems and how to select the system to meet the needs of the end users.
This material (Comp 8 Unit 2) was developed by Duke University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number IU24OC This material was updated in 2016 by The University of Texas Health Science Center at Houston under Award Number 90WT0006.
This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. To view a copy of this license, visit

2. System Selection – Software and Certification Learning Objectives
Compare and contrast COTS (Commercial Off-The-Shelf) and In-House /homegrown systems and describe their relative advantages and disadvantages
Verify system compliance with ONC-ACB certification
Identify purpose and categories of ARRA “Meaningful Use” criteria
There are many important steps to choosing the correct system for your institution and ensuring that it will quickly be adopted by your users. Discussions will begin with COTS (Commercial- Off-the-Shelf) and MOTS (Modifiable Off-the-Shelf) versus in-house software products, their advantages and disadvantages, along with costs associated with them.
We’ll discuss EHR certification and meaningful use criteria with regard to EHR systems. Finally, we will touch on some typical costs associated with selection and implementations of EHR systems.

3. Off-the-Shelf Software
Commercial Off-the-Shelf (COTS)
Modifiable Off-the-Shelf (MOTS)
200+ companies claim to make an EHR (Electronic Health Record)
May include “freeware” with commercial support
COTS, or Commercial Off-the-Shelf, is a term used to describe a product that is implemented "as-is" while MOTS, or Modifiable Off-the-Shelf, refers to a commercially available software product which can be, to some extent, modified by the purchaser, vendor, or contractor to better suit the purchaser’s specific needs. For the purposes of this discussion we will refer to both variants as COTS products.
COTS systems are designed by a software vendor to address the needs of many different purchasers. The services provided are those most popular and often most generic, that are desired by the majority of the customer base.
Most software can be considered COTS; operating systems, office productivity software, and Internet communication programs are examples. Because it can be sold to a larger market, COTS software may be available at relatively low cost.
At present, well over 200 software companies offer some sort of off-the-shelf EHR solution. Some of these solutions include “freeware” solutions, which are open-source products freely available for use, with commercial support.

4. Advantages of COTS Lower development costs
Wider “test market” to find bugs and limitations
Vendor training and product support, bug fixes
Easier learning curve
Eliminate development time
There are several advantages to buying complete off-the-shelf products.
For starters, vendor companies have already put up the up-front costs associated with developing and testing the product. This is especially advantageous for smaller healthcare settings that cannot afford an extensive IT development team. As part of the roll-out process, vendors often will work with the clinical IT teams to ensure the product is successfully integrated within the healthcare setting and plays well with preexisting software components. When things do go wrong, the vendor provides additional troubleshooting and support and usually works with the IT staff to resolve software glitches and bugs. The COTS products also generally have previously developed training documentation. This can mean that difficulties in learning the new system have been addressed in previous installations at other institutions.
Because the vendor generally has already created training programs and materials to help ensure a successful adoption of the product into the workplace, users and administrators can often be brought up to speed faster than with an in-house product.

5. Disadvantages of COTS Unalterable source code Compatibility issues
Uncertain upgrade schedules
Business practices may have to be modified, and workflow often has to be adapted to the particular product design.
(Rice, 2009)
Because many EHR systems are proprietary, access to the source code is often limited or nonexistent. This reduces the flexibility of the program and makes the institution dependent on the vendor to make enhancements to the system, system, which is often costly.
Compatibility is also a concern as EHR vendors must contend with an ever-increasing variety of hardware and software combinations. Add in the staggering number of drivers, peripherals, testing devices, and so on, and it becomes obvious that there is no way the vendor can test compatibility for all possible combinations. The issue is compounded with every new upgrade, which holds the potential to “break” something that was working perfectly in the earlier version. If a COTS product is in your institution’s future, you will need a plan that adequately addresses which users will receive upgrades and when, as well as contingency plans for use in the event that the upgrade is not successful. Be sure that an adequate test environment exists in your institution and that upgrades are thoroughly tested before deployment.
Each vendor is different with regard to frequency of upgrades. Reputable vendors theoretically are motivated to maintain a high level of product quality; however, this is not a guarantee. Keep open lines of communication with your vendor and stay abreast of product issues and pending upgrades. Never assume the vendor will meet upgrade release dates and never assume a certain level of quality until you have tested the product in your own institution's environments.
Another disadvantage to purchasing a COTS product is the inability to find a product that fits your institution “just perfectly,” often requiring workflow changes on an institutional level for successful adoption of the product.

6. In-House / Homegrown Locally-installed and managed EHR implementation
Only available to institutions with existing IT infrastructure and investment
Developed by
extending existing In-House systems, or
adapting open-source or other publically available software for institution needs
Some institutions decide to build their own in-house EHR solution. In-house software is developed by the operating institution and installed and managed by an existing IT team.
This kind of development is only undertaken by larger organizations with their own IT departments.
Development of the EHR system will often start through extension of existing In-House systems. Alternatively, the institution may elect to use an open-source or otherwise modifiable system and (depending on the software license) adapt it solely for its own use, or participate in further public development by contributing changes back to the source.

7. Advantages of In-House
Developed wholly by the operating institution
Design is specifically tailored to meet institutional objectives
Can mesh comfortably with existing workflow processes
More often than not, the decision to build an EHR in-house is driven by the desire to make a product that can fully integrate with existing software and/or closely match institutional processes and objectives.
The existing IT infrastructure and personnel will guide development of the system to ensure maximum compatibility with existing processes.

8. Disadvantages of In-House
Higher development costs, initial and throughout product lifecycle
Dependent on expertise of in-house development staff
Lack of vendor support – bug fixes, upgrades
Training must be developed in-house.
Longer development time
There are several obstacles to creating your own in-house EHR solution.
First of all, you need to have the right team in place. If you decide to build an in-house solution,  you will be spending a lot of time, money, and energy in recruiting and retaining quality IT developers capable of implementing such a large-scale project. Not many people take into consideration the costs involved in recruiting and hiring the right software development team along with the associated hardware and software needed to develop, compile and test coding components. You should expect to expend years of effort and dedicated resources toward the development and implementation process of an in-house EHR solution.
Secondly, you should have a person capable of monitoring and assessing the quality of the work, the output, and the productivity of the team hired. This consultant or project manager represents another added expense.
Likewise, your IT team will need to stand on its own when testing, troubleshooting, debugging, or adding enhancements to the EHR system throughout the product's entire lifecycle. This takes lots of time and resources. Products developed by vendors have the advantage of multiple clients providing feedback and bug reporting.
Lastly, before the product can be successfully rolled out to your users, planning programs and materials must be created, generally from scratch.
Given these obstacles, it's not surprising that many healthcare institutions – especially those that are not large institutions with adequate resources – choose to go with a COTS or MOTS software solution.

9. EHR Certification
Office of the National Coordinator for Health Information Technology (ONC) provides for a certification program for EHR Technology
Temporary Certification Program in effect June 2010
Permanent Certification Program in January 2011, replacing temporary program in 2012
American National Standards Institute (ANSI) is the ONC-Approved Accreditor (AA) for the Permanent Certification Program – ANSI will certify the ATCBs
Only 6 ATCBs as of Dec (
ATCBs are the Authorized Testing and Certification Bodies that grant certification to the products and vendors of Complete EHRs and EHR Modules.
Current list is available at
Certification is a prerequisite for participation in the Medicare and Medicaid incentive programs, which provide payment to doctors, clinics, and hospitals that “demonstrate meaningful use of certified EHR technology”
(ONC, 2011; CMS 2011)
The Office of the National Coordinator for Health Information Technology (ONC), as empowered by the US Department of Health and Human Services, provides for a certification program for Health Information Technology providers and systems.
According to ONC, “Certification of Health IT will provide assurance to purchasers and other users that an EHR system, or other relevant technology, offers the necessary technological capability, functionality, and security to help them meet the meaningful use criteria established for a given phase. Providers and patients must also be confident that the electronic health IT products and systems they use are secure, can maintain data confidentially, and can work with other systems to share information”
Given that use of a certified system means eligibility for payments from Medicare and Medicaid incentive programs – up to $44,000 for individual practitioners, and over $2 million for participating hospitals – there is strong incentive for any EHR system or module to become certified by an ATCB.

10. Standards and Certifications Criteria Final Rule
Final Rule on an initial set of standards, implementation specifications, and certification criteria adopted July 13, 2010
Interoperability, to work with systems sharing information
Functionality, to perform a set of well-defined functions
Security, to store and transmit confidentially and reliably
Utility, to support meaningful use of HIT data
(SCCFR)
A Final Rule on an initial set of standards, implementation specifications, and certification criteria for adoption by the HHS Secretary was issued on July 13, This Final Rule represents the first step in an incremental approach to adopting standards, implementation specifications, and certification criteria to enhance the interoperability, functionality, utility, and security of health IT and to support its meaningful use. The certification criteria adopted in this initial set establish the required capabilities and related standards and implementation specifications that certified electronic health record (EHR) technology will need to include in order to, at a minimum, support the achievement of meaningful use Stage 1 (beginning in 2011) by eligible professionals and eligible hospitals under the Medicare and Medicaid EHR incentive programs.

11. Why Certification? Reduce risks to physicians in EHR investment
Facilitate interoperability of EHR systems
Enhance availability of EHR adoption through stimulus incentives
Ensure that EHR systems and networks are secure and protect privacy
(Pizzi, 2007)
Certification of EHR systems accomplishes four major goals:
It reduces the risks to investment in EHR systems, which represent a sizable business investment, by providing additional assurance that the system is worthwhile.
It may facilitate interoperability between EHR systems, as multiple systems would adhere to the same set of standards.
As mentioned previously, certification is a prerequisite for Medicare and Medicaid incentive payments, among other stimulus incentives.
Finally, certification requires that EHR systems and networks protect the privacy of personal health information.

12. Why Certification? (cont’d)
Allow evaluation time to be used more efficiently
Narrow the initial field of vendors
Assure basic functionality and interoperability, allowing you to focus evaluation more on special or unusual needs of your institution
Choosing to narrow your search to certified EHR products also allows you, as the evaluator, to be assured that each of the certified software products will meet similar standards for basic functionality, interoperability, and security. This will allow you to focus your evaluation more on any special or unusual needs of your institution. It’s important to note that interoperability is at an early stage and requirements for interoperability are still being established.
Note: Certification examines only the system itself, and does not evaluate the company’s service aspects or financial solvency. You should perform this type of due diligence yourself. It is important to know that your vendor has a good reputation and plans to provide continuous support for your software throughout the product’s lifecycle.

13. What are ARRA and “Meaningful Use”?
ARRA (American Recovery and Reinvestment Act, a.k.a. “stimulus bill”)
Passed by Congress February 2009
Over $22 billion allocated to modernize health IT system.
HITECH (Health Information Technology for Economic and Clinical Health) Act: initially rewards institutions for “meaningful use” of EHRs, then in imposes penalties.
(U.S. Department of Transportation, 2009)
ARRA (American Recovery and Reinvestment Act of 2009), commonly referred to as the “stimulus bill”, is the economic package passed by the U.S. Congress in February Of the $787 billon in expenditures, $22 billion were allocated to facilitate modernization of health information technology systems.
The HITECH Act, part of the stimulus package, aims to induce more physicians to adopt EHRs with potential payments of more than $40,000 a year via Medicare or more than $60,000 a year via Medicaid during the initial years of the program.
Starting in 2015, failure to meaningfully use health IT will lead to financial penalties, starting with 1% reduction in Medicare reimbursement and growing over time.
(CMS.gov, 2011)

14. Meaningful Use Criteria: Stage 3
According to Centers for Medicare & Medicaid Services (CMS), the objectives for hospitals & providers are to:
Protect patient health information
Clinical decision support
Computerized provider order entry (CPOE)
Electronic Prescribing
(CMS, 2015)
The Centers for Medicare and Medicaid services in 2015 announced their stage three meaningful use criteria for EHR use. The objectives for hospitals and providers are to:
Protect patient health information, provide clinical decision support, utilize Computerized Provider Order Entry (CPOE), and Electronic Prescribing.

15. Meaningful Use Criteria: Stage 3 (cont’d)
Health information exchange
Patient-specific education
Medication reconciliation
Patient electronic access
Secure Messaging
Public Health
(CMS, 2015)
They expect the providers to use health information exchange, provide patient-specific education, perform medication reconciliation for their patients, allow their patients electronic access through patient portals or other means, utilize secure messaging and utilize the EHR to improve the public health.
We will look at each of these a little bit more in depth.

16. Meaningful Use Criteria: Stage 3 (cont’d)
1. Protect patient health information
Conduct or review a security risk analysis…addressing the security to include encryption
2. Clinical decision support
M1 – Implement 5 clinical decision support interventions for 4 or more CQMs or high-priority conditions
M2 – enabled and implemented drug-drug and drug- allergy interaction checks for entire reporting period
(CMS, 2015)
For protecting patient health, all providers as a part of the HIPAA security rule are expected to conduct or review a security risk analysis addressing the security, including encryption of protected health information (that would be individually identifiable data).
They are also expected to utilize clinical decision support; they can either implement five clinical decision support interventions for four more quality measures and they have to enable and implement drug-drug and drug-allergy intervention checks for the entire reporting period.

17. Meaningful Use Criteria: Stage 3 (cont’d)
3. Computerized Provider Order Entry (CPOE)
M1 - >60% of medical orders use CPOE
M2 - >30% of lab orders use CPOE
M3 - >30% of radiology orders use CPOE
4. Electronic Prescribing - >50% of permissible prescriptions are queried for drug formulary and transmitted using CEHRT
(CMS, 2015)
For Computerized Provider Order Entry there are three measures and that is that 60% of their medical orders have to be utilizing CPOE, 30% of lab orders and 30% of radiology orders. So the expectation is that providers will be using CPOE to place their orders.
For electronic prescribing, more than 50% of permissible prescriptions need to be queried for drug formulary and transmitted using Certified Electronic Health Record Technology (CEHRT).

18. Meaningful Use Criteria: Stage 3 (cont’d)
5. Health Information Exchange – transitions or referrals to another setting or provider:
(1) uses CEHRT to create a summary of care; and
(2) electronically transmits the summary for more than 10% of the transitions
6. Patient-specific Education – resources identified by CEHRT are provided to 10% of unique patients with office visits
(CMS, 2015)
For Health Information Exchange, it is required that the provider uses the Certified Electronic Health Record Technology (CEHRT) to create a summary of care and electronically transmit the summary for more than 10% of the transitions. These transitions could be to specialists, or it could be from a specialist to a primary care provider, or it could be from a hospital to a nursing home, or just different providers or settings of care.
So whenever you would have a transition or referral, the expectation would be that you would electronically transmit that more than 10% of the time.
With patient-specific education, the knowledge base within the Certified Electronic Health Record Technology (CEHRT) should provide information and that needs to be provided to 10% of unique patients who have office visits.

19. Meaningful Use Criteria: Stage 3 (cont’d)
Medication Reconciliation – medication reconciliation is performed for more than 50% of transitions of care in which the patient is transitioned into care
Patient Electronic Access
M1 - > 50% of all unique patients are provided timely access to view, download, and transmit
M2 – At least 1 patient views, downloads or transmits to a third party
(CMS, 2015)
Medication reconciliation needs to be performed for more than 50% of transitions in care.
And patient electronic access- greater than 50% of all unique patients must be provided timely access to view, download and transmit. And at least one patient needs to view, download or transmit to a third party.

20. Meaningful Use Criteria: Stage 3 (cont’d)
9. Secure Messaging
2015 – capacity for patients to send/receive was fully enabled
2016 – secure message sent to the patient using EM function or in response to a secure message for at least 1 patient
2017 – 2016 secure messaging functionality for more than 5% of unique patients
(CMS, 2011)
Secure messaging had three different levels. In 2015 there needed to be the capacity for patients to send and receive.
In 2016, secure messages needed to be sent to the patient using electronic messaging function or in response to a secure message for at least one patient.
In 2017, the secure messaging functionality for 2016 needs to be used for more than 5% of unique patients.

21. Meaningful Use Criteria: Stage 3 (cont’d)
10. Public Health
M1 – Immunization Registry Reporting – EP is in active engagement with a public health agency to submit immunization data
M2 – Syndromic Surveillance Reporting – EP in active engagement with a public health agency to submit syndromic surveillance data
M3 – Specialized Registry Reporting – active engagement to submit data to specialized registry
(CMS, 2015)
For the first measure of public health, eligible providers are expected to be in active engagement with a public health agency to submit immunization data. And the active engagement relates to the ability to the public health agency to accept it or not. Not all public health agencies have that capability yet.
Measure 2 is the same for syndromic surveillance reporting.
For Measure 3, the specialized registry reporting, the provider needs to be submitting data to a specialized registry and that specialized registry would depend on the type of provider- primary care versus specialty.

22. Meaningful Use Criteria: Next Stages
Merit-based Incentive Payment System (MIPS)
Finally, we look at the Meaningful Use and the next stages and the Meaningful Use will evolve beginning in Providers will be reimbursed under the Merit-based Incentive Payment System (MIPS) and this will roll together the PQRS and the Meaningful Use and it will include other activities. So there would be the Quality Measures, there are measures related to resource use. Practices would have to undertake improvement activities as well as meaningfully use Certified Electronic Health Record Technology (CEHRT) for a MIPS composite performance score that ranges from This would determine whether or not their payments are adjusted positively or negatively.

23. Typical EHR Costs to Consider
Start up costs
Initial hardware and network upgrades
Initial software and licensing
Initial interfaces
Maintenance costs
Annual software licensing, upgrades, support
Annual interface upgrades and support
Startup costs include:
New hardware and network components, including servers, switches, cabling, racks
Software components, including purchasing and licensing the EHR product, along with any customization and support contracts and
Interfaces, including laptops, workstations, PDAs, etc.
Bear in mind that licensing options vary and different licensing options may be available for each product. As an example, a single user license or tiered pricing (where the fees are different depending on the level of access the user has to the system) may be quite viable for a small practice. On the other hand, site licensing (a single fee covering all potential employees for an entity) may be a more viable option for larger entities but far too costly for the smaller practice settings.
Maintenance costs include all costs associated with the continued upkeep, maintenance, and upgrades to the system. This would include routine hardware replacements, software support fees, licensing renewals, and major upgrades.

24. Typical EHR Costs to Consider (cont'd)
Training costs
Administrators
Users
Productivity costs
Lost during transition
Consultant fees
Training costs include fees incurred by the vendor to train new system users and administrators during startup, as well as training materials, simulators, etc., throughout the lifecycle of the product.
What are the anticipated productivity costs associated with the implementation of this product? Are the users going to have to make significant changes in workflow resulting in substantial loss in productivity?
Lastly, what consultants will you need to bring in to implement the installation? Wireless and network upgrades may require consultation to ensure optimal results. Will you be bringing in an implementation specialist at $125 an hour?
Be sure to consider these costs when selecting an EHR system.

25. System Selection – Software and Certification Summary
COTS advantages and disadvantages weighed against in-house advantages and disadvantages
Costs involved in startup and maintenance of the system should be addressed
Certified systems and modules are preferred
Meaningful use priorities should be addressed
This concludes Unit 2, System Selection – Software and Certification.
In summary, when choosing a system, be aware of broad categories of systems available for selection. Weigh the advantages and disadvantages of them, paying special attention to the required resources for development and maintenance. Certification of systems should be strongly considered. Finally, any system that is considered and implemented should address the meaningful use priorities.

26. System Selection – Software and Certification References
About ARRA. Retrieved from HITECH Answers website:
ARRA Meaningful Use Snapshot. (n.d.). Retrieved from Medical Information Technology, Inc. website:
Certified Health IT Product List. Retrieved from Office of the National Coordinator for Health Information Technology, US Department of Health & Human Services website:
Electronic Medical Record [cited 2010 June 20]. Retrieved from:
EHR Incentive Programs Overview. (n.d.). Retrieved from Centers for Medicare & Medicaid Services website:
Medicare and Medicaid Programs; Electronic Health Record Incentive Program (2010, July). Federal Register. [Internet]. Retrieved from .
Fornes, D. (2008, February 6). Should CCHIT Influence Your EHR Selection? [Web log post]. Retrieved from Software Advice - The Medical Blog:
No audio

27. System Selection – Software and Certification References
Gates, M. (2009, Winter). All Systems Go? How to Select an EHR That Meets Your Needs. Correct Care, (pp 12-15). Retrieved from
Goals for EHR System. Retrieved June 20, 2010, from Health Technology Review website:
HITECH Act Enforcement Interim Final Rule. (n.d.). Retrieved from U.S. Department of Health & Human Services website:
McKinney, D. (2001, August). Impact of Commercial Off-The-Shelf (COTS) Software and Technology on Systems Engineering. Retrieved from Presentation to INCOSE Chapters website: Charts.pdf
Medicare and Medicaid Programs; Electronic Health Record Incentive Program; Final Rule, 75 Fed. Reg (2010) 42 CFR Parts 412, 413, 422, and 495
ONC-Authorized Testing and Certification Bodies. Retrieved from Office of the National Coordinator for Health Information Technology, US Department of Health & Human Services website:
No audio

28. System Selection – Software and Certification References
Pizzi, R. (2007, October 30). EHR adoption an "ugly process," but CCHIT can improve appeal. Retrieved from Healthcare IT News website: :
Rice, R. (2009). Testing COTS-Based Applications. Retrieved June 21, 2010, from
Standards & Certification. Retrieved from Office of the National Coordinator for Health Information Technology, US Department of Health & Human Services website:
Standards & Certification Criteria Final Rule. Retrieved from Office of the National Coordinator for Health Information Technology, US Department of Health & Human Services website:
No audio
Images
Slide 13: ARRA Recovery.gov logo. (2009). Retrieved from:
Slide 13: Center for Medicare and Medicaid Services EHR Incentive Programs logo. (2011). Retrieved from:

29. Installation and Maintenance of Health IT Systems Elements of a Typical Electronic Health Record System
This material was developed by Duke University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number IU24OC This material was updated in 2016 by The University of Texas Health Science Center at Houston under Award Number 90WT0006.
No audio
Health IT Workforce Curriculum Version 4.0