The Burden of Trust


I am a vocal participant on the NHIN Direct Security and Trust working group. Its a perfect place for me. I love Open Source healthcare, but my background was in InfoSec… and we never really forget our first love.. do we? At the NHIN Direct Security and Trust workgroup, I get to exercise all of my hats at once… and that is fun.

The purpose of NHIN Direct is to design an infrastructure for sending messages with clinical content between clinicians (and their patients). It is basically designed to be an email-like system for delivering health information. It is intend to eventually replace the current NHIN… which is the ad-hoc clinical fax network.

On a recent call, someone from the “Policy” department said something about our current plans to the effect of “I am not sure how putting the burden of Trust Decisions on individual providers will impact the ability of the project to replace the Fax network” I could not talk on the call… I was in a noisy airport… but I was surprised by that characterization of our work. In retrospect I can see how she would read what we are writing and come to the conclusion that we are putting new trust burdens on doctors… but in fact we want to lighten the trust burden they currently carry.

You don’t know the devil that you know

That is probably the most important point. The fax network comes with a very heavy trust burden. But we are used to it, so we rarely pay attention to it. This is a case of “acceptable losses”. Its kind of like Terrorism vs Auto Accidents. Many more people in the world are killed in car accidents each year than are killed by terrorism. The irony is that terrorism is much harder to fix than auto accidents. If the US Govt devoted the same budget to auto accidents that they do to the “War on Terror” we could probably prevent 99% of the auto accidents in the world. But we, as a society “accept” the burden of car crashes… because we are used to them. We have the same problem with medical errors… but that is another post.

So lets take a careful look at the “current trust burden” in the fax network. First, doctors do not actually deal with this problem directly. Typically they hire staff to do faxing. This isolates them from the problems that the “faxer” faces. It also means that they rarely hear of the errors.

“Faxers” fax to patients, and they fax to other clinicians. There are lots and lots of times when something that should have been faxed to Dr. Smith ends up going to Dr. Jones. We only hear about the most extreme cases. In fact before the existence of the NPI database, there was no reliable way to determine if a fax number was valid. If Dr. Adams wanted to send a record to Dr. Smith, his staff called their staff and wrote down the numbers. The numbers get jumbled, mislabelled and lots and lots of errors occur.

We do not hear of the cases where people were killed because information that was in a fax record was faxed to a wrong number. Perhaps sent to the “main hospital” fax line instead of the ER fax line where it was needed. These types of between-institution errors are almost impossible to detect, even the “big picture” at one large hospital is hard to sort out, and when you add another institution… no hope. Instead you get cases that are written off as “we did not know that X… oh well… nobody’s fault… nothing could be done”.

Then of course there is the assumption that fax lines are private. This is the farthest thing from the truth. Faxes, just like regular phone conversations are digitized and sent over the Internet. If a hacker gains control over a main router at a major Internet carrier, then they can re-route phone calls and faxes to themselves as well normal internet traffic. The fax network is actually going over the Internet right now… its just “obscured” rather than “encrypted”.

This is not the only problem with faxes, another problem is that institutions rarely have a firm grasp on how many fax machines are actually in operation. You can plug a computer modem into a wall and have a nearly undetectable new fax line… allowing “insiders” to send files to themselves via fax. In fact, phone lines can generally be re-purposed in to back-channel data ports in a number of ways, faxing is only one of them. Lots of my old Air Force buddies ended up at Securelogix, which is one of the top companies for phone security. They sell a telewall that can help prevent phone lines from being re-purposed. Its just what its name implies, a firewall for telephones. No large institution that I have every heard of that paid for a penetration test that include wardialing has ever had the wardialing effort return 0 rouge fax/modem instances. Clinicians should not assume that they understand their own fax infrastructure.

Even if you are really careful with who you fax to.. the current fax network is that it is difficult to maintain. Lets say that Dr. Smith sells his practice to Dr. Sneaky. If the fax number does not change, then Dr. Sneaky is going to get all of those faxes that were intended for Dr. Smith. Not good.

The problem with comparing the devil you know with the devil that you don’t know is that usually, you don’t actually know the first devil that well at all. The “trust burden” on the Fax network seems light because it is hopelessly brokenĀ  and we all just tolerate it.

A lighter burden

Which brings me to the “trust burden for NHIN Direct”. Our goal with regard to this burden is two fold:

  • When an NHIN Direct user makes a trust decision, it should me more reliable than the equivalent decision on the fax network.
  • Typical NHIN Direct users should be able to avoid directly managing trust at scale, making fewer and therefore better trust decisions.

The first one is easy. Without knowing exactly what standards we will be selecting at the time of the writing, I can already tell you that the security the NHIN Direct network will be an improvement over the Fax network. Moreover, it will provide more and better information to the users of the network than is possible with the fax network. Without going into the gory details, this is because PKI is better than post-it notes full of names and fax numbers for maintaining a secure information transfer.

The second one is a little tricky. What I mean by “trust at scale” is the problem managing lots of peer-to-peer trust relationships. If we have a NHIN where say, a third of all doctors in the Unites States participate, that is still probably over a million people. There is no way that you are going to get a doctor to make a list of all of the doctors that he/she does/does not trust taken from a million person list. Even trying to do peer-to-peer trust on a city level would not work. Hell I would be surprised if it would work even between two hospitals. (If you gave doctors the option to “not trust” some doctors at their own hospital… you would probably still get headaches). The fax trust management problem is a little simpler because you can sometimes aggregate to the organization… several clinicians share the same fax, but even that it is really difficult. Having to manage thousands of trust relationships dramatically increases the probability that you will get one of them wrong.

