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
