FHIR Chat · Patch · implementers

Stream: implementers

Topic: Patch

Josh Mandel (Nov 20 2015 at 10:34):

Just thinking through what we could do with jsonpath -- a patch interface like:

PATCH /Patient/123

{
  edits: [{
    op: "ensure-present",
    path: "telecom.where(system='phone' and use='home')",
    value: {
      system: "phone"
      use: "home",
      value: "800-555-1212"
    }
  }]
}

nicola (RIO/SS) (Nov 20 2015 at 11:25):

If fhirpath would be data DSL, it could be done like

Josh Mandel (Nov 20 2015 at 11:26):

Hmm, if you included an example there @nicola I don't see it.

nicola (RIO/SS) (Nov 20 2015 at 11:26):

["Pateint", ["telecome", {system: 'phone', use: 'home'}], {$patch: {value: '434324234'}}]

Josh Mandel (Nov 20 2015 at 11:28):

Wait, what am I looking at? Is that something you'd send as an HTTP body?

nicola (RIO/SS) (Nov 20 2015 at 11:37):

Another version :)

 {Patient: 
  {telecom: 
     { $filter: {system: 'Phone', use: 'home'}, 
       value: 'new one'}}} 

even more composable

Josh Mandel (Nov 20 2015 at 12:23):

Composable in terms of the tree, yes — but I don't understand its relationship with the path language.

Grahame Grieve (May 30 2016 at 22:03):

So does someone want to propose that we add Patch to STU3? or should it just remain a research interest?

Erich Schulz (May 30 2016 at 22:20):

that is one big can of worms!

Erich Schulz (May 30 2016 at 22:22):

this would be linked with reconcilliation wouldn't it?

Erich Schulz (May 30 2016 at 22:23):

and need to reconcile condition, allergy and medication lists?

Lloyd McKenzie (May 30 2016 at 22:27):

It's going to make terminology change proposal management a lot harder if we don't add it. (Though not having been part of the experimentation, I can't evaluate how much it's going to make harder if we do add it . . .)

Grahame Grieve (May 30 2016 at 22:42):

Erich, we have been testing PATCH in connectathons. If we added something, it would be based on the connectathon work.

Grahame Grieve (May 30 2016 at 22:43):

Lloyd, we can use patch in the terminology work even if we don't adopt in the spec.

Chris Grenz (May 31 2016 at 21:14):

My 2 cents are: 1. the connectathons haven't been conclusive, and 2. the proposed methods aren't FHIR, they're just an additional feature a server might add, like supporting gzip-ed content or something...

Grahame Grieve (May 31 2016 at 22:18):

define 'aren't FHIR'

Chris Grenz (Jun 01 2016 at 01:38):

They are pure document manipulation - they don't understand or utilize the FHIR metamodel or profiles, they just manipulate an XML or JSON document. Not that I'm against that...a server could simply indicate support for the JSON patch and XML patch MIME types to indicate support.

Chris Grenz (Jun 01 2016 at 01:39):

Not sure what the standardization provides...maybe just an affirmation that certain MIME types should be interpreted as using a particular implementation.

Grahame Grieve (Jun 01 2016 at 03:10):

encourages adoption, and yes, clarifies how it manifests in a conformance statement

Chris Grenz (Jun 01 2016 at 03:13):

meh..ok...I'll sit back and let others chime in.

Gaute Brakstad (Jun 01 2016 at 12:36):

We already have systems updating certain parts of our Patient resource. Those systems always just edit one specific part of our Patient resource. Having a way to tag that we support that and what elements we support PATCH on would be helpful for documentation purpose.

Jenni Syed (Jun 01 2016 at 21:54):

I'll also state that we're likely implementing patch for a very restricted MU workflow (likely only us as consumers) because of too many challenges trying to do it with full update. So I would be for at least adding some doc to the spec.

Jenni Syed (Jun 01 2016 at 21:55):

We know we're going to risky and non-passive change territory with this, which is why we're limiting scope so we likely only affect ourselves. (It's on top of DSTU 2)

Jenni Syed (Jun 01 2016 at 21:55):

but, it's our "prod beta" and beyond the connectathon proving out to see how it actually works IRL

Jenni Syed (Sep 17 2016 at 05:31):

For those who won't be able to join us in person today for the Connectathon but still want to participate from home...the presentation in the morning and at the conclusion of the Connectathon will be live streamed via this link:
https://attendee.gotowebinar.com/register/7818733115499491330
It will go live today around 9am ET when the Connectathon starts.

Jenni Syed (Sep 17 2016 at 05:33):

Also, if you haven't already, make sure to fill out the spreadsheet and indicate if you will be participating in the patch track: https://docs.google.com/spreadsheets/d/1rrz8yqkG5gHhSEzUvZxP-6_CCFr_6F0FUElFRGmObyw/edit#gid=0

Grahame Grieve (Sep 17 2016 at 13:35):

I made a ballot comment about adding Patch to the spec ;-)

