Medication order, Medication details, Dosage - ready for republication as a new major version

After discussion in Discourse, Slack and among editors, the following archetypes will be republished as a new major version.

At the same time, the following archetypes will be republished as a new minor version, to include the new major versions of the archetypes mentioned above as SLOT includes:

If you have any comments or objections, please note them here, at the latest before the planned publication date, December 23rd 2021.


Just an aside on this… I did a version compare on the first one between latest and the last .v1 version. I notice that the changes are main fixes to slot regexes. One of the new regexes (slightly altered for readability) is:

archetype_id/value = 

The first two matches can be written more readably as:

so the modified result would be:


This change could be used globally in CKM archetypes and would make the slot choices easier to understand. This kind of change can be done as a patch change, since any regex evaluator will return the same result with both forms of pattern.

Just an idea for the future :wink:

1 Like

Does the CKM support the pipes? I tried doing this in the discussion in the other thread, and the CKM didn’t finish the validation, but stopped at the pipe. @sebastian.garde

I prefer this original version. I know it is more verbose but it is way more readable and I’m sure is much easier to implement.


CKM supports the pipes.
However the way CKM currently interprets any pipe as a separator for complete alternatives.
So the Ian-preferred full version should work ok (assuming all individual archetype id patterns are ok), whereas Thomas shortcut syntax would indeed not be fully validated.
The thing with all this is: It is easy to check if a given archetype id is matched by the given pattern. It is however, generally speaking, far more difficult to interpret any possible regex pattern and determine whether it is VDAFI conformant as a whole.

1 Like

This is standard regex - does it mean that the Java (I assume) library / function for processing regexes in CKM doesn’t fully implement regex?

Yes, that is standard regex and no, such a lib would be kicked out. :slight_smile:
The problem is not that I cannot take any given archetype id and say whether it is matching the regex or not.
That is exactly as simple as you make it sound.

The problem is that when validating VDFAI, I do not necessarily have any archetype ids to match against the regex.
The only thing that can therefore be validated is whether the regex can possibly match at least one syntactically valid archetype id.
And that does not seem quite as straightforward to me. I have worked it out more or less for current practice of regex usage for slots. However, making such a validation theoretically bullet-proof for all possible regexes in the slot is not possible as far as I can see. If this problem is trivial to you and I am missing something, please share the solution with me, and we’ll implement it in CKM.

Now as I have said, I have worked it out for the existing typical regexes. However with “your” non-top-level pipes this has just become one extra step more complicated, because you need to do more checking to split the regex in its top-level parts (as separated by top-level pipes). Likely doable as well with extra effort, but not currently done.

1 Like

You just want to test the validity of the regex, right - the usual approach (at least to my knowledge) is to try to compile the regex and if that works, then the regex is valid (doesn’t mean it is ‘right’ of course).

Stackoverflow provided this bit of code for Java:

import java.util.regex.Pattern;
import java.util.regex.PatternSyntaxException;

public class RegexTester {
    public static void main(String[] arguments) {
        String userInputPattern = arguments[0];
        try {
        } catch (PatternSyntaxException exception) {
        System.out.println("Syntax is ok.");

Right - I see what you are doing. Unfortunately I think you’ll need to implement this, because anyone could write an archetype tool that creates slot regexes containing pipes below the ‘top level’ - CKM should die on anything that basic.

However, I think you can get away with counting ‘(’ and ‘)’ and as long as you are not inside any ‘()’, you are at the top level. So I think 4 or 5 lines of code will do it. How does this sound?

We might be in danger of letting the ‘magic of regex’ pushing us way beyond the actual requirements, based on many years practical experience, Silje and I both agree that all we need is to be able to specify…

  • A specific ‘mandatory’ archetype, including version number as the sole-slot fill (Actually not used in practice at all but there may be valid uses in the future)

  • much more commonly (in fact, right now universal) just define one or more archetype patterns as ‘suggested’ - these appear in green in AD, while other technically valid but not ‘suggested’ archetypes appear in grey.

  • occasionally exclude specific archetypes

with really only a couple of variations on that theme.

  1. Include specialisations
  2. Ignore major version numbers

The tooling (and explanation) could be a lot slicker based on these requirements, and is essentially met right now. Just needs the v* handling fixed in AD, I think.


Re ensuring the regex is syntactically valid - ok, no big deal.
Counting ( ) would have been my idea of a “solution” for top-level | as well to take this one step further.

BTW CKM is not dying in that case, it would just show you a (false positive) validation error you can however ignore if necessary.

I - of course - agree that what you are suggesting for a slot regex is valid, but at the same time I am not sure it is a good idea in practice. Ensuring that the main use cases are covered and use an agreed syntax where possible (as Ian suggests) that can be used by tooling to provide better explanations etc. seems far more powerful.


sure. I wasn’t proposing anything earth-shattering - just a readability suggestion. Tools can obviously implement the functionality the way you say - as long as it is saved as valid regex, which is the published standard (including the ISO version of AOM), then everyone will be happy.

1 Like

Where do I find the diff view off the changes in these minor revisions? (Couldn’t find it on CKM archetype history.)
I’m curious about the versioning, if these 2 archetypes now include a new major version of the included archetypes (and the previous version is no longer included) that’s a breaking change and thus a new major, right?
And if it doesn’t (and the previous version is still a valid include) and it’s just a suggestion, wouldn’t it be a patch update?
It doesn’t really matter off course, I’m just working on my understanding of openEHR versioning:)

Isn’t this a breaking change btw? (Again mainly for my understanding)
If an implementer processes this archetype, and all further archetype inclusions are blocked, they may assume a finite set (limited by the current include statement) of possible additions to the data structure. Removing this ‘exclude’ statement breaks that assumption, right? Or is the finite set of possible additions never valid, due to the openEHR constraint model, and therefor not a breaking change?

1 Like

My understanding is that this is not a breaking change because you are essentially widening/loosening the slot constraint.
This at least would be consistent with other elements: widening a constraint - and thus allowing more possible data - is not a breaking change. The other way round (towards more restrictive), it is breaking because the new archetype revision is not guaranteed to be able ‘read’ the data of the previous revision.
(At least for normal elements. Whether this would be the same for Slots is another discussion maybe, but - from memory - how we have it currently defined in CKM as well.)


Sorry, I hadn’t gotten around to making those changes yet. Here they are:

I’m not sure it is, because nothing is excluded in either of the revisions. They’re just suggestions.

The CKM thinks it’s a minor revision. For this particular change, and strictly semantically speaking, it’s probably a patch. But I’m not going to argue with the CKM about it. :smiley:

I agree with @sebastian.garde on this. We’re loosening the constraints, so all pre-existing data made using the previous constraints are still valid with the new constraints.

1 Like

Republished! Merry yule! :santa::christmas_tree::sparkles: