FHIR Chat · Search modifier for references: member-of-group? · implementers

Stream: implementers

Topic: Search modifier for references: member-of-group?

Josh Mandel (May 08 2019 at 12:34):

I think there's no good way to query for Encounters about a patient who is in my group, other than maaaaybe

 Encounter?patient:_has:Group:patient:_id=my-group-id

What would people think about an explicit modifier on reference searches like:

Encounter?patient:member-of-group=my-group-id

This is similar to "in" for valueset membership. For example it can apply to intensionally defined groups, where no materialized list of patients exists on the server. It's also similar to the _list search parameter, so in theory it could be addressed with a kind of _group parameter, but this feels kind of implicit.

This is all relevant because of subscriptions use cases, so we might wind up doing something special just for subsriptions, but seemed worth some broader discussion.

Brian Postlethwaite (May 15 2019 at 01:22):

I would actually like to consider just using the :in modifier.

Josh Mandel (May 15 2019 at 02:23):

Sure, it seems like a reasonable extension of the semantics. As long as we pick something :-)

Josh Mandel (Jun 11 2019 at 16:46):

Added GF#22690

Josh Mandel (Aug 19 2019 at 21:00):

Just took this up in FHIR-I. We have a draft disposition but wanted to check here for feedback from server authors about a few different ways we might define the :in modifier for reference-type searches. We'd say that :in modifier can be used to search for references that belong to a specific List (as in List.entry.item) or Group (as in Group.member.entity).

Josh Mandel (Aug 19 2019 at 21:00):

For the case of Lists and enumeration-based Groups, supporting this kind of lookup basically boils down (for server developers) to filtering based on a known set of references in the specified List (or Group). But for characteristic-based Groups, there is no pre-computed enumeration of members -- which would make support for :in quite a bit more challenging.

Josh Mandel (Aug 19 2019 at 21:01):

Among the following options, what would folks prefer to see? (Please thumbs-up your preferred options.)

Josh Mandel (Aug 19 2019 at 21:02):

1. The :in modifier for reference-based searches is defined for Lists and for enumeration-based Groups but is undefined for characteristics-based (non-enumerated) Groups.

Josh Mandel (Aug 19 2019 at 21:03):

2. The :in modifier for reference-based searches is defined for all Lists and Groups, but some servers supporting :in MAY refuse to work on non-enumerated Groups.

Josh Mandel (Aug 19 2019 at 21:04):

(Or feel free to present other options here ;-))

Paul Church (Aug 19 2019 at 21:35):

To the extent that group characteristics can be evaluated in terms of search parameters, I can see :in being an indirection that retrieves some criteria from the group and evaluates them. Even if those criteria are internal server magic rather than expressed in standard search terms, that still makes sense.

But I don't see how this makes sense in more abstract characteristic groups - for example, the R4 Group examples include a characteristic group for "Herd of 2500 breeding sows". How do I know if Patient/123, which is a pig and matches the characteristics, is one of those 2500 specifically? Or is that not a valid and relevant example?

Michele Mottini (Aug 19 2019 at 21:35):

Why adding this at all? Can't you just use _has ?

Josh Mandel (Aug 19 2019 at 21:38):

Encounter?patient._has:Group:member: ....? I just got lost.

Michele Mottini (Aug 19 2019 at 21:39):

Encounter?patient._has:Group:member: _id=xxxx (xxx is the id of the group)

Josh Mandel (Aug 19 2019 at 21:39):

Right.

Josh Mandel (Aug 19 2019 at 21:40):

I think this technically works but I'm not sure that argues against adding a more explicit/limited modifier.

Josh Mandel (Aug 19 2019 at 21:41):

i.e., I think the readability of Encounter?patient:in=Group/123 is itself a value proposition.

Josh Mandel (Aug 19 2019 at 21:43):

@Paul Church regarding the specific example with those pigs, I think that's not a group that's well-defined enough to ever resolve individuals. (If it said "Group of Farmer John's Breeding Sows" and had no quantity and instead characterics that established the sow-ness and belonging-to-farmer-john-ness, then I guess it could apply, since you could deterministically evaluate a particular Patient against the characateristics to resolve membership. But I think this is a separate discussion about Groups.)

Paul Church (Aug 19 2019 at 21:59):

I don't see how a general-purpose server can decide whether a particular characteristic group is or is not the kind that is well-defined enough to do this operation. It's fine for facade or customized servers, but from an interoperability perspective it seems like enumerated groups are the only case a client can rely on.

Josh Mandel (Aug 19 2019 at 22:04):

Yeah, I wonder if there is any way to tell whether a group is fully defined by its characteristics vs merely described by them. @Lloyd McKenzie has there been anything on this question? (It has echoes of modeling concepts in description logic like SNOMED.)

Paul Church (Aug 19 2019 at 22:04):

I think the readability of :in for enumerated groups/lists is a plus, and potentially an opportunity for optimization over _has.

Josh Mandel (Aug 19 2019 at 22:05):