Jenni Syed (Sep 17 2016 at 13:36):

As did I

Jenni Syed (Sep 17 2016 at 13:36):

:)

Chris Grenz (Sep 17 2016 at 13:37):

Is there draft language somewhere at this point?

Grahame Grieve (Sep 17 2016 at 13:45):

Draft language for what?

Chris Grenz (Sep 17 2016 at 14:41):

For the patch operation.

Grahame Grieve (Sep 17 2016 at 14:45):

well, I propose to support both json patch and xml patch as prototyped in the connectathons

Chris Grenz (Sep 17 2016 at 14:47):

I agree, but I'm interested in the language.

Chris Grenz (Sep 17 2016 at 14:48):

e.g. will the support spec be detailed like create or update, or will it be more "servers may support PATCH by implementing these content types and following the X specification".

Grahame Grieve (Sep 17 2016 at 15:01):

I would follow the existing pattern for patch, but I don't undertand your "or"

Chris Grenz (Sep 17 2016 at 15:05):

As they are external standards (but not really, e.g. ANSI/ISO), will we just reference them, or are we going to try and be more specific within the FHIR spec?

Grahame Grieve (Sep 17 2016 at 15:25):

we're going to refer to json and xml patch formats per the connectathon tracks

Jenni Syed (Sep 17 2016 at 16:04):

Some of you were asking for an example payload for a patch request:
[{ "op": "replace", "path": "/status", "value": "completed" }]

This would essentially update the Resource.status element with "completed" (eg: if MedicationOrder, it would complete the order)

Jorge de la Garza (Sep 17 2016 at 16:08):

The RFC for XML patch is very verbose and contains a lot of information that I, as a developer for FHIR, would never need to know. It would be nice to have something in the spec explaining just the relevant bits. The JSON patch RFC isn't as bad but same thing, some explanation relevant to FHIR is better than going through an RFC

Grahame Grieve (Sep 17 2016 at 16:16):

examples? I'll ask for examples from patch participants tomorrow - so if you're working on patch, it would be great if you can capture your examples and put them here:

Grahame Grieve (Sep 17 2016 at 16:17):

http://wiki.hl7.org/index.php?title=FHIR_Patch_Examples

Grahame Grieve (Sep 17 2016 at 16:17):

e.g. before, patch, after sequence, both xml and json

Jorge de la Garza (Sep 17 2016 at 17:21):

I have a bunch of examples (both XML and JSON) that I have been using to test, but I don't have an account to edit the HL7 wiki

Grahame Grieve (Sep 17 2016 at 17:22):

ok, send them to me or Jenni - but you can get an account on the wiki. I think you need to ask @Lloyd McKenzie (registration is not open to public because of continuous spam problems)

Grahame Grieve (Sep 17 2016 at 17:39):

Here's my patch tests:
https://github.com/grahamegrieve/fhirserver/blob/master/tests/json-patch-tests.json
https://github.com/grahamegrieve/fhirserver/blob/master/tests/xml-patch-tests.xml

Jorge de la Garza (Sep 17 2016 at 17:39):

@Grahame Grieve I see on your examples, the XPath selectors all have namespaces. ex: <remove sel="f:doc/f:foo[@t='1']"/> Is that a requirement? What is "f"?

Grahame Grieve (Sep 17 2016 at 17:41):

yes, that's a requirement. yay for @$%#%V namespaces

Grahame Grieve (Sep 17 2016 at 17:41):

f: is fixed by convention. see here:

Grahame Grieve (Sep 17 2016 at 17:43):

http://hl7-fhir.github.io/xml.html#schema

Grahame Grieve (Sep 17 2016 at 17:49):

