FHIR Chat · Patch in Transactions · implementers

Stream: implementers

Topic: Patch in Transactions

emilio (Jan 25 2018 at 19:45):

Is there a way to include patch operations in the JSON-patch fromat inside transactions?
I see that using the FHIRPath Patch is valid (although I couldn't find any examples of its being used in transaction) but I'm implementing a server in Javascript and XML is a very tedious format to handle.
Is there a way to encode FHIRPath Patch in JSON?

Eric Haas (Jan 25 2018 at 20:40):

Just making sure you know you can use either JSON or XML for the wire format

Eric Haas (Jan 25 2018 at 20:41):

Patch in JSON is described here: http://build.fhir.org/http.html

emilio (Jan 25 2018 at 20:44):

@Eric Haas But how would you make a FHIRPath patch in JSON? I can't find an example.

emilio (Jan 25 2018 at 20:46):

And yes, I saw what is written about Patch and JSON-Patch in http://build.fhir.org/http.html but I'm interested in Patch as part of a transaction, where, as I understand, json-patch is not valid.

Eric Haas (Jan 25 2018 at 20:51):

I did a paper example here-: https://argonautproject.github.io/scheduling/patient-scheduling.html#examples-1

I did test it out on the hapi test server.

Eric Haas (Jan 25 2018 at 20:52):

not sure about Patch in transactions - good question

emilio (Jan 25 2018 at 20:57):

Yes, What you have in that example is clear to me, I mean, the fact that you can PATCH with either json-patch or fhirPath.
My questions are:
1) Is it valid to use json-patch in a transaction?
2) Is it valid to use fhirPath Patch in a transaction?
3) How do you encode a fhirPath Patch in JSON (and use it in a transaction)?

Grahame Grieve (Jan 26 2018 at 00:48):

it is not valid to use json-patch in a transaction

Grahame Grieve (Jan 26 2018 at 00:49):

it is valid to use a fhirpath patch in a transaction - see http://build.fhir.org/fhirpatch.html for an example fhirpath patch

emilio (Jan 26 2018 at 01:58):

@Grahame Grieve Thanks, but what about my third question (fhirPath Patch as JSON)?

Grahame Grieve (Jan 26 2018 at 02:27):

well, it would be the json equivalent of the xml form in that link

Grahame Grieve (Jan 26 2018 at 02:28):

{
  "resourceType" : "Parameters",
  "parameter" : [
    {
      "name" : "operation",
      "part" : [
        {
          "name" : "type",
          "valueCode" : "add"
        },
        {
          "name" : "path",
          "valueString" : "Patient"
        },
        {
          "name" : "name",
          "valueString" : "birthDate"
        },
        {
          "name" : "value",
          "valueDate" : "1930-01-01"
        }
      ]
    }
  ]
}

Michael Calderero (Sep 26 2018 at 12:48):

Additional question regarding this.

I'm looking at http://build.fhir.org/http.html#trules and I don't see the order at which PATCH interactions should be executed (e.g. after POSTs, PUTs, or ?). Is there some guidance?

Lloyd McKenzie (Sep 26 2018 at 16:06):

Sounds like a good thing to raise as a change request.

Michael Calderero (Sep 27 2018 at 01:09):

GF#18300. Thanks.

Michael Calderero (Oct 05 2018 at 12:41):

Does STU3 provide support for putting PATCH operations in a batch/transaction interaction?

My assumption is no.

Even though http://hl7.org/fhir/STU3/http.html#patch says at the very end that PATCH is supported for batch and interaction transactions, you actually cannot build a STU3 batch or transaction bundle with a PATCH request in it because http://hl7.org/fhir/STU3/valueset-http-verb.html doesn't list out PATCH, and the binding on http://hl7.org/fhir/STU3/bundle-definitions.html#Bundle.entry.request.method is required.

Is my interpretation correct? We have to use R4 to be able to use PATCH in a batch/transaction bundle?

Lloyd McKenzie (Oct 05 2018 at 12:43):

The way I'd phrase is is that the R3 behavior is "undefined". Systems can certainly choose to support it, but can't count on it being supported.

Michael Calderero (Oct 05 2018 at 12:52):

We're using HAPI and my understanding is the STU3 definitions of its classes are generated. We could certainly fork it and add the necessary enums to HTTPVerb, but we'd rather not do that if we can avoid it.

I'm guessing my real question is is STU3 set in stone, or can it be updated via an errata (like for this one)? It would be nice if this were possible (it would make it look more official) and then perhaps it would flow down to the definitions HAPI uses for autogenerating the classes.

Lloyd McKenzie (Oct 05 2018 at 13:10):

STU 3 is more or less set in stone. Updating it requires a large number of person-hours and there are also rules about what changes can retroactively be made to a balloted specification. Thus in the past we've only done it when either a tooling issue meant that some of the artifacts where technically non-useable or when there was a serious security hole - and even then, we made the bare minimum change possible. This change would be the introduction of new capability and thus a "substantive change" which is prohibited under HL7's rules. While implementers are free to pre-adopt conventions from future releases (and implementation guides could theoretically mandate that), past releases won't be changed.

Brian Postlethwaite (Oct 05 2018 at 15:00):

Had this been resolved in R4?

Lloyd McKenzie (Oct 05 2018 at 15:19):

Yes. We approved a change request around this to clarify it at this WGM.

Brian Postlethwaite (Oct 05 2018 at 16:47):

Thanks, I just checked too connectivity getting limited now.

Last updated: Apr 12 2022 at 19:14 UTC