Stream: implementers
Topic: Transaction with PATCH request
Dimitar Dimitrov (Apr 14 2020 at 13:14):
Hello everyone.
I am wondering which is the right format of a transaction with PATCH request in it. I tried with something like that:
{
"resourceType": "Bundle",
"type": "transaction",
"entry": [
{
"resource": [
{
"op": "replace",
"path": "/status",
"value": "completed"
}
],
"request": {
"method": "PATCH",
"url": "MedicationRequest/11"
}
},
{
"fullUrl": "urn:uuid:aa4abd42-985b-461a-b15d-c15c04f5e634",
"resource": {
"resourceType": "MedicationDispense",
"status": "completed",
"medicationReference": {
"reference": "Medication/12",
"display": "AUGMENTIN FILM COATED TABLETS 875/125MG 14"
},
"subject": {
"reference": "Patient/13",
"display": "ГЕОРГИ ДИМИТРОВ"
},
"receiver": {
"display": "Димитър Димитров"
},
"quantity": {
"value": "2",
"unit": "опаковки"
},
"authorizingPrescription": {
"reference": "MedicationRequest/11"
}
},
"request": {
"method": "POST"
}
}
]
}
But it seems that it is not the correct. I didn't found any example in the Internet so please help me with that.
Thanks in advance.
René Spronk (Apr 14 2020 at 13:37):
See http://build.fhir.org/http.html#patch , you'll need to PATCH a Parameters resource, see http://build.fhir.org/fhirpatch.html for example.
Dimitar Dimitrov (Apr 14 2020 at 16:29):
Actually when I make a direct PATCH request everything is OK. In my case I am trying to put a PATCH request in a transaction bundle and execute it along with other request entries in single atomic transaction request. So as far as I saw I can use a PATCH value in the Bundle.request.method, but how I can specify the content of the PATCH request?
René Spronk (Apr 15 2020 at 06:17):
A Parameters resource.
James Agnew (Apr 15 2020 at 11:56):
If you want to use JSONPatch, you can also use a Binary resource as the container in the bundle:
{ "resourceType": "Bundle", "type": "transaction", "entry": [ { "fullUrl": "Patient/1", "resource": { "resourceType": "Binary", "contentType": "application/json-patch+json", "data": "WyB7ICJvcCI6InJlcGxhY2UiLCAicGF0aCI6Ii9hY3RpdmUiLCAidmFsdWUiOmZhbHNlIH0gXQ==" }, "request": { "method": "PATCH", "url": "Patient/1" } } ] }
Sreenivas Shenoy (Apr 16 2020 at 19:45):
Thanks @James Agnew . Isn't there any other way, I can set the patch body directly in the bundle? Directly as in [ { "op":"replace", "path":"/active", "value":false } ] and not the base 64 encoded format?
James Agnew (Apr 16 2020 at 19:51):
No, you can't put a JSON Patch directly into the Bundle because that wouldn't be valid FHIR. The contents of a FHIR Bundle resource needs to be another resource.
Sreenivas Shenoy (Apr 16 2020 at 19:52):
Thanks for the clarification.
Wizard Wu (Apr 17 2020 at 01:54):
The HAPI test server send the request that the content type is json+fhir, and the console will show that "Content type 'application/json+fhir;charset=UTF-8' not supported", how to solvet it? Thank you.
Lloyd McKenzie (Apr 17 2020 at 02:23):
As per the spec (https://build.fhir.org/http.html#mime-type), the required mime type is application/fhir+json. application/json+fhir is not expected to be supported
Wizard Wu (Apr 20 2020 at 06:45):
Lloyd McKenzie said:
As per the spec (https://build.fhir.org/http.html#mime-type), the required mime type is application/fhir+json. application/json+fhir is not expected to be supported
The HAPI test server send the request, and the format of request is application/json+fhir.
René Spronk (Apr 20 2020 at 08:03):
This was the recommended mime type at some time in the past, but has long since modified to be fhir+json. HAPI may still support the old / non-recommended format for backwards compatibility reasons, but it should not be sending that mime type anymore, unless perhaps in responses if one used used json+fhir on ones own Accept: header.
Wizard Wu (Apr 20 2020 at 08:26):
René Spronk said:
This was the recommended mime type at some time in the past, but has long since modified to be fhir+json. HAPI may still support the old / non-recommended format for backwards compatibility reasons, but it should not be sending that mime type anymore, unless perhaps in responses if one used used json+fhir on ones own Accept: header.
I make a subscription resource, when the HAPI test server always send me the application/json+fhir request, and i cannot support the format, and throw a exception in console. How to do the receive the application/json+fhir? And I set the consumes="application/json+fhir", it does not work.
Mirjam Baltus (Apr 20 2020 at 10:14):
@Wizard Wu : Which HAPI server are you using? I'm assuming you send a POST to it with a Subscription resource in the request body. What are the headers you have set on your request?
The public HAPI server will only respond with application/json+fhir when you have set the request Accept or Content-Type header to that value.
Lloyd McKenzie (Apr 20 2020 at 14:19):
@James Agnew
haex (Jun 18 2020 at 12:08):
Hi,
I'm using the smilecdr server and got the error response for my PATCH request: "Invalid Content-Type for PATCH operation: application/fhir+json" The content type application/json+fhir doesn't work neither.
Does anyone has an idea what the problem could be?
Lee Surprenant (Jun 18 2020 at 12:27):
are you trying to use fhirpath patch? i don't think hapi supports that yet
haex (Jun 18 2020 at 12:34):
Don't think so. I just try to add some demo data from https://synthetichealth.github.io/synthea/ via postman to our smileserver.
Lee Surprenant (Jun 18 2020 at 12:35):
OK, then you probably shouldn't be using PATCH. Sounds like you want POST (create) or PUT (create-on-update) as defined at https://www.hl7.org/fhir/http.html ?
haex (Jun 18 2020 at 12:37):
I tried this at first, but there I get the message "Unable to store a Bundle resource on this server with a Bundle.type value of: transaction"
Lee Surprenant (Jun 18 2020 at 12:43):
see https://www.hl7.org/fhir/http.html#transaction
haex (Jun 18 2020 at 12:46):
Yeah, I already read this. Guess the smileserver doesn't support this kind of operation.
Thank you for your help!
Lloyd McKenzie (Jun 18 2020 at 14:23):
Transactions need to be sent to the root endpoint, not the Bundle endpoint
haex (Jun 19 2020 at 08:05):
Your are great! Thank you! That was the problem :)
Ramesh jarabana (Jul 21 2020 at 17:58):
James Agnew said:
If you want to use JSONPatch, you can also use a Binary resource as the container in the bundle:
{ "resourceType": "Bundle", "type": "transaction", "entry": [ { "fullUrl": "Patient/1", "resource": { "resourceType": "Binary", "contentType": "application/json-patch+json", "data": "WyB7ICJvcCI6InJlcGxhY2UiLCAicGF0aCI6Ii9hY3RpdmUiLCAidmFsdWUiOmZhbHNlIH0gXQ==" }, "request": { "method": "PATCH", "url": "Patient/1" } } ] }
Hi James,
Binary Patch is working without conditional check but it's throwing error, whenever I want to validate before patching the resource like set-IF
any help will be appreciated..
Thanks
Ramesh
Lyndon Howie (Apr 13 2021 at 06:49):
I'm looking at implementing transaction bundles using FHIRPath patch and have a use case where we would add or replace an entire resource in the patched resources "contained" array/list. With jsonpatch this can be done in a single add/replace operation as the value can be an object/map. This doesn't seem to be possible with FHIRPath patch, which would require an operation for every field in the resource as there is no "open type" that can be used with the value to specify the value is a resource, or other complex type other than the few that are specifically listed.
Am I correct in my above understanding that replacing a resource in the contained array would require multiple operations using fhirpath patch?
Lloyd McKenzie (Apr 16 2021 at 17:46):
@Bryn Rhodes @Grahame Grieve
Grahame Grieve (Apr 18 2021 at 22:17):
yes that's a limitation that we can't easily address
Alexander Zautke (Oct 01 2021 at 16:10):
I’m currently searching in the spec for an answer under which circumstances a PATCH operation within a transaction counts as “failed” and therefore causes the whole transaction to fail. Is it expected to fail the transaction in case the PATCH operation returns a 404 response code (due to the target not being found)?
Gino Canessa (Oct 01 2021 at 16:24):
The description of patch includes some hints on when to consider it a failure. The description of transaction indicates that "the entire set of changes succeed or fail as a single entity".
Edit: fixed from re-reading the question: I would assume any attempt at a PATCH that doesn't result in a success normally on the server (yes, that is pretty unsatisfying).
Alexander Zautke (Oct 01 2021 at 16:34):
Agreed, that it’s not the happy path. But given that it’s a conditional Patch, there is maybe some room for interpretation here, e.g. as a client I want to specify that if the resource is present then please PATCH it. Otherwise just inform me about the result.
Alexander Zautke (Oct 01 2021 at 16:34):
I just would be in favor of handling it in a common way :)
Gino Canessa (Oct 01 2021 at 16:44):
Yeah - it is tough because a conditional update can serve as a create, but a conditional patch can't be executed. The note in patch specifies that a conditional patch with no matches fails with a 404, but if you have an idea and want to propose changing it, I'd be curious to see what would work.. it is difficult to distinguish 'worked' from 'not found' in success states.
Alexander Zautke (Oct 01 2021 at 16:55):
Our current implementation returns a transaction response bundle where the status is simply 404 but the overall status code is 200. I guess it’s uncommon for a client to check the response code from every entry. That said, if the resource is not referenced anywhere else in the transaction the whole transaction would not need to fail.
Alexander Zautke (Oct 01 2021 at 16:55):
But that’s shifting responsibility to the client, so I guess it’s better to let it fail.
Last updated: Apr 12 2022 at 19:14 UTC
