A common operation with a data store is GET or CREATE, and I was hoping to achieve this using Conditional Create of resrouces in FHIR, but the current specification prevents this:

One Match: The server ignores the post and returns 200 OK.

I was expecting Conditional Create to return Location, ETag and LastModified headers the same way regardless whether resource was created or already existed. I also think it would make sense for Conditional Create to interact with Prefer header the same way. My thinking is, server had to perform the search to resolve the condition already, so there is little overhead in returning the headers/resource back to the client.

This change should also apply when Conditional Create is used in a batch or transaction, where Location, ETag and LastModified headers should be set in corresponding properties in Bundle.entry.response and resource returned if requested with Prefer header (to match the existing behaviour for regular Create).

I would like to propose a change to the Conditional Create definition when One Match is found to something among the lines of:

One Match: The server returns the result of the search on the condition