CP ITI 1322

[oliveregger]

Incorporates CP 1322, see https://docs.google.com/document/d/1_akpDRB5dXZands28SUM7suXdTGaCBwQ/edit

The MHDS part will be in PR for MHDS

@slagesse-epic could you add a review

[slagesse-epic]

During balloting, it was discussed whether these should be integrated into the TF or into the MHD, MHDS, and PDQm supplements as changes to other specifications, since MHD, MHDS, and PDQm are not yet final text. It seems that the general consensus was that these should go into the supplements.

[JohnMoehrke]

You can't put Trial-Implementation updates into the Technical-Framework. Thus this CP must be made to the MHDS. Yes this means that these other profile updates are added as editor-instructions in the MHDS to a page that does not exist today "Changes to other profiles"

[slagesse-epic]

I think the bulk of this is actually a better fit for MHD, since we can talk about how to translate between XCA and MHD without talking about MHDS.

[JohnMoehrke]

The CP is not about MHD, it is about how to use XCA to federate MHDS communities.

MHD and XCA have been supported directly from the beginning.

[slagesse-epic]

...for example, the new section 18.2.3.3 describes grouping behavior between XCA and MHD and how to map the queries. I would expect that text to be useful to anyone implementing an XCA Responding Gateway grouped with an MHD document consumer regardless of whether the responding community implements MHDS.

[JohnMoehrke]

...for example, the new section 18.2.3.3 describes grouping behavior between XCA and MHD and how to map the queries. I would expect that text to be useful to anyone implementing an XCA Responding Gateway grouped with an MHD document consumer regardless of whether the responding community implements MHDS.

This is a case of a Responding Gateway using an MHD Document Consumer to access the MHDS community (XCA->MHD->MHDS). This is because the ONLY api we have to MHDS is MHD. This is only needed in the case where the community is MHDS.

If the community is XDS this is explained in 18.2.3.2 using an XDS Document Consumer (the logical equivalent)

Are you suggesting that someone would use XCA->MHD->XDS? I guess they could do that, but that is not what we are describing in this CP. This kind of a configuration would likely be lossy in ways that are not necessary.

[slagesse-epic]

I am suggesting that someone might use XCA->MHD, where the community does not implement MHDS. For example, a standalone MHD Document Responder exists in a community with no other IHE integration profiles.

[JohnMoehrke]

I am suggesting that someone might use XCA->MHD, where the community does not implement MHDS. For example, a standalone MHD Document Responder exists in a community with no other IHE integration profiles.

I guess that is possible. It was not part of the scope of the CP.

The reason I am pushing back is because many people have incorrectly thought that MHD didn't support XCA on the client side.

[oliveregger]

I added the CP changes to the other profiles directly to MHDS as suggested, put this PR back go draft that we could reuse it when MDHS gets final text.

[oliveregger]

https://build.fhir.org/ig/IHE/ITI.MHDS/branches/cp-iti-1322/cp.html

[JohnMoehrke]

don't forget to add a note to the top of XCA, and XCPD (in publications repo) indicating that it has changes found in MHDS. (See how XCA deferred response option is mentioned there). This should be done to any Final-Text that has integrated CPs that affect it, but where that integration is in a supplement.

So, this PR could be changed to just doing that.

[oliveregger]

@slagesse-epic can you review again?

[slagesse-epic]

Looks good!