On Friday, the HITSC Privacy and Security Workgroup reviewed the Direct Project specifications. Their findings are on the HITSC website. I would like to thank the Workgroup for the time and thought they put into the review, and would like to thank Dixie in particular for leading the Workgroup through the review process.
The Workgroup found that the core Direct Project SMTP + S/MIME specification met the goals of a secure transport and is scalable for the purpose intended (although it should be marked as less applicable for large (GB and higher) file size transport). In addition to that finding, the Workgroup also noted:
The core specification is "messy"
We agree -- the original version of the SMTP + S/MIME was a mixture of design advice and specification leading out of the creation of the reference implementations. On review, if you do not know what it already says, it is hard to read it to find out. We are in the process of revising the specification for editorial cleanup and readability.
The specification implies a key policy decision -- that it is OK for a receiver to reject unstructured content.
The discussion on this point was interesting. John Halamka has a good summary of the discussion and some e-mail based follow-on. The key point is that the policy decision (for instance, that sophisticated receivers should be open to accepting electronic data from senders who have less sophisticated technology) should be separated from the technology question (that, for instance, in some cases, receivers who are expecting particular healthcare formats should error if the content is not what is expected).
The use of DNS for certificate discovery should not be mandated
The HIT Policy Committee just published recommendations (link forthcoming) on provider directories, which call for certificate discovery as a key directory attribute. We expect a great deal of innovation here. DNS may be an appropriate option for the short term; long term, the strategy should align with the standards for provider and organizational directories.
TLS and S/MIME wrapping should be removed as optional components for already encrypted S/MIME content
The TLS issue is, I think, not an issue. The SMTP infrastructure already has the ability to upgrade to TLS on the fly so encouraging TLS support does not impede interoperability. The recommendation on message wrapping is that the complexity of wrapping the full message does not justify the benefit (protecting headers) and that the risk of subject and other headers containing PHI should be mitigated by policy.
There were some important recommendation regarding XDM and XDR that I will address in a separate post.