In theory we could resolve this issue with an additional flag on Group. I wonder how often we expect to see non-enumerated groups with characteristics that are merely descriptive (like the example from the spec).

Grahame Grieve (Aug 19 2019 at 22:05):

my server will resolve some groups - e.g. gender = female

Grahame Grieve (Aug 19 2019 at 22:05):

it knows what group characteristics it knows how to resolve or not

Grahame Grieve (Aug 19 2019 at 22:06):

though I do not pre-index this. I could, if I did the work

Grahame Grieve (Aug 19 2019 at 22:07):

I prefer the :in based syntax

Lloyd McKenzie (Aug 20 2019 at 02:08):

The intention for Group was that the characteristics are the definition. Enumeration of members is optional and not necessarily complete. Some characteristics may not be searchable. E.g. "Everyone who came within 2 miles of coordinates xyz between start date and end date" is a completely logical group definition for certain public health scenarios, but certainly not something you could hope to search by. (Though the public health folks would surely love us if we could come up with a way :>)

Lloyd McKenzie (Aug 20 2019 at 02:10):

In practice, I think Group is being used in two different ways. In some cases, the members are simply enumerated and the criteria are either missing or informational. This would be things like practice groups and capitation groups. On the other hand, for clinical trial definitions and public health, the criteria hold sway and members might not be enumerated at all. In some cases, you'll start with a set of criteria and eventually have a full enumeration (e.g. a clinical trial where the group eventually enumerates all enrolled participants).

Josh Mandel (Aug 20 2019 at 03:28):

But Paul's example http://hl7.org/implement/standards/fhir/group-example-herd1.json.html is not enumerated, and doesn't have fully definitional characteristics. Is that invalid?

Grahame Grieve (Aug 20 2019 at 06:39):

I don't think so.

Josh Mandel (Aug 20 2019 at 15:51):

Okay -- and what's @Lloyd McKenzie's take?

Lloyd McKenzie (Aug 20 2019 at 16:14):

Yet another use-case for group. In this case, the "identity" of the group is in its identifier. The herd of cows or crate of mice is managed by its identifier. The criteria could be fully specified by designating owner or crate number or barn or something, but for the intended use, that would be unnecessary. Someone, somewhere should know exactly which cows are in the herd or mice are in the crate, but that information might not always be shared.

Josh Mandel (Aug 20 2019 at 17:48):

Okay -- and do you think there's value in expressing this distinction (i.e. "This group is defined by its characteristics" vs "This group is described by its characteristics but not defined") in our model (e.g., Group.fullyDefinedByCharacteristics: Boolean)? To @Paul Church's point it's impossible for a generic server to navigate these distinctions otherwise.

Josh Mandel (Aug 20 2019 at 17:48):

I'll add a GForge item for this unless folks find it abhorrent here :)

Josh Mandel (Aug 20 2019 at 18:10):

Added GF#23724.

Paul Church (Aug 20 2019 at 18:17):

As an alternative, could change "actual" from a bool to an enum with 3 values. Otherwise there are 2x2 possible values, one of which doesn't make sense.

Josh Mandel (Aug 20 2019 at 18:18):

The one that doesn't make sense is "actual: false" and "fullyDefined: true"?

Paul Church (Aug 20 2019 at 18:19):

