FHIR Chat · OperationOutcome.issue.expression for json-patch · implementers

Stream: implementers

Topic: OperationOutcome.issue.expression for json-patch

view this post on Zulip Dennis Patterson (Nov 16 2020 at 18:30):

In the case that an invalid or unsupported json-patch request body is sent to a server, it presents an interesting challenge for what to populate in the OperationOutcome.issue.expression, since that field is a FHIRPath expression, but the request isn't FHIR (or FHIRPath-based patch).

Example:

PATCH <base url>/Resource/123

[
   {
      "path":"/attribute",
      "op":"replace",
      "value": "replacementValue"
   }
]
  • Option 1: Interpret the PATCH as a PUT and return the expression in reference to the Resource. i.e. Resource.attribute could be the expression if that value is invalid.
  • Option 2: If the need is to point more to an invalid operation, Option 1 may not be possible. That may be more of a $this[0].op. The request wasn't FHIR, so I'm curious for thoughts on this.
  • Option 3: Expressing the FHIRPath as if the original request was a FHIRPatch (Parameters-based) request presents a challenge if you want to point to a particular Parameters.parameter[0].part[?].valueString because part is index-based, but the request wasn't supplied that way.

I lean towards Option 1, but recognize that it may not work for all expressions, hence option 2. Not a fan of option 3.

view this post on Zulip Grahame Grieve (Nov 16 2020 at 21:16):

I'm not a super fan of any of the options. this is something we didn't think of

view this post on Zulip Grahame Grieve (Nov 16 2020 at 21:17):

probably the least worst answer is to just write FHIRPath against the json (or xml in the other case) directly per #2

view this post on Zulip Dennis Patterson (Nov 16 2020 at 21:49):

Not being a FHIRPath expert, and in the absence of a FHIR Resource, am I interpreting "$this[0].op" (or $this[0].path or $this[0].value) being the closest to a least worst representation?

view this post on Zulip Grahame Grieve (Nov 16 2020 at 21:58):

yes

view this post on Zulip Brian Postlethwaite (Nov 18 2020 at 14:13):

And if the location that fails is due to a change of another field (via invariant), but the field itself wasn't changed, Option 1 is the only thing I think you can do.
For me I think Option 1 is the only real option, as you needed to know from the client what the oringinal thing you were patching was to be able to work it out, so if the error comes back as that in the resource, I'm ok with that.
e.g. Invarint on patient that all active fields have a DOB entered, and a patch sets a patient with no DOB to active.

view this post on Zulip Dennis Patterson (Nov 18 2020 at 20:10):

I'm guessing there isn't a one size fits all here. The OperationOutcome might be able to point to the expression within the patch and say that changing the active indicator is the problem because other invariants are unfulfilled, or it could additionally point directly to the fields like DOB that weren't populated. If an "update" operation was sent, $this[0].op might be used to point to the invalid operation.

Option 1 allows for Patient.active rather than Option 2's $this[0].value being an expression of the problem. Option 1 allows somewhat of an intuitive representation of where in the resource the problem exists. Option 2 is there if you have to point to a specific part of the patch request

Last updated: Apr 12 2022 at 19:14 UTC


An HL7 Website -