MHD as an API to XCA

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 support in these product/stacks for this. Likely somewhere is needed a Consent management that might be based on BPPC or APPC.

What I will explain is the interactions between PDQm/MHD and XCPD/XCA.  The following diagram shows on the left the FHIR transactions, and on the right the SOAP transactions. This diagram shows the three steps: Patient discovery (PDQm-->XCPD), Document query (MHD-->XCA), and Document retrieve (MHD-->XCA). The three steps are joined by some processing that happens on the client side.

It is very possible that the processing on the client side is to simply do a Document query against all Patients found, and for each DocumentReference returned a Document retrieve. However I would hope that some kind of processing happens to select only the communities of interest, and only the documents of interest.

I don't show the design needed to convert PDQm (FHIR queries) into XCPD queries. I assert that for a given set of normally used queries this is possible. Note that the normally used queries are still a much smaller capability than PDQm or XCPD support. So, think about what is minimally needed, and work on that first.

I don't show the design needed to convert the MHD (FHIR queries) into the XCA queries. I assert that for a given set of normally used queries that are possible, there is a subset that is not hard to convert from FHIR to XCA. See Timebound XDS queries done right

Note that I have not done any extensions beyond what is documented in the PDQm/MHD or XCPD/XCA profiles. It is possible to do some short-cuts. It is possible to do some optimizations. I however here just wanted to put the facts on the table.

The above diagram is built from https://websequencediagrams.com using the following script. I provide it here for your use and enhancement, but also for my own archive of it:

+------------------------------+
title MHD -- XCA

participant Consumer
participant Responder
participant InitiatingGateway
participant RespondingGateway

note left of Responder
Consumer is used as PDQm-Consumer, and MHD-DocumentConsumer
Responder is used as PDQm-Supplier and MHD-DocumentResponder
end note 
note over Consumer
based on some need a patient is of interest
end note over 
Consumer->+Responder: PDQm Patient? blah
Responder->Responder: check if valid request
loop for all Partners in Community
Responder-->InitiatingGateway: trigger discovery

activate InitiatingGateway

InitiatingGateway->+RespondingGateway: XCPD Patient Discovery
RespondingGateway->-InitiatingGateway: found patient alpha @ beta community
InitiatingGateway-->Responder: store result in cache
deactivate InitiatingGateway
end loop
Responder->Consumer: Found all Patient reesources in cache
deactivate Responder

note over Consumer
based on Consumer processing of 
Patient resources returned
some or all Patients are interesting
end note

loop for all Patient entries found
Consumer->Responder: MHD DocumentReference?Patient=ABC&class=XYZ 
activate Responder
Responder->Responder: check if valid request
Responder-->InitiatingGateway: trigger 
activate InitiatingGateway
InitiatingGateway->+RespondingGateway: XCA Find Documents for given parameters
RespondingGateway->-InitiatingGateway: (n) Document metadata entries found
InitiatingGateway-->Responder: store results in cache

deactivate InitiatingGateway
end loop

Responder->Consumer: Found all document metadata entries in cache
deactivate Responder

note over  Consumer
based on Consumer processing of
DocumentReference resources returned
some or all Document Entries 
describe Documents of interest
end note
Consumer->Responder: Retrieve XYZ document
note right of Responder
URL found in DocumentReference is just retrieved (GET)
That URL might have been encoded by Responder to
have all the information necessary to do the XCA 
or it might rely on information in cache
end note
activate Responder
Responder->Responder: check if valid request (look in cache)
Responder-->InitiatingGateway: trigger Retrieve
activate InitiatingGateway
InitiatingGateway->+RespondingGateway: XCA Retrieve Documents
RespondingGateway->-InitiatingGateway: document returned
InitiatingGateway-->Responder: trigger doc available
deactivate InitiatingGateway
Responder->Consumer: document returned
deactivate Responder