ELEMENT without value in ADL

Specifications ADL
1

I cannot figure out how to interpret an empty ELEMENT declaration (last line below).

Which DATA_VALUE type is used for an ELEMENT without a “value matches”?

CLUSTER[id1] occurrences matches {0..*} matches {    -- Laboratory analyte result
    items cardinality matches {1..*; unordered} matches {
        ELEMENT[id28] occurrences matches {0..1} matches {    -- Analyte result sequence
            value matches {
                DV_COUNT[id9001] occurrences matches {0..1} 
            }
        }
        ELEMENT[id25] occurrences matches {0..1} matches {    -- Analyte name
            value matches {
                DV_TEXT[id9002] occurrences matches {0..1} 
            }
        }
        ELEMENT[id2] occurrences matches {0..*}     -- Analyte result
2

The type here is “any”. :smile:

2 Likes
3

Thank you!

This is how “Any” looks like:

any
any1920×312 64 KB

How is one supposed to implement “Any” in the UI? :thinking:

Technically it is easy - just present a user with a picker with all the possible data types.
I wouldn’t be a happy user with such an UX :unamused:

4

My thinking has always been that the type would be constrained in the template, or at run time using some sort of business logic.

1 Like
5

The example is from the “openEHR-EHR-CLUSTER.laboratory_test_analyte.v1.0.2.opt2” template found in “COVID-19 Pneumonia Diagnosis and Treatment - 7th edition”

In my experience there are many possible values and the modeler(s) don’t want to limit the field too much. So it is left for “later”. Usually it is not constrained in the templates and goes to use as “any”.

The decision is left to a programmer who probably doesn’t understand (or care) about the clinical meaning of the field. I suspect that many such fields are implemented as free-text leaving the querying/use problems for “later”. So it would be better to model it properly in the first place.

p.s.
In my case “a programmer” is a computer program generating the form. It can generate an “any” field in just a second and be done with it. But I believe it is wrong from a UX and clinical perspective.

6

Here, ‘any’ means the ‘any’ of data types, which is technically the class DATA_VALUE.

Much less terrible than the real Any type :wink:

2 Likes
7

Yes, I realized it is “only” DATA_VALUE types. That is 20 types + 20 in combination with DV_INTERVAL.

So a user would get a list of 40 options before entering any data? Is this how others implement it?

I’m curious because I have to implement this :blush:

p.s.
In practice I believe that “Analyte result” could limit some of the types and not leave it to the programmers to decide.
Some types on the DATA_VALUE diagram you linked to will obviously not be used.

8

DV_INTERVAL can only be used with DV_ORDERED types, so it’s a bit less than that.

Indeed - we know it is limited to:

  • the DV_QUANTIFIED types
  • DV_CODED_TEXT, maybe occasionally DV_TEXT
  • DV_BOOLEAN

This might help implementation wise.

9

Thank you for limiting the types. I’ve documented your “decision” in the code :innocent:

Screenshot 2022-02-22 at 11.56.12
Screenshot 2022-02-22 at 11.56.121442×928 133 KB

In practice my generator still doesn’t know that the empty ELEMENT types can be limited case-per-case.

I’ll probably list your most used types at the top and “hide” all the rest behind a “more…” button.

10

BTW I have tried to convince the openEHR clinical modelling community that we should specialise the archetype Laboratory Analyte Result (CLUSTER) on the data type of the Analyte Result field, as is done elsewhere, e.g. in the extensive Intermountain Healthcare Clinical Element Model (CEM) repository - look under ‘laboratory test result’ in the hierarchy view.

So far I didn’t manage to convince our clinical modellers :wink:

11

I missed DV_ORDINAL - you’ll need that.

12

Any time I (in the role of a modeler - not clinical - just a database modeler) left some field left to interpretation, it was interpreted incorrectly. I always blamed myself for not being precise enough.

13

So the rationale for modeling labs this way, is that most lab data is acquired through lab messages where it is often impossible to know in advance, exactly what datatype will be supplied or indeed units.

https://ckm.openehr.org/ckm/document?cid=1013.17.116

So this is message driven data capture, and essentially read-only, with the datatype being resolved at run-time, so you should be able to apply the correct

If the lab data is to be entered manually (quite common in registry-type projects) then I would create a template where everything was pre-constrained.

Example at Archetype Designer

We are working on adding SNOMED codes for all of the analyte names.

I’ve attached the .opt for you to play with if you want!! I’m sure @videhasharma will not mind!!

K Cloud Living Donor Assessment.opt (562.8 KB)

4 Likes
14

Thank you Ian for the PDF and the template.

I hope the “Proposed new modelling approach” gets implemented :crossed_fingers:

15

It has been implemented!!

Some progress has been made on microbiology archetypes, based on work done by Highmed but using the generic archetypes unconstrained for lab messaging, with the option of templating these locally for manual data entry is working well.

1 Like