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 <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 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<mailto: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
