Trust me, I'm a patient!

  • Article

In our little world of patient data interoperability, job #1 for the last year or so has been all about getting data out of provider systems. Meaningful Use VDT is a big part of that, and it’s cool to have been in the UK last week learning about their progress along a very similar path (some hints here). Not “mission accomplished” by any means, but we’ve made a ton of progress. Sweet!

The National Association for Trusted Exchange (NATE) has been a big part of that progress --- NATE’s  pilot programs, sponsored in part by the ONC,  did a great job teasing out remaining real-world issues, and it’s been great to work with the team there, in particular CEO Aaron Seib.

An IMpatient guy (you reading this, Jeff?), Aaron is now pushing hard to enable the next obvious workflow --- patients sending information to their providers. Think visit summaries from past encounters, home monitoring data, and so on. And he’s not alone; “patient-generated data” (or perhaps more accurately patient-supplied data) is quickly moving up the industry priority list.

A key issue that always comes up in that discussion is “provenance” --- if data is provided by a patient, how can the receiving provider make a judgment as to its veracity? Concerns arise not just around explicit fraud (e.g., drug-seeking behavior), but also perfectly honest “telephone game” mistakes --- e.g., did the specialist really conclude you have a particular condition, or was it simply a possibility?

Direct is a great mechanism for sending data from patients to providers … but it doesn’t have a mechanism to express the “provenance” of data shared in that way. And while the C/CDA is an excellent way to package information for exchange, it doesn’t really help with that either.

At a recent NATE workshop, Aaron and others proposed an extension to the Blue Button + “request.txt” file that would carry provenance metadata in a simple form that providers could review. We thought it was a good idea, so as of now, HealthVault always adds this metadata when sending attachments via Direct. A few examples:

  • Document-Source:name="Visit Summary.xml";source=<drbob@direct.myclinic.com>"
  • Document-Source:name="Glucose Readings.csv";source="PATIENT"
  • Document-Source:name="HealthVault Record Data (CCD).xml";source="MIXED"

In the first case the attachment was forwarded from a known Direct address. The second was information uploaded by the patient themselves. The last is a composite file created from a number of sources. It ain’t perfect, but it’s a nice way to start the process --- simple and easy.

Enough from me --- Aaron has thoughtfully agreed to write a few words about why he thinks provenance is a key piece of the puzzle, and how he hopes to get other folks excited about this new metadata approach:

First, I really can’t take any credit for the incredible results that NATE has had so far piloting these concepts. We have been really fortunate to get support from our member states, the VA and the University of California San Deigo, HIOs in CA (San Deigo Health Connect and Axession), OR (CareAccord) and AK (Alaska eHealth Network) as well as three amazingly collaborative PHR vendors – NoMoreClipboard, Humetrix and of course, Microsoft HealthVault.  

I think the real reason we have been able to make such great progress together is that there is a resounding demand from everyone’s stakeholders to make it practical for patients and providers to be able to benefit from the use of Directed Exchange to improve outcomes, patient satisfaction and provider workflows. NATE’s part so far has been mostly facilitative and specific to enabling bidirectional trust between the systems being employed by consumers and those being employed by providers.

We all agreed to start as simple as possible and only address the biggest barriers to getting to square one with regards to bidirectional interoperability between patient’s and providers. On the consumer side it came down to figuring out how to make the workflow for the patient as secure as necessary without setting the bar so high that only the most motivated users would bother getting started. Recognizing that the greatest ROI isn’t going to be realized by working with only those consumers that are already motivated and engaged in their care. At the same time we all understood that providers (and to a higher degree still the states and other entities that have to satisfy a higher bar than most private entities like the VA and other payers) were concerned that they didn’t have enough information to be comfortable disclosing to just any end-point. So the first thing NATE did with the pilot participants was establish a process to help ease the burden and provide a way to enable Direct based exchange between PHRs and Providers – that is to say we created a Pilot Trust Bundle and working with the participants established the onboarding criteria for PHRs to be added.

This step helped get real world use yet it wasn’t the entire equation. It isn’t just about making PHRs consumer friendly and helping differentiate those that comply with baseline security and trust requirements more easy to recognize - it’s also about making it work in the provider’s workflows. We recognized, thanks to the participation of practicing providers and practice management personnel who helped us early on in the pilot, that the current state of the art when data flows from the patient to the provider didn’t really match the work flow of the provider’s practice.  

Practices have always received information from all types of sources. All practices have had paper based data receipt procedures that they follow based on the type and source of information that they are receiving. What is missing in the electronic receipt process is a computable method of following those procedures. The functionality represented by the request.txt capability that Sean is announcing can go a long way toward helping practices better handle incoming data from consumers.

So far NATE has made some remarkable strides but we recognize that we are just getting started. There is much to learn and many more folks for us to learn from. We are nearing the completion of the pilot work that we have been doing in relation to the ONC funding activities and a report will be published soon highlighting the lessons learned from the pilot and our recommendations for next steps.

Included in the report’s recommendations is the need to “continue to collaborate in the next phase of this NATE initiative ~ by making a broad call for participation of more ~ PHR vendors and EHR vendors as well as others working in this domain to inform future work”. We hope to continue to work with everyone who has been involved so far, including the ONC, and will be making a broader call to interested parties but it would be great to hear from those of you who are interested in being part of the next step in this movement.

We know we don’t have all the answers and that we need a lot of help so if you’re interested in staying informed about next steps please let me know via email at aaron.seib@nate-trust.org !