well, it's a question of where you keep your complexity and uncertainty. Sure, you can exclude the uncertainty from the data type, and retain clear and simple operations associated with the type. But that doesn't mean that uncertainty goes away. You've just pushed it somewhere else. I agree that the value proposition of putting in the data type is less clear for openEHR than it is for FHIR, but I don't think you've accounted for the operational costs of where you propose to put the complexity. I argue that you should just eat the complexity into DV_QUANTITY because: - that's where the real world users expect it to be - and so that's where it goes in any other syntax you'll ever encounter (well, at least FHIR and v2, and some CDA documents, but not all .e.g USA enforces valid UCUM, so I don't know what happens to customary units) - it doesn't change the operations, it just means that outcome of trying them might be undefined - but it might be already if the ucum units don't have matching dimensions. So - least cost is to put it into the data type
Grahame On Thu, May 19, 2016 at 5:45 AM, Thomas Beale <[email protected]> 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 > [email protected] > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- ----- http://www.healthintersections.com.au / [email protected] / +61 411 867 065
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
