The 2015 Edition Certification and Standards Rule

TOPICS:

Posted By: Industry Expert October 20, 2015

Keith BooneBy Keith Boone, Healthcare Standards
Twitter: @motorcycle_guy

In case you’ve been in a cave (or at an HL7 working group meeting) and haven’t heard, the Meaningful Use Incentives and 2015 Standards and Certification rules dropped on October 1st. I already had a lot on my plate yester-eve, so my Twitter review didn’t start until about 10:30pm (much to the chagrin of of some folks).

Overall, I think this final rule is a win-win. One of the big changes I was very happy to see was the change from C-CDA 2.0 to the new C-CDA 2.1 that HL7 members developed in response to the proposed rule in record time (see my posts on that story). I got some very complimentary feedback on my work and that of Bret Marquard on that project, and I want to thank him again for his tremendous efforts in making that happen.

What follows below is essentially an edit of that twitter feed in case you weren’t up til 2:00am reading the rule like I was.

First, skip to page 5 (skip the background drivel). Starting there you will find an overview of what is in the rule. Highlights include:

  1. Updated standards and vocabulary for the new common clinical data set (CCDS).
  2. A functionally defined API (ONC is headed towards, but did not name FHIR) for access to CCDS content. Most of the industry is moving towards FHIR here.
  3. A shift from EHR focus to Health IT focus.
  4. Capture of sensitive health disparity data was retained, and includes not just gender, race and ethnicity, but also sexual identity, and social, psychological and behavioral data elements.
  5. A continued emphasis on privacy and security.
  6. More attention to user-centered design.
  7. Support for better patient matching (but not as severe as orginally proposed),
  8. About 4-5% of the document is devoted to implanted medical device identification, a very hot topic.
  9. It claims to provide more flexibility and time, and I certainly see some of the flexibility in this rule, but have to look at the incentives rule to answer more about “Time”.

A few other notes from the Executive Summary:

  • The API must support a query of any individual data item in the CCDS, as well as all at once (p7).
  • It introduces new C-CDA requirements to improve reliability.
  • It updates the 2014 Base EHR to add smoking status demographics, includes the API and implantable device list requirements.
  • Much of the incentive based material, such as definition of Certified EHR Technology, CQM requirements and meaningful use measurement requirements have moved to the Incentive rule, rather than the 2015 edition rule.
  • ONC estimates the total industry cost estimated at $330M +/- $70M (p15), and I might remind you that HITECH came out of an economic recovery bill.

Skip the next ten or so pages (history of past regulation isn’t that useful for most) to start again at page 26.

Not Adopted and Unchanged Material
Proposed criteria NOT adopted includes:

LOINC coding of Vital Signs, Family History using HL7 Pedigree standards, patient list, EMAR, Clinical Decision Support Knowledge Artifact and Service standards, Accessibility technology, Healthcare Provider Directory (HPD), and Electronic Submission of Medical Documents (esMD).

Criteria that is essentially unchanged includes:

CPOE for Meds, Labs and Imaging; drug and allergy checking, drug formulary checks, meds and allergy lists, smoking status, transmission of reportable lab results, privacy and security criteria regarding: Authentication, Access Control, Authorization, and Audit. Also amendments, automatic access time out, provision for emergency access, encryption of data on end-user devices, and accounting for disclosures.

New and Revised:

Pages 29-30 contain a good table describing the previous as well as new and revised stuff, I just wish this material was available not just in a machine and human readable format (PDF), but also a computable one like IETF RFC-4180.  I’m hoping ONC will do that as they have in the past.  For the most part, the remainder of this post addresses the new and revised material, and in some cases, the not adopted material.

Page 34 is simply a one page excuse for lack of use of consensus standards when they applied Direct. I’m grateful for this recognition that Direct falls into that category, and never became a standard even though that was the original intent.

