FHIR Chat · token search - case sensitive?

Stream: implementers

Topic: token search - case sensitive?

Lital Inghel (Jan 27 2022 at 15:39):

Should code and code system parameters values be case sensitive?
It's not very clear from FHIR spec, not sure what should we implement
http://hl7.org/fhir/R4/search.html#token

Michele Mottini (Jan 27 2022 at 15:46):

I’d go for case insensitive

Yunwei Wang (Jan 27 2022 at 15:47):

It is not required but recommended that server support case insensitive token search.
"When in doubt, servers SHOULD treat tokens in a case-insensitive manner, on the grounds that including undesired data has less safety implications than excluding desired behavior"

René Spronk (Jan 27 2022 at 15:48):

I remember from earlier discussions that there are some code systems that are case sensitive (whereas others are not), so you'd better beware.

Yunwei Wang (Jan 27 2022 at 15:50):

Yes, Code system could use CodeSystem.caseSensitive to enforce that.

René Spronk (Jan 27 2022 at 15:51):

.. which means that a server can't only support case-insentive search, unless one is sure that one would never have to deal with a cases sensitive coding system.

Yunwei Wang (Jan 27 2022 at 15:56):

Just read this sentence several times: "Match is case sensitive unless the underlying semantics for the context indicate that the token should be interpreted case-insensitively (see, e.g. CodeSystem.caseSensitive)." This seems suggest that server SHALL treat token as case sensitive unless CodeSystem specifically says CodeSystem.caseSensitive=false. That is contradict to the sentence that "When in doubt, servers SHOULD treat tokens in a case-insensitive manner," ????

Paul Church (Jan 27 2022 at 15:57):

We just implemented case sensitive and left it at that.

Yunwei Wang (Jan 27 2022 at 15:58):

So the default of CodeSystem.caseSensitive is true. Hmm, that is not what I thought.

Lital Inghel (Jan 27 2022 at 17:49):

got confused, so better to implement case sensitive as this shall be the default by the IG?

Craig McClendon (Jan 27 2022 at 18:45):

I've come across very few instances where case-sensitivity solved a problem rather than created one. Especially where humans may be involved in trying to search for things.

UCUM is the one example I can even think of that has meaningful/necessary case sensitivity, and I'm hard pressed to find examples where there would be meaningful ambiguity if you ignored case on search. 'K' (kelvin) vs 'k' kilo? But those would not be likely used in the same context. Perhaps someone can think of an example where it may bite you?

Craig McClendon (Jan 27 2022 at 18:49):

'Ms' mega-second vs 'ms' millisecond maybe? That's quite a few orders of magnitude though.

Daniel Venton (Jan 27 2022 at 18:52):

I have not seen any major code system other than UCUM where k and K don't have the same meaning. I'm sure somebody will be able to say, "in the national code system of Latveria D means Dr. Doom and d means doom (yours)." Since we know there is at least one system where case matters, then I think that treating all (unless otherwise known) as case sensitive is the safe route.

Lloyd McKenzie (Jan 27 2022 at 21:43):

URIs are always case sensitive. (So do your best to get the case right.) However, it's reasonable and desirable for systems to transparently handle case errors. And anyone who deliberately creates URIs that differ only by case and the difference is semantically meaningful should be taken out behind the barn...