TE170.314.b.2 – 2.05: Using the Inspection Test Guide, the Tester shall verify that the EHR technology is able to correctly discover and use address-bound and domain-bound certificates hosted in both DNS and LDAPThis test script correctly indicates that the EHR technology under test must do both DNS and LDAP methods for certificate discovery. This is indeed the way that the 1.1 version of the Direct project specification says, that both methods must be tried. This is even the recommendation of the S&I Framework project that requested that LDAP be added to the Direct project specification. I have commented against this requirement at all levels, and will continue to comment against it. I didn't use my negative vote, as I recognized that I was but a single vote.
What the issue is, when you have 2 methods to do the same thing one must define how you will get Interoperability between the methods. The two methods are the DNS-CERT and LDAP. What I mean is that you either force all certificates to be dual-published in both methods, or you force all clients to query both methods. The specification choose to query both methods. This WILL work. I am not arguing that it won’t work. But it has consequences that are not fully recognized. I really don’t understand why this model was chosen. I think the thinking was that senders should be as robust as possible and try both protocols. I don’t disagree with this robustness principle. What I disagree with is FORCING this principle, that is forcing that all senders must do both methods. Since you are forcing that both methods are tried, you are forcing Providers and Patients to use customized software for healthcare. If this was not forced, then off-the-shelf e-mail such as Thunderbird or Outlook could be used. But since these off-the-shelf emails don’t do the DNS-CERT certificate discovery methods they can’t be used, even though they do a fine job with the LDAP lookup and the S/MIME handling.
Those that are hosting HISP or Identity services should be the most capable of hosting 2 services rather than just one. Thus my recommendation was that certificates be published in both methods. The advantage of this is that it wouldn't have invalidated early Direct clients (which forcing both does), and would have allowed for off-the-shelf e-mail. Further advantage is that we could have retired the method that was not adopted as much over time. Meaning that we would have had a way to transition to the winning protocol, which ever it might be. I am sure LDAP will win, but that is not important to the point.
One last point. Forcing dual publication on the service side would have impacted fewer sites than the forcing of the dual method on the sending side. The reason is simple, there will be more senders then there will be service sides. Simple observation says that there will surely be organizations that will be publishing many number of certificates for endpoints within their organization (Surescripts, HealthVault, etc). This math alone makes it clear there will be fewer services then there will be senders.
LDAP will win in the end because it provides for Healthcare Provider Directories, and other directories as well. Directories enable pick-lists of endpoint addresses, queries, and other workflows. Note that I do agree that DNS-CERT is likely a short-term win as we haven't quite nailed down what a Healthcare Provider Directory is, how one would find them, and such.
Slightly concerning is the test step
TE170.314.b.2 – 2.07: The Tester cause the EHR to register the Direct (To) addresses specified in the Transport Testing Tool to be available as a recipient for sending of Direct messages within the EHRIt is possible that the EHR technology might want to have a pick-list for destination addresses, but surely the EHR technology better be able to take just a typed e-mail address. If we really are going to constrain to a pick-list, then why do we need ‘universal discoverability . With a ‘pick-list’ why do we need to have all this discussion around Certificate Authority – and Identity Proofing. We would just need a directory of ‘approved’ addresses. Heck we wouldn't even need S/MIME, as we could have gotten by just fine with a walled-garden security model…
More:
Good points here. John, do you think that they are so focus down stream on the integrity of the data a provider may be looking at? For example I've met several providers that are skeptical of data entered in information system that came from another provider using another type of information system. It's questionable to them. I ask if it appeared on paper would be just as questionable? Providers like to confirm a drug allergy with the patient. And if tje patient is unconscious, paper or electronic can not be confirmed. Further if electronic is from a different vendor or info system even more questionable as the provider is further from the source of the info he/she is reviewing.
ReplyDeleteCould it be that ONC wants to overemphasise the trustworthiness of what they see electronically?
I may be in left field so please comment. I enjoy your insights on the blog.
I do agree that this is a concern for any information not published by that provider themselves. HIE in all forms are challenging to this. I don't think this is related to the problem I outline here. This is simply a case of either (a) Not thinking through the ramifications, or (b) someone protecting their business model that is dependent on this choice.
DeleteTwo comments:
ReplyDelete1. I understand your argument that it would be nice to give Providers the option of using a standard e-mail client. But I think the current approach *does* allow that, if e.g. you configure Thunderbird to talk to your (CEHRT-supplied) HISP, which in turn is responsible for certificate discovery. (Isn't this how the Java bare-metal Direct implementation works?)
2. The test procedures you referenced are for patient-facing functionality (which everyone understands will be web portal-based). In this scenario, the portal is responsible for the heavy lifting of extracting clinical summaries and forwarding them to an address that the patient specifies. Standalone email clients aren't a possibility (because the portal functionality, not the email functionality, is the critical piece).
P.S. I think "TE170.314.b.2 – 2.07" should read "TE170.314.e.1 – 3.05" ?
Josh,
Delete1. But, the HISP software is custom made for healthcare... One could even create a much smaller service that looked like an LDAP directory but proxied the request to DNS-CERT... but that too would be customized code just for healthcare.
2. The test step is common. It will always be. The problem is core to the specification. The problem is caused by consensus group dominated by a viewpoint that was not broad enough and didn't think through the ramifications and future.
I don't disagree with how hard it is to do S/MIME using off-the-shelf software. You and I tried this 2+ years ago, and as knowledgeable people we had trouble.
ReplyDeleteBUT, there are off-the-shelf e-mail services that do off-the-shelf S/MIME.
Larger point is that this solution is much harder than it should be. But I prefer an exchange like HealtheWay,