Stream: implementers
Topic: Updating Group and Group members separately. Is it possible?
Erik Greif (Oct 12 2018 at 16:50):
I am hoping to gather some insight on the best way to implement the Group resource as a REST API.
What we're trying to do:
1. Create, destroy, and update Groups and their descriptions
2. Add and remove members from any given group without changing other attributes of the group
My team devised three approaches to doing this:
1. Have two endpoints: one for modifying the Group by ID as a template, and another for getting the group populated with members and deleting/adding members
2. Having the member-group relationship resource collection (like a Bundle) available as a sub-endpoint of the template Group resource. /api/Group/{group-id}/member/{member-id or member-group-relationship-id} and the respective collection endpoint.
3. Passing around a query parameter for whether we are modifying members in a group or the group properties itself.
The major worry here is that neither of these appear to confirm strictly to FHIR spec. It seems as though the spec indicates that the group resources and all of the contained members are ONE resource, and should be fetched and updated in a unified fashion.
The problem we face is, if I want to simply modify the attributes of the Group such as the name or characteristics, but don't want to interfere with external traffic (which is rapidly and transactionally inserting/removing members), how can I do it without splitting the resource into two pieces? Even if we use a special identifier to ensure data isn't lost in this process (block out-of-order changes), at some point, the updated resource becomes too large for a single HTTP request. It also means a lot of rejected update requests and retries during heavy load scenarios. This doesn't seem sustainable nor scalable.
I would appreciate hearing any input on what we ought to do in this case. This is my first post. If I've done it wrong, please feel welcome to move it or instruct me to do so!
Lloyd McKenzie (Oct 12 2018 at 16:55):
If external systems are "transactionally" adding and removing members, then they're going to need to query before the addition/removal of a member and ensure that the record hasn't changed when they do their PUT using the if-match mechanism. If that's already in place, then an update to the group name or other metadata would be handled the same as any other update collision - requery, then re-update.
If the concern is with the volume of data transmitted when updating the resource, you could look at PATCH.
Erik Greif (Oct 12 2018 at 17:49):
@Lloyd McKenzie Thank you for the input. We don't have that mechanism in place, but we are looking into it. Patch makes sense. I was mostly worried about removing from groups in that case. I guess that would be a deactivate operation on the members entry, rather than actually removing that member from the list. Since curation of the group's metadata (all except members) is done by manual requests right now, patch would be required because it does not use the if-match.
As a follow-up, we also want to know whether there is a way to fetch all groups for a member. I forgot to mention this problem earlier...
We thought maybe we should get a Bundle of Group resources, and filter based on ?patientId=whatever. Lingering questions are...
1. Is this operation even supported by FHIR?
2. Do the bundled Group resources returned contain the member field?
3. Should we filter to only the given member, or leave all members?
Lloyd McKenzie (Oct 12 2018 at 18:00):
You should be able to use [base]/Group?member=Patient/123 to grab all groups that the patient is a member of. You could also tag _summary onto that if you didn't want to see the full member list
Erik Greif (Oct 12 2018 at 19:33):
Fantastic suggestion, thank you! I didn't know that was how that worked.
Last updated: Apr 12 2022 at 19:14 UTC
