At our last meeting I agreed to try to add some details to why I think we can reasonably expect to bind certificates to individual addresses without being overwhelmed by PKI complexity. Fred has done a great job of beating me to the punch on this with his We Think 'CA' so users can think 'trust' post. I thought that running through a couple of concrete scenarios could help add some more clarity to the way this could play out.

As part of context setting --- I posit that in a given region there is likely to be a small number of authorities that “matter” in terms of ubiquitous exchange. My best guess is the center of gravity in the early days will be successful state HIEs that reuse the policy work they’ve already done to become regional NHIN-D authorities. The big IDNs might create their own authorities to support intra-organization messaging, and maybe we even make progress on a national NHIN-D authority. Exactly how this plays out doesn’t really matter; I’m just trying to give a bit of color to the landscape.

At a small practice ….

Dr. Smith of Small Practice, Inc. wants to sign up her practice for a web-based NHIN-D messaging service. Because she practices in Waltham, MA, she knows that she wants to exchange messages with members of the
NEHEN authority. She sees an advertisement for, an organization that advertises its certification and “easy setup” with NEHEN. “Certified by NEHEN” means that NEHEN has validated the practices of according to its own policies, and granted it a signing certificate issued by its authority. can use this signing certificate to create and manage new child certificates for its customers that root to NEHEN.

Dr Smith signs up Small Practice with After sufficiently proofing that Small Practice can meet the obligations of NEHEN membership, grants Small Practice Inc a Health Domain name ( and access to a web-based administration tool that allows her to set up NHIN-D addresses. She creates two addresses, and

The administration tool also has a section where Dr. Smith can configure the groups she trusts to exchange messages with. This interface might look something like this:


This interface shows that Small Practice is a member of NEHEN; under the covers has used its signing certificate to create an NEHEN-rooted certificate for Small Practice and for each NHIN-D address Dr. Smith creates. Small Practice will be able to automatically exchange messages with any address with an NEHEN rooted certificate. Note that there is no expiration date on this membership, because will automatically renew the certificates for Small Practice as needed behind the scenes.

In addition, Small Practice is willing to exchanges messages with Oncology of Waltham, a specialist practice that they refer to. This specialist is not a member of NEHEN, but the two providers can establish bilateral trust by exchanging certificates without having to share a common authority. Note that they don’t really have to handle the certificate itself – they exchange addresses (e.g.,, and the public certificates can be found based on that well-known “handle”. When the expiration date for the certificate approaches, can automatically use the address to fetch an updated certificate, again avoiding the need for Small Practice to worry about the complexities of PKI.

Finally, there are a number of individuals that Small Practice works with – mostly patients using addresses/certificates provisioned through PHR systems, but also individual doctors. Specific addresses can be trusted using these relationships. Note that patient Sean Nolan can receive messages from Small Practice, but the practice does not wish to receive them – perhaps because Sean sends too much email!

With all this in place, Dr. Smith and her staff can use a simple “webmail” client – part of her account -- to exchange messages with trusted parties – using all the same elements and metaphors they use for “regular” email today. Messages from untrusted sources are either rejected out of hand, or placed into a “Junk” folder for later review.

In the interest of illustration, I’ve made some user interface choices that have implications on the ability of Small Practice to configure their accounts. For example, there is only one set of trust relationships for all addresses created by Small Practice. I’ve also assumed that all organizational trust is mutual, although I believe the core protocol should allow for more granularity. The point is that different HISPs will implement their user interfaces differently, and that’s OK --- it will be a point of competition. I believe our job is to provide the option to express trust relationships to the address level, but for purposes of simplicity that may not be how the features are ultimately expressed for an end user.

In reality, I expect that in most cases the only “trust” management that small providers will actively participate in is to sign up for membership in organizations and hand-approve patient addresses – but more complex relationships will be needed in some cases and that is where the flexibility will save us from becoming irrelevant.

At a large hosptial ….
Waltham Memorial Hospital uses SomeEMR medical record software and SomeEMR has added NHIN-D capability to the product. Each EMR user account can be assigned an NHIN-D address and can conveniently send and receive messages from within the application interface. In addition, the product has the ability to associate NHIN-D addresses with patient records, and to automatically send them a visit summary in the form of a CCD when they leave the institution.

SomeEMR needs to be “hooked up” to a HISP in order to turn on this functionality, using some combination of defined Source-to-HISP protocols and possibly additional (private) interfaces. The Waltham Memorial CIO can choose “enterprise service” from a hosted HISP such as, or they can purchase a HISP server package to run on premise.

The CIO wants to be able to integrate NHIN-D address assignment and PKI management with the institution’s existing provisioning process, so he goes with the on-premise HISPServer option. First, he has to certify Waltham Memorial with NEHEN and be granted a signing certificate, just like He then configures the HISPServer with the certificate, points SomeEMR at the HISPServer instance and is ready to create NHIN-D addresses for his user base – either manually or automatically as EMR accounts are provisioned.

Note that the CIO will have to make a decision about how flexible to be with respect to receiving and sending messages from other organizations. He could choose to allow individual providers to create their own “contact lists” – or they may use a more heavy hand and only allow exchange with organizations officially endorsed by the institution. This is a policy and HISP implementation issue – not one for the NHIN-D protocol.

Meanwhile, back in Gotham City ….
There are an infinite number of permutations and implementations we could outline here. The purpose of these two was to try to make more concrete the implications of some of the trust arguments on the table.

I have tried to show that just because we use granular PKI as the enabling technology, the presence of the HISP in the equation can be a simplifying factor --- without limiting the full flexibility that I believe we need in order to become the transport of choice.

Looking forward to more discussion at our meeting this week!