Remove DV_QUANTITY.property attribute in BMM files

[borut.jures]

The DV_QUANTITY.property was removed in Release 0.9 as part of “Remove property attribute from Quantity package” (Jira) but is still present in the BMM files.

It was removed from the current web specifications:

• RM/latest/data_types.html#_quantity_package
• RM/latest/data_types.html#_dv_quantity_class

It is in the terminology:

• TERM/latest/SupportTerminology.html#_property

---

I made a PR for specifications-ITS-BMM but I’m not authorized to push to this repository.

Proposed changes: search the BMM files in the repository for:

["property"] = (P_BMM_SINGLE_PROPERTY) <

and remove the attribute in ["DV_QUANTITY"].

[borut.jures]

There are archetypes published after 2004 that use DV_QUANTITY.property.

One of them is openEHR-EHR-OBSERVATION.blood_pressure.v2.

@sebastian.garde Is it possible that CKM is still using this attribute and modelers fill it in? If so, shouldn’t it be removed from the UI? The exporter should probably remove this attribute from the exported ADL to make them valid.

[sebastian.garde]

Hmmm - interesting topic.

See this discussion from 2022, which seems to be related.

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…

@pablo’s conclusion from there was:

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).

I certainly find this odd as well and not sure what to make of it, but a few comments from my end:

1. Even if not a physical attribute, its usage is certainly still backed for 1.4 archetypes via the definition of C_DV_QUANTITY from the archetype profile, see
   https://specifications.openehr.org/releases/1.0.1/architecture/am/openehr_archetype_profile.pdf
   So, I don’t think we should modify existing archetypes using this.
2. Archie also keeps it when converting an archetype from 1.4 to 2.x
3. @thomas.beale 's example from the discussion above contains property for adl2 as well: adl-archetypes/ADL2-reference/features/aom_structures/tuples/openEHR-EHR-CLUSTER.lab_analyte-triglycerides.v0.0.1.adls at master · openEHR/adl-archetypes · GitHub
4. It may not be useful within data, but for constraining a quantity to e.g. pressure (of any unit) it makes sense to have.
5. How this is currently backed in any way by the specs - beyond the archetype profile - I don’t understand.

[ian.mcnicoll]

@siljelb may havebetter insight on this topic.

From memory Better originally removed ‘property’ from AD to align with the specs but that proved to be difficult for modellers so they reintroduced it.

[borut.jures]

I’m fine if DV_QUANTITY.property is reintroduced (lets wait for @siljelb and maybe somebody from Better to comment on their experience with this). I’m just pointing out that without it being reintroduced, the archetypes are not valid.

Let’s keep this to ADL2. It doesn’t have C_DV_QUANTITY to complicate things (being somewhere between AM and RM). DV_QUANTITY is an RM data type.

I know it is easy for the existing vendors and modelers to remember what was needed to change to make openEHR production ready. However, we must be more thorough in documenting such decisions when it comes to the specifications.

• In this case the removal is documented.
• The reintroduction by Better was not documented. Is there a link to a discussion about why it was difficult for modelers? Was it ADL14 related or is the difficulty gone in ADL2?
• Keeping it in archetypes is just ignoring the issue of the removal which makes the archetypes invalid. Tooling hosted on openEHR.org domain must produce valid archetypes to avoid all the new openEHR users to avoid headaches in the future.

Maybe @thomas.beale will share his reasoning for not including DV_QUANTITY.property in the S2 model for Quantity and how the difficulties for modelers are resolved.

[siljelb (Silje Ljosland Bakke)]

Yeah, I’m not sure why we need to remove this? It’s almost certainly not relevant in the data, but it can be useful for at least two separate things:

• Facilitating selecting units in the modelling tool UI
• Explaining to people looking at the archetype what this thing is about, which isn’t always obvious, like here:
  
  

[borut.jures]

@siljelb

I’m not sure why we need to remove this?

It was removed in 2004. We need to discuss if it needs to be reintroduced into RM.

@siljelb

Facilitating selecting units in the modelling tool UI

Isn’t this solved with tuples:

value matches {
	DV_QUANTITY[id12] matches {
		[magnitude, units] matches {
			[{|0.0..1000.0|}, {"mg/dL"}],
			[{|0.0..20.0|}, {"mmol/L"}]
		}
	}
}

Or do you need to leave the units “open” at the archetype level? The above example could be further constrained in templates to include only one of the units (or whatever makes clinical sense).

If DV_QUANTITY.property is reintroduced, it introduces a two-level constraining pattern between two RM attributes. Would this be the only such usage?

