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.

Friday, April 29, 2016

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: Creative Commons License
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.



Wednesday, April 27, 2016

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.


Thursday, April 14, 2016

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

Friday, April 8, 2016

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

Friday, March 25, 2016

I really think we should ... Oh look, squirrel

So the question came up last working group meeting about whether to pursue use of the FHIR StructureDefinition as a mechanism to capture CDA Templates in some meeting somewhere.  I wasn't at that meeting or I would have shown my distaste for the idea then.  Grahame's been playing with StructureDefinition and has demonstrated quite successfully I think that he can use it to represent models for everything from HL7 Version 3, CDA (being a version 3 derived spec, that should be no surprise), to I would guess, V2, X12 and even arbitrary XML schema and other models provided they follow a few fairly simple rules.

Thus, I introduce to you the squirrel in question.  It's a cute squirrel, and even a rather powerful one.

Why do we need this?  We have a perfectly good standard for representing CDA templates if we would just use it in the tools HL7 presently uses to publish so much of its own documentation in.

But it isn't FHIR related, and loses to the flavor of the month (year? decade?) I think.  I suspect chasing this squirrel will only distract any further work on something else that might benefit the HL7 community at large ... for example, liberating CDA Templates from Trifolia in a standard format.

The only benefit I see to this distraction may have is to keep people tied up in a harmless activity, at least for anyone but the squirrel.  But I think StructureDefinition will survive that race.

   Keith

Wednesday, March 23, 2016

Pilot Error

Tails of failure often involve a sequence of multiple errors, each of which by itself is not fatal (or in this case, vaguely comedic), but which together produce a totality that is hard to fathom.  I was reminded of this today when I went to register for the last class I need to complete my degree program, only to find out that it is on-campus only.

  1. I've been checking for the last three terms that I knew what I needed, AND
  2. Knowing also that scheduling can sometimes change, I did my best to get as much out of the way as I could up front, AND
  3. seeing that I had one dependency I couldn't meet last term, I checked with the instructor to be sure that the class was to be offered this term, AND 
  4. received confirmation ...

BUT,

  1. I failed to check that it was going to be available online, AND
  2. The syllabus I read was out of date, AND 
  3. I failed to notice that the syllabus was out of date, AND 
  4. I missed the wee bit in the course catalog noting it was offered online only in odd years.
I have two hopes left... I'm wrong, or I can do something else. And, no matter which happens, no babies die if I don't graduate the same year as my eldest, so I'll live either way, and still graduate, just a little bit later than I wanted to.

Gah, Pilot error.  Or in other words, the person most responsible for making sure things lined up the way they were supposed to failed to accomplish that, in part by failing to note other errors or discrepancies in data available.  In this case, I'm the pilot, and guess what, I'm human too.

In healthcare, we often rely on the physician to be the pilot ... but she or he is only human as well, and on a bad day is likely only to perform as well as the systems and people that surround him or her. Design for humanity ... design for error, and the world will be a better place.

   -- Keith



Saturday, March 19, 2016

Thinking?

The title  of this post is a response to a question in my household when someone says "What were you thinking?" when after due consideration the recipient realizes, Oh yeah, that was probably not so smart.

It's the question I had on receipt of a "secure email" the other day, coming from a healthcare institution.  I won't name the institution because the solution is a commercial one from crafted by an Internet security provider (Proofpoint) that apparently thinks it is a good idea.  Let me explain how it works to you:

When someone sends an e-mail that this software thinks needs to be protected, the software takes the body of the e-mail, encrypts it in some form, base-64 encodes the content of an e-mail into an XML payload, then base-64 encodes that into an HTML form.  It then sends that HTML page in an e-mail as an attachment to the original recipient.  In the body of the e-mail is an official looking page containing the sender logo, a lock icon, and text which explains that you have received a secure e-mail and that in order to access it, you either need to open the attachment, or click on a link.

I'd love to do a video that shows how this system works, and compare it to a phishing attack.

Consider that you have just received an e-mail that appears to be from an institution that you have a relationship with.  It looks official, and bears the correct logo [highlight the institution logo on both the phishing and secure e-mail].  When you click on the "more information" link, it clearly goes the institution's web site, which you can quite readily verify.  The email asks you to Open the attached file to obtain your secure message.  Feeling secured by all that you have done to ensure you security, you now open the attachment.  Once again, it looks very good and official, bears the right logos, and even bears a copyright from a trusted security provider.  It asks you to click a button to retrieve your message.

You do so.  At this stage you are now taken to an HTTPS page on the web which has a long URL which looks right on quick glance, and that asks you, since this is your first time to create a user name and password to access your message.  So far, both systems appear to work in nearly the same way.  So, you create your account.

One of these systems will then decrypt the packet sent to you and the other will send your username and password to pirate bay, where someone will then drain all your bank accounts.

The question is, should you open this attachment?  The answer in both cases is, for most people.  Hell no.

  1. You don't have the training to distinguish the attached file (which may contain a zero day exploit) from any other attached file which could infect your computer.
  2. You shouldn't expose your password management procedures to others whose security you cannot verify.  Many of you have pretty poor ones to begin with (like I use the same username and password for everything).
  3. Any of the italicized items in the scenario above are things that ANY competent software engineer or hacker can do.  In fact, if it can be done, a hacker doesn't need to do it him or herself, they can very likely simply steal it.
Why does an internet security provider believe that encouraging people to engage in behavior that security experts advise against, and other security products protect against, would be a good idea? Well, that goes back to another common response in my family to the "What were you thinking?" question:

It seemed like a good idea at the time?

-- Keith

P.S.  When I first saw this message, I actually thought it had originated from my corporate security folks, who craft similar messages in order to encourage people to take their phishing refresher class, an honor I have thus far managed to safely avoid (it's the reward for clicking on an attachment or link in their generated e-mails).  Yes, I get phished internally as training on what to avoid.