Stream: implementers
Topic: code search with hierarchical values
Josh Mandel (Mar 17 2016 at 17:24):
http://hl7.org/fhir/valueset-allergy-intolerance-status.html suggests a hierarchical value set -- but this is a bit misleading in behavior; do we expect:
GET /AllergyIntolerance?status=active
to return unconfirmed and confirmed results as well ?!
Lloyd McKenzie (Mar 17 2016 at 17:39):
It would certainly be desirable, but it would be good to clarify in the spec. Change request?
Jenni Syed (Mar 17 2016 at 17:42):
"It would certainly be desireable" Maybe, but it needs to be more clear when a single value is conveying a heirarchy. My inital thought is that this is very surprising value for something that doesn't seem multi-value (status - can something be in more than one state at a single time? maybe in physics :), but not intuitively)
Jenni Syed (Mar 17 2016 at 17:44):
But if I think of this in terms of the Observation.category, things can be categorized as multiple concepts - I can be both a "lab" and a "blood chem" (even though the spec doesn't allow a multi-value for that field)
Grahame Grieve (Mar 17 2016 at 18:18):
"do we expect:
GET /AllergyIntolerance?status=active
to return unconfirmed and confirmed results as well ?!" - no. we are clear in the spec that we do not. There's a modifier if you want to include unconfirmed and confirmed as well.
Eric Haas (Mar 17 2016 at 18:31):
@GG I can't find this in the spec so is unclear at least to me. I would certainly expect the behaviour Josh desc
ribes since 'active' is a parent concept of both 'unconfirmed' and 'confirmed'.
Eric Haas (Mar 17 2016 at 18:35):
never mind found the references to modifiers
Eric Haas (Mar 17 2016 at 18:39):
GET /AllergyIntolerance?status:below=active
Josh Mandel (Mar 17 2016 at 18:42):
I certainly don't think we've described the interaction of modifiers like :below with tokens specified only by code (with no system). That's another can of worms. When search problems, can I write GET /Condition?code:below=233873004, without even specifying snomed??
Josh Mandel (Mar 17 2016 at 18:43):
And servers don't have a way to say "I support :below only in certain contexts"
Eric Haas (Mar 17 2016 at 18:44):
Yes to your first questions ( its in the spec as an example GET [base]/Condition?code:below=126851005 )
Eric Haas (Mar 17 2016 at 18:45):
the search matches irrespective of code system - jsut readin this now
Grahame Grieve (Mar 17 2016 at 18:47):
Josh there is probably room for improvement with regard to documentation. I'm not sure that it's worth providing a computable way to say which modifiers are represented in which cases, but we are clear about the equality thing:
Grahame Grieve (Mar 17 2016 at 18:48):
Matches are literal (e.g. not based on subsumption or other code system features), but not case sensitive
Eric Haas (Mar 17 2016 at 18:48):
we should say just that last bit. I'll make a tracker
Grahame Grieve (Mar 17 2016 at 18:49):
what's the tracker for?
Eric Haas (Mar 17 2016 at 18:50):
to add "Matches are literal (e.g. not based on subsumption or other code system features), but not case sensitive" to here http://hl7-fhir.github.io/search.html#token I think that clears it up.
Grahame Grieve (Mar 17 2016 at 18:51):
that's where I copied it from
Eric Haas (Mar 17 2016 at 18:52):
Obviously I need new glasses cause I just read it
Josh Mandel (Mar 17 2016 at 18:55):
The thing I find incredibly confusing is this interacts with code datatypes like AllergIntolerance.staus
Eric Haas (Mar 17 2016 at 18:55):
but I think it should be more prominent not an ..oh by the way.. and then say something like if you want to base on subsumption use the modifiers described below. minor editorial stuff.
Grahame Grieve (Mar 17 2016 at 18:56):
why is that confusing?
Eric Haas (Mar 17 2016 at 18:56):
its a token search
Eric Haas (Mar 17 2016 at 18:56):
...still
Robert McClure (Mar 17 2016 at 20:14):
This discussion is giving me some shivers... Your GET shoud NOT (please no) return subsumed codes based as a defualt because a value set expansion (that's what you are operating against for the GET) is a flat list of codes. The expansion can also include additional information, like the hierarchy defined in the code system the codes came from, but that information is suplemental and not somehow "inside the code". So if you want your GET to bring back codes from the value set based on some of the additional information available to you, you should structure the GET "query" to bring a value set subset based on defined parameters. For your example you need to craft a GET that explicitly communicates you want code="active" and all codes subsumed by "active".
Grahame Grieve (Mar 17 2016 at 20:16):
Rob - you've misunderstood the context of the question, which is the primary reason you have the shivers
Robert McClure (Mar 17 2016 at 20:17):
OK... So when would a GET return subsumed concepts?
Grahame Grieve (Mar 17 2016 at 20:18):
well, we're not actually doing value set expansion here. The context is something else
Last updated: Apr 12 2022 at 19:14 UTC
