The ABBI Hour (or two)

I've spent the last couple of days at the ONC Annual Meeting.  Yesterday morning was filled with a joint session between the Beacons and S&I Framework folk.  The afternoon was an S&I Framework Round Table, followed by the ABBI Town Hall Meeting.  I covered the morning session in yesterday's post.  I'm not going to cover the S&I Framework Round Table since it was basically a report out from the various S&I Projects, and either you care and already know, or you aren't that interested.  What I will cover today (as promised) is what we talked about in the ABBI Town Hall meeting.

First of all, I'm not sure what the difference is between the "Round Table" and "Town Hall" meeting format.  I think they just pulled these names out of a hat.  The ABBI Meeting certainly had the flavor of "Town Meeting" though, especially if you'd had any experience with that form of government.

Farzad Mostashari kicked off the ABBI Town Hall meeting with a rather personal story.  [FYI: Everything I'm telling you here Farzad cleared with his parents, and was also stated in public in a room full of 1300 people this morning].

It starts with this tweet from Presidential Fellow Henry Wie MD (which Farzad retweeted) just before Thanksgiving:

RT @henryweimd: On T-day, show older family how to get their Blue Button health data; eg myMedicare.gov Could save their life someday
— claudiawilliams (@claudiawilliams) November 21, 2012

And he did sign up his father and mother on Turkey day.  Then he looked at the nearly unreadable text, and decided that he needed to get them hooked in with an App that would make sense of that. So he downloaded the winning app from the Blue Button Mashup Challenge (from ABBI committed participant Humetrix).  He had to e-mail some folks at the company to resolve an issue, but got it worked out (all on T-day).

The next day, his father complains about serious eye pain.  Great, he thinks.  This is going to be a miserable Thanksgiving Holiday.  He and his parents are going to spend half the day or more at an ED in a hospital, that doesn't have an Opthamologist on call, and with no access to provider records from physicians in their home state (MA).  But, now Farzad can look at the diagnosis code that the physician provided for a previous procedure on his father's eye, or even better yet, look it up on the Internet.

As it turns out, he winds up finding an Opthamolagist who can see his father the same day using another App.  And his father, upon being asked for the history of this problem, can hand the Doctor his cell phone and say, here it is.

OK.  If you thought Farzad was over the top about the value of Blue Button before, you should see him prance about now.  There is nothing like a personal story that will make it hit home.  I've been through this hassle (One of the stories on my jacket is about the 3 extra days spent in the hospital, uselessly waiting on data that wasn't available until Monday morning).  Guess the date.  Yep, my step-father also went into the hospital the day after Thanksgiving when he was visiting me.

Farzad wondered why his parents medicines weren't also in the CMS download data, but then realized that they weren't enrolled in Part D.  So, he made sure to enroll them in that as well.

This kind of solution is what ABBI is about.  But better than a file of text that has to be parsed out, ABBI will use the same standards that are in Meaningful Use.

Next up was Ryan Panchadsaram (Presidential Fellow), to discuss some of what we've accomplished in the project thus far.

There are three aspects of ABBI: Liberation of data, fidelity of data (through structured content), and automation of access.  The last part has been described as the "set it and forget it" feature.

There are two different forms of ABBI that we've been working on: PUSH, enabling providers to transmit to patients using Direct (not hitting a meaningful use goal unless you count push to a patient as a download), and PULL, enabling patients to view or download the content (either counting towards patient engagement metrics in MU Stage 2).

Ryan started off with a shout out to me on some of the work I've been doing here.  Then he described some of the accomplishments of the four workgroups: Content, Push, Pull, and Payer (which I'll get into in a moment).  In describing how I've been working on the Document Bits, Ryan stumbled and it came out "Documents Bitch".  Which led to this tweet.  I embrace it.  Yes.  most of my standards work has been about documents for the last decade (and more).  And I embraced Ryan as the room burst into laughter.

Following Ryan (and that was difficult at this point), was Henry Wei, also a Presidential Fellow working on the project.  He was up to the task though, reminding all that we record the calls, and that it is a good idea to go on mute before using certain facilities.  That gained another brief bit of laughter, and we got back to the meeting.

Henry's been keeping up with the payer group, who have been working diligently to develop a standard to enable patients to get access to cost data, which could be a real game changer for cost transparency.  While they are pretty much all-in on developing the standard, there is a great deal of concern that they won't be so keen on sharing it (I'd make the point to them, that to win the pot, you have to show your cards).  Will they be brave enough?  That's a good question, but I think some of them get it, and will.

On the standards, at least one participant has been pushing the payer community to something like a JSON representation of the 835.  They are calling this 835ish.  I like the name, but will have to see how the results come out.  I could probably automate the representation based on the X12 standard content (oh joy, more PDF scraping), but I think I'll let the payer community work that out.

So now we get to the real fun part, which was where the meeting definitely felt like a town meeting.  

We were given three questions to address:

For Push, the question was stated something like: How do we figure out what Direct addresses to white list?

I was aghast.  I don't want to be forced to use any address other than the one I've already set up for this purpose.  I've got an e-mail address.  I have a secure certificate.  And when I give my provider my e-mail address, I can also send him a signed e-mail to ensure that he's got my certificate.  After all, this is the way that certs get passed around today.  There are certainly ways to automate this.

The reality of this is that the question was badly stated.  What I suggested above certainly will work with Direct.  A direct address is an end-point.  It could be to an e-mail client, or it could be to something like HealthVault.  For end-points used by non-tech-weenies like me, what/how should we create a "trust-bundle" and manage that?  And still, I don't see the problem.  Provider A's trust-bundle could well be different from provider B's.  This only seems like a way to cut out possible end-points.  Rather than assume that all end-points are bad unless proven otherwise, why not consider the opposite, and let the eco-system police itself in some way.  We'll see where this goes.  I expect that whatever solution they come up with, if it shuts out innovation or patient access, will be corrected by hactivist patients, and the eco-system will adjust (just as the Internet did, first with HTTPS, and later with PayPal and the like to support secure payments).

What is this trust-bundle thing?  Well, imagine it this way:  Every browser is configured with a set of root certificates that it trusts.  There's a bundle.  This bundle of root certificates manages what X.509 certificates are acceptable to the brower to ensure trust in a secure site.  We want to understand what the "initial" configured rules are for the bundle for Direct endpoints.

On the idea of White List, Farzad asked:  Is bar too high? too low? Do we need a bar?
Doug's question was perhaps more pertinent: Or should we go to the bar?

I'm of the opinion (if you haven't figured it out), that a White list (or preconfigured trust bundle) for patient owned Direct addresses sets the access bar for providers implementing portals higher than we've already set it for via HIPAA/HITECH for providers enabling patient data access through a portal.

Next question on the table was for Content:  How can we set content expectations to be consistent with MU Stage 2/CEHRT 2014, but meet providers where they are today?

I think we agreed that

1. ABBI should recommend best practices for content,
2. But allow for use of any content available.

Farzad talked about even sending "Open Notes".  I'm not sure that everyone gets that the eight structured document types in Consolidated CDA can serve two purposes:

1. To document an encounter for your "Clinical Notes"
2. To act as a summary for that encounter for Meaningful Use.

And so, you could have your cake, and eat it too, OR, as I keep telling people, use the document you are already creating in your existing workflow, to act as the visit summary.

Finally, for PULL: What is needed besides working code; what will it take for organizations to implement pull? 

I restated the question to the room:  How many of you here are data holders that would want to share data using ABBI PULL.  Peter Levin failed to raise his hand, but I think he meant to.  Nobody else in the room in the afternoon was a data holder.  My conclusion is that we were in the wrong room, and needed to head over to HIE or Beacon Communities to ask the question again.  [FWIW:  I went fishing today among ONC grantees and programs, and got a few bites.  I may just have to change my business card to read "Standards Coordinator" rather than "Standards Geek"].  Maybe I can convince Microsoft to use their CCD APIs to implement something that works.  (Sounds like an IHE MHD Hackathon adventure).

The last major comment in the Town Hall that I remember was the person who said:  Consumers need to be the ones with ALL of the choices when it comes to ABBI.  I agree.

We closed with #ABBI Hour, at a nearby pub, just as Doug suggested.