SMTP Consensus Issue Responses

(first cut 6/11/2010; unfinished)

Better define error handing and exception processes [ed note: email clients support MDN but specific features supported vary)

Just like SOAP has soap faults and REST has HTTP errors, SMTP has transactional error codes (see here). Because it is an asynchronous protocol, we also have the abliity to return errors as messages with well-known content. We can use something formal like MDN, or simply define our own attachment type for error information.
 
  I did discuss a question as to what happens if a message is accidentally sent to a non-NHIN-D node. I misspoke this morning when I said this could happen --- in fact, the agent will reject such a message before it ever makes it off the server, because it will not be able to fetch a trusted certificate to encrpyt with. So --- not an issue.
 
 

Define ability to address additional metadata [ed note: specification endorses use of XDM attachments]

I think we did this very clearly in our presentation:
 
  1. Simple metadata in headers
  2. XDM metadata as an attachment for richer scenarios, such as EMR to EMR when the receiving EMR is known to prefer XD* data (such as the Federal gateways, etc)
 
  The IHE team has indicated that they believe step up / step down from SMTP to XDR is feasible, and has agreed to better define the minimum standards necessary to be considered "profile compliant" XD* metadata.
 
 

Presence of viewers for health content

Same for all implementations. An SMTP backbone can be integrated into EHRs just as easily as any of the others. There is no "viewer negotiation" unique to the other implementations. In fact, the "content-type" approach for email attachments is far better suited to finding appropriate viewers, as the operating system (at least Windows) has built in functionality to help you find a viewer when a type is unrecognized. For example, Cerner has implemented SMTP-delivered data into routine Millennium data viewers, using a standard Java Mail API to pull data out of SMTP MailDirs.
 
 

Address cost of data centers to add new infrastructure not currently supported (note that data centers for HIE often not the same IT staff as data centers for email)

It is certainly possible that a dedicated HIE data center would not have SMTP servers running in it. However, every health organization in the world either has SMTP servers running or has already contracted with an ISP to provide the service --- these IT staffs would be in an ideal position to run SMTP HISPs.
 
  However, this argument misses the real point. Big organizations already have big IT capabilities. They don't need to be coddled. The big rock in this problem is to find a solution that can be deployed to the thousands of small business across the country. This means we need to find the lowest-cost way to get credible service providers running. For every other segment of the economy this is the ISP industry. They have extensive existing iron and existing talent for running SMTP servers. They have zero for running IHE stacks.
 
  So in terms of costs --- the cost to add SMTP services to our large organizations pales in comparison to the cost of building up IHE service for the majority of docs that have nothing. The cost of adding SMTP from scratch will be less than the cost of add IHE stacks from scratch.
 
 

Trusted paths of routing [ed note: OCR may consider any intermediary that has even encrypted data as requiring a BAA]

I assume this refers to the fact that mail may pass through an intermediate mail server on its way to a destination. That does not happen randomly, it only happens when a server is set to be a relay. The only relays in use would be HISPs or Intranet-based relay servers. So --- a non issue. OR, a simple policy that requires Mutual TLS for all SMTP nodes, where each node must possess a certificate from a trusted certification authority could be required.
 
 

Address extension [clarified as: "How do you support additional use cases"]

We would do this by leveraging the ability to carry structured attachments. We would re-use existing formats when available (e.g., folks might send structured labs as HL7 v2 OB* segments), or create new ones if required. We showed evidence of just how easy this was by integrating CCD data into HealthVault by sending it as a structured attachment. As we put it in our slides "let innovation occur via extensions to the payload."
 
 

Risk analysis

Email is the most attacked and most mitigated protocol in the world. S/MIME is a well-understood standard that uses well-understood cryptography techniques. Indeed, an SMTP implementation should under go extensive threat modeling during the execution phase --- just like every other implementation. REST introduces completely new attack surfaces, SOAP systems need to be deployed properly to be secure, and any step up / step down code wil introduce new attacks as well. So it does not hold that this is a weakness with an SMTP backbone. SMTP is likely to be the most secure "off the shelf" solution.
 
 

Automated testing

Again, all implementations will need a testing suite. It is misleading to say that this is "done" for SOAP/XDR, because we are talking about new use cases, new inputs, changes in metadata, etc. All the implementations will need to be tested --- there is nothing special or difficult about doing so for SMTP.
 
 

Address risks of users using their current email clients (possible confusion, sending data to standard SMTP servers)

This is a concern about the client being used by the doctor. EVERY TEAM said that "SMTP on the edge" --- that is, an email client --- was necessary and desirable to support small doctors. Thus this "risk" applies equally to any team that implements an SMTP edge. We are happy to talk about ways to mitigate this preceived risk of using an email client --- but are not willing to accept it as an issue of SMTP on the backbone. Almost everyone has more than one email account, and thus the learning curve for "one more" email account would be easy. Clinicians have to be trusted at some level to understand and use technology properly. Selecting the correct email account would not present a difficult challenge.