Friday, August 11, 2017

The Privacy Advisor Podcast: Kirk Nahra on the complications of healthcare privacy

I listen to podcasts. I have recently come across "The Privacy Advisor Podcast". From the perspective of Privacy, this podcast does a fantastic job. Further Angelique  is fun to listen to. I suspect each podcast we learn a bit more about her, very unusual for a Privacy Advisor. But then again Privacy Principles do enable the subject to expose their data as they wish, a form of control.

To my blog audience, that tends to focus on Healthcare Privacy, the podcast with Kirk Nahra is fantastic. Kirk has a deep and thorough grasp of "Healthcare Privacy" in the USA, from a reality perspective. Not from a ideology perspective. Thus for those that want to understand WHY is Healthcare Privacy like it is, in the USA, this podcast hits every topic. I will warn that none of the points are fully explained, but all the points are spoken. So if you listen to this, and don't understand a point Kirk is making, then you need to do some research. I fully agree with Kirk's point of view and assessment of why and how we got here. He speaks of many of the struggles that I have participated in over the past 25 years. A he points out, if we were to write Privacy regulations today, it would not look this way.

The Privacy Advisor Podcast: Kirk Nahra on the complications of healthcare privacy
6/30/17 by IAPP Publications Team
Web player
In this episode of The Privacy Advisor Podcast, Kirk Nahra of Wiley Rein talks about the challenges of working in the healthcare space these days, particularly, the challenges healthcare entities have in managing the multitude of third-party vendors and the "ongoing element of risk" involved in trying to ensure not only your organization is in compliance with regulations, but vendors are too. He also discusses the explosion of available data not covered under current healthcare laws, like the data from your wearable devices, and whether that data is regulated by any body of law at all. "We've got this enormous gap right now," and the new administration isn't particularly interested in figuring that out, Nahra says, but he's hopeful U.S. state Attorneys General are going to pick up the slack.Want to keep up with new episodes? Be sure to subscribe to our feed.

Thursday, August 10, 2017

Order Word Understand Not Is

Keith has written a humorous yet very informative article "Order Word Import Not Is". This article points out that although there is a right order for words in a sentence, we tend to understand even when the words are in awful painful order.

So, I very much agree with Keith that people can handle it when words are in diffeent order, and even when they are the wrong word but spelled close. I would argue that all software should also handle the case were elements are not in the defined order. I would assert that this is mostly the case today.

I commonly declare that Postel's Law is absolutely necessary in Interoperability. This is the principle that is given much credit for the success of the Internet. It is that when one sends messages to another system, great care should be taken to follow the specification. While it also tells recipients of messages to be very robust and generous in how it processes messages from others. This bi-directional principle addresses Interoperability two ways. It does not only address Interoperability by declaring that the specification is LAW. It also addresses Interoperability by requiring robust input processing with the intent that the recipient tries really hard to understand what the sender wants to say.

However right now there is an emergence of CDA scorecards, and CDA test tools. These are being very strict regarding the specification, including the order of elements. Thus they throw warnings, sometimes errors, when the elements are out-of-order. These tools then give a POOR score to the CDA document. This poor score is justified, as it is not a quality document.

The problem is, that these poor scores are not an indication of the quality of the data. That is there is no evaluation by these tools of the medical fitness of the medical data. This is not their intent, nor is this possible in a test tool. I am only pointing out that it is a perception that someone that doesn't fully understand the purpose of the tool might improperly come to.

More important these poor scores are not really an indication of how well the data could be processed. That is to say that the CDA document might be well processed with no failures, because recipients are using Postel's Law, and are able to process the XML even with the elements not in perfect order.

Should the tools be changed? No, we just need better tools to explain the output of the tools. For example, the test tool can notice that the failure is because of an out-of-order element. It somewhat does this today. But they complain that the NEXT element is not the one expected. The failure is actually caused by the PREVIOUS element having been inserted too soon.

