Super-simple connectivity with DOPU

Our operations team is in the final stages of releasing one of my favorite new HealthVault features to the production systems. "Drop-off / Pick-up" (DOPU for short) is live in the partner environment now and will be ready for public consumption next week.

The idea behind DOPU is that sometimes it's just not necessary or appropriate (or convenient!) to create an ongoing, trusted relationship between a HealthVault record and a clinical system. There are many totally reasonable cases where an institution, laboratory, state agency, or whatever just has some information they want to give their patients -- and be done with it.

That's what DOPU is all about... simply create a file and "drop it off" at HealthVault. Later, the patient visits HealthVault and "picks up" the information using a secret code and challenge question. No muss, no fuss. If the file you create is a CCR, that's fantastic. But if it's not, no problem. We can take images, text or HTML files, Word documents ... pretty much anything will work.

Because there is no ongoing relationship, the integration model is much simpler than in other scenarios -- something most folks can easily implement in a few days. It has the potential to be a real accelerant for clinical connectivity -- I am totally excited to get it out there.

In order to help things along, I've written some fully-functional sample code that you're welcome to use as a starting point. Actually, the sample creates a small console application that you can even use exactly as-is to implement DOPU -- this means that you can now securely send information to HealthVault without writing a single line of code.

How it Works: Drop-off

To start with, the clinical system needs to obtain a HealthVault application id and install a certificate that is used to identify the system in calls to HealthVault. For my sample application, I've included a certificate that is pre-configured to work in our partner environment. Simply import the file "Drop-off Sample.pfx" using the HealthVault Application Manager that comes with our SDK.

Next, the clinical system has to generate a file they want to send. Ideally this is in a packaged format such as a Continuity of Care Record, but it can also be a file like an image, text, PDF, HTML or Word document. How this is done of course depends on your source systems -- one super-simple way to get started is to use "print-to-pdf" software to generate Adobe PDF files. The system also needs to collect a name and email address for the patient, and a "challenge" question and answer that the patient will remember (for example, "What was the name of your first pet?" = "Seeds the parakeet").

Finally, the system needs to run the DOPU application with a bunch of command-line parameters to make it do the right thing. The "test-dopu-ccr.bat" and "test-dopu-file.bat" files in the zip package demonstrate how to use the DOPU command line. I've also put together a more complete description of each parameter here.

And that's it. The data has been safely tucked away, and the patient will receive an email with instructions for picking it up. The original file can be deleted or archived as appropriate for the institution.

How it Works: Pick-up

When the patient arrives home, they will have an email waiting for them. The sample application uses the following text; a real-life application would provide more context. However, it is important to remember that email is a fundamentally insecure channel -- so no personally-identifiable information should be included in the email text.

When the user clicks the link, they are guided through a set of pages:

1. Signing into HealthVault, creating an account if needed.
2. Providing the secret code from the email.
3. Answering the previously-agreed-upon challenge question.
4. Picking the correct record to add information to.

After this, they're done. The information has been moved into their HealthVault record and is ready to be shared with other providers or family members, used with other HealthVault applications -- whatever makes sense for the patient.

What about privacy?

When the data is added to the HealthVault "holding pen", it is encrypted using a key derived from the answer to the user's challenge question. Because that answer/key is not sent to HealthVault along with the information, there is no way for HealthVault (or anyone else for that matter) to see what is in the package -- so no disclosure from the institution has occurred at that point.

Only when the patient goes through the "pickup" process and provides the answer to that question can HealthVault decrypt the package -- successful decryption indicates that the answer is correct, and together with the valid secret code confirms that the patient has rights to the information.

This is a pretty neat twist, one that allows HealthVault to manage virtually all of the "heavy lifting" for the institution while still preserving patient privacy and supporting the institution in its HIPAA obligations. Too awesome.

Which model is right for me?

At this point, we've developed three models for clincial connectivity, and each makes sense in a different context. DOPU is ideal when you're not establishing a long-term relationship with your patients. It can also be a perfect "first step" into connectivity that has a much lower technical barrier to entry than other models.

