Azure API for FHIR Create New Resource with Generate Id

591 Views Asked by At

I am using the Azure API for FHIR service, and I would like to generate a resource with an Id I create on my side. Looking at the docs, it looks like you are supposed to be able to do a PUT request to /, but it doesn't seem to be working. If I do a POST to / and specify my Id, it gets ignored.

In the future, I want it to be able to generate the Ids, but for the "Importing Legacy Data" phase, I want to be able to specify my own Ids to make the linking side of things easier.

Any ideas?

Update The problem I am trying to avoid is having to push all the data to the FHIR Endpoint and then go over everything again to create the links.

2

There are 2 best solutions below

0
On

If the server allows an upsert, you would do the PUT to '/[ResourceType]/[id]', not to just '/'.

For example, if you have a Patient with technical id '123', you could do: PUT [base]/Patient/123

Make sure the Patient resource has its 'id' field set to '123' inside the resource as well. It has to match the id you put on the url.

Another option would be to construct a transaction Bundle, where you can make entries for each resource you want to upsert. You would use the PUT verb and '[ResourceType]/[id]' again for the entry.request details. After constructing the Bundle, you can send it with a POST to the base, so the server knows to process this as a transaction.

Transaction Bundles are also very useful if you have a bunch of resources that are related and reference each other, since the server is required to update all references for new resources inside the Bundle. See http://hl7.org/fhir/http.html#trules for more information about that. Note that not all servers support transactions, just like not all servers allow upserts as Lloyd mentions in his answer.

0
On

Servers are not required to allow external systems to assign ids. Many servers won't support 'upsert' as it risks id collisions. Those that do will typically only enable it in certain circumstances. E.g. all ids are required to be UUIDs, so collisions aren't possible; there's only one source and it's synchronizing with the target system, so it 'owns' the id and there can't be collisions.

Some servers may have a configuration ability to turn on 'upsert' capability if it's been determined to be safe to do.