ONC has found that many Health Information Service Providers (HISPs) are deploying Direct in a way that proactively enables exchange within a given HISP’s boundaries while not offering mechanisms or supporting policies that enable exchange with other HISPs. Such limitations effectively block providers using different HISPs from exchanging patient information. In effect, HISPs are creating “islands of automation using a common standard.”Are they really surprised that it is easier to get trust working within the space that your organization controls, and it is hard to make trust work with others? Yes, Trust is hard; I might add that keeping trust is even harder.
To address these challenges, some HISPs have begun using DURSA-like agreements to enable providers using different HISPs to exchange Direct messages. Once an agreement is executed, HISPs allow their respective users to seamlessly exchange messages. Unfortunately, such peer-to-peer legal agreements are expensive and time-consuming to implement and are cumbersome to monitor and enforce. They are not a realistic long-term basis for scalable trust.
Wait, isn’t that what the NwHIN-Exchange does? Why build something new? I will note that although logically this makes it look like there is a central infrastructure, this is not the case. This is a trust relationship where there is a central broker of trust that is virtually in the center. The conversations still go peer-to-peer without the central broker of trust knowing about day-to-day communications. This is an important concept to grasp that confuses many. Too often I have found that people think that the NwHIN-Exchange has some central servers that know everything that happens, an intermediary. This is simply not true. There is no central core, just central governance.
The document then goes into a set of common policies that they say HISPs and CAs should adhere to. Worrisome word, ‘should’.
The recommendations are mostly right out of the existing DURSA agreements, essentially moving these business-to-business agreements into a template for a business-to-business agreement. However the items they list are not sufficiently detailed.
- Who is responsible for publishing certificates? The protocols are outlined in Direct and S&I; but responsibility to publish is missing. The protocol specification can’t say who is responsible for publishing, but a governance really should.
- A HISP that manages private keys MUST protect them, this is not a ‘well they should probably do a risk assessment if they feel like it might be something that they might want to someday do’. This is not a ‘should’ requirement, it is a MUST. Further, this model really angers me.
- A HISP that manages a trust anchor MUST publish their certificate policies. This item should be in the CA/RA category, not the HISP one. But my point is that a trust anchor MUST publish their certificate policy
- Their certificate criteria force only cross-certified with the Federal Bridge Certification Authority. This is likely where things are going, but forcing this is really forcing the hand of much of the Direct community. Not just the HISP community, but also any large organization that thought they were going to be issuing certificates for their employees.
- The certificate policy also forbids PATIENTS from participating. All the work spent to make sure we had a protocol that was accessible to patients is being washed away in business priorities. This is becoming far more bureaucratic than the NwHIN-Exchange. I could be optimistic and believe that this use-case is the one called for with (8), where users can directly trust a certificate that is otherwise not trusted.
- Last mile encryption – this is a nice statement, but the last mile must also be mutually authenticated as well. We can’t allow non-authenticated users to access information. We can’t allow a trusting user to be miss-directed to a phishing site. Mutual-Authentication is the answer here. It doesn’t need to authenticate the user using TLS client side certificates; but it must authenticate them somehow that meets requirements. The HISP services must be very clearly authenticated as being that specific HISP service; not just any web-server on the internet or even any SSL protected web-service on the internet. This last mile is not easy, hence why I suggest there is no last mile – that S/MIME truly be end-to-end by putting a fully capable e-mail application on the doctors desktop. But this is not favored because there is no HISP business needed, and some see this as a way to make jobs and increase healthcare costs.
- The CA/RA needs to be forced to publish CRL and/or OCSP for certificate revocation checking. They should also be given the responsibility to publish their certificate policy.
This is actually a good start, but it is not in any way ready for execution.
- Healthcare use of X.509 and PKI is trust worthy when managed
- SSL is not broken, Browser based PKI is
- Trusting e-Mail
- S/MIME vs TLS -- Two great solutions for different architectures
- Healthcare Provider Discoverability and building Trust
- Healthcare is not secure - trust suffers
- Universal Health ID -- Enable Privacy
- HIE/HIO Governance, Policies, and Consents