Skip to content
This repository has been archived by the owner on Apr 13, 2023. It is now read-only.

feat: support number and quantity type parameters #58

Merged
merged 3 commits into from
Apr 19, 2021

Conversation

carvantes
Copy link
Contributor

Description of changes:

number and quantity search param types are similar. quantity is essentially a number with units(expressed via system + code)

https://www.hl7.org/fhir/search.html#number
https://www.hl7.org/fhir/search.html#quantity

key features:

  • Implicit range according to number of significant digits.

    Searching on decimals involves an implicit range. The number of significant digits of the implicit range is the number of digits specified in the search parameter value, excluding leading zeros. So 100 and 1.00e2 both have the same number of significant digits - three

    [parameter]=100.00 | Values that equal 100, to 5 significant figures precision, so this is actually searching for values in the range [99.995 ... 100.005)

  • Quantity type allows to specify system and code

  • Prefixes. Behavior is mostly the same as the prefixes for Dates. Some refactoring was done to reuse prefixes code across several query types.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Copy link
Contributor

@nguyen102 nguyen102 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good. One minor change suggestion, and one question.

src/QueryBuilder/typeQueries/common/prefixRange.ts Outdated Show resolved Hide resolved
Object {
"range": Object {
"valueQuantity.value": Object {
"gte": 0.0053950000000000005,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are all of the 0s before the 5 intended? Why not just 0.005395?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In practical terms, the number is 0.005395. The ...00005 is rounding error due to floating-point arithmetic. This is fairly standard and is one of the reasons why FHIR proposes comparing against a small range around the number instead of doing equality comparisons for number searches.

https://floating-point-gui.de/

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants