v[0-9][0-9] would also include v00-v09, which we don’t want.


From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> On Behalf 
Of Anastasiou A.
Sent: Tuesday, December 18, 2018 1:04 PM
To: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Subject: RE: Syntax for including archetypes in SLOTs, regardless of version

Hi Silje

I may not have got this right, but why not “v[0-9][0-9]?” (or, not care about 
what follows “body_mass_index”) ?

In other words, add a pattern to catch “any single (possibly double) digit 
version number” (?).

This looks like a straightforward case of “constrain to 

All the best
Athanasios Anastasiou

From: openEHR-technical 
 On Behalf Of Bakke, Silje Ljosland
Sent: 18 December 2018 11:57
To: For openEHR technical discussions 
Subject: Syntax for including archetypes in SLOTs, regardless of version


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_]+)*\.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 version of a given archetype in a SLOT:

  1.  An explicit regex for the version number, for example 
  2.  Leaving out entirely the version part of the expression, for example 

I think it should still be possible to include a specific version of the 
archetype, but that this should not be the default behaviour of the tools.

I don’t particularly care if one of these two suggestions, or an entirely 
different solution, is adopted, but this issue has to be decided and 
implemented soon.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no<http://arketyper.no/> / Twitter: 

openEHR-technical mailing list

Reply via email to