# ELEMENT without value in ADL **Category:** [ADL](https://discourse.openehr.org/c/adl/40) **Created:** 2022-02-22 08:57 UTC **Views:** 618 **Replies:** 14 **URL:** https://discourse.openehr.org/t/element-without-value-in-adl/2386 --- ## Post #1 by @borut.jures 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 ``` --- ## Post #2 by @siljelb The type here is "any". :smile: --- ## Post #3 by @borut.jures Thank you! This is how "Any" looks like: ![any|690x112](upload://ax8hSHExcKbbbQin8pyAsMTi2YR.jpeg) 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: --- ## Post #4 by @siljelb My thinking has always been that the type would be constrained in the template, or at run time using some sort of business logic. --- ## Post #5 by @borut.jures 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. --- ## Post #6 by @thomas.beale [quote="siljelb, post:2, topic:2386, full:true"] The type here is “any”. :smile: [/quote] Here, 'any' means the 'any' of data types, which is technically the [class DATA_VALUE](https://specifications.openehr.org/releases/UML/latest/index.html#Diagrams___18_1_83e026d_1433773265129_527432_8703). Much less terrible than the real `Any` type ;) --- ## Post #7 by @borut.jures 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. --- ## Post #8 by @thomas.beale [quote="borut.jures, post:7, topic:2386"] That is 20 types x 20 in combination with DV_INTERVAL [/quote] DV_INTERVAL can only be used with DV_ORDERED types, so it's a bit less than that. [quote="borut.jures, post:7, topic:2386"] In practice I believe that “Analyte result” could limit some of the types and not leave it to the programmers to decide. [/quote] 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. --- ## Post #9 by @borut.jures Thank you for limiting the types. I've documented your "decision" in the code :innocent: ![Screenshot 2022-02-22 at 11.56.12|690x444](upload://5DBbn6V0axHgsHyTvBFdWpYugg5.png) 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. --- ## Post #10 by @thomas.beale BTW I have tried to convince the openEHR clinical modelling community that we should specialise the archetype [Laboratory Analyte Result (CLUSTER)](https://ckm.openehr.org/ckm/archetypes/1013.1.2881/mindmap) 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](http://www.clinicalelement.com/cimi-browser/#/) - look under 'laboratory test result' in the hierarchy view. So far I didn't manage to convince our clinical modellers ;) --- ## Post #11 by @thomas.beale I missed DV_ORDINAL - you'll need that. --- ## Post #12 by @borut.jures [quote="thomas.beale, post:10, topic:2386"] So far I didn’t manage to convince our clinical modellers :wink: [/quote] 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. --- ## Post #13 by @ian.mcnicoll 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 https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJDI5ODc1OTZlMjdhMTQ4N2FhZGFkNmNhYjg5NmJmY2E2 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|attachment](upload://8qTV1NnT7r3ot8duqyULYtNQgrl.opt) (562.8 KB) --- ## Post #14 by @borut.jures Thank you Ian for the PDF and the template. I hope the "Proposed new modelling approach" gets implemented :crossed_fingers: --- ## Post #15 by @ian.mcnicoll 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. --- **Canonical:** https://discourse.openehr.org/t/element-without-value-in-adl/2386 **Original content:** https://discourse.openehr.org/t/element-without-value-in-adl/2386