Stream: new zealand
Topic: Updating the NHI
David Hay (Jul 08 2019 at 22:31):
Current thoughts on updating the NHI (and, likely the HPI also)
feedback welcomed!
Peter Jordan (Jul 08 2019 at 23:49):
Given that the underlying DB Schema of the NHI Patient Repository is a fairly simple one, I'd question the need to create custom operations to perform basic CRUD tasks. Using 'vanilla' RESTful commands would certainly create an API that's simpler than the existing SOAP interface to the NHI. I'm concerned that what's being proposed in David's Blog Post would make it more complex.
David Hay (Jul 09 2019 at 01:09):
Well, it's certainly a different style as I pointed out in the post - but the update documents are quite straightforward to build, and get around the issue of having to submit (and the server process) an entire resource when you only want to change part of it. (And there were the issues with patch that I mentioned). But - would be good to get the perspective of the implementer community - which is why I wrote the post in the first place...
Brian Postlethwaite (Jul 09 2019 at 08:39):
Given how custom it is, not sure on the benefit of using fhir for updates there. It's custom anyway.
David Hay (Jul 09 2019 at 08:53):
You don't agree with using FHIR operations for this? Part of the issue is that not all of the elements in the resource can be updated by all users (like the general practitioner for example). Using standard rest for, say, an address update would mean that the client would need to read the current resource, update the address, PUT the resource to the server which would need to strip out the elements that can't be updated by the user and update the ones that can be.
Clearly defined operations seemed the simpler (and clearer) approach...
Peter Jordan (Jul 09 2019 at 22:34):
Because the NHI Repository is a 'single source of truth' for NZ patient demographic data, with (eventually) inputs from all healthcare facilities, there are many complex server-side rules around updates. My inclination would be to leave this complexity where it belongs - on the central server - and allow the client to make PUT requests containing complete patient resources to the Server for potential updates.
David Hay (Jul 09 2019 at 22:57):
Will be good to get the input of the development team about just how complex this logic will be. In principle that's the simplest approach (and the one most commonly used generally) but the existing system is service (operations) based - and I wonder how complex this logic will be to implement - especially for some of the edge cases and repeating fields. For every update operation the server will need to compare what is in the submitted resource with the all data in the back end systems (not FHIR of course) to determine what has changed. Next, it must determine whether the changed field/s's can be updated at all and whether the current user has the rights to make that change. Finally the change can be applied, and the user notified.
All do-able of course, but what will it take to do so, and what's the performance impact? Having specific operations reduces that complexity (as the nature of the update is specified) and I do wonder just how much more complex it is to the client. They already know what the change is they wish to make, so the resource PUT approach means updating the resource and submitting it, and the operations approach means specifying the change and submitting that.
@Brian Postlethwaite - how are other jurisdictions managing FHIR updates to registry data?
Brian Postlethwaite (Jul 09 2019 at 23:06):
They are done out of band as a request, then processed in.
We do this in our EPD product, just a simple update for the client, and all the hard work done on our end.
The Submitter just sends what they know complete and is curated into the central record.
And many of them don't use fhir to update either.
What you have there is making the job easier for their dev, but more work for everyone else. They can't just send what they have, and let the registry worry about merging all the data together.
David Hay (Jul 11 2019 at 17:57):
So any other comments (particularly from implementers)?. To summarise, we're looking at 2 'styles' of update:
- One where there are specific update operations (address, ethnicity, name) etc that the client calls as required.
- The other where an updated resource is submitted and the server figures out what changes were made
In both cases validation, security and access control is applied, so the update may not proceed (an OperationOutcome with the issues will be returned)
David Hay (Aug 12 2019 at 20:01):
Taking a closer look at PATCH: https://fhirblog.com/2019/08/13/updating-a-resource-using-patch/ . (Actually, Grahame suggested this right back at the beginning - just getting round to taking a closer look now. Silly me...)
Peter Jordan (Aug 12 2019 at 20:43):
That looks like a much better solution than custom operations!
David Hay (Aug 12 2019 at 21:54):
Yeah - I kinda kick myself for not taking a closer look earlier...
Brian Postlethwaite (Aug 12 2019 at 22:02):
Interesting in your address example you insert the collection first otherwise it would fail /as you noted)
However this wouldn't be a problem as you need to know the state of the resource before to know that you're not creating a dup address.
Great write up though.
David Hay (Aug 12 2019 at 22:05):
exactly. (and thanks!) - a better solution than custom operations do you think?
David Moorhouse (Oct 30 2019 at 21:08):
Hi David, Thanks for your thoughts on this. I think that the PATCH verb is easier to support than custom operations. The only reservation is around the manipulation of collections such as addresses - I can see scenarios where a client app is submitting a "stale" PATCH i.e. where the data has been updated by a third party in the time between the client reading it, the user making the change, and the client resubmitting.
Would atomic operations on collections be a better alternative - such as requiring ALL addresses to be submitted.
David Hay (Oct 31 2019 at 02:42):
Thanks for that David. Are you concerned about, say, 2 users trying to remove the same address at different times? I did make the comment below - would that help to resolve this? I am assuming / requiring a read / update using optimistic locking to avoid collisions...
So for adjusting the array, you need to know the position of the element in the array to remove. This shouldn’t be a problem as the client will have just loaded the patient, and optimistic locking ensures that no-one else has changed it in the interim.
cheers...
Last updated: Apr 12 2022 at 19:14 UTC