Yes. (Or does it? I'm not sure how actual: false is used.)

Josh Mandel (Aug 20 2019 at 18:20):

I'm not totally sure either, but I think you're right. I updated the GF issue to include this point.

Grahame Grieve (Aug 21 2019 at 19:27):

I already had a task about this

Grahame Grieve (Aug 21 2019 at 19:30):

I was thinking of GF#17457

Josh Mandel (Aug 21 2019 at 19:51):

Yeah, it's related but distinct.

Josh Mandel (Aug 21 2019 at 19:52):

(GF#17457 gets at the question of whether enumerations are always expected to be complete, but GF#23724 gets at the question of whether membership can automatically be inferred. For the "pile of pigs" Group, the characteristics don't actually define the group, so membership couldn't automatically be inferred.)

Brian Postlethwaite (Sep 01 2019 at 19:42):

Could this also be applied to organization or location hierarchies?

Brian Postlethwaite (Sep 01 2019 at 19:42):

Or is that a seperate tracker?

Josh Mandel (Sep 02 2019 at 23:54):

I think it's a separate tracker (or should be) but I'd like to see it

Brian Alper (Sep 21 2019 at 13:35):

GF#24849 added to suggest Group.characteristicCombination to enable specifying union (combine characteristics with OR) in addition to the 'default' intersection (combine characteristics with AND). This element could also have codes that would capture 'definedByCharacteristics' and 'characteristicsAsNondefinitionalDescriptions'

Josh Mandel (Sep 24 2019 at 21:35):

Reviewing where we are with GF#22690 -- I'd like to suggest we move ahead with defining :in as a modifier on reference-type searches, enabling search by Group and List to start. Are there concerns / comments on this approach before we take up in FHIR Infrastructure?

Josh Mandel (Sep 24 2019 at 21:35):

(We've been through discussion above; just checking back here before we more ahead.)

Gino Canessa (Sep 24 2019 at 21:37):

Would there need to be a matching :not-in, or is that a solution to a problem that doesn't exist?

Josh Mandel (Sep 25 2019 at 14:02):

:not-in hasn't really come up -- so I'm comfortable moving ahead without it. The problem may exist but we can add negation if/when we hit that problem.

natus (Oct 20 2019 at 10:13):

Hi @Josh Mandel why not simply using:

Encounter?subject:Group/123

natus (Oct 20 2019 at 10:17):

this apply to any resource referecing a group.

The only corner case is for patients (give me all patients in this group):

Patient?_has:Group:member:_id=xxxx

natus (Oct 20 2019 at 10:27):

I was wrong, encounter.group is for people present during the encounter.
Then both would use reverse chaining (in my case xxxx is a patient cohort):

Encounter?patient._has:Group:member:_id=xxxx
Patient?_has:Group:member:_id=xxxx

natus (Oct 20 2019 at 10:30):

In case Encounter?patient:in=Group/123 is adopted, how would this apply for patient ?

Patient?_id:in=Group/123

?

natus (Oct 20 2019 at 10:58):

As an alternative:

List resource can be linked to a Group. So in order to retrieve the members of an Encouter from a given Group doing so:

List?subject=Group/123 // get the list for the given group ; returns 456
Encounter?_list=456 // returns the encounters of patients within the group 123

Cindy Jiang (Nov 21 2019 at 14:01):

We have a use case 'return all DiagnosticReport where DiagnosticReport.subject is in myPatientList'. We did some testing on test.fhir.org/r4 and HAPI fhir server.

1) on test.fhir.org/r4: created a new group
http://test.fhir.org/r4/Group/105 containing the patient
http://test.fhir.org/r4/Patient/0379d9a0-a010-49b8-9aa3-defd2c3fb2

1.a) the following reverse chaining using the group ID did not work as expected - it returned all the records without filtering.
http://test.fhir.org/r4/Patient?_has:Group:member:_id=105
1.b) tried to query DiagnosticReport based on the group of patient but got an error.
http://test.fhir.org/r4/DiagnosticReport?patient:_has:Group:member:_id=105

2) on the HAPI test server, the query outlined in 1.b above didn't return any record however it didn't error out either.

@Grahame Grieve & @James Agnew , are the queries in 1.a and 1.b above syntactically correct in FHIR R4 for our use case? The proposed :in modifier definitely will make the query more readable, however we need to figure out how to support our use case in R4 for the time being. Look forward to your advice!

James Agnew (Nov 21 2019 at 14:18):

Your query on 1b looks invalid: You have "patient:_has:..." but I'm
assuming you intended that to be "_has:patient:..."

Sanjaai (Nov 23 2019 at 13:30):

@James Agnew thanks for your suggestion. with the following queries, still not successful.

Sanjaai (Nov 23 2019 at 13:35):

1. Original query
   http://hapi.fhir.org/baseR4/DiagnosticReport?patient:_has:Group:member:_id=52152
   no syntax errors, returns empty result set. however there are matching DIagnosticReports

2. Tried following, per suggestion,
   2.1. http://hapi.fhir.org/baseR4/DiagnosticReport?_has:patient:_has:Group:member:_id=52152
   2.2. http://hapi.fhir.org/baseR4/DiagnosticReport?_has:Patient:_has:Group:member:_id=52152
   2.3 http://hapi.fhir.org/baseR4/DiagnosticReport?_has:Patient:Group:member:_id=52152
   2.4 http://hapi.fhir.org/baseR4/DiagnosticReport?_has:Patient:group:member:_id=52152
   all of them are returning syntax errors.

René Spronk (Nov 23 2019 at 14:28):

1 is a valid query IMHO..

James Agnew (Nov 23 2019 at 18:41):

I don't get how 1 could be valid.. Where in the spec is the syntax [searchparam]:_has described?

Michele Mottini (Nov 23 2019 at 18:54):

http://hl7.org/fhir/search.html#has - 'The _has parameter can be chained' - the example chains two _has but there seems to be no reason chaining it with a normal search parameter should be forbidden

Sanjaai (Nov 23 2019 at 19:12):

My need is same as what is stated at the top of the post. I have a List or Group of patients and want to get the DiagnosticReports for everyone in the List or Group. Is there a simpler way to get it if Query 1 is questionable?

James Agnew (Nov 23 2019 at 19:19):

Ahh if it's a chain we're trying to do, that syntax uses a dot, not a colon. The query you're after is probably this one:

http://hapi.fhir.org/baseR4/DiagnosticReport?subject._has:Group:member:_id=52152

James Agnew (Nov 23 2019 at 19:20):

..or even better this one, which will be slightly more efficient in HAPI:

http://hapi.fhir.org/baseR4/DiagnosticReport?subject._has:Group:member:_id=Patient/52152

Sanjaai (Nov 23 2019 at 21:25):

thanks @James Agnew it appears to be returning the correct data set.

Last updated: Apr 12 2022 at 19:14 UTC