There are a couple of ways that we could do this – but the simplest one is to create a route that matches the one used in the post – here it is:
As you can see, it is almost an identical copy of that post – in fact, a bit more than that as it actually sends the bundle to a FHIR® server to be processed. Take a look at the top line:
The CSV is received via an HTTPS comm point, then the properties filter sets a number of Rhapsody properties such as the REST operation (POST), URL of the FHIR® server, and content type.
Next, there’s a JavaScript filter that converts the CSV into a collection of objects (with properties that reflect the data element – just make the next step more readable).
The object collection is then passed to another JavaScript filter that creates the FHIR® Bundle – it’s almost a copy of the one in the earlier post, with the exception that we were able to use more readable names – rather than col[n].
Here’s what it looks like:
Another option we had was to use the freemarker template filter in place of the JavaScript filter, but since we had JavaScript to work from, this way was easier.
Once we’ve created the Bundle, we post it directly to the FHIR server (rather than just returning it) using the REST client comm point.
The server we’re using is Aidbox – created by Health Samurai out of Russia. (I love the way that FHIR® has such a global reach!).
They provide a fully-featured FHIR® server that supports the functionality we need (transaction processing and conditional updates in particular). That ends the ‘top line’ in the first image above.
The response from Aidbox is processed on the second line – in this case, we’re simply returning it to the client, but we could look inside the response and perform further actions if we wanted to.
Note that the response from Aidbox is also a bundle – with a matching entry for each one in the original bundle – see the spec for details.
Of course, this won’t match the original CSV file (as the resources were created from the CSV) which is one reason why we might do further processing rather than simply returning the response.
There are a couple of things we could do differently.
As in the original post, we used a conditional update for the Patient resource. Looking at the spec, there are a couple of alternatives we could consider.
First up are conditional references (which are valid in a transaction only)
This works in the same way as the conditional update – except that the Patient resource is not replaced if one is found. This may actually be preferable in some cases.
We could have looked at the ‘ifNoneExist’ element in the bundle. This is a conditional create – the resource will be created if does not exist.
But – the extra processing where the references of other resources are adjusted does not occur, so this won’t work for us for the Patient.
But – we could use it to avoid duplicating the Condition resource if we had a unique query parameter to use.
We’ll take a look at ways of avoiding this duplication in my next post.
Learn more about the latest version of Rhapsody here!
®Health Level Seven, HL7, FHIR, and the FHIR [FLAME DESIGN] are registered trademarks of Health Level Seven International, registered with the United States Patent and Trademark Office. The use of these trademarks does not reflect HL7’s endorsement.
