Hi Erik, Thomas,
I think we need to address three issues separately here. The first is the archetype identification in CKM; the second is use of the draft archetypes and the third, the apparent lack of progress of archetype publication in the openEHR CKM. Archetype identification is ultimately a technical issue and one in which I normally don't have an opinion. Clearly it is useful from an implementation point of view to have unique IDs for each archetype and be able to determine diffs etc. However, from a non-technical point of view I believe that it is extremely helpful to clearly delineate between early/alpha/raw models and the mature ones that have been published, more than just by a 'status' or icon, although we need these too. I'm increasingly of the opinion that it will be helpful to have a common understanding that the first published version of an archetype in CKM is always known as v1.0, such that if we eventually find we are using v4.x we (the non-technical) can easily infer that this is a published archetype that has undergone 3 major updates. This is very valuable to the non-techies who will be using CKM. Otherwise we run the risk of having a release set that will contain wildly disparate version numbers and will infer no idea of the state/maturity of the archetypes To be honest, how we version the pre-published, currently known as 'draft' archetypes doesn't worry me - v0.x seems sensible in light of the previous statements but if you have a better way to approach it, I'm cool with that. Second point: use of the draft archetypes is an increasing issue. My general rule of thumb is 'don't' - because they are likely to change significantly by the time they are published. Do a diff on any of the published archetypes in CKM eg Blood Pressure - this is available by clicking on the 'Archetype History' icon on the toolbar in CKM . Check the 'Compare' box for the latest version of the archetype (on the left) and the first version (on the right); Select 'Compare archetypes' up the top. I think you will be surprised at the amount of change. So if anyone wants to use them, do so, but understanding the implications. In addition, further work in other domains has meant that modelling practice has matured and when we are able to revise these archetypes we might approach some quite differently. Draft is draft - please don't infer anything more from them. And this leads in to my related third point - the apparent lack of progress on the openEHR CKM re archetype publication. To me it is the proverbial 'elephant in the room'. I am somewhat embarrassed, but we have not been resourced to be able to continue this work directly in the volunteer openEHR space. The Ocean team did a lot of huge amount of work in the early days to get CKM up and running - Sam, Ian and Sebastian in particular - please don't underestimate it. That burned me out, and I had to cut back; now paid work has become busier - I have had to prioritise just like everyone else. I would love to see the openEHR CKM flourishing but the Foundation and the community needs to take it on and resource it, not just rely on Ocean resources to drive it or do the actual work. The Editorial resources are largely the bottleneck. It does take a particular personality and mindset, attention to detail and a considerable time commitment to become an Editor. Ian McNicoll and I took these roles on originally - we were learning and needed to establish some processes. This is still being fine-tuned but we are certainly in a position to mentor and train others who might be interested in taking on some Editorial responsibilities and have the time to do the job properly - it is never done in isolation, and the Editorial team approach is proving very successful. I have approached some individuals who I have thought might be suited but unfortunately most have baulked at the potential time commitment. We have had one Editor start but they have drifted off with other priorities. So we are absolutely open to more efforts and probably should have been making this more public for some time now. And the modelling efforts have not disappeared totally. There is active modelling and reviewing of archetypes happening in the Australian NEHTA CKM <http://dcm.nehta.org.au/ckm/> . Many of the archetypes in here have been drawn from the openEHR CKM and are now undergoing review and fine-tuning by stakeholders in Australia. NEHTA's approach to development of a clinical model library and publication of their specifications are found here <http://www.nehta.gov.au/connecting-australia/terminology-and-information/de tailed-clinical-models> . As we undertook this work with NEHTA we understood that the models published in their CKM would be able to be shared back to the international community - we are seeking confirmation of this, and hope to be able to update the openEHR models with these more mature ones soon. They are making good progress. Ultimately we need the community more active in the openEHR CKM - make it yours! Take the initiative. Volunteer as an Editor. Send us candidate archetypes. Tell your colleagues. Translate the published archetypes from inside CKM - simply select 'Translate archetypes' from within the 'Archetypes' menu. Interestingly one member has been busy translating archetypes into Arabic (Syrian) - both the draft and published. I did email them to advise they prioritise the published archetypes to ensure they realised that if the draft archetypes change, the translation will potentially need to be re-done, yet they keep coming;-) I'm still excited. the more I'm involved, the more I'm convinced that this work has great potential to make a real difference. Please join in. Cheers Heather From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale Sent: Thursday, 16 June 2011 6:25 PM To: For openEHR clinical discussions; Openehr-Technical Subject: Re: Archetype versioning on CKM Erik, thanks for the pointer. I like this set of rules. It is not too different from the current draft identification spec <http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/k nowledge_id_system.pdf> , and it would be easy to upgrade it to reflect the SemVer rules more faithfully. In the openEHR spec, major.minor.patch is referred to as version.revision.build. I seem to remember a discussion where we thought about renaming these. Do people think we should just stop mentioning version/revision/build with respect to archetypes? Or is it helpful to think of an openEHR 'revision' as being the same as a 'minor' version (personally I think yes)? The only thing I don't like that much is going back to putting 'draft' etc on the end of the version string, but I guess it is so common, that we should just go with the flow. If we can get a bit of consensus here, I can update this draft proposal to reflect it pretty quickly. - t On 14/06/2011 09:24, Erik Sundvall wrote: Hi! I came to think of this openEHR versioning discussion thread when I read about the Semantic Versioning initiative at http://semver.org/ I think the reasoning there is very appropriate also for openEHR artifacts. The problem for openEHR might be that there are so many seemingly usable archetypes in the openEHR-hosted CKM that are neither modified for a long time nor officially tagged as "published". It is understandable if it's tempting to start using them in real systems already now. After all the alternative is to reinvent the wheel locally and is that really better? Perhaps there should be a time limit on how long artifacts in the CKM can stay at a version below 1.0.0? Perhaps things would become easier if we break the link between an artifact having "published" status (as in being CRB approved) and the fact that an artifact has a version over 1.0.0. That way systems can start using archetypes past 1.0.0 knowing that non-compatible changes will have new major version numbers (irrespective of if they are published or not). Keeping approval "badges" like "ARB published", "NHS approved" or "WHO 2011 Certified" separate from technical version numbers might be a good idea anyway... (Example: the first "ARB published" version of Archetype X might be 2.4.2 and the next time it's awarded an "ARB published" badge again might be when the ARB has time to get around to looking at version 2.8.4 or 7.8.9). Likely, agencies will want to approve sets of artifacts on a regular basis like tagging a number of mutually compatible archetypes and templates as "NHS 2012-Q1 approved". The reasoning under #3 at http://semver.org/ (regarding 1.0.0beta1 < 1.0.0beta2 < 1.0.0.) might solve the "draft problem" discussed in this openEHR thread previously. (Provided that beta versions etc. don't get used/abused in live EHR systems.) The Semantic Versioning specification formalism is also machine processable in a nice way. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110621/ce9e00c3/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 1189 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110621/ce9e00c3/attachment.jpg>
