Stream: implementers
Topic: searching optional attribute
Mark Kramer (Mar 05 2016 at 23:11):
AllergyIntolerance.category is an optional attribute with possible values drug, food, environment, and other. If I want to search for drug allergies, what is the best (most efficient and accurate) way to do that? I can't simply search with category=drug because that would miss resources where 'category' is missing (PS -- I am trying to build a drug allergy list, so the answer can't be 'get the drug allergy list')
(note - in original post, I confused type and category - what I meant was category)
Josh Mandel (Mar 06 2016 at 02:40):
As far as I can tell right now, @Mark Kramer, if you want to avoid non-drug allergies you have to write two queries:
GET /AllergyIntolerance?category=medication GET /AllergyIntolerance?category:missing=true
This is a pain, of course (and the "include missing" logic is harder than other "or" searches that could be handled like category=food,medication; perhaps it's worth an API level fix for this discrepancy).
Don't forget that you could just get all allergies and filter client-side. This is unlikely to be a huge list, so it's probably the better approach :/
(And note that for food vs. drug allergies you need category rather than type).
Grahame Grieve (Mar 06 2016 at 08:08):
I'm not sure what the API fix for this would be. But AllergyIntolerance.category is a pain - anytime you do analysis on this attribute with a bunch of clinical record stakeholders, you're going to get a lot of pain and argument.
Grahame Grieve (Mar 06 2016 at 08:08):
are there other cases like this?
Josh Mandel (Mar 07 2016 at 00:30):
The API level fix would be something like replacing the :missing modifier with an empty value, so ?category=medication,, (I'm not advocating this, just explaining what I meant by API level fix)
Grahame Grieve (Mar 07 2016 at 00:32):
no I wouldn't advocate it either, but what other options is there?
Josh Mandel (Mar 07 2016 at 00:41):
The only alternative I see is top level boolean (and/or) structures for the REST API.
Grahame Grieve (Mar 07 2016 at 00:42):
top level boolean?
Josh Mandel (Mar 07 2016 at 00:43):
Like the ability to create arbitrary and/or queries.
Josh Mandel (Mar 07 2016 at 00:45):
?$or:[{category:{$missing: true}}, {$category: "medication"}}]
Grahame Grieve (Mar 07 2016 at 00:47):
should use _filter for that
Josh Mandel (Mar 07 2016 at 00:50):
I'm just saying that the REST API could supported this sort out logic.
Grahame Grieve (Mar 07 2016 at 00:50):
we do support it in the _filter parameter
Josh Mandel (Mar 07 2016 at 00:50):
_filter isn't on many people's radar (mine included)
Josh Mandel (Mar 07 2016 at 00:50):
Of course.
Grahame Grieve (Mar 07 2016 at 00:53):
yes. cause it's complicated. So lets clone the complications?
Josh Mandel (Mar 07 2016 at 01:23):
Hey now, I was just answering your question of how we could deal with this feature!
Grahame Grieve (Mar 07 2016 at 01:34):
ok fair enough. On the other hand, I'm not sure we want to impose _filter for this case.
GET AllergyIntolerance?category:may=medication
Grahame Grieve (Mar 07 2016 at 01:34):
or soemthing like that
Mark Kramer (Mar 08 2016 at 23:30):
Grahame, you asked if there are other cases like this, and I think there are many, many category-like elements that are both optional and searchable.
Grahame Grieve (Mar 08 2016 at 23:55):
and also where the idea of excluding known others but not unknowns arises? like Observation.category perhaps.
Grahame Grieve (Mar 08 2016 at 23:55):
SQL deals with this with a double negative, right?
Bryn Rhodes (Mar 09 2016 at 01:01):
select * from AllergyIntolerance where IsNull(category, 'drug') = 'drug'
Bryn Rhodes (Mar 09 2016 at 01:01):
Would be one way to do it.
Grahame Grieve (Mar 09 2016 at 01:02):
or select * from AllergyIntolerance where not categroy != 'drug'
Josh Mandel (Mar 09 2016 at 02:20):
You and your fancy SQL. where category=NULL or category='drug'
Grahame Grieve (Mar 09 2016 at 03:05):
well, that's 3 ways to do it. Anyone want to try for 4?
Grahame Grieve (Mar 09 2016 at 03:05):
GET [base]/AllergyIntolerance?category=drug,:missing
Grahame Grieve (Mar 09 2016 at 03:07):
that would be the equivalent, except that :missing is a modifier and can't be combined like that. That's the core problem, I think
Bryn Rhodes (Mar 09 2016 at 03:11):
I actually like the :may modifier you proposed above:
Bryn Rhodes (Mar 09 2016 at 03:11):
GET AllergyIntolerance?category:may=medication
Bryn Rhodes (Mar 09 2016 at 03:12):
Reads pretty naturally, category may equal medication.
Grahame Grieve (Mar 09 2016 at 03:28):
great. Someone likes me. I was beginning to wonder...
Brian Postlethwaite (Mar 15 2016 at 05:16):
And that :missing assumes a true value
Brian Postlethwaite (Mar 15 2016 at 05:16):
Should :missing consider nullflavour extensions too?
Grahame Grieve (Mar 15 2016 at 05:33):
I would consider them missing
Brian Postlethwaite (Mar 15 2016 at 05:35):
(as the node would exist, but its meaning is that it's not there)
And my search logic needs to be updated (and my servers fhirpath expressions for validation will want some internal checking also)
Lloyd McKenzie (Mar 15 2016 at 11:37):
I don't think it should care about the type of extension - if @value isn't there, it's "missing". Do we need to clarify the text of the spec to make that explicit?
Brian Postlethwaite (Mar 15 2016 at 11:45):
as long as its the @value that exists, and not the parent node (which has the name in it)
Michelle (Moseman) Miller (Nov 04 2016 at 16:19):
FYI -- this topic of searching on optional attributes came up in Patient Care (related to GF#12136). While PC agreed to add a usage note for AllergyIntolerance.category searches, does a broader statement exist anywhere to reiterate being careful when searching on optional attributes (e.g. consider how missing/null should be handled in each use case and if missing/null is needed then recommend which way to query for either missing or value XYZ)?
Grahame Grieve (Nov 04 2016 at 18:55):
logical place is to add a note to the implementers safety chcek list
Michelle (Moseman) Miller (Nov 07 2016 at 13:48):
GF#12324 has been logged
Last updated: Apr 12 2022 at 19:14 UTC
