than is about business needs On Fri, Sep 9, 2011 at 1:11 PM, Ian McNicoll < Ian.McNicoll at oceaninformatics.com> wrote:
> Hi Jussara, > > It is not really a technical problem. The platform that CKM is built > on will actually support federation fairly easily. The challenge is in > knowing what and how to federate, which itself is much more about > governance of the assets and how cross-repository change requests and > other communications will work. > > We are right on the cusp of having to do this for some CKM instances, > and while hooking up a CKM with a non-CKM repository will definitely > bring some technical challenges, our feeling right now is that these > are fairly easily resolved once we get a better picture of the real > requirements. > > As always, the technology is the easy bit. > > 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 9 September 2011 16:44, jussara rotzsch <jussara.macedo at gmail.com> > wrote: > > Em 09/09/2011 12:24, Ian McNicoll escreveu: > >>> What I meant was that: if we, in the future, have several CKMs around > the > >>> world, maybe forming a hierarchy or not, we need a clear specification > of > >>> the versioning rules for this distributed CKM.I don't know for sure if > the versioning issue is solved or not, or if it's > >>> solved only at the CMK or if it's part of the specifications. What we > need > >>> is the latter. > >> [IAN] It is nearly solved > >> Not so long ago there was a very interesting discussion about that: > >> http://www.openehr.org/mailarchives/openehr-technical/msg05797.html > >>> > >>>> 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. > >>>> > >>> I would love to see that. Can you point me to some information or > >>> discussions about those issues? > >> [IAN] Coming soon! > >>>> 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. > >>>> > >>> Is this a closed discussion? I would like to help. > >> [IAN] Thanks. Once we get some coherent thoughts/ proposals properly > >> documented, we will definitely open this up to a wider audience, and > >> your input would be very welcome. > >> > >>> The Release Set is a nice idea. but I think CKMs should support > individual > >>> artefact commits also. > >> [IAN] Absolutely. Individual commits will always take place but will > >> inevitably result in a loss of coherence between dependent artefacts. > >> Part of the idea of Release sets is to give an extra level of > >> assurance to consumers that any dependency issues between artefacts > >> have been at least minimally resolved i.e all templates have the > >> correct version of archetypes, termsets available. > >> > >> > >>> > >> > >>>> Yep, it would take time, but is necessary if we want worldwide impact. > Maybe > >>>> is not only necessary, but strategic. > >>> We (the Open EHR Gen team) have developed very basic service oriented > >>> repository, a simple web oriented template editor that communicates > with the > >>> reposiotry to load archetypes and templates, and save templates. It > would be > >>> nice to try other groups tools and see how we can join efforts. > >>> > >> [IAN] You should start a discussion with Sebastian about how this > >> works. There is a lot of interest in web-based openEHR > >> archetype/template tools. I am not personally convinced that this > >> makes sense, any more than web-based Eclipse or Visual Studio makes > >> sense, but I am willing to be convinced otherwise. We certainly need > >> to integrate any authoring tools, web or desktop, much better with > >> repositories such as yours and CKM but these have to be able to > >> support the local developer private authoring phase. > >> > >> Is there any potential for using your work as part of the openEHR > >> community repository idea? Derek Hoy of Snowcloud might well be > >> interested in further discussion in this area. He does lurk on these > >> lists but I will give him a nudge. > >> > >> > >> 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 8 September 2011 18:17, pablo pazos<pazospablo at hotmail.com> wrote: > >>> Hi Ian, > >>> > >>>> 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. > >>>> > >>> What I meant was that: if we, in the future, have several CKMs around > the > >>> world, maybe forming a hierarchy or not, we need a clear specification > of > >>> the versioning rules for this distributed CKM. > >>> I don't know for sure if the versioning issue is solved or not, or if > it's > >>> solved only at the CMK or if it's part of the specifications. What we > need > >>> is the latter. > >>> Not so long ago there was a very interesting discussion about that: > >>> http://www.openehr.org/mailarchives/openehr-technical/msg05797.html > >>> > >>> > >>>> 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. > >>>> > >>> I would love to see that. Can you point me to some information or > >>> discussions about those issues? > >>> > >>> > >>>> 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. > >>>> > >>> Is this a closed discussion? I would like to help. > >>> > >>> > >>>> 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. > >>>> > >>> The Release Set is a nice idea. but I think CKMs should support > individual > >>> artefact commits also. > >>> > >>> > >>>> 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. > >>>> > >>> Yep, it would take time, but is necessary if we want worldwide impact. > Maybe > >>> is not only necessary, but strategic. > >>> > >>> > >>>> 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. > >>>> > >>> We (the Open EHR Gen team) have developed very basic service oriented > >>> repository, a simple web oriented template editor that communicates > with the > >>> reposiotry to load archetypes and templates, and save templates. It > would be > >>> nice to try other groups tools and see how we can join efforts. > >>> > >>> > >>> regards, > >>> Pablo. > >>> > >>> _______________________________________________ > >>> 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 > > federating things is always a challenge, I?m a doctor not a tecnology > > guy, but I think that middlewares like an ESB helps, am I right? > > > > _______________________________________________ > > 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 > -- Jussara R?tzsch -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20110909/d8f8c70f/attachment.html>
