Stream: implementers
Topic: valueset - sorted by preferred
Jose Costa Teixeira (Jan 25 2018 at 06:57):
How can we provide some "sort by preferred" functionality to a valueset? Is there an attribute in valueSet.include.code.concept that i can use like a "sequenceNumber" to sort on?
Scenario: Physician 1 wants to select an ICD code from a list, using a search or type-ahead box, and the codes displayed should be sorted by any sort order we want, e.g. their "preferred codes" displayed first, not by default ICD order.
Grahame Grieve (Jan 25 2018 at 10:42):
how do you define what a 'preferred code' is?
Jose Costa Teixeira (Jan 25 2018 at 10:43):
this would probably be like a "most recent files" thing. When we select a code, it gets +1.
Jose Costa Teixeira (Jan 25 2018 at 10:44):
so, the system will know for each code, a score or a sequence number.
Jose Costa Teixeira (Jan 25 2018 at 10:44):
for that physician, or for that physician group.
Jose Costa Teixeira (Jan 25 2018 at 10:47):
the definition of "preferred codes" can be also provided as reference data by the hospital,
e.g. "for surgeons, when they search for "accident", "CV accident" comes before "car accident", but for GPs, it is the other way around".
What i want to convey is the information that supports this.
Jose Costa Teixeira (Jan 25 2018 at 10:47):
i don't see anything, so I could have an extension, say "score"..?
unless there is something already
Robert McClure (Jan 25 2018 at 13:57):
This is yet another example where code system supplement would be used and then applied via an expansion profile. Keep in mind that a code system supplement is simply something that has information about code system concepts, such as "choice frequency" linked to the concept identifier. You can make these very specific so that it is applied for only one value set.
Lloyd McKenzie (Jan 25 2018 at 14:44):
This would definitely be extension territory. I don't think it would be captured with a code-system suppment because it's valueset-specific. There'd be no such thing as a "preferred SNOMED code", but there might be a "preferred code from this list of SNOMED diagnoses" and a different "preffered code from this list of SNOMED procedures"
Robert McClure (Jan 25 2018 at 15:12):
@Lloyd McKenzie Ok, I guess that makes sense with the focus on one specific value set. But if this was applied for any value set that listed ICD codes, then would a supplement be the choice then?
Lloyd McKenzie (Jan 25 2018 at 16:11):
I can't think of a use-case that would be valueset-independent...
Michael Lawley (Jan 29 2018 at 23:28):
If you're going to explicitly order the codes, then do it in the ValueSet and just use the definition (ie do it all client-side, since this is a UI/UX issue). Otherwise, you could use a terminology server that returns results from $expand with a filter parameter in "best match" order.
Our terminology server allows you to include an extension to adjust the weights on codes, so for your use case the GP ValueSet would increase the weight for "car accident" and the surgeon's ValueSet would do the same for "CV accident"
Malgorzata Schwab (May 25 2018 at 16:57):
@Lloyd McKenzie So... what is the conclusion? Sort is value-set specific, is that a good use case for an extensions? how to go about it?
Lloyd McKenzie (May 25 2018 at 20:09):
Define an extension on ValueSet.compose.include.concept that indicates relative popularity and define an operation that allows you to generate an expansion sorted in that order
Grahame Grieve (May 25 2018 at 20:17):
a parameter to the expansion operation, not a new operation
Michael Lawley (May 28 2018 at 10:42):
Is there a need for the parameter? If the ValueSet contains the extension elements, then presumably that's indication enough that they should be used to influence the sort order. Ontoserver supports such an extension (documented here http://ontoserver.csiro.au/docs/5.1/api-fhir-extensions.html) at the compose.include level
Robert McClure (May 30 2018 at 13:29):
Once a sort value is defined for the valueset via an extension, wouldn't we just expect $expand to bring back the sort value as another concept attribute, and the client can use that to order the list?
Yunwei Wang (May 30 2018 at 13:42):
@Michael Lawley That is an interesting extension. Just to clarify, when you say "adjust the ranking ... of codes when performing an $expand with filter", you mean the codes expanded from he include section. Is that right? Because my first thought was that ranking applies to $expand?filter=xxxx operation.
Michael Lawley (May 30 2018 at 22:32):
@Robert McClure Yes, I think that's a good way to manage it. However, for large expansions it might be nice if the results could be returned sorted on that field so that 'give me the first n results' was actually useful.
Michael Lawley (May 30 2018 at 22:40):
@Yunwei Wang Yes, after performing the $expand, then applying the filter=xxx to match and rank the codes, we adjust the scores of the codes that were contributed by that include.
Yunwei Wang (May 31 2018 at 13:51):
Can you give me an example how the filter works with scores?
Thanks.
Michael Lawley (Jun 13 2018 at 00:34):
Lets assume there are two include criteria (an OR) - one is "all active SNOMED codes" and the other is "all inactive SNOMED codes". Further assume that the first criteria has a boost of 1.5 and the second of 0.5. Next, assume that there are two codes for 'cataract', one of which is inactive. Then you do a $expand?filter=catarac (note the substring), both codes get the same raw score (say, 0.875) but because of the weighting the active concept ends up with a score of 1.3125 and the inactive concept gets a score of 0.4375.
Last updated: Apr 12 2022 at 19:14 UTC
