The proposed Stage 2 Meaningful Use Recommendations include numerous patient engagement features: patient communication preference, electronic self management tools, EHR interfaces to PHRs, patient reporting of care experiences online, and patient generated data incorporation into EHRs.
I've long felt that a barrier to patient engagement is the lack of common approach to transfer data between EHRs and PHRs as well as to send reminders/alerts/communications to patients.
Patients lack a Health URL or Health Email Address which would enable any EHR or HIE to route data securely among providers and patients.
There's a solution in sight, enabled by the Direct project.
Last week, Microsoft announced that it will provide a health email addresses (your_name@direct.healthvault.com) to every user of Healthvault. Also, they've provided an innovative way to sign up users who do not yet have a Healthvault account - just send an email to newuser@direct.healthvault.com with a subject line containing the patient's existing email account. The patient will be sent instructions to set up an account and receive their secure health message.
All of this uses the Direct S/MIME secure email approach for transport.
If Google, Dossia, and other PHR vendors support a similar Direct approach, then all we need to do to support the patient engagement aspects of Meaningful Use Stage 2 is capture each patient's secure health email address at registration or capture their regular email address and send an enrollment message to the PHR of their choice.
Instead of proprietary software development for every PHR, the Direct approach creates a single one time implementation for hospitals and EHR vendors.
Sean Nolan at Microsoft and have been exchanging email about the implementation details. Below, he outlines the details and the options
"1. For sending the message:
a. If you have an existing product that supports S/MIME, feel free to use it as long as it can encrypt AND sign outbound messages. (BIDMC uses a Proofpoint appliance for email security management and it may support Direct S/MIME requirements out of the box.)
b. You can also generate the S/MIME message outside of the email system and then submit it as any other message to your existing Exchange server for delivery. You could use something like the smime utility that comes with openssl, or there are commercial components such as IP*Works S/MIME. This avoids any changes to your infrastructure and concentrates the work in the code that generates the outbound message.
c. You can install an instance of the C# or Java gateways that have been created as part of the Direct project. For outbound messaging, your message generating code could send plain-vanilla SMTP to the gateway, and it could do the sign/encrypt and forward it through your existing email system.
2. For managing certificates:
Two sides to this … your certificate (for signing the message) and ours (for encrypting it).
For encryption --- we can simply give you the HealthVault organizational public certificate to use. If you go with 1C, you can install this in the gateway software. For 1A or 1B you’ll use different approaches to storing it.
For signatures --- we’ll need a copy of your organizational public certificate, and then you’ll need to sign outbound messages with the private key. Again, for 1C above you can just add your private and public keys to the gateway; for 1A and 1B you’ll manage differently.
3. Testing:
You can self-provision HealthVault test accounts and Direct addresses here, which connects to our “pre-production environment” where all of our developers build and test code. The Healthvault staging certificates can be downloaded from here."
If Direct truly creates a single mechanism for healthcare stakeholders to exchange content - summaries, reminders, homecare device data etc, then we'll finally get enough endpoints connected to demonstrate the value of HIE. With Meaningful Use Stage 2 as a motivator and HIE funding as a catalyst, let's hope the country can converge on a common transport approach.
I've not jumped on the PHR bandwagon, but with an easy to understand, easy to implement (relatively), and easy to use platform that is NOT tied to a specific vendor - wow, I think that the hard work is beginning to pay off. Leveraging well understood platforms (email in particular) is absolutely the way to go.
ReplyDeleteHi John,
ReplyDeleteVery interesting post, and I concur with you on the implications and potential of using Direct as the standardized transport method to PHRs, instead of multiple proprietary alternatives. Assuming what you describe is implemented, do you think that would meet the proposed Stage 2 MU objective of giving patients the ability to "view and download" their health info? Patients could do both in the PHR that received info from the EHR. The tricky nuance is that the PHR is not "part of" an EHR (as is proper, since the PHR belongs to the patient, not to an EHR vendor or a provider). It raises some questions for what qualifies as "certified EHR technology" in that case.
David
In order to understand this more clearly, I'll provide an example. I have a PHR called MyChart provided by an EHR vendor, Epic. I enrolled by providing my personal email address and similar to subscription lists, it sent me an authorization code that I verified. My communication with doctors, nurses, and staff happens within MyChart, but doesn't require a separate MyChart email. I get updates in my personal email letting me know there is a MyChart message waiting for me.
ReplyDeleteAre you saying that if MyChart provided me with a personalized, secure email adress, patient@mychart.epic.com, for example, and I went to another doctor who used Allscripts, that doctor could somehow access my PHI through the use of the MyChart email address?
What if they asked me to get an Allscripts iHealth account with its own email address? How would HIE work in this case with tethered PHRs?
There's a very good interoperable RFC standard for S/MIME over SMTP: AS1
ReplyDeletehttp://www.ietf.org/rfc/rfc3335.txt
Re-using existing standards, especially ones that enjoy interoperable implementations in the marketplace and have existing interop testing programs in place is good place to look.
To Ashay Kapur,
ReplyDeleteGood question. While I can't speak for John, his example was an untethered PHR, not a tethered one. Direct is a "push" so the example you brought up about an Allscripts doctor "accessing my PHI" in EpicMyChart would not fit with the Direct push model. Theoretically, one patient using a tethered PHR could push a record to a different tethered PHR, assuming both those PHRs supported the Direct protocols. But I think it's easier to understand the examples in the context of a use case where an EHR pushes to an independent PHR, to which the patient granted the EHR provider the right to send it. At least that's how I read this post.
BTW, I shouldn't have made a blanket statement that the "PHR is not part of an EHR." I meant that it is not NECESSARILY part of the EHR, because there are different PHR models, such as independent (like HealthVault), payer-based (like BlueCross), employer based (like Dossia), and EHR-based. The Direct Project could be used for any of those, though some might be more likely than others.
ReplyDeleteDavid
If Clinic A decides to send to HealthVault, and Clinic B decides to send to Google (assuming they add this functionality) ... then it would be OK, but the patients would have to deal with two systems.
ReplyDeleteI guess that is better than nothing. Maybe as people understand the concept of "Health Email Address", they would learn to consolidate.
sounds very interesting.. goes on the agenda for exploring further I think.
ReplyDeleteNo doubt this will be interesting to see how it all rolls out and I stuck with the basic consumer side for now to advise patients to sign up as I did mine with HealthVault. The average practice has no clue on certificates unless they have a geeky MD working there:) According to what I read on the latest blog post from Sean, the process will move to being able to do this online in time so I'll watch for some additional announcements too.
ReplyDeleteThe Direct Project really stands to remove so many of the communication barriers we have all been dealing with to provide simple secure communication!
How a physician can send a secure Direct message from Care360 EHR to a patient's Healthvault PHR account:
ReplyDeletehttp://mdinteractive.blogspot.com/2011/02/sending-secure-direct-message-from.html
Great post. Here are a few questions we are trying to answer at WhiteGlove.
ReplyDeleteThe truth is that there is only so much an employer can do with healthplan redesign. In the end, the employer’s healthcare costs are a variable cost line item and driven by:
1. How often their employees and dependents seek care;
2. Where their employees and dependents go for care;
3. How many unnecessary procedures are performed on their employees and dependents?
4. How many unnecessary brand Rx meds are consumed by their employees and dependents?
5. When their employees and dependents need care and the options available at that time?
And most of these factors are truly out of the employer’s control. What it is going to take is the advent of healthcare providers that have the courage to bring change and innovation to healthcare that lowers the overall cost of care for the employers and their employees and dependents WHILE improving the healthcare experience!
Innovation has to be driven at the corporate level. We're doing our part to make EMR and individual accountability a reality.
Bob Fabbio
CEO
WhiteGlove House Call Health
www.whiteglove.com