General modeling question for DV_QUANTITY with multiple properties

I was creating some examples for my clinical modeling students, and one example that I wanted to create was to allow recording different units for different physical properties in the same DV_QUANTITY, then realized the Archetype Editor didn’t allow multiple “properties” in the same DV_QUANTITY.

Spec-wise, in general, without considering any specific use case, would it be possible to create such archetype / ADL?

I think it’s not possible if using the archetype_profile class C_DV_QUANTITY since it has only one field property, so multiple C_DV_QUANTITY objects would be needed to define the alternative properties, but that would also generate more node_ids, making the paths to each C_OBJECT different. Without using C_DV_QUANTITY and using just a C_COMPLEX_OBJECT I think it’s possible since the alternatives for the same path would be on C_ATTRIBUTE, though the Archetype Editor doesn’t support that alternative definition.

I believe this pattern of having a DV_QUANTITY constraint in AOM with multiple property values is not possible in the current AOM Profile model.

Though it made me think: even though we have AOM Profile classes, is it valid to use C_COMPLEX_OBJECTs to constraint DV_QUANTITY? Because modeling tools don’t seem to support both C_DV_QUANTITY and C_COMPLEX_OBJECT.

Thanks.

I think it’s a bit odd to want to do it, but it could be done in ADL2, which uses tuples for this kind of thing. You can see an example here.

The Quantity bit is:

value matches {
	DV_QUANTITY[id0.16] matches {
		property matches {[at0.0.1]}
		[magnitude, units] matches {
			[{|0.0..1000.0|}, {"mg/dL"}],
			[{|0.0..20.0|}, {"mmol/L"}]
		}
	}
}

This only varies on units and magnitude. Formally, a 3-tuple ca be formed with property as well.

However, I would think it is clearer to do it using alternatives for the different properties and then tuples for the units:

value matches {
	DV_QUANTITY[id0.16] matches {  
		property matches {[at0.0.1]}    -- concentration
		[magnitude, units] matches {
			[{|0.0..1000.0|}, {"mg/dL"}],
			[{|0.0..20.0|}, {"mmol/L"}]
		}
	}
	DV_QUANTITY[id0.17] matches {
		property matches {[at0.0.2]}    -- mass
		[magnitude, units] matches {
			[{|0.0..45.0|}, {"mg"}],
			[{|0.0..0.0015|}, {"oz"}]
		}
	}
}

Thanks @thomas.beale when I asked my first question I was thinking about a lab result archetype, when the numeric result could have many properties (concentration, volume, weight), or even a medication prescription where dosage could have also many different properties associated. IT seems by using the archetype profile C_DV_QUANTITY class in the archetype it is no possible to do that at the same node (have one path with many property units associated).

My second question is if it’s valid to constraint a DV_QUANTITY using a C_COMPLEX_OBJECT from the AOM instead of a C_DV_QUANTITY from the archetype profile. Would an editor supporting both be compliant with openEHR?

All modeling tools I tried use the profile classes and don’t have an alternative for C_COMPLEX_OBJECT when constraining DV_QUANTITY.

Thanks!

It is, even in ADL1.4, and should be done for simple constraints that don’t need C_DV_QUANTITY.

Definitely a tooling question. Might be interesting to manually edit an archetype to have a normal C_COMPLEX_OBJECT constraint, and read it into one of the tools and see what happens.

Great! I’m not sure this is clear to all modeling tool developers though.

One interesting thing about C_DV_QUANTITY is the property constraint is not actually a constraint over a RM attribute, but kind of a terminology set constraint over the DV_QUANTITY.units (I know UCUM is not exactly a terminology, I mean the property defines which possible units from the UCUM system could be used, then further constraining could be done at the units level, now that being a RM attribute).

Back to the initial question, then from what you mentioned, with C_COMPLEX_OBJECT it would be possible to define constraints for DV_QUANTITY.units without a property constraint.

@yampeku is it possible to constraint a DV_QUANTITY with C_COMPLEX_OBJECT instead of C_DV_QUANTITY by using LinkEHR?

I believe this will also affect CDR implementers! I need to build a test case for this in the Conformance Test Suites :slight_smile:

1 Like

Yes, we ended up adding domain types in the end, but the default usage was to be able to constraint rm types directly. For mapping we always need to get the standard equivalent for the domain types in order to choose the right alternative when doing mapping tables

It usually does so implicitly, but it is not necessarily the case. The original idea was that property on its own could be constrained (e.g. to ‘concentration’) without saying anything about units (i.e. use whatever concentration units your hospital / equipment uses).

See that example on Github I linked above, and imagine the property constraint is gone.

Did you implement tuples? With that, I don’t see any need for domain types.

That kind of breaks the normal way of constraining, because property is not a physical attribute in the RM but an implicit concept behind the units. I’m guessing that is why this pattern is actually defined in the Archetype Profile model and not in the AOM itself, because the AOM only works over physical/explicit attributes of the RM (declared in a RM class).

Interesting… never though about that.

1 Like