ONC Health IT Certification Program - Updated Test Procedures and Companion Guides - 05Aug16
For the week ending August 06, 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
Summary of Change:
Clarified that health IT system under test must be able to record at least two race and ethnicities via the CDC race and ethnicity code set and then aggregate them to the core OMB race and ethnicity categories.
Impact and Commentary:
Minor. While this update does not change the requirements of 2015 Edition Final Rule, this is a good update as the previous version of the test procedure was misleading in its requirements. In prior version 1.1, it did not clearly present this aggregation of individual race to the five core OMB race standards (e.g., record race of “Chinese” which is mapped to “Asian”). This is beneficial as this aspect is new to the demographics functionality because of the 2015 Edition Final Rule. Clarifying recording multiple races is good although that requirement was already present in previous 2014 Edition so it should not be new to either developers or clinicians.
Summary of Change:
Changed the receiving protocols choices of IMAP and POP3 from “Optional” to “Alternative”. Also removed the link to the now deprecated Transport Testing Tool.
Impact and Commentary:
Moderate. There have been many JIRA support tickets with ONC on this issue and general confusion of what is allowed as alternatives and what is optional. To appreciate this change, you have to understand in ONC’s terms how a standard or criteria is listed as “optional” or “alternative”.
“Optional” basically means “not required but can be done as long as other required features have been met”. However, “alternative” is a stronger level of choice. To be “alternative”, you must have at least two or more standards or functional aspects presented side-by-side so to speak, and one of those “alternatives” MUST be chosen. For example:
Standards for Criterion X:
Standard A (alternative)
Standard B (alternative)
Standard C (optional)
Standard D (optional)
System MUST either implement Standard A or Standard B (or both). Both Standard A and Standard B are equally valid, but one of them must be chosen. System is always allowed to implement multiple alternative standards if desired.
After that requirement is met, system could choose to implement optional Standard C or Standard D or neither. However, what is NOT allowed is system implementing Standard C or Standard D but NOT first implementing either Standard A or Standard B.
Coming back to 315.b.1 test procedure, it previously listed IMAP and POP3 as “optional” choices for the health IT system (typically an EHR) in receiving messages from a HISP via the Direct Edge exchange. This meant that the health IT system had to support either IHE XDR or SMTP for receiving as they were the only alternatives. Once that implementation of alternatives was met, the system could elect to also support IMAP or POP3.
With this change, it makes IMAP and POP3 on equal standing with IHE XDR or SMTP in terms of how a health IT system (EHR) can receive messages from its HISP.
How does this impact EHR developers? If a developer of a health IT system (seeking to be certified in 315.b.1) was already in their development roadmap working on supporting either IHE XDR or SMTP, this does not negatively impact your roadmap or plans as both choices are still valid. Just continue with your current direction.
However, for developers who had not yet started on 315.b.1 Edge exchange capabilities, this does open some doors in terms of different options. If developers have an existing relationship with a HISP or HIE, they should discuss these choices with their HISP or HIE to determine which of these alternatives best works for their relationship.
COMPANION GUIDES
No updates this week.
TEST TOOLS
Summary of Change:
Minor update to new version 1.2.6. Release notes are here.
Impact and Commentary:
Minor. Corrections on minor bugs. Also made changes to allow an account to be made to save Transport and Validation settings for utilizing the Surescripts REST-based transport. This is a helpful change as it is strongly encouraged that developers utilize the Surescripts REST transport interface which greatly expedites testing over cut and paste efforts of individual messages.
