At present it is not possible to use 'dose units' e.g 'tablets', 'drops' 'puffs' in DV_QUANTITY which makes it impossible to record medication amounts within a single element i.e needing an element for amount and one for 'units'.
This seems clumsy for a reference model attuned to clinical care where medication amounts are ubiquitous.
One solution might be to allow non-UCUM terms as 'units'.
My first impression is that this can be modeled in a CLUSTER instead of directly into the DV_QUANTITY, but I can think of a subclass of DV_QUANTITY specific for substance ordering/administration that contain the new attribute.
Looking at HL7 v2.5 Chapter 2, they have a CQ datatype with quantity NM and units CE (is a composite datatype created from 2 simpler dts, like a CLUSTER, but this is equivalent to our DV_QUANTITY). On Chapter 4, they have a complete segment to specify a pharmacy order (RXO), RXO-5: Request Dosage Form - This field indicates the manner in which the treatment is aggregated for dispensing, e.g., tablets, capsules suppositories. In some cases, this information is implied by the dispense/give code in RXO-1-requested give code or RXO-10-Requested dispense code. Required when both RXO-1-Requested give code and RXO-10-Requested dispense code do not specify the drug/treatment form. Optionally included otherwise.
I think that might be equivalent to what Ian proposes, but it is also a field on a segment, not in the DT that represents the quantity. So the CLUSTER solution doesn't looks so bad for me.
This was originally modelled as a CLUSTER archetype but this approach adds substantially to the complexity of medication models since dose amounts and quantities are used in many different places within the models and require us to archetype this information, rather than having it handled 'silently' by the reference model.
The drug 'form' is specified differently from 'dose units' e.g for an inhaler the form is 'inhaler' and the dose unit 'puff'.
If it is a problem of modeling than a problem of the RM itself, the extension way would be better than the change to DV_QUANTITY itself. Maybe directly to the RM, or via a profile model like we have on the AOM.
This was a recent email (July 13th 2018) to the SEC that generated a nice review of this topic. Just for the record:
Subject "Constraints of current DV_QUANTITY.units"
I'm playing around with FHIR resources and found that they use UCUM units but considered as a coded value, so it can use other terminologies for the units, or even use custom units.
On the other hand, seen some forced archetype modeling trying use the current units that we have on DV_QUANTITY that are UCUM only, adding some extra nodes to model custom units.
Basically, we are stuck with UCUM because DV_QUANTITY.units is String, not CODE_PHRASE.
I think that change would simplify modeling, and with modeling, will simplifying storing, querying, etc.
Personally I like the idea of being able to use other units when needed, and control the terminology used for the units.