Tuesday, July 31, 2012

Implementation Guidelines for State HIE Grantees on Direct Infrastructure & Security/Trust Measures for Interoperability

ONC has released to the HIE Grantees a statement on securing Direct. The document starts:
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.
Again, this is the logical next step. Some form of business-to-business agreement is a well matured way to build trust. The NwHIN DURSA is a good model, it is not that hard to read too. Clearly this is not scalable, even if there were only a few HISP providers. But then again there really is no alternative. At least no alternative until there is a centrally managed DURSA trust exchange.

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.

1 comment:

Tuesday, July 24, 2012

Can Direct messages be "delegated/forwarded?"

I got this question offline, and know others are wondering too. The question is actually a Policy question. The technology answer is simple.

The Direct Project put policy completely out-of-scope, saying that it was the sender’s responsibility to determine that they have the necessary authorization and that they have chosen the right target. The Direct Project picks up at that point in the workflow, at the point where there is a need for technology to deliver the message. I know some people want Direct to encompass more, but it does not. And I should not, as that would limit policy and creative software.

Further, the Direct Project has no way to carry policy rules from one place to the other. It is true that there is a TO addressee and when using XDM there is an intendedRecipient. But neither of these technical fields have a policy attached. Just like every email that is sent, there is no way to compel the reader to not share the message with anyone (I had an oops like this just today, sorry about that). Hence why some people put various forms of disclaimers at the bottom of their email, things that have been proven not legally binding as well. Some e-mail packages have actually tried to implement some policies, but without universal use this won't work.

Within the NwHIN-Exchange the highest level policy (DURSA) has clauses in it that forbid one party from re-publishing the document that they got from another party. This means that if you receive a document through the NwHIN-Exchange that you can’t republish that document, it does not restrict you from using the document for the purposeOfUse. It does not restrict any derivative works, your medical summary or diagnosis including evidence from my document. This is a Policy that is defined and enforced by the overall NwHIN-Exchange governance. The NwHIN-Direct does not have such a Policy, and there is lots of resistance to an overall organization.

Note that the S&I Framework – Data Segmentation for Privacy – workgroup is working on this problem in an indirect way. That workgroup is working on specific regulations that mandate that policy in English textual form accompany specific types of data; so they are looking at how to do that. They want to send along restrictions on exactly which individuals can see the data, and what long-term rules must always be applied to even the decomposed attributes from the data. The reality is that this is not something that is done outside of healthcare today, so there isn’t free technology we can leverage. The non-healthcare world is using more of the NwHIN-Exchange model, with pre-negotiated policy principles; and policy applies to a whole-document.

The DirectTrust.ORG is also looking into the use-case you bring up. Specifically they want to force the TO or intendedRecipient to truly be the only one that can use the data. I think this is a mistake that the market-place will push back on. Simply because of Medical Records Retention, and Medical Ethics will prevail. If the data is used for treatment, then it must be incorporated into the local medical record (electronic or not).

Lets just imagine one can come up with a solution, we would need to certify that everyone involved in healthcare, including patients, are all using compliant software. And that it was impossible to hack around it. Impossibility. The sooner we get to that understanding, and lean on policy that is backed by regulation and punishment; the sooner we will make progress. 

A middle ground is that there be e-mail addresses (Direct addresses) that are clearly the individual-for-no-other-eyes, and the individual-and-medical-records. This is not much different than the discussion of an organizational e-mail address, or a departmental one. 

7 comments:

Friday, July 13, 2012

IHE Document Digital Signature - Non-Repudiation

I presented the Document Digital Signature profile to the S&I Framework - esMD workgroup. This group is looking for ways  to have non-repudiation proof of authorship and are hell-bent on using digital signatures. I am not convinced that they yet have the compelling use-case to overcome the 'costs' that come along with Document Digital Signatures. These costs are money, but more so they are resources, changes to workflows, and a long-term commitment. It is  this long-term commitment that usually stops most projects short.

My presentation leveraged much of the things that I have blogged about.
3 comments:

Wednesday, July 11, 2012

Trusted Identity of Physicians in Cyberspace Public Hearing

ONC did another FANTASTIC job of putting together an agenda and gathering experts. Not only that but the coverage of the healthcare space and coverage of the identity space was exceptional. I hope you all were watching this testimony, if not please get the recording. This was also not just the HIT Standards Privacy and Security workgroup but also the HIT Policy Privacy and Security tiger team. The intention was to inform these groups, not to make any decisions. The decisions and discussion will happen in future meetings.

