CP-ITI-1116: FHIR Transaction vs soft failures about iti.mhd

[JohnMoehrke]

@jlamy please provide comment and perspective.

[jlamy]

Ok, there are a few separate issues.

First, you are right that the MHD Document Recipient can’t undo the XDS transaction, so what did get persisted needs to be returned. Further, there doesn't seem to be a clear way that the MHD Document Recipient could advertise that Lists or DocumentReference.relatesTo must not be passed.

Second, note that this problem can also happen if the MHD Document Recipient is grouped with an XDR Document Source or an XCDR Initiating Gateway. They don't have to persist anything.

So if we were to adopt a strict reading of FHIR transactions, we could:

• Tightly constrain MHD/XDStar groupings to only allow full-featured XDS
• Switch ITI-65 from transaction to batch (or to an operation or a message), and add our own almost-transaction semantics

But let's look at FHIR transactions. Yes, they are all or nothing, but see: Variations between Submitted data and Retrieved data. There's enough wiggle room here to allow submitted elements within resources and even entire resources to not be saved intentionally: "In fact, for some interoperability paradigms, they're not obligated to store any data at all". So the transaction semantics might be more appropriately described as "If all the resources the server chooses to process can be processed, then the transaction succeeds."

So I agree that the "Partial..." warnings should be ok to return. However, we need more specificity in how to do so:

• For an intentionally unsaved document relationship, I suggest we return the warning only in the entry for the source DocumentReference. Reason: the relatesTo is only in the source DocumentReference, and further, the target DocumentReference may not even be in the same submission.
• For an intentionally unsaved resource (List or DocumentReference), this case is not described at all in base FHIR. Ideally we could get guidance from FHIR-I, but until we do, here's what we are doing in eHealth Exchange:
  • it SHALL Return a Bundle.entry.response.status of 204 (No Content) to indicate the Resource has been processed successfully but has no resource identity,
  • it SHALL omit the .location and .etag elements in the Bundle.entry.response.

[JohnMoehrke]

Is there any examples of what this request and response would look like? I would like to get these so that I can understand better, document it better, and have examples for readers. I think examples, even theoretical and possibly wrong, examples would help move this along.

[JohnMoehrke]

Current assessment: This is not enough of a violation of "Transaction" to be considered non-compliant. Moving to an Operation is not seen as necessary. This because this is defined behaviors for MHD ITI-65 transaction.

change to a closed issue