Hi,
I have just submitted a comment to the HITPC governance working group regarding there process for making governance recommendations to ONC. I make the argument that for the most part, comments from HITPC regarding privacy and security architecture have been largely counter-productive because they fail to account for what the chosen NW-HIN (the artist formerly known as NHIN, shortly to be known as the Health Internet) protocols dictate regarding security and privacy architecture. Here is my comment:
I worked on the Security and Trust Working Group for the Direct Project, which forms one of the two approved protocols on the NHIN. I am somewhat informed regarding the other project CONNECT and the IHE protocols it implements.
In the Direct Project Security and Trust working group, we took -great- care to ensure that our work, would not trample the ability of HITPC or ONC to make reasonable (or for that matter unreasonable) decisions about how trust, security and privacy should be made. However, out of necessity, we did have to choose a technology stack and specific protocol configurations in order to get any kind of working system in place. Those decisions were not intended to limit your ability to make policy decisions, except in one important way; to quote the current version of the introduction to our Direct Project Security Overview: “In some cases, these protocols and technologies will come with specific configuration options that will have policy implications and may also present constraints that Direct Project will force on the trust policies of its users.”
In short, we asked that you implement your policy decisions in terms of the technology choices that we made. Most specifically we chose X.509 as a protocol for managing trust relationships. This is the same underlying trust architecture that is implemented in IHE and CONNECT. Rather than honor this basic request, to speak in relevant technological terms, HITPC has largely decided to recommend ‘in the abstract’. HITPC has ignored the fact that the fundamental designs of both Direct and IHE dictate that certain security and policy issues -must- be answered, and renders other issues irrelevant.
For instance, your document asks: ‘When is exchange not considered NW-HIN and, therefore, not subject to NW-HIN governance? ‘ While this may be a relevant question for those under the IHE protocol, the Direct protocol ‘Circle of Trust’ concept supersedes this questions basic premise. Its not the ‘answers’ the question… it just makes it irrelevant. With Circles of Trust participating in the ‘official NW-HIN’ is a fluid concept. Nodes will float freely in and out of any given definition of what ‘official NW-HIN’ means.
However, in your “what to do plans” you note that you expect to: “Establish technical requirements to assure policy and technical interoperability.” With all due respect, that work is largely done, and what little remains will be finished by participants in the Direct and CONNECT projects. Moreover, any ‘governance’ of these issues, that cannot influence the contents of reference implementations of the IHE and Direct protocols is mostly just blowing smoke. ‘policy and technical interoperability’ will be 100% dictated by what the Direct and CONNECT programmers put into those projects. Which means that for any governance body to get ‘policy and technical interoperability’, that body will need to be deeply linked in with the developers of those projects. So far there has been a substantial breakdown between what we the developers have asked for as far as policy guidance and what we have been given. Most of the advice from the Security and Privacy Tiger Team, while well-intentioned, made extremely poor technical assumptions and did not begin to approach the actual issues that we needed to address. For the most part, HITPC discussions of Security and Privacy have been a distraction to those of us actually deciding how things where going to be implemented.
Which brings me to what I think is the really only relevant issue here: Who should be on the governance board for the NW-HIN.
The answer to that question is pretty straight forward to me: You need to have at least one representatives from the Security and Trust developers from each of the two projects. Preferably the people who are actually involved with the implementation of the relevant portions of the code. (which rules me out sadly).
Moreover, -every- other member of the governance body should be well-versed in X-509. This means that it should be made up -entirely- of people who are both technology and policy fluent. If the members of a governance board are uncomfortable discussing revocation lists, and CA chain of trust or cross-certification intelligently, then they do not belong on the governance body for any portion of the NW-HIN. There are enough clinicians, who are capable of meeting those requirements that we have no reason not to expect this level of competence. Moreover, you should fully expect that the governance body will largely ignore your abstract questions and recommendations, and instead focus on those security and privacy issues that bubble up from our protocol choices, and start to ignore those that issues that are largely handled in-protocol.
Regards,
-FT
Please consider liking this comment if you have felt some of the same frustrations.
Regards,
-FT