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.

BED Time at the IHE Face-to-Face meeting

It's always good when you can get an SDO to schedule some BED time on its face-to-face meeting agenda.  I think next year we may have to have profile acronyms like N-A-P and H-A-P-P-Y so we can schedule some NAP time and a HAPPY hour.

The Bed Management profile is a return to IHE roots of using HL7 Version 2.  It makes sense in this case because we are integrating systems that are already using HL7 Version 2 messages to communicate ADT messages.  The essential transactions in this profile are the admission notifications (ADT A01), pending admission (ADT A15), and patient movement messages, with a few others thrown in for completeness.

The A01 messages are used to communicate that an admission has occured.  These messages can go from the Patient Registration system to the EDIS to indicate that a patient has been assigned to an ED Bed, or from a Bed Management System to other systems to indicate that a bed has been assigned in an inpatient or observation or other setting.  A tracking system can monitor all of the messages, so as to report on bed status, perform analytics, or produce dashboard, et cetera.

Through this profile the Bed Manager is provided with critical information about the kind of bed that is or may be needed for a patient, whether or not the patient needs isolation, and the level of care (acuity) necessary for treatment.

The profile has a novel feature, the notion of a heads up message that indicates that an admission is likely, even though it is not yet ordered.  This uses the same message structure as the admission order, with a flag that allows the receiver to determine that this is a "heads up" notice rather than a formal admission order.  A provider can now indicate that it is highly likely that the patient will need a bed in a particular setting, and when it may be needed.  This allows the bed management system to project its needs better, and prioritize allocation of rooms, and ensure that adequate staff is available for patients who will be using the beds.

We finished the profile this morning, 30 minutes prior to the end of our allotted time for today, and a day early, so we voted it forward for public comment also a day early.

At the same time, we also produced a security considerations section and audit trail messages that are missing from Bed Management's cousin, the IHE Patient Administration Management (PAM) profile from IT Infrastructure.  We borrowed heavily from PAM, and the two profiles are designed to be operated with together, but we don't specifically require it.

Relevant and Pertinent meets Acute/Chronic, Active/Inactive/Resolved and Current/Historical

We held our first Relevant and Pertinent meeting in several weeks due to some scheduling challenges, which resulted in some interesting thinking about what our output is going to look like.  We've stopped focusing so much on whether a decision that something is relevant affects what is done in the send or on the receive side.  It's a judgement, an assessment, a category that can help decide how to do something innovative to make information more useful.

I think people will argue less about the result because they will be less worried about unanticipated consequences.  Making an assessment about the relevance of a thing becomes a point of information that can be acted upon within an exchange, but it need not prohibit information from being exchanged, we leave that in the hands of the users of that assessment.  In some ways, it's very much similar to how saying "this information is sensitive" helps make access control decisions.  The assessment of sensitivity can be agreed upon if we can separate that assessment from access control consequences that we might not agree with.

In drilling down into this, we came up against one of my first deep discussions on problem classifications.  I was looking at the "Problem Status" vocabulary of CCR at the time:  Active, Inactive, Chronic, Intermittent, Recurrent, Rule Out, Ruled Out, Resolved.

What a basket of stuff, crossing at least three different classification boundaries.  Since then, we have probably all come to understand acuity, activity, and temporality as being three distinct axes of classification.

An acute condition is typically active or resolved.  A chronic condition is either active, inactive (I think I prefer managed), or in some few cases, resolved.  Chronic lower back pain is something that I suffered through for about a 12 month period, but it did eventually get resolved.  Other cases (specifically dealing with chronic disease states), rarely occur, but have been known -- often due to radical intervention.

This then gets into the question of relevance.  What is relevant about my chronic lower back pain, vs. my acute lower back pain, and how could one automate distinctions.  Let me propose that the following is a true statement:

What is relevant about a condition is all data related to that condition over the history where it has been present.  The data relevant to the acute lower back pain covers the period from which the problem was discovered to when it was last active and shortly thereafter.  The same is true for the chronic lower back pain, it's just that it's "active" history might be much longer.  Now, if you link diagnosis and treatment to problems (in a problem oriented medical record), you can now determine what treatments and diagnostics are perhaps "relevant" when considering lower back pain, regardless of chronicity/acutity.

I think we'll next need to get into a discussion of current, recent and historical.  Current is thought of in the now, but is actually in the very short term past, as in just happened.  Recent is a slightly longer window, perhaps measured in the context appropriate to the situation.  When one asks what my recent immunizations are, the context is a little bit different from when was my most recent blood glucose. Both are thinking about "most recent last", but not just now events.  The time context window is different for one rather than the other.  If you wanted to know when my most recent TDAP was, you might look back 5 years before saying, "That's far enough! You need a new one," whereas for blood glucose, you might go back as far as a year.  In both cases, anything before those dates is "historical" because it doesn't matter how far back after that time frame, its relevance is about equal (time for a new one).

The locus of focus may also affect our perception of relevance.  At the time of a visit, attention is on the condition that the patient is being treated for, the chief complaint or reason for visit.  For another whose attention is on that visit (locus), their attention (focus) may be elsewhere.  In communicating forward in time we usually assume that our focus will match that of the receiver, and so would determine relevance based on that focus.   We often discover that what appeared to be inconsequential then is more important now.

We have no way to predict the future, which results in the fear that a determination of relevance could prevent something that could/should have been communicated.  If, however, we can, as I would, put a protective force bubble around "what to do with the determination" as being subject to use-case appropriate judgement, we might come to dramatic consensus on what is "relevant" as best we are able to determine.


    Keith

A PubMed for HealthIT Standards - A Preview

I'm in meetings today in DC to talk with ONC, who has convened representatives from Health IT Vendors, provider organizations, and SDOs to talk about how to support feedback on standards. About two weeks I was asked to talk briefly about the project.  I went one better and gave a demo.

It took some doing, and the last skeletal pages of my demo came together last night, and were checked in this morning around 4:30am.  It's still really rough, but you can see how it is coming together as a work in progress here.

Please note, this would probably considered a gamma release, not even of beta quality.  I welcome feedback in comments below, and will at some point create a more formal way to provide feedback and comments and hook it in to the site.  Until then, understand, this is something to play with, don't expect it to be up 24-7, or count on it for anything important.  Things may go down for days while I build it out.

Save the bug reports until I get that implemented from the site (so you can report them where they occur), right now I know there's stuff that doesn't work. Think of this as a sprint review, rather than a release.

   Keith