only it seems we took it out ;-(

Grahame Grieve (Sep 17 2016 at 17:49):

f: for fhir namespace, h for the html namespace. these are the only namespages in FHIR resources

Jorge de la Garza (Sep 17 2016 at 18:26):

@Grahame Grieve What should a JSON patch to your server look like? I tried:
[{"op":"replace", "path":"/identifier/0/value", "value":"67890"}]
on a patient and got a 500 error back: "Error parsing JSON source: Unexpected content at start of JSON: OpenArray at Line 0 (path=[])"
The request has Content-Type=application/json+fhir

Jenni Syed (Sep 17 2016 at 20:02):

FYI: the Cerner server's MedicationStatement currently has an issue. It will respond with a 302 at the moment, and once I push out the latest, it will respond with a version conflict error. If you get to the version conflict, you're probably doing it correctly... the server just has a bug

Grahame Grieve (Sep 17 2016 at 20:15):

@Jorge de la Garza - you need to use a different mime type - there's a mime type for json patch

Peter Girard (Sep 17 2016 at 20:32):

for those java developers, use the https://github.com/flipkart-incubator/zjsonpatch library instead of https://github.com/fge/json-patch as the second library does not generate valid patch json

Jenni Syed (Sep 18 2016 at 14:18):

example med statement body: https://gist.github.com/daliboz/1976cdf0681d9074c8d954aca10487dc

Jenni Syed (Sep 18 2016 at 14:21):

URL: https://fhir.stagingcernerpowerchart.com/stu3/a758f80e-aa74-4118-80aa-98cc75846c76/MedicationStatement
HTTP method is POST. Content-Type is application/fhir+json (or application/json)

Grahame Grieve (Sep 18 2016 at 15:31):

Thanks Jenny for all the patch comments. Added all against the master patch task

Jenni Syed (Sep 18 2016 at 16:15):

Gratzi, sir

Jenni Syed (Sep 18 2016 at 16:15):

For others: the RFC links I had in the presentation again:
HTTP PATCH method: https://tools.ietf.org/html/rfc5789
JSON Patch: https://tools.ietf.org/html/rfc6902
XML Patch: https://tools.ietf.org/html/rfc5261

Brian Postlethwaite (Sep 23 2016 at 20:10):

Has anyone tried this with the .net stack?

Brian Postlethwaite (Sep 23 2016 at 20:21):

And do all the current servers support XMLpatch, or just json patch?

Grahame Grieve (Sep 24 2016 at 01:49):

my server supports both

Richard Ettema (Sep 24 2016 at 16:46):

The AEGIS server also supports both

Brian Postlethwaite (Sep 27 2016 at 12:09):

Thanks

James Agnew (Sep 27 2016 at 20:48):

HAPI actually supports it now too. This was the first time I've ever gone to a connectathon with a plan to build something, and actually finished that thing during the connectathon. :p

Jenni Syed (Nov 07 2016 at 22:36):

So, I've been burried and missed the connectathon track cutoff.

Jenni Syed (Nov 07 2016 at 22:37):

Are we interested in trying Patch with the (hopefully snapshot) spec in Jan that includes it?

Jenni Syed (Nov 07 2016 at 22:37):

And if so, can I still add it? :)

Jenni Syed (Nov 07 2016 at 22:37):

cc @Grahame Grieve

Grahame Grieve (Nov 07 2016 at 22:37):

well, patch is just part of the spec now. There's an open issue around patch as part of a batch/transaction

Grahame Grieve (Nov 11 2016 at 06:26):

@Jenni Syed I am just doing the editorial work to add PATCH to the spec. In the task, we volunteered to add lots of examples - you were going send me yours, but I can't find any record of them.

Grahame Grieve (Nov 11 2016 at 06:26):

anyone else is welcome to contribute patch examples....

Richard Ettema (Nov 11 2016 at 15:29):

The Connectathon 13 PATCH Test Track has a couple simple examples in both json and xml. You can find them in the test track resources folder in the gforge svn here http://gforge.hl7.org/svn/fhir/trunk/connectathons/BaltimoreSep2016/Connectathon13/PATCH/_reference/resources

nicola (RIO/SS) (Nov 11 2016 at 17:01):

@Richard Ettema Nice, could you make this publicly available?

Richard Ettema (Nov 11 2016 at 17:12):

@nicola All of the Connectathon test track TestScripts and fixtures (resources, supporting files) are available in our Touchstone Testing Platform - http://touchstone.com - under the Test Definitions left-hand menu link. You don't need an account to view the Test Definitions; however, you do need an account to execute them.

nicola (RIO/SS) (Nov 11 2016 at 17:15):

thx

Jenni Syed (Nov 11 2016 at 17:16):

@Grahame Grieve Our original ones were on the track proposal. I can add those and more to that examples page. Also, the touchstone ones that Richard mentioned

Grahame Grieve (Nov 11 2016 at 20:37):

well, how do we want them gathered? I had intended to make them available in a set of files with a common format:
tests
test (name)
before patch
patch
after patch

Grahame Grieve (Nov 11 2016 at 20:38):

so that people could use them in their unit tests. And note, I wasn't intending to use testscript here, but something simpler and lower level, focused purely on the patch part

Brian Postlethwaite (Nov 27 2016 at 07:26):

I note in the spec that for PATCH we explicitly have stated the batch/transaction support is not there, but for auditing think that we should extend http://build.fhir.org/valueset-http-verb.html to include PATCH so that it can be specified, and not sure if we should udpate http://build.fhir.org/valueset-audit-event-action.html so that it can be logged more appropriately.

