Stream: implementers
Topic: FHIR "Transaction" Bundle POST... Mimicing on API PaaS?
Michael Cox (Jul 14 2020 at 18:38):
Hello my FHIR friends,
I wanted to come here with a couple questions related to an extension I am building as part of our custom API platform tied to Azure API For FHIR AS A MANAGED SERVICE (the "PaaS" version). As I understand, sending a Transaction-Bundle to this version of FHIR server will not complete the requests as a single atomic transaction... It will handle batch requests, but not transactions for that "atomic" aspect I think. I am going by the rules of the transaction bundle (Delete > Post > Put > Get)
I am just wondering about the most "RESTful" way to bridge the gap of this functionality for certain types of requests....
DELETE: If I send an Http DELETE for a resource on an Azure API For FHIR, what would the best practice be to "undo" this interaction?
- my thinking was, if the Server still persists the resource_id (so that it can say "no longer available" if attempted to retrieve), you could maybe send a PUT with the full resource data in the request to "restore" that resource which was deleted?
- Otherwise, would sending a new POST be correct? I just worry about the resource_id being changed and that breaking things
POST:
- just send an HTTP Delete?
Also: If a GET fails, and there were successful PUT POST and DELETE reqs completed before then unrelated to the GET that is failing, is it still necessary to roll back the previous requests?
Finally, since I am creating a custom flow, what would I need to do to create a new Bundle to return if the transaction request was fully successful?
I was playing around on the HAPI server and saw that the response-schema is something like this:
{
"resourceType": "Bundle",
"id": "5821dd1d-80c7-4b55-a80c-ba82abdfb056",
"type": "transaction-response",
"link": [ {
"relation": "self",
"url": "http://hapi.fhir.org/baseR4"
} ],
"entry": [ {
"response": {
"status": "200 OK",
"location": "Task/1414/_history/2",
"etag": "2",
"lastModified": "2020-06-01T23:37:45.967+00:00"
}
}, {
"response": {
"status": "201 Created",
"location": "QuestionnaireResponse/1390659/_history/1",
"etag": "1",
"lastModified": "2020-07-13T23:07:57.933+00:00"
}
} ]
How can I create a Bundle response like that manually?
Thanks for any and all input as always folks!
Lloyd McKenzie (Jul 14 2020 at 18:55):
You can do an update on a deleted resource to put it back - but the meta.version/eTag and meta.lastUpdated will change. That's going to be your problem in general, actually. There is no way to 'do' and then 'undo' an action without triggering multiple increments of meta.version and meta.lastUpdated as well as (in some systems, anyway), the creation of corresponding Provenance and AuditEvent instances.
The rules on transaction are that if anything fails, the whole thing rolls back. (So don't stick GETs in your transaction if you want to maximize chances of success.) You could submit a change request asking us to change the rules to allow ignoring GET failures. That seems like a reasonable thing to do, but I'm not sure we can get away with it given that transaction is now normative.
Don't really understand your question about a new Bundle. You'll have your results from your Batch. You should just be able to turn your batch-response into a transaction-response. The trick is that the transaction-response conveying failure won't let you indicate which eTags got changed.
Michael Cox (Jul 15 2020 at 22:11):
Lloyd McKenzie said:
You can do an update on a deleted resource to put it back - but the meta.version/eTag and meta.lastUpdated will change. That's going to be your problem in general, actually. There is no way to 'do' and then 'undo' an action without triggering multiple increments of meta.version and meta.lastUpdated as well as (in some systems, anyway), the creation of corresponding Provenance and AuditEvent instances.
The rules on transaction are that if anything fails, the whole thing rolls back. (So don't stick GETs in your transaction if you want to maximize chances of success.) You could submit a change request asking us to change the rules to allow ignoring GET failures. That seems like a reasonable thing to do, but I'm not sure we can get away with it given that transaction is now normative.
Don't really understand your question about a new Bundle. You'll have your results from your Batch. You should just be able to turn your batch-response into a transaction-response. The trick is that the transaction-response conveying failure won't let you indicate which eTags got changed.
Hi Lloyd, thanks as always for the super informative responses.
I understand that GETs would definitely compromise the success rate, for our use case I don't see a lot of GETs being involved.
I wanted ask about what you meant in your last paragraph there... Were you suggesting that I submit the Bundle as a "batch" to my Azure API for FHIR, then "undo" or modify the operations that were completed IF there was one that was rejected? My original thinking was have custom logic parse out the transaction bundle then send each HTTP request independently?
Would I just be better off submitting as batch, checking to ensure all operations succeeded, then modifying the response to read "transaction" instead of "batch"?
Last updated: Apr 12 2022 at 19:14 UTC
