# Modelling and behavior of of the data type DV_ORDINAL **Category:** [Specifications](https://discourse.openehr.org/c/specifications/6) **Created:** 2021-02-05 14:59 UTC **Views:** 2138 **Replies:** 42 **URL:** https://discourse.openehr.org/t/modelling-and-behavior-of-of-the-data-type-dv-ordinal/1271 --- ## Post #1 by @mikael Hi, 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. Regards Mikael --- ## Post #2 by @ian.mcnicoll Hi Mikael, [quote="mikael, post:1, topic:1271"] 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”? [/quote] 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 [quote="mikael, post:1, topic:1271"] 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. [/quote] I don't really understand what you mean here? - can you give an example? --- ## Post #3 by @damoca [quote="mikael, post:1, topic:1271"] 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”? [/quote] 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. --- ## Post #4 by @ian.mcnicoll [quote="damoca, post:3, topic:1271"] 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. [/quote] 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!! --- ## Post #5 by @thomas.beale Works in the ADL Workbench... parent on the left, child on the right. ![dv_ordinal_specialised|690x151](upload://iyT7iAUz95cb6bzsvSZWHviBFQl.png) Parent: ``` archetype (adl_version=2.0.6; rm_release=1.0.2) openehr-TEST_PKG-SOME_TYPE.dv_ordinal_refinement.v1.0.0 language original_language = <[ISO_639-1::en]> description original_author = < ["name"] = <"Thomas Beale"> > details = < ["en"] = < language = <[ISO_639-1::en]> purpose = <"Example to show refinement of a DV_ORDINAL."> > > definition SOME_TYPE[id1] matches { -- root item standard_ordinal_attr matches { DV_ORDINAL[id6] matches { -- ordinal 2 value matches {1} symbol matches { DV_CODED_TEXT[id9] matches { defining_code matches {[at3]} } } } } clinical_ordinal_attr_1 matches { DV_ORDINAL[id11] matches { [value, symbol] matches { [{1}, {[at3]}] } } } } terminology term_definitions = < ["en"] = < ["id1"] = < text = <"root item"> description = <"xxxx"> > ["id6"] = < text = <"ordinal 2"> description = <"ordinal 2"> > ["at3"] = < text = <">3 L/min"> description = <">3 L/min flow-rate"> > > > ``` Child: ``` archetype (adl_version=2.0.6; rm_release=1.0.2) openehr-TEST_PKG-SOME_TYPE.dv_ordinal_child.v1.0.0 specialize openehr-TEST_PKG-SOME_TYPE.dv_ordinal_refinement.v1 language original_language = <[ISO_639-1::en]> description original_author = < ["name"] = <"Thomas Beale"> > details = < ["en"] = < language = <[ISO_639-1::en]> purpose = <"Example to show refinement of a DV_ORDINAL - child."> > > definition SOME_TYPE[id1.1] matches { -- root item - specialised standard_ordinal_attr matches { DV_ORDINAL[id6.1] matches { -- ordinal 2 - refined value matches {1} symbol matches { DV_CODED_TEXT[id9.1] matches { defining_code matches {[at3.1]} } } } } clinical_ordinal_attr_1 matches { DV_ORDINAL[id11.1] matches { [value, symbol] matches { [{1}, {[at3.1]}] } } } } terminology term_definitions = < ["en"] = < ["id1.1"] = < text = <"root item - specialised"> description = <"xxxx"> > ["id6.1"] = < text = <"ordinal 2 - refined"> description = <"ordinal 2 - refined"> > ["at3.1"] = < text = <">5 L/min"> description = <">5 L/min flow-rate"> > > > ``` 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). --- ## Post #6 by @mikael Hi, Thank you for your responses! @ian.mcnicoll, then we agree that this is a possible construction. I was primary using the Archetype Designer at the URL https://tools.openehr.org/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, https://en.wikipedia.org/wiki/Ordinal_data . 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. :-) Regards Mikael --- ## Post #7 by @mikael Hi again @ian.mcnicoll, 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. Regards Mikael definition CLUSTER[at0000] matches { -- test items cardinality matches {1..*; unordered} matches { ELEMENT[at0001] occurrences matches {0..1} matches { -- Test_ordinal value matches { 1|[local::at0002], 1|[local::at0003] } } } } ontology term_definitions = < ["en"] = < items = < ["at0000"] = < text = <"test"> description = <"test"> > ["at0001"] = < text = <"Test_ordinal"> description = <""> > ["at0002"] = < text = <"Normal"> description = <""> > ["at0003"] = < text = <"Common"> description = <""> > > > > --- ## Post #8 by @sebastian.garde Hi @mikael 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. Regards, Sebastian --- ## Post #9 by @ian.mcnicoll 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. I think Better just copied this behaviour initially, but the current AD build allows duplicate symbols - the NEWS2 archetype is an example. https://ckm.openehr.org/ckm/archetypes/1013.1.3342 So @michael - you should be able to do what you need in Archetype Designer. --- ## Post #10 by @mikael @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` For the ADL code ELEMENT[at0.13.1] occurrences matches {0..1} matches { -- Andningsfrekvens value matches { 0|[local::at0.14.1], 1|[local::at0.15.1], 2|[local::at0.16.1], 3|[local::at0.17.1], 3|[local::at0.17.2] } } Do maybe @thomas.beale know more about it? --- ## Post #11 by @thomas.beale [quote="mikael, post:10, topic:1271"] @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. [/quote] Well, if there is a problem, always report it [here on the Discourse AD support group](https://discourse.openehr.org/c/tool-support/archetype-designer/30). 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](https://www.openehr.org/download_files/adl_workbench/adl_workbench_2.0.6-windows_64bit.exe) - check what you have in Help>About on your current copy). See [this archetype for exmaple](https://github.com/openEHR/adl-archetypes/blob/master/ADL2-reference/validity/domain_types/openEHR-TEST_PKG-ENTRY.VCOV_value_duplicated_in_ordinal.v1.0.0.adls) 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. --- ## Post #12 by @mikael Hi @thomas.beale , 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? Regards Mikael --- ## Post #13 by @thomas.beale 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... --- ## Post #14 by @mikael Ok. In that case, it is Betters Archetype Designer that doesn't follow the ADL1.4 specification. --- ## Post #15 by @siljelb Hi Mikael! I suspect you may be looking for the functionality I was asking for in this topic: https://discourse.openehr.org/t/specialising-value-set-items/970 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. --- ## Post #16 by @mikael Hi @siljelb, Yes it seems to be the same issue with both the DV_CODED_TEXT and DV_ORDINAL, so I think that we agree. :slight_smile: Regards Mikael --- ## Post #17 by @heather.leslie [quote="ian.mcnicoll, post:2, topic:1271"] 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 . [/quote] 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. Cheers Heather --- ## Post #18 by @thomas.beale [quote="heather.leslie, post:17, topic:1271"] 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. [/quote] 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. --- ## Post #19 by @mikael 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. --- ## Post #20 by @ian.mcnicoll Thanks @heather.leslie, 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. https://sepsistrust.org/professional-resources/clinical/ and the template with the various sepsis archetypes https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJDU2ODk4NzkwNDU3NjQ0NTliMTgwNzMxZDU1Y2ZmN2Ux 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. --- ## Post #21 by @ian.mcnicoll Hi @mikael, You are not wrong to start with at 'ontological' perspective. I would hope I do the same (though with less experience), and we definitely did a lot more of that in the past. However, with experience, I think we are recognising that in the 'medical record space' there are a lot of pseudo-inheritance type relationships. TNM is a great example. What seems like a 'standard'. probably started as something that had a few fixed stages that seemed universal across all cancers but has evolved into a very complex set of models that have virtually no real commonality other than the labels T, N,M. The valuesets are different, the modifiers are different, the rules are different for every cancer, and change again with every edition. And ultimately what is the real-world cross-queryability of lung cancer T1N2M4 vs. breast cancer T1N2M4? Thee may well be some biomedical ontological relationships than can be inferred, and that is where SNOMED should add value but is often a really awkward fit, in these kind of models. --- ## Post #22 by @ian.mcnicoll @mikael and everyone lurking!! I'd also meant to say that I think we *all* still wrestle with optimising these patterns. I don't think any of us who have been doing this for a while would be confident to say 'you are doing it wrong' - more 'we feel your pain but here's the journey we went on and where we ended up'. I'm not sure if it is privilege or a curse to be exposed to so many information patterns. It is the power of the openEHR approach that makes it applicable to so many different areas of clinical records - we are trying to boil the ocean, just one cup at a time. And all of this 'wrangling' is already happening in traditional non-openEHR systems around the world.. again ,and again, and again. At least we are sharing the cost, the experience and hopefully building the standardisation pot. There is joy .... eventually.. --- ## Post #23 by @thomas.beale [quote="mikael, post:19, topic:1271"] 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. [/quote] I am very sympathetic to that view for the same reasons, so don't abandon it with archetypes! I just think this particular case is borderline... --- ## Post #24 by @thomas.beale [quote="ian.mcnicoll, post:21, topic:1271"] TNM is a great example. What seems like a ‘standard’. probably started as something that had a few fixed stages that seemed universal across all cancers but has evolved into a very complex set of models that have virtually no real commonality other than the labels T, N,M. The valuesets are different, the modifiers are different, the rules are different for every cancer, and change again with every edition. [/quote] For @mikael and other ontologists, you will recognise these custom systems as often being fiat categories / boundaries, created by great docs who don't even know what ontology is, so they don't think about subsumption relationships of a term (say, some particular TNM value) down through sub-populations (e.g. re-applied to different kinds of cancer with different mechanisms) - and the correspondence of terms to reality doesn't come out that clean. Some of the scales from adult to children, or with relation to sex or race etc are not ontologically entirely sound. This is not really to criticise such docs - I doubt that even today there is a single mention within medical school of the potential problems of sub-optimally designed scores/scales/classifications causing real downstream problems in clinical information systems later on... really we should start teaching ontology in primary school or early secondary school (and for fun, here is the book to do it with: [The Art of Reasoning](https://www.amazon.co.uk/Art-Reasoning-Introduction-Logic/dp/0393421716)). So, in some sense, we who come along with our keen sense of Aristotelian classification, are mopping up after some eggs have been dropped ;) --- ## Post #25 by @mikael I can agree on many things you say. However, this time the Swedish version of PEWS is a better candidate for using specialization in the modeling than in many other scores. I am more than happy to discuss all details of the modelling when I have finalized the modelling and published the first drafts of the archetypes. However, I haven't had time to solve the incompatibilities between Better's Archetype Editor and the Swedish incubator in CKM yet, so I am not able to share the archetypes yet. (In my everyday working environment in Sweden it is very rude to criticize a colleague's idea before the colleague has had a fair chance to present the entire idea. I must therefore say that I am very surprised about some of the comments above.) --- ## Post #26 by @ian.mcnicoll Hi Mikael, You should be able to share a link from Archetype Designer that would let us have a look, in advance of the CKM issue being resolved. Use the share button to the left of the archetype Id. You many know this , of course, so this is also for those lurking!! ![image|411x57](upload://wP1LDakg0wB9iD7gjoJMQVBRyuz.png) As one of those commenting, and perhaps being seen to be criticising, for me at least , that was not all my intent. I was just merely reflecting my experience of very similar issues. I don't think any of us would claim that we are doing this 'absolutely right' or that others are 'doing it wrong'. So apologies on my part if any criticism was felt, it was definitely not intended, and I'm looking forward to seeing your approach. --- ## Post #27 by @mikael Hi Ian, I have now posted the archetypes and the considerations in the post [Modelling of Swe-PEWS - Clinical - openEHR](https://discourse.openehr.org/t/modelling-of-swe-pews/1294). Regards Mikael --- ## Post #28 by @borut.fabjan [quote="mikael, post:14, topic:1271, full:true"] Ok. In that case, it is Betters Archetype Designer that doesn’t follow the ADL1.4 specification. [/quote] I guess It's an overstatement saying Archetype Designer doesn't follow ADL1.4 specification. It's just strict when it comes to specialization - prevents changes, which break specialization (parent-child) relationship. In Archetype Editor this was quite relaxed which further lead to inconsistencies. --- ## Post #29 by @mikael I more and more think that this is something we really need to bring up to a proper discussion because there are many opinions, but I am unable to really find anything in the specifications. Do you have any suggestions @borut.fabjan ? Might it only be that informaticians/ontologists have one view and software engineers another? For me, as an informatician, I simply see the value attribute in the DV_ORDINAL as a representation of a concept. The meaning of the concept is explained by the text in the symbol attribute. When I specialize the DV_ORDINAL, one of the options is also to specialize the concept that is represented by the value. This is done by changing the text in the symbol attribute to explain the specialised meaning of the concept. This kind of specialization isn’t stranger than I in SNOMED CT can specialize the concept `117590005 |Ear structure (body structure)|` by adding the refinement `272741003 |Laterality (attribute)| = 7771000 |Left (qualifier value)|` into the expression `117590005 |Ear structure (body structure)| : 272741003 |Laterality (attribute)| = 7771000 |Left (qualifier value)|` which means “left ear”. This corresponds to changing the symbol in the DV_ORDINAL from “Ear structure” to “Left ear structure”. This approach might provide one more possible way of incorrect modelling, but I assume that these modelling errors are found and corrected in the usual reviews or in the ontology binding regression tests. (We have discussed specialisations of DV_ORDINALs in our Swedish openEHR meetings where among others @erik.sundvall , @Asa_Skagerhult , @martin.grundberg and @stoffe have participated and it seems like we all understand the specifications in the above described way.) --- ## Post #30 by @heather.leslie Hi Mikkel, I think we need to be careful here. There are well specified logic rules that support the specialisation of 'ear' to 'left ear'. But this is an extremely unlikely use case for content of an ordinal. The ordinal will be used for scores and scales where the value associated with the text will be used as a count (towards a score) or to graph change in the values over time. In the PEWS example, for specialisation we need to identify a parent model and each of the age groups have equal semantic weight - there is no clear parent or source of original truth on which to specialise. And I am not convinced of the validity of specialising ordinal text values - for example Pulse frequency for score 1 for 16-18yo is a dual range of 41-50 **and** 91-110, yet for other ages it is a single range of 111-124, 121-134 , 131-144, 166-179 etc. This sequence or relationship makes no sense to me as a logical, semantic specialisation. And is nothing like the clear 'ear' to 'left ear' relationship. IMO it is much cleaner and clearer to model as separate, age-specific archetypes that have common content in many data elements and different content in others. Kind regards Heather --- ## Post #31 by @ian.mcnicoll Hi Mikael, There is certainly active debate about ADL2 specialisation of CodedTexts which is basically the same issue. 1. Specialisation: Currently AOM2 allows for specialisation of terms within a valueset but only if these 'inherit' from an existing code in the Valueset. On that basis, I think AD should allow you to do what you want, both for CodedText, Ordinals and upcoming Sclae datartypes. @borut.fabjan - why do you think this is currently disallowed? in a set [red, yellow ,green] we can add light-red 2. A few of us (mostly modellers!!) argued that we should also be allowed to extend the valueset in a specialised archetype (or template) as long as the new term logically belongs to the same 'set'. in a set [red, yellow ,green] we can add black This is actually a much more common requirement, where a local community wants or needs to add some extra terms to an otherwise agreed set. This was hotly debated and the compromise was reached that this was allowable, as long as the Valueset binding strength was not set to 'required' . @borut.fabjan - this is relevant to AD!! 3. Finally there is that 'modelling' discussion about where and when to assert inheritance, and although it is a tricky area, I agree with @heather.leslie above that the kind of inheritance you are proposing is not as helpful as it might first seem and can actually be misleading. I have tried exactly the same kind of specialisation in the past GCS->paediatric GCS and I now think it is the wrong approach. The kind of ontological truth that can be asserted around biomedical facts such as body-site often does not transfer well to what are essentially record artefacts - derivations of the biomedical data but heavily contextualised. So to sum-up. We definitely need to be able to extend (or perhaps replace) valuesets in specialisations, and we sometimes need to be able to create pure specialisations from parent terms. Whether it is helpful to do so, is a different argument! The nice thing about openEHR is that it allows for this kind of variation. We are all still discovering the optimal patterns as we encounter the challenges thrown by existing clinical records. Heather and I might not agree with specialising the Ordinal in this case (based on our prior experience of trying to do something similar) but your archetypes will work perfectly well from a technical POV. --- ## Post #32 by @thomas.beale [quote="ian.mcnicoll, post:31, topic:1271"] The kind of ontological truth that can be asserted around biomedical facts such as body-site often does not transfer well to what are essentially record artefacts - derivations of the biomedical data but heavily contextualised [/quote] This is a key point. I happen to be in favour of more specialisation in general in archetypes to allow better re-use - e.g. examination CLUSTERs ... but always observing this principle - i.e. the specialisation has to be understood as being between epistemic (record) entities, not (generally speaking) ontological entities, as in terminology. --- ## Post #33 by @borut.fabjan [quote="ian.mcnicoll, post:31, topic:1271"] Hi Mikael, There is certainly active debate about ADL2 specialisation of CodedTexts which is basically the same issue. 1. Specialisation: Currently AOM2 allows for specialisation of terms within a valueset but only if these ‘inherit’ from an existing code in the Valueset. On that basis, I think AD should allow you to do what you want, both for CodedText, Ordinals and upcoming Sclae datartypes. @borut.fabjan - why do you think this is currently disallowed? in a set [red, yellow ,green] we can add light-red 2. A few of us (mostly modellers!!) argued that we should also be allowed to extend the valueset in a specialised archetype (or template) as long as the new term logically belongs to the same ‘set’. in a set [red, yellow ,green] we can add black This is actually a much more common requirement, where a local community wants or needs to add some extra terms to an otherwise agreed set. This was hotly debated and the compromise was reached that this was allowable, as long as the Valueset binding strength was not set to ‘required’ . @borut.fabjan - this is relevant to AD!! [/quote] All above (point 1,2) In terms of DV_ORDINAL is supported in AD. See screenshot: ![Screenshot 2021-03-10 at 08.26.19|690x276](upload://etZI14iyzokgM73Gmyl16M1nPky.png) What is **not allowed** when specialising is to modify inherited (parent) items. For example, turning item red into light-red or black. --- ## Post #34 by @borut.fabjan [quote="mikael, post:29, topic:1271"] I more and more think that this is something we really need to bring up to a proper discussion because there are many opinions, but I am unable to really find anything in the specifications. Do you have any suggestions @borut.fabjan ? Might it only be that informaticians/ontologists have one view and software engineers another? For me, as an informatician, I simply see the value attribute in the DV_ORDINAL as a representation of a concept. The meaning of the concept is explained by the text in the symbol attribute. When I specialize the DV_ORDINAL, one of the options is also to specialize the concept that is represented by the value. This is done by changing the text in the symbol attribute to explain the specialised meaning of the concept. [/quote] Regarding documentation @thomas.beale can pull bits & pieces addressing specialisation. In general terms: https://specifications.openehr.org/releases/AM/latest/Overview.html#_archetype_specialisation I don't think specialisation per se is ambiguous. However when you apply constraints (narrowing) for some DV it might become philosophical. Example; If parent defines a magnitude constraint 0 < x < 10 it's pretty clear what's allowed when specialising. DV_ORDINAL {(at0006, 'red'), ((at0007, 'green'), (at0007, 'blue')} If you specialise, you can't just rename text "red" to "light-red". But you can add a new item in the set. However when it comes to DV_CODED_TEXT, or DV_ORDINAL, ... we may end-up in murky waters where epistemology, ontology and logic may collide. Usually it all revolves around what actually means "narrowing". In terms of Archetype Designer we wanted to support a path to AOM2 and enforce specialisation with ADL14 archetypes - having parent & child in sync. --- ## Post #35 by @ian.mcnicoll [quote="borut.fabjan, post:34, topic:1271"] DV_ORDINAL {(at0006, ‘red’), ((at0007, ‘green’), (at0007, ‘blue’)} If you specialise, you can’t just rename text “red” to “light-red”. But you can add a new item in the set. [/quote] Agree but you can do DV_ORDINAL {(at0006, ‘red’), (at0006.1, ‘light-red’)(at0007, ‘green’), (at0007, ‘blue’)} and with the latest spec proposals also DV_ORDINAL {(at0006, ‘red’), (at0006.1, ‘light-red’)(at0007, ‘green’), (at0007, ‘blue’), (at0.9, ‘black’)} as long as this is not a 'required' valueset . This was disallowed in the previous version of the AOM2 spec. i.e. you could not add a new term to the valueset, if it did not directly inherit from an existing term. The key thing in both is that you are creating a specialisation of the valueset itself, and it is this that carries the extra members. I think there is agreement that for ORDINAL, CODED_TEXT and SCALE that all of this *should* be possible. i.e. what Mikael is wanting to do should be technically possible in the spec and in tooling. Whether it is a good idea from a modelling POV is a different question!! --- ## Post #36 by @mikael BTW; This comment was about if the ADL in the post https://discourse.openehr.org/t/modelling-and-behavior-of-of-the-data-type-dv-ordinal/1271/12 , which was created in the Archetype Designer was correct ADL 1.4 or not. It seems like most people argued that it is correct ADL 1.4 and in that case Archetype Designer do the right thing. --- ## Post #37 by @mikael Hi Heather, I totally agree with you that we need to be careful and I really hope that these issues are well documented now or in the future in some kind of archetype design pattern best practice document. But still I would like to understand what are the allowed specialisations of the data types that contain some kinds of categories, like DV_ORDINAL and DV_CODED_TEXT, because there seems to be different opinions in this thread about what the technical specifications really states. --- ## Post #38 by @mikael Hi Ian, Thank you for the clarifications. For the record I would like to point out that I haven't argued that specialisation of the values in DV_ORDINAL is a generally helpful thing. I only asked if it was allowed according to the technical specifications and tried to unsuccessfully keep the discussion on the technical specifications. The background was that I had found a specific modelling problem that I understood **might** be one of the probably rare situations where this mechanism is useful. But the modelling problem is discussed in another thread. --- ## Post #39 by @mikael I understand @ian.mcnicoll as changing the text from "red" for value 3 in the mother archetype to "light-red" for value 3 in the child archetype is allowed. I also understand as @borut.fabjan first agrees with @ian.mcnicoll , but then state that it is not allowed to change the text from "red" for value 3 in the mother archetype to "light-red" for value 3 in the child archetype. Instead a new value, like 4, needs to be added for the "light-red" text in the child archetype. This confuses me. --- ## Post #40 by @mikael I can only agree that it is important to know what "narrowing" mean. That is why I am very found of supplement the information model with a formal ontology. :slight_smile: --- ## Post #41 by @thomas.beale @mikael nothing you won't already know here, but I'll state it for the benefit of others following the discussion. We have a definition for 'narrowing' - it's the golden rule of openEHR: **a specialised model can only be changed with respect to its (inheritance-flattened) parent in such a way that its instances will also be formal instances of any of its flat parents**, and the underlying reference model (RM). In constraint-land, only 'narrowing' of existing properties can achieve that. The consequence is that querying for some attribute in archetype A will correctly pick up direct A instances, as well as instances of A's archetype children. However, it is worth noting that *new* properties can usually be added in RM container attributes that remain 'open' for addition. This is what provides the flexibility while retaining computability. This concept is the almost the as subsumption in terminologies, if you consider it to be: A' is-a A if all of the a' in the extension of A' are also in the extension of A.; then the relationship between the *intensional* definitions of A' and A is the equivalent of 'narrowing' in constraint models. --- ## Post #42 by @SDubois Hi Ian and others! As a pathologist working at Skåne University, Sweden, I realise all too well I'm waaaaay out of my depth here at the OpenEHR discussion Forum. I'm a member of the Snomed Int'l Cancer Synoptic Reporting Project Group (CSRPG). A word of caution, perhaps. A point we discussed in that forum is the access to the TNM coding system: the AJCC has copyright and would expect Snomed CT to pay a large sum for permission to use the system. The UICC (= European) TNM does not have copyright in the same sense, but the AJCC is in the courts claiming that the UICC are using their system. Food for thought - food for lawyers! --- ## Post #43 by @ian.mcnicoll Thanks Stefan, It is an excellent point. We do have a specific agreement with SNOMED International which allows us to publish SNOMED-CT bindings inside archetypes and templates as long as we make it clear that these can only be used (outside of the free Global Set) if the end-use application or user is licensed to do so. Actually this is routine disclaimer that we make for any copyrighted scales/scores/instruments. > While openEHR archetypes are all freely available under an open license, the specific content of this archetype may be copyright protected. Any use of this archetype within implementations must be in compliance with the terms established by the copyright owners where a copyright exists. > Actually I noticed this is not in the current TNM archetypes (though AJCC is credited in the references) so we should add that -thanks. I'll suggest we should so. This satisfies the vast majority of potential copyright holders. Occasionally we do need to have more complex conversations but they often find it quite difficult to understand that openEHR is not an actual implementer. --- **Canonical:** https://discourse.openehr.org/t/modelling-and-behavior-of-of-the-data-type-dv-ordinal/1271 **Original content:** https://discourse.openehr.org/t/modelling-and-behavior-of-of-the-data-type-dv-ordinal/1271