Grahame Grieve (Nov 27 2016 at 08:50):

there's no resource for PATCH, so it won't work. There's a task to define one somewhere for exactly this purpose - it's pretty recent (Nicola and I talked about it at DevDays), but I don't see how it has a track for STU3

Brian Postlethwaite (Nov 27 2016 at 08:52):

For the AuditEvent ation codes would make sense though so you can record that it was done?

Grahame Grieve (Nov 27 2016 at 09:28):

yes. I currently record it as an update, actually

Brian Postlethwaite (Nov 27 2016 at 09:34):

(My server would do that too right now, but thinking should be the other - partial support)

John Moehrke (Nov 28 2016 at 14:03):

I think it is simply an update. Yes there are two ways to update today, but from the big-Verb perspective they are updates. They are either authorized, and successful; or not authorized or otherwise not successful. At the AuditEvent record level that is all that is recorded. AuditEvent is not interested in the element-by-element change.

Grahame Grieve (Nov 28 2016 at 18:44):

I think that ignores that there is a difference between update and patch at the implementation level, even if not at the concept level

Erik Wiffin (Dec 16 2016 at 20:56):

I am extremely late to this conversation, but after looking for PATCH support today and reading what I could find publicly about the draft spec, it seems like there is some dissatisfaction about JSON Patch (https://tools.ietf.org/html/rfc6902). I haven't seen it mentioned anywhere, but there's also a JSON Merge Patch spec (https://tools.ietf.org/html/rfc7396) that I think makes more sense than JSON Patch.

Grahame Grieve (Dec 16 2016 at 21:00):

why do you think it makes more sense? 7396 looks a whole let less capable than 6902 - therefore simpler for easy stuff, but unable to cope with real world patch requirements

Jenni Syed (Dec 16 2016 at 21:01):

For example (real world issues): to modify an array, you have to include the whole array

Erik Wiffin (Dec 16 2016 at 21:02):

I guess for my imagined use case (change "status" of a resource), it's a lot simpler and easier to read

Jenni Syed (Dec 16 2016 at 21:02):

The serializing nulls would also be a surprise for most FHIR developers since it's not allowed by the spec

Grahame Grieve (Dec 16 2016 at 21:03):

well, we don't disallow it here. It's not our style, that's true

Erik Wiffin (Dec 16 2016 at 21:03):

that's fair

Grahame Grieve (Dec 16 2016 at 21:04):

I think that it would be simpler for changing the value of an element that cannot repeat. but as soon as you start dealing with repeats and nesting, the approach collapses

Grahame Grieve (Dec 16 2016 at 21:04):

the fact that it doesn't mention it's limitations suggests to me that it's not well thought out

Erik Wiffin (Dec 16 2016 at 21:08):

I think my biggest attraction to it is that I could maintain the existing structure of my resources, but you're right, working with arrays and sufficiently nested dictionaries would get complicated pretty quickly

Brian Postlethwaite (Jan 20 2017 at 22:22):

Tracker Item 12349 which talks about the new proposal for implementing patch using an operation:
If this is just using the normal parameters resoure type I have an issue with this is backbone elements cannot be used as the paramater.value.
The use case I would like to see an example created for is to add 2 new contacts to a patient, or 2 new participants to a care team, or 2 new concepts to a ValueSet.compose.include.concept

Ewout Kramer (Jan 30 2017 at 15:03):

I would turn this into a gforge issue....

Grahame Grieve (Feb 06 2017 at 03:38):

this is ok; I

Grahame Grieve (Feb 06 2017 at 03:38):

I

Grahame Grieve (Feb 06 2017 at 03:38):

I'm going to put up a server update that demonstrates how this is done. I'll post instructions once I've got it done

Mallesh (Jan 19 2021 at 07:36):

Hi Everyone,

I'm new to FHIR can you help to implement patch in .net

René Spronk (Jan 19 2021 at 07:40):

You may wish to pose that question in the #dotnet stream, you'll have a better chance of getting a response. Please also inform the readers on that stream what you've already tried, and where you got stuck.

Mallesh (Jan 19 2021 at 07:46):

Please anyone share patch code

Lloyd McKenzie (Jan 19 2021 at 15:24):

@Mallesh - There's some guidance here on how best to ask questions that will get a useful answer. One of the keys is "showing your work" - explain what you've already tried and where you're having trouble. The link to the stream devoted to .net is here: #dotnet. That's the best place to raise your question. (Zulip has a large number of streams and newcomers are, by default, only signed up to a couple of them. However, you can always join other ones that are relevant to your interests - and it sounds like .net is one of yours.)

Last updated: Apr 12 2022 at 19:14 UTC