Stream: implementers
Topic: Adding a choice of valueInteger to Observation
Eric Haas (Jun 29 2017 at 20:23):
The Orders and Observation workgroup is considering the tracker - #13375 to add a choice of valueInteger to Observation resource. We are seeking feedback on this before voting on whether to approve this tracker. Specifically looking feedback on any negative consequences.
Lloyd McKenzie (Jun 29 2017 at 20:35):
The main negative consequence is that increases the likelihood that different implementers will uses a different data type to capture the same Observation value. There's already a (slight) likelihood of that now with CodeableConcept vs. boolean. But the risk is much higher with Quantity vs. integer. As an aside, Quantity allows you to display Quantity.unit which is often helpful for human interpretation. With integer, you're totally reliant on the Observation.code.coding.display or Observation.code.text which, in some cases, may not be totally clear. As far as I can tell, the only benefit of adding valueInteger is that you eliminate one layer of nesting - Observation.valueInteger as opposed to Observation.valueQuantity.value. I'm not sure the saving 7 characters is worth the complexity of supporting an additional type, deciding which observations should use Quantity vs. integer, loss of the expressive capability that Quantity provides around unit, and need for extra logic to handle both types when graphing or doing other numerical analysis.
Eric Haas (Jun 29 2017 at 21:24):
I don't understand how this is any different from having an Integer datatype and a count specialization on Quantity. Those same arguments would apply there but we have two choices....
Eric Haas (Jun 29 2017 at 21:30):
Also my expectation is that at my end of the spectrum - publshing the standard specification you would want to provide a broader level of support and optionality and as you move to the other end of the spectrum - the implemenation you would profile ( at least informally ) what you will use.
Lloyd McKenzie (Jun 29 2017 at 22:00):
The main difference is that we use the integer data type on elements that can't possibly be anything than an integer. To my knowledge, we've never supported a choice of integer|Quantity. With Observation, frequently values can be something other than an integer, so there's a need to have Quantity.
Lloyd McKenzie (Jun 29 2017 at 22:01):
With FHIR, we're not doing design-by-constraint. We provide necessary flexibility, but we try not to be more flexible than necessary. Variability is the enemy of interoperability, so we try to only support flexibility where it's necessary to support implementer capabilities. It's not clear how that could be the case here.
Eric Haas (Jun 29 2017 at 22:38):
I don't think we are jumping on 'the design by constraint' train - if you expect integer values you would expect to find valueInteger without having to read the spec.
Lloyd McKenzie (Jun 30 2017 at 03:53):
It adds complexity, it adds likelihood of non-interoperable variation, and it doesn't increase expressive functionality. If there's confusion, it can be addressed with a paragraph in the notes section. I don't see the benefit being worth the cost.
Richard Townley-O'Neill (Jun 30 2017 at 05:27):
A agree with Lloyd here, but we do need clear and obvious documentation about how to use valueQuantity for what valueInteger could do.
Sadiq Saleh (Jun 30 2017 at 17:13):
Based on UCUM specifications any string between a {} is actually a value of 1. Thus a value of {beats}/min is actually equivalent to {b}/min.
However as far as I can tell in FHIR, these are codes not equivalent as they are not an exact match.
Is it possible to aim for interoperability without also requiring the enforcement of UCUM rules as well?
And if the argument is to use a unit of 1 for all counts (rather than the {}), then does this not take away from the human readability?
Lloyd McKenzie (Jun 30 2017 at 20:02):
The codes are definitely not equivalent. So a value set expecting "{beats}/min" would not match on "1/min" even though both codes correspond to the same UCUM concept. (In much the same way as a value sets that includes a pre-coordinated SNOMED concept wouldn't accept the post-coordinated variant.)
Grahame Grieve (Jun 30 2017 at 20:18):
Lloyd: define equivalent in that sentence. Because I think they are equivalent, thought they are not the smae
Lloyd McKenzie (Jun 30 2017 at 20:33):
Equivalent means "not equal from a string perspective", which is what matters if you're dealing with an enumerated value set. (You're fine if you're using a subsumption based value set - something like "all UCUM codes that express distance".)
Lloyd McKenzie (Jun 30 2017 at 20:34):
But with an enumerated value set, if the enumeration contains "1/min" and doesn't contain "{beats}/min", only the former would be a legal value in the instance - regardless of the fact that the meaning of the two is the same.
Eric Haas (Jun 30 2017 at 22:43):
The are 2 timely issues on this stream:
- Mine - the original one which is the tracker we, OO are considering. of which my concern about having to read the damn specification in order to express valueInteger has not been addressed to my satisfaction - is that a barrier to adoption or at least an unnecessary hurdle for implementers. ( It was the same with valueBoolean - after the 3 separate tracker requesting it - OO gave in and added it ....either nobody bothered read the notes on how to handle it or did not agree with it )
- Sadiq's - UCUM issue which is timely because we need to say more about Quantity vis a vis UCUM. I think in this stream Lloyd summarizes this issue very well and namely the fact that UCUM provides a human readable {[whatever-you-are-counting]} and the Quantity.unit do very similar things. i.e., provide a way to display the units to the end user. putting the
{}stuff in Quantity.code may be problematic for systems. OO has a tracker on that and will probably punt to MNM or Vocab to say more on this particular topic in a more general way.
Lloyd McKenzie (Jun 30 2017 at 23:48):
Why is it a problem to have to read the specification to figure out how to express valueInteger? I think setting that as an expectation to avoid interoperability issues is a reasonable tradeoff...
Mark Kramer (Jul 13 2017 at 13:55):
I support adding valueInteger to Observation. There are lots of observations whose values are fundamentally and always integers. How many people in your household? On a scale of 1-5 how would you rate your satisfaction? What is the Mitotic Count Score (1, 2 or 3)? I don't believe the issue is referencing the value, it is roundoff error in representing an integer value as a decimal. Is 1.0000000000000001 (the nearest decimal to 1 in one system) equal to 0.9999999999999 (the nearest decimal to 1 in a different system) equal? This is basic to every computer language. It's nutty that FHIR Observations do not support integers.
Richard Townley-O'Neill (Jul 14 2017 at 05:26):
"How many people in your household?" should get an answer of "x people". Just as "How tall are you (in centimetres)?" should get an answer of "x cm."
Stefan Lang (Jul 14 2017 at 07:44):
Whether scores and ratings are numeric or rather codes (thus CodeableConcepts in FHIR) is one of the discussions that will probably never settle. Despite the fact that scores are often calculated by adding up subscores, many systems are treating them as codes. But even if you treat them as numeric, it should be "x score points" or "x rating points" rather than "x".
I also think that the mentioned precision issues should be handled on the implementation side (something that is also within the capability of every computer language). If you store/send "1.0000000000000001" within a decimal element, that should mean exactly "1.0000000000000001" and not "1 +/-0000000000000001". If you want to have "1" and you know that your calculation result has only 3 significant figures, ensure to round properly.
The FHIR spec is quite clear on how to handle the precision of decimals, up to the required ability to keep trailing zeros.
Stefan Lang (Jul 14 2017 at 07:47):
So, tl;dr: I don't see increased functionality by adding integer, but I would see increased confusion and decreased interoperability, as Lloyd pointed out.
Grahame Grieve (Jul 21 2017 at 12:32):
I'm not seeing us circling towards resolution on this issue. It seems to me that the issues are relatively clear, and people differ on values. Mu summary is that adding valueInteger is clearer for newbies encountering the spec who have what looks like an integer, and aren't used to the ucum code tricks that insiders know all about, and also allows newbies to defer the precision issue (though I agree with Stefan). But adding it means that there'll always be the question for ever with regard to having to look for either valueInteger, or a valueQuantity with a UCUM code - and many people will get caught out by that
Grahame Grieve (Jul 21 2017 at 12:33):
e.g. it's a classic reader vs writer thing
Lloyd McKenzie (Jul 21 2017 at 14:14):
In my opinion, the newbie issue can be minimized with some clear documentation and a couple of examples
Brian Postlethwaite (Jul 26 2017 at 05:45):
+1 to using valueQuantity so that you get the units.
Eric Haas (Jul 26 2017 at 23:28):
The issue is now closed OO voted in favor.
Last updated: Apr 12 2022 at 19:14 UTC
