Missing "magnitude" for DV_QUANTITY constraint

NeoEHR · 31 January 2022 09:14

In “openEHR-EHR-EVALUATION.health_risk.v1.1.7.opt2” there is a DV_QUANTITY constraint without “magnitude” attribute which is a mandatory attribute for DV_QUANTITY:

ELEMENT[id4] occurrences matches {0..1} matches {    -- Risk assessment
    value matches {
        DV_TEXT[id9011] occurrences matches {0..1}
        DV_PROPORTION[id9012] occurrences matches {0..1}
        DV_QUANTITY[id9013] occurrences matches {0..1} matches {
            property matches {[at9001]}    -- Qualified real
            units matches {"1"}
        }
    }
}

Other templates with a missing “magnitude”:

“openEHR-EHR-OBSERVATION.energiebehoefte_eiwitbehoefte_volwassenen.v1.0.0.adls”:

ELEMENT[id85] occurrences matches {1} matches { – BMI
ELEMENT[id44] occurrences matches {0…1} matches { – Gemeten VVM
ELEMENT[id71] occurrences matches {0…1} matches { – Eiwitbehoefte
ELEMENT[id75] occurrences matches {0…1} matches { – Eiwitbehoefte
ELEMENT[id79] occurrences matches {0…1} matches { – Eiwitbehoefte

“openEHR-EHR-OBSERVATION.loopbandtest.v1.0.0.adls”:

ELEMENT[id6] occurrences matches {0…1} matches { – Functionele loopafstand in meters:
ELEMENT[id8] occurrences matches {1} matches { – Maximale loopafstand in meters:

“openEHR-EHR-OBSERVATION.lysholmscore_gemodificeerde_versie.v1.0.0.adls”:

ELEMENT[id66] occurrences matches {0…1} matches { – Totaalscore

“openEHR-EHR-OBSERVATION.neck_disability_index_ndi.v1.0.0.adls”:

ELEMENT[id97] occurrences matches {0…1} matches { – Totaalscore

“openEHR-EHR-OBSERVATION.verkorte_checklist_veilige_zorg.v1.0.0.adls”:

ELEMENT[id21] occurrences matches {0…1} matches { – Totaalscore Ondervoeding
ELEMENT[id36] occurrences matches {0…1} matches { – Totaalscore huidletsel
ELEMENT[id51] occurrences matches {0…1} matches { – Totaalscore incontinentie
ELEMENT[id66] occurrences matches {0…1} matches { – Totaalscore Medicatiefouten
ELEMENT[id83] occurrences matches {0…1} matches { – Totaalscore Vallen
ELEMENT[id98] occurrences matches {0…1} matches { – Totaalscore Depressie
ELEMENT[id115] occurrences matches {0…1} matches { – Totaalscore Mondproblemen
ELEMENT[id130] occurrences matches {0…1} matches { – Totaalscore Delier
ELEMENT[id142] occurrences matches {0…1} matches { – Totaalscore Oogproblemen
ELEMENT[id155] occurrences matches {0…1} matches { – Totaalscore Oorproblemen
ELEMENT[id168] occurrences matches {0…1} matches { – Totaalscore Pijn
ELEMENT[id179] occurrences matches {0…1} matches { – Totaalscore Eenzaamheid

Empty “magnitude”

In “openEHR-EHR-OBSERVATION.meet_en_weet_stuurgroep_ondervoeding.v1.0.0.adls” there is an empty “magnitude” attribute without a C_REAL constraint:

ELEMENT[id230] occurrences matches {0..1} matches {    -- Totaal vocht
    value matches {
        DV_QUANTITY[id231] matches {
            magnitude
            units matches {"ml"}
            precision matches {0}
        }
    }
}

CADL2 grammar allows such an attribute but what does it mean if there is no C_OBJECT for “magnitude”? It should be a C_REAL.
The “magnitude” attribute constraint is still not specified as required by the DV_QUANTITY.

How should this be handled? Is there an implicit default “magnitude” like magnitude matches {|>=0.0|}?

Can a CKM warn clinical modelers about the missing mandatory attributes?

Seref · 31 January 2022 11:48

I don’t think the fundamentals of how we do constraints changed in adl 2, so I’ll comment on that assumption. I’m also assuming you’re using adl 2, based on the opt file name extension you provided.

openEHR’s description of valid data is based on two levels: the RM (level 1), which is a fixed set of types (classes and I think we have an interface or two there), and archetypes, which are constraints on those types (level 2).

If you do not express any constraints on an RM type or its attributes, it means all data that is based on that RM type is valid data. In other words, if a property of a type is not mentioned in your archetype, it means any RM data with that property would be valid according to that archetype.

In your case, it is the magnitude of DV_QUANTITY. RM says that it is a real number, and every DV_QUANTITY instance should have this property set to a value. The only way you can constrain RM here is to say that the value is in an interval etc. Other than that, you cannot make magnitude optional, since an archetype can never remove an RM constraint. If you don’t introduce any constraints for that value, it means any REAL typed value goes here.

To see an example of this behaviour, get the blood pressure archetype from the global CKM, then use either the Ocean archetype editor, or Better’s tool (online) and modify the archetype so that sytsolic has no constraints for value, and diastolic has constraints. Here is what I did:

Then:

And look at the resulting adl (when you save the archetype):

No magnitude constraint for systolic!!!

Leaving aside adl version and tooling details etc, this should be what is going on mainly.

Someone should jump in and correct me in a minute if I’m not even getting the basics right anymore

pablo · 31 January 2022 11:55

Magnitude of mandatory in the RM not in AOM//TOM. No constraint for an attribute in the AOM means the value for that atribuye is not constrained, so any value is accepted.

NeoEHR · 31 January 2022 12:33

You are both correct. Thank you for reminding me that no constraint for an attribute in the AOM means the value for that attribute is not constrained (any value is accepted).

I clicked “Solved” next to Seref’s answer because he used screenshots

But Pablo’s answer achieved the same in much fewer words

Thank you both!

p.s.
I ended up adding “magnitude” as |infinity, infinity| since it is required in RM.

ian.mcnicoll · 31 January 2022 12:46

And just to confirm that this is a deliberate modelling pattern not an error. In this case we allow the use of a real number to carry an estimate of risk but at archetype level have no idea about any potential ranges on magnitude, so deliberately left unconstrained.

@NeoEHR -where are you adding your ‘infinity’ statement? Just curious!!

NeoEHR · 31 January 2022 13:33

The DV_QUANTITY is an alternative value for a single valued ELEMENT id4 (first post).

This is how the generated class for DV_QUANTITY[id9013] looks like:

These are the parameters names:

DvInterval(bool lowerUnbounded, bool upperUnbounded, bool lowerIncluded, bool upperIncluded)

…and this is DV_QUANTITY constrained with magnitude and units (tuples):

When I was writing this answer I noticed that the “units” are missing for DV_QUANTITY[id9013] (the first screenshot). I thought I had a bug in my code but the generator is much smarter than me - it knows there are no units in infinity, and didn’t add the unit “1” as specified in ADL

ian.mcnicoll · 31 January 2022 13:44

That is correct - sometimes we constrain to ‘1’ i.e any real number, in other cases, we simply have to leave units completely open and unconstrained e.g lab tests where the unit is supplied in the lab message.