Indeed, as Keith points out  "Order Word Import Not Is". Thus don't complain that you can't figure out what the "Is" word is... Look earlier and see that "Is" could have been valid had it been inserted sooner.

Wednesday, August 2, 2017

MHD (FHIR DocumentReference) support for Repositories and Communities

The MHD profile is a RESTful API for Document exchange. One use is to use it as a more simple API for discovery and use of Document in a Document Sharing environment such as XDS or XCA. The MHD profile shows this in abstract terms, but abstract diagram does not show a complexity that implementers will be faced with. I have taken those diagrams, and cut them to show only the Document Consumer side. I have also augmented them to show the reality.

XDS and XCA Reality is multiple

The reality is, that within an XDS Affinity Domain, there will be many Document Repositories, each will have their own "repositoryUniqueId". The XDS model allows for multiple Repositories to support environments where each authoring system wants to hold onto their documents until they are Retrieved for use. In XDS, a Document Consumer must know both the documentUniqueID and the repositoryUniqueId in order to do a ITI-43 Retrieve Document Set-b transaction.

Similarly XCA is a "Federation" of "Communities", and thus there are many Communities. Therefore reality in XCA, is that the documentUniqueId, repositoryUniqueId, and homeCommunityId is needed in order to do a ITI-39 Cross Gateway Retrieve. Note that ITI-39 has a degenerate form that s ITI-43, which can also carry the homeCommunityId. This all recognizes that in XCA one must know which community holds the document, and possibly what repository within that community (Another deployment model where a Community is an XDS Affinity Domain).

Where does the repositoryUniqueId, and homeCommunityId go in the DocumentReference Resource?

I have been asked this question multiple times. There is no place in DocumentReference for these two values. This is intended, and there is no need to add an extension.

The MHD Document Consumer never needs to know these two values. They are not helpful to evaluating the metadata. All the metadata that is necessary is in DocumentReference.

However when a MHD Document Consumer requests a document, the MHD Document Responder must know these values in order to appropriately execute the ITI-43 or ITI-39. So where does the Document Responder get these values?????

Parameter Solution

One possible solution is that the MHD Document Responder encoded them into the URL used for the document Retrieve transaction.....   Let me explain...

The Document Responder is in complete control of the DocumentReference.content.attachment.url. It can put any valid URL into this element. The MHD Document Consumer is told it must simply execute a GET using that URL.

So, one could use a "?" Query String


Long Identifier Solution

Elliot suggests a different solution that might fit better a 100% MHD solution, that has better round-trip consistency between the MHD Provide Document Bundle [ITI-65] transaction and the Retrieve Document Set [ITI-43]. This solution does keep with using "Binary" for the document bits. This solution just strings along the various unique identifiers in sequence.

[base-url]/Binary/<documentUniqueId> + "_" + <repositoryUniqueId> [+ "_" + <homeCommunityId>]

During the Provide transaction there would be no homeCommunityId, or it would be very unusual. 

Other Solutions

Other solutions are possible. With this solution everything that a Document Responder needs is handy, thus the DocumentResponder does not need to reference internal data. Holding internal data in a server is an alternative, but requires the DocumentResponder be stateful.

Security Considerations

The URL should not be interpreted as authorization. That is the Document Responder, and any services behind the Document Responder, needs to do authorization checks on every access request. One must be robust to a client manipulating the URL to point at different documentUniqueId, repositoryUniqueId, and homeCommunityId.


There is no need for extensions, no need for these values to be in the DocumentReference for MHD to work properly. However some software/system design is needed to make a working DocumentResponder. The solution I offer is just one possibility. One that I think is elegant.

Questions, Comments, and Criticism welcome.

UPDATES Since original post:

  • Thanks to Elliot for pointing out my failure on "#" fragment.... I changed it to "?"
  • Thanks to David for recommending against use of "Binary" as unnecessary and possibly confusing
  • Thanks to Elliot who convinced me to formally recognize his "_" solution given that it is likely more consistent with FHIR RESTful model.