by: Dr. Uri Lerner

 

The Challenge of Updating Healthcare Data

In every healthcare organization and in almost every imaginable scenario, we sometimes face the need to update existing data. Although it is not a desirable operation, especially when discussing the medical domain (With regards to legal implications), but sometimes it is necessary.

When managing a FHIR repository that holds large amounts of data, complex resource structures and often a very interlaced network of referenced resources, such an update might be a challenging and very time-consuming mission, where you need to extract the relevant resources from the server, update what needs to be updated, and then PUT them back in, maintaining all relationships.

 

Introducing the PATCH Operation

Here, the PATCH operation comes in handy. It allows you to alter one element (or more) in an existing resource on the server, using simple HTTP operation. The syntax is fairly straightforward as detailed here: [Link], and you can perform various operations – add or remove an element, replace a value with a new one or move\copy an existing value between different elements within the resource. A conditional Patch is also an option, to change data only if needs be.

 

 

The Limitations of Single Resource Updates

When discussing updating a single resource, this might suffice. However, there are many scenarios for which this is not the case. Imagine a FHIR repository, containing lab results and associated data from a large hospital. As we discussed previously here, each lab “operation” results in many different resources, interconnected and data-rich.

In some cases, we would like to update one element for some of those resources, at once, maybe for a single patient (on multiple results), or for a given test (for multiple patients). We will have some common denominator, by which we can get the ids for all the resources that need to be updated. Usually, this is the time to create a bundle, gather all our operations, and post them to the server.

Alas, in this scenario, this is not so straightforward; most FHIR servers do not support using FHIRPath patch in a bundle containing parameters resources (as detailed in the FHIR spec linked above), and we need to use a workaround.

 

 

The JSONPatch Solution

Lucky for us, such a solution exists. We can use JSONPatch document, tailored to our needs, and POST it to the server within a bundle, for as many resources as we desire. However, you’re probably wondering how a bundle supports JSONPatch document, where it must hold only resources as payload?

The answer lies with the Binary resource. When encoding our document as base64 and adding the header “application/json-patch+json”, the server knows to interpret our request and update the resource accordingly.

 

 

Real-Life Example: Updating Lab Results Status

So, let’s look at a real-life example: due to a recall notice from the manufacturer of one of the lab’s analytical devices, the status of all observations obtained from that device (according to the test code) should change to “cancelled”, regardless of the patient they reference.

The first step is to obtain the ids of the resources we want to find, by querying the server. Let’s assume the results include the following resources: “800883349-20250127100000-6”, “800883349-20250127100000-11” and “800883349-20250127100000-13”.

The next step is creating our Patch operation, where we want to replace the status with the value cancelled.

The JSONPatch document would look like this:

Then, we need to wrap this document within a Binary resource, not forgetting to encode it as base64 and defining the proper header for the JSONPatch operation:

Constructing the Bundle

The final preparation step is to construct our bundle, which contains three entries. Notice that the proper syntax for this operation requires that entry.fullUrl element will hold the same path as entry.request.url:

That is it. Now all we need to do is POST this bundle to our server, make sure we get a “200 OK” response and our resources are updated.

 

General Principles for More Complex Scenarios

This example is of a relatively simple scenario, with the same type of resource, same single element and same operation. You will probably encounter (if haven’t already) more complex cases, but the principle remains the same:

1. 1. Obtain target resource ids.
   2. Phrase the correct JSONPatch document and encode in base64.
   3. Wrap it in Binary resource with the proper header.
   4. Construct the bundle, while maintaining correct fullURL and url elements for all resources.
   5. Post to server.

Summary

To summarize, in this post we discuss a simple approach to update multiple resources on a FHIR server using the PATCH operation and bundles, to save time and complexity that derive from the need to recreate the entire resource just to change one element. We hope this will someday be useful in your implementations. 

Feel free to reply or contact us with any questions!