Setting property values to "null" when submitting FHIR objects via FHIR2 module

Likely a question for @ibacher but posting here for all.

When using the FHIR module to post FHIR resources, is there a pattern for telling the FHIR module to explicity set a field value to null?

Probably easier to understand with an explanation: I’m currently working on the Dispensing ESM, and, specifically, editing a MedicationDispense object. I was testing the use case where the dispenser substitutes a drug and sets the substitution type and reason properties on a Medication Dispense, but then updated the element and, in the form, sets the values back to null. The issue is that if those values are empty/null, the underlying OpenMRS Medication Dispense object fields don’t get set to null (and therefore keep their original value), it just skips setting the field on the OpenMRS object enitrely:

It would be straightforward to add an else clause, ie:

if (substitution.hasType()) {
else {

… but taking a quick look, it seems like there are a lot places throughout the FHIR2 code we’d have to do this, I was wondering if there was already a means to do this I was missing…

fyi @mseaton


Take care, Mark

No, you’re right that there’s no obvious way to do this. So there are a few things going on here:

  1. With updates, I wanted to be able to support partial updates, i.e., where the client only sends the changed fields in the resource instead of needing to echo back everything. That’s not necessarily required or even encouraged by the spec, but the semantics of actual patch requests are a bit complicated.
  2. In some cases we don’t support all of the fields that OpenMRS can store (for example, most attributes) and so it seemed like the FHIR APIs would always be managing only a subset of values and if you needed to do something we didn’t support, I kind of assumed you could use the REST API.

That said, there is utility in being able to clear out values… I wonder if there’s a way to detect whether a user explicitly set a field to null as opposed to just omitting it?

Thanks @ibacher … yeah, everything you said makes sense, I was just hoping a solution had already been figured out. :slight_smile: Let me poke around a bit, surely something other FHIR uses must have had to deal with? It definitely will be a blocker to using FHIR to transmit data from the UI to the backend for data entry.

Take care, Mark

So, there seems to be a weakness in the FHIR implementation; specifically the implementation of the has...() checks for the presence of an element on a resource (like hasType()) generally looks something like this:

return type != null && !type.isEmpty();

So, in other words, there’s no way to use the has...() functions to distinguish between a value that wasn’t supplied at all and a value that was explicitly set to a blank value. Without the ability to make that distinction, we kind of don’t have a simple path forward.

There are basically two ways I can think of to work around this:

  1. Just drop support for partial updates and actually add support for PATCH operations for cases where partial updates are important. While this requires a fair bit of changes to the code, they should be quite straight-forward and this would put us in a place that I think we’d be doing what the average consumer would expect a FHIR API to do. This does mean we’d need to ensure that frontend code talking to the backend was always echoing back all the relevant properties of the FHIR object (basically, any fields not in the meta attribute).
  2. We implement support for an extension to indicate whether or not a field was explicitly set as empty and use the presence of that extension to explicitly set a field to null. This is allowable FHIR and would permit us to continue supporting partial updates, but is non-standard and certainly not what a default FHIR consumer would expect.

I think I’ve talked myself into option 1… We can probably handle this in stages instead of needing to fix everything all at once.

In principal, support for both JsonPatch syntax and XmlPatch syntax is not hard. There are existing Java libraries supporting these (since their generic) and, coding-wise, it’s just a matter of:

  1. Loading the existing record and converting it to the appropriate document type (JSON or XML)
  2. Call the third-party library to apply the requested changes.
  3. Parse the resulting resource and run it through the translator to save things.

There’s a FHIR-specific PATCH syntax which would likely require a bit of coding to support, though in principle, the idea is the same as the above.

Cool, I’m likely onboard with option #1… I was in the midst of posing the HAPI Fhir google group when I saw your post, so I finished that message in case anyone has any bright ideas, see:

Take care, Mark

Definitely hoping I’ve missed something!