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

[Bakke, Silje Ljosland]

Amen.

So, do we have a conclusion that toolmakers can reference? Can we document this 
somewhere in the specs or elsewhere?

Regards,
Silje

From: openEHR-technical  On Behalf 
Of Heather Leslie
Sent: Wednesday, December 19, 2018 7:22 AM
To: For openEHR technical discussions 
Subject: RE: Syntax for including archetypes in SLOTs, regardless of version

Hi everyone,

In our modelling, it is safe to assume that the latest version of an archetype 
is the best candidate on offer for anyone using an archetype and filling a SLOT 
for the first time. Options for use of previous versions may be useful for 
implementers who have older versions in their current systems and don’t want 
two different versions or to update all their systems to the latest version.

I totally agree that from a governance point of view SLOT inclusions won’t need 
to specify a version in 99% of cases. However in some situations it 
theoretically may be appropriate to fix a version in place in a specific SLOT. 
In fact I can’t think of a use case YET where we need to specify a certain 
version, but no doubt this will occur at some time in the near future.

In all our modelling it seems that as soon as we limit our options one way or 
another we discover a use case that breaks our most recently made rule! 
Murphy’s law?

So we want to have our cake and eat it too – default to any or all versions of 
an archetype, with the option to specify one (or maybe even multiple) if needs 
be. Same theory applies to exclusions in a SLOT as well.

The governance overheads of currently specifying v0 and/or v1 and/or v2  will 
only increase as time goes on and at present as CKAs we have people upset that 
v0 is specifically included but that archetype has subsequently been published 
as v1. They want to see v1 specifically included. They don’t understand the 
theory behind it, not unreasonably, that as long as no archetypes (and 
versions) are excluded in a specific way, even if the SLOT suggests a v0 as an 
inclusion, it technically doesn’t stop a v1 being inserted in there. So the 
inclusion of all versions also has an important design guidance function as 
well. Newbies may not understand that if an archetype of the appropriate class 
is no actively excluded, then any or all of the archetypes of that class are 
technically valid for adding into a template.

Regards

Heather

From: openEHR-technical 
mailto:openehr-technical-boun...@lists.openehr.org>>
 On Behalf Of Bakke, Silje Ljosland
Sent: Wednesday, 19 December 2018 1:15 AM
To: For openEHR technical discussions 
mailto:openehr-technical@lists.openehr.org>>
Subject: 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:image001.jpg@01D4A69F.B91D67F0]

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 

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

[Heather Leslie]

Hi everyone,

In our modelling, it is safe to assume that the latest version of an archetype 
is the best candidate on offer for anyone using an archetype and filling a SLOT 
for the first time. Options for use of previous versions may be useful for 
implementers who have older versions in their current systems and don’t want 
two different versions or to update all their systems to the latest version.

I totally agree that from a governance point of view SLOT inclusions won’t need 
to specify a version in 99% of cases. However in some situations it 
theoretically may be appropriate to fix a version in place in a specific SLOT. 
In fact I can’t think of a use case YET where we need to specify a certain 
version, but no doubt this will occur at some time in the near future.

In all our modelling it seems that as soon as we limit our options one way or 
another we discover a use case that breaks our most recently made rule! 
Murphy’s law?

So we want to have our cake and eat it too – default to any or all versions of 
an archetype, with the option to specify one (or maybe even multiple) if needs 
be. Same theory applies to exclusions in a SLOT as well.

The governance overheads of currently specifying v0 and/or v1 and/or v2  will 
only increase as time goes on and at present as CKAs we have people upset that 
v0 is specifically included but that archetype has subsequently been published 
as v1. They want to see v1 specifically included. They don’t understand the 
theory behind it, not unreasonably, that as long as no archetypes (and 
versions) are excluded in a specific way, even if the SLOT suggests a v0 as an 
inclusion, it technically doesn’t stop a v1 being inserted in there. So the 
inclusion of all versions also has an important design guidance function as 
well. Newbies may not understand that if an archetype of the appropriate class 
is no actively excluded, then any or all of the archetypes of that class are 
technically valid for adding into a template.

Regards

Heather

From: openEHR-technical  On Behalf 
Of Bakke, Silje Ljosland
Sent: Wednesday, 19 December 2018 1:15 AM
To: For openEHR technical discussions 
Subject: 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@01D497BE.ED038BC0]

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 

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

[Bakke, Silje Ljosland]

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:image001.jpg@01D496E4.7F780930]

Regards,
Silje

From: openEHR-technical  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 version of a given archetype in a SLOT:

  1.  An explicit regex for the version number, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v([0]|[1-9][0-9]*)
  2.  Leaving out entirely the version part of the expression, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*

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 / Twitter: 
@arketyper_no




___

openEHR-technical mailing list

openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Thomas Beale
Principal, Ars Semantica
Consultant, ABD Project, Intermountain 
Healthcare
Management Board, Specifications Program Lead, openEHR 
Foundation
Chartered IT Professional Fellow, BCS, British Computer 
Society
Health IT blog | Culture 
blog | The Objective 
Stance
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

[Thomas Beale]

For reference, these are the various regexes I use in the ADL workbench 
.



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

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

[Karsten Hilbert]

On Tue, Dec 18, 2018 at 01:17:38PM +0100, Karsten Hilbert wrote:

> > In other words, add a pattern to catch “any single (possibly double) digit 
> > version number” (?).
> 
>   \d{1,2}

Ah, sorry, was misled by *number*.

Karsten
-- 
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

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

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

[Thomas Beale]

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 version 
of a given archetype in a SLOT:


 1. An explicit regex for the version number, for example

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v([0]|[1-9][0-9]*)
 2. Leaving out entirely the version part of the expression, for
example openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*

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 / Twitter: 
@arketyper_no 



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

--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Project, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 
 | The Objective Stance 

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

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

[Karsten Hilbert]

On Tue, Dec 18, 2018 at 12:09:56PM +, Bakke, Silje Ljosland wrote:

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

\d{1,2}

Karsten
-- 
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

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

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

[Bakke, Silje Ljosland]

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

Regards,
Silje

From: openEHR-technical  On Behalf 
Of Anastasiou A.
Sent: Tuesday, December 18, 2018 1:04 PM
To: For openEHR technical discussions 
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 
openEHR-EHR-OBSERVATION\.body_mass_index”.

All the best
Athanasios Anastasiou




From: openEHR-technical 
mailto:openehr-technical-boun...@lists.openehr.org>>
 On Behalf Of Bakke, Silje Ljosland
Sent: 18 December 2018 11:57
To: For openEHR technical discussions 
mailto:openehr-technical@lists.openehr.org>>
Subject: Syntax for including archetypes in SLOTs, regardless of version

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 version of a given archetype in a SLOT:

  1.  An explicit regex for the version number, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v([0]|[1-9][0-9]*)
  2.  Leaving out entirely the version part of the expression, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*

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 / Twitter: 
@arketyper_no

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

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

[Anastasiou A .]

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 
openEHR-EHR-OBSERVATION\.body_mass_index”.

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

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 version of a given archetype in a SLOT:

  1.  An explicit regex for the version number, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v([0]|[1-9][0-9]*)
  2.  Leaving out entirely the version part of the expression, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*

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 / Twitter: 
@arketyper_no

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