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.
2011/9/8 Ian McNicoll <Ian.McNicoll at oceaninformatics.com>: > 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 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 10:14, Diego Bosc? <yampeku at gmail.com> wrote: >> 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 >> >> 2011/9/8 Ian McNicoll <Ian.McNicoll at oceaninformatics.com>: >>> 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 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 00:29, Diego Bosc? <yampeku at gmail.com> wrote: >>>> 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 :) >>>> >>>> 2011/9/8 Ian McNicoll <Ian.McNicoll at oceaninformatics.com>: >>>>> 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 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 7 September 2011 19:03, pablo pazos <pazospablo at hotmail.com> 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 >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> _______________________________________________ >> 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 >
