# Remove DV_QUANTITY.property attribute in BMM files

**Category:** [BMM/Expressions](https://discourse.openehr.org/c/bmm-el/60)
**Created:** 2025-05-08 08:10 UTC
**Views:** 81
**Replies:** 12
**URL:** https://discourse.openehr.org/t/remove-dv-quantity-property-attribute-in-bmm-files/6779

---

## Post #1 by @borut.jures

The `DV_QUANTITY.property` was removed in Release 0.9 as part of "Remove property attribute from Quantity package" (https://openehr.atlassian.net/browse/SPEC-95) but is still present in the BMM files.

It was removed from the current web specifications:
- [RM/latest/data_types.html#_quantity_package](https://specifications.openehr.org/releases/RM/latest/data_types.html#_quantity_package) 
- [RM/latest/data_types.html#_dv_quantity_class](https://specifications.openehr.org/releases/RM/latest/data_types.html#_dv_quantity_class) 

It is in the terminology:
- [TERM/latest/SupportTerminology.html#_property](https://specifications.openehr.org/releases/TERM/latest/SupportTerminology.html#_property)

---
I made a PR for [specifications-ITS-BMM](https://github.com/openEHR/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"]`.

---

## Post #2 by @borut.jures

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

One of them is [openEHR-EHR-OBSERVATION.blood_pressure.v2](https://ckm.openehr.org/ckm/archetypes/1013.1.3574/adl).

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

---

## Post #3 by @sebastian.garde

Hmmm - interesting topic.

See this discussion from 2022, which seems to be related. 
https://discourse.openehr.org/t/general-modeling-question-for-dv-quantity-with-multiple-properties/2647/

@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: https://github.com/openEHR/adl-archetypes/blob/master/ADL2-reference/features/aom_structures/tuples/openEHR-EHR-CLUSTER.lab_analyte-triglycerides.v0.0.1.adls 
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.

---

## Post #4 by @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.

---

## Post #5 by @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.

---

## Post #6 by @siljelb

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: 
![image|402x144, 50%](upload://3TDJ0W6UGJBqyvBUU1add9xmMI1.png)

---

## Post #7 by @borut.jures

[quote="siljelb, post:6, topic:6779"]
I’m not sure why we need to remove this?
[/quote]

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

[quote="siljelb, post:6, topic:6779"]
Facilitating selecting units in the modelling tool UI
[/quote]

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](https://specifications.openehr.org/releases/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](https://discourse.openehr.org/t/units-with-dv-quantity/4297) and [here](https://discourse.openehr.org/t/adding-to-the-dv-quantity-units-options/1964) 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?

---

## Post #8 by @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)?

---

## Post #9 by @siljelb

[quote="borut.jures, post:7, topic:6779"]
It was removed in 2004. We need to discuss if it needs to be reintroduced into RM.
[/quote]

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.

[quote="borut.jures, post:7, topic:6779"]
[quote="siljelb, post:6, topic:6779"]
Facilitating selecting units in the modelling tool UI
[/quote]

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"}]
		}
	}
}
```
[/quote]
Not sure? This is what we need to do:
![2025-05-08_14-02-17|689x299, 75%](upload://g1wGvzoD3yhBqIZ4AjRrNQFBEZ4.gif)
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.

---

## Post #10 by @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).

[quote="siljelb, post:9, topic:6779"]
But helping users understand what the unit *is*, does require persisting the property in the archetype, I think.
[/quote]

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

---

There is a note about this: https://specifications.openehr.org/releases/RM/latest/data_types.html#_basic_semantics

> 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 :blush:

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.

---

## Post #11 by @pablo

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.

---

## Post #12 by @borut.jures

[quote="borut.jures, post:10, topic:6779"]
Once the units are constrained, `DV_QUANTITY.property` is redundant (it is still nice to have it in tooling).
[/quote]

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

---

## Post #13 by @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?

---


**Canonical:** https://discourse.openehr.org/t/remove-dv-quantity-property-attribute-in-bmm-files/6779
**Original content:** https://discourse.openehr.org/t/remove-dv-quantity-property-attribute-in-bmm-files/6779