Stream: research
Topic: Differences in Inclusion/Exclusion between R4 and R5
Gustav Vella (Oct 15 2021 at 22:16):
ResearchStudy R4 allows references to 0..* groups https://hl7.org/fhir/researchstudy-definitions.html#ResearchStudy.enrollment
ResearchStudy R5 allows references to 0..1 groups https://hl7.org/fhir/2021May/researchstudy-definitions.html#ResearchStudy.recruitment.eligibility
While I could express I/E via multiple groups in R4 I can't do that any more in R5. What's the Idea for this change? Am I missing something?
Lloyd McKenzie (Oct 15 2021 at 22:39):
Good question. Group allows "ANDing" of characteristics. If you want "ORing" of characteristics, your only option is distinct groups. @Hugh Glover ?
Gustav Vella (Oct 16 2021 at 13:46):
Yeah "ORing" is exactly our (@Clemens ) case.
Clemens Scherer (Oct 18 2021 at 09:17):
Would be nice to clarify how to model OR criteria in R5. We have implemented I/E criteria screening in R4 using FHIR groups (OR criteria by using different, distinct groups)
Hugh Glover (Oct 18 2021 at 16:32):
I've asked this question before and not got an answer :(
Lloyd McKenzie (Oct 18 2021 at 17:04):
Where did the change to the cardinality come from?
Mike Hamidi (Oct 18 2021 at 19:23):
This is how the Vulcan SoA was conceptualizing it (i.e. groups). A lingering question is 1..* I/E amendments and sub-study I/E enrollments (i.e., overall complexity in real-world setting across sites).
Gustav Vella (Oct 19 2021 at 07:11):
Hugh was so kind as to put it on the Agenda for discussion tonight. Hope this clarifies the thinking. I'm using constructs very similar to those here https://www.devdays.com/wp-content/uploads/2020/08/Community-Bulk-Export-API-DevDays-2020-Virtual.pdf and am using alot R5 elements via http://hl7.org/fhir/r4/versions.html#extensions because of the significant improvements for ReSubj and ReStudy in R5 and obvioulsly would like be sure things remin R5 compatible.
Gustav Vella (Oct 20 2021 at 16:57):
@Hugh Glover explained the rationale for the change in yesterdays call. I'm doing my best here to summarize. What I got is as follows:
Looking at the listing of elements and attributes in ResearchStudy, there is a recruitment block as Backbone element with the eligibility attribute referring to a Group defining Inclusion and exclusion criteria.
We also have the actualGroup attribute referring to a Group, in this case defining the group of participants who were actually enrolled in study.(I struck this though since not really relevant for this discussion)
If we look at the Group resource, you have the Group.member as backbone element, defining who or what is in group. Multiple members are possible, each containing an Group.member.entity attribute that can take a reference to the group resource itself as value. Hence, you can have multiple members and thus, via entity multiple groups.
According to Hugh Glover , the argument by Brian Alper for suggesting the changes was that you got a 0..* in Group.member, where you define top level groups e.g. which distinguish between inclusion or exclusion so you would have 2 groups at that level and within each of those you'd have as many component groups as you actually wanted. Hence, by having 0...1 in ResearchStudy.recruitment.eligibility you provide a single base to a hierarchical structure and you walked your way down, branching off in tidy distinct Group resources.
Gustav Vella (Oct 20 2021 at 16:58):
What do I think of this? Instinctively I prefer flat structures. Leaving that instinct aside, it always depends on what you want to do. If you want to make things more legible, packaging I/E in different groups is helpful. If you want to process and query the stuff (query on group traits), the change makes things complicated or not possible at all.
The first thing that comes to mind is the following case/user story:
As physician, I want to find the appropriate Study for a patient. The System should show me all ResearchStudies with following inclusion criteria. ...
That type of search is not possible with this construct because afaik you don’t have recursive reference support in search. Am I wrong?
Gustav Vella (Oct 20 2021 at 17:08):
@Alexander Zautke you are my source of wisdom regarding search.
Lloyd McKenzie (Oct 20 2021 at 18:21):
I'm not understanding that logic. ResearchStudy.recruitment.eligibility is 0..1 - and there you're definitely not listing specific patients yet - you've only got criteria. And if you're specifying criteria, you're going to need AND + OR. The only way to get the latter is multiple repetitions of Group.
For ResearchStudy.recruitment.actual if the preseumption is that you're always listing group members, not criteria, then 0..1 is probably ok. However, if you wanted to indicate which set of members you had for each combination of eligibility criteria, then you'd probably want the 'actual' to mirror the 'eligibility' in terms of criteria - in addition to enumerating the members.
Gustav Vella (Oct 20 2021 at 19:00):
No, the case I'm assuming the change will cause trouble with is not when searching for patients but when searching for trials which match specific traits of my patient against the traits/criteria in the I/E groups related to the trial. Hence, when I want to find a trial for a given patient using a search operation.
That's the only issue I see with the spec change right now.
Mike Hamidi (Oct 21 2021 at 14:11):
I would assume ResearchStudy.recruitment is 0..1 as retrospective studies do not require recruitment - determined, e.g., via ResearchStudy.primaryPurposeType. To me, it seems that you can have 1..* ResearchStudy.recruitment.eligibility grouping sets. For example, when there are multiple I/E amendments. However, which patients are in which I/E group is based on ResearchStudy.recruitment.actualGroup.
Side note, I think there should be conditions when ResearchStudy.recruitment is 1..* because those supporting elements would have conditions to their requirement. For instance, if an interventional clinical trial has ResearchStudy.recruitment then an expectation for ResearchStudy.recruitment.eligibility, ResearchStudy.recruitment.targetNumber, etc. would be true. Again, this is something being evaluated by the Vulcan SoA.
Lloyd McKenzie (Oct 21 2021 at 15:10):
For a retrospective study, you could still potentially use 'recruitment' to track which Patient records were deemed in scope for the analysis.
Brian Alper (Oct 21 2021 at 17:01):
A ResearchStudy Resource could be used without a recruitment element if you are building/describing a protocol and have not yet determined the group/population/sample enrollment/eligibility criteria. The Resource instance does not have to be completely filled out to be meaningful.
If a research study includes multiple groups they can be described in the comparisonGroup element which is 0..* while the recruitment element is 0..1 for the overall group/population for the entire ResearchStudy.
The Group Resource contains 0..* characteristics for describing inclusion and exclusion criteria. If you want to search for clinical trials (research studies) which contain specific inclusion criteria within the group eligibility criteria there are 2 ways to consider doing this:
1) Use the ResearchStudy.classification, ResearchStudy.condition, and ResearchStudy.keyword, and ResearchStudy.location elements -- until more and more groups are defined in coded structured data in Group Resources this will be needed
2) Search the Group resource referenced by the ResearchStudy for the eligibility criteria of interest. This does require mapping through the reference to the Group Resource then search the characteristic elements of the referenced resource.
Also the actual group does not need to use Group.members -- often the actual group will have a quantity and could included characteristics without disclosing who the members are.
Gustav Vella (Oct 21 2021 at 17:43):
first off, thanks for following-up.. very clear explanation..
Brian Alper said:
If you want to search for clinical trials (research studies) which contain specific inclusion criteria within the group eligibility criteria there are 2 ways to consider doing this:
1) [...]
2) Search the Group resource referenced by the ResearchStudy for the eligibility criteria of interest. This does require mapping through the reference to the Group Resource then search the characteristic elements of the referenced resource.
I'm not sure what you exactly mean by "mapping through the reference" - could you elaborate on that? In the case of the hierarchical structure , we'll have to map through several references.
Brian Alper (Oct 21 2021 at 18:00):
I don't know how FHIR search API works, but for other data transformations I have been able to call a resource by following the value in the reference element, interrogate the resource for known data values (such as characteristic containing desired strings), and complete a "search" in a for-loop. This may not be scalable the way I have done it but I haven't built search engines. I think there are discussions about using FHIR for data exchange vs. using FHIR for data store. Others may have a lot more understanding for this.
Clemens Scherer (Oct 21 2021 at 18:57):
Lloyd McKenzie said:
I'm not understanding that logic. ResearchStudy.recruitment.eligibility is 0..1 - and there you're definitely not listing specific patients yet - you've only got criteria. And if you're specifying criteria, you're going to need AND + OR. The only way to get the latter is multiple repetitions of Group.
For ResearchStudy.recruitment.actual if the preseumption is that you're always listing group members, not criteria, then 0..1 is probably ok. However, if you wanted to indicate which set of members you had for each combination of eligibility criteria, then you'd probably want the 'actual' to mirror the 'eligibility' in terms of criteria - in addition to enumerating the members.
As Lloyd stated indirectly, FHIR Group has the rule "Can only have members if group is "actual". So if want to prospectively search patients for your clinical trials in a hospital by using I/E criteria with AND and OR conjunctions, you are not allowed to use the BackboneElement "member" in FHIR group (no "actual" but descriptive group). Therefore, you have to use multiple groups for enrollment (0...*), each representing a certain subset of I/E criteria - for example: A AND (B OR C) would lead to the two groups A AND B, A AND C.
Gustav Vella (Oct 28 2021 at 16:59):
@Clemens Scherer has a good point here. Let me try and pick this up again, rephrase, and clarify misundertandings.
We are not takling about "actual" groups but of groups defined descriptively via characteristics.
For the "members" attribute both in R4 and in build R5 we have the rule "Can only have members if group is "actual" member.empty() or (actual = true)".
Inclusion/Exclusion groups are definitely not "actual" but descriptive groups defining chracteristics. Hence, according to the definition, we can't use the backbone element "members" for defining the I/E criteria.
Brian Alper (Oct 28 2021 at 22:51):
If you want to define inclusion/exclusion criteria (whether the group is actual=false, actual=true with no member data or actual=true with member data), the inclusion/exclusion criteria would be defined in the characteristic element (using exclude=true for exclusion criteria).
You can define Group A = Group B criteria AND Group C criteria by creating 2 characteristic elements in Group A to reference the other 2 groups. This approach will mean that Group A is smaller than Group B and Group C combined because you are expressing the combination of both sets of criteria.
If you wanted to define Group A as having members of Group B and Group C you could use member but that would only work for "actual" groups.
If you want to express Group A has the characteristics of Group B or Group C, I don't think there is an easy way to do it in the current Group Resource structure and we would probably need a Group.characteristic.value[x] option of Expression data type. There is a FHIR tracker https://jira.hl7.org/browse/FHIR-33264 to suggest adding Expression datatype to Group.characteristic.value[x] for other reasons.
Last updated: Apr 12 2022 at 19:14 UTC