I am a member of the  HIT Standards Privacy and Security workgroup. I really wanted to be physically at the hearing. I had booked hotel and flight; but the day-job got in the way at the last minute. This day-job took me away from the call a few times, each time I really felt I was missing something useful. Pulling the presentations is not sufficient to get the depth of the presentations. 


I duplicate the agenda below, but encourage everyone to go to the HIT Standards site to get any updates or recording. I include the  agenda simply to inspire you to go get the information.


Trusted Identity of Physicians in Cyberspace Public Hearing
Wednesday, July 11, 2012
9:00 am to 3:00 pm/EDT
The DuPont Circle Hotel
1500 New Hampshire Ave NW Washington, DC 20036
How to Participatehttp://altarum.adobeconnect.com/ONChearing/
Meeting Agenda
Meeting Materials


My biggest concerns:

a) Provisioning identities is important, but MORE important is keeping identities accurate, de-provisioning, and dispute handling.
b) Setting identity assurance levels and authentication assurance levels is important; but there is too much focus on perfecting these identities, vs recognizing that any service that has protected resources will in real-time make the assessment on if the identity and credentials offered on a request are sufficient to authorize that request. Meaning that we can actually be using different levels-of-assurance in the NwHIN; with purpose-of-use and data-classification specific enforcement.
c) Timeframe - In a perfect world we can define great identities and design NEW systems to use them. BUT there is much existing software and systems and organizations involved. Retrofitting everything is expensive.
No comments:

Tuesday, July 10, 2012

Are Documents Dead?


As I am looking over potential comments to the mHealth profile, I find Gary's post asking, in the context of the mHealth profile, if Documents are Dead. I don't know why this is relevant to the mHealth profile, except that it is document based, so far. Meaning that the goal of the profile is actually to give access to documents. Thus it does start with the premise that documents do exist and people/systems want access to them. Reminder the profile is actually "Mobile Access to health Documents (MHD)", it is just referred to as mHealth simply for the marketing.

I find it very interesting that Gary uses a Document to indicate that Documents are dead. The blog post is a Document. The format clearly is different than historic documents, but the concept that Gary has taken past experience and research; applied his brain; and produced a new concept that is Documented into a format that tells a story... a document...

The Document is far more the conclusion of a past set of thinking. The blog article is now being split up into datum by the likes of google and bing; it is being recollected in the likes of RSS feeds; and likely republished in some newsletter like deployment. I see these very things happening with healthcare documents. The document is not intended to be an input to a human, it could be; but rather the human is an inference-engine intended to treat a patient given historic knowledge and then document the reasoning and what was done. I certainly hope that humans can get a more relevant format as input than a blunt list of historic documents. But ultimately something must have decomposed the historic information.

There is a circle of information, a document is just one step. And a blog only proves that the "document" has a place on this life-cycle.
1 comment:

Thursday, July 5, 2012

RESTful interface to XDS - Comment NOW!

The IHE ITI mHealth Profile is in Public Comment for only a little bit more. The formal due date is today, but anytime is a good time to comment. I will work hard to get any constructive comments worked into the profile. The IHE IT Infrastructure domain has published just this one new supplement for Public Comment. The supplement is formally “Mobile access to Health Documents (MHD)”, but is often referred to as the mHealth profile. 


I have explained the profile
I have explained the user authentication model


I really want comments on the profile, especially the Open Issues



OPEN ISSUES

As a Public Comment version there are many issues that have come up during the development that are not fully locked down. Most of them are due to the learning-curve of the committee. Thus I really want constructive comments on the whole Profile but specifically on these Open Issues. The open issues are far more detailed in the document, they are basically:
  • Restricted “Create” to ONE document, with derived SubmissionSet
  • No access to SubmissionSet, Folders, and Associations
  • Patient ID is needed as part of URL
  • Bring in hData as framework and thus ATOM in GET path for multiple entries?
  • Conditional get is not supported due to the differences between the semantics of HTTP and XDS concepts of resource age.
  • Do we need more on Security, specifically Audit?
  • JSON use of anonymous objects or not?


6 comments:
Subscribe to: Posts (Atom)