Converting CSV files to FHIR® with Rhapsody
A recent post on fhirblog.com described how a CSV file could be converted into a FHIR® bundle and imported into a FHIR® server. That post used the Node-RED application – let’s take a look at how we could do that with Rhapsody.
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.
Here’s what it looks like:
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 which 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 to 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 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.
®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.