Partial Rejection and Levels of Validity in CDA (or anything else for that matter)

One of the things that I learned in my Informatics education was that there were many different ways to evaluate validity of something.  It's not a yes/no question, but rather a multi-faceted scale.  Most informaticists are familiarity with a 5 or even 7 point scale used to evaluate quality of evidence.  This is essentially the same idea.

In a recent Structured Documents discussion, the topic of what it means to "reject" an "invalid" CDA document was discussed.  When you look at these terms, they seem like yes/no, binary decisions. But here is how you can turn this into shades of gray:

Level 0: Totally bogus content.  Is this even XML?
Level 1: The CDA Header is valid.
Level 2a: Level 1 + the narrative content is valid according to the CDA Schema
Level 2b: Level 2 + the LOINC codes for documents and sections are recognized as valid.
Level 3a: Level 2 + the entries are schema valid according to CDA.
Level 3b: Level 3a + the codes are recognized.

Here's how a system can respond after making these assessments (note that possibly available actions at higher level include those at the level below):

Level 3b: Discrete data can be imported into the system.

Level 3a: Some data can be coded based on string matching, and for that data which has matching codes, that data can be imported into the system after validation by a healthcare provider.
Level 2b: Narrative only sections (such as Reason for Visit or HPI) can be imported, but no discrete data.
Level 2a: After performing some simple pattern matching, some narrative only sections can be imported, after validation by a healthcare provider.  The document can safely be displayed to the end user.

Level 1: The CDA Header is valid.  The fact that a document has been received for a patient from a particular organization can be displayed to the end user.
Level 0: You might be able to look at some magic numbers in the data to figure out what the heck someone sent you, but there's no way to even assess what patient it was for unless you have that stored in some other metadata (thus Direct+XDM evolves as a good solution for sending files).  You might be able to figure out an appropriate viewer for the content, but even then, there are no guarantees it is safe.

Validity?  It's not a switch.  It's a dial.  And mine goes to 11.  Rejection? That's just a pre-amp filter.

Connecting the Dots: MIPS & MACRA, 2015 Certification Edition and HIPAA Omnibus

This is definitely one of those cases that most people will likely miss unless it is explicitly called out, so here I go.

Within the recently released MIPS/MACRA proposed regulations (which I call NuMu for reasons that should be readily apparent), CMS indicates that the legislation (law not regulation!) says:

To prevent actions that block the exchange of information, section 106(b)(2)(A) of the MACRA amended section 1848(o)(2)(A)(ii) of the Act to require that, to be a meaningful EHR user, an EP must demonstrate that he or she has not knowingly and willfully taken action (such as to disable functionality) to limit or restrict the compatibility or interoperability of certified EHR technology. Section 106(b)(2)(B) of MACRA made corresponding amendments to section 1886(n)(3)(A)(ii) of the Act for eligible hospitals and, by extension, under section 1814(l)(3) of the Act for CAHs. Sections 106(b)(2)(A) and (B) of the MACRA provide that the manner of this demonstration is to be through a process specified by the Secretary, such as the use of an attestation.

The 2015 Edition Certification rule requires that Health IT supporting the View, Download or Transmit capability must:

(C) Transmit to third party. Patients (and their authorized representatives) must be able to:Show citation box

(1) Transmit the ambulatory summary or inpatient summary (as applicable to the health IT setting for which certification is requested) created in paragraph (e)(1)(i)(B)(2) of this section in accordance with both of the following ways:

(i) Email transmission to any email address; and

And finally the HIPAA Omnibus rule suggests that patients may request e-mail transmission of the records they request.  See OCR guidance here.

As a result, a common case that occurs when I have requested e-mail transmission of my HCP saying, we aren't set up to do that nearly disappears after they adopt 2015 technology.  After all, the technology has to support direct e-mail to any e-mail address, and the provider cannot knowingly or willfully take any action to disable that capability.

Even if the MACRA/MIPS regulation changes, that doesn't matter, because what I've highlighted above is IN LAW, not regulation, and the other regulations I've referenced are final.

So, if your provider tells you that they aren't set up for that, you might need to connect the dots for them.  Ask them if they are using 2015 certified product (which will become possible for many starting in 2017, and much more common in 2018), then reference the legislation above, the 2015 certification requirements, and the HIPAA Omnibus requirements.

This is NOW an existing part of public policy, and my head just exploded as I realized its ramifications for patients in 2017 and beyond.

   Keith

P.S. This POST: 
Connecting the Dots: MIPS & MACRA, 2015 Certification Edition and HIPAA Omnibus by Keith W. Boone is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at http://motorcycleguy.blogspot.com/2016/04/connecting-dots-mips-macra-2015.html.

The 2015 Edition Certification and Standards Rule

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 yesterday.  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.

   -- Keith

---

P.S. The first draft of the bookmarked final rule can be found here, thanks again to Corey Spears. This is just as much as he could get bookmarked so far, expect updates.
P.P.S. You can find the changed tracked regulatory text here.  I extracted (using Acrobat) the proposed and final regs from the PDF into Word, and then applied Word's document comparison to get the edits.  Your mileage from this process may vary.
P.P.P.S. ONC's presentation from today is here.