ELEMENT with "name" and "value" attributes in ADL

Specifications ADL
1

Vital signs template includes “openEHR-EHR-OBSERVATION.pulse.v2.0.4.opt2” with ELEMENT definition that has two attributes: “name” and “value”.

ELEMENT has three optional attributes: “null_flavour”, “value”, “null_reason”.

ELEMENT[id1024] occurrences matches {0..*} matches {    -- Clinical interpretation
    name matches {
        DV_CODED_TEXT[id9015] occurrences matches {0..1} matches {
             defining_code matches {[ac9004]}    -- Clinical interpretation (synthesised)
        }
    }
    value matches {
        DV_TEXT[id9016] occurrences matches {0..1} 
    }
}

ac9004 can have two values:

  • at1059: Rhythm(en); Specific conclusion about the rhythm of the pulse or heartbeat, drawn from a combination of the heart rate, pattern and other characteristics observed on examination.
  • at1058: Clinical interpretation(en); Generic label to allow for any or all statements about the pulse or heart beat.

Shouldn’t the above ELEMENT be specified as:

ELEMENT[id1024] occurrences matches {0..*} matches {    -- Clinical interpretation
    value matches {
        DV_CODED_TEXT[id9015] occurrences matches {0..1} matches {
            defining_code matches {[ac9004]}    -- Clinical interpretation (synthesised)
        }
        DV_TEXT[id9016] occurrences matches {0..1} 
    }
}

Or am I missing something?

In case the second example is the solution:

ADL grammar/parser cannot catch ELEMENT with two attributes as error. Should the CKM catch it? Or the OPT validator?

2

The “name” is inherited from LOCATABLE.
The first part of the constraint above thus specifies a constraint on the name of the ELEMENT/LOCATABLE and one of the - in this case two - options is to be picked at runtime:

grafik
grafik758×204 10.3 KB

1 Like
3

Thank you Sebastian!

I missed the LOCATABLE.

I’m glad it is something I can fix in my code :blush:

1 Like