• Kyle Meadors

ONC Health IT Certification Program - Updated Test Procedures and Companion Guides - 29Jul16


For the week ending July 29, 2016, ONC updated the following test procedure, companion guides, test tools and other aspects related to their 2015 Edition testing program. Links to documents or relevant release emails are include below as appropriate. Summary of changes and commentary of potential impact to developers as determined by Chart Lux staff are included.

TEST PROCEDURE

§ 170.315(g)(3): Safety-enhanced design

Summary of Change:

Added a link to the CHPL SED Guide, primarily needed for ONC-ACBs in submission of results to the ONC CHPL.

Impact and Commentary:

Minor. The CHPL SED Guide is critically important to ONC-ACBs to accurately report results of usability testing to the ONC CHPL. With the new CHPL, detailed usability results are report to the CHPL rather than only being within a PDF report which ultimately allows them to be searched or accessed at a granular level. This SED Guide identifies the required fields and their allowable values/formats.

The ONC-ACB should offer a spreadsheet template for the developer to complete to fill in the results of their usability testing, and this spreadsheet will be used to upload results to the ONC CHPL. Hopefully the spreadsheet will include some degree of value checking to ensure developer properly enters necessary results. Developers should check with the ONC-ACB to see what material they have available, and that material is likely of more value than this CHPL SED Guide to a developer.

However, it is of some value that the developer at least aware of this guide and potentially refer to it if developer has some questions entering results into the ONC-ACB spreadsheet.

COMPANION GUIDES

§ 170.315(d)(6): Emergency access

Summary of Change:

Clarification to the scope of emergency access. Specifically, these two points were added.

  • Emergency access is intended to cover a broad range of scenarios, including life threatening emergencies related to the patient as well as normal patient care where timely access to electronic health information becomes critical. [see also 75 FR 44617].

  • Emergency access is part of a Health IT' Module's general access control and should be established before the emergency, potentially as a “pre-set” function. [see also 75 FR 44617] The goal of the capability is to ensure that there is a way for identified users to have access (e.g., by elevating their access privileges) in an emergency to gain or maintain access to patient health information, which should be an auditable event. [see also 80 FR 62655] In sum, the "emergency access" functionality should be demonstrated based on the access rules already built into the Health IT Module.

Impact and Commentary:

Moderate. This criterion has been unchanged since the initial 2011 Edition certification. However, details of how exactly to satisfy emergency access capabilities has always been a little nebulous, and this updates helps clarify in one key way. It describes emergency access as more of a “break the glass” functionality that is pre-set, and can be accessed by limited users on demand.

While “break the glass” was a common way of implementing this criterion since its beginning, this clarification rules out the approach of allowing an admin to go in and change a user’s rights to “emergency access” which typically cannot be done in time to meet real-world emergency needs. Instead, the feature must be configured in advance for at least certain users to access on demand. This access is then record in the audit log.

While most systems already implemented emergency access this way, some did not and would need to make changes to align with this interpretation.

If developers are unsure if their current approach meets the ONC clarification, feel free to contact us here at Chart Lux to discuss your specific method and ways to satisfy it.

§ 170.315(e)(1): View, download, and transmit to 3rd party

Summary of Change:

Provided clarification on the timeframe selection requirement adding this points.

Timeframes

  • This criterion has two timeframe filters that patients must be able to select and configure on their own (specific date and date range). We did not include the ability to select a specific data element category as part of this filtering requirement.

Data Requirements.

  • Paragraph (e)(1)(i)(D) and its subsequent subparagraphs focus on "data." The scope of the information to be included in the timeframe selection for paragraphs (e)(i)(A),(B), and (C) is focused on the data as laid out in (e)(1)(A)(1) through (5), which is more than just the Common Clinical Data Set.

  • All referenced data in the specified range of the timeframe selection must be returned regardless of whether the data is contained in a C-CDA document or in an atomic form and parsed.

  • Returning all data all the time regardless of a date selection or date range selection is non-conformant insofar as the technology is not demonstrating filtering by date range. The health IT developer must be able to demonstrate that filtering based on the two timeframes can be done properly.

  • Filtering in terms of excluding certain data must be by timeframe pursuant to the two filtering functionalities.

  • We expect that the Health IT Module must be able to send, at a minimum, all required data for a specified date range(s). We acknowledge that there will be organizational policies and/or safety best practices that will dictate additional data to be sent and when data is considered complete and/or ready for being sent.

Approach

  • An approach based on providing previously received C-CDA documents matching to the patient’s date or date range selection that the patient could then view, download, or transmit in their original form is a valid approach. The decomposing, extracting, and recomposing of the data from the individual C-CDA documents is not required for certification. However, such practice would have the positive effect of making discrete data available to the patient upon request.

  • Health IT must separately demonstrate compliance with paragraphs (e)(1)(i)(B)(3) and (e)(1)(i)(C)(2) if this criterion. However, the data requirements of paragraph (e)(1)(i)(D) do not apply to “supplied” transition of care/referral summaries referenced in these paragraphs.

Impact and Commentary:

Moderate. This is very helpful clarification from ONC on a confusing aspect of the criterion. What is helpful is that is works well with one of the most common method for portals to obtain patient information which is through receiving a CCDA file from their EHR. With this clarification, ONC explicitly states it does NOT expect the portal or VDT system to filter on specific data elements within the CCDA but instead just reference the CCDA itself (although ONC does state granular filtering/displaying would be of value to the patient).

While the clarification is helpful, ONC does emphasize that some filtering of data must be done. Thus, always returning all data in the record all the time regardless of timeframe filter request is not complaint.

TEST TOOLS

ePrescribing

Summary of Change:

Minor update to new version 1.2.5. Release notes are here.

Impact and Commentary:

Minor. Just corrections on minor bugs, such as inaccurate medication codes and validation functions.

Edge Test Tool

Summary of Change:

ONC announced plans to begin transitioning the ETT to their “Transport Testing Platform” or “TTP”.

Impact and Commentary:

Minor. This is more about where the tool will be hosted rather than a change to the tool itself so it not an impact to a development timeline for certification. However, if developers do not already have it bookmarked, they should bookmark https://sitenv.org. It is where they will host all of their transport protocols and API-based interoperability activities. Virtually all ONC test tools will eventually flow through this site or at least be linked from it.

CQMs/Cypress

Summary of Change:

The CQM test tool for 2015 Edition is now officially release. Cypress vs 3.0 is now available for 2015 Edition certification testing. It supports the CMS yearly updates of CQMs from years 2015 and 2016.

Impact and Commentary:

MAJOR. With the release of Cypress vs 3.0, developers can now officially test CQMs for 2015 Edition certification. Any developer who plans to certify on CQMs should plan on being familiar with this test tool as it is essential for certification.

#testtools #updates #2015Edition #testprocedures #companionguides #ONC

© 2016 Chart Lux Consulting, LLC