Stream: terminology
Topic: Filtering by property
Josh Mandel (Mar 25 2022 at 00:18):
A code system can define filters as well as properties; a value set can apparently reference both of these through ValueSet.compose.include.filter, which can "Select codes/concepts by their properties (including relationships)"
-
Does this imply that it's invalid to define a filter and a property with the same name? Otherwise how do you resolve the difference in case of conflict? Should there be a constraint to this effect?
-
When filtering in a ValueSet based on a CodeSystem property... those property values can be codings, booleans, date times, strings, integers, decimals, etc. What syntax is used to query for boolean properties or or codings or for dates? Is the syntax based on FHIR search parameters? Are prefixes like
gtallowed? I am having trouble finding details on this.
Michael Lawley (Mar 25 2022 at 00:39):
- No. If you only declare a property, then there's a (limited) default set of filters for that property. If you additionally declare a filter then that specifies what's available.
- Most are straightforward - boolean is true / false, integers are sequences of digits, optional sign, etc Mostly we rely on HAPI's default behaviour for a String passed to the single-argument constructor of the primitive type class: e.g.,
new DateTimeType(propValue)
For Coding we opted for system|code as the syntax. I recall discussing it here somewhere, but I don't believe it's in the spec itself.
Josh Mandel (Mar 25 2022 at 00:48):
Thanks! and for date times, are they iso8601 strings? Is matching based on timespan containment?
Michael Lawley (Mar 25 2022 at 01:04):
It ultimately uses BaseDateTimeType.parse() which accepts a range of formats (not documented except by code).
Our matching is just based on the string representation. However, having just looked a little more closely, I see that the only impact of the parsing is to "validate" the string's format and that our matching is exactly against the original string value in the CodeSystem.
Michael Lawley (Mar 25 2022 at 01:05):
Also, there's no range/less/greater querying available via filters
Josh Mandel (Mar 25 2022 at 01:09):
Interesting -- thanks again for the details here!
Michael Lawley (Mar 25 2022 at 01:09):
I think the reasoning is that DateTimes in terminology are controlled and, within a single code system, have consistent format, precision and interpretation, so more sophisticated handling is not really needed.
However, SNOMED has a dateTime property (effectiveTime) which we handle specially because of ECL where you can do before/after queries, but the timezone is fixed (Zulu/UTC).
Josh Mandel (Mar 25 2022 at 02:12):
Thanks! I'm a bit uneasy in my understanding of what gets modeled by filters and what gets modeled by properties. It seems like there is gray area -- like, a filter asking about "code: is-a, op: =, value: 123" vs asking about "code: concept, op: is-a, value: 123". (I'm trying to imagine that every concept has a fixed list of attributes and relationships -- together, "properties" -- and ideally filters could be expressed as queries against that list.)
Am I right in thinking that not every property is currently addressable through the filters mechanism? Like, should a server explicitly list properties in the filters array of a CodeSystem if it plans to allow filtering by them?
Josh Mandel (Mar 25 2022 at 17:57):
Gino recently pointed me at https://build.fhir.org/codesystem.html#filters which partially addresses the question. I submitted FHIR-36643 to request that "exists" and "regex" should have standard filter semantics for all properties, in addition to the currently defined "=" and "in".
It would also be good to standardize a "concept" filter supporting "child-of", "is-a", "descendant-of" and "generalizes", similar to what is described at https://build.fhir.org/snomedct.html#filters but applying to any CodeSystem with hierarchical concepts.
Josh Mandel (Mar 25 2022 at 18:06):
To this end I've also submitted FHIR-36644
Last updated: Apr 12 2022 at 19:14 UTC
