Is my 2014 Ed product required to be updated to the 2015 Ed program?

Your 2014 certified EHR technology can be used for meaningful use attestation through 2017. Effective Jan 1, 2018 all EPs attesting for meaningful use, regardless of stage, will be required to use Health IT software certified to the 2015 edition.

Will I be able to certify to both the 2014 Ed and 2015 Ed program?

Any type of dual certification is not technically feasible and strongly discouraged from a development and testing perspective. While some 2014 edition modules will be eligible for gap inheritance, the 2015 edition criteria is substantially different and more complex.

How long does it take to test to the 2015 Ed program?

For vendors previously certified to the 2014 Edition, we estimate approximately three days to complete 2015 Edition testing based on testing for Meaningful Use (MU)-related modules only. For EHR clients with technology is not previously certified and wishing to test all MU-related, test time may be approximately four days.

How much will 2015 Edition testing cost and when can I begin?

Pricing, and other logistics related to 2015 Edition testing, including test procedures, will be finalized in 1Q2016. At that time, Drummond Group will announce the start of the 2015 Edition test and certification process via our e-newsletter. To join our newsletter list, please register here.

Did CMS make changes to Meaningful Use for this year?

Yes. The Center for Medicaid and Medicare Services (CMS) issued a Final Rule addressing changes in Meaningful Use for 2015-2017 and establishing Stage 3 starting in 2018. There is substantial information in this rule, but the key changes are:

  • All providers and hospitals are moving to what is called Modified Stage 2 starting in 2015.
  • Reporting period for 2015 is 90 consecutive days, and the attestation period will be opening up in January 2016. Reporting periods for 2016 and 2017 are still one calendar year for returning providers.
  • Providers and hospitals will report on the same reporting period of calendar year; fiscal year will no longer apply.
  • In 2017, providers &hospitals may elect to start Stage 3, but it is not mandatory. However, if doing Stage 3 in 2017, providers &hospitals can use a 90 consecutive day reporting period instead of a full year.
  • In 2018, all providers & hospitals must start on Stage 3.
  • Both Stage 3 and Modified Stage 2 dramatically streamlined the Meaningful Use measures, including dropping those which have topped out and no longer need to be reported.

What stage of Meaningful Use will providers & hospitals submit attestations on in CY 2015?

In 2015, ALL providers and hospitals move to what is now called Modified Stage 2, regardless of whether they were scheduled to do Stage 1 under previous CMS rules. Modified Stage 2 uses a set of 10 objectives for providers and 9 objectives for hospitals, and replaces the core and menu objective approach.

What measures are required in Modified Stage 2 and how can I learn more about it?

The CMS landing page, which outlines the 2015 program year requirements, is an excellent start. Once on that page, refer to PDF tip sheets and a recorded webinar, at the bottom, for valuable information.

What is the relationship between Stage 3 and Modified Stage 2?

Modified Stage 2 and Stage 3 are closely aligned. While some measures are different and some objectives have been combined, the idea is to make Modified Stage 2 closely resemble Stage 3.

What does Stage 3 require?

For a better explanation of Stage 3, refer to the CMS webinar PDF slides.

Does my 2014 Edition certified product need to be updated to meet Modified Stage 2?

No. 2014 Edition certifications, which “worked” in calendar year 2014 for Meaningful Use, will also work in calendar year 2015.

Does my 2014 Edition certified product need to be updated to meet Stage 3?

Yes. Only the new ONC criteria, 2015 Edition, can be used for Stage 3. As it currently stands in the regulation, all Health IT systems will need to be certified to 2015 Edition no later than December 31, 2017 so that providers and hospitals can do their full reporting year with their 2015 Edition CEHRT in CY 2018.

What criteria are required to certify to the 2015 edition?

ONC has published the 2015 Edition Health IT Certification Criteria which includes new, revised, and some gap-eligible criteria. Drummond Group is currently developing overview documents to help make the regulation easier to understand and more efficient for testing preparation. Once these are complete, Drummond Group will communicate the release via our e-newsletter.

Why is a Complete EHR certification not part of the 2015 Edition program?

Beginning with the 2015 Edition, “Complete EHR” certifications will no longer be issued, and only “Health IT Module” certifications will be issued. This will allow the ONC Health IT Certification Program to be more open and accessible to other Health care/practice settings. Drummond Group will be providing a certification track highlighting criteria required for the Meaningful Use Program to support vendors who have this goal.

What is the Privacy and Security criteria for 2015 Edition?

The 2015 Edition Criteria uses many of the same privacy and security criteria as 2014 Edition, but also introduces two new criteria, Trust Connection (d.9) and Auditing Actions on Health Information (d.10). The full list:
315.d.1: Authentication, access control, and authorization
315.d.2: Auditable events and tamper-resistance
315.d.3: Audit report(s)
315.d.4: Amendments
315.d.5: Automatic access time-out
315.d.6: Emergency access
315.d.7: End-user device encryption
315.d.8: Integrity
315.d.9: Trusted Connection
315.d.10: Auditing Actions on Health Information
315.d.11: Accounting of Disclosures

What are the changes to Privacy and Security functionality?

The 2015 Edition introduces the “Privacy and Security Certification Framework” which lays out privacy and security certification criteria applicable to a Health IT module presented for certification based on other capabilities included in the Health IT module and for which certification is sought. The intent is to require privacy and security functionality which would typically be needed for patient safety based on the respective criteria being used. This framework is as follows:

Criteria Requires
Clinical [170.315.a.1-15] 170.315.d.1-d.7
Care Coordination [170.315.b.1-b.9] 170.315.d.1-d.3, d.5-d.8
Clinical Quality Measures [170.315.c.1-c.4] 170.315.d.1-d.3, d.5
VDT [170.315.e.1] 170.315.d.1-d.3, d.5, d.7, d.9
Secure Messaging and Patient Health Information Capture [170.315.e.2-e.3] 170.315.d.1-d.3, d.5, d.9
Public Health [170.315.f.1-f.7] 170.315.d.1-d.3, d.7
API [170.315.g.7-g.9] 170.315.d.1, d.9 and d.2 OR d.10
Transport Methods [170.315.h.1-h.2] 170.315.d.1-d.3

For example, an HEALTH IT Module presented for certification of CPOE criteria (315.a.1-a.3) would at a minimum only be required to be certified in criteria 315.d.1-d.7. However, if that same Health IT Module added Transition of Care criteria (315.b.1), this Health IT Module would also have to be certified in criteria 315.d.8 as well.

Does my Health IT Module have to be tested repeatedly on privacy and security criteria for every criteria in the framework. For example, if I am certifying in criteria 315.a.1-a.15, do I have to test 315.d.1-d.7 all fifteen times?

No, with just a few minor exceptions. ONC has clarified that a Health IT Module would only need to be tested once to each applicable privacy and security criterion as long as the Health IT developer attests that such privacy and security capabilities apply to the full scope of capabilities included in the requested certification. However, there are two exceptions to this:

i. A Health IT Module presented for certification to 315.e.1 (VDT) MUST be separately tested on 315.d.9 (Trusted Connection)
ii. A Health IT Module presented for certification to 315.e.2 (Secure Messaging) MUST be separately tested on 315.d.9 (Trusted Connection)

This is because these patient engagement features, which often reside in patient portals, may have different architecture design than the EHR system being tested and, thus, need separate testing of this security functionality.

What if my Health IT Module does not support some of the criteria required by the Privacy and Security framework?

