clair054

I have not written a blog article on the output of the Panel discussion I lead at the ONC Interop Forum . The discussion I wrote up before the event is a good place to start . The panel, as one would expect, did deviate slightly with a much more focus on: Difficulty implementing Privacy controls with the large number of privacy regulations. This complexity becomes very difficult around the edge cases: Going across state lines, Emancipated Minor, Minor transition, Elderly delegated access, etc. The panel members were NOT looking for less privacy rights, just more clear rights.  There is some benefit to federation level overrides such as we now see with Europe GDPR Provenance of the data submitted by the Patient. Where did the Patient get the data? How do we know the Patient hasn't changed the data? Most Patients are good, but some are being nefarious, for example drug seeking behavior. There is a need for clear guidance on minimal Provenance information. The four modes of communicat...

 I presented these same slides at the FHIR DevDays . The overall goal is 15 Minute presentations that build first explaining general Document Sharing (XDS, XCA, etc), then Mobile access to Health Documents (MHD), and finally the Mobile Cross-Enterprise Document Data Element Extraction (mXDE) which orchestrates Query Element Data for Mobile (QEDm). The slide deck is also available to View and download. View Document Sharing Slides View MHD Slides View mXDE Slides

In the last article I show how PDQm can be made Asynchronous by using the FHIR Subscription . This is just one step in the overall interaction that one does with a Cross-Community Document Exchange (XCA). It is however the one that typically has the largest delay. Baseline using Synchronous API Here is a simplified view of a Consumer requesting through a synchronous API to do a Patient Discovery (PD), Query for Documents (QD), and Retrieve Documents (RD). A more detailed view  in previous articles. This high-level view works for MHD as an API to XCA, just as well as using XCA/XDS old-school. Lets imagine there is 200 partners within the exchange. The Patient Discovery must be sent to each one of them. This fan-out is not shown, it is being done by the Service on the right. The Service must wait for the response to come back from each of them. Only when all partners have responded, or some timeout has happened, can the results be returned back to the Consumer.  As I indicated b...

In the last article I covered the basic flow of using PDQm and MHD as an API to an XCPD/XCA environment. This is the classic intention of the current IHE Profiles. But, the reality of XCA communities are that You likely have hundreds of communities to probe Some of those communities will be fast, some will be slow Some communities will be down and never respond The reality is that the time between a Consumer asking a PDQm discovery request, and getting ALL of the results from ALL of the communities, might be many minutes. Yes, many minutes. That long of a time between a RESTful GET (query) and the response is unusual. A typical http RESTful api toolkit likely doesn't wait that long. One solution is to just make sure all your Consumer implementations wait a very long time before giving up and assuming their Responder/InitiatingGateway infrastructure has failed them. How long to wait? This might be a value populated somewhere, like the CapabilityStatement on the Responder, or in a S...

I expected this configuration was well enough explained within the MHD profile with the one paragraph and one diagram in the informative section 33.6.2-1. I find that I need to explain this a bit more than I expected, and have a follow on article that needs this baseline. Often I have to address the fact that XCA is a federation protocol that is addressing many communities . Federation is an important architectural capability allowing many communities to each act on-their-own, while cooperating in a Patient centric way. The concept of simply using  MHD as an API for XCA is over simplifying what actually needs to be done. Even the following diagram still oversimplifies in that not just PDQm and MHD are needed, but also ATNA for basic security, and IUA  (or SMART-on-FHIR) paired with XUA for app and user security. This pairing of OAuth for FHIR with SAML for SOAP is not trivial, but is also not an unusual configuration for these security protocols. I am sure there is suppo...