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 >
