Stream: implementers
Topic: sort order
Nikolai Schwertner (May 04 2016 at 18:08):
It looks like the "correct" sort order according to FHIR when requesting results with _sort:asc=given is not exactly intuitive. The behavior if you search would be to map each patient to her alphabetically-earliest given name. So a patient with:
{
"name": [{
"given": ["c", "f","d"]
}, {
"given": ["b, "a"]
}]
}
would be sorted by a (in asc context) or f (in desc context).
Wouldn’t it make sense to have a mechanism for requesting a sort order that would be “natural” to human beings (i.e. sorted by b a in asc and c f d in desc)?
Grahame Grieve (May 04 2016 at 18:37):
interesting. we've never talked about this
James Agnew (May 04 2016 at 19:59):
Wow, that is interesting.. I've never thought about this, but you're right, the way we do this would produce surprising results.
Doing this the "right way" would be hard though, at least for me.
Nikolai Schwertner (May 04 2016 at 21:06):
Could we assume that the first name in a list of names is the preferred one and takes precedence when sorting(that would need to be in the spec however)? In the prior example applying this rule would mean sorting by c f d b a. Does this make any sense at all?
Josh Mandel (May 04 2016 at 21:33):
(FYI, this came up for us in designing a pretty straightforward FHIR-based patient selector widget -- and we realized it was hard to support with the standard API.)
James Agnew (May 04 2016 at 22:13):
Hmm... Does c f d b a make more sense, or b c a f d?
Is there any reason that the first repetition of the name (as opposed to the first repetition of given) carries more weight?
Josh Mandel (May 04 2016 at 22:30):
Shouldn't be :)
Brian Postlethwaite (May 04 2016 at 22:37):
Should there be some consideration as to what use properties should be used?
as described for what you should use in the display segment that I described for practitioner.
http://hl7-fhir.github.io/practitioner-definitions.html#Practitioner.name
This probably applies to patient also, and therefore maybe to the sort order.
Josh Mandel (May 05 2016 at 00:59):
It's an interesting point. But of course here, we're distinguishing between multiple instances of the same field (given, or family) even within the same name. I hate the idea is special cases but they current behavior prevents the creation of a simple FHIR-powered patient picker.
Grahame Grieve (May 05 2016 at 04:49):
well, the most likely solutions seems like defining a new search parameter that only searches the first of the given names
Grahame Grieve (May 05 2016 at 04:49):
but that fails when a patient actually uses their second given name
Lloyd McKenzie (May 05 2016 at 20:57):
Would it make sense to say that when you're sorting by an element that's a collection, you're actually sorting by the string concatenation of those elements?
Josh Mandel (May 05 2016 at 21:49):
When you're sorting by a string element? Maybe, but I know in our server at least the sort code is tied into our indexing code, so we'd want consistent rules.
Chris Grenz (May 07 2016 at 13:08):
I'd like to see us define type equivalence/comparison rules for each of the types. Similar issue applies when sorting by (or slicing by) CodeableConcepts...I'm unclear if/where this is defined?
Grahame Grieve (May 07 2016 at 13:08):
sigh. we haven't
Chris Grenz (May 07 2016 at 13:09):
ok...that's one of my goals for this week mainly in the context of slicing.
Grahame Grieve (May 07 2016 at 13:10):
well, slicing, it's narrower - the fixed value has to match
Grahame Grieve (May 07 2016 at 13:11):
or the concept has to match
Chris Grenz (May 07 2016 at 13:11):
Anonymous slices....
Grahame Grieve (May 07 2016 at 13:11):
what's an anonymous slice?
Chris Grenz (May 07 2016 at 13:14):
A bit in left field here... There are times when we want to be able to dis-aggregate a list by some criteria but don't need to name or constrain any slice in particular. We use this then to compare resources. So I slice Encounter.participant by type. We then know that type is the "primary key" for participants when moving them into a relational system or when merging instances (PATCH).
Chris Grenz (May 07 2016 at 13:17):
Finally, another use case is defining a constraint to dis-allow redundant CodeableConcepts (e.g. Encounter.type). What's a duplicate?
Last updated: Apr 12 2022 at 19:14 UTC
