Performing an Observation search with value-quantity that has zero's after decimal gives no results

[brianpos]

If you have an Observation in your database with a quantity value of "140.0" a search with that value will not return any results (with no error)
http://zzzz z.com.au/fhir/Observation?value-quantity=140.0||mm[Hg]

however if you search for 140 (no decimal places) then it works
http://zzzz z.com.au/fhir/Observation?value-quantity=140||mm[Hg]

[mharthoorn]

As far as I can see, the behaviour that Brian mention is not a bug, but by design. 140.0 IS more precise than 140 so. A search for 140.0 should exclude a value of 140.5. While a search for 140 should include a value of 140.5. This behaviour is documented and conforms to our unit tests. See https://github.com/furore-fhir/Fhir.Metrics/blob/master/Fhir.Metrics.Tests/TestSearchableQuantity.cs.

The measurement 140 means that the value lies between 139.5 and 140.5. So it is very well possible that the value lies outside of the range of 140.0.

Another way of explaining it: with 140 you will find 140.0. Where as with 140.0 you will not find 140.

Or am I missing your point here Brian?

[brianpos]

I searched for exactly what was in the value and it didn't get returned. 140.0 was in the db.

[CorinaCiocanea]

So, appereantly this could be a bug, but is a bug in the Hl7.FhirLibrary that Spark uses:
The behaviour is like that: Spark uses Hl7.Fhir.Serialization.FhirSerializer that in turn uses Newtonsoft.Json serialization. By default Newtonsoft.Json serializes both decimal value 6 and 6.0 as 6.0.
That means that we lose a part of the precision specified above from Martijn.
The search functionality does not use the value serialized in the above form. This is why the search still behaves correctly :) (although that is not obvious). If you insert a resource with a value of 140, and afterwards you read it back it will have the value 140.0. But the search will still know that the actual value was 140, so it won't be returned if you search for 140.0.
So, this is not a search issue, but a "create"/"storage" issue and is not really a Spark issue, but a Hl7.Fhir issue. I will close this issue and add one in Hl7.Fhir.