Vocabulary
One vocabulary, they kept the provisions on use of NDC Vaccine codes��, as is CDC Race and Ethnicity ��. One of the big changes the latter introduces is that the EHR must now support capture of multiple ethnicities, something that is not required by OMB, nor was required or supported previously in C-CDA. We can address that latter need through an extension created for this purpose by structured documents. ONC and NIST can address how multiple ethnicities can be used in a sub-regulatory way. As this follows the pattern necessary for multiple race, I foresee no difficulties with applying that process.

There’s a useful table of vocabulary OIDs used in Meaningful Use on page 39 (note, that’s a useful table of OIDs, not a table of useful OIDs).

Psycho-social Data Capture
On the psycho-social front, I noted that gender identity value set includes Male, Female, trans (male/female), genderqueer, and other categories. My kids can tell you that this is a very limited set, but it at least begins the recognition that gender identity is an issue associated with treatment disparities. Elsewhere on the psycho-social-behavioral data capture front, the EHR needs to support it, even though the physician (under stage 3) is not required to use that capability.

Discussion of device identifiers takes up 1/25 (approximately) of the rule text. The short summary is that yes, you have to store and parse them, but FDA can help.

C-CDA
On C-CDA, you’ll have to support read of both 1.1 and 2.1 releases, and output 2.1 content that is backwards compatible with 1.1. They did limit the requirements to support only the CCD, Referral Note and in the case of inpatient settings, the discharge summary. Furthermore, systems must be able to support validation and error checking on both releases on import/incorporate/display. A gold standard sample document is being prepared to a) show implementers how things should be done, and b) ensure that they can produce something like that. On the topic of relevant and pertinent content, they remind us that providers can decide what to include, but the EHR must have the ability to send all content. To further support relevant and pertinent, they also require the EHR to have the ability to support display of only a particular section (or sections), set user preferences for display order, and to set the number of initial sections to display. Note, creating and receiving a C-CDA document are now separate meaningful criteria, which makes it quite nice for folks who are developing systems that just generate the C-CDA to be integrated with others that handle the transmit/receive capabilities.

Patient Matching
Some of the Patient matching requirements remained in the rule, but the CAQH Core rules were not adopted for a variety of good reasons (mostly having to do with the fact that this normalization is done at the receiver side). C-CDA does support the needs here.

They did note a challenge in that prior address is not explicitly called out in C-CDA, nor is usable period. However, I will note that since C-CDA is based upon CDA, and those capabilities are still present, just not specifically called out in C-CDA (nor where they in CCD). So, they can still be used to identify historical data.

Data Provenance and Data Segmentation for Privacy
Capturing and recording Data Provenance using the HL7 DPROV was suggested, but has been dropped from the final rule, essentially as not being ready for prime time (my words, not theirs). The provisions for Data Segmentation for Privacy (DS4P) have been included, but are not required for the incentive rule or the base EHR capability, so DS4P is essentially optional.

Reconciliation

I’m still crying inside that ONC essentially adopts the IHE requirements its RECON profile for incorporation of data, but does not name it.

ePrescribing includes 10 NCPD transactions, including history, but does not require NCPDP structured sig as it is deemed to be a bit immature.

Patient Access
A number of changes to VDT and other patient access requirements really made my day. View, Download and Transmit are expected to support imaging reports and lab results. One of the new requirements on transmit is that an EHR must support transmit not just to a Direct address, but also to any e-mail address (unencrypted). Patients, under current HIPAA regulations, may presently ask that data be disclosed to them via unencrypted email, although that provision is little known. After a provider has a certified EHR product (to the 2015 edition criteria), docs won’t be able to use the excuse that “we don’t have that capability” when a patient requests it. If they do, I imagine this page might get more hits (although it needs to be made clear that access falls under privacy and security).

The API requirements are also noted as being able to support patient access criteria.

API
API requirements have been split up into three separate pieces. While FHIR was mentioned several times in the rule, it was not named for API requirements. As ONC states a couple of times: “we decline to recommend a specific standard at this time, although we intend to do so in a future.”

That last statement is a big hint to everyone. While Meaningful Use may go away, Certification seems to be here to stay.

This article was originally published on Healthcare Standards and is republished here with permission.