Structured query v2 #3
Conversation
geloro94
requested review from
alexanderkiel,
rwm,
juliangruendner,
lukszi and
thkoehler11
| "valueFilter": { | ||
| "type": "object", | ||
| "properties": { | ||
| "type": { "enum": ["concept", "quantity-comparator", "quantity-range"]} |
There was a problem hiding this comment.
The date-time-comparator type is missing here?
|
|
||
| | Enumeration | Comparator | | ||
| | ----------- | ------------- | | ||
| | le | less equal | |
There was a problem hiding this comment.
Why don't we use ≥ and ≤ signs instead of less equal and greater equal like above?
| ## ConceptValueFilter | ||
| ### DateTime-comperator | ||
|
|
||
| A valueFilter of type datetype can be applied to all datetime criterion concepts. It allows to use the |
There was a problem hiding this comment.
IHMO the type should be called date-time-comparator and not datetype to be on par with the quantity-comparator type name.
Fixt SQV2 Example attributeFilter -> attributeFilters; quanitityUnit -> unit
|
What is the reason for multiple term codes per criteria? |
|
Multiple codes per criterion allow us to express synonyms. Similar to https://www.hl7.org/fhir/datatypes.html#CodeableConcept coding. This would allow us to have a single UI representation for i.e. Sleepapnea encoded in ICD-10 and SNOMED and simultaneously query both. Alternatively, we could have used concept mappings. We likely will not use this feature in ABIDE, but in other projects utilizing the structured query. |
|
I thought that we will use the mapping to expand the criteria concept into multiple synonym codes. At the end we most likely will use value sets for FHIR searches, because using value sets can be potentially more performant and keeps query string short. But I'm ok if we allow multiple term codes. At the end, more options are good here. I have one question about the display of the multiple term codes. The FHIR CodeableConcept has an additional text field for the use of displaying one string that is valid for all the codes. Having only the multiple display strings would force an UI to choose one of them. So we may go the full CodeableConcept route if one merged display string would be relevant for us. |
|
In the UI Profiles, we already do so, we do not use the display from the TermCode but have a TerminologyEntry with multiple TermCodes and a single display. This is also necessary for unofficial displays like german translations for snomed. |
Fixt errors in example
termCode -> termCodes
termCode -> termCodes for array of termCode
No description provided.