Pages

▼

Friday, March 30, 2012

Complexity

HIE solution that is Just as complex as it needs to be and no more complex. (analogous to Occam’s razor)

I have had multiple discussions this week around how complex this or that HIE standard is. This usually comes back to the statements from the HIT Standards NwHIN Power Team evaluation of Direct vs Exchange. In their recommendation they indicate that Exchange was complex. It is amazing how these things keep coming up. I argue that they have two different goals that have overlap. The solution to this overlap is logical progression, not totally different. Thus, we should not be looking to choose one or the other; but rather choose both and apply them to the use-case that they target.

Page count:Given that our government continues to back projects like HITSP and S&I Framework that consider Page Count an important aspect, let’s look at the page count between Direct and Exchange. 

Direct Project                                                                   89 Pages
NwHIN-Exchange Currently in Effect                             133 pages
So using page count alone, Exchange is only 50% more complex than Direct, for all the more functionality of Exchange over Direct. At this rate, I wonder why we would want to use Direct over FAX, FAX doesn’t require any healthcare documentation. Or pony-express, very simple just a man and his horse. Or better yet, smoke signals.

Reality
Yes you caught me… I didn’t include the page counts of the IHE specifications, OASIS specifications, W3C specifications, or IETF specifications that they both reference. It is clear page count is a hard thing to figure out. I would argue too that complexity is also a hard thing to figure out. The only reason why e-mail seems easy today is because the last 20 years have worked out the kinks. In the 80s wrote an SMTP system for DOS, it ran as a TSR. That was not easy to do, but I will admit that anything that could run as a DOS TSR must be pretty simple. Well it didn’t support all the protocols we include today in the simple term ‘e-mail’, and didn’t support S/MIME at all.

There is far more similarity in technology between the two. Where Direct uses MIME, this is very similar to the Exchange use of SOAP carrying multiple parts. One can easily argue that the Direct use of S/MIME to secure the communications is far harder than mutually-authenticated-TLS; yet both rely on X.509 Digital Certificates to prove identity and authentication. I would actually argue that none of this matter at all as these are off-the-shelf libraries that are not specific to healthcare. Even in the healthcare space: Where Direct includes XDM and XDR, Exchange uses XCA and XDR. Much of the complexity of XD* shows up in both, just different modes.

In both cases there are Open-Source reference implementations. Actually for Direct there is only ONE that I know of, whereas Exchange has 2 or more (NIST, Open Health Tools). See: http://wiki.ihe.net/index.php?title=Implementation

complex or neededSo, yes the NwHIN-Exchange specifications are harder, significantly harder. They are more complex because they are trying to achieve more than simple push. This is not in any way to say that Direct isn’t what it should be, it was designed to be a simple push replacement for FAX. What angers me is that blanket arguments of complexity are being used to indicate that Exchange is bad.

The NwHIN-Exchange provides in addition to what Direct can do:
  1. Service Endpoint Configuration Discovery 
  2. Patient Identity discovery
  3. Patient data location discovery
  4. Patient data query, when the data is needed
  5. Pull of documents, when the data is needed
  6. Security model that supports federated identity and layers
  7. Privacy model that supports confidentiality classifications and consents
  8. Metadata that is queryable, yet independent of the document format
    1. type of document (clinical type, format type, mime type)
    2. provenance (author, role, specialty, institution, type)
    3. the patient identity 
    4. tags the privacy/security classification 
    5. integrity protection independent of transport
    6. relationships between documents (predecessor, successor, signs, transform, amendment, etc)
    7. date ranges of the healthcare information
  9. Support for Digital Signatures
  10. Platform for multi-organizational workflows
  11. Deployment models for XDS or other HIE architecture
I likely overstated Exchange, but not by much. And my overstatement is far less than the negativity promulgated by those that do nothing but spread Fear, Uncertainty, and Doubt. I am very glad to help anyone understand, go ahead and ask me a question.
The complexity is really needed. In order to support the above capabilities we need to define a Metadata model that is comprehensive enough without being tied to a specific document type, or being overly descriptive of the healthcare condition. This is a difficult tradeoff but I think XDS* got it right, and have it defined in a way that local policy can choose to be expressive or conservative. In the absence of a National Patient ID, we are forced to do all kinds of tricks to discover where a patient's data might be in a way that doesn't expose that patient unnecessary and has enough controls to allow a really high quality match. See: NwHIN-Exchange use of XCPD. In order to support a privacy and security model that can handle patient consent, yet also handle the fact that this exchange is between competing healthcare organizations, IHE called upon the power of SOAP, SAML, and TLS. Yes these are not a simple as REST, OpenID, and HTTPS; but the additional capabilities are needed in the backbone. This is not inconsistent with mHealth use of REST, OpenID, and HTTPS. There are more...

I am involved in S&I Framework – Data Segmentation for Privacy workgroup. This is not a simple topic, but it is made simple by the fact that IHE considered these use-cases when making that ‘complex’ XDS profile. The thing is that IHE didn’t even consider these things complex, they were very clearly needed given the use-case needs that were brought before us. This long term, yet realistic term, view has paid off. The XD* profiles could have been far more complex. Take a look at all that is in the OASIS ebXML Registry specification, really great stuff that we simply don’t need… yet.

Conclusion
Getting to some goal requires stepping stones. I do think that Direct is an appropriate stepping stone, I think the next one is XDS for regional exchanges, XCA for federation of regional exchanges. Eventually we might get to the attribute level exchanges defined in the PCAST report.

References

No comments:

Post a Comment