Stream: implementers
Topic: Connectathon Patch Stream
Grahame Grieve (May 05 2016 at 07:07):
Looking at the patch connectathon details, it's really unclear to me what the correct mime type for the patch is. For JSON, I used application/json-patch+json. It would seem that we should use application/patch-ops-error+xml for the XML patch, but it looks like the test scripts are using the standard fhir xml mime type?
James Agnew (May 05 2016 at 11:22):
Definitely using the FHIR ones is wrong, since these aren't FHIR documents.
Using the ones you proposed, with the normal application/json and application/xml being accepted by the server sounds like good behaviour to me. IMO the server should reject the +fhir variants.
Grahame Grieve (May 05 2016 at 11:23):
both the json patch and xml patch define their own mime types. we should use those
James Agnew (May 05 2016 at 11:24):
Those being application/json-patch+json and application/patch-ops-error+xml right? I am in agreement.
Grahame Grieve (May 05 2016 at 11:28):
y
Grahame Grieve (May 05 2016 at 11:29):
sorry, I didn't parse what you wrote correctly
Grahame Grieve (May 06 2016 at 07:05):
finally getting to this: the patch specc says
Grahame Grieve (May 06 2016 at 07:05):
As the schema defined in this document does not declare any target namespace, the type definitions inherit the target namespace of the including schema.
Grahame Grieve (May 06 2016 at 07:05):
hence we need to define a namespace. I'd prefer not to use http://hl7.org/fhir
Grahame Grieve (May 06 2016 at 07:05):
opinions?
Grahame Grieve (May 06 2016 at 07:19):
I'm not enjoying reading the XML Patch specification. In particular, the section "Departures from XPath Requirements" - does anyone seriously intend to write their own XPath processor in order to be conformant?
Grahame Grieve (May 06 2016 at 07:19):
and the sections about namespaces are horrifying....
Grahame Grieve (May 06 2016 at 14:58):
actually, after learning more about xml patch, I am using http://hl7.org/fhir
Richard Ettema (May 06 2016 at 15:12):
I found an open source implementation on github that I'm incorporating into my server - https://github.com/dnault/xml-patch.
Richard Ettema (May 06 2016 at 15:12):
Yes, I'm finding the namespace issue is a pain.
Grahame Grieve (May 06 2016 at 15:22):
does your implementataion agree with my tests:
Grahame Grieve (May 06 2016 at 15:22):
https://github.com/grahamegrieve/fhirserver/blob/master/tests/xml-patch-tests.xml
Grahame Grieve (May 06 2016 at 15:22):
?
Richard Ettema (May 06 2016 at 15:42):
I'll review and work on these as best I can during my travel to Montreal. I need to leave for the airport in about an hour.
Grahame Grieve (May 06 2016 at 15:43):
ok. actually, I have all the xpaths wrong - I'll commit a fixed version shortly
Richard Ettema (May 06 2016 at 15:44):
Ok. I was thinking I could also turn these into a TestScript set of tests. :)
Grahame Grieve (May 06 2016 at 15:50):
well, perhaps. but the more you get your hammer to do, the messier the hammer gets
Grahame Grieve (May 06 2016 at 15:55):
updated
Richard Ettema (May 06 2016 at 15:59):
Agreed. But, I love a good challenge. And I thought I wouldn't have anything to do on the plane. Thanks!
Grahame Grieve (May 06 2016 at 21:08):
ok. Patch works on my server. Here's an example patch:
<patch xmlns="http://hl7.org/fhir"> <remove sel="f:Location/f:extension[@url='http://hl7.org/fhir/StructureDefinition/location-alias'][1]"/> <replace sel="f:Location/f:status/@value">inactive</replace> </patch>
Grahame Grieve (May 07 2016 at 13:24):
I didn't say - to use patch on my server:
PATCH /open/[type]/[id] Content-Type: application/patch-ops-error+xml <patch xmlns="http://hl7.org/fhir"> <op.....> </patch>
Grahame Grieve (May 07 2016 at 13:24):
the json patch still works, of course
Richard Ettema (May 07 2016 at 13:48):
I have both json and xml patch working on my server as well - http://wildfhir.aegis.net/fhir. For Content-Type you can specify standard json or xml media types as well as "application/json-patch+json" or "application/xml-patch+xml" (rfc7351).
Richard Ettema (May 07 2016 at 13:48):
PATCH [baseurl]/[type]/[id]
Content-Type: "*json" or "*xml"
Richard Ettema (May 07 2016 at 13:48):
The payload for xml patch can use <diff> or <patch> as the root element; e.g.
<diff>
<op.....>
</diff>
or
<patch>
<op.....>
</patch>
Grahame Grieve (May 07 2016 at 13:49):
why are we using different media types?
Grahame Grieve (May 07 2016 at 13:51):
I've changed my server to application/xml-patch+xml now
Jenni Syed (May 07 2016 at 15:43):
The Cerner fhir server firewall fun has been resolved. JSON patch is now available at https://fhir.stagingcernerpowerchart.com/dstu2/a758f80e-aa74-4118-80aa-98cc75846c76/ (and it's stu3 despite what the URL indicates...)
Jenni Syed (May 07 2016 at 15:43):
working on xml patch
Chris Grenz (May 07 2016 at 20:28):
Something for the PATCH interested to consider. We have this working in our environment today. https://github.com/chrisgrenz/FHIR-Primer/wiki/PATCH-with-Profiles
Jenni Syed (May 08 2016 at 13:58):
@Chris Grenz A few initial concerns with the profile approach:
1) I thought profiles couldn't "remove" required fields, how would a client send in an update when the required fields aren't being updated? (I could be wrong about this rule/restriction.
2) How will you version the profiles? EG: if one of the profiles adds a field, you'll end up in the same place as a normal modify where you can't tell if then intended to delete a field or aren't on the latest version of the profile
3) Sheer number of profiles to represent every combination of a modify a client application can do.
Chris Grenz (May 08 2016 at 14:22):
Hi Jenni - for posterity and others my response!
1 - True. This is an open discussion with FHIR-I. We're using the SUBSETTED tag for profiles that remove a required or modifier element. Otherwise, the profile is standard.
2 - Versioning of profiles is an issue...generally we're more concerned with the appearance of new extensions rather than changes to the base elements from HL7 which we handle via endpoint versioning. In other words, and API is stable at the element level (since only HL7 can change the list of valid elements) by convention and stable at the slice level explicitly via the profile.
3 - Yep. I guess we're expecting *many* profiles to be published (both internal to the enterprise and globally) so this is assumed in our design.
Jenni Syed (May 08 2016 at 15:54):
Graham - gathered a few medication statement resources off your server for the demo, but realized that the fields aren't up to date with the stu3 order. Known issue?
Jenni Syed (May 08 2016 at 15:55):
literally just field order
Grahame Grieve (May 08 2016 at 15:55):
which server were you using?
Jenni Syed (May 08 2016 at 15:55):
eg: http://fhir3.healthintersections.com.au/open/MedicationStatement/6
Grahame Grieve (May 08 2016 at 15:56):
so the connectathon is based on the frozen version here:
Jenni Syed (May 08 2016 at 15:56):
actually... my rest client may be reordering... which is a bit surprising...
Grahame Grieve (May 08 2016 at 15:57):
http://hl7.org/fhir/2016May/index.html
Jenni Syed (May 08 2016 at 15:57):
I'll play around more
Grahame Grieve (May 08 2016 at 15:57):
you were looking at the current build
Sajjad Hussain (May 08 2016 at 17:52):
+3
Sean Moore (May 10 2016 at 19:45):
@Jenni Syed is the typical use case for Patch to have a client update a single element in a single transaction, or do your client applications want to make changes to multiple elements in a single transaction? I have some thoughts on PATCH but I want to understand the use cases you're working with first, since my experience is theoretical, and not yet practical.
Grahame Grieve (May 10 2016 at 19:46):
one change - may be two actions - remove + add
Grahame Grieve (May 10 2016 at 19:47):
that would be most common, but there's no limit to only that
Jenni Syed (May 10 2016 at 19:51):
It can be either. We have apps that are updating medicationStatement status only right now. We also have apps where the doctor may modify a Condition (comment, etc), and what is modified depends entirely on what the physician is trying to do.
Jenni Syed (May 10 2016 at 19:51):
patch allows you to do either in a single request (with multiple operations included in that request)
Last updated: Apr 12 2022 at 19:14 UTC
