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.
- 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