If you already have a patient portal, then using that as the connection point with HealthVault almost always makes the most sense. Without that portal -- if you want to support ongoing or bi-directional exchange of data (for example, reading home monitoring information into the institution on a regular basis) -- direct-to-clinical is the way to go.

Having a lot of choices means that almost certainly there's a natural way for you to integrate with HealthVault. Our partner team is always ready to help you figure out the right path forward -- best way to get started with that is a post on our MSDN forum. I can't wait to see us all connected.

Download Sean's DOPU Sample Application

 

10/31/2011 --- fixed broken code links

Comments

• Anonymous
  July 17, 2008
  Drop off / Pick up is a new platform feature that helps you schedule service appointments for your light

• Anonymous
  July 23, 2008
  Hey Sean, Can you tell me what the difference is between the storage behind HealthVault and the LiveMesh cloud? Best Regards, Jeff Kane

• Anonymous
  July 25, 2008
  Hi Jeff --- Both the HealthVault and Live Mesh services are hosted within our MSN facilities, which means the same operations organization manages the properties, and they share the same basics in terms of infrastructure. However, because of the fundamentally sensitive nature of HealthVault data, the HealthVault servers are isolated (both logically and physically) from all other Microsoft services. Our servers also sit on top of a significantly stricter set of policies and technologies than most other services, to ensure that we can deliver on our privacy commitments around health information. One of the great things about being part of Microsoft is that, as other groups continue to advance the state of the art in things like cloud storage, we get to take advantage of their work. Live Mesh is part of a project to do some really neat things with large-scale storage, and we absolutely will leverage that technology as it continues to roll out. Of course, we bring our own requirements to the game ... but that just improves the base services as well. It's a great feedback loop. Hope that helps ... let me know if I can answer anything else. ---S

• Anonymous
  August 13, 2008
  Hello Sean, We have been working on HealthVault SDK for quite a while now.  One of the challenge we have always had was overall learning curve for the patient. This functionality is just awesome from that perspective. Also - the fact that you do not have to create "permanent trust relationship" dramatically increases the number of use-cases providers can support. Great thought!!! CT Team

• Anonymous
  August 13, 2008
  Can you support a reverse functionality as well? For example -

1.  As a patient, I log into HealthVault
2.  Create an application to generate a new CCD based on various datatypes available in HealthVault - i.e.- latest Continuity of Care Document/ Record based on data available with me in my consumer health account.
3.  Drop it off to a location with a secret key for an application/ user to pick-up.
4.  On my next visit to provider office - I provide secret key and answers to some unique question
5.  App on provider-side (with valid App ID) can pick-up my CCD and import into its local EMR !!! CT Team

• Anonymous
  August 13, 2008
  This is a really interesting idea ... you can get kind of close to it using the OpenQuery stuff with a PIN and an expiration date ... but it would be a lot of work, primarily around constructing the innards of the CCR/CCD itself. That is probably our first step --- to make it really easy to make a request through the platfom to get a "standards-based" response ... and then thinking through the reverse-dropoff piece becomes a much smaller item. Thanks for the feedback --- it's incredibly helpful, especially from folks like you all that have been working with the platform so deeply. ---S

• Anonymous
  September 26, 2008
  A couple of weeks ago now we shipped a bunch of new HealthVault stuff --- in particular, we've significantly

• Anonymous
  February 09, 2010
  Link to Download Sean's DOPU Sample Application does not work. Please fix.

• Anonymous
  May 15, 2014
  This works well from a bat file, but when I try and pass through System.Diagnostics.Process.Start(the dopu exe, my parameters) or through .arguments process.start it does not seem to work.  It simply flashes on the screen.  I know I am using the correct parametrs since it work in the bat file I made.

• Anonymous
  May 15, 2014
  Likely issues I can think of would be: (a) for some reason args aren't making it in properly, you could edit the code to just print those out on startup to a console to verify; (b) Missing required DLLs; (c) some kind of permissions issue, i.e., the context that the app is being run from doesn't have rights. I'd try classic printf debugging on those too. Sorry to not have more specific ideas --- without running the code hard to figure out.