Hi Pablo - re- your important observation below. It was a difficult decision to go with a proprietary product to underpin the openEHR CKM, but at the time there was no apparent open source tool to provide the first stage functionality required. It is complex and expensive software to develop and maintain and, through the good offices of Sam and Ocean, we secured a free license to support the CKM repository, which we were thereby enabled to make quickly available for experimental use. Of course, open-source tools are not cost and resource neutral options, but it is certainly easier for many to engage along an open source pathway of development. That said, I believe that going with the proprietary CKM was a sensible decision at the time (it was and had to be Dipak's and mine, I should say, and in no way an Ocean decision). It has certainly been fully vindicated, in my eyes, by the free use that has been made of it, which we can observe day by day, within both the openEHR community and several cognate groupings, all over the world, exploring and working with the archetypes now residing in the public CKM repository that Ocean has generously created and maintained throughout, for the openEHR community.
Looking forward, Ian's link with Derek Hoy/Snowcloud and the offer he has made, is interesting and potentially a very useful new thread in the tooling agenda for openEHR. I don't think anyone imagines we are near to an ideal tooling environment to support effective clinical engagement with archetype/template/terminology development and support. The field will undoubtedly benefit from concerted and coordinated efforts to create new and better open source tooling in this area - a goal that is dear to many clinicians' hearts, I know - Tony Shannon and Dipak Kalra, to name but two! Forgive my inquisitiveness, Pablo, but I have just located and read your impressive CV and you seem exactly the right sort of person to join with others discussing here, in taking forward an initiative like that for the openEHR community. Once Sam and the new board (fully operational from October 1st) has given time for its current consultation about future governance to evolve into decisions about next steps, I very much hope there will be a way for you to do so. David I On 07/09/2011 19:03, pablo pazos 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20110907/5576ec2d/attachment.html>
