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.
Also:
- 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
John,
ReplyDeleteAs I see it there is a HISP business model doing S/MIME on the doctors desktop using Direct. This is closer to the "one level above Fax" simplicity that originally got people excited about Direct.
The way I have designed this Direct implementation, is that it provides RA functions at 800-63 LOA 3, uses an outside CA with public trust anchors with equivalent medium assurance policy OIDs mapped to the FBCA and stores those X.509v3 certificates in a Provider Directory that has attributes that meet the S&I use case 2 for electronic endpoints.
In this case the Direct Address is one of many possible endpoints in PD and dependent on whether there is a documented implementation per long discussions with Karen.
The gap analysis I did indicated that the providers were not comfortable with S/MIME and the relative complexity of managing individual certificates.
The way very heavy users of PKI deal with this, like Boeing, is to rely on a trusted source of up to date Certificates, publish their own Certificates through an LDAP proxy which gives one the correct CERT if you already know the email address. The rest of the providers can use their CERT to authenticate to the Directory (as per the original X.509v1 design) so they are not anonymous for the more sensitive attributes. The same CERT that does S/MIME also does client authentication to the Directory as the design originally was defined.
Right now, as Claudia Williams noted, most of the HISPs do not want to publish their trust anchors in a readily available way, and in fact I have seen a requirement for certification which states the trust anchors must be kept confidential. I don't think that leverages the power of the Internet to really extend the HIT data informatics model.
We know the Internet is a bad neighborhood, but it's a basic crypto principle from Kerkhoff in 1883 to Shannon 1945 that it is the secret key that must stay secret, and the crypto system must survive revealing anything else to be secure.
Even if Doctors were put in a secret protected class, (like we need to protect NSA and CIA identities and witness protection by Federal law), it would not make sense to do so from a RBAC point of view since they function in public, with a few exceptions.
Thus by providing a local LDAP resource designed to replicate from the HISP, and the X.500/LDAP Directory which the HISP maintains, the increased security of end to end encryption is achieved, at lower security risk to the HISP since it sees no PHI.
The HISP can validate that a message has in fact been delivered, (the client can do encrypted MDNs) or run reports, or place an e-discovery hold if required, but the decision to open up the message must be done by the sender or recipient. I suspect a lack of simple access to this data stream is objected to by certain principles in national security, which must be policy balanced by international legal conventions that put medical data outside of military data gathering cyberwarfare access. As such I have used a simple meta tag approach for now of a recognizable and registered string OID that can be included in the X- headers indicating special handling.
This pushes some of the risk back to the desktop STA, which then becomes a new gap, so remedial security analysis/assessment is also offered for MU2.
The downside is the inability to do a mux of the Connect and Direct streams since it is truly point to point. We have virtualized that behind the STA with a mesh pub-sub architecture that simply uses the STA for secure transport.
The fact that the HISP can replicate with the State shared services layer in the design concept, and then the STA can pull CERTs from DNS and LDAP (some code to be written or imported from DP RI) or at some point access the c=US Directory, (of which part is now at the FBCA) specifically running IHE HPD in one area of the X.500 DMD allows for everyone to participate, and still maintain their functional control of their organizational domains.