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:
- Signing into HealthVault, creating an account if needed.
- Providing the secret code from the email.
- Answering the previously-agreed-upon challenge question.
- 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