Stream: implementers
Topic: Sorting of parameters with 0..* cardinality
Muhammad Abubakar Ikram (Nov 22 2018 at 07:01):
What should be the behavior if the search parameter in _sort does not have scalar value?
for example: {base}/Patient?_sort=given
the given names of a patient could be multiple so how to sort resources in such condition?
Michele Mottini (Nov 22 2018 at 13:55):
I believe the specifications do not say anything about that. I'd say implementation can do what they like - that would be to use the minimum or maximum of the available values
Lloyd McKenzie (Nov 22 2018 at 15:42):
From the spec: "A search parameter can refer to an element that repeats, and therefore there can be multiple values for a given search parameter for a single resource. In this case, the sort is based on the item in the set of multiple parameters that comes earliest in the specified sort order when ordering the returned resources."
Lloyd McKenzie (Nov 22 2018 at 15:43):
So if you ask to sort by Patient.name, then "John Abrams Smith" will come before "Adam George Smith" (on the grounds that "Abrams" comes before "Adam".
Lloyd McKenzie (Nov 22 2018 at 15:44):
If that's not the behavior you want, then you'll need to define custom search parameters that are specific to first name, first middle name, second middle name, etc.
Michele Mottini (Nov 22 2018 at 16:09):
(Sorry, my bad - I should have checked)
Elliot Silver (Nov 22 2018 at 17:22):
I don't think that result is what people would expect, at least for Patient name.
Lloyd McKenzie (Nov 22 2018 at 17:26):
True. We could propose a change in R5 that where collections are defined as "ordered" (as names are) that the sorting is based on defined order. Though not sure we can do that when the backward compatibility rules kick in
Elliot Silver (Nov 22 2018 at 17:32):
Add a new sort prefixes < and > for ascending and descending according to server-defined criteria, or according to a "logical" sort order?
Elliot Silver (Nov 22 2018 at 17:49):
Lloyd McKenzie (Nov 22 2018 at 17:54):
Was more thinking about saying that rather than sorting by the "lowest" element within a collection, if the collection was ordered, then you'd sort by the first element in the collection.
Elliot Silver (Nov 22 2018 at 17:55):
Do we have collections identified as "ordered" vs "non-ordered"?
Elliot Silver (Nov 22 2018 at 18:06):
My thought was that by adding new search prefixes, that trigger the new behavior (which is, perhaps, as you suggest), you could avoid backward compatibility issues.
Am I correct that current behavior is that when sorting by patient given name, not only would you sort by the alphabetically first given name (whether that's first or middle), but also if the patient has multiple names, then you'd sort by the alphabetically first of any given name across any of their names?
Lloyd McKenzie (Nov 22 2018 at 18:15):
Elements now have an orderMeaning element that can be populated if the order has significance. It doesn't most places, but does for HumanName.given and a few other places.
Lloyd McKenzie (Nov 22 2018 at 18:17):
And yes, as currently defined, if there were multiple names, you would take all of the name parts (including text) that are included by the current search criteria and sort them alphabetically and would then sort the Patient based on the first of those strings
Elliot Silver (Nov 22 2018 at 18:18):
Thanks.
Muhammad Abubakar Ikram (Nov 29 2018 at 16:37):
@Lloyd McKenzie "So if you ask to sort by Patient.name, then "John Abrams Smith" will come before "Adam George Smith" (on the grounds that "Abrams" comes before "Adam"."
would you please help me to understand this? how "John Abrams Smith" will come before "Adam George Smith"?
I understand that you have not ordered these two full names as the whole strings but in parts.
Jean Duteau (Nov 29 2018 at 18:12):
I'm not Lloyd, but I'll answer for him since he's away. sorting on Patient.name is sorting on all of the name parts of each patient. His earlier quote pointed out that when a search parameter contains multiple elements (like Patient.name), then it uses the earliest element. So it uses "Abrams" from the first Patient and "Adam" from the second patient and puts "John Abrams Smith" ahead of "Adam George Smith".
Muhammad Abubakar Ikram (Nov 30 2018 at 06:51):
@Jean Duteau oh alright, kindly correct me if I am wrong.
So, you are saying that first sort the subparts of the name which are "John", "Abrams" and "Smith" hence, "Abrams" will be on first. Then, do this for the second full name from the second full name "Adam" comes first. So, then sort both full names on basis of "Abrams" and "Adam" which one come first its full name will come first. Am I right?
Jean Duteau (Nov 30 2018 at 07:44):
Yep
Brian Postlethwaite (Dec 03 2018 at 10:39):
And with Patient name searching, really depends what you're doing here too, if you're doing demographic analysis or other non patient specific searching that makes sense, but if you're looking for a patient, you're more likely to be doing an MPI search where a set of values are applied and the order is based on rank/weighting rather than by name.
And I'd expect there to be a specific name that would be identified as the usual one for sorting, and that depends on the system which way they do that, and other factors in the use case..
Lloyd McKenzie (Dec 11 2018 at 01:51):
The challenge is that most collections in FHIR are unordered - so ordering them prior to comparison is necessary. However, some collections are ordered, and ordering them prior to comparison breaks things. Unfortunately, we're past the point where we can fix this for R4 - and based on our interversion compatibility rules, it's going to take significant agreement from the community to fix it in R5.
Last updated: Apr 12 2022 at 19:14 UTC
