Stream: implementers
Topic: Reducing scope of Group resource
Josh Mandel (Oct 21 2019 at 20:57):
Based on GF#24848, we (the FHIR Infrastructure workgroup) realized the scope of the Group resource has been creeping upward over time, covering things beyond the "Groups of people that share common characteristics" that was the original intent. In the current state, Groups start to overlap quite a bit with Lists, and we're receiving requests to keep expanding the scope. Instead, we're discussing reducing the scope of Groups, so they only cover things we consider "participants" (see http://build.fhir.org/participant.html#Participant).
On this reasoning, we'd remove "device | medication | substance" from the allowed group types, and remove "Device | Medication | Substance | Group |" from the participant types. To describe these kinds of collections, we'd point people toward the List resource (e.g. using an Expression extension if needed to attach inclusion criteria).
Thoughts? Concerns? Discussion?
Grahame Grieve (Oct 21 2019 at 20:58):
@Floyd Eisenberg
Floyd Eisenberg (Oct 21 2019 at 21:01):
Thanks Grahame. Looking for input from @Bryn Rhodes and @Brian Alper
Brian Alper (Oct 22 2019 at 09:31):
It sounds ok to remove device, medication and substance from the Group Resource. In the future if FHIR is used to report evidence about such things we can add an extension or other element to cover evidence of "things" rather than evidence of "participants".
Brian Alper (Oct 22 2019 at 09:43):
However, using Group to cover "participants" for evidence, for recommendations, for quality measures, for care plans, for selection/matching to groups of patients -- these are areas where interoperability is critical for broad use. When reporting evidence there is a very common scenario when multiple studies (each representing evidence from a group) are combined for an overall analysis -- this is not just common, this is better science and much more trustworthy for informing decisions that is the expected approach for clinical care, guidelines, etc. In these cases the group for the summary statistic is not a single group of participants, and is not a group of groups of participants either. It is a group of studies/evidence in which each study/evidence has a group of participants. The simplest way to accommodate this is to add "information" to the allowed group types and to add "Evidence" to the allowed participant types.
Brian Alper (Oct 22 2019 at 09:49):
This is the third of 3 responses - I do not have direct use cases for use of Group as a participant type for Groups -- member.entity Reference (Group) - but it sounds logical for creating an actual Group from 2 or more Groups -- it sounds like less effort than recompiling the multiple lists of members from each group to make a larger combined group. Perhaps there are real examples from quality measures where they use groups for each provider, each department, each hospital and the whole institution - how do they handled the groups of groups? @Bryn Rhodes @Floyd Eisenberg @Grahame Grieve @Josh Mandel
Floyd Eisenberg (Oct 22 2019 at 13:28):
As far a participant type that Brian references, the ability to manage attribution for measures or a group to which to send information from a CDS Hook: A quality measure is often population-based, indicating appropriate care process or outcome expected for a given patient cohort. The measure, however, can indicate the organization for which initial population criteria are met, then assure that a member of that organization performed the tasks required for the numerator. The organization is a group of practitioners (or a group of organizations). And implementers will want to assure that only appropriate groups within that organization receive information about required processes or outcome success or failure to help improve care. It will be challenging for a generic measure or CDS artifact to reference a list as opposed to a group to indicate the appropriate individuals as might be defined at any given site (without having to know the configuration of each site). I also support the need for group to express specific patient cohort characteristics as noted by Brian.
Perhaps these use cases still fit with the expected use of Group - If I read the note from Josh correctly, the types of devices or individual devices, medications or substances are being removed as allowable group types, but not people with common characteristics. If that is true, our use cases may still be supported. I would question why we need lists when a value set may suffice for devices, medications and substances.
Bryn Rhodes (Oct 22 2019 at 17:52):
The key distinction that's being promoted (and that I agree with), is that the Group resource is used to define groups, actual or definitional, of participants (so I note that Device is actually still allowed). The concern is with overlap of the List resource, which is the more appropriate choice for things like Medications, Substances, Procedures, etc. The use case from quality measurement requires both lists of participants _and_ lists of things, but the challenge with using List for that is that it is always an "actual" list, where we need a "definitional" list. @Brian Alper , I think the summary use cases you're describing could also be represented with List if it supported "definitional" lists. So is there a case for extensions to List to support defining characteristics (and a modifier extension to say this is "definitional")?
Lloyd McKenzie (Oct 22 2019 at 21:19):
More specifically, passive participants. Groups cannot take responsibility for an action. They can only be acted upon.
Last updated: Apr 12 2022 at 19:14 UTC