TERM/latest/SupportTerminology.html#_property does not specify the units. This means they still have to be specified in the archetypes (as supported by AD) or we would need a mapping table for the property codes to the actual units codes (openEHR unit list).

There are posts here and here that point out that the openEHR unit list is a pain point.

Don’t we solve the issue with the openEHR unit list if we agree that DV_QUANTITY.property was removed 20+ years ago?

[sebastian.garde]

I agree with @siljelb that this is needed in archetypes for the reasons stated.

My view is that current CKM archetypes using the C_DV_QUANTITY profile to constrain DV_QUANTITY are valid as per the profile spec. It may be a bit odd and a stretch but I don’t think that it absolutely must be an exact match of an attribute in the RM for any archetype modelled upon this to be regarded as valid.

However, even if this view is agreeable, we still need a way forward for ADL2. That is assuming we are not missing anything here, @thomas.beale (asking you because the adl2 reference archetype mentioned has the property attribute)?

[siljelb (Silje Ljosland Bakke)]

@borut.jures

It was removed in 2004. We need to discuss if it needs to be reintroduced into RM.

That’s interesting, as I first started looking at openEHR in 2008, and “properties” has been available in tools when using DV_QUANTITY since then.

@borut.jures

@siljelb

Facilitating selecting units in the modelling tool UI

Isn’t this solved with tuples:

value matches {
	DV_QUANTITY[id12] matches {
		[magnitude, units] matches {
			[{|0.0..1000.0|}, {"mg/dL"}],
			[{|0.0..20.0|}, {"mmol/L"}]
		}
	}
}

Not sure? This is what we need to do:

But this doesn’t require persisting the property in the archetype, just that the units source file has properties.

But helping users understand what the unit is, does require persisting the property in the archetype, I think.

[borut.jures]

List of filtered units is a very important “nice to have” for the modelers but it is a tooling feature. It also means “openEHR units list” is not an openEHR maintained list, but a list of each tooling provider (tooling providers can still decide to maintain a common list).

Persisting the property in the archetype, makes everything dependent on the “openEHR units list”. Specifications don’t mention that implementations must in any way use DV_QUANTITY.property to restrict the list of valid units for a quantity data. This means it doesn’t make sense to leave the units unconstrained in the archetype. Once the units are constrained, DV_QUANTITY.property is redundant (it is still nice to have it in tooling).

@siljelb

But helping users understand what the unit is, does require persisting the property in the archetype, I think.

Are there archetypes with only DV_QUANTITY.property and without DV_QUANTITY.units?

---

There is a note about this: Data Types Information Model

while these semantics will allow comparison of e.g. two pressures recorded in mbar and mmHg, or even two accelerations whose units are `“m.s^-2” and “m/s^2”, they provide no guarantee that this is a sensible thing to do in terms of domain semantics: comparing a blood pressure to an atmospheric pressure for example may or may not make any sense. It is not within the scope of the quantity package to express such semantics - this is up to application software which uses Quantities found in specific places in the data.

---

I’m not against having DV_QUANTITY.property in the archetypes. We just have to add this property back to RM

p.s.
My tools support DV_QUANTITY.property so it is easiest for me if it is officially reintroduced to RM. The goal here is to decide what to do with it and make the specifications consistent with the decisions made.

[pablo (Pablo Pazos)]

Oh I remember this one.

IIRC I was doing compliance verification for ehrbase and checking the specs in detail at the same time.

I believe the idea of the property is to simplify archetype modeling tools and processes to constraint the units at the UI level, but not at the data level, since that attribute doesn’t even exists in the RM. Though for some reason, maybe it was a bug on the Archetype Editor, it was included in the ADL, or maybe it was used as a hint when opening the archetype again for editing, to still have the units constrained by property. Still, it’s not a real RM attribute and IMHO it’s one of those things that are borderline spec-valid (though nobody is discussing its usefulness).

Though this could be formalized in the specs besides being a common practice for years, if it’s formalized/specified, there is no need to remove anything.

[borut.jures]

@borut.jures

Once the units are constrained, DV_QUANTITY.property is redundant (it is still nice to have it in tooling).

Just an idea – tools could work without DV_QUANTITY.property in the archetypes:

• The current UI would remain the same. For new archetypes, the tool would offer a list of categories as shown in the image above.
• If the property is not saved in the archetype, and such an archetype is opened in the tool, the proper category would be determined from the constrained units in the archetype (based on the first unit is probably enough).

[ian.mcnicoll]

I think that is a perfectly reasonable proposition @borut.jures.

@borut.fabjan - do you have any thoughts on this - can we easily support ‘unit property’ in tooling, without it being recorded explicitly in archetypes?