Stream: implementers
Topic: Resource id's in OperationOutcome?
Michael Christensen (Feb 05 2018 at 11:36):
Without returning the entire resource I was looking at finding a structured way of returning resource id's / resource URLs upon a successful create/update. I thought about putting it in the location part of an OperationOutcome, likes this:
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "Successfully created resource \"Observation/855807/_history/1\" in 48ms"
"location": [
"Observation/855807/_history/1\"
]
}
]
}
But location is supposed to be an XPath, so this seems to violate the intent of location? Is there any nice/simple way of achieving this?
Grahame Grieve (Feb 05 2018 at 19:32):
"finding a structured way of returning resource id's / resource URLs upon a successful create/update" - why? what ids?
Lloyd McKenzie (Feb 05 2018 at 19:46):
The URL for the version should come back in the location header on both operations - and from that you can extract both the resource id and the version. (Though on an update, you should already know the resource id going in...)
Elliot Silver (Feb 05 2018 at 22:09):
Wouldn't adding the HTTP header Prefer: return=minimal work? (http://build.fhir.org/http.html#2.21.0.5.2)
Michael Christensen (Feb 06 2018 at 12:58):
Ok, probably should have explained about the context. Appart from supporting REST-based http communication I am building (FHIR based) services that use Apache Kafka as underlying messaging system (but could be any messaging system). So, I may get an incoming message that tells me to create or update a resource (with resource content as payload of the message). When I'm done with this I would like to tell the world, via Kafka, that/if the request succeeded. The listeners on such a message could typically be interested in knowing what resource was created and where to potentially retrieve the content from. Therefore, I was looking at sending out a message with an OperationOutcome as payload and to have this OperationOutcome contain a url for the version of the resource created/updated. From the description of OperationOutcome it wasn't obvious to me how/if this was legal.
@Lloyd McKenzie If I do a POST of an observation resource to http://fhirtest.uhn.ca/baseDstu3/Observation I get:
{
"resourceType": "OperationOutcome",
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h1>Operation Outcome</h1><table border=\"0\"><tr><td style=\"font-weight: bold;\">INFORMATION</td><td>[]</td><td><pre>Successfully created resource \"Observation/15241/_history/1\" in 3ms</pre></td>\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t</tr>\n\t\t\t<tr>\n\t\t\t\t<td style=\"font-weight: bold;\">INFORMATION</td>\n\t\t\t\t<td>[]</td>\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t<td><pre>No issues detected during validation</pre></td>\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t</tr>\n\t\t</table>\n\t</div>"
},
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "Successfully created resource \"Observation/15241/_history/1\" in 3ms"
},
{
"severity": "information",
"code": "informational",
"diagnostics": "No issues detected during validation"
}
]
}
Are you saying that there ought to be a URL for the version created in a location part of the OperationOutcome?
Jens Villadsen (Feb 06 2018 at 13:50):
@Michael Christensen - check the HTTP header 'location'. See also https://www.hl7.org/fhir/http.html#create
Jens Villadsen (Feb 06 2018 at 14:11):
You could patch the FhirResourceDaoDstu3 (or r4) in the createOperationOutcome and add a value to the location attribute ... given that you use the HAPI FHIR impl.
Michael Christensen (Feb 06 2018 at 14:37):
@Jens Villadsen Ah, that "Location", now I see that @Lloyd McKenzie meant. Thanks. I will probably just do the same in my Kafka messaging as I am designing these messages with a header and body structure as well.
Vassil Peytchev (Feb 06 2018 at 16:02):
If you are using messaging, why not use FHIR messaging? http://build.fhir.org/messaging.html
Lloyd McKenzie (Feb 06 2018 at 18:53):
And if all you're doing is asking for a bunch of creates & updates, you might also look at Batch and Transaction, which have a bit less overhead than messaging - and which don't require site-to-site negotiation about message contents, event codes, etc.
Michael Christensen (Feb 07 2018 at 09:44):
Working on a microservice based infrastructure, very loosely coupled services, event sourcing style messaging. Involves more than just creates and updates and also quite a bit of non-FHIR content. I have had a look at FHIR messaging a while back, but will look again. Thanks.
Last updated: Apr 12 2022 at 19:14 UTC
