DNS-SRV Trust Model
Model
Source HISP is ready to send a message on behalf of the Source Endpoint to the Destination Endpoint via a Destination HISP. Source HISP does a query for any "nhind" "SRV" records associated with the domain name of the Destination Endpoint. It gets back a list of responses that look something like this:
IN SRV 100 10 8080 nhin1.hisp.com
IN SRV 102 10 8080 nhin2.hisp.com
IN SRV 104 10 8080 nhin3.hisp.com
In this example, the Destination HISP is "hisp.com", who have defined three different possible "handoff points" for its inbound "nhind" services. 100, 102, and 104 express preference, as does the "10". 8080 is the port the "nhind" service is running on.
In order of preference of each part of the SRV response, the Source HISP then queries through a potential chain of zero to N CNAME records (the hostname nhin1.hisp.com might actually be an alias for one or more specific hostnames). Then, it looks up the A record to resolve that hostname to an actual IP address. The Source HISP then opens a TLS connection to the IP address the A lookup returned, and to the port given in the SRV response. The Source inspects the certificate provided in that connection; if that certificate is not one acceptable to the Source HISP, then the connection is closed and the Source HISP tries the next address - either the next address associated with the same handoff point (as part of a CNAME multiple-address alias), or the very next handoff point from the SRV response, in order of preference.
If all possible TLS connections result in an unacceptable TLS certificate, then the Source HISP returns the message to the Source Endpoint as undeliverable due to no common trust circle.
As an optimization, the Source HISP may wish to cache the certificate it associates with a given connection, so long as it expires that response on a reasonable basis. As a further optimization, the Destination HISP may wish to publish CERT DNS records for each handoff hostname, that the Source HISP can look for in the DNS, using the caching and expiration management tools available in the DNS, so as to avoid opening connections that will fail anyways.
Implications
The idea here is that each handoff point can present a different TLS certificate, working around TLS's restriction of one certificate per connection. If any certificate is acceptable, the message is passed along. If there is no acceptable certificate, then the Source HISP says that the message can not be delivered, because there is no trust circle that includes the Source and Destination HISP.
This does mean that the "circle of trust" is defined by the HISP, and any requirements of being a part of that circle have to be a part of the HISP/endpoint business relationship. While this might seem too coarse-grained, consider that the HISP is possibly in a much better position to evaluate the options and communicate them to their own users, and join new trust circles all the time, than an individual practice would be.
smallfamilypractice.com, when signing up with a HISP, would be told to add one or a few SRV records to their DNS, much as they would be told to add some simple records. The CNAME functionality above allows the HISP to join new trust circles (that is, open new endpoints with TLS certificates associated with that trust circle) without requiring the endpoints to change their DNS settings for their healthdomainnames. Furthermore, smallfamilypractice.com could simultaneously have SRV records pointing to two different HISPs, if it wished to receive messages from two different trust circles that a single HISP would not provide.