Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Wednesday, March 25, 2015

Remaining 2015 Certification Criteria

I've finished looking at the certification criteria, but still have about 150 pages of more reading until I'm done with the ONC Certification Rule.

Here's what I've found in the remaining criteria:

Public Health

All the standards have been updated to more recent versions.  This shouldn't be a huge shift, but I suspect the new Immunizations guide will have some new capabilities that you want to look at.  They dropped the "Cancer Case" certification criteria from the 2014 edition in favor of a separate case reporting guide based on the IHE Structured Data Capture Work.  But for that, ONC also wants to know if we should use FHIR.  I think timetables dominate here.

The HL7 Healthcare Associated Infection Reports (you might remember this as "Hospital Acquired Infections" if you are a) old enough, and b) politically insensitive) now have a home in a criterion designed to capture information about antimicrobial use and resistance.  These specifications and this project has been around in HL7 for quite some time.

They've also added a criterion to support transmission of electronic survey data to public health using the HL7 National Health Care Surveys implementation guide.

Design and Performance

In design and performance, gratefully, numerator and denominator recording remain unchanged. 

Safety Enhanced Design (SED) gets a big makeover.  They added Demographics, Vitals Signs, Problem List, Implanted Device List, Decision Support Knowledge Artifact and Service, and Incorporation of Lab Tests and Results into the original list of ten items requiring SED.  Rather than summarize the set of changes, let me just tell you to read this section closely.

On the use of a Quality Management System, this is the pertinent quote:
For the 2015 Edition QMS criterion, we are taking that next step by not permitting health IT to be certified that has not been subject to a QMS and also requiring health IT developers to either use a recognized QMS or illustrate how the QMS they used maps to one or more QMS established by the federal government or a standards developing organization(s) (SDOs)
Basically, this means get on board with QMS.  You could get away without one previously, but now they are serious, and if you've rolled your own, you will have some work ahead of you to map to the standards.

Accessibility: There's been a push to make sure that not only is data accessible to patients in an accessible fashion, but also that the design of  EHR systems takes into account accessibility requirements for providers.  This is another section where you will want to look closely, and have your User Centered Design (UCD) folks look over your shoulder (or you over theirs).  If you don't have any UCD folks on staff, be worried.  [I'm still maintaining an A.E. Neuman pose on this section].  There's also a push to document all accessibility standards or laws that the Health IT module conforms to.  The list of standards and laws here seems like overkill ...

C-CDA testing will be toughening up (and its about time).  I think the certification criteria is a bit overboard in this area, because a lot of what they describe could be addressed in a sub-regulatory fashion in how they test C-CDA creation and display.

Application access to the common clinical data set is a huge addition in this rule.  This is the API criterion, which functionally describes what the API should do.  The closest standard we have for this is FHIR, which is where I expect this to go eventually, but ONC clearly heard that it wasn't ready yet [even though they've mentioned at least five standards that are still in the making in this rule so far]. I'm sure most EHR systems have this capability, the question is whether they want to expose it quite so far as is required by ONC.  Some of the documentation that EHR vendors have they consider to be trade secret, released only to customers under an NDA.  That situation seems likely to change if the rule goes through as currently written.  It is an interesting consideration, because elsewhere in IT, the situation is remarkably similar to the current situation in Health IT, that product APIs are often only released to licensed users of the product.

Transport Protocols

There's not much new here, although with Direct they'd like to add an Implementation Guide on Delivery Notification.  There's a bit of rework on the Edge protocols around XDR/XDM, regarding support for XDM.  The SOAP transports remain unchanged [I might guess that their maturity is showing ;-)].  On the new side, there's HPD with a separate request and response criteria, optionally utilizing Federation.


This is another new one, and frankly, a bit of a mess.  There are three separate capabilities required for signatures (are these guys signature happy or what? ... what else would you expect from auditors). There's an additional set of C-CDA templates also required supporting what is effectively attachments, although that specification has certainly received mixed reviews from the HL7 Attachments workgroup during its development.  This one needs a careful look, because maybe there will soon be an attachments rule, and my guess is that it would reference this NPRM, if it ever sees the light of day (after 15 years of waiting, I have reason to be dubious).

Thus ends my review of the criteria, there's still some 150 pages left, including the actual rule text itself.  Once I finish that, I'll have another spreadsheet to share, and then on to the Penalties rule.

   -- Keith


Post a Comment