Stream: implementers
Topic: Search on AllergyIntolerance.patient
Grahame Grieve (Jun 05 2018 at 01:48):
@Michele Mottini has picked up an issue in my server which is an an issue in the specification itself
Grahame Grieve (Jun 05 2018 at 01:49):
the symptom is that the search http://test.fhir.org/r3/AllergyIntolerance?patient=1 returns an error which should be:
Parameter "patient" is invalid because the type of resource referenced is not specified
Grahame Grieve (Jun 05 2018 at 01:49):
but if you check at http://hl7.org/fhir/STU3/allergyintolerance.html#search you'll see that patient is apparently only defined for the patient resource, and so that error is wrong.
Grahame Grieve (Jun 05 2018 at 01:50):
only... not so fast. if you look carefully, you'll see that it has 31 other resources using the common search parameter
Grahame Grieve (Jun 05 2018 at 01:52):
and if you hunt down the formal definition in the downloads - because this it is never published - you'll see that this search parameter has 2 target types: Patient and Group. Because some of the other resources allow group, even though AllergyIntolerance doesn't
Grahame Grieve (Jun 05 2018 at 01:52):
my server is actually implementing the underlying search parameter
Grahame Grieve (Jun 05 2018 at 03:59):
so the question is, what does it mean when a resource shares the parameter, but has a lesser target type range?
Michele Mottini (Jun 05 2018 at 13:19):
Isn't that a mistake in the formal definitions? (I actually did notice it in our own auto-generated code and I programmed around it...)
Michele Mottini (Jun 05 2018 at 13:20):
See also https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13601
Grahame Grieve (Jun 05 2018 at 13:50):
Yes, this is the same issue
Grahame Grieve (Jun 05 2018 at 13:50):
there's a mistake somewhere, but I'm not sure where it is.
Grahame Grieve (Jun 05 2018 at 13:50):
@Ewout Kramer - you drove this...?
John Silva (Jun 05 2018 at 17:28):
related question -- is this property name going to be 'harmonized' to 'subject' like is done in other STU3 or newer resources? ( https://www.hl7.org/fhir/encounter.html#tabs-diff )
Grahame Grieve (Jun 05 2018 at 18:46):
Our general rule is that if it's just patient, then it should be patient, where as it would be subject if it can be something other than patient (such as group)
Christiaan Knaap (Jun 05 2018 at 18:55):
Just added to the issue that it is also raised on nr. #15903. In Vonk we override this searchparameter with a corrected version of it that targets only Patient because we got this same question several times.
Ewout Kramer (Jun 06 2018 at 15:02):
@Ewout Kramer - you drove this...?
In what sense do you mean?
The background I have is this: We've found this because users of the .NET API reported it: https://github.com/ewoutkramer/fhir-net-api/issues/339, on 30 june 2017 I wrote
"I found the cause. No, it's not all of them. Some resources have their own defined parameter "patient", here the target is just "Patient". However, there is a searchparameter in the spec called "clinical-patient" that is defined for a number of resources, and which has both Patient and Group. This is the cause. It does not seem to make sense to me. I'll continue this discussion in Zulip...."
this is talking about the search parameters in "search-parameters.xml", a file that we use to generate the API. It has
<target value="Patient" />
<target value="Group" />
so, this seems to be the cause.
Grahame Grieve (Jun 06 2018 at 19:55):
you drove that the cross-research search parameters should be correctly defined
Grahame Grieve (Jun 06 2018 at 19:57):
what I'm not sure about here is which way to resolve this:
- if the shared resource doesn't have all the target types on a particular resource to which it applies, then the target need not be specified
- a search parameter can't be shared across multiple resources in this case
- this search parameter is wrong because "patient" should never target "Group"
Ewout Kramer (Jun 07 2018 at 08:43):
So, I am leaning to the third option - if we've noticed these parameters are actually "the same" across resources, we might ask a committee why they deviate. The result of this discussion might be a conclusion that either
a) the search parameter is not "the same", and should be renamed, so it is no longer shared
b) yes, it should be aligned, and the additional targets added or removed
The second option is not possible I think - we consider adding a new reference type a non-breaking change, but it would make a shared search parameter disappear - which is a breaking change.
The first option would cause "runtime" errors: there would be no way to avoid causing errors by looking at just the definitions we provide, unless we would define a parameter with the same name both on the general resource and on the more specific resource where it deviates. This adds complexity.
I think we can get away with option 3 for now, as this might well be the only case.
Michele Mottini (Jun 07 2018 at 17:49):
+1 for changing the definition of the "patient" search parameter to target only Patient
Last updated: Apr 12 2022 at 19:14 UTC
