openEHR archetype publication sprint IS GO!
/Review+archetype+content There are also a couple of videos that provide an overview of the CKM and Reviewing an archetype: http://www.openehr.org/wiki/display/healthmod/Clinical+Knowledge+Manager+Video+Tutorials Looking forward to having you involved during the sprint. Please share this email with anyone who you think may be interested. Many thanks Heather Leslie Dr Heather Leslie MBBS FRACGP FACHI Director/Consulting Lead Ocean Informaticshttp://www.oceaninformatics.com/ Phone - +61 418 966 670 Skype - heatherleslie Twitter - @omowizard [16] [2013 Health-Partner-of-the-Year] -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/9a5cb048/attachment-0001.html -- next part -- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 5944 bytes Desc: image001.gif URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/9a5cb048/attachment-0002.gif -- next part -- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 5607 bytes Desc: image002.gif URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/9a5cb048/attachment-0003.gif
Archetype Naming proposals - do we need V0?
Hi all, Apologies for cross-posting in both clinical and technical but this does neatly cross that divide. We are getting close in CKM to implementing the ADL1.5 archetype naming /versioning rules proposed at *http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification* http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification mostly by adding the metadata to the ADL other_details section, which means we can carry the information in ADL 1.4 archetypes without disturbing current systems. These latest proposals are now very much in line with the de-facto standard SemVer 2.0 see http://semver.org which allows major revision minor revision patch build but one of the questions which remains controversial is whether to support a major revision of V0 (as allowed in SemVer). In Semver, V0 is allowed for very immature ?first draft? semantic artefacts/APIs prior to initial release but SemVer allows for any revision to appended with a pre-release modifier e.g. v2.0.0-alpha or v1.0.0-unstable This is recognised as meaning that the artefact is unstable and the version numbering cannot be relied on e.g to assert backward compatibility. In that sense v0.0.0 and v1.0.0-unstable are identical in terms of their ?stability? and lack of commitment to the versioning rules. So the question for us in the openEHR world is whether tooling should support v0.0.0, or simply use v1.0.0-unstable V0 Advantages 1. The archetype is clearly marked as immature 2. Full compliance with SemVer 3. Supported in current test build of CKM V0 Disadvantages 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change to support V0 2. Add another layer of complexity to the archetype naming/versioning rules 3. Question arises of whether / if to convert current draft V1 CKM archetypes to V0 with overhead of explanation to current users. 4. Adds complexity where V0 archetypes are being used within templates, when the archetype is published and needs to be updated to V1 within these templates. V1- Advantages 1. Compliant with SemVer 2. Does not need any changes to Archetype Editor. 3. Easier transition between draft and publication states when used within templates i.e does not need V0-v1 change V1- Disadvantages 1. Does not so clearly differentiate ?first draft? archetype from others Before a final decision is made, we are interested in feedback from the community on whether V0 should be implemented in CKM and other openEHR tools, although in practice V1- will do an identical job in terms of version number governance. Regards, Ian McNicoll Heather Leslie Sebastian Garde Thomas Beale -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/c3092858/attachment.html
Archetype Naming proposals - do we need V0?
Hi Ian, Personally I think V0 has significant costs in exchange for not so significant benefits. Semver compatibility would be nice, but nice is not worth the implementation cost for parser etc here. I don't know if V0 support would break things deep down in actual openEHR implementations but even that may be a possibility if there is a reg-ex sitting in some code that expects v1 as the starting point. The features in adl 1.5 would probably help provide a workaround to express the semantics that would otherwise be expressed with V0 Best regards Seref On Wed, Oct 1, 2014 at 11:23 AM, Ian McNicoll ian at mcmi.co.uk wrote: Hi all, Apologies for cross-posting in both clinical and technical but this does neatly cross that divide. We are getting close in CKM to implementing the ADL1.5 archetype naming /versioning rules proposed at *http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification* http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification mostly by adding the metadata to the ADL other_details section, which means we can carry the information in ADL 1.4 archetypes without disturbing current systems. These latest proposals are now very much in line with the de-facto standard SemVer 2.0 see http://semver.org which allows major revision minor revision patch build but one of the questions which remains controversial is whether to support a major revision of V0 (as allowed in SemVer). In Semver, V0 is allowed for very immature ?first draft? semantic artefacts/APIs prior to initial release but SemVer allows for any revision to appended with a pre-release modifier e.g. v2.0.0-alpha or v1.0.0-unstable This is recognised as meaning that the artefact is unstable and the version numbering cannot be relied on e.g to assert backward compatibility. In that sense v0.0.0 and v1.0.0-unstable are identical in terms of their ?stability? and lack of commitment to the versioning rules. So the question for us in the openEHR world is whether tooling should support v0.0.0, or simply use v1.0.0-unstable V0 Advantages 1. The archetype is clearly marked as immature 2. Full compliance with SemVer 3. Supported in current test build of CKM V0 Disadvantages 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change to support V0 2. Add another layer of complexity to the archetype naming/versioning rules 3. Question arises of whether / if to convert current draft V1 CKM archetypes to V0 with overhead of explanation to current users. 4. Adds complexity where V0 archetypes are being used within templates, when the archetype is published and needs to be updated to V1 within these templates. V1- Advantages 1. Compliant with SemVer 2. Does not need any changes to Archetype Editor. 3. Easier transition between draft and publication states when used within templates i.e does not need V0-v1 change V1- Disadvantages 1. Does not so clearly differentiate ?first draft? archetype from others Before a final decision is made, we are interested in feedback from the community on whether V0 should be implemented in CKM and other openEHR tools, although in practice V1- will do an identical job in terms of version number governance. Regards, Ian McNicoll Heather Leslie Sebastian Garde Thomas Beale ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/cb621a28/attachment.html
Archetype Naming proposals - do we need V0?
Thanks Seref, That is my feeling exactly. In practical terms, in an openEHR context, .V0 and .v1-unstable are identical. We do know that V0 breaks the old AE Eiffel parser. This is probably easily fixable but is an example of work that would need to be done. We are replicating the ADL 1.5 features as you suggest but in a way that does not change core archetype identification in ADL1.4, other than .V0. Perhaps the compromise is to defer the decision until tooling and systems are ready to use ADL1.5, by which time we will have experience with V1-unstable and have a better understanding of whether V0 is really necessary. Ian On 1 October 2014 11:34, Seref Arikan serefarikan at kurumsalteknoloji.com wrote: Hi Ian, Personally I think V0 has significant costs in exchange for not so significant benefits. Semver compatibility would be nice, but nice is not worth the implementation cost for parser etc here. I don't know if V0 support would break things deep down in actual openEHR implementations but even that may be a possibility if there is a reg-ex sitting in some code that expects v1 as the starting point. The features in adl 1.5 would probably help provide a workaround to express the semantics that would otherwise be expressed with V0 Best regards Seref On Wed, Oct 1, 2014 at 11:23 AM, Ian McNicoll ian at mcmi.co.uk wrote: Hi all, Apologies for cross-posting in both clinical and technical but this does neatly cross that divide. We are getting close in CKM to implementing the ADL1.5 archetype naming /versioning rules proposed at *http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification* http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification mostly by adding the metadata to the ADL other_details section, which means we can carry the information in ADL 1.4 archetypes without disturbing current systems. These latest proposals are now very much in line with the de-facto standard SemVer 2.0 see http://semver.org which allows major revision minor revision patch build but one of the questions which remains controversial is whether to support a major revision of V0 (as allowed in SemVer). In Semver, V0 is allowed for very immature ?first draft? semantic artefacts/APIs prior to initial release but SemVer allows for any revision to appended with a pre-release modifier e.g. v2.0.0-alpha or v1.0.0-unstable This is recognised as meaning that the artefact is unstable and the version numbering cannot be relied on e.g to assert backward compatibility. In that sense v0.0.0 and v1.0.0-unstable are identical in terms of their ?stability? and lack of commitment to the versioning rules. So the question for us in the openEHR world is whether tooling should support v0.0.0, or simply use v1.0.0-unstable V0 Advantages 1. The archetype is clearly marked as immature 2. Full compliance with SemVer 3. Supported in current test build of CKM V0 Disadvantages 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change to support V0 2. Add another layer of complexity to the archetype naming/versioning rules 3. Question arises of whether / if to convert current draft V1 CKM archetypes to V0 with overhead of explanation to current users. 4. Adds complexity where V0 archetypes are being used within templates, when the archetype is published and needs to be updated to V1 within these templates. V1- Advantages 1. Compliant with SemVer 2. Does not need any changes to Archetype Editor. 3. Easier transition between draft and publication states when used within templates i.e does not need V0-v1 change V1- Disadvantages 1. Does not so clearly differentiate ?first draft? archetype from others Before a final decision is made, we are interested in feedback from the community on whether V0 should be implemented in CKM and other openEHR tools, although in practice V1- will do an identical job in terms of version number governance. Regards, Ian McNicoll Heather Leslie Sebastian Garde Thomas Beale ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at freshehr.com Clinical modelling consultant freshEHR Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/20ca5421/attachment-0001.html
Archetype Naming proposals - do we need V0?
I tested v0 with LinkEHR editor and works just fine. I think that 'v1.0.0-unstable' has additional problems, such as deciding which words are allowed (e.g 'unstable', 'firstdraft', 'alpha', etc.), which means that tools have to be modified anyway. Arguably, is better to widen a range than to parse specific strings which end changing in the end. Also, adding this breaks all current v1 slots (related to my last question to the list) v0 is also fully compliant with SemVer, which means that in theory archetype identifiers won't need to be changed when we move to ADL1.5 (going with v1-unestable will need another change in the future) 2014-10-01 12:23 GMT+02:00 Ian McNicoll ian at mcmi.co.uk: Hi all, Apologies for cross-posting in both clinical and technical but this does neatly cross that divide. We are getting close in CKM to implementing the ADL1.5 archetype naming /versioning rules proposed at http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification mostly by adding the metadata to the ADL other_details section, which means we can carry the information in ADL 1.4 archetypes without disturbing current systems. These latest proposals are now very much in line with the de-facto standard SemVer 2.0 see http://semver.org which allows major revision minor revision patch build but one of the questions which remains controversial is whether to support a major revision of V0 (as allowed in SemVer). In Semver, V0 is allowed for very immature ?first draft? semantic artefacts/APIs prior to initial release but SemVer allows for any revision to appended with a pre-release modifier e.g. v2.0.0-alpha or v1.0.0-unstable This is recognised as meaning that the artefact is unstable and the version numbering cannot be relied on e.g to assert backward compatibility. In that sense v0.0.0 and v1.0.0-unstable are identical in terms of their ?stability? and lack of commitment to the versioning rules. So the question for us in the openEHR world is whether tooling should support v0.0.0, or simply use v1.0.0-unstable V0 Advantages 1. The archetype is clearly marked as immature 2. Full compliance with SemVer 3. Supported in current test build of CKM V0 Disadvantages 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change to support V0 2. Add another layer of complexity to the archetype naming/versioning rules 3. Question arises of whether / if to convert current draft V1 CKM archetypes to V0 with overhead of explanation to current users. 4. Adds complexity where V0 archetypes are being used within templates, when the archetype is published and needs to be updated to V1 within these templates. V1- Advantages 1. Compliant with SemVer 2. Does not need any changes to Archetype Editor. 3. Easier transition between draft and publication states when used within templates i.e does not need V0-v1 change V1- Disadvantages 1. Does not so clearly differentiate ?first draft? archetype from others Before a final decision is made, we are interested in feedback from the community on whether V0 should be implemented in CKM and other openEHR tools, although in practice V1- will do an identical job in terms of version number governance. Regards, Ian McNicoll Heather Leslie Sebastian Garde Thomas Beale ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
Archetype Naming proposals - do we need V0?
to current users. 4. Adds complexity where V0 archetypes are being used within templates, when the archetype is published and needs to be updated to V1 within these templates. V1- Advantages 1. Compliant with SemVer 2. Does not need any changes to Archetype Editor. 3. Easier transition between draft and publication states when used within templates i.e does not need V0-v1 change V1- Disadvantages 1. Does not so clearly differentiate ?first draft? archetype from others Before a final decision is made, we are interested in feedback from the community on whether V0 should be implemented in CKM and other openEHR tools, although in practice V1- will do an identical job in terms of version number governance. Regards, Ian McNicoll Heather Leslie Sebastian Garde Thomas Beale ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/7757fd2a/attachment.html
Archetype Naming proposals - do we need V0?
Hi Ian, I prefer V0, because it would be easier to adopt for other developers who do not know openEHR well. For parser implementation, 1.0.0-unstable is not a good design, because it is not clear that which is the later release amongs, unstable, testing, pre-release, release-candidate, draft, etc... I would suggest 0.9.9 instead of 1.0.0-unstable. We can revise the revision 0.9.9 after it released, to 0.9.9.9. or 0.9.9.99. Shinji 2014-10-01 19:23 GMT+09:00 Ian McNicoll ian at mcmi.co.uk: Hi all, Apologies for cross-posting in both clinical and technical but this does neatly cross that divide. We are getting close in CKM to implementing the ADL1.5 archetype naming /versioning rules proposed at http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification mostly by adding the metadata to the ADL other_details section, which means we can carry the information in ADL 1.4 archetypes without disturbing current systems. These latest proposals are now very much in line with the de-facto standard SemVer 2.0 see http://semver.org which allows major revision minor revision patch build but one of the questions which remains controversial is whether to support a major revision of V0 (as allowed in SemVer). In Semver, V0 is allowed for very immature ?first draft? semantic artefacts/APIs prior to initial release but SemVer allows for any revision to appended with a pre-release modifier e.g. v2.0.0-alpha or v1.0.0-unstable This is recognised as meaning that the artefact is unstable and the version numbering cannot be relied on e.g to assert backward compatibility. In that sense v0.0.0 and v1.0.0-unstable are identical in terms of their ?stability? and lack of commitment to the versioning rules. So the question for us in the openEHR world is whether tooling should support v0.0.0, or simply use v1.0.0-unstable V0 Advantages 1. The archetype is clearly marked as immature 2. Full compliance with SemVer 3. Supported in current test build of CKM V0 Disadvantages 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change to support V0 2. Add another layer of complexity to the archetype naming/versioning rules 3. Question arises of whether / if to convert current draft V1 CKM archetypes to V0 with overhead of explanation to current users. 4. Adds complexity where V0 archetypes are being used within templates, when the archetype is published and needs to be updated to V1 within these templates. V1- Advantages 1. Compliant with SemVer 2. Does not need any changes to Archetype Editor. 3. Easier transition between draft and publication states when used within templates i.e does not need V0-v1 change V1- Disadvantages 1. Does not so clearly differentiate ?first draft? archetype from others Before a final decision is made, we are interested in feedback from the community on whether V0 should be implemented in CKM and other openEHR tools, although in practice V1- will do an identical job in terms of version number governance. Regards, Ian McNicoll Heather Leslie Sebastian Garde Thomas Beale ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Archetype Naming proposals - do we need V0?
On 01/10/2014 11:23, Ian McNicoll wrote: In that sense v0.0.0 and v1.0.0-unstable are identical in terms of their 'stability' and lack of commitment to the versioning rules. Hi Ian, I don't think this is true. Firstly, the standard first possible version is v0.0.1 in any versioning environment I know of; secondly, the rules that I thought we were adopting have the following implications: * an uncontrolled archetype is uploaded for the first time, with version v0.N.P * at some point in the CKM environment is becomes v1.0.0, which is the first possible version at which it could be published o let's just say for argument's sake, it is first published at v1.2.0 * later, it goes back for revision, which means according to the state diagram in the latest draft http://www.openehr.org/wiki/download/attachments/5996562/artefact_lifecycle_versioning.png?version=3modificationDate=1412031989000api=v2, its next version has to be v1.2.1-unstable, i.e. one patch ahead of v1.2.0, the last published version o the meaning of this, as I understood it was that this version is 'at least' one patch level different from the version at the preceding patch value (v1.2.0), and also unstable, meaning that it might have more differences than jst that. * when it is ready for publishing, its version is adjusted, with the help of a diff tool, to the actual version it is required to be according to the type of diffs present. E.g. it might have to be v1.3.0. So the new vresion is either v1.3.0 or v1.3.0-rc.B, if the release candidate path is being used. It seems to me a no-brainer that we should support v0, because it's the clearest possible sign I can think of, that everyone already recognises, that indicates an artefact to be in early chaotic/uncontrolled development. So v0 should be the start version for any archetypes created new on someone's own machine, or any similar location. I'm not that worried about 'compliance with SemVer' - it's more that v0 is universally understood as indicating early chaotic development - it's a universal 'play with me, but don't trust me' sign. By that argument we also know that any version v1 or higher must be from a controlled governance environment like a CKM or similar. In terms of possible concerns listed below: * There is no doubt changes are needed to various tooling, but that's the situation anyway, e.g. to implement namespaces or other changes. * I think that the openEHR.org CKM archetypes identified for the industry sprint should stay at v1.x, and others that are of unknown quality should go to v0, which finally establishes what is clinically trustworthy and what is not. o You might possibly petition the clinical list to find out if anyone has ever used an archetype mooted for v0 renaming, in any production context. * I don't see the problem with v0 references in templates, since it's the same problem between any major version. An archetype .v0.x can't be assumed to be compatible with .v1.y - as for other major versions, we treat them technically as different archetypes. So either the template reference is v* (any major version you like) or it isn't, in which case it points to a known major version - v0, v1, v2 or other. o we should assume that future tools will make it easy to change these template references - it won't be difficult to do. I may still be missing something here, so this analysis is what seems sensible to me based on what I know today. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/cf9b9cc0/attachment.html
Archetype Naming proposals - do we need V0?
McNicoll Heather Leslie Sebastian Garde Thomas Beale ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at freshehr.com Clinical modelling consultant freshEHR Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/5e3acadc/attachment.html
Archetype Naming proposals - do we need V0?
Hi Thomas and all, On 01.10.2014 14:07, Thomas Beale wrote: On 01/10/2014 11:23, Ian McNicoll wrote: In that sense v0.0.0 and v1.0.0-unstable are identical in terms of their ?stability? and lack of commitment to the versioning rules. I don't think this is true. Firstly, the standard first possible version is v0.0.1 in any versioning environment I know of; secondly, the rules that I thought we were adopting have the following implications: * an uncontrolled archetype is uploaded for the first time, with version v0.N.P * at some point in the CKM environment is becomes v1.0.0, which is the first possible version at which it could be published o let's just say for argument's sake, it is first published at v1.2.0 The point when it becomes v1.0.0 is when the archetype is first published - i.e. the first published version will always be 1.0.0 and not v1.2.0 If the transition to v1.0.0 comes from v0.0.1[-unstable] or v1.0.0-unstable doesn't really matter - purely technically speaking the terms of stability and lack of commitment are the same for both 0.0.1[-unstable] and v1.0.0-unstable It seems to me a no-brainer that we should support v0, because it's the clearest possible sign I can think of, that everyone already recognises, that indicates an artefact to be in early chaotic/uncontrolled development. So v0 should be the start version for any archetypes created new on someone's own machine, or any similar location. Supporting it as part of the specs for uncontrolled/chaotic development is one thing and I agree. But what we are looking at here is that all CKM archetypes would have a v0 extension until they are first published (as v.1.0.0). Existing pre-publication CKM archetypes would be converted to have a v0 extension (either as a batch or one-by-one when each one is updated the next time) * I think that the openEHR.org CKM archetypes identified for the industry sprint should stay at v1.x, and others that are of unknown quality should go to v0, which finally establishes what is clinically trustworthy and what is not. That's not really an option unless you want to make this migration even more difficult. What you are suggesting requires two different sets of rules and someone needing to deciding which stays at v1 and which is converted to v0. I don't think it makes sense - either we use v0 to indicate pre-publication archetypes or we don't. * I don't see the problem with v0 references in templates, since it's the same problem between any major version. An archetype .v0.x can't be assumed to be compatible with .v1.y - as for other major versions, we treat them technically as different archetypes. So either the template reference is v* (any major version you like) or it isn't, in which case it points to a known major version - v0, v1, v2 or other. o we should assume that future tools will make it easy to change these template references - it won't be difficult to do. Sure, looking forward to tooling support on it, but realistically at the moment it is a pain that is not needed for the first publication if you go with v1 as a the initial major version. Sebastian -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/dd4685b1/attachment-0001.html
Archetype Naming proposals - do we need V0?
Group, NHS Scotland BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/d1d15b1d/attachment.html
Archetypes vs. Templates, archetype version in slots
On 30/09/2014 22:33, Ian McNicoll wrote: Hi Diego, I understand your point but I am not sure that slot naming is really working out as any of us envisaged. In the vast majority of cases where we specify an archetype pattern in the slot description we also leave the constraint open-ended because experience has shown us that too tightly coupling the parent and child leads to over-complication of dependencies and insufficient flexibility to cope with new use cases. In this respect the slot filling constraint acts as useful 'design guidance' i.e this is the sort of archetype we expect to be slotted in here but others (including V2 versions are allowed). it might be worth noting that slots and external references (i.e. direct references to archetypes, without the slot) have identifiers, like all nodes, in ADL/AOM 1.5, and also that external references are used ubiquitously in CIMI, which are all named (if you mean that they have 'meanings', i.e. id-code references). We also have to remember that 13606 and other archetype formalism users might have quite different styles of use, as CIMI does. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/9122c4fa/attachment.html
Archetype Naming proposals - do we need V0?
On 01.10.2014 14:04, Shinji KOBAYASHI wrote: Hi Ian, I prefer V0, because it would be easier to adopt for other developers who do not know openEHR well. For parser implementation, 1.0.0-unstable is not a good design, because it is not clear that which is the later release amongs, unstable, testing, pre-release, release-candidate, draft, etc... Actually, this is clearly defined by SemVer, see rule 11: 1.0.0-alpha 1.0.0-alpha.1 1.0.0-alpha.beta 1.0.0-beta 1.0.0-beta.2 1.0.0-beta.11 1.0.0-rc.1 1.0.0. But I don't think we would usually want to do this at all for unstable archetypes. They are just unstable, no guarantee whatsoever. If you want to have a specific one, you can always use the unique build id for that. Sebastian I would suggest 0.9.9 instead of 1.0.0-unstable. We can revise the revision 0.9.9 after it released, to 0.9.9.9. or 0.9.9.99. Shinji 2014-10-01 19:23 GMT+09:00 Ian McNicoll ian at mcmi.co.uk: Hi all, Apologies for cross-posting in both clinical and technical but this does neatly cross that divide. We are getting close in CKM to implementing the ADL1.5 archetype naming /versioning rules proposed at http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification mostly by adding the metadata to the ADL other_details section, which means we can carry the information in ADL 1.4 archetypes without disturbing current systems. These latest proposals are now very much in line with the de-facto standard SemVer 2.0 see http://semver.org which allows major revision minor revision patch build but one of the questions which remains controversial is whether to support a major revision of V0 (as allowed in SemVer). In Semver, V0 is allowed for very immature ?first draft? semantic artefacts/APIs prior to initial release but SemVer allows for any revision to appended with a pre-release modifier e.g. v2.0.0-alpha or v1.0.0-unstable This is recognised as meaning that the artefact is unstable and the version numbering cannot be relied on e.g to assert backward compatibility. In that sense v0.0.0 and v1.0.0-unstable are identical in terms of their ?stability? and lack of commitment to the versioning rules. So the question for us in the openEHR world is whether tooling should support v0.0.0, or simply use v1.0.0-unstable V0 Advantages 1. The archetype is clearly marked as immature 2. Full compliance with SemVer 3. Supported in current test build of CKM V0 Disadvantages 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change to support V0 2. Add another layer of complexity to the archetype naming/versioning rules 3. Question arises of whether / if to convert current draft V1 CKM archetypes to V0 with overhead of explanation to current users. 4. Adds complexity where V0 archetypes are being used within templates, when the archetype is published and needs to be updated to V1 within these templates. V1- Advantages 1. Compliant with SemVer 2. Does not need any changes to Archetype Editor. 3. Easier transition between draft and publication states when used within templates i.e does not need V0-v1 change V1- Disadvantages 1. Does not so clearly differentiate ?first draft? archetype from others Before a final decision is made, we are interested in feedback from the community on whether V0 should be implemented in CKM and other openEHR tools, although in practice V1- will do an identical job in terms of version number governance. Regards, Ian McNicoll Heather Leslie Sebastian Garde Thomas Beale ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- *Dr. Sebastian Garde* /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ Ocean Informatics Skype: gardeseb -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/cf40ece8/attachment-0001.html
Archetype Naming proposals - do we need V0?
Hi Diego,
On 01.10.2014 12:54, Diego Bosc? wrote:
I tested v0 with LinkEHR editor and works just fine.
That's great, although in this case I think you are actually being too
lenient if you strickly stick to the current spec which defines a
V_IDENTIFIER as
[a-zA-Z][a-zA-Z0-9_]+(-[a-zA-Z][a-zA-Z0-9_]+){2}\.[a-zA-Z][a-zA-Z0-9_]+(-[a-
zA-Z][a-zA-Z0-9_]+)*\.v*[1-9]*[0-9]*
v0 is also fully compliant with SemVer, which means that in theory
archetype identifiers won't need to be changed when we move to ADL1.5
(going with v1-unestable will need another change in the future)
v1.0.0-unstable is also fully compliant with SemVer - I don't understand
why this would require more changes in the future that v0 doesn't need?
Sebastian
2014-10-01 12:23 GMT+02:00 Ian McNicoll ian at mcmi.co.uk:
Hi all,
Apologies for cross-posting in both clinical and technical but this does
neatly cross that divide.
We are getting close in CKM to implementing the ADL1.5 archetype naming
/versioning rules proposed at
http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification
mostly by adding the metadata to the ADL other_details section, which means
we can carry the information in ADL 1.4 archetypes without disturbing
current systems.
These latest proposals are now very much in line with the de-facto standard
SemVer 2.0 see http://semver.org which allows
major revision
minor revision
patch
build
but one of the questions which remains controversial is whether to support a
major revision of V0 (as allowed in SemVer).
In Semver, V0 is allowed for very immature ?first draft? semantic
artefacts/APIs prior to initial release but SemVer allows for any revision
to appended with a pre-release modifier
e.g. v2.0.0-alpha or v1.0.0-unstable
This is recognised as meaning that the artefact is unstable and the version
numbering cannot be relied on e.g to assert backward compatibility.
In that sense v0.0.0 and v1.0.0-unstable are identical in terms of their
?stability? and lack of commitment to the versioning rules.
So the question for us in the openEHR world is whether tooling should
support v0.0.0, or simply use v1.0.0-unstable
V0 Advantages
1. The archetype is clearly marked as immature
2. Full compliance with SemVer
3. Supported in current test build of CKM
V0 Disadvantages
1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change to
support V0
2. Add another layer of complexity to the archetype naming/versioning rules
3. Question arises of whether / if to convert current draft V1 CKM
archetypes to V0 with overhead of explanation to current users.
4. Adds complexity where V0 archetypes are being used within templates, when
the archetype is published and needs to be updated to V1 within these
templates.
V1- Advantages
1. Compliant with SemVer
2. Does not need any changes to Archetype Editor.
3. Easier transition between draft and publication states when used within
templates i.e does not need V0-v1 change
V1- Disadvantages
1. Does not so clearly differentiate ?first draft? archetype from others
Before a final decision is made, we are interested in feedback from the
community on whether V0 should be implemented in CKM and other openEHR
tools, although in practice V1- will do an identical job in terms of version
number governance.
Regards,
Ian McNicoll
Heather Leslie
Sebastian Garde
Thomas Beale
___
openEHR-clinical mailing list
openEHR-clinical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
*Dr. Sebastian Garde*
/Dr. sc. hum., Dipl.-Inform. Med, FACHI/
Ocean Informatics
Skype: gardeseb
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/b942d273/attachment.html
Archetype Naming proposals - do we need V0?
+44 (0)775 209 7859 skype ianmcnicoll ian at freshehr.com Clinical modelling consultant freshEHR Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/a7077055/attachment.html
Archetype Naming proposals - do we need V0?
On 01/10/2014 13:31, Sebastian Garde wrote: It seems to me a no-brainer that we should support v0, because it's the clearest possible sign I can think of, that everyone already recognises, that indicates an artefact to be in early chaotic/uncontrolled development. So v0 should be the start version for any archetypes created new on someone's own machine, or any similar location. Supporting it as part of the specs for uncontrolled/chaotic development is one thing and I agree. But what we are looking at here is that all CKM archetypes would have a v0 extension until they are first published (as v.1.0.0). Existing pre-publication CKM archetypes would be converted to have a v0 extension (either as a batch or one-by-one when each one is updated the next time) that sounds right to me - is it a problem? * I think that the openEHR.org CKM archetypes identified for the industry sprint should stay at v1.x, and others that are of unknown quality should go to v0, which finally establishes what is clinically trustworthy and what is not. That's not really an option unless you want to make this migration even more difficult. What you are suggesting requires two different sets of rules and someone needing to deciding which stays at v1 and which is converted to v0. I don't think it makes sense - either we use v0 to indicate pre-publication archetypes or we don't. I would have thought that individual archetypes can have their version modified? I don't think the world minds if there is a period of a few months during the industry sprint when the rules are technical being broken. Once it's done, there will be 70+ archetypes with v1.x, and the rest with v0.x, and that will correctly represent the situation of the archetypes in CKM. Then for every mirroring, copy, and reuse of what's in openEHR.org CKM, there is no need to educate anyone on anything - it's obvious what the situation is. So we are only talking about a limited period of time where the rules are being broken (as they are right now in fact ;-) * I don't see the problem with v0 references in templates, since it's the same problem between any major version. An archetype .v0.x can't be assumed to be compatible with .v1.y - as for other major versions, we treat them technically as different archetypes. So either the template reference is v* (any major version you like) or it isn't, in which case it points to a known major version - v0, v1, v2 or other. o we should assume that future tools will make it easy to change these template references - it won't be difficult to do. Sure, looking forward to tooling support on it, but realistically at the moment it is a pain that is not needed for the first publication if you go with v1 as a the initial major version. well I think its a bigger danger, given the level of reuse of CKM archetypes, that the version ids wouldn't correct reflect the state of the archetypes. We could in theory revert everything that is not published to v0 right now, and i guess that is breaking the rules for less time. But there are still some dozens of fully reviewed and published archetypes that have to retain their v1.x version anyway. So I think the only question is to do with the industry sprint archetypes. How about doing this: * mark archetypes that have never been 'published' and are not in the industry sprint as v0.5.0 * mark the industry sprint archetypes as v1.0.0-unstable * leave currently published archetypes on v1.x, i.e. where they are today. If I receive a copy of archetypes marked like that in say the GitHub mirror, or through a different CKM, I don't need any further education, it's obvious what's going on. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/d527e646/attachment-0001.html
Archetype Naming proposals - do we need V0?
___ openEHR-technical mailing listopenEHR-technical at lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing listopenEHR-technical at lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- *Dr. Sebastian Garde* *Dr. sc. hum., Dipl.-Inform. Med, FACHI* Ocean Informatics Skype: gardeseb ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at freshehr.com Clinical modelling consultant freshEHR Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org ___ openEHR-technical mailing listopenEHR-technical at lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- *Dr. Sebastian Garde* *Dr. sc. hum., Dipl.-Inform. Med, FACHI* Ocean Informatics Skype: gardeseb ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at freshehr.com Clinical modelling consultant freshEHR Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/2123e600/attachment-0001.html
Archetype Naming proposals - do we need V0?
Hi Ian. I have read once SemVer, but it is still confusing about suffix. especially alpha.11 alpha.beta beta.1 sequence. This needs tricky grammar rule to parse. Hi Sebastian, I think revision history should be exclusive, even it is unstable version. Regards, Shinji 2014-10-01 21:26 GMT+09:00 Ian McNicoll ian at mcmi.co.uk: Hi Shinji, Can I suggest you read the semver.org specifications? Semver is now used pretty widely in systems and tooling (including the nodeJS Package Manager NPM). We have taken the - suffix directly from those specifications and in other respcts we are now following semver exactly so there should be open source parsers out there that can be used. Semver exists because we have to treat semantic specifications differently from normal software builds. In normal software alpha, beta, pre-release and indeed the numbering chosen do not need to have any computable significance. Windows 9 is only called Windows 9 for marketing reasons ,not because it represents a breaking change. My recent Yosemite Beta 3- Beta 4 update may make all sorts of breaking changes but is still a Beta and appears to be only a build different from the Developer Pre-release Yosemite candidate. When we are dealing with Semantic artefacts such as APIs or archetypes, the numbering scheme and suffixes have very specific meanings and rules, to do with backward compatibility. The -suffix is necessary to make it very clear that this is a pre-release artefact and that the normal versioning rules do not apply. What comes after the suffix does not really matter and The prime responsibility we have as archetype authors is to make sure that developers know whether they are working with a stable, published archetype which has followed the versioning rules, or an unstable archetype where those rules are temporarily suspended. It is impossible to do this clearly with a numbering schema alone which is why the - suffix is well-established in SemVer and the tools which use it. In normal circumstances unstable archetypes would never be used in production systems. Ian On 1 October 2014 13:04, Shinji KOBAYASHI skoba at moss.gr.jp wrote: Hi Ian, I prefer V0, because it would be easier to adopt for other developers who do not know openEHR well. For parser implementation, 1.0.0-unstable is not a good design, because it is not clear that which is the later release amongs, unstable, testing, pre-release, release-candidate, draft, etc... I would suggest 0.9.9 instead of 1.0.0-unstable. We can revise the revision 0.9.9 after it released, to 0.9.9.9. or 0.9.9.99. Shinji 2014-10-01 19:23 GMT+09:00 Ian McNicoll ian at mcmi.co.uk: Hi all, Apologies for cross-posting in both clinical and technical but this does neatly cross that divide. We are getting close in CKM to implementing the ADL1.5 archetype naming /versioning rules proposed at http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification mostly by adding the metadata to the ADL other_details section, which means we can carry the information in ADL 1.4 archetypes without disturbing current systems. These latest proposals are now very much in line with the de-facto standard SemVer 2.0 see http://semver.org which allows major revision minor revision patch build but one of the questions which remains controversial is whether to support a major revision of V0 (as allowed in SemVer). In Semver, V0 is allowed for very immature ?first draft? semantic artefacts/APIs prior to initial release but SemVer allows for any revision to appended with a pre-release modifier e.g. v2.0.0-alpha or v1.0.0-unstable This is recognised as meaning that the artefact is unstable and the version numbering cannot be relied on e.g to assert backward compatibility. In that sense v0.0.0 and v1.0.0-unstable are identical in terms of their ?stability? and lack of commitment to the versioning rules. So the question for us in the openEHR world is whether tooling should support v0.0.0, or simply use v1.0.0-unstable V0 Advantages 1. The archetype is clearly marked as immature 2. Full compliance with SemVer 3. Supported in current test build of CKM V0 Disadvantages 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change to support V0 2. Add another layer of complexity to the archetype naming/versioning rules 3. Question arises of whether / if to convert current draft V1 CKM archetypes to V0 with overhead of explanation to current users. 4. Adds complexity where V0 archetypes are being used within templates, when the archetype is published and needs to be updated to V1 within these templates. V1- Advantages 1. Compliant with SemVer 2. Does not need any changes to Archetype Editor. 3. Easier transition between draft and publication states when used within templates i.e does not need V0-v1 change
Archetype Naming proposals - do we need V0?
a copy of archetypes marked like that in say the GitHub mirror, or through a different CKM, I don't need any further education, it's obvious what's going on. - thomas ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/893e4adb/attachment.html
Archetype Naming proposals - do we need V0?
, or through a different CKM, I don't need any further education, it's obvious what's going on. Well, I for one, would not understand without your explanation that the difference between 0.5.0 and 1.0.0-unstable is that the one is in industry sprint and the other isn't. There are more logical ways to me to find this out (just look at the CKM project). Sebastian -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/fa01a433/attachment-0001.html
Archetype Naming proposals - do we need V0?
/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/63248d6e/attachment.html
Archetype Naming proposals - do we need V0?
archetypes without disturbing current systems. These latest proposals are now very much in line with the de-facto standard SemVer 2.0 see http://semver.org which allows major revision minor revision patch build but one of the questions which remains controversial is whether to support a major revision of V0 (as allowed in SemVer). In Semver, V0 is allowed for very immature ?first draft? semantic artefacts/APIs prior to initial release but SemVer allows for any revision to appended with a pre-release modifier e.g. v2.0.0-alpha or v1.0.0-unstable This is recognised as meaning that the artefact is unstable and the version numbering cannot be relied on e.g to assert backward compatibility. In that sense v0.0.0 and v1.0.0-unstable are identical in terms of their ?stability? and lack of commitment to the versioning rules. So the question for us in the openEHR world is whether tooling should support v0.0.0, or simply use v1.0.0-unstable V0 Advantages 1. The archetype is clearly marked as immature 2. Full compliance with SemVer 3. Supported in current test build of CKM V0 Disadvantages 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change to support V0 2. Add another layer of complexity to the archetype naming/versioning rules 3. Question arises of whether / if to convert current draft V1 CKM archetypes to V0 with overhead of explanation to current users. 4. Adds complexity where V0 archetypes are being used within templates, when the archetype is published and needs to be updated to V1 within these templates. V1- Advantages 1. Compliant with SemVer 2. Does not need any changes to Archetype Editor. 3. Easier transition between draft and publication states when used within templates i.e does not need V0-v1 change V1- Disadvantages 1. Does not so clearly differentiate ?first draft? archetype from others Before a final decision is made, we are interested in feedback from the community on whether V0 should be implemented in CKM and other openEHR tools, although in practice V1- will do an identical job in terms of version number governance. Regards, Ian McNicoll Heather Leslie Sebastian Garde Thomas Beale ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at freshehr.com Clinical modelling consultant freshEHR Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at freshehr.com Clinical modelling consultant freshEHR Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/ee63c85f/attachment-0001.html
Archetype Naming proposals - do we need V0?
within templates i.e does not need V0-v1 change V1- Disadvantages 1. Does not so clearly differentiate ?first draft? archetype from others Before a final decision is made, we are interested in feedback from the community on whether V0 should be implemented in CKM and other openEHR tools, although in practice V1- will do an identical job in terms of version number governance. Regards, Ian McNicoll Heather Leslie Sebastian Garde Thomas Beale ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Dr. Sebastian Garde Dr. sc. hum., Dipl.-Inform. Med, FACHI Ocean Informatics Skype: gardeseb ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at freshehr.com Clinical modelling consultant freshEHR Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/3ec26155/attachment.html
Archetype Naming proposals - do we need V0?
2014-10-01 15:35 GMT+02:00 Sebastian Iancu sebastian at code24.nl: Dear all, I'm surprise to see such a low analysis of the impact of changing v1 to v0 of the existing CKM archetypes. Even though they are not 'published', or are in logical 'draft' mode, they were conformant to openEHR standards for at least past 5 years or so. Some of them are used already in production environments for more than 2-3 years (at least in our case). Changing them now on CKM will break logical binding with already existing production data. This cost has to be eventually supported by industry implementers, and I can assure you this is not trivial, and it is giving the impression that openEHR standard is not reliable/stable enough. Sebastian, Although you are for sure right in your worries, that doesn't mean that current archetypes managed in CKM are safer. For many years most of the current v1 archetypes in CKM where in draft and that meant that they have been changing without changing their id. You can protect your systems if you check archetype correspondences not only by the archetype id but using something else such as their hash code. And in that case, changing to v0 should not mean any difference or additional problem. David -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es http://www.linkedin.com/in/davidmoner Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia - 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/fc487bf9/attachment.html
Licensing of specs and artifacts
Hi everyone, In light of the recent re-licensing of FHIRhttp://www.healthintersections.com.au/?p=2248 using the Creative Commons CC0 Public Domain Dedication as well as the discussion about licensing at the 2014 openEHR Roadmap Meetinghttp://www.openehr.org/wiki/display/oecom/September+2014+Roadmap+Meeting in Lillestr?m on September 16 and 17, I'd like to restart the discussion on licensing of openEHR specifications and artefacts (mainly archetypes, but also potentially templates and terminology sets). As of now, the specifications are licensed using the Creative Commons Attribution No-Derivativeshttp://creativecommons.org/licenses/by-nd/3.0/ (CC-B-ND) license, while the Creative Commons Attribution Share-Alikehttp://creativecommons.org/licenses/by-sa/3.0/ (CC-BY-SA) is used for artefacts. Several issues have been raised about this choice of licences. Feel free to add to this list, I'm bound to have forgot some issues: CC-BY-ND (for specs): ? Theoretically, a hostile takeover of the openEHR Foundation might leave the openEHR specs dead, as with the CC-BY-ND only the copyright holder (the Foundation) has the rights to modify them. A forkable license like for instance CC-BY-SA would solve this issue. Global registering of the openEHR trademark would keep any derivates to be branded as openEHR. CC-BY-SA (for artefacts): ? Commercial implementers might avoid using CC-BY-SA artefacts because the license requires any published modifications of the work to be licensed using the same license. This might lead implementers to believe the license would require them to license their entire software product as CC-BY-SA. There are several examples of CC-BY-SA works being used in copyrighted works, such as Wikipedia articles being used in newspapers, but this is probably reliant on a benign licensor, which any normal commercial company can't rely 100% on. The way I see it, this problem could be solved in one of two ways: o Use the CC-BY license, which retains the attribution clause, but doesn't require any derivative works to use the same license. This has the disadvantage of enabling proprietary tweaking of archetypes, which could potentially ruin interoperability. o Retain the CC-BY-SA license, but add an explicit clause that allows all implementers to use artefacts in closed-source, proprietary products with any license they like. Artefacts published by themselves, as standalone archetypes, templates or terminology sets would still be bound by the ShareAlike clause. This is supported by Creative Commons via the CC+https://wiki.creativecommons.org/CCPlus protocol. I realise these issues will ultimately be decided by the board of the openEHR Foundation, but if the community can come to some kind of consensus on this issue I would hope it'd send them a strong signal. Kind regards, Silje Ljosland Bakke Coordinator, National Editorial Board for Archetypes, National ICT Norway Adviser, RD dept, E-health section, Bergen Hospital Trust Tel. +47 40203298 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/5e2d6c81/attachment-0001.html
Archetype Naming proposals - do we need V0?
etc) depends on the need (see specifications). Sebastian Code24 On 10/1/2014 2:57 PM, Thomas Beale wrote: On 01/10/2014 13:31, Sebastian Garde wrote: It seems to me a no-brainer that we should support v0, because it's the clearest possible sign I can think of, that everyone already recognises, that indicates an artefact to be in early chaotic/uncontrolled development. So v0 should be the start version for any archetypes created new on someone's own machine, or any similar location. Supporting it as part of the specs for uncontrolled/chaotic development is one thing and I agree. But what we are looking at here is that all CKM archetypes would have a v0 extension until they are first published (as v.1.0.0). Existing pre-publication CKM archetypes would be converted to have a v0 extension (either as a batch or one-by-one when each one is updated the next time) that sounds right to me - is it a problem? * I think that the openEHR.org CKM archetypes identified for the industry sprint should stay at v1.x, and others that are of unknown quality should go to v0, which finally establishes what is clinically trustworthy and what is not. That's not really an option unless you want to make this migration even more difficult. What you are suggesting requires two different sets of rules and someone needing to deciding which stays at v1 and which is converted to v0. I don't think it makes sense - either we use v0 to indicate pre-publication archetypes or we don't. I would have thought that individual archetypes can have their version modified? I don't think the world minds if there is a period of a few months during the industry sprint when the rules are technical being broken. Once it's done, there will be 70+ archetypes with v1.x, and the rest with v0.x, and that will correctly represent the situation of the archetypes in CKM. Then for every mirroring, copy, and reuse of what's in openEHR.org CKM, there is no need to educate anyone on anything - it's obvious what the situation is. So we are only talking about a limited period of time where the rules are being broken (as they are right now in fact ;-) * I don't see the problem with v0 references in templates, since it's the same problem between any major version. An archetype .v0.x can't be assumed to be compatible with .v1.y - as for other major versions, we treat them technically as different archetypes. So either the template reference is v* (any major version you like) or it isn't, in which case it points to a known major version - v0, v1, v2 or other. o we should assume that future tools will make it easy to change these template references - it won't be difficult to do. Sure, looking forward to tooling support on it, but realistically at the moment it is a pain that is not needed for the first publication if you go with v1 as a the initial major version. well I think its a bigger danger, given the level of reuse of CKM archetypes, that the version ids wouldn't correct reflect the state of the archetypes. We could in theory revert everything that is not published to v0 right now, and i guess that is breaking the rules for less time. But there are still some dozens of fully reviewed and published archetypes that have to retain their v1.x version anyway. So I think the only question is to do with the industry sprint archetypes. How about doing this: * mark archetypes that have never been 'published' and are not in the industry sprint as v0.5.0 * mark the industry sprint archetypes as v1.0.0-unstable * leave currently published archetypes on v1.x, i.e. where they are today. If I receive a copy of archetypes marked like that in say the GitHub mirror, or through a different CKM, I don't need any further education, it's obvious what's going on. - thomas ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- *Dr. Sebastian Garde* /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ Ocean Informatics Skype: gardeseb -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/68c00eb0/attachment-0001.html
Archetype Naming proposals - do we need V0?
openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at freshehr.com Clinical modelling consultant freshEHR Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- *Dr. Sebastian Garde* /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ Ocean Informatics Skype: gardeseb -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/72ce209b/attachment-0001.html
Archetype Naming proposals - do we need V0?
to V1 within these templates. V1- Advantages 1. Compliant with SemVer 2. Does not need any changes to Archetype Editor. 3. Easier transition between draft and publication states when used within templates i.e does not need V0-v1 change V1- Disadvantages 1. Does not so clearly differentiate ?first draft? archetype from others Before a final decision is made, we are interested in feedback from the community on whether V0 should be implemented in CKM and other openEHR tools, although in practice V1- will do an identical job in terms of version number governance. Regards, Ian McNicoll Heather Leslie Sebastian Garde Thomas Beale ___ openEHR-technical mailing listopenEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing listopenEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicollian at freshehr.com Clinical modelling consultant freshEHR Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org ___ openEHR-clinical mailing listopenEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org ___ openEHR-clinical mailing listopenEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicollian at freshehr.com Clinical modelling consultant freshEHR Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org ___ openEHR-technical mailing listopenEHR-technical at lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing listopenEHR-technical at lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- *Dr. Sebastian Garde* *Dr. sc. hum., Dipl.-Inform. Med, FACHI* Ocean Informatics Skype: gardeseb ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at freshehr.com Clinical modelling consultant freshEHR Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/5f95892c/attachment-0001.html
openEHR archetype publication sprint IS GO!
] -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/d3239487/attachment-0001.html -- next part -- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 5944 bytes Desc: image001.gif URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/d3239487/attachment-0002.gif -- next part -- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 5607 bytes Desc: image002.gif URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/d3239487/attachment-0003.gif
