Hi, it occurred to me that we don’t often talk and do much on archetype specialisations. I came across a few videos where people familiar with FHIR raised the question of how does openEHR handle meeting certain use cases, such as national or project specific requirements where the base/global archetype doesn’t have certain extra properties/data elements. Well, that’s why this particular extension method has been created for. But I have seen in several instances the Extension slot has been suggested to answer that.
There are two problems here:
In most OBSERVATION archetypes I have looked at this Slot is in the Protocol section so I don’t think it is appropriate to add extra data elements that relates to the actual Data capture into protocol.
If we allow this as the defacto means of extending archetypes we will run into the same conundrum that FHIR is having with uncontrolled proliferation of extensions! Plus we lose important semantics that added data elements are part of Data, Protocol or State and in most cases those added data elements will have some semantic relationship with existing data elements (e.g. may be under a defined CLUSTER or added valueset items to well defined valueset etc.)
In the S2 archetype library, which contains re-engineered openEHR archetypes, we have added more specialisation, not less, including adjusting some existing ones (e.g. anatomical location) to have specialisation. We do this for the same reason inheritance is used in OO programming - a) extension at design time and b) substitutability at runtime (polymorphism).
We also replaced nearly all archetype slots with use_archetype direct references, many to a parent archetype of a specialisation hierarchy. This produces much more usable templates and greatly improves seamless extension of generic concepts with more specific forms.
Great topic, Koray. I’ll be really interested to hear other opinions
When I got started, the practice was to create a lot of specialisations but quite quickly it became apparent that this was problematic.
It was tricky to do synchronisation in the specialisation hierarchy e.g. when a parent archetype was updated, because, in ADL1.4, specialisations are complete archetypes, including all the parent nodes. ADL@ gives us differential .adls archetypes which will make this easier, along with the use of semantic versioning. However, this was not the real barrier.
Much more importantly, we found that the semantics of ‘pure’ single-inheritance type specialisation was often problematic. As the specialisations were extended, we found that what had seemed like common inherited patterns broke down as we got into further detail.
It also became very difficult to manage the need for multiple inheritance i.e. where we had specialised for a particular device but also needed to add some kind of national localisation, perhaps with some common metadata
As a result, a much more common pattern now is to extend archetypes by adding cluster archetypes into slots.
The only problem with that is that in ADL1.4 we somewhat lose the idea of these ‘compound structures’ being archetypes - right now we have to represent them as embedded templates.
Now this is where ADL2 is going to make a big difference, as it formally allows specialised archetypes to include slot-fill extensions or even direct references
, as Thomas mentioned - so a specialised ADL2 archetype may actually only include aggregated clusters or references.
@thomas.beale - can you provide an example of one of the S2 archetypes that uses references?
There is still a place for ‘traditional’ specialisation - see the Imaging clusters for example, but I’m pretty sure the future will be a mix of limited traditional specialisations and slot fills/references.
TBH I don’t think the mechanism of extension really has an impact on the impact of local variance. The main difference between us and FHIR in that regard, is our commitment to largely model and manage concrete definitions as an international shared effort, rather than local heavy extension of generic resources like Observation or Questionnaire
Here’s S2 form of BP. The modelling of Location of measurement + Structured measurement location is not quite right for BP in my view; in other archetypes, we only use the Structured measurement location data point.
I am looking at modifying the semantics of use_archetype to allow multiple possibilities; if this works, I’ll propose it as an ADL3 innovation and we would be able to scrap slots altogether.
That is certainly true, even of the resources that are semantically more detailed like adverse reaction. Heavily modified in each implementation space.
Hi Tom, I’m not familiar with ADL2 and is there a public repo for S2 archetypes? What tool support it has (as I can see Archetype Workbench?)
What does S2 stand for? @thomas.beale@ian.mcnicoll
Hi Tom,
I may have missed it but in the two screenshots: First: Assuming this is an Archetype, I can only see direct archetype references with a particular major revision number Second: I can see Exertion and Device inline expansion of that archetype in the Template
I don’t see how specialisation of any archetype is represented. If you wanted to show slotting of specialisations of anatomical_location archetype it’s not represented in the template (second one)
Is there any documentation or other resource on this? @thomas.beale@ian.mcnicoll
Thanks @ian.mcnicoll !
There’s a lot going on here. With my limited understanding (e.g. single vs multiple inheritance / polymorphism applied to Archetypes) I fail to understand the reasoning.
Perhaps an pseudo example might be useful:
Archetype A: an Observation
data:
-Element 1
-Cluster 1
—Element 2
—Element 3
If I want to add a new element between 2 & 3 I need a SLOT to add CLUSTER extension which includes that Element. There’s an implied semantics that this new Element is related to Cluster1 and add more detail in addition to Elements 1&2. In order to do this Archetype has to be modified to add that Slot which is not ideal OR include a lot for extension under each main section (e.g. data, protocol, state etc.) and under every Cluster!
Another use case is to change constraints to Element 3 (0…* to 0…1) or remove some local enums - not sure how an Extension slot will achieve that. Except for templating but we’re looking at Archetype level now.
Currently the generic Extension in the protocol of many Observation archetypes will not be appropriate to add these sorts of extensions (new Elements, narrowing constraints or redefining existing Elements). IMHO, we need to find a solution ASAP as the rate of modelling is increasing exponentially as I can see. I honestly don’t think we will be able to move to ADL2 anytime soon so let’s not wait for that to happen to address this important issue!
FHIR extensions, leaving aside the modelling process, provide the means to:
a) don’t need to alter base resource
b) can add anywhere in the tree
c) if they are properly documented and published in the registry perhaps smart tooling can prevent people creating similar extensions. I think we should also look at improving modelling tools (e.g. an AI semantic checker that guides modellers to reuse existing specialisations rather than reinventing new ones).
One other current limitation is lack of (full/partial) support for querying specialised archetyped data using AQL - it may be defined but most likely not supported by all/some CDR implementations. This is a major shortcoming that would hinder use of specialisations even if it’s defined in the specs.
It’d be great to get insights/recommendations from implementers > @sebastian.iancu@bna@birger.haarbrandt@Seref@matijap@chunlan.ma
at the moment, you would query for the base archetypes and its specialized archetypes like this in EHRbase:
{
"q": "SELECT obs FROM EHR e CONTAINS OBSERVATION obs WHERE obs/archetype_node_id LIKE 'openEHR-EHR-OBSERVATION.blood_pressure*.v2'"
}
I would have to take a look, but I think the semantics for automatically resolving all data based on specialized archetypes is not yet part of the spec. I remember some discussions on this, but I don’t think we concluded it.
That’s how we are doing most refs. However, we think we also want to allow open version, i.e. just take the latest, no matter what it is. This can be controlled if needed in a template. This avoids endless reversioning of archetypes to fix wrong versions in slots.
It’s not in those. Here’s the specialisation of anatomical location. A use_archetype ref to just the top one allows it, or any child at templating time, or at runtime.
Thanks @birger.haarbrandt looks pretty straightforward. I hope it works OK in CDR implementations. One has to be careful about the version of the parent archetype, though and a process to look for and update specialised archetypes based upon previous versions. Again, smart tooling would be nice to have.
