Well Ian, even having perfect versioning/revisioning rules is useless if users just keep updating and modifying the archetypes without changing version numbers, status, etc. I think CKM has one big challenge: We want it to be the reference repository for archetypes, but at the same time we are discouraging the use of most of the currently available archetypes. Should we do a CKM 'archetype cleanup' as soon as test repositories arise?
PD: The day I see one v2 archetype on the CKM I will be happier :) 2011/9/8 Ian McNicoll <Ian.McNicoll at oceaninformatics.com>: > Hi Pablo, > > I think we do have very good versioning / revisioning rules and CKM > has implemented these within its comparator function when we upload a > modified archetype. > > There is active work exploring how to tighten up the governance > issues, especially around namespaces but I think we are pretty close > to having this worked out. > > Once you consider the potential dependencies of templates, archetypes, > specialisations and termsets, there are some interesting challenges > ahead in understanding how best to keep good blend of agile > development and the kind of stability that vendors and other projects > will require. > > I think Release Sets will play an important part here by giving > different projects a fixed, coherent set of artefacts to work with, > even as the leading-edge development moves on. I think it is much more > likely that connections between repositories will be through Release > Sets than by full 'current' access. We are starting to look at this > issue of 'federation' in CKM but current thinking is that a simple > view of, or reference to, assets in another repository is really not > going to help real development very much. The key issue is how to > request and acheive change in a non-native artefact, and how to handle > the inevitable mismatch in development cycles between native and > non-native artefacts. > > Although the Ocean CKM is a pretty unique product for now, I am sure > alternatives, quite possibly open source, will emerge but as David > Ingram suggested this kind of functionality is complex and will take > time to develop. > > I would be much more interested in starting with a light-weight > community repository tool, without the burden of tight governance > requirements of a CKM-like application. I think this can get started > with relatively low development requirements based around Derek's > Snowcloud template tool. > > Ian > > 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 > openEHR Clinical Knowledge Editor www.openehr.org/knowledge > Honorary Senior Research Associate, CHIME, UCL > BCS Primary Health Care ?www.phcsg.org > > > > > On 7 September 2011 19:03, pablo pazos <pazospablo at hotmail.com> wrote: >> Hi, >> >> I agree that we need localized CKM's and clear governace rules technical >> (e.g. free&open tools, common API) and behavioral (e.g. versioning). >> >> I've answered this on other thread, I think this is the correct one: >> ------------ >> Hi David, >> >> You mention a big issue: we want to build local archetype and template >> repositories but we don't have the tools to do it in a coordinated way with >> the openEHR CKM. >> >> I think it would be great to have an open & free CKM to start with, and a >> common generic API to connect our local CKMs to regional CKMs and regional >> CKMs to the global CKM in a controlled way (in this scenario the versioning >> of artefacts is a big issue and I think it is not solved at the tool level >> yet). >> >> AFAIK the to install the global CKM we have to buy some licenses. >> ------------ >> >> -- >> Kind regards, >> Ing. Pablo Pazos Guti?rrez >> LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez >> Blog: http://informatica-medica.blogspot.com/ >> Twitter: http://twitter.com/ppazos >> >>> From: yampeku at gmail.com >>> Date: Wed, 7 Sep 2011 10:36:45 +0200 >>> Subject: Re: openEHR Transition: Community Knowledge repository >>> To: openehr-clinical at openehr.org >>> >>> I completely agree with you, but if we do that, we need a very clear >>> governance and versioning policy (and be willing to stick to it). >>> And define the minimal access API as soon as possible ;) >>> >>> >>> 2011/9/7 Ian McNicoll <Ian.McNicoll at oceaninformatics.com>: >>> > Hi Diego, >>> > >>> > I am strongly in favour of establishing a community-led/ >>> > lightly-governed clinical knowledge repository as suggested by Shinji, >>> > particularly if we can arrange some sort of federation between this >>> > and a number of locally or regionally managed repositories. >>> > >>> > However, these must sit quite separately from the openEHR CKM or any >>> > other nationally governed repositories. I would anticipate that many >>> > of the archetypes from this repositories would find there way into the >>> > governed CKMs but Shinji's comments about needing the freedom to >>> > experiment outside the necessary restrictions of CKM are absolutely >>> > correct. I appreciate that many of the current archetypes are still in >>> > draft and as you say 'use at your own risk' but we are trying to avoid >>> > having competing representations in this 'interoperability' space. >>> > That is not to imply that Shinji's work is poor or incorrect, just >>> > that it often uses different design patterns and approaches. If we >>> > adopt a free-for-all approach to CKM now, it will become impossible to >>> > resolve later. However, IMO, this also makes the establishment of a >>> > community repository even more essential so that some of the excellent >>> > ideas that Shinji and others are developing have a place to grow and >>> > flourish. >>> > >>> > I would welcome suggestions for a repository framework e.g GitHub that >>> > might support a community repository, particularly one that supports a >>> > distributed/federated approach. >>> > >>> > Snowcloud have an open-source collaborative tool that has been used by >>> > both ICNP (nursing terminology) and Wm Goosen's Netherland's DCM group >>> > as a front end for their collaborative working. Derek Hoy, who runs >>> > Snowcloud, would be happy to assist in setting up an instance for >>> > openEHR, though we would have to consider hosting etc. >>> > >>> > This would not be trying to compete with the governed CKMs, rather >>> > allow more free-flowing collaboration and early work-up of ideas. The >>> > Foundation should, I believe, be prepared to support and endorse this >>> > effort but I would expect it to be almost wholly community-driven and >>> > governed. >>> > >>> > Further thoughts would be very welcome. >>> > >>> > 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 >>> > openEHR Clinical Knowledge Editor www.openehr.org/knowledge >>> > Honorary Senior Research Associate, CHIME, UCL >>> > BCS Primary Health Care ?www.phcsg.org >>> > >>> > >>> > >>> > >>> > On 6 September 2011 17:24, Diego Bosc? <yampeku at gmail.com> wrote: >>> >> Good to hear about you! I hope everything is ok in Japan. >>> >> I would encourage you to put the archetypes on the CKM anyway, as I >>> >> would >>> >> say that most of the available archetypes on the repository are in the >>> >> same situation as your archetypes (the implicit 'use under your own >>> >> responsibility') >>> >> >>> >> 2011/9/6 Shinji KOBAYASHI <skoba at moss.gr.jp>: >>> >>> Hi All, >>> >>> >>> >>> I have been suffered by sever jet lag after long trip, while I have >>> >>> been thinking about this new white >>> >>> paper and our local activity. I could not find such localisation >>> >>> activity in this white paper, but please >>> >>> consider and mention about such local activity. >>> >>> I would like to show these two proposals. >>> >>> 1) Local activity support. >>> >>> As a global standard, localisation to each country or area is >>> >>> necessary. ?My three years experience >>> >>> to implementation of the Ruby codes, archetypes and template, we need >>> >>> lots of localisation efforts >>> >>> for Japanese use. I think this experience may be available to localise >>> >>> for other countries. East Asian >>> >>> countries people is keen in openEHR development and their engagements >>> >>> are promising for their >>> >>> health care. >>> >>> >>> >>> 2) ?Premature artefact repository >>> >>> CKM provides us well-considered archetypes and templates. This is a >>> >>> great knowledge resource >>> >>> for mankind. However, to incubate archetype as a common concept takes >>> >>> long time like vintage wine. >>> >>> On the other hand, I need more agile movement for daily development. I >>> >>> have developed about 50 >>> >>> archetypes and 6 templates. These artefacts are still premature to >>> >>> evaluate on CKM, but I would >>> >>> like to discuss about my artefacts on line with many people. Yes, it >>> >>> will be a 99% junk repository, >>> >>> but 1% diamond would be a precious for our community. As Major league >>> >>> cannot exist without >>> >>> minor leagues, I think CKM needs such minor artefacts groups. >>> >>> I am preparing to share them on GitHub, because anyone can use >>> >>> repository for each use by fork >>> >>> and merge request is useful. >>> >>> I think the licence of this repository would adopt CC-BY-SA, is this >>> >>> OK, Erik and Ian? >>> >>> >>> >>> Cheers, >>> >>> Shinji KOBAYASHI(in Japan, a path of typhoon.) >>> >>> >>> >>> 2011/9/6 Erik Sundvall <erik.sundvall at liu.se>: >>> >>>> Thanks for replying Sam! >>> >>>> >>> >>>> Erik Wrote (to openEHR-technical at openehr.org): >>> >>>>>> Was that whitepaper formally ratified by the new board, or by the >>> >>>>>> old board, >>> >>>>>> or is it's current state just a suggestion by Sam? >>> >>>> >>> >>>> On Mon, Sep 5, 2011 at 17:58, Sam Heard >>> >>>> <sam.heard at oceaninformatics.com> wrote: >>> >>>>> [Sam Heard] The whitepaper was ratified by the participants in the >>> >>>>> planning >>> >>>>> process, the current Board (Profs. Kalra, Ingram and myself) and the >>> >>>>> new >>> >>>>> Transitional Board. >>> >>>> >>> >>>> This is a bit worrying for the period until a broader board can be >>> >>>> elected. I was hoping that somebody within the new board would be >>> >>>> interested enough and have time to take licensing issues and >>> >>>> community >>> >>>> feedback seriously, let's hope that the board does a bit more >>> >>>> research >>> >>>> and community dialogue before ratifying a new version of this >>> >>>> whitepaper. Could somebody from the board please confirm that you'll >>> >>>> take a serious look at this in the near future? >>> >>>> >>> >>>> Erik wrote: >>> >>>>> What is the mandate period of the transitional board? When will the >>> >>>>> suggested new structure with an elected board start? >>> >>>> >>> >>>> On Mon, Sep 5, 2011 at 17:58, Sam Heard >>> >>>> <sam.heard at oceaninformatics.com> wrote: >>> >>>>> [Sam Heard] I for one am very happy to express a date for elections >>> >>>>> if >>> >>>>> organisations embrace these arrangements. Clearly if there is no >>> >>>>> interest in >>> >>>>> participating from industry or organisations then we would have to >>> >>>>> think >>> >>>>> again. I suspect we will then move to election of the Board by >>> >>>>> Members but >>> >>>>> it is our wish to provide a means of determining the governance for >>> >>>>> openEHR?s key sponsors. The aim is to balance the Members with >>> >>>>> governance >>> >>>>> from the funders and sponsors. Some may prefer a democratic >>> >>>>> organisation top >>> >>>>> to bottom; we do not think this will achieve the best results. >>> >>>> >>> >>>> So there is no absolute end date set. :-( >>> >>>> >>> >>>> The "if organisations embrace these arrangements" part is worrying, >>> >>>> especially since we already have seen failed attempts at getting >>> >>>> buy-in from "organisations". >>> >>>> >>> >>>> Can't you set an absolute latest date (e.g. at the very latest >>> >>>> December 31, 2012) when the new arrangements will start no matter if >>> >>>> big organisations have made use of the introductory offer of buying a >>> >>>> position in the board? If not, we risk having an interim board >>> >>>> forever, and we really don't need any more delays in the journey >>> >>>> towards community-driven governance. If you get buy-in from the >>> >>>> number >>> >>>> of big players you want before that absolute end date then there >>> >>>> would >>> >>>> be nothing stopping you from doing the transition earlier than the >>> >>>> "latest date". >>> >>>> >>> >>>> Erik wrote: >>> >>>>> The thoughts behind the third point in the "Principles of licencing" >>> >>>>> are >>> >>>>> understandable, but as stated over and over again, e.g. at... >>> >>>>> >>> >>>>> http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal?focusedCommentId=13041696#comment-13041696 >>> >>>>> ...the SA part of CC-BY-SA won't help against copyright and patent >>> >>>>> abuse. >>> >>>>> Only fighting possible upcoming bad patents in particular and bad >>> >>>>> patent >>> >>>>> laws in general might save the openEHR community form patent abuse. >>> >>>> >>> >>>> On Mon, Sep 5, 2011 at 17:58, Sam Heard >>> >>>> <sam.heard at oceaninformatics.com> wrote: >>> >>>>> [Sam Heard] If this is true then the SA part of the license has no >>> >>>>> value. If >>> >>>>> this is true then I have not heard this before. >>> >>>> >>> >>>> I am very glad if you might have started to see the lack of value in >>> >>>> SA for archetypes. Using pure CC-BY (for both archetypes AND >>> >>>> specifications) would make the first six points under "Principles of >>> >>>> licensing" unnecessary and reduce confusion. >>> >>>> >>> >>>> At the same time I am very worried about the totally amazing >>> >>>> information blocking filter you must have built in if you have "not >>> >>>> heard" this argument before. Several people have been questioning >>> >>>> your >>> >>>> reasoning on this very point for years! >>> >>>> >>> >>>> On the official openEHR-wikipage set up for this particular question >>> >>>> when community feedback was requested... >>> >>>> >>> >>>> http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal >>> >>>> ...you have several people (including Tom Beale) in clear text saying >>> >>>> that CC-BY-SA will NOT protect against patent attacks. (Scroll down >>> >>>> to >>> >>>> the heading "Discussion summaries regarding CC-BY versus CC-BY-SA for >>> >>>> content models".) >>> >>>> >>> >>>> How on earth could you and the entire board miss that when writing up >>> >>>> the draft for the transition whitepaper and when making earlier >>> >>>> license decisions? >>> >>>> >>> >>>> One thing that however is very efficient in fighting patent trolls is >>> >>>> "prior art". Thus one of the best protections regarding archetypes >>> >>>> etc. is to have as much as possible of development completely public, >>> >>>> indexed and archived by trusted sites (like http://www.archive.org/). >>> >>>> This means always making sure to allow enough search engines and not >>> >>>> requiring login in order to read archetype discussions and thoughts >>> >>>> in >>> >>>> development repositories (things like the CKM). The earlier date the >>> >>>> mention of an idea can be traced back to, the more patent claims it >>> >>>> will protect against. >>> >>>> >>> >>>> Best Regards, >>> >>>> Erik Sundvall >>> >>>> erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: >>> >>>> +46-13-286733 >>> >>>> >>> >>>> P.s. I agree with Pablo & Diego that we need to talk about >>> >>>> communication between several repositories, not just discuss the >>> >>>> current openEHR-hosted CKM. >>> >>>> >>> >>>> _______________________________________________ >>> >>>> openEHR-technical mailing list >>> >>>> openEHR-technical at openehr.org >>> >>>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >>> >>>> >>> >>> >>> >>> _______________________________________________ >>> >>> openEHR-technical mailing list >>> >>> openEHR-technical at openehr.org >>> >>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >>> >>> >>> >> >>> >> _______________________________________________ >>> >> openEHR-technical mailing list >>> >> openEHR-technical at openehr.org >>> >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >>> >> >>> > >>> > _______________________________________________ >>> > openEHR-clinical mailing list >>> > openEHR-clinical at openehr.org >>> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical >>> > >>> >>> _______________________________________________ >>> openEHR-clinical mailing list >>> openEHR-clinical at openehr.org >>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical >> >> _______________________________________________ >> openEHR-clinical mailing list >> openEHR-clinical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical >> > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical >
