Barnet_David_HEALTH
(Barnet David (HEALTH AND SOCIAL CARE INFORMATION CENTRE))
1
Hi All
I’m having a bit of an issue with CKM re-versioning archetypes and slots that reference Clusters.
When I create a new archetype in the archetype editor (Version 2.2.905 Beta), the archetype is saved as version 1. For example
“openEHR-EHR-OBSERVATION. blood_pressure.v1.adl”
When I upload the archetype to CKM, the process renames the archetype to version 0 – for example “openEHR-EHR-OBSERVATION. blood_pressure.v0” (we are hosted on version 1.4.0 of the Clinical Knowledge Manager)
The re-versioning becomes an issue when I use slots. In the Archetype editor I can assign a slot to a Cluster (for example), but this process creates a link to a version of the Cluster. If it’s a new Cluster, this will be version 1. When the Cluster and the archetype are uploaded to the CKM, they are both put back to version 0. However, the slot Cluster is looking for version 1 of the Cluster, which won’t exist on the CKM (so CKM can’t make the link between these 2 objects).
Does anyone have a work-around, or have some advice and guidance, for this issue?
I recognise the problem which is a result of the transition to a much richer and better versioning mechanism.
The Archetype Editor has been updated to handle the new versioning (on the openEHR Github, not released yet ) but we will need to adapt the slot fill regex to allow for .v0 archetypes, which are now the default for new, uncontrolled archetypes.
The default regex for slot-fill pattern needs to be changed to allow any Version not just V1
My understanding was that minor version and patch version would not be part of the normal archetype id, which is what you are looking for here?
Otherwise you’d need to allow “-alpha” etc here as well?
I was really thinking towards the future and the same slot constraints appearing or being redefined in templates where tighter constraints might be needed.
Technically speaking, if we want to properly match any archetype in a slot, we need a regex that will match any level of versioning id. Since matched archetypes will eventually all have 3-part versions (but today might have only 1-part versions), we need to match thngs like
.v0
.v1
.v0.0.1
.v3.0.2
and so on. So Diego's expression will do that. But Sebastian is correct - some of the matched archetypes could be test or research archetypes. So you need the remaining bit as well. You could in theory use:
v[0-9]+(\.[0-9]+(\.[0-9]+((-rc|-alpha)(\.[0-9]+)?)?)?)?
but I would say it is overkill (you only use regexes like that when you think there could be garbage version ids and you want to catch them and reject them). A reasonable balance is probably something like
\.v[0-9]+.*
which forces at least one digit of major version, and allows anything at all to come after, which is reasonable if we assume that no tools will create completely invalid version ids.
The + is redundant here, since it’s just saying that there has to be one or more digits after the ‘v’. But the next thing that it says is that you can have anything at all after those digits.
So you might as well omit the +:
.v[0-9].*
This says that there has to be a digit after the ‘v’, followed by anything at all. This amounts to the same, since any extra digits qualify as “anything at all”.
On a related note; the openehr.org website still advertises Archetype Editor v2.2.905 beta from 2013, and Template Designer 2.6.1213.3. Especially now after the v1 → v0 change, the newest builds should be linked from the web site.
I’m assuming there’s no reaction to this because everyone is still enjoying their well-earned holidays. J
But this is a serious issue, which leads to only people “in the know” being able to download updated tools and create and edit archetypes and templates which conform to the newest patterns. Precisely what we’d like to avoid, isn’t it?
I’m assuming there’s no reaction to this because everyone is still enjoying their well-earned holidays. J
But this is a serious issue, which leads to only people “in the know” being able to download updated tools and create and edit archetypes and templates which conform to the newest patterns. Precisely what we’d like to avoid, isn’t it?
I’ve personally used newer versions of both tools than what’s currently on the website, in fact we haven’t used TD v2.6 since we got our CKM in February 2014, since it doesn’t work with Norwegian Bokmål (nb) archetypes. If you need people to do testing for a release I’d be very happy to help, and I’m sure lots of other people would too. Is there any test documentation available so testers can know what to do and where to get the test versions of the tools?
I have been using the new versions of the tools in ‘live’ settings for some time now. I have not come across any showstopper issues. I think we are pretty well ready to go.
Looking at this again, AE currently provides two choices
Do not include specialisation, in which case the slot constraint matches the provided slot archetype name and version exactly.
Include specialisation where any specialisation of the provided slot archetype is allowed (but currently only the same version of the supplied slot archetype).
I suggest that we leave (1) as -is to allow precise slot-fills to be defined but loosen (2) to allow any version.
