Stream: Orders and Observation WG
Topic: GF#17520
Eric Haas (Sep 04 2018 at 01:45):
GF#17520 @Christine D
see http://build.fhir.org/extension-quantity-precision.html if that meets your needs will you be willling to withdraw this tracker?
Christine D (Sep 06 2018 at 13:08):
Hi @Angie Romano are we planning to derive the precision or would this extension be helpful? (the extension only represents the decimal portion, where we are looking for something like 5,3)
Angie Romano (Sep 06 2018 at 13:32):
We can determine the precision of a specific result, but I think what we would be looking for would be that all the results for the same test show in a uniform precision. so that is one A1C value was 5.4 and another was 5.55. If we have that the precision should be 2 then all the results would be displayed at 5.40 and 5.55 in this example. I will try out the extension on our test dataset.
Lloyd McKenzie (Sep 06 2018 at 14:33):
A system could choose to expose all data as having the same precision or enforce that all data is captured with the same precision, but fundamentally precision is a property of each record. Also note that precision is retained withint the value. So if you send 5.40, systems are expected to respect and remember that. @Eric Haas What's the actual use-case for the extension? I can see a need for sharing precision if you want to send a value like 5000 and say it has precision of 2. But based on the definition of the extension, you couldn't use it in that case.
Eric Haas (Sep 06 2018 at 15:22):
@Christine D What's the actual use-case for the extension? See lloyd's comment
Christine D (Sep 06 2018 at 18:59):
Central Labs align their data with the CDISC LAB data standard. Within that standard is a need to understand the precision at the lab. As noted above, sometimes zeros are lost in the transmission process, so it is important to understand the precision at collection. This is part of the CDISC LAB standard - numeric result precision. As Angela noted above, we may receive a 5.4 that should actually be represented as 5.40. The explicit numeric precision is useful in that situation.
Lloyd McKenzie (Sep 06 2018 at 20:21):
In a compliant FHIR system, zeros cannot be lost. In a non-compliant system, they're unlikely to support the extension, so you're not gaining much by adding the extension to the spec.
Eric Haas (Sep 06 2018 at 22:29):
It sounds like your concerns are already addressed by FHIR.
Grahame Grieve (Sep 06 2018 at 22:42):
there's already an extension. couldn't possibly add another
Angie Romano (Sep 07 2018 at 14:49):
@Christine D based on @Lloyd McKenzie's comments, do you want to use the extension or derive based on the result?
Christine D (Sep 07 2018 at 19:12):
@Angie Romano using the extension would get us part of the way, but there would still be some deriving. So maybe we just derive this one?
Last updated: Apr 12 2022 at 19:14 UTC
