Stream: implementers
Topic: FHIR values and numeric precision?
John Silva (Jan 20 2018 at 21:03):
What, if anything, does FHIR do or specify for numeric precision, e.g. in valueQuantity property of an Observation? JSON, in general, assumes arbitrary precision on it's numeric types. I know the Quantity data type talks about this but has anyone seen the necessity to have something to communicate the agreed-upon precision in FHIR so that end points can maintain the proper precision, e.g. when converting back and forth from JSON (or XML) to a database storage format?
Grahame Grieve (Jan 20 2018 at 21:04):
see discussion here: http://build.fhir.org/json.html#primitive
John Silva (Jan 20 2018 at 21:12):
Yes, I've seen that discussion before (and about using something like Java's BigNum library). However, that doesn't allow systems to specify, maybe in a profile, exactly what precision they support for specific types of measurements, maybe guided by the unit of measure. Clinicians will tell us that there are certain expected precision values for certain types of measurements (and typically it's tied to UofM); but FHIR doesn't seem to give us a way to communicate (or profile?) this concept. It doesn't seem like a 'one size fits all' approach works in all cases in healthcare.
Grahame Grieve (Jan 20 2018 at 21:15):
so all the systems I've seen so far, the precision is configured at the per-observation code level. In FHIR, that equates to a structure definition. You can specify the precision of the Observation.value using ...
Grahame Grieve (Jan 20 2018 at 21:15):
well, no you can't. Odd. I thought we had sorted that.
Grahame Grieve (Jan 20 2018 at 21:15):
nearest I can see is http://build.fhir.org/extension-maxdecimalplaces.html
John Silva (Jan 20 2018 at 21:21):
I just searched on OpenEHR and they have this as part of their DV_Quantity data type (and maybe others, I just looked at this one):
https://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_dv_quantity_class
I guess the bigger question is, are there use cases where this is important for FHIR exchanges? (Personally I think so, but I'm new to this but I've seen the importance of precision in other medical info systems.)
A related concept is accuracy; OpenEHR has this to say about precision and accuracy:
https://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_dimensioned_quantities
Grahame Grieve (Jan 20 2018 at 21:25):
the openEHR DV_Quantity is something different to what you are asking for. DV_Quantity has 2 fields: a floating point precision value, and a precision. The FHIR decimal conflates those into a single string representation. Specific exchange formats might differ (for instance, there's a group of us working on google protobuf format, and that probably will use a pair of floating point number and precision). But for JSON, after long discussion, we chose to use number directly, with that note I referred to above
Grahame Grieve (Jan 20 2018 at 21:26):
so the requirements are clear: for an individual number, precision is explicit and important. OTOH, specifying precision capability is still work in progress
Eric Haas (Jan 21 2018 at 01:27):
the 'observationdefinition' should IMO represent this.
John Silva (Jan 21 2018 at 23:16):
Thanks @Eric Haas -- it seems something as fundamental as numeric precision should be able to be specified; most clinical measurements have a specific precision and this is also important when performing calculations using these measurements as well.
Eric Haas (Jan 22 2018 at 02:51):
John Silva (Jan 22 2018 at 19:47):
@Eric Haas - is this a new property in R4? That's good if it is; didn't see this in STU3 (or couldn't find it if it's there)
Richard Townley-O'Neill (Jan 22 2018 at 22:40):
ObservationDefinition is a new resource in R4.
Richard Townley-O'Neill (Jan 22 2018 at 23:16):
http://build.fhir.org/observationdefinition.html
John Silva (Jan 23 2018 at 02:41):
OK, looked at this but not sure how to 'tie it' to the Observation resource. (an aside, there seems to be broken links on the ObservationUnit link)
Last updated: Apr 12 2022 at 19:14 UTC