MHD: Provide Document Bundle - clarify replaceTo behaviour with transaction

[oliveregger]

Section Number
https://profiles.ihe.net/ITI/MHD/ITI-65.html#2365413-expected-actions
2:3.65.4.1.3 Expected Actions

Issue

The Document Recipient shall process the bundle atomically, analogous to both the Provide and Register Document Set-b [ITI-41] transaction and FHIR “transaction” as specified in http://hl7.org/fhir/R4/http.html#transaction.

If a new document is provided which replaces a previous document, the new DocumentReference is added in the Bundle with a reference to the to be replaced DocumentReference.

ITI-41 with RPLC requires that the replaced DocumentReference will be in 'deprecated' (eq to 'superseded') state. However you need know this 'hidden' behaviour, it is not clear from the FHIR Bundle transaction semantics.

See also discussion on Zulip

Proposed Change
Explicitly add a remark that for replacing a document that the to be replaced DocumentReference has to be added to the transaction bundle with an Update Entry:

The Document Recipient shall process the bundle atomically, analogous to both the Provide and Register Document Set-b [ITI-41] transaction and FHIR “transaction” as specified in http://hl7.org/fhir/R4/http.html#transaction. Note: If a DocumentReference will be replaced, the to be replaced DocumentReference needs to be added and updated to 'superseeded' within the transaction bundle.

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

[JohnMoehrke]

is this preferable to moving to a transaction? It has the downside of requiring the Document Source to provide the to-be-replaced Resource, which XDS did not require. It would certainly be more obvious that this is required.

I think in the case of signs, and appends; this would not be a problem since the new DocumentReference simply points at the previous, there is no change to the previous.

[simoneOnFhir]

IMO, the only sustainable solution is to move to Operation and define the replaces-behaviour as part of the expected business logic. The problem is this: a transaction is a generic thing. It processes whatever is in the bundle in a transactional manner. All implementations must be generic because transactions are not named, we cannot assign a special meaning to one transaction above the others based on a specific constellation of the Bundle's content.
This only works, if the MHD-transaction is the ONLY transaction, the server ever implements and the client ever uses. But how sustainable is that?

How can a server that implements multiple transactions convey to a client which interactions inside a transaction are allowed and which aren't? My assumption has alway been that a client can post any and all permutations of individual REST interactions a server supports (according to their CapabilityStatment) as a transaction. But that is not the case in MHD.

I believe that forcing servers to use the transaction in this very particular manner, prevents them from implementing generic transactions in the future and therefore these server can never be anything but an MHD Endoint.

[JohnMoehrke]

@simoneOnFhir I think I agree with you. Can you propose what the change to ITI-65 would look like, including the definition of the operation? (create a pull-request that we could review at an upcoming call)

[oliveregger]

@JohnMoehrke @simoneOnFhir the original proposal was, that the replaceTo functionality is added in a 'restful' way and in a non XDS grouping this would just work fine with the transaction api and no need to know any semantics behind it. if it would be grouped with an xds system, the implementation could also communicate any conditions not satisfied within the xds environment.

I'm not against defining an operation, but the operation should cover then the replaceTo functionality and not the regular provide and register functionality which can be handled just with the standard fhir transaction semantics.

[JohnMoehrke]

I would like to have some alternative pull-requests we can look at.

[simoneOnFhir]

@oliveregger Yes, the replaceTo issue was the original trigger that started this discussion, but in the meantime I found additional problems described above. Mainly: A transaction is a (random) aggregeation of available RESTful Interactions on a server. However MHD does not define CREATE of DocumentReference, Binary etc. as individually available interactions. They just 'magically' appear inside the transaction, which is a feature for which FHIR has no means of defining this in a CapabilityStatement, unless client and server simply agree on the fact that "the server does whatever MHD says and nothing more". This approach however breaks as soon as the server's functionality goes beyond MHD.

[simoneOnFhir]

We are currently developing the Operation approach for the German 'ISiK' project: https://simplifier.net/isik-dokumentenaustausch/submit-document
The documentation also describes the expected relatesTo behaviour.
However, for this to work in an MHD context, the Operation would need to be expanded to include Lists(SubmissionSet).

Side note: we have found it to be a bit more challenging to express references between parameters, since we do not have a fullUrl property in the Parameter resource...
In our context this isn't much of an issue, since the reference between metadata and pyload can be assumed to be implicit, but as soon as the possibility of submitting multiple documents at once is introduced, this needs to be addressed.

[simoneOnFhir]

Currently discussing best practice for references between Parameters: https://chat.fhir.org/#narrow/stream/179177-conformance/topic/References.20between.20parameters

[oliveregger]

discussion at f2f of variations:

• existing iti-65 should be converted to an operation (1)
• existing iti-65 should be a transaction with replaceTo DocumentReference in the bundle (2): an invariant could be added that a DocumentReference with a superseeded state needs to be referenced in the bundle
• addon replaceTo operation and remove replaceTo behaviour from iti-65 transaction
• undecided or no preference (2)

[JohnMoehrke]

Although we have accepted one solution, other alternative solutions can be presented accepted. Where multiple alternatives can be presented in Public-Comment for decision. @simoneOnFhir please submit a pull request of your solution.