Choice between data element and SLOT?

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.


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

1 Like

“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!

1 Like

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’

1 Like

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:

1 Like

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.

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.

1 Like

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.

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.

  • 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.

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.

1 Like

All of this is possible and has been tried. You can obviously do this if you want - the current pattern allows this.

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 - openEHR Archetype Use and Reuse Within Multilingual Clinical Data Sets: Case Study - PubMed.

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.


@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.


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.

This is my aim indeed!

What stops this becoming a combinatorially huge resource that looks like say the LOINC table but with units added? (Genuine Q :wink:

1 Like

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.

1 Like

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.

Actually nothing - it does look like the LOINC table with added units!! Just easier to manage and would allow for more local maintenance.

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.

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!!

1 Like

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…

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.