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 <http://arketyper.no/>/ Twitter:
@arketyper_no <https://twitter.com/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 <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog
<http://wolandsothercat.net/> | The Objective Stance
<https://theobjectivestance.net/>
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