How do we fix that? We need trust aggregation points. So far there are two of these in our model. The first is at the organization level, just like faxes. Typical NHIN direct addresses for providers working in hospitals or clinics will look something like the “” part of the address is the “health domain name” and you could use that to trust all of the messages that came from that health domain name. The second way is with what we are calling Anchor CAs. For those familiar with the way CAs (Certificate Authorities) work with https, it is basically the same. The difference is that there will be no “automatically included” Certificate Authorities. When you login at amazon your browser makes a secure connection automatically because the person who makes your browser decide for you that you would trust Versign CA certificates. You can find out how your browser developer makes this trust decision for you… but they are still making the decision for you.

That model… where someone else makes your trust decisions for you… is not going to fly in healthcare. The stakes are simply to high to outsource trust in this fashion.

However, the notion of aggregating trust using Certificate Authorities is a good one. Lets imagine that my home town, Houston, decided to setup a Certificate Authority. They would decide on some reasonable policies for things like:

  1. Anti-virus (think Storm Worm not Influenza)
  2. Firewalls
  3. at-rest disk Encryption
  4. Password Strength
  5. Local Authentication (two factor?)
  6. Logging
  7. etc
  8. etc

Then the Houston HIE would create a CA, and that CA would “vouch” for organizations and individuals on the NHIN Direct network. BobsClinic might signup for the CA, then the CA would follow a bunch of steps to verify that BobsClinic was legit and was willing and capable of following the policy… and then the CA would say.. ok we are willing to vouch for BobsClinic.

Most clinics in Houston who wanted to use NHIN Direct could “import” the public key of the local CA. That’s fancy talk for they would accept the vouches that the CA made for all of the organizations that signed up. Those of you with security backgrounds understand that we are talking about a pretty basic CA infrastructure, but we wanted a way to make the trust decisions that clinicians would be making under this model free of unneeded technical language. So we are calling the CA, and all of the people that the CA “vouches” for a “Trust Circle”. It makes sense… if you have not imported the certificate of the CA, you are “outside the circle”, if you have imported the public cert of the CA then you are “inside the circle”.

This “Trust Circle” notion will reduce the number of trust decisions that typical NHIN Direct users will need to make. Of course, it will be really important that clinicians are very careful when they evaluate the policies and enforcement provided by a given CA. Those policies should meet or exceed their internal standards for handling PHI. It is important because you are not just trusting one organization… you are trusting lots of organizations “through” one organization, a much bigger deal.

Trust Circles get around the thorny problem of managing peer to peer relationships, but the also dodge another bullet. They avoid the need for a top-down single CA architecture. Things would be much simpler, technically, if the NHIN (which is a too-vague term BTW) would just setup the one-ring-to-rule them CA and make everyone in the United States follow the same policy for exchanging health information. That is a deal killer for about a hundred reasons, here are a few…

  • You are going to try and force catholic charity hospitals to share information with planned parenthood clinics.. are you kidding?
  • Making psychiatric hospitals message each other in the same way that normal hospitals do?
  • Make children’s hospitals message the same way that normal hospitals do? (kids are not just short people… Think about it.. Does the step dad get NHIN Direct messages for little johnny or only his biological father get them? Tough issues there.)
  • Create a policy that is guaranteed to be legal in all 50 states? (think about the implications of medical marijuana in California alone)

Policy is really really hard, even if you do not assume that you are going to get everyone to agree. Assuming that everyone will agree… makes the NHIN a non-starter.

Trust Circles (plural) gets you out of that problem. When organizations and clinicians can see eye to eye on policy, then they can use NHIN Direct to communicate secure messages… when they can’t see eye to eye… nothing in the NHIN Direct security protocols will attempt to force or even encourage them to compromise.

Another thing to note is that there is nothing in the design that prevents NHIN Direct users from managing trust relationships one at a time. You do not have to join Trust Circles to send messages with NHIN Direct. If you want to “self-sign” your certs and exchange them on floppy disks, in person, with people you trust.. that works too! That is why I used the word “typical” above…

But now we come to the real problem.

The first step is..

Even though the trust burden of the NHIN Direct system will be less than the trust burden of the current fax network… it may not feel that way. The reason is that we have not actually taken responsibility for the trust we place in the fax network. We continue to pretend that everything is fine. But its not. The fax network is irreparably broken and the first step towards fixing it is NOT to try and design a new model without a heavy trust burden, but to recognize that we have problem. Once we do that we can see that indeed “the burden is light”.

3 thoughts on “The Burden of Trust”

  1. Great post.

    One nuance – if the new system (NHIN Direct) is at least as good as the old system and if the new system has more features / functions / convenience – then it will get used, even if the new system is NOT BETTER, but JUST EQUAL TO the old system in some areas…

    We’ve been using the design parameter “at least as good as AND costs no more time than” as a comparator for features / functions in HIT with some success.

    (re: your comment about NHIN DIRECT TRUST)

    Thanks for taking the time to share your thoughts!

Comments are closed.