2015 Certification: 6 Things to Know

Steve Jobs famously remarked that users “don’t know what they want until you show it to them.” This is often true in the software development world as a whole, while in Healthcare IT much of what we do is essentially client-driven.

But what about when a feature is neither? Such is the case with some of the requirements found ONC 2015 Edition Certification. When faced with 2015 Edition Certification, EMR developers have a lot of questions, starting with “Why should we do this in the first place?”

Drawing on experience from our own certification and that of our clients, we’ll address some of the most pressing concerns in this post.


1. 2015 Certification software has become increasingly compulsory

SOURCE: ONC


At its inception, EMR developers fairly asked, given limited time and resources, whether there was any immediate reason to broadly adopt 2015 Certification criteria. It’s been essential to keep current on clinical quality measures in order to report to CMS programs (QPP, HQR, Joint Commission and CPC+), but Certification criteria as a whole has become more relevant with time.

Part of this is catching up with early adopters for competitive and marketing reasons. MIPS requirements for ambulatory providers have also been a driver – certified electronic health record technology is required for participation in the Advancing Care Information category of the QPP and only a 2015 Edition certification that includes automated measure calculation will enable reporting on ACI measures past the “Transition” phase.

2. Self-declaration takes some of the pressure off
Perhaps the most important thing to note about self-declaration is that the technical requirements for “self-declare” measures have not been eased. And there is a good bit of documentation required to prove the testing you have conducted independently.  However, the inclusion of a wide swath of self-declaration (non-live testing) measures has eased some of the burden for developers. The stakes and costs are lower now that you can test iteratively and do not have to schedule extra live testing (and potential re-testing) with your proctor. Keep in mind also that your proctor can ask at any time to review the self-declaration criteria.

3. Building an API for Patient Engagement means knowing your endpoints
If you know you’re going to be certifying the 2015 Edition “API” measures (g7 – g9), you’ll need to decide on technologies for delivering clinical data resources and authenticating user. We recommended FHIR and OAuth, respectively. There are pros and cons for both, but our decision was based on which technologies are best-positioned for where Health IT interoperability is headed.

It’s also worth exploring how patient-accessible APIs are going to work in the wild. The 2015 Certification measure provides a pathway to certifying that you can make XML/JSON available per patient and filterable by common clinical dataset sections and date. But it doesn’t connect the dots between accessing the raw resources from the API and getting it into a consolidated location that is usable by a non-technical patient user. For that, you’ll need to consider the extent to which you’ll take that leap into Patient Health Record development – or tailor your solution for compatibility with big players in this space such as Apple (which is, for now at least, pursuing a FHIR-based mobile record).

4. (b)(1) Transition of Care is a many-layered measure
The (b)(1) measure is proof that a world of functionality can lurk in a single sentence. In addition to sending and receiving a variety of transition of care documents through your chosen protocol(s), b1 also requires you to:

  • Detect valid and invalid ToC/referral summaries and provide an accounting of errors
  • Display a human-readable C-CDA for BOTH r1.1 and r2.1 CCDA
  • For both r1.1 and r2.1, allow your users to display only the data within a particular C-CDA section, set a preference for the display order and set the initial number of sections to be displayed.
5. (b)(6) Data Export is about more than just CCDAs
The 2015 Edition Data Export measure (b6) shares a similarly ambitious goal with the API: that all patient data can be made portable and requested from an EMR at any given time. For data export, not only are you asked to pull out patient data in CCDA form, but you need to be able to slice the patient data in several different ways, exporting either in real-time or scheduled ahead.
The different permutations for exporting under this measure are often a source of confusion, so here are the discreet taste cases to help make things more intelligible:
  • On-demand (export runs immediately):
    • Request all patients from a specific start date and time until the present
    • Request all patients from a specific start date and end date, with the end date occurring prior to the present
    • Request a subset of patients from a specific start date and time until the present
    • Request a subset of patients from a specific start date and end date, with the end date occurring prior to the present
  • Scheduled (configured for a future date-time):
    • Relative (a recurring scheduled report)
      • Request all patients based upon a relative date and time from the date range in the data (e.g., generate a set of export summaries from the prior month on the first of every month at 1:00 a.m.)
      • Request a subset of patients based upon a relative date and time from the date range in the data
    • Specific (a one-time scheduled report)
      • Request all patients based upon a specific date from the entered start and end dates and times (e.g., generate a set of export summaries with a date range between 01/01/2015 and 03/31/2015 on 04/01/2015 at 1:00 a.m.).
      • Request a subset of patients based on upon a specific date from the entered start and end dates and times
6. Automated measure calculations and usability testing involve a lot of data-gathering 
Automated measure calculations are based on an expansive spreadsheet of test cases furnished by ONC. These cases ensure that your measure calculations follow the expected measure logic faithfully. There’s really no corner-cutting on these, but one limiting factor is the measures you are certifying overall. If, for instance, you aren’t certifying ePrescribing, you will not be on the hook for those calculations.  Also, if you know the programs and stages of Medicare MU/Promoting Interoperability, Medicaid MU and ACI that apply to your users, you can hone in on just the calculations that are relevant. 
For usability testing, you will be in good shape by modeling your study and write-up after an established usability process approved by ONC. Your proctor should provide you with a sample list of functions subject to testing. The estimated time to conduct the study and complete the write-up would be 3 weeks, but this will be contingent on difficulty of recruitment, your own test design and then post-test editorial/graphic design considerations for the doc itself. The results of the testing will be posted on CHPL.
For
vendors seeking support on 2015 Edition measures, check out our site to see how our
bolt-on certification solutions can fit into your certification plan.
Copyright Dynamic
Health IT ©, Inc 2018. We specialize in ONC-certified
solutions, CQMs and system interoperability via standards such as HL7®, CDA®,
CCD and FHIR® using our flagship products – CQMSolutions, ConnectEHR, ConnectEHR-Portal, DynamicFHIR and The Interface
Engine(TIE). 

Subscribe to our newsletter and mailing list here.