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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20110907/6485d33e/attachment.html>
