Sum of age groups doesn't match with the result from Count #2528
Comments
Not necessarily. We use the range definitioins of Try changing your Alternatively you could change |
|
Actually, let me have a look deeper look at this to see if we have something wrong here. The only real overlap should be from target values that have a range that spans across the upper bound of the two searches and in the case of a birthday we really shouldn't have that. |
|
I did another set of tests on a different subsection of my patients. general count to have a reference value gt1800 to check if it counts any patients that might not have a birthdate set. Now I did one lt1961, le1961, gt1961, ge1961 and =1961. [base]\Patient?_has:Condition:patient:code=C49.0&birthdate=lt1961&_summary=count [base]\Patient?_has:Condition:patient:code=C49.0&birthdate=le1961&_summary=count [base]\Patient?_has:Condition:patient:code=C49.0&birthdate=gt1961&_summary=count [base]\Patient?_has:Condition:patient:code=C49.0&birthdate=ge1961&_summary=count [base]\Patient?_has:Condition:patient:code=C49.0&birthdate=1961&_summary=count This means that there is something going wrong with the le and ge modifiers. It seems like those actually do the same as lt and gt |
We use the range interpretation of the search prefixes for both date and number/quantity searches. The spec says `lt` is interpreted as "the range above the search value intersects (i.e. overlaps) with the range of the target value" Previously, we interpreted that to mean that a search like `gt2016` should return any value above `2016-01-01 00:00:00` in the server's timezone. However, this interpretation leads to confusing and unintuitive results. Instead, we will now interpret the "search value" of 2016 to be the range `[2016-01-01 00:00:00, 2017-01-01 00:00:00)` and therefor it will only find target values above 2017-01-01 00:00:00 (inclusive). Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
We use the range interpretation of the search prefixes for both date and number/quantity searches. The spec says `lt` means "the range below the search value intersects (i.e. overlaps) with the range of the target value" and `gt` means "the range above the search value intersects (i.e. overlaps) with the range of the target value" Previously, we interpreted that to mean that a search like `gt2016` should return any value above `2016-01-01 00:00:00` in the server's timezone. However, this interpretation leads to confusing and unintuitive results. Instead, we will now interpret the "search value" of 2016 to be the range `[2016-01-01 00:00:00, 2017-01-01 00:00:00)` and therefor it will only find target values above 2017-01-01 00:00:00 (inclusive). And similarly for `lt`. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
We use the range interpretation of the search prefixes for both date and number/quantity searches. The spec says `lt` means "the range below the search value intersects (i.e. overlaps) with the range of the target value" and `gt` means "the range above the search value intersects (i.e. overlaps) with the range of the target value" Previously, we interpreted that to mean that a search like `gt2016` should return any value above `2016-01-01 00:00:00` in the server's timezone. However, this interpretation leads to confusing and unintuitive results. Instead, we will now interpret the "search value" of 2016 to be the range `[2016-01-01 00:00:00, 2017-01-01 00:00:00)` and therefor it will only find target values above 2017-01-01 00:00:00 (inclusive). And similarly for `lt`. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
We use the range interpretation of the search prefixes for both date and number/quantity searches. The spec says `lt` means "the range below the search value intersects (i.e. overlaps) with the range of the target value" and `gt` means "the range above the search value intersects (i.e. overlaps) with the range of the target value" Previously, we interpreted that to mean that a search like `gt2016` should return any value above `2016-01-01 00:00:00` in the server's timezone. However, this interpretation leads to confusing and unintuitive results. Instead, we will now interpret the "search value" of 2016 to be the range `[2016-01-01 00:00:00, 2017-01-01 00:00:00)` and therefor it will only find target values above 2017-01-01 00:00:00 (inclusive). And similarly for `lt`. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
We use the range interpretation of the search prefixes for both date and number/quantity searches. The spec says `lt` means "the range below the search value intersects (i.e. overlaps) with the range of the target value" and `gt` means "the range above the search value intersects (i.e. overlaps) with the range of the target value" Previously, we interpreted that to mean that a search like `gt2016` should return any value above `2016-01-01 00:00:00` in the server's timezone. However, this interpretation leads to confusing and unintuitive results. Instead, we will now interpret the "search value" of 2016 to be the range `[2016-01-01 00:00:00, 2017-01-01 00:00:00)` and therefor it will only find target values above 2017-01-01 00:00:00 (inclusive). And similarly for `lt`. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
We use the range interpretation of the search prefixes for both date and number/quantity searches. The spec says `lt` means "the range below the search value intersects (i.e. overlaps) with the range of the target value" and `gt` means "the range above the search value intersects (i.e. overlaps) with the range of the target value" Previously, we interpreted that to mean that a search like `gt2016` should return any value above `2016-01-01 00:00:00` in the server's timezone. However, this interpretation leads to confusing and unintuitive results. Instead, we will now interpret the "search value" of 2016 to be the range `[2016-01-01 00:00:00, 2017-01-01 00:00:00)` and therefor it will only find target values above 2017-01-01 00:00:00 (inclusive). And similarly for `lt`. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
For both date and number searches. We use the range interpretation of the search prefixes. The spec says `lt` means "the range below the search value intersects (i.e. overlaps) with the range of the target value" and `gt` means "the range above the search value intersects (i.e. overlaps) with the range of the target value" Previously, we interpreted that to mean that a search like `gt2016` should return any value above `2016-01-01 00:00:00` in the server's timezone. However, this interpretation leads to confusing and unintuitive results. Instead, we will now interpret the "search value" of 2016 to be the range `[2016-01-01 00:00:00, 2017-01-01 00:00:00)` and therefor it will only find target values above 2017-01-01 00:00:00 (inclusive). And similarly for `lt`. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
For both date and number searches. We use the range interpretation of the search prefixes. The spec says `lt` means "the range below the search value intersects (i.e. overlaps) with the range of the target value" and `gt` means "the range above the search value intersects (i.e. overlaps) with the range of the target value" Previously, we interpreted that to mean that a search like `gt2016` should return any value above `2016-01-01 00:00:00` in the server's timezone. However, this interpretation leads to confusing and unintuitive results. Instead, we will now interpret the "search value" of 2016 to be the range `[2016-01-01 00:00:00, 2017-01-01 00:00:00)` and therefor it will only find target values above 2017-01-01 00:00:00 (inclusive). And similarly for `lt`. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
|
We use the range interpretation of the search prefixes for both date and
For numbers, the spec additionally says:
Previously, we tried to interpret date search in the same way and so a search like However, even if we properly implemented this "arbitrarily high precision" clause for date search, Instead, I have opened #2531 to interpret the "search value" of |
I meant to include this in my last commit for #2528... Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
|
should be verified with issue 1624 1653 |
|
Verified by creating 6 patients (2 per year) with birthdates in 1961, 1962, and 1963. https://localhost:9443/fhir-server/api/v4/Patient |
Hey,
I just made several search queries on my FHIR server:
[base]\Patient?_has:Condition:patient:code=C49.0&_summary=count
=> Result: 1500
[base]\Patient?_has:Condition:patient:code=C49.0&birthdate=gt1961&_summary=count
=> Result: 369
[base]\Patient?_has:Condition:patient:code=C49.0&birthdate=le1961&_summary=count
=> Result: 1255
=> Total: 1624
The total of both queries should result in the same as the general count, right?
If I split the same search by gender the numbers work out again.
Is there something I'm doing wrong with the search?
I'm using version 4.7.1
The text was updated successfully, but these errors were encountered: