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. 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 other words the safe and sensible use of the operators is always going
to be constrained by the circumstances of use, of which the use of SI units
or not, is only one factor that needs to be considered.
We need to solve the UCUM displayname/code issue anyway. We need to allow
different code systems e.g. SNOMED CT, we need to support dose units/ pack
units etc. Adding termcode and terminology solves that problem in a way
which prevents avoids change, avoids introducing another flavour of
quantity (more stuff for people to learn), and makes modelling of the key
area of medication much cleaner.
I would be really keen to hear from other openEHR implementers on this. If
operators are being heavily used and the suggested change would compromise
computability or ease of implementation, I could be otherwise persuaded.
Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll
Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL
On 18 May 2016 at 20:45, Thomas Beale <thomas.be...@openehr.org> wrote:
> Grahame,
>
> I think you are saying that you can implement the *semantics *of dose
> units with just a DvQantity / FHIR Quantity. If 'dose units' includes the
> knowledge of the discrete unit of delivery, i.e. table, drop etc, as well
> as total amount, you can't. You need at least the elements here, or their
> equivalent.
>
> class DoseQuantity
> unitForm: DvCodedText // type of physical dose entity tablet,
> capsule, puff etc
> unitAmount: DvQuantity // how much is in a `doseForm` unit e.g.
> 5mg
> doseCount: Integer // how many items of `doseForm` to
> deliver
>
> doseAmount: DvQuantity { // total amount of substance delivered
> to patient
> Result := doseCount * unitAmount
> }
> end
>
> If on the other hand you are saying we just go the pseudo-units route,
> where 'tablet' is a kind of unit, we can, but the Quantity library won't
> work properly anymore, because you no longer know if you can add two
> quantities even if they have the same unit, because 'tablet' as a unit
> doesn't mean anything. Where I am coming from is: Quantity is not just
> data, it is operations and computing
> <http://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_quantity_package>;
> it includes operators like:
>
> - DV_AMOUNT: =, +, -, *, etc
> - DV_ABSOLUTE_QUANTITY: diff, add, subtract
>
> (there are many ways to model this kind of thing, that's just the openEHR
> way).
>
> If you are saying: use a code + code-system approach, and check the code
> system, and do something if UCUM, and something else if not, I've now:
>
> - got just a data-oriented Quantity type
> - a bunch of if/else code to treat different Quantity 'types'
> differently
> - I have to move the operators out to another level, because they no
> longer make sense for this new style of Quantity
>
> So, in terms of what we do in openEHR, I don't think it makes sense. In
> terms of FHIR, it makes sense; but I have to check a FHIR Quantity and
> instantiate different kinds of RM structures depending on the units code
> system.
>
> - thomas
> On 18/05/2016 17:58, Grahame Grieve wrote:
>
> Hi
>
> You missed my point. I assume that the content model will differentiate
> between ucum code and some other code, so as to enable all the behaviour
> you describe.
> But you don't need to force the use of a different element in a different
> place of the model. Merely differentiating the terminology used will
> achieve that. A processor will know when it can use ucum based logic - not
> that I've ever seen that in the real world - and it will know when it can't
>
> Eric's part of this thread notes the issues with doing with this
> implicitly, so I'm not advocating for that, which brings you back to the
> FHIR model: human units, and system + code for computable units.
>
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
