0

For instance if we (as client app) retrieve a Patient with one array of contacts and now we send to the fhir server a PATCH request to modify some of the info for some of the contact... the only way we sawto indicate it is using the position. Example : Patient.contact[1].gender. Thats only one example.

I think that approach (using array position) is not safety because services are not stateful and besides, no always the server are returning the same order for the same array (its no makes sense to suppose we are reciving the contact list ordered) so the server could change the wrong contact (in this case or to be more dangerous/unsafe situation if we use clinical resources).

I'm wrong ? There is another more safety approach of using PATCH without penalize the performance?

3 Answers3

1

For a JSON Patch, you could use a "test" operation if you had a value within the array that can be relied upon. The patch operation as a whole is required to fail if the test fails: http://jsonpatch.com/#test

For XML Patch, I believe you may be able to do something similar with selectors? https://www.rfc-editor.org/rfc/rfc5261#section-4.1 - again, it depends on what you're trying to update.

I also agree with others that you should only attempt to patch if the version matches. There are very few updates that should be made to clinical data in a version-blind manner.

Community
  • 1
  • 1
jsyed
  • 21
  • 1
0

Servers are supposed to retain order. Not all servers will, but servers who don't probably won't be able to support PATCH. If you wish, feel free to submit a change request and we can highlight that in the specification.

Lloyd McKenzie
  • 6,345
  • 1
  • 13
  • 10
0

Thanks so much for your clarification. Sure, we will request a change, at least in the documentation for highliting this requirement (server have to mantain the order).

But What do you mean exactly with "order"?? For instance, Meanwhile the appclient1 retrived the Patient with 3 contacts (Andrew,Bob,Dukhan) and send a patch for [2] (Dukhan), but during this time any other system (appclient2) has added a new contact (Carl) .. now the list (on server side) will be Andrew (0), Bob (1), Carl(2) and Dukhan (3).... so when PATCH request for dukhan is received on the server from the initial appclient1 the position [2] just now is not Dukhan , is Carl. So we continue with the same unsafe situation.

  • Yes. That's unsafe. You can mix version specific writes with Patch, to make it safe, or use some other method to ensure that this doesn't happen, or you can not use XML patch - these limitations are inherent in XML patch. Not that you can use FHIRPath based Patch, which doesn't have these limitations - but that doesn't avoid the problems associated with multiple writes. – Grahame Grieve Aug 09 '17 at 22:01
  • I think the problem is not due to using XML or JSON, in fact we are working with json patch and even with fhir patch. Using resource versionId ensure your are modifing correct resource, but our problem is even when we are sure that the versionId is the same, we cannot ensure the position of the array is in the same order that the server suppose. FHIR As clinical protocol API should be a safety, well documented and standard way to do this and not depend on how client side prepare and sent the data or supossing how the server order the arrays .Should be unrecommeded to use PATCH in these cases. – Jose Antonio Jiménez Capitán Aug 09 '17 at 22:40
  • I think we didn't document this on the basis that it was pretty obvious: a server that can't maintain order won't support index based patch. but we haven't seen any servers that can't – Grahame Grieve Aug 10 '17 at 02:21