On 19/05/2016 08:26, Ian McNicoll wrote:
Hi Thomas,
I appreciate that the Quantity classes add computability such as the
+,-,=, diff operators etc but computability (or at least safe/sensible
computability) is not a given even when the two operands share the
same unit.
it might not be clinically, but it always is in terms of quantities -
that's the whole point of the system of physical quantities. It's not up
to the DvQuantity (or any similar) type to know the clinical semantics
at hand; the way it has to work is that a higher level clinical context
in an application knows what Quantities are clinically comparable, when
it does, it's a /guarantee /that two DvQuantity instances of the same
unit (say 'g') are addable, subtractable and can be multiplied by a scalar.
This is the point of having a simple Quantity type in the system - just
to do this job.
Nor does the fact that a unit is non-scientific invalidate the use of
those operators in many cases e.g 1 tab + 1 tab = 2 tabs. Of course
there are situations where to do so would be unsafe and not sensible
but that also applies to cases where SI units are being used.
in this case you simply can't know, not even if you know that both
'tablet' quantities are for Aspirin. You have to at least know what the
tablet size is. This can be known, and the semantics can be known, but
not from a basic Quantity type; we need something more.
A very basic rule in IT and modelling is to build things additively,
using a new abstraction for each new complication. The alternative of
trying to jam all possible use cases into a single type or abstraction
always leads to something unwieldy, unclear and guaranteed to create
bugs in processing and data. That's the reason we don't try to make the
type 'Integer' do more than a simple integer can do.
Similarly, I would argue that the basic 'Quantity' type in a set of data
types for science / biomedical computing should just do its basic job -
representing quantities with units, accuracy, and precision. (We already
violate this somewhat in openEHR by including reference ranges, but at
least that remains perfectly computable.)
When we get to the scenario of quantities of drugs delivered in
quantised dose objects such as tablets etc, we are at another level of
sophistication. It doesn't make sense to change the Quantity data type
to do a more complicated job; if we do that, we have no Quantity type
that just implements standard scientific quantities.
Adding a new smart type, say DoseQuantity, is easy enough. Or else we
relegate the more complex information needed for drug information to
archetype data points as we do now. Trying to hack an existing type to
do a job it is not designed to do is a bad idea.
- thomas
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
