@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.
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.
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.
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).
So, in some sense, we who come along with our keen sense of Aristotelian classification, are mopping up after some eggs have been dropped
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.)
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!!
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.
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.
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.)