It is possible to have an exception of sorts to the testing required in the privacy and security framework. The privacy and security framework can be met either by completing the required testing (Approach #1), or the vendor may submit system documentation (Approach #2) which explains how the respective Health IT Module has implemented service interfaces which allow it to be integrated to other Health IT systems and, then, access external services necessary to meet the privacy and security criteria.

For example, a Health IT Module is developed for clinical quality measures (c.1-c.4) and is designed to be integrated within a hospital system. On its own, this software does not provide audit log capabilities as required by the framework criteria 315.d.3. However, the Health IT Module has API which allows it to access the hospital’s main EHR system and provide logging information. Thus, this Health IT Module can report its logging information in the hospital’s main EHR system. Documentation is shown to the test proctor explaining this and confirmed for certification.

For any vendor choosing Approach #2, it is vital this information is shared with the test proctor early in the testing process so that it can be evaluated and confirmed satisfactory or, if deemed insufficient, to allow the vendor sufficient time to resolve the problem before the test event is complete.

Will the proposed changes enhance interoperability with new or updated implementation specifications for the various certification criteria?

The 2015 Edition criteria seeks to support the establishment of the interoperable nationwide Health information infrastructure. Some of the highlighted areas include:

§ Improve interoperability for specific purposes by adopting new and updated vocabulary and content standards for the structured recording and exchange of Health information, including a Common Clinical Data Set composed primarily of data expressed using adopted standards; and rigorously testing an identified content exchange standard [Consolidated Clinical Document Architecture (C-CDA)];
§ Facilitate the accessibility and exchange of data by including enhanced data export, transitions of care, and application programming interface (API) capabilities in the 2015 Edition Base Electronic Health Record (EHR) definition;
§ Establish a framework that makes the Office of the National Coordinator for Health Information Technology (ONC) Health IT Certification Program open and accessible to more types of Health IT, Health IT that supports a variety of care and practice settings, various HHS programs, and public and private interests;
§ Ensure all Health IT presented for certification possess the relevant privacy and security capabilities;
§ Provide Health IT developers with more flexibility, opportunities, and time for development and certification of Health IT that supports interoperability, usability, and innovation.

With the proposed changes for the 2015 Edition Meaningful Use program overseen by the ONC, what has changed regarding the surveillance aspect of EHR software products?

ONC has expanded existing surveillance responsibilities for authorized certification bodies (ONC-ACBs) by adding “in-the-field” surveillance and updates to transparency and disclosure requirements. ONC-ACBs are required each calendar year to randomly select at least 2% of the Complete EHRs and Health IT modules for which it has issued a certification. Additionally, “reactive” surveillance are required for any certified product based on complaints or other information about potential non-conformities. Drummond Group will release further information regarding “Surveillance and Maintenance of Certification” once our testing process has been finalized.

How do I use the ONC CHPL?

The ONC Certified Health Product Listing (CHPL) is used by providers and hospitals to identify and select the certified EHR technologies they are using for Meaningful Use and then obtain a CMS EHR Certification ID number to use in their Meaningful Use attestation.

Instructions for navigating the CHPL and obtaining the required CMS EHR Certification ID can be found here and is also the entry point for the ONC CHPL portal:

ONC has also provided further instructions on the CHPL on this page:

How do I register for EHR testing and how much does it cost to test and certify with Drummond Group?

Registration for EHR testing is completed online at Register for EHR tests.

Please contact to Tracy LaRue ( or 512-826-2938), our Client Services Coordinator for EHR, to receive our 2014 Edition Certification and Testing Decision Kit which includes our pricing.

What is the 2014 Edition Criteria and how does it relate to Meaningful Use Stage 2?

2014 Edition Criteria is the name given by ONC to the new criteria required for Stage 2 Meaningful Use. You can find the final rule document here: Refer to sections 170.314 at the bottom of the rule to see the specific criteria.

Also, the list of all the required technical standards along with website references to the respective specifications is found here:

The previous certification was over the criteria which ONC now calls 2011 Edition Criteria (sections 170.302, 170.304, and 170.306 found in this ruling: Meaningful Use Stage 2 is developed and overseen by CMS and includes various measure thresholds required to obtain incentives. ONC has created a PDF document mapping the 2014 Edition Criteria to the Stage 2 Meaningful Use measures which you can find here: ONC also created a useful page containing informational presentations and documents regarding the new criteria which can be found here:

On this same ONC webpage, there is a PDF showing how 2014 Edition Certification can be used for Stage 1 MU.

What are Clinical Quality Measures?

Per the CMS website:

Clinical quality measures, or CQMs, are tools that help us measure and track the quality of healthcare services provided by eligible professionals (EPs), eligible hospitals (EHs) and critical access hospitals (CAHs) within our health care system.  These measures use a wide variety of data that are associated with a provider’s ability to deliver high-quality care or relate to long term goals for health care quality.  CQMs measure many aspects of patient care including: health outcomes, clinical processes, patient safety, efficient use of healthcare resources, care coordination, patient engagements, population and public health, and clinical guidelines.

Beginning in 2014, EPs must report on 9 of the 64 approved CQMs and EHs/CAHs must report on 16 of 29 approved CQMs, and the selected CQMs must cover at least 3 of the National Quality Strategy domains. Under 2014 Edition core measures are no longer required for submission in Meaningful Use attestation, but CMS does encourage use of these core set as applicable to the scope or practice and patient population:

The CQM measures and further information can be found here:

Does Drummond Group offer consulting services for EHR?

Due to our ONC-required vendor neutrality, we can neither offer nor recommend consulting services.

How do I qualify for meaningful use?

It is important to understand the distinction between certification of an EHR vendor and meaningful use attestation by an EP/EH/CAH. As this ONC website points out (, an EHR product must first be certified before an EP/EH/CAH can attest to Meaningful Use. The EP/EH/CAH must then “meaningfully use” their certified EHR in such a way to meet the specific objectives required by the CMS measures to obtain the incentives as described in the CMS Final Rule for Stage 2. The CMS Final Rule goes into the necessary detail to explain what is required, but qualifying for meaningful use incentives is ultimately the responsibility of the eligible providers and hospitals. The CMS Final Rule for Stage is found here:

My product is certified to 2011 Edition Criteria. Does it inherit its certification for 2014?

No. Per the ONC Final Rule, no previously certified EHR Module could have its certification automatically “updated” to the 2014 Edition EHR certification criteria because it would need to be certified to at least the new quality management system certification criteria (170.314.g.4). Therefore, testing with an ONC Authorized Testing Lab like Drummond Group is necessary for any 2014 Edition Certification. Also, all 2011 Edition Criteria that have been revised must be retested as well.

However, ONC has identified several unchanged criteria which qualify for “Gap Certification” and may not need to be retested for certification. These Gap Certification criteria include:

314.a.1 – CPOE (or the individual CPOE criteria 314.a.18-20).

314.a.6 – Medication List

314.a.7 – Medication Allergy List

314.a.17 – Advance Directives (Inpatient Only)

314.b.5 – Incorporate Lab Results (Inpatient Only)

314.d.1 – Authentication, Access Control, and Authorization

314.d.5 – Automatic Logoff

314.d.6 – Emergency Access

314.d.8 – Integrity

314.d.9 – Accounting of Disclosures (Optional)

314.f.1 – Immunization Information

314.f.7 – Syndromic Surveillance (Ambulatory Only)

For Gap Certification, an ONC-ACB may accept the test results from a previous certification test administered by an ONC-ATCB or ACB for unchanged criteria. If these test results are accepted, the EHR would not need to be retested for these Gap Certification criteria.

My EHR was certified by an ONC-ATCB or ACB other than Drummond Group. Can my EHR be certified by Drummond Group for the new 2014 Edition Criteria?

Yes. An ONC-Authorized Certification Body (ONC-ACB) like Drummond Group can accept test results from any ONC-ATCB or ACB. Vendors are free to use one ONC Authorized Testing Lab (ONC-ATL) for testing and a different ONC-ACB for certification, if desired.

What is a Base EHR?

Base EHR is a term defined by ONC and CMS to describe the minimum criteria required by all EPs/EHs/CAHs regardless of what Meaningful measures they are attempting to meet. Its origins are traced back to the HITECH Act itself which required physicians to demonstrate meaningful use of a qualified, certified EHR to obtain incentive money. A qualified EHR was defined as an EHR capable of:

  • Including Patient Demographic and Medical History and Problem Lists
  • Providing Clinical Decision Support
  • Supporting CPOE
  • Capturing and Querying Information Relevant to Health Care Quality
  • Exchanging and Integrating Electronic Health Information with other Sources
  • Protecting the Confidentiality, Integrity and Availability of Health Information

In the previous 2011 Edition Criteria Final Rule, the term “Qualified EHR” was used. However, with 2014 Edition, ONC replaced the term “Qualified EHR” with “Base EHR” to convey the requirements in a plain language meaning. ONC then explicitly defined the 20 criteria which comprise a Base EHR:

314.a.3, 5-7 – Including Patient Demographic and Medical History and Problem Lists

314.a.8 – Providing Clinical Decision Support

314.a.1 or a.18 or a.19 or a.20 – Supporting CPOE

314.c.1-3 – Capturing and Querying Information Relevant to Health Care Quality

Minimum of 9 CQMs covering 3 domains, including 6 CQMs from recommended core set, for EPs

Minimum of 16 CQMs covering 3 domains for EHs/CAHs

314.b.1-2, 7 – Exchanging and Integrating Electronic Health Information with other Sources (NOTE – certifying on combinations of optional criteria 314.b.8 and 314.h.1 can potentially be part of Base EHR; please ask Drummond Group’s technical team for more details.)

314.d.1-8 – Protecting the Confidentiality, Integrity and Availability of Health Information

EPs/EHs/CAHs, must have at a minimum certified EHRs, either through a single EHR product or using multiple EHR Products, covering the Base EHR definition. For example, even if an EP can qualify for the exclusion of the CPOE Measure, the EP must still have certified EHR technology with CPOE (314.a.1) criteria because it is part of the Base EHR.

Please note that Base EHR is NOT a separate EHR certification seal or designation. The two EHR certifications remain EHR Module and Complete EHR.

My software is developed for a specialty practice (e.g., dental, etc.) and some criteria are not relevant for my customers. To be a Complete EHR, do I still need to certify over all the criteria?

To be a Complete EHR, it is still required that the EHR be certified to all required ONC Criteria for the given setting, Ambulatory or Inpatient. For Fiscal Year or Calendar Year (FY/CY) 2013, EPs/EHs/CAHs must still have certified EHR technology covering all applicable and required criteria. For example, a Dentist who never submits immunizations must still have certified EHR technology with immunization functionality (either 2011 Edition 302.k criterion or 2014 Edition 314.f.1-f.2 criteria).

However, starting in FY/CY 2014, ONC and CMS have relaxed the requirement that EPs/EHs/CAHs must have Complete EHRs or EHR Modules which collectively cover the same criteria as a Complete EHR to be a fully certified EHR technology. The definition for certified EHR technology will then be more flexible in that now it is required:

  • Certified criteria which meet the Base EHR definition and…
  • Only certified criteria necessary to meet the Meaningful Use measures which are sought to achieve.

Going back to the earlier example, a dentist would now not need his or her EHR technology certified to immunization (314.f.1-f.2) even though Immunization Submission is a Core measure for Stage 2.

Please note that all applicable 2014 Edition Utilization criteria (314.g.1-g.4) would still be required for EHR certification.

Does my product have to meet all the privacy and security criteria to be certified?

For certification to 2014 Edition criteria, it is no longer required for an EHR Module to be certified to the required privacy and security criteria (170.314.d.1-d.8). However, EPs/EHs/CAHs still must have certified EHR technology over all of the required privacy and security criteria. NOTE – the Accounting of Disclosures criteria (314.d.9) is an optional criteria and not required for qualification for Meaningful Use.

Are there any required criteria for an EHR Module certification?

Yes. For certification to 2014 Edition criteria, an EHR Module must be certified to the applicable criteria in the Utilization section of the criteria, 314.g.1-g.4.

314.g.4 – Quality Management System – Required for ALL EHR Modules

314.g.1 – Automated Numerator Recording – Required for EHR Modules certifying for criteria:

  • 314.a.1 – CPOE
  • 314.a.3 – Demographics
  • 314.a.4 – Vitals, BMI, Growth Chart
  • 314.a.5 – Problem List
  • 314.a.6 – Medication List
  • 314.a.7 – Medication Allergy List
  • 314.a.9 – Electronic Notes
  • 314.a.11 – Smoking Status
  • 314.a.12 – Image Results
  • 314.a.13 – Family Health History
  • 314.a.14 – Patient List Creation
  • 314.a.15 – Patient-specific Education Resources
  • 314.a.16 – eMAR (Inpatient Only)
  • 314.a.17 – Advance Directives (Inpatient Only)
  • 314.a.18 – CPOE-Medication
  • 314.a.19 – CPOE-Laboratory
  • 314.a.20 – CPOE-Diagnostic Imaging
  • 314.b.2 – Transition of Care – Create and Transmit
  • 314.b.3 – Electronic Prescribing
  • 314.b.4 – Clinical Information Reconciliation
  • 314.b.5 – Incorporate Lab Results
  • 314.b.6 – Transmission of Electronic Lab Tests and Value/Results (Inpatient Only)
  • 314.b.8 – Transitions of Care
  • 314.b.9 – Clinical Information Reconciliation and Incorporation
  • 314.e.1 – View, Download, Transmit to 3rd Party
  • 314.e.2 – Clinical Summaries (Ambulatory Only)
  • 314.e.3 – Secure Messaging (Ambulatory Only)

NOTE – 314.g.1 is not required if certifying to 314.g.2 (Automated Measure Calculation)

314.g.3 – Safety Enhanced Design – Required for EHR Modules certifying for criteria:

  • 314.a.1 – CPOE
  • 314.a.2 – Drug-drug, Drug-allergy Interaction Checks
  • 314.a.6 – Medication List
  • 314.a.7 – Medication Allergy List
  • 314.a.8 – Clinical Decision Support
  • 314.a.16 – eMAR (Inpatient Only)
  • 314.a.18 – CPOE-Medication
  • 314.a.19 – CPOE-Laboratory
  • 314.a.20 – CPOE-Diagnostic Imaging
  • 314.b.3 – Electronic Prescribing
  • 314.b.4 – Clinical Information Reconciliation
  • 314.b.9 – Clinical Information Reconciliation and Incorporation

For more details on these specific criteria, please refer to the ONC 2014 Edition Final Rule and the ONC Test Procedures.

Can I view your test procedures/test scripts specific for my certification prior to testing?

Drummond Group will utilize the ONC test procedures that have been extensively reviewed as the basis for our testing. We do create test scripts,referred to as Proctoring Sheets, which clearly state the test procedures, expected results and verification steps for testing. However, our proctoring sheets in no way add additional requirements beyond what is expressed in the ONC test methods and are mapped back to the requirements dictated by the ONC test methods. Reviewing and using the ONC test methods for your test preparation will fully prepare you for the Drummond Group EHR ONC certification. The Drummond Group proctoring sheets will be issued to each applicant that has returned a signedMaster Services Agreement, provided us a purchase order or deposit, and has scheduled a test date on our calendar.

How do I test my software if I use a third-party ePrescribing solution?

Third-party software is permitted to be included in your certification testing. However, any third-party software, including eRx solutions integrated within your system, must be noted in the ONC certification report which will eventually be reported within the ONC CHPL.

If I use a third-party module in my software, do I need to test that module if it has been certified by an ONC-ACB?

Yes, if you want to receive certification over the criteria in question. A good example is a using a third-party e-Prescribing module. If that e-Prescribing module has been certified by an ONC-ACB, but can also be integrated within an EHR system, a Vendor’s EHR product cannot receive certification for e-Prescribing (170.314.b.3) unless they test and demonstrate compliance with that criterion. However, if you choose not to test the e-Prescribing criterion that was certified as an EHR Module in the remaining ambulatory setting criteria, your customers could still have a qualifying EHR technology by virtue of the Vendor’s EHR Module and the third-party e-PrescribingEHR Module collectively satisfying the requirements of a Complete EHR.

How much assistance can I get before registering and signing-up for testing with Drummond Group?

Prior to registering and signing up for testing with Drummond Group, we will attempt to answer any questions you have, including detailed technical questions. Our technical team is very busy with our testing services, and we do assign priority in addressing technical questions to vendors who have completed registration and sign-up. However, we will work to sufficiently answer your questions and reply as quickly as possible.

When will I receive proctoring sheets and be assigned to a Test Proctor?

Once you have satisfied the necessary legal and payment requirements for obtaining a firm test date, you will be assigned a test proctor and receive the proctoring sheets. The test proctor will then setup an introductory conference call to go over the test process and answer any questions you may have. You can also email the proctor with additional questions prior to your test date.

Do I need to notify Drummond Group if I modify my certified product?

ONC addresses this within their Final Rule on the Permanent Certification Program. The relevant section is quoted below in italics:

Comments.Several commenters requested that we clarify whether each updated version of a Complete EHR or EHR Module would need to be recertified in order for its certification to remain valid, and whether there would be a mechanism available to accommodate routine changes and product maintenance without the need to fully retest and recertify each instantiation of a previously certified Complete EHR or EHR Module.  Some of these commentators stressed that they provide bug-fixes and other maintenance upgrades to customers on a regular basis and that those versions are normally denoted by a new “dot release” (e.g., version 7.1.1 when 7.1 received certification).

Response. We understand that Complete EHR and EHR Module developers will conduct routine maintenance.  We also recognize that at times Complete EHR and EHR Module developers will provide new or modified capabilities to either make the Complete EHR or EHR Module perform more efficiently and/or to improve user experiences related to certain functionality (e.g., a new graphical user interface (GUI)). Our main concern, as we stated in the preamble, is whether these changes adversely affect the capabilities to which a Complete EHR or EHR Module has already been tested and certified and whether those changes are such that the Complete EHR or EHR Module would no longer support an eligible professional or eligible hospital’s achievement of meaningful use.  Accordingly, we clarify that a previously certified Complete EHR or EHR Module may be updated for routine maintenance or to include new capabilities that both affect capabilities related and unrelated to the certification criteria adopted by the Secretary without its certification becoming invalid. However, we do not believe that it would be wise to simply permit a Complete EHR or EHR Module developer to claim without any verification that the routine maintenance or new/modified capabilities included in a new version did not adversely affect the proper functioning of the previously certified capabilities.  We believe that an ONC-ACB should, at a minimum, review an attestation submitted by a Complete EHR or EHR Module developer indicating the changes that were made, the reasons for those changes, and other such information and supporting documentation that would be necessary to properly assess the potential effects the new version would have on previously certified capabilities.

Therefore, if you make changes to your certified product which result in a new version release and wish to see this updated version of your product listed on the CHPL as a certified EHR technology, then you must submit a written attestation to Drummond which details exactly what was changed and how it impacts or does not impact the previously certified criteria.  Drummond will provide a document containing several questions for your use in assessing the changes and their impact. The attestation will be reviewed by the Drummond Certification Committee and either approved or not approved, thus allowing the new version to be listed on the CHPL without retesting, or your company will be asked to retest this version before certification is granted.  The first attestation is free and subsequent attestations are $1000.  If your company is asked to retest, then retesting fees will apply. You can request this attestation document by registering on the Drummond website here.

What is price transparency?

One change ONC has made to the certification program is requiring vendors of certified EHR technologies to include price transparency language when promoting their certification status. These are types of costs only in addition to the costs that an EP, EH, CAH would pay to purchase the EHR technology capabilities for which certification are required. Below are some examples ONC provides in their Final Rule:

For example, if EHR technology is certified to the “view, download, and transmit to a 3rd party” certification criterion, and an EP would be expected to pay an “ongoing” monthly service fee to the EHR technology developer for it to host/administer this capability in order for the EP to meet the correlated MU objective and measure, the existence of this potential “ongoing” cost would need to be disclosed by the EHR technology developer. As another example, an EHR Module certified to the public health electronic lab reporting certification criterion (§ 170.314(f)(4)) would be able to create a valid HL7 message for electronic submission. However, for the purposes of achieving MU, a hospital may be expected to pay their EHR technology developer a separate “one-time” and/or “ongoing” interface development and configuration fee to establish connectivity between their certified EHR Module and a public health authority. In such a situation, the potential costs of the interface development and configuration fee would need to be disclosed. A final example would be where an EHR technology developer charges a “one-time” fee to integrate its certified EHR technology with a hospital’s other certified EHR Modules or a health information exchange organization. Again, just like the other examples, the potential for this fee would need to be disclosed by the EHR technology developer. Building off these examples, we would expect that an EHR technology developer could satisfy § 170.523(k)(1)(iii) by disclosing: 1) the type(s) of additional cost; and 2) to what the cost is attributed. In reference to the first example above, an EHR technology might state that “an additional ongoing fee may apply to implement XYZ online patient service.” In situations where the same types of cost apply to different services, listing each as part of one sentence would be acceptable, such as “a one-time fee is required to establish interfaces for reporting to immunization registries, cancer registries, and public health agencies.”

Which modules do I need to test for Ambulatory or Inpatient EHR?

The required modules for each setting are listed below. Please be aware that General Module criteria, which apply to both settings, may require different standards or test data according to their setting. Please refer to the 2014 Edition Certification Criteria Final Rule and associated test procedures for these details.

General Modules – Applicable for both Ambulatory and Inpatient

314.a.1 – CPOE

314.a.2 – Drug-drug, Drug-allergy Interactions Checks

314.a.3 – Demographics

314.a.4 – Vitals, BMI, Growth Chart

314.a.5 – Problem List

314.a.6 – Medication List

314.a.7 – Medication Allergy List

314.a.8 – Clinical Decision Support

314.a.9 – Electronic Notes

314.a.10 – Drug-formulary Checks

314.a.11 – Smoking Status

314.a.12 – Image Results

314.a.13 – Family Health History

314.a.14 – Patient List Creation

314.a.15 – Patient-specific Education Resources

314.a.18 – CPOE-Medication (Optional)

314.a.19 – CPOE-Laboratory (Optional)

314.a.20 – CPOE-Diagnostic Imaging (Optional)

314.b.1 – Transition of Care – Receive, Display and Incorporate

314.b.2 – Transition of Care – Create

314.b.3 – Electronic Prescribing

314.b.4 – Clinical Information Reconciliation

314.b.5 – Incorporate Lab Results

314.b.7 – Data Portability

314.b.8 – Transitions of Care (Optional)

314.b.9 – Clinical Information Reconciliation and Incorporation (Optional)

314.c.1 – Clinical Quality Measures – Capture and Export

314.c.2 – Clinical Quality Measures – Import and Calculate

314.c.3 – Clinical Quality Measures – Electronic Submission

314.d.1 – Authentication, Access Control, and Authorization

314.d.2 – Auditable Events and Tamper-Resistance

314.d.3 – Audit Report(s)

314.d.4 – Amendments

314.d.5 – Automatic Logoff

314.d.6 – Emergency Access

314.d.7 – End-user Device Encryption

314.d.8 – Integrity

314.d.9 – Accounting of Disclosures (Optional)

314.e.1 – View, Download, Transmit to 3rd Party

314.f.1 – Immunization Information

314.f.2 – Transmission to Immunization Registries

314.f.3 – Transmission to Public Health Agencies – Syndromic Surveillance

314.g.1 – Automated Numerator Recording

314.g.2 – Automated Measure Calculation

314.g.3 – Safety-Enhanced Design

314.g.4 – Quality Management System

314.h.1 – Direct Protocol Transport with CCDA (Optional)

314.h.2 – Direct Protocol Transport with XDM (Optional)

314.h.3 – SOAP Transport with XDR (Optional)

Ambulatory-Specific Modules

314.e.2 – Clinical Summaries

314.e.3 – Secure Messaging

314.f.5 – Cancer Case Information (Optional)

314.f.6 – Transmission to Cancer Registries (Optional)

314.f.7 – Syndromic Surveillance (Optional)

Inpatient-Specific Modules

314.a.16 – eMAR

314.a.17 – Advance Directives

314.b.6 – Transmission of Electronic Lab Tests and Value/Results

314.f.4 – Transmission of Reportable Lab Results


Additional Resources:

ONC FAQs are located at:

CMS FAQs are located at:

What is Drummond Group?

Drummond Group is the trusted interoperability test lab offering global testing services throughout the product life cycle. In addition to interoperability testing services, Drummond Group offers test lab services including CSOS auditing, QA, conformance, and test consulting. Founded in 1999, Drummond Group represents best-of-breed on linking technologies, standards and interoperability issues with the needs of vertical industries such as automotive, consumer product goods, healthcare, financial services, government, petroleum, pharmaceutical and retail.

What is CSOS?

The Controlled Substances Ordering System (CSOS) is an electronic commerce initiative overseen by the U.S. Drug Enforcement Administration (DEA) that provides an automated alternative to the current paper-intensive process required for the purchase and distribution of Level I and II controlled substances.

In the current paper-based process, paper forms must be created or updated at every registered shipping location when controlled drugs are transferred. With CSOS, the DEA is defining a system based on digital signatures which allows for the paper forms, known as Form 222, to be replaced by digital messages often referred to as e222 or electronic 222 forms. Purchasers and suppliers may now use either of these methods, paper-based or electronic forms, to fulfill DEA requirements that prevent illegal diversion of controlled drugs.

The DEA proposed rule for CSOS includes technical and business requirements for products used to digitally sign, transmit or receive e222 forms. Software companies that provide these products must participate in an initial audit of the product and additional audits when changes are made to the core digital signing technology. End user companies that build in-house CSOS systems for digital signing, transmission or receipt of e222 forms also must be audited.

Which CSOS services does DGI offer?

As an independent, neutral third party, Drummond Group offers two types of CSOS Services.


  1. Drummond Group offers CSOS Auditing services certifying software products-with-version for compliance with DEA rules for sections 1311.55b and 1311.55c. CSOS Auditing Certification is proof that software offerings can enable purchasers and suppliers to interchange e222 forms in a predictable and secure manner compliant with DEA requirements.
  2. In addition to CSOS Audits conducted with the highest level of assurance, Drummond Group also offers pre-audit consulting (conducted with minimal assurance) to work with companies who are developing CSOS implementations to ensure they are working towards the CSOS compliance in the Audit

What does an audit consist of?

The CSOS Audit is conducted on pre-installed, off-the-shelf commercial software or in some cases, on in-house built systems by the end-user:


  • Confirmation that products-with-version have been issued seals of compliance to FIPS (Federal Information Processing Standards). FIPS sets best practices and prescribes specific computer software algorithms approved by the federal government to insure data security.
  • The ability to digitally sign, transmit and receive e222 forms in a FIPS enabled mode. Auditing will confirm that the products can perform digital signature functions while using only FIPS required methods.
  • The ability of products to execute fundamental digital signature processing including applications of digital signature, validating a business partner’s digital signature using that business partner’s public key and validation of message integrity.
  • The products’ ability to recognize and act on invalid digital signatures and invalid digital certificates that have expired or have been revoked by the DEA.

Who needs to be audited?

The proposed rule requires that systems developers or vendors must be audited. If you are developing an in-house system that digitally signs, transmits or receives e222 forms, your system must also be audited. If you are purchasing a product that digitally signs, transmits or receives e222 forms, the software vendor that provides the system must be audited and provide you with proof of certification for that product-with-version.

For both systems developers and vendors, an additional audit is required whenever signing or verifying functionality is changed.

NOTE: All organizations handling Level I and II controlled substances are ultimately responsible for ensuring that they fully comply with DEA regulations regarding handling of Level I and II substances. Using software which has received CSOS certification in and by itself does not exempt organizations handling Level I and II controlled substances of this responsibility.

What is the importance of CSOS auditing?

The DEA requires that any applications used to digitally sign, transmit and/or receive CSOS orders must be audited by an independent third party. See QA 7 for more info.

What do I look for in a certifying organization?

The certifying organization should have experience in testing and auditing security related software standards, in particular the use of digital signature technology. Drummond Group has audited the majority of the current CSOS software used in the Pharmaceutical Distribution Industry today!

To remove the likelihood or appearance of biased auditing, certifying organizations should be verifiably neutral companies that do not themselves produce or market CSOS products and do not have business partnerships with companies that produce or market CSOS products.

The proposed rule requires the use of an independent, third-party in section 1311.55(d): “For systems used to process CSOS orders, the system developer or vendor must have an initial independent third-party audit of the system and an additional independent third-party audit whenever the signing or verifying functionality is changed to determine whether it correctly performs the functions listed under paragraphs (b) and (c) of this section.”

What are the steps to testing the DEA Audit requirements?

The security modules of a CSOS product-with-version must be FIPS 140-2 certified to at least Level I and must include FIPS Certified digital signature and secure hash algorithm implementations.

The auditing process will verify compliance to CSOS through a series of positive and negative physical tests of the product-with-version. Please contact Drummond Group by email

Where can I get more information about CSOS?

For more information about CSOS, please visit the DEA website:

What is the GDSN and how does it work?

The Global Data Synchronization Network (GDSN) is a network of interoperable data pools and a global registry called the GS1 Global Registry, for communicating master data (Catalogue Item and Party) between trading partners. The GDSN, conceived and supported by EAN International, the Uniform Code Council, Inc. (UCC), and leading companies and industry groups worldwide, is a global, Internet-based initiative that will enable trading partners to quickly and efficiently exchange supply chain data that is accurate, up-to-date, and compliant with universally supported EAN.UCC System standards.

The GDSN was developed in partnership with the global business community to address the high costs associated with inaccurate data. The GDSN vision, conceived by the Global Commerce Initiative (GCI), is based on a centralized, global registry that connects to numerous data pools around the world, enabling data to be standardized and synchronized for trading partners on a near real-time basis. In order to ensure the GDSN meets the business needs of the user community, EAN International and the UCC established a GDSN Oversight Committee as the foundation of its governance structure. The Oversight Committee, which currently includes 17 senior executives from manufacturing, retailing, and EAN Member Organizations, has been appointed to govern the GDSN, promote global adoption and address strategic issues related to the rollout of the GDSN.

For more information, please see:

What is the GS1 Global Registry?

On Aug. 1, 2004, the global registry functionality required for the creation of a global network was put into production under the jurisdiction of EAN International. The GS1 Global Registry™ (in anticipation of the EAN/UCC 1st January, 2005 name change to “GS1”) will be operated as a distinct and separate neutral entity by EAN International. The GS1 Global Registry will serve as a global gateway for companies to locate source (manufacturer) or recipient (retailer) data pools, which contain item and party information.

What are the benefits of participation in GDSN certification?

Benefits will include opportunities to:

  • Learn the early needs of the sponsoring user communities and get market validation for your data pool
  • Debug your data pool with leading competitors in a vendor-neutral, low risk, “market simulated environment” so that you resolve problems before you provide data pool services to your customers
  • Gain market acceptance and recognition for implementing new standards
  • Join the early adopter list of certified data poolsÑthe shopping list for trading partners searching for data pool services.

How are the test plans developed?

The test plans are developed by Drummond Group. They will be reviewed by vendors who choose to join the interoperability project and necessary modifications will be made as appropriate. Drummond Group will be facilitating the test process through the Drummond Group Test Lab using its Interoperability Compliance Process® is a robust interoperability process methodology which enables vendors to thoroughly test their products against other participating vendors. A copy of the Final Report will be published along with the test results and posted on the GDSN website.

What part of GDSN is being tested?

Participating data pools will use the GS1 messaging standards to execute a series of registry functionality tests that will focus on enabling data transactions. Exactly what use cases are tested in each test event are being defined by the GDSN task group. Data pools will then execute a series of notification type events fulfilling data synchronization. In a phased approach, data pools will demonstrate full interoperability with all participants by the final phase of testing.

What happens after my data pool passes GDSN Interop?

Upon Drummond Group’s notification of passing the GDSN Interop test, your data pool is certified as “Interoperable” and your product-with-version will be listed on the GDSN website.

What is Drummond Group's role?

Drummond Group is the exclusive testing certification authority for GDSN. Drummond Group administers testing in a neutral, cooperative and non-competitive environment. DGI maintains strict vendor neutrality to assure integrity of the testing process.

  • Drummond Group maintains the confidentiality of each participant’s progress during the testing process
  • Drummond Group only interacts with the technical staff of the participating data pools on daily phone calls during the testing process (Sales and Marketing are only involved in related press releases subsequent to the completion of testing)
  • Drummond Group creates a non-competitive, cooperative environment for data pools to successfully pass and complete testing
  • Drummond Group only announces those data pools that have successfully passed the tests — i.e., Drummond Group does not make public those entities that have not succeeded in completing or passing tests.

How can I safeguard my intellectual property?

  • No one sees your actual products (i.e. not your competitors, not even Drummond Group)
  • You choose how much you want to share with the group on specific code problems with your product
  • All testing is done over the Internet from your controlled environment
  • All discussions on problems and code adjustments are held via conference calls and email
  • Other participants only see data exchanged (we provide the data for the test in concert with the participants)
  • Sales and Marketing contacts are not allowed on the daily conference calls. Only approved technical contacts are allowed on the daily phone calls and email list serve.

What are Drummond Group's responsibilities in this testing?

  • Drummond Group provides a neutral environment to ensure you and your competitors can work cooperatively together to ensure compliance/conformance and interoperability
  • Drummond Group does not see or request your code at any time
  • Drummond Group sees the test data and ensures the test results are accurately recorded
  • Drummond Group will NOT publicly announce any entities who fail to pass the tests. Only those passing data pools are announced.
  • Drummond Group resolves individual and group problems as they occur and makes every effort to ensure fair and speedy dispute resolution to keep the testing process moving

Where will the tests take place?

Tests will be conducted over the Internet with mandatory daily conference calls. It is suggested that one person be dedicated during the process to handle the testing. At times it may be necessary to add additional staff to keep from falling behind in the testing process and ensure your product stays on the test schedule.

What is Drummond Group?

Founded in 1999, Drummond Group is a leader in innovative, global software testing, certification and acts as a catalyst to advance and tie together technologies, standards, security and interoperability in vertical industries – smart grid, automotive, health care, financial services, government, petroleum, pharmaceutical and retail. As a trusted, experienced and accredited interoperability test lab, the firm offers global test services through the product life cycle, including auditing, quality assurance, conformance and test consulting.

Drummond Group administers interoperability tests to enable vertical and horizontal interoperability across the global supply chain. Drummond Group’s expertise in interoperability testing services and ebusiness standards is reflected in a series of research reports designed to provide education and valuable insight into current technology issues and guidance to enterprises seeking the best solutions for their supply chains.

What is ebXML?

Electronic Business using eXtensible Markup Language (ebXML) is a standards framework created by UN/CEFACT and OASIS. ebXML’s mission is “To provide an open XML-based infrastructure enabling the global use of electronic business information in an interoperable, secure and consistent manner by all parties.”

ebXML has five main areas of focus:

  • Business processes – Business Process Schema Specification
  • Register business processes – Registry & Repository
  • Define trading relationships – Collaborative Partner Profiles & Agreements
  • Common terms for business data – Core Components
  • Reliably exchange business messages – Message Services

The ebXML framework is a loosely coupled group of standards that was built concurrently. The end result is that each major standard may be implemented independent of the others.

What is ebXML Message Services?

ebXML Message Services is the messaging standard defined within the ebXML framework and is sometimes abbreviated as ebMS. ebMS has seen the most interest and adoption of the five key ebXML standard efforts. ebMS provides for secure and reliable messaging over the Internet. Organizations that exchange business data using ebMS can take advantage of its ability to provide:

Encryption of data via SSL or optional data encryption standards

User authentication via SSL or Digital Signature

Reliable Messaging
Once-and-only-once message delivery and integrity of message content validated through SSL or Digital Signature

Robust Messaging
Support for extremely large messages, multiple payloads in a single message & asynchronous messaging

Messages of any data type, including binary graphics, EDI or XML

How is ebMS being utilized within the automotive industry?

In the automotive sector, industry groups such as AIAG (Automotive Industry Action Group) and STAR (Standards for Technology in Automotive Retail) are looking to ebMS as a means for businesses to exchange messages and data directly in a safe, reliable manner over the Internet and are making recommendations to their respective memberships.

In August 2004, STAR published the STAR Transport Guidelines which included ebMS Implementation Guidelines. These guidelines provided best practice recommendations for using ebMS in the upstream automotive space and a recommendation to include data compression, a feature not currently in the ebMS specification, but critical to their business needs. STAR serves as the IT standards body for the North American retail automotive industry and focuses on providing assistance to automotive dealers, manufacturers and Retail Systems Providers (RSPs) as they seek to establish a common data exchange with one another.

For AIAG, ebMS is one of the core standards in play within a critical pilot and demonstration project named IV&I (Inventory Visibility and Interoperability). It is in a position to bring significant cost savings to the auto sector by providing a base for interoperability of inventory systems throughout the automotive manufacturing industry.

What is the price of ebMS software and how can I purchase it?

Drummond Group serves as a vendor-neutral, third party to test commercial software for interoperability. To maintain its vendor neutrality, Drummond Group does not make product recommendations or provide pricing information. Companies interested in purchasing software which have successfully passed interoperability testing can refer to the product listings located on the Drummond Group website. To see a list of certified ebMS products, or to read all the test details, go to ebMS Interoperability Product Directory.

Take note that ebMS is just one of the standards that Drummond Group tests. Products that pass DG’s vendor-neutral tests are certified interoperable or compliant and published in the list of Drummond Certified products. Since 1999, Drummond Group has facilitated multiple ebMS test events of numerous software vendors’ products. When suppliers choose from the list, they start with products that:

  • Have met the benchmark requirements for interoperability and compliance
  • Will work together with a minimum of installation effort and expense
  • Represent a range of features and price points to meet different supplier needs

It is up to you to contact the individual companies to get pricing and product feature information.

How often does Drummond Group conduct tests for messaging standards such as ebXML or ebMS?

Drummond Group conducts periodic tests of products for various standards. The frequency varies by standard and its stage of adoption in the industry. See the Drummond Group Test Calendar for each year’s schedule.

What is interoperability testing and why is it important?

Interoperability testing is important to ensure that your supply chain can efficiently operate even when your partners are using applications developed by different software vendors. Just because a product is “conformant” or “compliant” to a standard does NOT mean that it’s interoperable. For companies engaged in the growing electronic commerce marketplace, software interoperability is vital, and its absence can strongly inhibit supply chain implementations and add significant supply chain costs.

The exchange of vital information at a proven security level between automotive dealers, manufacturers and RSPs is critical for the automotive sector to meet the demands of a changing world. This requires the move toward new technical communication environments that share common data messaging standards in the supporting software.

What is the difference between compliance testing versus interoperability testing?

Compliance means “I followed the technical specifications” and is generally tested against one software reference implementation. Interoperability testing goes one step further because it means each party is both compliant and can interoperate with each other party according to a subset of the standard. Interoperability testing is done among all participating software products. When an important communication is needed, an interoperable software product will ensure the communication will be there reliably and securely. It will work when needed.

Interoperability testing goes further than compliance testing by ensuring that software solutions from different vendors can communicate thereby reducing integration and implementation costs. For example, the retail industry found compliance insufficient and made a strategic decision to roll-out only interoperability tested software in their supply chains. This was critical to successfully automating the exchange of millions of dollars of invoices and purchase orders on a daily basis.

Best practices which can be applied to automotive supply chains are:

  • Confirm that each party’s software is compliant with the technical standard
  • Reach solid agreement on a compliance profile, or subset of a complex standard
  • Confirm each party’s software can interoperate with each and every other party over the profile

What is Drummond Group's Interoperability Compliance Process™?

This is a methodology for testing that software applications created by different vendors can communicate with each other. Drummond Group tests every product-with-version against all of the other products-with -version involved in a specific test round. Drummond Group has done extensive work in the world of interoperability, having tested products from more than 350 software products since 1999 which support these Internet messaging standards: AS1, AS2, AS3, ebXML messaging vs 2.0 and CPFR®. Drummond Group’s reach extends across the globe as companies based in Europe, Asia-Pacific and the Americas have participated in interoperability testing.

How are Drummond Group's interoperability tests performed?

Drummond Group’s software testing services provide a critical link by ensuring that multiple software products are interoperable. Furthermore, Drummond Group continues to mediate the resolution of interoperability problems, if they occur, between DG-tested products in the industry.

Since 1999, Drummond Group has specialized in interoperability tests, cross-testing all participating products against each other to ensure interoperability among all products in the test round. Products that pass testing not only comply with the standard and work against a reference platform, but interoperate with one another. The testing process, as well as detailed test results for each product and standard, is available at: Certified Products Directory

In addition to a team of experienced developers, Drummond Group also offers new automated testing software called InSitu™. If your initiative requires ongoing periodic verification of interoperability across versions, InSitu can provide valuable savings in manpower, time and costs.

How do I obtain the software needed for secure ebMS with my supply chain?

Third-party software vendor solutions that support ebMS can be used to automate business to business style messaging with supply chains.

What third-party vendor software solutions have been tested and certified as being interoperable?

ebMS is just one of the standards that Drummond Group tests. Products that pass Drummond Group’s vendor-neutral tests are certified interoperable or compliant and published in the list of Drummond Certified products. Since 1999, Drummond Group has facilitated multiple ebMS test events with numerous software vendors’ products. To see a list of certified ebMS products, or to read all the test details, go to ebMS Interoperability Product Directory.

When suppliers choose from the list, they start with products that:

  • Have met the benchmark requirements for interoperability and compliance
  • Will work together with a minimum of installation effort and expense
  • Represent a range of features and price points to meet different supplier needs

What are the key benefits to using ebMS for data interchange?

Benefits will differ depending upon exact situations, but general benefits include:

  1. Secure messaging, including encryption for Privacy of data
  2. Reliable messaging including guaranteed one-time delivery of messages
  3. Ability to automate messaging, reducing keying errors

Are there any performance issues when using ebMS software?

Performance will differ depending upon platforms, memory, network and processor speed. Most ebMS solutions are capable of processing a message in a matter of seconds, and will allow for significant scalability even on smaller servers or desktop machines.

Is ebMS limited to transporting only XML data? What about binary formats like pictures, audio or EDI data formats?

ebMS can transport any type of digitized data including pictures, audio and EDI file formats. Data is transported in a package known as a payload, in a similar fashion to e-mail attachments. A single message can contain multiple payloads.

How can I integrate ebMS software with my current information technology infrastructure?

Software vendors that provide ebMS support also provide middleware, or partner with companies that provide middleware targeted at integrating messaging with back-end systems. As ebMS is SOAP-based, an ebMS gateway can also be quickly integrated to backend systems that support SOAP based messaging.

What version of ebMS will be used in Drummond Group's interoperability test rounds?

Currently, ebMS version 2.0 of the ebXML Message Service standard is being utilized by multiple industries, such as automotive and public health.

What is the current status of ebXML Message Services Version 2.0?

ebMS is maintained by OASIS (Organization for the Advancement of Structured Information Systems) and was approved as an OASIS standard in 2002. Since 1999, more than 100 ebMS solution providers have successfully completed Drummond Group’s interoperability testing of ebMS Version 2.0.

If I buy a software solution supporting ebMS, will it work with an AS2 based software solution?

No. The AS2 and ebXML Messaging standards do not interoperate. However, a growing number of software vendors provide functionality that would support both standards. So, one might start with AS2 and move to ebXML, or vice versa, with the same product base. Please check with your software vendor for particulars.

How can I estimate an ROI for using ebMS for data interchange?

Return-on-Investment will differ depending upon situations. General ROI can be assessed by looking at:

  1. Error reduction due to less keying of data
  2. Value of using a secure, standards based messaging service
  3. Value of integrating back-end systems

Where can I find more information about ebMS?

OASIS and the UN sponsor an industry portal specific to ebMS at:

What is randomized in-the-field surveillance?

The purpose of in-the-field surveillance is to “provide assurance to customers, implementers, and users that health IT certified on behalf of ONC will continue to meet the requirements of its certification when it is implemented and used in a production environment” (80 FR 62707).  Therefore, unlike conducting testing directly with a health IT developer, in-the-field surveillance is conducted with end users to evaluate how the product operates in a “real world” environment.

Additionally, the ONC 2015 Edition Final Rule requires that ONC-ACBs randomly select a minimum of 2% of all certified Complete EHRs and/or Health IT Modules for this type in-the-field surveillance each calendar year (45 CFR § 170.556(c)(6)).

How are products selected by Drummond Group for randomized surveillance?

Drummond Group created a randomized selection tool to identify 2% of certified products for in-thefield surveillance.  Per the Final Rule, ACBs may apply an appropriate weighting value to the sampling.  Drummond Group believes it is in the best interest of the program to give different weights to Complete EHRs and Health IT Modules that have a large user base compared to those with a smaller deployment.  This is determined based on Meaningful Use attestation data from the API.

While a weighted system has been applied, giving products with higher volumes of attestations a greater chance of being selected, all Drummond certified products are included in the randomized  selection tool and any product is eligible for random selection.  For more information on Drummond’s randomized calculation, please see Drummond Group’s CY 2017 Annual Surveillance Plan.

How many end user organizations will be selected for in-the-field testing?

At least one end user organization will be randomly selected for each certified product chosen for inthe-field testing.

How does Drummond select the end users for testing?

Health IT developers are required to provide Drummond Group with full customers lists for any products selected for randomized surveillance.  Drummond Group utilizes a spreadsheet randomize routine to select at least one end user organizations for in-the-field review.  No weighting scale or special values are applied to the selection of end users.  Drummond Group will inform the developer of the end user organization that was selected.

How will the developer’s provider/hospital customers be notified?

For each provider/hospital organization that is selected, Drummond Group will email the contact that the developer included as part of their customer list.  They will be provided with end user specific FAQs and documents that explain randomized in-the-field surveillance and what they can expect as a participant.  They will also receive end user specific proctor sheets with the test scenarios for in-the-field review.

How will health IT developers be notified of the results?

Upon completion of in-the-field testing with the end user, Drummond Group will email the health IT developer to inform them of the results.  If all criteria passed, the developer will be notified and no further action will be required.  If potential deficiencies were identified, the health IT developer will be notified of the deficiencies.  Depending on the nature of the potential deficiency, further review with the health IT developer and provider will likely be needed to assist Drummond in determining if the deficient result is a non-compliance of the certified health IT or if lack of training, site-specific implementation or other factors contributed to the result.

What happens if a non-compliance is found?

If a non-compliance is confirmed, Drummond Group will issue a Corrective Action Plan to the health IT developer and file the non-compliance on the ONC CHPL.  The health IT developer will be required to fix the deficiency and complete a paid re-test of the non-compliant feature(s) with Drummond Group.  The fix must be deployed to all impacted end users.  Drummond may also elect to re-test that feature with an end user in the field to validate the fix.

When will testing with end users occur?

Testing with end users will be conducted before the end of the calendar year and will be scheduled based on availability of the end user organization and Drummond test proctors.

What criteria will be tested?

The goal is to follow the spirit and direction of the ONC criteria being evaluated while mimicking the normal workflow of the provider.  Special proctor sheets are provided to the end user to allow them to prepare for the testing.  As required by ONC, Drummond Group will test all the certification criteria that have been prioritized in ONC’s annual surveillance guidance.  The list of prioritized criteria is detailed below.  If the selected health IT product is not certified in one of the prioritized criterion, that prioritized item will simply not be tested.

Interoperability and Information Exchange

  • 45 CFR § 170.314(b)(1) Transitions of care – receive, display and incorporate transition of care/referral summaries
  • 45 CFR § 170.314(b)(2) Transitions of care – create and transmit transition of care/referral summaries
  • 45 CFR § 170.314(b)(7) Data portability
  • 45 CFR § 170.314(b)(8) Optional – transitions of care
  • 45 CFR § 170.314(e)(1) View, download, and transmit to 3rd party
  • 45 CFR § 170.314(h)(1) Optional – Transmit – Applicability Statement for Secure Health
  • 45 CFR § 170.314(h)(2) Optional – Transmit – Applicability Statement for Secure Health Transport and XDR/XDM for Direct Messaging


  • 45 CFR § 170.314(a)(2) Drug-drug, drug-allergy interaction checks
  • 45 CFR § 170.314(a)(8) Clinical decision support
  • 45 CFR § 170.314(a)(16) Inpatient setting only—electronic medication administration record
  • 45 CFR § 170.314(b)(4) Clinical information reconciliation
  • 45 CFR § 170.314(b)(9) Optional – Clinical information reconciliation and incorporation


  • 45 CFR § 170.314(d)(2) Auditable Events and Tamper-Resistance
  • 45 CFR § 170.314(d)(7) End user Device Encryption

Population Management

  • 45 CFR § 170.314(c)(2) Clinical quality measures – import and calculate

What information must a health IT developer provide to Drummond if selected for randomized surveillance?

Health IT developers must provide Drummond with a list of customers currently using the certified product selected.  That customer list must include contact information for each customer and should be uploaded per the instructions provided in the Surveillance Manager task and using the Drummond Excel spreadsheet template.

Additionally, Health IT developers must provide Drummond with a copy of their complaint log.

Why does Drummond require the submission of a health IT developer’s complaint log if they are selected for randomized surveillance?

Per the ONC CY Program Guidance, ONC requires that ACBs identify, for each health IT developer whose technology was subject to surveillance during the applicable calendar year, and regardless of the circumstances that triggered surveillance or the type of surveillance performed:

  • The extent to which the developer followed its complaint process, and any observed deficiencies with its process.
  • The frequency of complaints made to the developer associated with the prioritized elements in Part IV.

Are there consequences if a health IT developer does not provide Drummond with the requested information?

Yes, health IT developers must provide Drummond Group with the requested information or their certification status may be at risk.  The 2015 Edition Final Rule states that “if a health IT developer refuses to provide this information to an ONC–ACB, the ONC–ACB may regard the refusal as a refusal to participate in surveillance under the ONC Health IT Certification Program and institute appropriate procedures, consistent with the ONC–ACB’s accreditation to ISO 17065, to suspend or terminate the health IT developer’s certification” (80 FR 62716).

Is Drummond Group allowed to access PHI when conducting in-the-field surveillance with providers?

Yes, Drummond Group is allowed to access PHI for the purposes of surveillance.  Per ONC FAQ 45,

“Under the Office of the National Coordinator (ONC) HIT Certification Program rules at 45 CFR 170 Subpart E, ONC-ACBs are authorized to perform EHR technology certification on behalf of ONC. An ONC-ACB is also required as a condition of its accreditation and ONC-authorization to perform surveillance on the EHR technology it certifies to ensure the EHR technology continues to perform in an acceptable manner in the field. In this capacity, ONC-ACBs meet the definition of a “health oversight agency” in the HIPAA Privacy Rule, and a health care provider is permitted to disclose PHI (without patient authorization and without a business associate agreement) to an ONC-ACB during the limited time and as necessary for the ONC-ACB to perform the required on-site surveillance of the certified EHR technology. 45 CFR 164.501,