We are currently modelling archetypes for Swedish scores and ran into two problems of how the data type DV_ORDINAL is intended to work. Hopefully someone here are able to answer.
The first problem is how values in DV_ORDINAL is possible to specialize in a specialized archetype.
Let say that archetype A contain the DV_ORDINAL D and archetype B specialize archetype A. Assume also that the DV_ORDINAL D in archetype A contain the value 1 which is defined in the text as “>3 l/min”. Is it then possible to specialize the DV_ORDINAL D in archetype B so the value 1 in this archetype is defined in the text as “> 5 l/min”?
From an informatics point of view this is a pure refinement and is usually allowed as a specialization of something. However, the open EHR specifications and tooling doesn’t give a clear answer here.
The second problem is if a single value in a DV_ORDINAL can have more than one text (with an individual at code to each text) associated with the value. Unfortunately, it seems like the tooling do differently here.
This should be possible, as I understand it, both in ADL1 and 2 (Archetype Designer uses ADL2 under the hood). What tooling are you using?
However, although you are correct that the example is pure refinement, I do wonder about the real value of specialisation here (from a semantics perspective) when the 2 archetypes child and parent are considered as whole .
I faced a similar issue when trying to model the paediatric GCS. I started out be specialising but was not really sure in the end if that added value since ultimately the paeds GCS as a whole is very different from the adult version.
Tricky one but I’m not entirely sure that it will be viable to create a hierarchy of PEWS scores, or that it truly adds value - are these really interchangable? A similar example is TNM in cancer which is really just a very generic framework - every cancer-specific TNM is quite different and changes with each new edition.
This is an area to experiment with a little - I’m not sure there is a clear
I don’t really understand what you mean here? - can you give an example?
I don’t think this is a valid specialization from a purely tecnical point of view. “>3 l/min” is a string constraint to a fixed value. In a specialization you cannot change it to a different string. It is not a numeric range that can be constrained.
What could be done in the specialization is to remove that DV_ORDINAL (if it is optional) and create a new one with the new meaning, but this could raise other usage problems.
I didn’t see it that way @damoca - the question being asked is (I think!!) “Oxygen supply score” i.e what is the numeric score which represents the amount of oxygen being delivered. Now if there is an ’ Oxygen supply score’ in both parent and child, and the scoring is identical, lets say 0…1, the only difference is essentially the rule built into the text.
At that level, I think it could be argued that the specialised ‘ordinal’ is_a child, or certainly a sibling of the original. though I’m not sure that te cross-querying is safe or helpful!!
This doesn’t mean this is a good idea, and I have not thought my way through all the querying consequences. But it doesn’t break any ADL2 rules (or ADL1.4 rules).
@ian.mcnicoll, then we agree that this is a possible construction. I was primary using the Archetype Designer at the URL Archetype Designer . That tool locks the editing possibilities for specialized DV_ORDINAL, which is not the behavior I expected when I did the design.
My example with the refinement from “>3 l/min” to “> 5 l/min” was something I made up to in a simple way show the principle I was aiming for. My real use case is the Swedish PEWS archetypes but using them as examples would have been more complicated to explain my question. Instead, my plan is to do my modelling according to this pattern and send out those archetypes for commenting later this week.
@damoca, If this had been a question about the data type DV_TEXT’s value attribute and we have seen this from a strict software engineering point of view I had agree with you. However, from my informatics point of view I see the DV_ORDINAL as openEHR’s implementation of ordinal data, Ordinal data - Wikipedia . Therefore, I see the DV_ORDINAL’s symbol attribute as a description of the underlying concept the DV_ORDINAL’s value attribute represents. And from an informatics point of view this concept is possible to specialize with a refinement of this concept by replacing the concept with any of its descendants. This is basically what I do when I specialize from “>3 l/min” to “> 5 l/min”.
@thomas.beale , thank you for your example! This behavior is the behavior I expected.
I think it is time for me to write some ADL by hand in Notepad. It was long since the last time.
My second question was if it is correct to use two different texts (with two different at-codes) for the same value in an ordinal. Like what I have done in my example below where I have associated both “Normal” and “Common” to the value 1 in the Test_ordinal.
The constraint that there can only be one symbol per value has never been in the specifications as far as I know, but I think that some core implementations used to handle it that way and maybe some still do.
In any case, while tooling may be handling this differently, it is my understanding that having more than one symbol (code+text) for the same value is not forbidden by the specifications.
It was very hazy but until recently the ADL-parser code that underpinned theOcean Archetype Editor, issued an error if there were duplicate symbols and hinted at a formal specification rule but we could never find that documented in the specs.
@ian.mcnicoll Well. Betters tooling has provided me with some unexpected behaviors, so we are currently not best friends … But it is better than Notepad.
However, it still seems like the ADL Workbench doesn’t allow me to have two different symbols for the same value for an DV_ORDINAL. At least it complains with the error message
ERROR line 104 [last token = V_EXPANDED_VALUE_SET_DEF]: (VCOV) invalid ordinal constraint: duplicated value 3
On that error, that archetype would pass today - I think you must have an old copy of ADL WB (here is most recent - build 3060 - check what you have in Help>About on your current copy).
See this archetype for exmaple of same thing that was VCOV but now passes. I forget when we changed this, but this is the correct answer at a technical level. Whether it is semantically ‘right’ is always a question, but all tooling should allow it now.
I am using ADL Workbench v2.0.6.3063 and just got the error messages
WARNING (WCACA14) ADL 1.4 archetype - attribute 'items' in object node at path /: cardinality 1..* does not conform to cardinality 1..* in reference model
ERROR line 38 [last token = V_EXPANDED_VALUE_SET_DEF]: (VCOV) invalid ordinal constraint: duplicated value 3
When I loaded the archetype below (which is created entirely in Betters Archetype Designer).
archetype (adl_version=1.4; uid=0bb0685a-eee9-457c-b35c-e3dbdf4cbb3d)
openEHR-EHR-CLUSTER.test_ordinal.v0
concept
[at0000]
language
original_language = <[ISO_639-1::en]>
description
original_author = <
["date"] = <"2021-02-10">
>
lifecycle_state = <"unmanaged">
details = <
["en"] = <
language = <[ISO_639-1::en]>
>
>
other_details = <
["licence"] = <"This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/4.0/.">
["custodian_organisation"] = <"openEHR Foundation">
["original_namespace"] = <"org.openehr">
["original_publisher"] = <"openEHR Foundation">
["custodian_namespace"] = <"org.openehr">
["build_uid"] = <"537d1478-6ef5-3603-ac7a-b503c641738b">
>
definition
CLUSTER[at0000] matches { -- test_ordinal
items cardinality matches {1..*; unordered} matches {
ELEMENT[at0001] occurrences matches {0..1} matches { -- An ordinal
value matches {
1|[local::at0002],
2|[local::at0003],
3|[local::at0004],
3|[local::at0005]
}
}
}
}
ontology
term_definitions = <
["en"] = <
items = <
["at0000"] = <
text = <"test_ordinal">
description = <"test_ordinal">
>
["at0001"] = <
text = <"An ordinal">
description = <"">
>
["at0002"] = <
text = <"One">
description = <"">
>
["at0003"] = <
text = <"Two">
description = <"">
>
["at0004"] = <
text = <"Three">
description = <"">
>
["at0005"] = <
text = <"Three and some more">
description = <"">
>
>
>
>
Might be problem has been fixed for ADL 2, but not for 1.4?
This is the right result for ADL1.4, unless we back-port the change from ADL2. I am not 100% sure why ADL WB is doing this though, because it performs the ADL 1.4 → ADL2 conversion before doing most of the validation. Need to check…
That topic was about specialising DV_CODED_TEXT, but I’ve done some testing right now, and it looks like AD doesn’t allow changing any value set items from the specialised archetype in either DV_CODED_TEXT or DV_ORDINAL. It only allows adding new items, and not even constraining out value set items like you can in templates.
In my opinion, you should be allowed to change or constrain these out. Making sure you’re within a reasonable semantic refinement of the original item is your responsibility as a modeller.
While the issue of tooling and whether it is valid to specialise an ordinal, I’d also like to question whether it is valuable to specialise an ordinal, especially in PEWS or similar. Personally I think we should just create a practical and pragmatic CLUSTER for each age group.
Sometimes we tie ourselves in knots re semantic patterns and consistency when there is not a lot of value to our patient records or benefits to querying.
Just playing devil’s advocate here. I have been known on occasions to get lost in deep down rabbit holes (a la Alice in Wonderland). I have learned through experience if things get really convoluted, it’s often the universe sending me a message and a cue to step back and re-evaluate.
I have to agree - while specialisation is technically possible, here it doesn’t appear semantically quite right to me, and I think separated CLUSTERs by cohort type (age or whatever it might be) is also probably the right kind of thing to do.
I will be happy to change the modeling style after a review of the archetypes if it is most peoples opinion that another modelling approach would be better, but not on beforehand.
A general comment is that I probably come from a more ontological modelling style than I believe most openEHR modelers do. This might mean that I am more more found of specializing and less found of pragmatic things, because pragmatism tend to break the overall model when you have really many information artefacts in your system.
I’m definitely of the same mind. I have also been down similar rabbit holes around AVPU->ACVPU, GCS-> paeds GCS, and lately a horrendous bit of wrangling on sepsis-scoring archetypes, where the top-level ideas are broken down into the age-group of the patient and the clinical setting/person recording the score. e.g clinical vs. non-clinical, hosital vs. community etc etc. There is a bit of overlap and 'potential specialisaiton but it is very messy indeed.
For sepsis, we have done exactly as you suggested - a few top-level observations to carry the broad context, but using cluster archetype to maximise the 'potential shareability of some parts of the models - we will get them up onto the Aperrta CKM as an examplar.
