The Direct Project put policy completely out-of-scope, saying that it was the sender’s responsibility to determine that they have the necessary authorization and that they have chosen the right target. The Direct Project picks up at that point in the workflow, at the point where there is a need for technology to deliver the message. I know some people want Direct to encompass more, but it does not. And I should not, as that would limit policy and creative software.
Further, the Direct Project has no way to carry policy rules from one place to the other. It is true that there is a TO addressee and when using XDM there is an intendedRecipient. But neither of these technical fields have a policy attached. Just like every email that is sent, there is no way to compel the reader to not share the message with anyone (I had an oops like this just today, sorry about that). Hence why some people put various forms of disclaimers at the bottom of their email, things that have been proven not legally binding as well. Some e-mail packages have actually tried to implement some policies, but without universal use this won't work.
Within the NwHIN-Exchange the highest level policy (DURSA) has clauses in it that forbid one party from re-publishing the document that they got from another party. This means that if you receive a document through the NwHIN-Exchange that you can’t republish that document, it does not restrict you from using the document for the purposeOfUse. It does not restrict any derivative works, your medical summary or diagnosis including evidence from my document. This is a Policy that is defined and enforced by the overall NwHIN-Exchange governance. The NwHIN-Direct does not have such a Policy, and there is lots of resistance to an overall organization.
Note that the S&I Framework – Data Segmentation for Privacy – workgroup is working on this problem in an indirect way. That workgroup is working on specific regulations that mandate that policy in English textual form accompany specific types of data; so they are looking at how to do that. They want to send along restrictions on exactly which individuals can see the data, and what long-term rules must always be applied to even the decomposed attributes from the data. The reality is that this is not something that is done outside of healthcare today, so there isn’t free technology we can leverage. The non-healthcare world is using more of the NwHIN-Exchange model, with pre-negotiated policy principles; and policy applies to a whole-document.
The DirectTrust.ORG is also looking into the use-case you bring up. Specifically they want to force the TO or intendedRecipient to truly be the only one that can use the data. I think this is a mistake that the market-place will push back on. Simply because of Medical Records Retention, and Medical Ethics will prevail. If the data is used for treatment, then it must be incorporated into the local medical record (electronic or not).
Lets just imagine one can come up with a solution, we would need to certify that everyone involved in healthcare, including patients, are all using compliant software. And that it was impossible to hack around it. Impossibility. The sooner we get to that understanding, and lean on policy that is backed by regulation and punishment; the sooner we will make progress.
A middle ground is that there be e-mail addresses (Direct addresses) that are clearly the individual-for-no-other-eyes, and the individual-and-medical-records. This is not much different than the discussion of an organizational e-mail address, or a departmental one.
I have covered this before:
- Handling the obligation to prohibit Re-disclosure
- ConfidentialityCode can't carry Obligations
- NHIN-Direct Focus and Scope Creep
- Policy Enforcing XDS Registry
- Critical aspects of Documents vs Messages or Elements
- Proposal for confidentialityCode vocabulary
- IHE - Privacy and Security Profiles - Conclusion
I posed this exact issue to the S&I RHEx group. RHEx is charged with dealing with links sent in Direct messages. The person who accesses the link may or may not be the recipient of the Direct message. Either way, they will need to be authenticated and the link's host will have to decide if access is appropriate.
ReplyDeleteLet's keep in mind that patients are first-class citizens in Direct and they need the convenience of forwarding and web links.
So: Yes, we should allow forwarding of Direct emails and Yes we should encourage the use of links secured with OAuth and OpenID Connect to manage security as required by the patient.
Adrian,
ReplyDeleteI very much agree with you statements that Patients need to be considered a first-class citizen. You and I have been side by side on that point.
However the sending of a link to a secured web-service, does not need Direct. This can be sent as a normal email without all the trust fabric that Direct is forced to build. The use of secured web-services is an alternative that I am also very much a proponent of. One definition for these links for document based targets is currently released as a IHE supplement -- Mobile access to Health Documents. I have authored and pushed for this profile because I see REST as a great solution for end-user access.
There simply is no need to use the heavy Direct stack for secured web links. We need less friction, not more.
There are three reasons to use Direct for sending links:
ReplyDelete1) links to streaming medical imaging that would be too large as an email attachment
2) the doctor doesn't need to worry about PHI in the message introducing the links
3) the EHRs will (let us pray) be mandated to accept Direct messages whereas they can ignore regular email and continue to charge for back end interfaces like HL7 and Exchange
Adrian,
DeleteI have more faith in real people than I do in government mandates. There is far more real e-mail today between doctors and patients than there ever will be using Direct.
John: Nice piece. I want to say that I have no recollection of any position taken by DirectTrust, or within the Rules of the Road WG prior to the formation of DirectTrust, on this issue. Specifically, we are not to my knowledge trying to "force" anyone to do this, or anything else for that matter. Let me know if you have any documentation of a recommendation or other policy statement from DirectTrust on this matter.
ReplyDeleteregards, DCK
David,
DeleteIt is very possible that I miss understood some conversations. I am glad to hear that DirectTrust is sticking only to identity and trust, and not going into governance of the use of Direct.
John thanks for posting this. Glad to also hear DCK's clarification. I like the idea of making different types of email addresses as you suggest, though that is policy and can't be enforced. Adrian also makes the excellent point that patients need the ability to forward what they receive (the "View/Download/TRANSMIT" objective) if they choose.
ReplyDeleteJust to clarify the context of the "offline" question -- I was the one who sent it, asking whether a Direct Message to a specific doctor could be forwarded to other colleagues (e.g., other physicians in the practice, or office staff).
Human behavior can't be totally governed. We expect "common courtesies" from people and usually get them, but not 100%. So even with the vast majority of personal and work-related emails which are unencrypted, I've made the mistake in the past of forwarding something sent to me, only to realize later that it contained some wording that the sender might not want shared (encryption or not!). So, trying to learn from that, I'm trying to develop the habit of asking the sender if it's OK to share the email with others. They generally say "sure" but thank me for asking. But I don't expect everyone to do this each time they forward a Direct message. Hopefully those who forward will fully comply with HIPAA and properly constrained use of the data for treatment, payment, and operations.
David