# Choice between data element and SLOT? **Category:** [Clinical](https://discourse.openehr.org/c/clinical/5) **Created:** 2020-09-25 07:22 UTC **Views:** 2077 **Replies:** 41 **URL:** https://discourse.openehr.org/t/choice-between-data-element-and-slot/995 --- ## Post #1 by @siljelb In some use cases, we need to model elements that can be simple or more complex, within the same model. An example is the body site of a diagnosis, which can be as simple as a free text string or precoordinated terminology term, but could also involve aspects, lines, distances from a landmark in a specified direction, or a circular direction around a landmark. Till now we've handled this by putting in a DV_TEXT plus a SLOT for a CLUSTER archetype, like this: ![image|690x473](upload://9Q4PIwYFDQ2fOqfX84TCW8LNTy1.png) This works relatively well, but can in some cases be problematic for querying the data. This led us to think about the possibility of adding a combined data element and SLOT to an archetype. Similar to the way we currently can add several different data types to a data element. Is this something that could work? --- ## Post #2 by @thomas.beale The simplest approach is to do what you are doing and always ensure the simple DV_TEXT element contains an appropriate value even if the more complex data are filled in, i.e. so that querying can always succeed in the simple mode, even if the data tree is also there. --- ## Post #3 by @siljelb Sure, that's how the models are intended to be used now, although we can't enforce it. But the question was if we can make a single AT-code (or id-code in ADL2) a choice between (for example) DV_TEXT and a CLUSTER slot? And if we can't do it now, what would need to be changed for this to become possible? --- ## Post #4 by @yampeku Wouldn't be enough to adjust parent attribute cardinality to {1..1} and make occurrences of both element and slot [0..1]? --- ## Post #5 by @siljelb That would make us always have to choose one or the other, but not make the element and the slot have the same AT-code for queryability? --- ## Post #6 by @yampeku But being two different classes makes already impossible to reuse the query, as they have different attributes --- ## Post #7 by @thomas.beale [quote="siljelb, post:3, topic:995"] although we can’t enforce it [/quote] Soon you will be able to, when we get archetype rules finalised. [quote="siljelb, post:3, topic:995"] make a single AT-code (or id-code in ADL2) a choice between (for example) DV_TEXT and a CLUSTER slot? And if we can’t do it now, what would need to be changed for this to become possible? [/quote] Not really possible without the creation of a new formal type. This is the same problem as the 'smoker=true?' problem. I will reflect further... --- ## Post #8 by @GerardFreriks In general: the EHR is documenting things in the patient system. This can be a body location. Anything documented has localisation in time and space. Space can be the world (GPS), address, organisation and anatomical location, etc. Localisation in space, in general, can be absolute (e.g. GPS) and relative to anything else including an Anatomical Body Part. When it is a relative location one needs to specify in more detail the vector from a point of reference. This vector defines the point of origin, the distance between the point of origin and the item that is documented, plus direction. In addition and alternatively the vector can be replaced by a term from a classification defining things as: (partial) overlapping, above, below, to the left, to the right. All these subtleties pose problems too easy querying but are needed to fully model data in the EHR. For the moment any quick fix is just that. --- ## Post #9 by @ian.mcnicoll I did have some ideas about his a few years ago, as I completely recognise the issue but it was pretty difficult to come up with a solution. It was discussed in CIMI but my head exploded trying to work out a solution!! --- ## Post #10 by @ian.mcnicoll The basic problem is to make this CLUSTER: 'Complex Body site' ELEMENT: Body site SLOT: look like this (for simpler use-cases) ELEMENT: Body site i.e where the parent Cluster and slot are normally hidden but the query path is actually the more complex one. --- ## Post #11 by @siljelb Not sure I understand this. Could you explain again? :innocent:🤕 --- ## Post #12 by @yampeku I assume both Element and slot Element are hanging from CLUSTER, so generic paths without specifying the node_id can indeed be used. Again, playing with cardinality could ensure you have either the original Element or the slot one --- ## Post #13 by @heather.leslie Not quite. The suggestion as I understand it is to have a run-time choice between a coded_text and a SLOT containing a CLUSTER that would provide detailed structure for the same semantics. Body site is a classic example - prefer to use a value set of body sites where possible but allow CLUSTER.anatomical_location as a fall back if you need more specific detail or to cover something not included in the value set. --- ## Post #14 by @yampeku but you would need 2 different queries to get values from either, right? --- ## Post #15 by @ian.mcnicoll I'll try again!! Told you it made my head hurt last time!! What we want for the majority of simpler uses, or where pre-coordinated terminology works is just ELEMENT: Body site but sometimes we need to handle more complex constructs ELEMENT: Body site ELEMENT: Laterality Currently we do that by adding a SLOT for the more complex example but that means we end up with Body site both two places. I think what I am trying to get at is something like EXPANDABLE ELEMENT : name: Body Site value: Lung other details: CLUSTER SLOT So this is as full blown Element not a slotted in construct. It already has a 'slot' at the same level as the name and value. THe other_details is other details relating to the Element itself not sitting alongside it in the root. In this world the current anatomical location CLUSTER would be much the same but would not have its own 'body site' element. That should give us a clear query target for body site. THe only way we can do that is use the CLUSTER every time which is a pain. One other approach would be to change the visuals via some kind of directive to give the option of 'hoisting' the CLUSTER body site ELEMENT to the root level. That would mean adding the CLUSTER to every template. The only other option I can see is to consider creating some 'domain' datatypes e.g. an 'Anatomical location' datatype. Are there other examples of similar patterns /problems - I guess the Medication Order / Cluster is one although that is more subtle --- ## Post #16 by @damoca This is probably not the solution you are searching for, but I think the problem you are presenting is just in the middle of that grey zone between information models and terminologies. An in my opinion, the representation of this case should fall in the terminological area. At the end, you want an element with a code, that can be simple or be somehow postcoordinated. If you are using SNOMED CT, this would be "easy", just use a post coordinated expression. If using post coordination is still something futuristic, or if you want to define constraints over the specific atrributes of the code, or if you are not using SNOMED CT at all and you want to use a terminology that does not support post coordination, then probably you need something new in the RM. In the old 14796 data types standard (the one used in the first version of ISO 13606), the Concept Descriptor (CD) data type supported this feature. It represents a coded value where you can attach semantic qualifiers (attributes) with a role and a code value. This allows creating a basic post coordination using the information structure. The advantage would be that we still could build AQL queries over the data type information structure. --- ## Post #17 by @ian.mcnicoll I probably agree David, other than that a) I'm not sure anyone is using post-coordination in operational systems in anger b) SNOMED licensing remains an issue. If it were not for that, I think there is a good case for at least testing whether the current SNOMED anatomical location model is a good fit. Certainly an area where the kind of dual terminology/Information model representation that CIMI was striving for might be worth the effort, although I suspect that even that you might find that the biomedical view of anatomy - essentially the relationship between body parts, gets out of kilter with the IM requirements e.g relative locations, detailed xy,z coordinates. Beyond laterality, I wonder how much overlap really exists? --- ## Post #18 by @heather.leslie Discussions with local SNOMED experts today about how to manage laterality in diagnoses and body site... Apparently there is a SNOMED ref set that captures all of the duplicated body structures, so there should be a pretty comprehensive value set for body structures that means the Anatomical location archetype will only need to be used in outlier situations. The updated body sites with laterality are limited to left or right , so we need two occurrences if we need to represent both left and right of a duplicated body structure. The hierarchy containing 'both' or 'left and right' body sites is apparently outdated and I was advised it should not be used, at least for now. It means that we can safely keep most diagnoses and their body sites modelled within the single archetype, without needing to extend with the Anatomical location CLUSTER. There is an increasing number of precoordinated diagnoses with Left/Right/Bilateral as well. Reassuring if you have a SNOMED license, but this is still diverting from the original question of how a CHOICE may be implemented at run-time and found in queries. H --- ## Post #19 by @ian.mcnicoll A big help here would be if we could persuade SNOMED Int. to release those pre-coordinated body site + laterality codes as a 'free set'. That would largely solve the body site issue as I think it mostly relates to laterality. Who wants to start a conversation (maybe along with FHIR folks) ?!! However I still suspect there are other similar patterns but can' think of specific examples so far!! Are there any from the physical examinations? There probably are some examples from the old histopathology work --- ## Post #20 by @heather.leslie [quote="ian.mcnicoll, post:19, topic:995"] similar patterns [/quote] Not quite sure what you mean. We do the same Body site/SLOT Structured Body site combo with BP and the Exam CLUSTERs. Procedure has Body site and suggestion to put Anatomical Location in the Procedure detail SLOT, rather than a dedicated one. Imaging instruction will need it. There will be others. --- ## Post #21 by @ian.mcnicoll Sorry - meant the situation where we have an Element which, particularly if coded, will work for the majority of scenarios but where we have to add a slot which in some aspect replicates that element within the slotted in cluster - similar to having body_site in 2 places. The other aspect which I had forgotten is that DIPS had a use case for being able to query for body sites regardless of the containing ENTRY archetype - 'things about left eye'. AQL allows us to do this for anything in a CLUSTER archetype but not for normal ELEMENTS. In theory this should be possible but I think is a technical challenge as it would mean having to index every ELEMENT to make it preformant. So next question for us as modellers - would we feel able to identify and tag 'key' ELEMENTS that could/should be independently queryable, as flag to the technical guys that these might be usefully indexed. --- ## Post #22 by @heather.leslie If I understood what you meant, I'm sure the answer will be 'modellers can do anything'! It would need to be at an Editorial level in a CKM situation, I guess --- ## Post #23 by @ian.mcnicoll "Sure, that’s how the models are intended to be used now, although we can’t enforce it. But the question was if we can make a single AT-code (or id-code in ADL2) a choice between (for example) DV_TEXT and a CLUSTER slot? And if we can’t do it now, what would need to be changed for this to become possible?" Just to get back to the original issue - I don't think just having a choice of Element and Cluster slot really solves the problem, which is really that the 'body-site element still potentially exists at two different places, so is not easily queryable. The challenge is to have that 'body site' element at a single location, but also extensible with a slot, and also independently queryable (regardless of parent archetype). Easy! --- ## Post #24 by @ian.mcnicoll [quote="thomas.beale, post:2, topic:995, full:true"] The simplest approach is to do what you are doing and always ensure the simple DV_TEXT element contains an appropriate value even if the more complex data are filled in, i.e. so that querying can always succeed in the simple mode, even if the data tree is also there. [/quote] This didn't work work for DIPS as they wanted to be able to query independently of the containing entry which you can do with CONTAINS CLUSTER. 'Give me everything associated with left eye' --- ## Post #25 by @heather.leslie [quote="ian.mcnicoll, post:23, topic:995"] The challenge is to have that ‘body site’ element at a single location, but also extensible with a slot, and also independently queryable (regardless of parent archetype). [/quote] We have spent a lot of time on that and the only way around it is to have the advice in the comment of CLUSTER.anatomical_location that it is redundant if the body site is already identified in the parent. OR systems can duplicate it, potentially. Not good enough, really. :zipper_mouth_face: --- ## Post #26 by @joostholslag Just discovered this topic. For me this is a nice example case of my recently initiated discussion about reusing more elements/clusters between archetypes. In my mind the only ‘right’ way to model Siljes example would be to remove the element Body site and only use the cluster. I understand this adds some overhead but not sure how big the overhead is? What we could do to help implementers is to offer a template where the cluster is already configured. Or to embed a ‘template’ overlay on the cluster in the observation, or is that not allowed in the current RM? The usecase is indeed the querying. I think there is tremendous value on “give me everything to do with the left eye” and this also goes for most other archetyped data: “give me everything to do with blood pressure” should return an observed bp, the instruction for the order to measure BP, the action where the activity was registered, the evaluation where the diagnosis high blood pressure was recorded. So to me blood pressure as a medical concept should be a cluster. As should maybe all other elements.... To me medical data is associative/relation: all data relates to other data. I think the RM has a lot of features to model this ‘properly’. But we use very little. What if we put all elements in a cluster, like we now do not put any data elements in a composition for reuse purposes. --- ## Post #27 by @heather.leslie [quote="joostholslag, post:26, topic:995"] In my mind the only ‘right’ way to model Siljes example would be to remove the element Body site and only use the cluster. I understand this adds some overhead but not sure how big the overhead is? [/quote] Hi Joost, This is the way all of these archetypes started and it didn't work. The overhead is huge, because in these situations, by far the majority of the time we only need one data element. Academically the CLUSTER makes perfect sense and so we built 3 variations of Anatomical location - normal, relative and circular. They've all been published, but IRL I never model with them, except to add them to the slot *just in case* the use case exceeds our simple anatomical location site value set. The only reason we need the CLUSTERs are for the outliers - our 'get out of jail free card', if you're a Monopoly player. I totally empathise with your grappling with this. You aren't the first and you won't be the last. The current modelling option allows you to model as you suggest, but also allows the rest of us to keep what we are doing as well. Silje's suggestion to combine a SLOT with a data element as a choice would be an even more elegant solution to the practical issues we face every day. On my wishlist, for sure. --- ## Post #28 by @joostholslag Hi Heather, Thanks for your response. I’m sure you are right that the overhead is not worth it atm. But would you share a bit about your experience why it did not work. Where is the overhead? I’m not trying to advocate changing our modelling to something that favours academic purity above something that has proven to work. I’m just interested to learn where the pain is. Because I’m still naive and idealistic enough to believe we might make it work the second time around. --- ## Post #29 by @heather.leslie Others should speak up as well. It was not a solo decision by me :thinking: In principle, adding a CLUSTER archetype containing the maximal dataset seems to fit the openEHR academic principles we teach! Yet the practical implications for modelling/querying etc are just as important. So the 'art of archetyping' is as much in knowing when to break the rules as when to apply them. We use anatomical site in many archetypes, most effectively used in conjunction with a terminology value set derived from SNOMED CT or similar. That is the most powerful way we have of recording the location of a thing on the body, and the 95-99% use case, if we're honest. The detail of a precise Relative location will be needed when we need to describe the start and end of a laceration perhaps. Circular location when describing a haemorrhoid or breast lump. Otherwise a value set, containing a list of anatomical sites, even better if they were precoordinated as left/right, where appropriate. The rest of the regular anatomical location data elements will likely hardly ever be required, except where precoordinated terms are not (yet) available. So in practice, if we only use the SLOT and standalone CLUSTER for anatomical location - 95+% of the time we have to constrain all of the other data elements out. It's extra steps for modelling, even if we create an archetype level constrained template, and insert it into the parent archetype. Instead use it as an alternative when SNOMED does not carry the desired precoordinated terms and model Anatomical location as required for the archetype. A better example may be the notion of dimensions. We are increasingly finding that our earliest ideas of creating a reusable 'Dimensions' archetype is not as utilitarian as we first thought and we are slowly coming around to the principle of adding the specific, relevant dimensions inline per archetype, rather than trying the SLOT/generic archetype combo. We will never query on all 'widths', only the same width within the context of the same clinical archetype to identify change. Querying on all Anatomical sites is also not so useful, although we have ensured that anatomical site has been modelled within examination findings so that SNOMED bindings will allow us to find all examinations related to a specific site or children/detail of that exam site. Hope this helps. --- ## Post #30 by @joostholslag > - 95+% of the time we have to constrain all of the other data elements out So the issue is the work on excluding unused elements. I see multiple ways of solving this: 1. we could create a template specialisation of the cluster that constraints out all infrequently used elements and include that in the usecase specific template. 2. We could create a template for the archetypes that include the cluster and constrain out the infrequently used elements in a template overlay. 3. (Not sure the spec allows this) we could create a slot in the archetype that uses an element from the cluster. Like use-archetype element openEHR-EHR-CLUSTER.anatomical-location.v1/items/at0065 Interested what you guys think about this. [quote="heather.leslie, post:29, topic:995"] We will never query on all ‘widths’, only the same width within the context of the same clinical archetype to identify change. [/quote] Makes sense, querying all width probably has little value. Though also in this case I see a lot of value in the reusable approach. If the application can understand and rely on what a reletive width is, you can build an interface that shows a ruler with the distance from the know point. This could be very useful in e.g. linking radiology data (tumor is 5cm left lateral to the thalamus) to surgical microscopes that can project the tumor based on neuronavigation. I can still see that the usecase is too exotic and not worth the effort. I just would like to discuss how to ease reusing archetype(elements) to lower the cost and make the exotic usecase more viable. --- ## Post #31 by @heather.leslie [quote="joostholslag, post:30, topic:995"] * we could create a template specialisation of the cluster that constraints out all infrequently used elements and include that in the usecase specific template. * We could create a template for the archetypes that include the cluster and constrain out the infrequently used elements in a template overlay. [/quote] All of this is possible and has been tried. You can obviously do this if you want - the current pattern allows this. [quote="heather.leslie, post:29, topic:995"] So the ‘art of archetyping’ is as much in knowing when to break the rules as when to apply them. [/quote] I still go back to this statement. In archetype design, reuse is always at the forefront of our mind. I have been the major advocate for reuse, where it is valuable, including publishing papers on it - https://pubmed.ncbi.nlm.nih.gov/33035176/. However, in this specific situation, the current Editorial approach is that reuse, for reuse's sake, is not a good principle. We have tried and tested your suggestions, and more. But being pragmatic wins out sometimes for reasons including modelling overheads, training others to model etc. --- ## Post #32 by @ian.mcnicoll @joostholslag - it is great that you are bringing up these issues. As Heather has said some are a well and sometimes frustratingly well-trodden path. We have round the houses quite a few times but we have all been caught with situations like 'physical properties' where re-use turned to be a bit of a mirage and just complicates things. What we should possibly be doing its taking a fresh look at some of these knotty problems ,not from the perspective of clinical modelling patterns perhaps, because I think we have probably arrived at some optimum approaches for now, but in terms of what we might change in the RM or basic structures and where terminology might help. We have tended to avoid poking the RM too much as it has proven very stable but perhaps time to take fresh look at some aspects. e.g is there merit in looking at an anatomical location structure that would smooth the bumps you have identified and play very nicely with SNOMED-CT. Essentially something that would feel like and anatomical location datatype that could be used in any archetype. I am thinking aloud here - don't ask me for details!!! I would not look to get these changes into production any time soon but no harm in us taking another look at the requirements with a clean view and see if we can come up with some new approaches that are not possible with the current RM. Another idea we might pick up on is a somewhat obscure bit of FHIR called ObservationDefinitions. The idea there seems to be able to create lightweight definitions for things like physical properties, lab analyte codes, coupled with appropriate units but as an external reference lookup, not as a constraint model as we do in archetypes (and FHIR does to a lesser extent in profiles). So these are definitional references (souped up terminologies) rather than formal constraints. I can see the advantages of using something like that for common physical properties and lab analyte properties. > 1. (Not sure the spec allows this) we could create a slot in the archetype that uses an element from the cluster. Like use-archetype element openEHR-EHR-CLUSTER.anatomical-location.v1/items/at0065 I think that is worth exploring - It would also let us use fragments from Observations as Clusters BTW - The 'snowflake' button in Archetype Designer has removed 90% of the pain of constraining out un-needed nodes in templates. For those not familiar - it sets every node to 0..0 unless that node is mandatory in the archetype. So you take everything pout then add back in the ones you want. --- ## Post #33 by @joostholslag [quote="ian.mcnicoll, post:32, topic:995"] sometimes frustratingly well-trodden path [/quote] Yeah I understand you guys have been doing this for many years to get a feel for what works and what doesn't. So I'm not trying to change the CKM editorial policy (for now). I'm just interested to learn form your experiences what the downsides are from reusing clusters vs seperate elements, for Nedap custom archetypes. But also I love the openEHR community and spec very much. And it contains so much insight into health informatics that I want it to be even better. The area that is very interesting to me is the associative aspect of healthcare data, everything is/could be linked/related! And I feel there is an opportunity to improve the openEHR artifacts to better facilitate recording those links. That's why I like exploring this. [quote="ian.mcnicoll, post:32, topic:995"] I would not look to get these changes into production any time soon but no harm in us taking another look at the requirements with a clean view and see if we can come up with some new approaches that are not possible with the current RM. [/quote] This is my aim indeed! --- ## Post #34 by @thomas.beale [quote="ian.mcnicoll, post:32, topic:995"] ObservationDefinitions. The idea there seems to be able to create lightweight definitions for things like physical properties, lab analyte codes, coupled with appropriate units but as an external reference lookup [/quote] What stops this becoming a combinatorially huge resource that looks like say the LOINC table but with units added? (Genuine Q ;) --- ## Post #35 by @pablo What I have seen happening in the FHIR world, is 1. having optional field or object (element or slot in our case), like the example 2. and, if that data is mandatory in any of those nodes, there is a rule stating one or the other should contain some data I think we are lacking the rule part in our archetypes yet. I don't think there is a way around having the "alternatives" in the model, I guess queries should consider both cases, and use the correspondent CONTAINS or EXISTS accordingly. --- ## Post #36 by @heather.leslie Agree, and this is where the conversation comes full circle. The FHIR approach to modelling is one of the triggers for this thread. Having two related data objects modelled sequentially and annotated as alternatives is not an ideal solution. Longstanding modelling experience has identified this as a new requirement. --- ## Post #37 by @ian.mcnicoll Actually nothing - it does look like the LOINC table with added units!! Just easier to manage and would allow for more local maintenance. --- ## Post #38 by @thomas.beale [quote="ian.mcnicoll, post:37, topic:995"] ctually nothing - it does look like the LOINC table with added units!! Just easier to manage and would allow for more local maintenance. [/quote] So I think in that case it's a kind of tool cache rather than a model-level facility? Which could be very useful, but I'm not clear on whether there is any new semantic element. --- ## Post #39 by @ian.mcnicoll Agree - what both FHIR and openEHR lack is the ability to have an association between the 'simple' coded element and essentially the same 'coded' element within a more complex structure - you can see this in FHIR with the relationship in between e.g the Medication request and Medication resource - although their 'choice' is a little more elegant is fundamentally still leaves potentially 2 elements which have identical meaning - this is exactly the same issue as we have with 'body site' . So, yes having an improved 'choice' is useful but dose not really resolve the tricky question fo how to associate body site in the Entry/resource parent with 'body site' in the Cluster/resource. or equivalent for 'Medication name'. I had a go at this a few years ago as part of CIMI but it made my head explode!! --- ## Post #40 by @thomas.beale To get the effect that people want, at the RM level, the structure is just a CLUSTER, but one that always follows the pattern that @ian.mcnicoll was trying to get at with his EXPANDABLE_ELEMENT... [quote="ian.mcnicoll, post:15, topic:995"] EXPANDABLE ELEMENT : name: Body Site value: Lung other details: CLUSTER SLOT [/quote] The structure is just a CLUSTER that always follows the pattern: * CLUSTER -- root point * ELEMENT[1] -- logically atomic representation * CLUSTER[0..1] -- detailed representation This assumes the 'atomic' part is always representable as an ELEMENT. So there's nothing mysterious in my view about how to solve the need here, except for the basic (annoying?) fact that the minimum RM structure needed is *always a CLUSTER*. I would call this a 'standard pattern', and it could easily make sense for archetype modelling tools to support them. How would they do this, if they are driven from BMM files (like AD, LinkEHR, ADL WB etc)? It means that there is a config file containing a list of named pattern structures for the RM being used. I.e. archetype fragments/prototypes to be used by tools. --- ## Post #41 by @yampeku In LinkEHR we added an artifact called "semantic pattern" that was a predefined ADL structure that was also added as a binding (DCM::SemanticPatternId). I think this is what you describe. We use it for different things, such as CLUSTERs equivalent to complex data types in different RM, or semantic structures that represent classes in other RMs --- ## Post #42 by @thomas.beale [quote="yampeku, post:41, topic:995"] In LinkEHR we added an artifact called “semantic pattern” that was a predefined ADL structure that was also added as a binding (DCM::SemanticPatternId). I think this is what you describe [/quote] I knew someone smart would have thought of this! --- **Canonical:** https://discourse.openehr.org/t/choice-between-data-element-and-slot/995 **Original content:** https://discourse.openehr.org/t/choice-between-data-element-and-slot/995