API Conditions Of Certification

Conditions of Certification

In a previous blog, we mentioned that there’s a six month window for any “Certified API Developer” to “publish all terms and conditions for its certified API technology, including any fees, restrictions, limitations, obligations, registration process requirements or other similar requirements.” It is important to note that this applies to any API certified to 170.315(g)(7) through (9) and is independent of, and separate from, the requirement for APIs to conform to the FHIR standard (see previous blog). So these publication requirements precede any of the new FHIR requirements.

  • Transparency: Developers must provide publicly accessible documentation for those wishing to interact with their certified API.
  • Fees: Fees are restricted but allowed to cover development, deployment, upgrade and usage of the API. EHR developers can also charge for “value-added services” over and above the basic certified API functionality.
  • Openness: Developers “must grant API Information Sources the independent ability to permit API Users to interact with the certified API technology deployed by the API Information Source”. Also, API Information Sources and API Users must be allowed full access and ability to provide products and services that leverage the API.

Maintenance of Certification

As a certified EHR developer, there are new ongoing tasks you’ll need to follow. Attestations must be submitted every 6 months, starting April 1, 2021, with a 30-day window for submission.

ONC has introduced an interesting new concept and associated requirement: “Real world testing” and it is required for 170.315(b), (c)(1-3), (e)(1), (f), (g)(7-10) and (h). Real world test (RWT) plans must be developed and submitted to your ONC-ACB in order to maintain certification.

RWT plans are intended to demonstrate that CEHRT meets intended use cases in a production context.

“The certified health IT is exchanging electronic health information in the care and practice settings for which it is intended for use”.

Fortunately for some of the smaller and niche vendors we work with, ONC “decided not to establish a minimum number of settings or minimum percentage or fraction of production instances of the developer’s applicable certified Health IT Modules that must be included in the developer’s annual real world testing activities.” They did emphasize that real world testing should address each type of clinical setting in which a developer markets the health IT product.

“We have therefore built into our real world testing policy flexibility that offers the developer a substantial opportunity to design real world testing approaches that minimize burden and fully optimize value of the real world testing activities and results to current and prospective customers.”

“In response to the recommendation that developers be allowed to compensate their customers for participating in the developer’s real world testing activities, we note that nothing in our proposed or finalized policy under part 170 would prohibit that.”

RWT for public health criteria will be interesting. ONC states: “Variations in system configurations across different public health agencies’ infrastructures may suggest different real world testing strategies may be most appropriate, or most relevant to customers, compared to what might be the case for some other criteria within the scope of real world testing.”

The ONC has not yet released templates or much specificity about RWT plans, except to state that the plan must include the following:

  • The testing method(s)/methodology(ies), with mandatory focus on scenario- and use case-focused testing;
  • The care and practice setting(s) that will be tested, including conformance to the full scope of the certification criteria requirements, and an explanation for the health IT developer’s choice of care setting(s) to test;
  • The timeline and plans for voluntary updates to ONC-approved standards and implementation specifications that ONC has approved (Standards Version Advancement Process – SVAP);
  • A schedule of key testing milestones;
  • A description of the expected outcomes of testing;
  • At least one measurement/metric associated with the real world testing for each certification in scope; and
  • A justification for the health IT developer’s real world testing approach.

Note that the RWT plan is per-developer, per criteria, not necessarily per-product. So a developer with multiple certified products could piggy-back them onto one test plan. The RWT is meant to be “post-certification”, with the first plans due December 15, 2020 and results due 15 months later on March 15, 2022. ONC will publish the plans and results on the ONC CHPL. Any developer achieving their 2015 Edition certification prior to August 31, 2020 will be required to submit a RWT plan by the December deadline.

At DHIT, we welcome your feedback on requirements and are eager to assist with certification. Our expert consulting and bolt-on modules have paved the way for many successful EHR vendor certifications. Please contact Michelle Bond for additional information: mbond@dynamichealthit.com or 504-309-9103.