Stream: implementers
Topic: Group Resource
Radu Craioveanu (Jan 05 2018 at 18:20):
This may have been answered, as it seems basic. We have FHIR Groups that have hundreds of thousands of members. When we read the resource, we crash the java heap if many users are pulling it. Is there a cursor or iterator that can be used to traverse the array of members in the Group?
Lloyd McKenzie (Jan 05 2018 at 20:51):
No. Resources cannot be retrieved in chunks. It's possible to update them in chunks using PATCH, but we haven't defined a way to retrieve them that way. Feel free to submit a change request and we can think about it. I can see the possibility of this being an issue for List occasionally too.
Lloyd McKenzie (Jan 05 2018 at 20:51):
(Groups with hundreds of thousands of members is not something anyone else has hit yet - what are the groups for?)
Radu Craioveanu (Jan 05 2018 at 21:10):
The Groups are for tracking Patient eligible for various programs, such as HepC vaccination, or some Pilot treatments... Basically there is some enrollment criteria (based on clinical, financial or otherwise) which Adds a member onto a Group. The member may become ineligible and then eligible again, so he may appear multiple times in the Group. We need that for tracking history also.
I thought Groups were meant for doing Population level tracking based on criteria. We have a very large patient population. Are we not using the right resource?
Radu Craioveanu (Jan 05 2018 at 21:12):
Does the List behave the same way? One cannot paginate through it, or pull only a limited number of items?
Lloyd McKenzie (Jan 05 2018 at 21:41):
Groups aren't intended to represent history - they represent current membership. To see history, you'd need to look at older versions of the resource. Are you using a modifier extension to indicate members that aren't actually current members?
Lloyd McKenzie (Jan 05 2018 at 21:43):
It's not so much that this use is "wrong", but it's certainly not anticipated. I would probably have used the group to define the criteria, but I'd have created individual Eligibility instances for each period of time over which a given patient was deemed eligible. That gives you your history and also makes it much easier to filter when retrieving information. You can also capture any patient-specific constraints on eligibility, information about when elegibility was determined (which might be distinct from when the eligibility became effective), etc.
Radu Craioveanu (Jan 05 2018 at 22:07):
Lloyd, I don't follow the model you are suggesting. In my scenario I wanted to capture the following, see below. Please check it out and let me know:
Say I have 10 patients that have been enrolled in SpecialProgram based on their BP > 150 (making stuff up here). One can look at the Group and see all 10 patients be Active, with an enrollment date (Period Start = 1/1/2018). Patient_1 gets better, his BP is now less than 150, so the Group.member is updated an Inactive status, and the Period End = 1/5/2018. Two days later, Patient_1 gets high BP again, so he gets put back in the group, new entry in the Member array, status is set to Active, Period Start is 1/7/2018.
Application_Y wants to know if Patient_1 is part of the SpecialProgram, so it queries teh SpecialProgram Group for that Patient identifier
Application_Z wants to view all Patients that have been in the Special Program during the month of January, so it queries SpecialProgram for all Members who have a Period Start before January and Period End during or after January. Accounts for no Period End.
Grahame Grieve (Jan 06 2018 at 01:19):
there is graphQL. That's the only tool we offer to grapple with very large resources like this
Lloyd McKenzie (Jan 06 2018 at 04:02):
@Radu Craioveanu Apparently I haven't looked at Group in a long time. I didn't realize that period or "active" had been added to it. I'm rather nervous about "active" as that's essentially a status - and resources are only supposed to have one state. If we're trying to manage something more sophisticated than "these are the 20 rats in the cage" or "these are the 50 people who were exposed to agent X", then that's going a bit beyond the realm of the originally intended use of the resource. @Brian Postlethwaite, has PA thought about what the boundaries should be between using Group and capturing membership as enrollments?
Brian Postlethwaite (Jan 06 2018 at 06:07):
What did you mean by enrolments here in terms of fhir?
Lloyd McKenzie (Jan 07 2018 at 02:59):
I was thinking of EnrollmentRequest/EnrollmentResponse (though EnrollmentResponse needs to evolve a bit more - the ability to say "no" should be handled by Task and saying "yes" should be an Enrollment "event" resource if we want to be consistent with workflow everywhere else.
Last updated: Apr 12 2022 at 19:14 UTC
