# openEHR Transition: Community Knowledge repository **Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153) **Created:** 2011-09-07 08:18 UTC **Views:** 45 **Replies:** 36 **URL:** https://discourse.openehr.org/t/openehr-transition-community-knowledge-repository/14574 --- ## Post #1 by @ian.mcnicoll 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@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 --- ## Post #2 by @ian.mcnicoll Meant to add Snowcloud Clinical Templates http://www.clinicaltemplates.org/ Dr Ian McNicoll office \+44 \(0\)1536 414 994 fax \+44 \(0\)1536 516317 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian\.mcnicoll@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 --- ## Post #3 by @yampeku 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 ;\) --- ## Post #4 by @pablo 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: --- ## Post #5 by @David_Ingram_UCL_acc 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 --- ## Post #6 by @ian.mcnicoll Hi Pablo, 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\. 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\. 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\. 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\. 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\. 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\. 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@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 --- ## Post #7 by @yampeku Just for curiosity, is that license available anywhere? --- ## Post #8 by @yampeku Well Ian, even having perfect versioning/revisioning rules is useless if users just keep updating and modifying the archetypes without changing version numbers, status, etc\. I think CKM has one big challenge: We want it to be the reference repository for archetypes, but at the same time we are discouraging the use of most of the currently available archetypes\. Should we do a CKM 'archetype cleanup' as soon as test repositories arise? PD: The day I see one v2 archetype on the CKM I will be happier :\) --- ## Post #9 by @ian.mcnicoll Hi Diego, I think you may be misunderstanding the governance process in CKM \(which is closely aligned to openEHR specifications\. Anything that is 'draft' is subject to change, nothing can be guaranteed\. These are unstable, volatile artefacts\. They have no 'official' status in the openEHR ecosystem\. Having said that, I think it would be helpful to include in ADL, the internal versioning metadata that e\.g\. CKM uses to manage review rounds, but this is quite separate from official openEHR version/revision numbers\. I am not suggesting that things are perfect\. There is, as you know, a good case to be made that we should make this 'first draft' status more obvious, perhaps by adopting a v0 suffix or even omitting a suffix, but the key issue is that Draft means exactly that\. If you use a draft archetype in an application, all bets are off\. Once the archetype is published we MUST, of course, adhere to the specifications with regard to versioning and revisioning rules\. So you will see a v2 before too long, but only from a published archetype\. The real issue here is not that the rules are deficient, or that CKM disobeys those rules but that we have been much slower than we had hoped to convert archetypes from 'draft' to 'published', so that consumers have currently very few archetypes which meet the strict rules criteria\. The bottleneck is in editing, for which I as one of the editors have to take some responsibility but editing is time\-consuming and somewhat specialised and we have not, to date, secured protected resourced time for this activity\. Apart from limiting the amount of time that Heather and I can give to CKM, it also hampers our efforts to widen the editorial team, as it is difficult to identify qualified clinical people who are prepared to make the kind of commitment required without protected and resourced time\. 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@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 --- ## Post #10 by @yampeku As I said before, I am perfectly fine with archetypes being volatile, unstable, and whatever you want\. What I don't like is archetypes disappearing into the 'limbo'\. Ignoring the versioning may be OK when you are just completing the archetype \(missing terms, etc\.\), but surely is not OK for archetypes with big structural changes \(even if they are draft\)\. I'm not telling you to show it in the same way that current 'up to date' archetypes\. Hide it to most users, mark it obsolete, deprecated, put a red flag\.\.\. there are a lot of alternatives\. Having the obsolete archetypes available also helps you to understand why the new version was needed on the first place\. I don't really see the point of leaving the drafts out of the versioning process \(why don't they have any 'official' status in the first place? incomplete concepts are still concepts\)\. Archetype status \(drafts, published, team review, etc\.\) and versioning \(SemVer?\) should be two completely separated things There is another thing I think I haven't quite understand from your post\. Is 'editing' process made by reviewers or is an additional process to the 'review' process made by a team of editors? If the editors are all the reviewers \(currently more than 200 regarding CKM statistics\) then the real challenge is to involve them \(as seems like most of them are inactive users\) Diego --- ## Post #11 by @ian.mcnicoll Hi Diego, I'll answer your last question first, as it is easier\. Commenting on and reviewing an archetype is generally fairly straightforward and can be done by very many clinicians without a detailed understanding of openEHR or informatics\. In contrast, editing high\-quality, universal archetypes is a fairly time\-consuming and specialised activity\. As editors we have to\.\. 1\. Author the original archetypes or source them from elsewhere, taking into account other international standards such as HL7 2\. Do research around real\-world electronic documentation practice of the concept in question\. 3\. Understand current clinical best\-practice in the area\. 4\. Understand ongoing informatics discussion as they apply to the concept e\.g on the role of terminology or how best to handle allergy recordings\. 5\. Set up review rounds, collate the results, contact specific users for clarification or discussion 6\. Make judgements about how best to reflect the review comments in the archetype design, which does require a pretty good feel for archetype best practice, and then feed back this to the review community\. 7\. Make sure that the archetypes are technically correct and, of course, adherent to the versioning rules\. There is a great deal of word\-smithing and communication with reviewers and other domain experts\. We will not need a huge number of people with these skills but they will need protected and resourced time\. The NEHTA CKM is a good example of the kind of editorial input required at national and international level\. Of course, over time, this will reduce as more published archetypes become available\. 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@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 --- ## Post #12 by @pablo 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. --- ## Post #13 by @system Hi Pablo If the structure and licensing proposals are generally acceptable to the community then the next step will be to agree the Associate Fee structure and the qualified Members within each group (including possibly a Localisation/Translation group). How would you like to see us determine the qualification of Members to bootstrap the effort. The alternatives are: 1. Seek nominations from the list and then have a poll to see who are seen as the best candidates – take the top ‘n’. (Democratic) 2. Seek nominations from the list, have a poll and seek ‘n’ of the candidates that provide the best mix of skills. (Mix of democratic and merit) 3. Seek nominations from the list, take the three best candidates and ask them to form a team from the rest. (Predominantly peer merit) According to our current proposal, the group would then nominate a leader and seek approval from the Board. We would then have our Program groups. The new direction is focussed on providing quality outputs efficiently – with Members working as individuals and being promoted by peers. From then on, the Program group would enlist and promote members, seeking direction and support from the Board. Funding for work would come either directly to team members (in kind) or through the Foundation. Another key element is to have an annual conference. I would suggest that this should be in Europe as that is our origin. We will need a location and sponsors. Cheers, Sam --- ## Post #14 by @system Hi Diego, Ian answered the second, I'll have a go at your first question. I for one believe it is ok for a DRAFT archetype to be changed in any way without increasing the version number. I don't think that we should start clocking up versions if a DRAFT archetype needs to change in an incompatible way or you are ending up publishing say v27, v35, and then v56 instead of v1, v2, and v3. Technically this may be possible, but I would not see this as desirable. However, what we have to do is to clearly differentiate between revisions and versions of an archetype. Any change to an archetype will clock up the *revision* of the archetype - and will be retrievable e.g. via the CKM Revision History for each archetype. On the other hand, the *version* number should be increased only occur if the following conditions are met: 1. The publication status of the archetype has been published 2. The archetype has changed in a backwardly incompatible way. In this case at *some* stage before republishing the archetype, its version number has to be increased. Note that IMO the version number doesn't have to be increased *immediately* when the breaking change is taking place. This is because you potentially would want to revert this change later (e.g. after a review round) and go for a less radical, non-breaking change. So - if the currently published revision of the archetype and the new revision to be published are not compatible, then and only then should we need to increase the version number. Imagine for example you are making a breaking change which you need to revert at a later stage. This is not an uncommon situation. Say we start with v1 and due to this change we go to v2 in a draft archetype. Then you make another breaking change (v3) and now during the comprehensive review of the archetype you realise that actually none of this was required and instead a compatible change from v1 (or no change at all) was all that was needed. Now - potentially - you have to go to v4...whereas in reality you are at v1. In this example, v2 and v3 were never intended for anybody's use, they are just intermediate. Of course, all revisions are always available for these archetype - a little less visible, but always accessible via the Revision History of the archetype. This internal revision number (or some corresponding external one) could be part of an extended id of the archetype, or part of its meta data. But it has to be clear that many of these revisions are just intermediate steps and should not be upvalued more than necessary by assigning them a version number on their own. As Ian said in a previous post, the real problem is that we have so many DRAFT archetypes and so few published ones on CKM. In my opinion being able to appropriately resource the editing/publishing process of 'official' openEHR archetypes, should be made one of the top priorities of the transitional board Cheers Sebastian --- ## Post #15 by @yampeku Oh, then we need more qualified editors\. Shouldn't we ask also the users which field of medicine they are specialized on and put them as editors for that kind of archetypes? At its current stage, archetype approval process in CKM seems to be similar to 'design by committee' standards approval process\. --- ## Post #16 by @ian.mcnicoll Thanks Sebastian, That saved me replying to Diego on the first question\! I agree that we need to make a very clear distinction between the official 'external' openEHR version/revision number arrangement and any internal design\-space scheme, used to identify numerous design\-time revisions, which as you say may not ever appear in the outside world, and may be quite specific to the internal operations of the repository tool in question\. I agree that it would be helpful to carry this internal design\-space numbering information in the metadata, so that developers who did want to make use of a DRAFT archetype could know the exact revision if necessary\. e\.g\. Version = 1 Revision = 2 DesignRevision = 134567::345678 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@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 --- ## Post #17 by @system > Oh, then we need more qualified editors\. Shouldn't we ask also the > users which field of medicine they are specialized on and put them as > editors for that kind of archetypes? We do ask the users for their profession and the health area / field of medicine and also if they are generally available to act as a reviewer\. They are asked when they sign up, but anybody can change this at any stage via Tools/Update my profile\. These users will be asked to act as reviewers \(not editors\) when an archetype is under review that fits with their expertise\. This of course is not necessarily very precise, but gives a good overview of what the reviewer community for this archetype was\. Therefore, the best way to make sure you won't be missed is to adopt the archetype \- this means that you are clearly stating that you have some ownership of this archetype and want to be involved in the review for this particular archetype\. > At its current stage, archetype approval process in CKM seems to be > similar to 'design by committee' standards approval process\. I don't think that this is true at all\. But I would be very interested to know where you think the CKM process should be improved\. Cheers Sebastian --- ## Post #18 by @ian.mcnicoll Hi Diego, Absolutely \- we need more editors\. We do ask users which fields they are interested or specialised in \- and we definitely make use of this when inviting people to review archetypes but remember that, by definition, archetypes are designed to be re\-used by a broad range of clinicians \(and indeed patients\) and the specialist view of a subject is not always the only or indeed the 'correct' view\. I would certainly expect a significant opthalmology specialist input into say a Visual Acuity archetype, including optometrists, and would hope that it might be endorsed by a professional opthalmological association, but I would also want to ensure that we had input from GPs, and a broad range of many other clinicians who might make use of the archetype\. Bear in mind too that most of the very important clinical concepts like medication, diagnosis, adverse reaction etc have very broad clinical use and no real natural speciality\. This is what makes development of these kind of archetypes particularly demanding\. I would disagree that current CKM development is 'by committee'\. A traditional 'design\-by\-committee' approach is: 1\. By invite only\. 2\. Closed to outside participation or comment\. 3\. Physical meeting based, requiring significant resource 4\. May be backed up by private email conversations The CKM approach is quite different 1\. Although the Editors will invite particular 'specialists' to participate in a review, anyone wo has expressed an interest in a particular archetype'adopted' will be invited automatically, and anyone else is very welcome to participate\. The entry barrier i\.e a free login /password is minimal\. 2\. The entire review process is published and viewable to anyone with a CKM login\. Those who wish to comment outside of the review process can do so via the Discussion area\.\. The Editors are alerted if there are outstanding discussions\. 3\. The chain of past review and archetype versions is always available\. 4\. Almost everything is achieved via the web, with no travel required and minimal reviewer time commitment\. No long, boring meetings\. I appreciate that the current, slow progress in the openEHR CKM may be misleading and the activity in the current NEHTA CKM dcm\.nehta\.org\.au/ckm/\# will give a much better idea of how we expect things to work once the current log\-jam is resolved\. We can, of course, do much better, but this is a very new kind of way of working, and we are to some extent making up the requirements as we go along, in the light of experience\. So, in summary, I think we have the correct approach, not 'design\-by\-committee', not 'design\-by\-expert' but something closer to 'crowd\-sourcing', but it does require specialist input in the form of Editors who understand openEHR in some depth, CKM in some depth but crucially need a clinical informatics background\. The NEHTA example shows what is possible when the resource is available\. Not perfect \- we know it can still be a bit daunting for non\-informaticians, but we think the basic philosophy is correct\. 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@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 --- ## Post #19 by @yampeku Well I was writing a response to Sebastian, but meantime Ian mail arrived, so I'll answer both summarizing a little\. As I said: changing minimally a DRAFT archetype without increasing version number\-\-> OK changing completely the structure of a DRAFT without increasing version number and erasing the first one \(as if it never existed\) \-\-> Not OK In the case I was telling, 4 archetypes were completely changed and refactored, changing their complete structure and relationships \(even the identifier was different\)\. The refactored archetypes were just deleted from CKM, which is not cool We have more publication status between draft and published\. What happens if an archetype is in 'team review' status and then we need a new version \(again, breaking changes\)? we just delete it? about versioning: I like SemVer a lot\. Using that it won't be v56 but v1\.2\.3 \(or v0\.1\.4\)\. One last thing: In my opinion, openEHR revision policy doesn't have to be CKM specific \(and so including CKM specific metadata on the archetype may not be the best idea\) --- ## Post #20 by @yampeku First, I want to be clear in one thing: this kind of opinions are not against the editors themselves, which I think they are doing a huge work for the community\. I appreciate them and they work, and I know they are very busy people \(you just have to follow any of them on twitter\) ;\) comments inline: >> Oh, then we need more qualified editors\. Shouldn't we ask also the >> users which field of medicine they are specialized on and put them as >> editors for that kind of archetypes? > > We do ask the users for their profession and the health area / field of > medicine and also if they are generally available to act as a reviewer\. > They are asked when they sign up, but anybody can change this at any > stage via Tools/Update my profile\. > > These users will be asked to act as reviewers \(not editors\) when an > archetype is under review that fits with their expertise\. > This of course is not necessarily very precise, but gives a good > overview of what the reviewer community for this archetype was\. > Therefore, the best way to make sure you won't be missed is to adopt the > archetype \- this means that you are clearly stating that you have some > ownership of this archetype and want to be involved in the review for > this particular archetype\. I know that part, and I hope editors can access that kind of information\. When I said put them as editors I was thinking more in contacting them and offer them to be the lead editors of that archetype\. I can see how people can miss archetypes they would want to review or be editors just for not knowing it has started\. Maybe is just a silly idea, but what about tagging the archetypes with expertise areas and launch a notification to all the people registered in that area when an archetype has been created for the first time \(so they can adopt it\)\. And as you said, adopting makes you a reviewer, not an editor :\) >> At its current stage, archetype approval process in CKM seems to be >> similar to 'design by committee' standards approval process\. > > I don't think that this is true at all\. > But I would be very interested to know where you think the CKM process > should be improved\. summarizing: very few people \(elected by other editors?\), with no timelines\.\.\. will expand this on the response to Ian post --- ## Post #21 by @ian.mcnicoll Hi Diego, More later but I absolutely agree on the last point, and that nothing should be Ocean CKM specific\. But \.\. I think we have to accept that whatever design tool is used it may have its own dependency on some kind of 'private, internal' versioning scheme for the kind of design\-time churn that we know happens in any pre\-release software\. All I am suggesting is that the tool concerned simply exposes that internal number in the metadata, with only some kind of minimum commitment that this should be unique for any commited change to the archetype\. If you are a consumer of this DRAFT archetype, this gives you some kind of versioning control, but I don't believe it makes any sense for us to try and micro\-mamage the public versioning of a draft archetype\. If you download it and use it, you are on your own\. It WILL change, possibly dramatically and no ontological or structural commitment can be made by the authors\. The big problem is that, for good reasons, we are exposing 'alpha' software to public view, and in essence, mixing up the requirements of a development environment from a publishing environment\. I think we are actually quite close to SemVer in philososphy but openEHR need to have a much more precise definition of Version and Revision\. Could you give an example of how you think it might help in the context above\. 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@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 --- ## Post #22 by @ian.mcnicoll Hi Diego, No worries\. This is good, robust discussion\!\! Nothing is/was taken personally :\-\) I like the suggestion about inviting adoptions for new archetypes from those with specialist interests, although it can actually be pretty difficult to delineate these, as very many archetypes have a very broad possible interest group, or indeed no specialist interest group\. We are aware of this when 'labelling' each archetype as relevant to a particular speciality \- where does 'Blood pressure' sit, or 'pulse oximetry' ? Does Pregnancy summary only apply to obstetricians and midwives? Do people want to be bombarded with CKM spam, inviting them to adopt every new archetype? I think we would all agree with your summary: "summarizing: very few people \(elected by other editors?\), with no timelines\.\.\." and I will encourage the new Board to make this a priority to resolve\. As ever, it is largely about resource\. 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@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 --- ## Post #23 by @yampeku Well, regarding 1\. By invite only: I just learned yesterday of this 'editor' figure \(I thought all people were just reviewers\)\. At this moment I don't really know quite well which are they roles or who they are\. Is there a way to know who are the editors of an archetype? Editors must be nominated, proposed or approved by other editors? \(this is only a hunch by reading the other replies\) 2\. Closed to outside participation or comment: I think this is not intended, but currently relevant people could be left out just for not knowing it\. If only editors can nominate editors it will end being too 'endogamic'\. If you don't want someone you disagree with to be part of the archetype discussion you can potentially do that \(if you don't tell him he can be just unaware of this\)\. You have to believe in the good faith of the editors \(and as seen on committee editing process, this may not be the case\)\. 3\. Physical meeting based, requiring significant resource: I give you this one ;\) although this is something that official bodies could improve easily 4\. May be backed up by private email conversations: so can this \(?\) that's why I said that it was like committee\-driven process --- ## Post #24 by @yampeku well, tagging doesn't need to be mandatory, but I think that everyone with an specialized field should be included \(or at least, invited\) to domain specific archetypes\. --- ## Post #25 by @system Hi Diego > ``` > > ``` > > > ``` > > Sebastian: We do ask the users for their profession and the health area / field of > > medicine and also if they are generally available to act as a reviewer. > > They are asked when they sign up, but anybody can change this at any > > stage via Tools/Update my profile. ... > > > > ``` > > ``` > I know that part, and I hope editors can access that kind of > information. > ``` Of course..they can search for users with a certain expertise etc and invite them to reviews, etc. > ``` > When I said put them as editors I was thinking more in > contacting them and offer them to be the lead editors of that > archetype. > ``` Sure, being a specialist in one clinical field can be used as one criterion. But being a lead editor requires good knowledge of openEHR and two-level modelling at least as much as it requires specialist knowledge in a particular clinical field. This holds true for more general, cross-domain archetypes, but also for the more specialist ones like the visual acuity Ian mentioned. Becoming an editor for one single archetype only is a huge overhead unless you are already VERY familiar with openEHR, other archetypes, etc. > ``` > I can see how people can miss archetypes they would want to > review or be editors just for not knowing it has started. Maybe is > just a silly idea, but what about tagging the archetypes with > expertise areas and launch a notification to all the people registered > in that area when an archetype has been created for the first time (so > they can adopt it). > And as you said, adopting makes you a reviewer, not an editor :) > > ``` Actually, the archetypes are tagged with the expertise areas (e.g. right-click on an archetype and select classification or use the search facility in CKM to find appropriate resources.) You can even export this information in an OWL format which can e.g. be read with Protégé - via Tools/Export Ontology). You can also opt to be notified via email of any new archetype via Tools/Options. You can also subscribe to [http://twitter.com/#!/openEHRCKM](http://twitter.com/#!/openEHRCKM) to be notified of any updates (new archetypes, templates, termsets, etc or updates to them. It is also announced there when a new review round starts for an archetype). Your idea of notifying users that have experience/interest in a certain domain when an archetype for that domain is created is interesting. One reason we have not pursued this so far, is that although the uploader is encouraged to classify/tag the archetypes directly after uploading, you often simply don't do this immediately...and then of course you don't really have a basis to send these emails. Also, how to organise the ontology and consistently tag the archetypes, is often less obvious than you may think. But maybe we should revisit how we can make this functionality work. Another option (in addition possibly) is to display all archetypes that currently fit your profile within CKM more easily. > > > ``` > > > At its current stage, archetype approval process in CKM seems to be > > > similar to 'design by committee' standards approval process. > > > > > > ``` > > > > ``` > > I don't think that this is true at all. > > But I would be very interested to know where you think the CKM process > > should be improved. > > > > ``` > > ``` > summarizing: very few people (elected by other editors?), with no timelines... > > ``` Ok, I subscribe to what Ian has said about how design by committee and the ckm process are different. Very few people is only true for the editors, not the reviewers. I am confident that anybody putting her or his hand up and willing to invest the kind of time required to become an editor for a *series of* archetypes will be more than welcome. But let me assure you it requires a lot more time than you likely think. Yes, timelines are an issue - again one reason why I think the archetype development and reviewing should be made one of the top priorities and we need to look how we can resource this internationally. In national programs, where this is properly resourced, timelines seem to work quite well and a lot of progress has been made. There could of course be a different more democratic approach to who is an editor of an archetype, and I am sure that the current process can be improved. You may have seen the Orphan team on CKM - our initial idea here was that any team could pick up archetypes that are in there (and not being under the auspices of another team/editor). If a team/editor would not act on it for too long, it would go back into this pool of orphaned archetypes for others to pick up. However, the team approach never actually worked very well (it is too design-by-committee like if you so like) and therefore we more and more use ad-hoc teams of reviewers that differ for each and every archetype. Cheers Sebastina Cheers Sebastian --- ## Post #26 by @ian.mcnicoll Hi Diego, 1\. By invite only: I just learned yesterday of this 'editor' figure \(I thought all people were just reviewers\)\. At this moment I don't really know quite well which are they roles or who they are\. Is there a way to know who are the editors of an archetype? Editors must be nominated, proposed or approved by other editors? \(this is only a hunch by reading the other replies\) \{IAN\] The editors responsible for any Archetype review are very clearly identified in CKM\. See http://openehr.org/knowledge/OKM.html#showArchetype_1013.1.484 and press Team\. 2\. Closed to outside participation or comment: I think this is not intended, but currently relevant people could be left out just for not knowing it\. If only editors can nominate editors it will end being too 'endogamic'\. If you don't want someone you disagree with to be part of the archetype discussion you can potentially do that \(if you don't tell him he can be just unaware of this\)\. You have to believe in the good faith of the editors \(and as seen on committee editing process, this may not be the case\)\. \[IAN\] You will see from the example above or many of the NEHTA examples that we do invite other people with special interest or expertise to jointly edit many archetypes\. In due course, with the right resource and training, many of these people would become primary editors\. We do try to get as an inclusive an audience as we can into archetype reviews, balancing this against unwelcome 'spamming'\. Sebastian can detail the very many ways that CKM communicates new archetypes and new archetype reviews to as wide an audience as possible, including Twitter, RSS, emails etc etc\. Other suggestions would be very welcome\. As part of the review process we ask people to suggest others who might become involved, and others are invited as a result\. Of course, in any governed space \(and a CKM has ultimately to be governed\), one relies on the good faith of the editors, but that in turn needs oversight and governance from the Foundation, so that if these editors are felt to be acting inappropriately, action can be taken\. The relationship between the Foundation and the CKM Editorial team will be part of the new Board discussions\. 3\. Physical meeting based, requiring significant resource: I give you this one ;\) although this is something that official bodies could improve easily 4\. May be backed up by private email conversations: so can this \(?\) \[IAN\] By this I meant that private email was very much part of the normal business of standards development, not on any sense of 'deals being done behind closed doors', although this of course can take place\. It is however closed to a wider audience who might want to participate\. We do also sometimes communicate with reviewers privately, but only in specific circumstances where such a private conversation is necessary because the person involved does not want to derail the review process with 'out of scope' concerns or has personal, commercial or organisational reasons for not wanting to discuss this publicly\. This is very rare and we would always try to take any important and relevant concerns back to the wider community in a de\-identifiable fashion\. It is not part of the 'normal business' of a CKM review but is part of the real\-world experience of managing this kind of activity\. I think we need to be careful to separate issues that arise from a flaws in the CKM approach \(there are some and we will identify more with experience\), from those which arise from not being able to fund or resource this properly, including building up and training a bigger editorial team, and the oversight of that team\. In Formula 1 terms, don't attack the car designer if it runs out of petrol ;\-\) 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@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 --- ## Post #27 by @ian.mcnicoll well, tagging doesn't need to be mandatory, but I think that everyone > with an specialized field should be included \(or at least, invited\) to > domain specific archetypes That is exactly what does happen\. Are you aware of any examples where it has not? It does, of course rely on people identifying their special interests correctly and us tagging the archetypes appropriately \(not always easy\)\. We are always very keen to have speciality experts involved, since it reduces the editorial burden of doing background research and of course lends credence to the resulting model\. 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@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 --- ## Post #28 by @pablo Hi David, I think the current tools are as good as one can imagine for this moment, what I mentioned was of the tools we need to the future, and maybe some ideas to add to the whitepaper. (I wanted to be clear in this point, sometimes my bad english doesn't let me to express my ideas in a clear way, sorry for that). What I meant with free&open tools was ment for the local and regional CKMs, and with a clear API, we could develope local CKMs that are interoperable with the global CKM (without changing any of the current great work). Thank you David, I'm here to help in any way I can. I'm sure that openEHR is the way to go and I'm sure that we need to move forward together. There are a lot of great professionals in this community and I have learned and grow a lot since the first time I worked with openEHR in 2006. I regret there aren't more coleagues from south america participating on this great community, that's why I insist with the local openEHR communities, to engage this people (and selfishly to don't feel so lonely :D). Cheers, Pablo. --- ## Post #29 by @ian.mcnicoll > 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@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 --- ## Post #30 by @system 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? --- ## Post #31 by @ian.mcnicoll 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@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 --- ## Post #32 by @system than is about business needs --- ## Post #33 by @system Hi all, There are (at least) three artefact production processes: - one for the author('s) designing unripe artefacts. This is the **initial design, authoring** phase. - one for **public**, more ripe, **draft** artifacts that are shared with others. This is the **reviewing, QA**, phase. - one for **active** **published** artifacts, This is '**official**' **published** artifact phase. Each of these processes has their own 'state model', meta-data attributes, rules, etc, that must be managed by any artifact repository via a standardized interface. GF Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) --- ## Post #34 by @pablo I think is mainly a governance issue: a set of rules and guidelines to coordinate distributed work, in order to provide solutions to business needs in a consistent and compatible way. Governance is an internal problem, and business needs is an external one. --- ## Post #35 by @system Hi Gerard I think this will be too heavy a process - I would go for candidates in the first phase. Mind you for local archetypes, replicating the central process seems appropriate if there is a sufficiently large user group. Cheers Sam --- ## Post #36 by @system Heavy? This reality. Who said that real life is simple? To provide for these three real life processes takes the correct set of attributes per artefact. What is so complex about that? Gd --- ## Post #37 by @David_Ingram_UCL_acc Hi Pablo Thank you for your warm support. Don't be at all concerned about how you express your concerns - they are clearly stated and well-understood. I once heard it said at a conference that the universal language of international collaboration has become broken English spoken slowly! My family is half Polish and I speak very broken Polish, all over the place. I'm not sure how I'm going to manage with broken Chinese, though! The current discussion, at all levels, is heart-warming as it confirms, to me at any rate, that now is exactly the right time to be pushing forward into new territory, and involving new people with the strategy and governance of openEHR. I might even now change my maxim about the three most important challenges faced by openEHR, from implementation, implementation, implementation (which dominated my perspective and approach and, admittedly, resulted in rather too limited a focus, in the bootstrap era of openEHR and then 13606, on important community governance issues) to implementation, clinical engagement and goverance, all of which now matter, pretty much on a par with one another, for effective and sustainable future endeavour in the field. Best wishes, David I --- **Canonical:** https://discourse.openehr.org/t/openehr-transition-community-knowledge-repository/14574 **Original content:** https://discourse.openehr.org/t/openehr-transition-community-knowledge-repository/14574