AW: AW: Syntax for including archetypes in SLOTs, regardless of version

[Sebastian Garde]

Von: openEHR-technical  Im Auftrag 
von Thomas Beale
Gesendet: Dienstag, 18. Dezember 2018 18:39
An: openehr-technical@lists.openehr.org
Betreff: Re: AW: Syntax for including archetypes in SLOTs, regardless of version


The example below 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2] means that 
not only v0, v1, v2 are valid, but also v10, v15, v27 to name a few.

the regex character class [0-2] matches only a single digit having the 
character values in the series 0-2, i.e. 0, 1, or 2.

[SG] Sure – but if it is were the case that only a partial match is required, 
anything could be added to the left or the right (as long as it makes a valid 
archetype id).

Now that you mention it, I do seem to remember we specified a very long time 
ago that those regexes did have to be full validating ones.

[SG] That’s exactly what I mean, yes, thank you. (And that then ensures that 
the above does not match v10 or v15…)

So that means using something more like

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v(0|[1-9][0-9]*)(\.(0|[1-9][0-9]*)){0.2}

as the checker regex in CKM, and patterns like 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v.*, where the 
trailing '.*' matches anything, and the validator regex ensures it is only 
semver dotted version patterns.

- thomas


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AW: Syntax for including archetypes in SLOTs, regardless of version

[Thomas Beale]

On 18/12/2018 16:48, Sebastian Garde wrote:


Hi Silje, hi Thomas, hi all,

Whether the CKM validation errors from below are correct or bogus 
boils down to my question from before whether it is valid or not to 
just leave the version part out completely.


In my understanding the regex needs to be fully matched which means 
you cannot just leave it out completely – but it is not 100% clear 
from the specs as far as I can see (but see my excerpt from the ADL2 
specs from before).


if you are using the regex to validate ids, then you will need the full 
regex to match any valid id. If the regex is just to filter out ids that 
are validated elsewhere then you can minimise the regex.


If we assume the regex does NOT need to be a full match, then the 
validation errors from CKM below are bogus of course.


But if partial matches are sufficient, this in turn requires some 
reinterpretation of existing regexes as well:


For example, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 would 
then also match openEHR-EHR-OBSERVATION.body_mass_index.v15 (or v10 
v11 etc. for example)


The example below 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2] 
means that not only v0, v1, v2 are valid, but also v10, v15, v27 to 
name a few.


the regex character class [0-2] matches only a single digit having the 
character values in the series 0-2, i.e. 0, 1, or 2.


Now that you mention it, I do seem to remember we specified a very long 
time ago that those regexes did have to be full validating ones. So that 
means using something more like


openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v(0|[1-9][0-9]*)(\.(0|[1-9][0-9]*)){0.2}

as the checker regex in CKM, and patterns like 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v.*, where 
the trailing '.*' matches anything, and the validator regex ensures it 
is only semver dotted version patterns.


- thomas


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

AW: Syntax for including archetypes in SLOTs, regardless of version

[Sebastian Garde]

Hi Silje, hi Thomas, hi all,

Whether the CKM validation errors from below are correct or bogus boils down to 
my question from before whether it is valid or not to just leave the version 
part out completely.
In my understanding the regex needs to be fully matched which means you cannot 
just leave it out completely – but it is not 100% clear from the specs as far 
as I can see (but see my excerpt from the ADL2 specs from before).

If we assume the regex does NOT need to be a full match, then the validation 
errors from CKM below are bogus of course.
But if partial matches are sufficient, this in turn requires some 
reinterpretation of existing regexes as well:
For example, openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 
would then also match openEHR-EHR-OBSERVATION.body_mass_index.v15 (or v10 v11 
etc. for example)

The example below 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2] means that 
not only v0, v1, v2 are valid, but also v10, v15, v27 to name a few.

A few archetypes in CKM (demographics mainly I think) have shortened this 
further to omit the openEHR-EHR- prefix. This currently turns up as a 
validation error in CKM as well, but in the partial match interpretation, it 
would be validit can be seen as  brief and elegant or regarded as confusing 
(especially with CLUSTERs from the EHR or DEMOGRAPHIC parts).

Personally, I think it is better to always require a full match here – this is 
more explicit and avoids unintended side-effects like the ones described above.
But most importantly, I think this needs to be clarified so that either that 
regex or one with additional open version regex can be used to describe what 
you want to model: any version is allowed (and a template can then tie this 
down).

Regards,
Sebastian
Von: openEHR-technical  Im Auftrag 
von Bakke, Silje Ljosland
Gesendet: Dienstag, 18. Dezember 2018 15:15
An: For openEHR technical discussions 
Betreff: RE: Syntax for including archetypes in SLOTs, regardless of version

Thanks Thomas,

The idea here is that we (likely in 99% of the cases) do want to include any 
version of the archetype, so the .v[0-2] variant isn’t relevant. The reason for 
this is that even though an archetype will have breaking changes from one major 
version to the next, the clinical concept will stay the same (or it should have 
a completely new ID). We don’t generally include archetypes based on their 
specific content at the time of inclusion, but on the clinical concept they 
represent.

If leaving the version part out completely is the correct way to leave 
versioning open when including archetypes, the CKM will need to change 
behaviours regarding this, since it currently rejects any archetype that does 
this:
[cid:image002.jpg@01D496F8.22699E70]

Regards,
Silje

From: openEHR-technical 
mailto:openehr-technical-boun...@lists.openehr.org>>
 On Behalf Of Thomas Beale
Sent: Tuesday, December 18, 2018 1:30 PM
To: 
openehr-technical@lists.openehr.org
Subject: Re: Syntax for including archetypes in SLOTs, regardless of version


Silje,

just as a technical note, the proper regex for including

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2.

is
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v(0|1|2)

or

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2]

to allow any version, just leave the version id part off entirely.

Note that different major versions of an archetype are technically different 
archetypes - i.e. they contain some breaking change. So whether allowing any 
major version of an archetype in a slot is a good default probably needs to be 
thought about carefully.

- thomas
On 18/12/2018 11:56, Bakke, Silje Ljosland wrote:
Hi,

Sebastian Garde and I had a brainstorm a while ago about how to handle 
inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY archetypes, or 
ENTRY archetypes within COMPOSITIONs or SECTIONs). At the moment this has to be 
noted explicitly (whether because of tooling or the specifications, I don’t 
know), so that in order to include for example all historical versions and 
specialisations of the Body Mass Index archetype in a COMPOSITION or SECTION, I 
have to include both 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2. If we ever make 
a v3 BMI archetype, this will then need to be added. This is a hassle when 
modelling archetypes in the first place, and it’s an even worse problem for 
governing them over time.

Based on the discussion I had with Sebastian, and with the kind help of some 
regex geeks on Twitter (you know who you are ), I propose one of the following 
as the default syntax for including any