Family Health Guy

In which Sean talks about HealthVault and other cool ideas in Personal Health

Raising the stakes again ... here come the patients!

Raising the stakes again ... here come the patients!

  • Comments 1

Some days I feel like I ought to send my good friends at ONC a big care package full of Valium. The team there really is doing great work, and frankly I can understand trying to move fast given all the political FUD around health reform, but boy is it exhausting trying to keep up with the level of energy they put out. Maybe Valium for them and a daily Red Bull for me?

Now that Blue Button Plus is in “execution” mode, the action has quickly started to move towards the flip side of patient engagement --- individuals sending messages and data TO their providers using Direct. A not-insignificant part of me is screaming “Let’s just get VDT working first!!!” But years of working with Peter have taught me that pulling back on the reins rarely leads to success. So ok, deep breath, let’s go.

Truth be told, here on the HealthVault team we’ve been working on patient-side data sharing for a long time --- really since we started way back in 2006. All of our best use cases amount to this pattern: individuals tracking key observations at home and sharing them with their caregivers. Armed with this information, providers can use CRM-style tools to watch for and alert on problematic trends --- providing simple interventions that keep little issues from turning into emergency room visits. In case you’re wondering, it totally works.

The question on the table, then, is not about whether this is a good idea, but how we can scale that success by integrating patient-to-provider communication into the quickly accelerating world of Direct. That’s the discussion I’m hoping to frame with this post.

Where did we land with provider-to-patient?

The Blue Button Plus guidance prescribes a pretty simple approach: ask your patients for their Direct address and store it with their chart. Just like you take their phone number. Simple, super-effective, and totally avoids the “identity” quagmire --- because that authenticated exchange of the address is the best identity proof we could ever hope for (more tedious arguments on this here).

So isn’t that enough for provider-to-patient?

Yes! That same address exchange provides us all the raw material we need to make good decisions about patient-to-provider messaging as well. Conceptually, when a provider receives a message from a patient address, they can simply check if that address is already associated with a chart --- if so, awesome; if not, drop it on the floor.

There are only two problems with just calling this good and moving on:

  1. Direct doesn’t have a way of distinguishing a “patient address” from a “provider address” … so applying different inbound rules to a “patient” address isn’t actually possible today.
  2. Even having solved #1, the Direct applicability statement has no concept of a “white list” … so there is new code to write somewhere in the stack.

Note that theoretically you could make the current implementations work as-is. You could “white list” a patient address by adding the patient cert directly into the trust anchor store for a given organization or provider. But that would be extraordinarily cumbersome and brittle --- so much so that it’s really not worth spending more thought time on here.

So let’s take a look at each of those two issues.

1. How to identify a “patient” address vs. a “provider” one?

Certificates can contain arbitrary attributes. These attributes, identified by “OIDs” (big long strings of numbers separated by dots), make claims about the nature of the certificate. All we have to do here is to define standard OIDs for representing a certificate as applying to a “patient” or a “provider” and we’re good to go.

Since most Direct certificates in use today are provider-side anyways, we might even assume that certificates belong to providers unless the patient OID is present --- that will reduce the amount of rework the system overall has to do (speaking for HealthVault we’re happy to update our patient certs with a new OID if that makes sense).

2. Where does the whitelist code go?

With #1 in place, we really could just leave this to the application (EHR) layer to implement --- it doesn’t have to be part of Direct itself. But I think it’s pretty clear that the approach of delivering production-ready reference implementations has served Direct really well, so it seems smart to add the capability to those. That doesn’t mean everybody has to use it --- but it is ready to go for those that want it.

Each reference implementation has a configuration database already. This is just a bit of feature work to associate “white listed” addresses with inbound addresses or domains, just as other trust information is. Then when new messages are received, we add an additional filtering step to determine if a white list is present and if the sender is on it. Easy peasy.

That’s it. A pretty good strawman that gets us where we need to be.

There are other approaches to the problem as well --- one popular idea is to only allow patients to reply to messages from their providers. At the end of the day, this involves exactly the same mechanics as what I’ve described above … and IMNSHO it’s just conceptually a bit harder to explain than “Give us your address and we’ll keep it with your chart.”

Anyway … once you solve this problem, there are all kinds of awesome exchanges that can start to happen. For example, the folks at RWJF have been working on a model whereby a provider could use direct to query for patient-generated data updates. You could imagine appointment scheduling working over this channel, and bill payments, and tons more. It’s pretty exciting stuff.

So let’s get it done … and THEN can we take a break???

Leave a Comment
  • Please add 4 and 5 and type the answer here:
  • Post
  • Well when former Seattleites who now work for ONC are up reading your blog (and trying to locate Dempsey) at 3:30 am EST I doubt it will stop anytime soon. ;-) Great timing though Sean.. Thanks extremely helpful information

Page 1 of 1 (1 items)