NHIN-Direct leans towards HealthQuilt Security Model

My last big project, before the skunkworks project I am doing now for Cautious Patient, was as the Chief Architect at HealthQuilt.

HealthQuilt was a prototype project for a Health Information Exchange in Houston T.X. hosted by UT SHIS. (Which just won the status of Regional Extension Center under ARRA . My boss at HealthQuilt, project leader Dr. Kim Dunn will be the director of the new REC. Dr. Dunn built a community of the local “interested parties” in Health IT during the HealthQuilt project. Ultimately, politics (remember this was pre-incentive) would prevent any data being transferred between organizations using our model before funding ran out. But now the community that Dr. Dunn built will be vital in her new role as REC director.

My job at HealthQuilt was to choose which technologies we would use to prototype the HIE. HealthQuilt was committed to Open Source from the beginning, so I was an obvious choice to handle the detailed technology choices. We spent alot of time with  Houston Health Information Security professionals aling with the crews at Mirth and MOSS, designing a workable trust model.

I am happy to say that just as Dr. Dunn will be able to build on the HealthQuilt community for the Houston-based REC, the NHIN-Direct project may decide to reuse some of the concepts (and perhaps some of the code) that we developed at HealthQuilt. Here are some of the basic, core concepts of the HealthQuilt model.

• The Health Information Network should be built using point-to-point ssl VPN or https connections.
• The trust model should use X.509 PKI Certificates.
• It should use many (rather than one) Certificate Authorities (CA).
• Both the recipient and the destination of a given VPN tunnel or https connection must have certificates. This is very different than the PKI model used on the Internet, where servers are generally certified but clients are generally anonymous.
• This “encrypted Health Internet” should run entirely underneath any healthcare protocols. That means trust is handled first at the network level. If some actor in the network is no longer trusted, CRL or blacklists will prevent -any- communication with them, rather than relying solely on relatively young implementations of health protocols to provide adequate encryption.
• The “relatively young implementations of health protocols” should still implement encryption, as though there was no network security in place. (This one is actually Sean Nolans idea.. more later)
• This allows for a natural layering of security, which makes security wonks like me feel all warm and fuzzy.
• The “core NHIN organization” should have a list of “typically trusted CAs” called “anchor CAs” that it recommends to all network participants. This is similar to the way that normal Internet CA’s are “suggested” to you by automatic inclusion in your browser of choice.
• Individual network participants can also choose to trust other CAs, like those provided by a hospital they are affiliated with.
• The job of the CA’s will be (roughly) to make sure that anyone they issue a certificate to is, in fact, a particular clinical entity (doctor, clinic, hospital, etc) who has the right to receive and/or send PHI.
• This means that members of the network do not need to sort out trust relationships on a peer-to-peer basis. They can assume that everyone who the CA trusts is trustworthy, and they can automatically share data with them when a clinical need justifies it.
• If, for some reason, two members of the network do not trust each other, they can still use a blacklist to prevent communication.

The browser providers determine what bar CA’s must reach for automatic inclusion in each browser. That “automatic inclusion” is the foundation of the trust model of the Internet. That is what gets you a secure connection to Amazon to buy a book, even though you do not think too much about “how do I know that is really Amazon?”

So why did HealthQuilt come up with this model? We knew that each institution in the Houston area would need to make trust decisions on its own. They would never tolerate us saying “Here are the ten other hospital systems in the network, take it or leave it”. The answer would always be “leave it”.  Some of our constituents were very concerned that a blanket trust policy would mean that they would trust organizations that they do not have a real-world trust relationship with, i.e. Planned Parenthood clinics vs. Catholic Charity Clinics. In order to participate in the network, they needed to have fine-grain control over the trust decisions. Most participants planned to trust everyone else in the network, but they did not want to trust that the network itself would remove bad actors in the future. The combination of blacklists (which is how a node can cut off communication with another node) and CRL’s (which is how a CA says “I do not love you anymore”)  provide both network and node level control over dealing with “bad-actors”.

Most importantly, the network-level security model is technologically identical to the current Internet trust technology. The policies and the trust decisions are very different, but the technology is basically the same; ssl + x509. That is good, because it means that the trust issues are not entirely handled at a level where new protocols are being developed. If you rely only on message security, and you discover that one implementation was “leaking” information by encrypting slightly less than what was intended in a given “message” that could be a real problem. SSL-vpns and https, using x509 PKI is a known-quantity (not the same thing as “safe” mind you). Using that “underneath” the new stuff that NHIN Direct and CONNECT projects will develop will help ensure that implementation or design mistakes do not automatically imply a broad attack vector.

Moreover, when advances (i.e. quantum cryptography) makes the current Internet Trust model obsolete, it will have to replaced with something. Whatever it is replaced with will have to play at least some of the same roles as the current X509/ssl infrastructure. That means the whole Internet will work with us to upgrade the network trust model.

I should point out that the NHIN Direct team was certainly not doing nothing until I showed up and told them what I had done with HealthQuilt. I think that something very like the basic HealthQuilt Trust model would have been embraced in any case anyway. I am just happy to be able to present a package of thought-out ideas to the NHIN Direct team. Ironically, even before I made my suggestions, Sean Nolan, of Microsoft HealthVault, was already arguing against the “single CA, top down trust model”. Once you make the concession that you are not going to attempt to do trust entirely using CA’s and proxy CA’s (the top down model) then most of the HealthQuilt Trust model, is just incremental obvious choices.

I will be calling this trust model, the “HealthQuilt Trust Model”. This is despite the fact that the NHIN Direct trust model seems like it could justifiably also be called the “Microsoft Model”. Microsoft has some really talented technical people and it makes me feel good to see them reaching the same conclusions that I do, in parallel. Still I seriously doubt that the new NHIN Direct trust model will ever be called “The Microsoft Model” since the name does not actually describe the model at all.  This is good, because the phrase “Microsoft Model” generally makes the hair on the back of my neck stand up and do the polka. It should also be noted that my original ideas on the HealthQuilt model were pretty useless without adjustment from Ignacio Valdes of LinuxMedNews, my brother rick, or David Whitten of WorldVistA and the VA and several of the Mirth engineers and Alesha Adamson of MOSS. All of whom gave me valuable feedback. It is also important to note that the model has improved substantially in response to the excellent thinking done by Brian Behlendorf and the rest of the NHIN Direct Security and Trust Workgroup.

Still, I will be using the name because it is truly indicative of how the trust model should work. It should be like a quilt, legitimately different ideas about trust and security implemented by different organizations, but despite those differences, still connected. The Internet has shown time and time again, that uniformity is not the only way to cooperate.

You can follow whats happening on the NHIN Direct Security and Trust Workgroup forum. If you are truly a glutton for reading, you can read my posts and the responses

• Anchor CAs: Like the browsers but better
• Message vs Transport… and the answer is ‘yes’
• We think “CA” so that users can think “trust”
• Trust Models, Global Trust Concerns, and Questions

-FT