Submit Health Event Response - Bundle.entry.response element

[mickohanlon23]

The Submit Health Event Transaction expects to be returned: “a DDCC Submit Health Event Response which consists of a Bundle of type batch-response following the FHIR specification for transaction responses.” (According to the Message Semantics Response section of the spec).

The following is how the FHIR specification for transactions responses defines this response:

For a batch, or a successful transaction, the response the server SHALL return a Bundle with type set to batch-response or transaction-response that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. For a failed transaction, the server returns a single OperationOutcome instead of a Bundle.

A client may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and ETag header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the Prefer header.

FHIR Core currently defines an invariant (bdl-4) that makes the Bundle.entry.response element required for all Bundles of type 'batch-response'. But within the response element, only Bundle.entry.response.status is required. According to the language above, should the DDCC Submit Health Event Response Profile additionally be making Bundle.entry.response.location and Bundle.entry.response.etag required, since the spec directly points to this language saying that these elements SHALL be returned?

[lukeaduncan]

I think the FHIR spec is a little vague on some of these and the elements aren't required by a invariant or cardinality. I believe the intention is that those fields should be based on the underlying requirements of the request. So for POST (create), location SHALL be there, but ETag is a SHOULD (if versioning is supported). The wording for PUT (update) is also problematic, as it seems to require etag and lastModified, but the wording could be clearer and it doesn't call out if you don't support versioning. It also says for create from update, location SHOULD be provided.

However, this transaction is of operations and for the return value of the generateHealthCertificate operation, location and etag don't make sense as the resource returned isn't being created locally (and perhaps not at all in some implementations). I think it makes sense if there is a repository that the location be set, but I don't think we can require it. Also, since it's a new document, the version (if supported) would always be 1, so the etag isn't particularly helpful, but again in those cases with no repository or no versioning it wouldn't be available.

I think perhaps one change that would help is to set the url in the request for Submit Health Event Request to make this more clear.

[mickohanlon23]

Both explanations for location and etag not being required make sense to me. Thank you for the detailed explanation!