Choice of quantities?

Clinical (archive)
1

Hi,

We’re doing some work on the tobacco smoking archetype (yes, still), and one of the identified elements is the amount of tobacco smoked. Smoking tobacco comes in two main forms; cigarettes and loose tobacco for roll-your-own or pipe smoking. This means that the “Amount” element needs to take into account both the amount as a frequency (number of cigarettes per time unit), and a “flow rate” (gram per time unit). We’re trying to make this a choice element between a Quantity (frequency) and a Quantity (Flow rate), but the archetype editor doesn’t allow us to add more than one quantity to a choice. Is this a tooling issue or a specification issue? If this is disallowed in the specs, why? Are there any other (and better) ways of representing this?

Kind regards,
Silje Ljosland Bakke

Information Architect, RN

Coordinator, National Editorial Board for Archetypes
National ICT Norway

Tel. +47 40203298

Web: http://arketyper.no / Twitter: @arketyper_no

2

Hi Silje,

its a tool limitation. The Archetype Editor for some reason always represents DV_QUANTITY constraints as C_DV_QUANTITYs, but this is in fact needed only when there are alternate unit systems and ranges, e.g. a deg-C temp range and a deg-F temp range, and the property is the same i.e. ‘temperature’.

For all other situations it should just create normal DV_QUANTITY constraint structures. I

This can easily be done by hand, and has the following form

ELEMENT[at0003] matches { – smoking amount
value matches {
DV_QUANTITY[at0004] matches { – cigs/day
units matches {“/d”}
magnitude matches {|>=0.0|}
}
DV_QUANTITY[at0005] matches { – flow rate
units matches {“g/d”}
magnitude matches {|>=0.0|}
}
}
}

However, I don’t know if the tool will read this and save it correctly.

The other alternative is to use two separate ELEMENTs i.e.

ELEMENT[at0003] matches { – smoking amount cigs/day
value matches {
DV_QUANTITY matches {
units matches {“/d”}
magnitude matches {|>=0.0|}
}
}
}
ELEMENT[at0003] matches { – smoking amount g/day
value matches {
DV_QUANTITY matches {
units matches {“g/d”}
magnitude matches {|>=0.0|}
}
}
}

Here, you would not need any codes on the DV_QUANTITYs. I suspect this is the way that the CKM editors would advise to do it, and the Archetype Editor supports this.

ADL2 fixes all these problems :wink:

  • thomas
3

I believe that the issue here (and probably also related with the
bindings problem we were talking the other day) is related to the
impossibility of defining node identifiers to data type objects in the
archetype. In theory, they are alternatives from the same type, so
nothing wrong there when editing archetypes. The problem comes latter
on. I believe that ADL supports this (i.e. you can say that legally in
ADL), but as the reference model doesn't have a place to store that
identifier you wouldn't be able to distinguish between the two
alternatives in data, which in the end makes validation impossible.
I think your use case is no different than when we define a domain
type as a set of ordinals, which in the end are just dv_ordinal
alternatives

4

The second option is a bit situational, as it assumes you don't have
any more ELEMENTs as childs from "items" attribute. If you don't have
more alternatives then you can simulate the choice with the "items"
cardinality.