The case for SMTP
Really, this is just email for health information. If you were to magically make all of the security, privacy and spam/phishing-related issues of today’s Internet mail go away --- we would be done!
- Email scales from small practices to large ones, and to patients.
- It is supported across all platforms by a ton of robust, real-world proven software that handles all the edge cases: admin, monitoring, provisioning, etc.
- Its store-and-forward design is resilient in the case of network outages.
- It enables both unstructured and structured exchange.
- It supports endpoints that are humans, groups, or computers.
- It uses concepts that are widely understood and accepted.
- Etc.
I think there would be pretty universal agreement that this would be a no-brainer. So the question becomes --- is there a minimal-code approach we can take to achieve the “magic” we need?
As it turns out, email gives us an answer for at least part of the magic, too. S/MIME provides a standard, well-understood mechanism to use digital certificates to both encrypt email messages – ensuring that they are not inadvertently disclosed as they travel through the email system – and sign them – ensuring that senders can be tracked and untrusted messages get bounced back.
The obvious question then is – if it’s so great, why don’t we all use S/MIME for all of our email exchanges already? The answer is pretty simple. Current S/MIME implementations put a pretty nasty burden on the end user – every user has to acquire a certificate for their account, install it, remember to renew it when it expires, and keep track of certificates for others in their address books. Some enterprise systems reduce this burden somewhat, but without ubiquitous usage, it’s just never caught on.
This is where we can add a bit of software to the existing stack to make the magic we need. We already have an advantage in that the healthcare community understands and accepts the need to have a secure and trustable exchange – so our solution doesn’t have to be ZERO work over normal email, just small enough that it is manageable and easily adopted by end users and their email providers.
We have proposed the “NHIN Direct Agent” --- a piece of code that can be inserted into existing email pipelines --- to manage the handling of certificates and mechanics of S/MIME signatures and encryption. This approach also requires an improved mechanism for distributing public certificates, which we can solve using DNS records – again leveraging already-deployed infrastructure to avoid new work.
The agent can be inserted at many levels --- at the email server (hosted by a service provider or owned by a large organization), at the organizational boundary (as an email proxy or gateway), or on an individual client desktop (as a personal proxy or a plug-in to existing software). These different approaches not only enable maximal reuse of existing systems, but are the key to making S/MIME usable for all constituents: responsibility for certificate management can be delegated to a service provider, managed by an organization, or kept at the level of the individual if desired.
I will refrain from going into more technical detail in this note --- we are hard at work building on those technical documents and writing code to prove the approach. The takeaway I am hoping to leave people with is not those details, but the bigger ideas that:
- We are trying to build email for healthcare.
- Except for a few key flaws, email works extremely well already.
- Those flaws are addressable with minimal and well-understood new work.
This approach is in direct contrast to others that are building up entire new messaging stacks or trying to adapt ones that are “close” but don’t exactly fit the need. While I am sure we can do either of these – they seem strange paths to take and high hills to climb, especially when you take into account the huge amount of “last mile” work required to make a new stack truly Internet-ready. The SMTP approach is simple and just makes sense.