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 >
