Actually GitHub does not care if you are a not-for-profit or not. It is the private repos that are paid-for.
I think it might be quite difficult to define not-for-profit fairly in this environment. Is Pablo's training need not-for-profit? As William says, if I am developing archetypes for a commercial organisation and getting paid for that work but sharing them publicly - is that not-for-profit? Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: ian at freshehr.com twitter: @ianmcnicoll Director, freshEHR Clinical Informatics Director, openEHR Foundation Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 14 March 2015 at 22:01, Marcus Baw <marcusbaw at gmail.com> wrote: > Non profits with a free CKM licence would be public not private. This is > the github model > On 14 Mar 2015 20:50, "WILLIAM R4C" <wgoossen at results4care.nl> wrote: > >> And how would you handle commercial entities willing to share archetypes >> and not for profit organizations that keep "their" archetypes legacy? >> >> Vriendelijke groet, >> >> Dr. William Goossen >> >> Directeur Results 4 Care BV >> +31654614458 >> >> > Op 14 mrt. 2015 om 21:22 heeft >> openehr-clinical-request at lists.openehr.org het volgende geschreven: >> > >> > Send openEHR-clinical mailing list submissions to >> > openehr-clinical at lists.openehr.org >> > >> > To subscribe or unsubscribe via the World Wide Web, visit >> > >> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >> > >> > or, via email, send a message with subject or body 'help' to >> > openehr-clinical-request at lists.openehr.org >> > >> > You can reach the person managing the list at >> > openehr-clinical-owner at lists.openehr.org >> > >> > When replying, please edit your Subject line so it is more specific >> > than "Re: Contents of openEHR-clinical digest..." >> > >> > >> > Today's Topics: >> > >> > 1. Re: How to fix CKM biggest issue (Marcus Baw) >> > 2. RE: How to fix CKM biggest issue (pablo pazos) >> > >> > >> > ---------------------------------------------------------------------- >> > >> > Message: 1 >> > Date: Sat, 14 Mar 2015 19:53:57 +0000 >> > From: Marcus Baw <marcusbaw at gmail.com> >> > To: For openEHR clinical discussions >> > <openehr-clinical at lists.openehr.org> >> > Subject: Re: How to fix CKM biggest issue >> > Message-ID: >> > <CAGoUAhqcAuwPZKxLStOMMmAZ7yhE-gE8f0vuHhtPDVN6HMhiJQ at mail.gmail.com> >> > Content-Type: text/plain; charset="utf-8" >> > >> > Re: GitHub, for me the point is not that GitHub itself is proprietary or >> > open source, it's that anyone doing an open source project can have >> free GH >> > repos. Perhaps this 'freemium pricing model' is a model that the CKM >> > pricing could follow so that nonprofits could develop and review >> > archetypes, while commercial entities would pay. This is the same as the >> > Confluence/Atlassian model too. >> > >> > And the other point about GitHub is that the underlying technology (Git) >> > definitely IS open source and free. Worth noting that GitHub is only >> one of >> > many online Git hosting services (Bitbucket etc does the same thing in >> the >> > same way, and there are FOSS alternatives like GitLab) >> > >> > M >> > >> >> On 14 March 2015 at 16:13, Ian McNicoll <ian at freshehr.com> wrote: >> >> >> >> Hi Marcus/ Pablo, >> >> >> >> I think the comparison/ contrast to Github is instructive, because, of >> >> course GitHub is a hugely successful product which is highly >> supportive of >> >> open-source development, but it is not itself open-source. It is a >> >> proprietary tool. If you truly feel that tooling to support >> collaborative >> >> working itself necessitates an open source license then you should >> close >> >> your Github accounts and look elsewhere. >> >> >> >> I would very much like to see a future where levels of sponsorship, >> >> industry engagement, national funding etc, etc made it possible for >> CKM and >> >> other similar tools to be open-sourced but we are simply not in that >> >> position right now. All of the key authoring tools are open-sourced or >> >> free, (and all, I understand, will be open-sourced within a short >> period). >> >> >> >> CKM was built to perform a very specific role i.e to help >> informaticians >> >> manage the complex process of crowd-sourcing clinical input, working >> out >> >> the impact of version changes, handling translation work, term-binding >> >> work, terminology building, particularly at international or national >> >> level. It is not needed to build an archetype, build a template or >> build a >> >> termset. It is not needed to display an archetype or template or >> termset. >> >> All of the resources are mirrored to GitHub and all of the >> specifications >> >> and information necessary to perform these activities are freely >> available. >> >> >> >> CKM is a highly specialised tool with limited focus, primarily on >> national >> >> and international asset management. It is not needed to build openEHR >> >> systems, any more than GitHub is needed to build open source software. >> >> >> >> Alternative repository management tools are starting to appear, such as >> >> the 13606 Assocn. CIMM. I am sure David and Diego will not mind me >> saying >> >> that, as things stand, CIMM is a fair way off providing CKM -style >> >> functionality. >> >> >> >> I think we are in danger of confusing some real and significant issues >> >> around community engagement with the Foundation governance process. >> The >> >> issue of CKM licensing is model has, in my view, no practical impact >> on the >> >> concern that Pablo raised. Don't confuse the tool with the process. >> >> >> >> Even then I think we need to be aware that there are probably two quite >> >> different requirements here. >> >> >> >> We need a much better way for good candidates for international >> >> archetypes to find their way into the international repository, >> probably to >> >> Incubators in the first instance. Some of the upcoming technical >> changes to >> >> the tool will help this but we also need to develop clear policies of >> how >> >> and when this is appropriate. The Foundation repository is primarily >> >> designed to manage set of archetypes as a 'source of truth' with new >> >> content flowing through in a relatively controlled but coherent >> fashion. >> >> Managing the governance of these 'semantic assets' requires much more >> care >> >> and precision than 'source code' >> >> >> >> This is quite different from the position in e.g Github which is >> >> essentially a tool which allows some degree of socialisation between >> >> otherwise siloed repositories. This is great for allowing assets and >> source >> >> code to be exposed, forked and re-used but it lacks the control and >> >> coherence that is required by 'managed' national and international >> >> standards development. >> >> >> >> I actually think we need both kinds of environment, and there is >> nothing >> >> to say that both environments need to be instantiated in the same tool. >> >> >> >> @Marcus - there is actually very little metadata in archetypes. The >> >> translation support that Silje asked for is already supported in the >> AOM, >> >> and in some archetype editors such as LinkEHR. It is not supported in >> the >> >> openEHR archetype editor but as this is an open source tool, I will be >> >> working on that problem later today :). >> >> >> >> I think there is a lot to be said for using Git to manage some of the >> >> versioning and asset management activities we need, indeed I do that >> all >> >> the time when working on local projects, but none of this kind of >> metadata >> >> is carried in archetypes anyway. The kind of versioning and governance >> >> metadata that we do need is equivalent to the metadata used by >> RubyGems or >> >> npm, needed for distributed source control, and the new versioning >> metadata >> >> that will be carried in archetypes is compliant with Semver which >> underpins >> >> npm. >> >> >> >> ADL is actually a very readable language, given the complexity of >> >> information it needs to convey. >> >> >> >> It is, of course, unfamiliar but it is perfectly possible to produce >> xml, >> >> json, yaml ... serialisations of the Archetype Object Model which is >> the >> >> real source of truth. >> >> >> >> XML serialisation is fully supported by the LinkEHR and openEHR >> Archetype >> >> Editors, Thomas's Archetype Workbench exports these other formats and >> the >> >> template designer output is all expressed as XML. >> >> >> >> The problem is that these non-ADL serialisations are actually much more >> >> difficult to read and understand than raw ADL, once, of course, you get >> >> your head around ADL. >> >> >> >> @Pablo - CKM does make use of a proprietary document management system >> but >> >> the real challenge here is not technical, it is how we find a funding >> model >> >> that would sustain the kind of professional support that a tool like >> CKM >> >> requires. This is not a hacker project, it requires sustained >> investment, >> >> proper maintenance and a proper business model. So far it has not been >> >> possible to persuade the wider informatics community to collaborate on >> the >> >> kind of joint funding that would make commercial sense to a prospective >> >> supplier. >> >> >> >> This is an important discussion. I'm glad to hear people being >> supportive >> >> of all the great work that has been done, particularly by Heather >> Leslie >> >> and Sebastian Garde. It is not easy to develop a first-of-kind product. >> >> >> >> I think we have a great opportunity to discuss how to expand CKM >> editorial >> >> capacity, review current editorial policy around community involvement >> and >> >> to see how other non-CKM applications might fill some of the gaps that >> have >> >> been identified. I will certainly raise this via the new Board and, of >> >> course, discuss further with Heather in our capacities as CKM editors >> and >> >> Heather's position as Clinical program lead. >> >> >> >> Let's not mix that discussion up with an equally important issue of >> how we >> >> can secure the funding necessary to sustain development and support for >> >> repository tooling in the future. I don't think there would be much >> >> objection to the principle that an open-source licensing model would be >> >> preferred but that can only happen if the commercial model makes sense >> for >> >> potential providers. >> >> >> >> Ian >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Dr Ian McNicoll >> >> mobile +44 (0)775 209 7859 >> >> office +44 (0)1536 414994 >> >> skype: ianmcnicoll >> >> email: ian at freshehr.com >> >> twitter: @ianmcnicoll >> >> >> >> Director, freshEHR Clinical Informatics >> >> Director, openEHR Foundation >> >> Director, HANDIHealth CIC >> >> Hon. Senior Research Associate, CHIME, UCL >> >> >> >>> On 14 March 2015 at 13:20, Marcus Baw <marcusbaw at gmail.com> wrote: >> >>> >> >>> >> >>>> On 14 March 2015 at 04:53, pablo pazos <pazospablo at hotmail.com> >> wrote: >> >>>> >> >>>> For me the biggest concern, besides the limited publishing >> capabilities >> >>>> or non editors, is that the CKM is made over proprietary software, >> that >> >>>> doesn't allow us to create our own instances of the CKM for free, >> and share >> >>>> archetypes in a distributed / versioned way, like GitHub does. >> >>> >> >>> >> >>> >> >>> ?Pablo, you've nailed the problem here. *The CKM is proprietary*. >> >>> >> >>> Yet: >> >>> "All contributions to CKM is on a voluntary basis, and all CKM >> content is >> >>> open source and freely available under a Creative Commons licence?" >> From >> >>> openEHR Foundation website: >> >>> http://www.openehr.org/programs/clinicalmodels/documentation >> >>> >> >>> There's a disconnect there. I have in the past been in the middle of >> >>> trying to explain openEHR to open source 'purists' and been left with >> some >> >>> uncomfortable questions to answer about the tooling used not being >> freely >> >>> available. (no, despite what may appear to be my OSS zealotry I am >> >>> actually not even close to being a Richard Stallman-esque OSS purist) >> >>> >> >>> 'community' computing is very definitely moving away from anything >> that >> >>> is dependent on proprietary platforms, towards cross-platform, open >> source, >> >>> generic systems. Open source languages, and Git for version control. >> >>> >> >>> *If we could find some way to wrap ADL in a more readable language >> then >> >>> perhaps we really could just use GitHub for archetype sharing one >> day!* >> >>> One of the primary reasons for reliance on a GUI is that ADL in its >> raw >> >>> form is so unreadable. If it could be read and understood in a text >> editor >> >>> then there would be less need for a GUI. I accept that clinician led >> review >> >>> would still benefit from a GUI. >> >>> >> >>> Another benefit of using a mature version control system such as Git >> is >> >>> that some of the metadata about archetype authoring and details of >> who did >> >>> a certain translation could reside in the version control commit >> history >> >>> and would therefore not need to reside inside the archetype itself. >> This >> >>> would reduce the size of archetypes, and would also obviate some of >> the >> >>> problems such as the one Silje mentioned on another thread - in which >> there >> >>> isn't room to record more than one translator. >> >>> >> >>> BTW this post is very definitely not intended as a criticism of any >> >>> individuals, and I recognise the massive amount of hard work that has >> gone >> >>> before to even get where we are now. >> >>> >> >>> Marcus >> >>> >> >>> _______________________________________________ >> >>> openEHR-clinical mailing list >> >>> openEHR-clinical at lists.openehr.org >> >>> >> >>> >> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >> >> >> >> >> >> _______________________________________________ >> >> openEHR-clinical mailing list >> >> openEHR-clinical at lists.openehr.org >> >> >> >> >> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >> > -------------- next part -------------- >> > An HTML attachment was scrubbed... >> > URL: < >> http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150314/b525d7d1/attachment-0001.html >> > >> > >> > ------------------------------ >> > >> > Message: 2 >> > Date: Sat, 14 Mar 2015 17:22:35 -0300 >> > From: pablo pazos <pazospablo at hotmail.com> >> > To: openEHR Clinical <openehr-clinical at lists.openehr.org> >> > Subject: RE: How to fix CKM biggest issue >> > Message-ID: <SNT151-W26B41FD43BBEF174D9B78FC8040 at phx.gbl> >> > Content-Type: text/plain; charset="utf-8" >> > >> > Hi Ian, >> > As I said, my opinion is about the technical aspects, and I tried to >> separate this view from the management process problems, so I think there >> would be no confusion, just another complementary opinion. >> > For me the problem with the process is the one mentioned by Gustavo: I >> can't get my archetypes on the CKM directly to share them with others, in >> my case with students. If I want to teach them about the whole archetype >> management process, I can't do much with the current CKM functionalities >> besides archetypes translation. I want them to upload, review, translate, >> approve, download, create new versions, upload new versions, etc, etc.I >> would say this is another use case for the CKM that currently is not part >> of the CKM, because you mention that the challenges are about "funding" and >> "professional support". I don't think my use case needs neither of both, >> but I think it can generate qualified professionals capable of doing such >> work. So IMO what you mention and my use case are two faces of the same >> coin. Without accessibility to all the functionalities of the CKM to >> everyone (the tool aspect), it would be difficult to generated the >> knowledge needed to manage the knowledge on the central CKM and on each >> country (process aspect). After having trained professionals, "funding" is >> a total different beast. >> > GitHub is not open source, but anyone can download it and create local >> repositories that can be versioned in a distributed way, even without using >> Github servers. Also I can create my own GitHub like servers ( >> https://about.gitlab.com/). >> > I mentioned GitHub because everyone knows it. But Git, the core >> technology of GitHub is open source: http://git-scm.com/ >> > Basically what GitHub adds to Git is the cool views and the social >> aspect, but technically speaking, Git does all the versioning management >> work (repos, branches, pull requests, etc.). >> > About Git not being a "managed", I think all the contrary, pull request >> reviews are just that: a way to control what should or shouldn't be part of >> the main source of truth, a.k.a. master branch. >> > >> > For the record, I'm not trying to troll the initial discussion by >> setting the focus on technical aspects. >> > >> > -- >> > Kind regards, >> > Eng. Pablo Pazos Guti?rrez >> > http://cabolabs.com >> > >> > From: ian at freshehr.com >> > Date: Sat, 14 Mar 2015 16:13:18 +0000 >> > Subject: Re: How to fix CKM biggest issue >> > To: openehr-clinical at lists.openehr.org >> > >> > Hi Marcus/ Pablo, >> > I think the comparison/ contrast to Github is instructive, because, of >> course GitHub is a hugely successful product which is highly supportive of >> open-source development, but it is not itself open-source. It is a >> proprietary tool. If you truly feel that tooling to support collaborative >> working itself necessitates an open source license then you should close >> your Github accounts and look elsewhere. >> > I would very much like to see a future where levels of sponsorship, >> industry engagement, national funding etc, etc made it possible for CKM and >> other similar tools to be open-sourced but we are simply not in that >> position right now. All of the key authoring tools are open-sourced or >> free, (and all, I understand, will be open-sourced within a short period). >> > >> > CKM was built to perform a very specific role i.e to help >> informaticians manage the complex process of crowd-sourcing clinical input, >> working out the impact of version changes, handling translation work, >> term-binding work, terminology building, particularly at international or >> national level. It is not needed to build an archetype, build a template or >> build a termset. It is not needed to display an archetype or template or >> termset. All of the resources are mirrored to GitHub and all of the >> specifications and information necessary to perform these activities are >> freely available. >> > CKM is a highly specialised tool with limited focus, primarily on >> national and international asset management. It is not needed to build >> openEHR systems, any more than GitHub is needed to build open source >> software. >> > Alternative repository management tools are starting to appear, such as >> the 13606 Assocn. CIMM. I am sure David and Diego will not mind me saying >> that, as things stand, CIMM is a fair way off providing CKM -style >> functionality. >> > I think we are in danger of confusing some real and significant issues >> around community engagement with the Foundation governance process. The >> issue of CKM licensing is model has, in my view, no practical impact on the >> concern that Pablo raised. Don't confuse the tool with the process. >> > Even then I think we need to be aware that there are probably two quite >> different requirements here. >> > >> > We need a much better way for good candidates for international >> archetypes to find their way into the international repository, probably to >> Incubators in the first instance. Some of the upcoming technical changes to >> the tool will help this but we also need to develop clear policies of how >> and when this is appropriate. The Foundation repository is primarily >> designed to manage set of archetypes as a 'source of truth' with new >> content flowing through in a relatively controlled but coherent fashion. >> Managing the governance of these 'semantic assets' requires much more care >> and precision than 'source code' >> > This is quite different from the position in e.g Github which is >> essentially a tool which allows some degree of socialisation between >> otherwise siloed repositories. This is great for allowing assets and source >> code to be exposed, forked and re-used but it lacks the control and >> coherence that is required by 'managed' national and international >> standards development. >> > I actually think we need both kinds of environment, and there is >> nothing to say that both environments need to be instantiated in the same >> tool. >> > @Marcus - there is actually very little metadata in archetypes. The >> translation support that Silje asked for is already supported in the AOM, >> and in some archetype editors such as LinkEHR. It is not supported in the >> openEHR archetype editor but as this is an open source tool, I will be >> working on that problem later today :). >> > I think there is a lot to be said for using Git to manage some of the >> versioning and asset management activities we need, indeed I do that all >> the time when working on local projects, but none of this kind of metadata >> is carried in archetypes anyway. The kind of versioning and governance >> metadata that we do need is equivalent to the metadata used by RubyGems or >> npm, needed for distributed source control, and the new versioning metadata >> that will be carried in archetypes is compliant with Semver which underpins >> npm. >> > ADL is actually a very readable language, given the complexity of >> information it needs to convey. >> > It is, of course, unfamiliar but it is perfectly possible to produce >> xml, json, yaml ... serialisations of the Archetype Object Model which is >> the real source of truth. >> > XML serialisation is fully supported by the LinkEHR and openEHR >> Archetype Editors, Thomas's Archetype Workbench exports these other formats >> and the template designer output is all expressed as XML. >> > The problem is that these non-ADL serialisations are actually much more >> difficult to read and understand than raw ADL, once, of course, you get >> your head around ADL. >> > @Pablo - CKM does make use of a proprietary document management system >> but the real challenge here is not technical, it is how we find a funding >> model that would sustain the kind of professional support that a tool like >> CKM requires. This is not a hacker project, it requires sustained >> investment, proper maintenance and a proper business model. So far it has >> not been possible to persuade the wider informatics community to >> collaborate on the kind of joint funding that would make commercial sense >> to a prospective supplier. >> > This is an important discussion. I'm glad to hear people being >> supportive of all the great work that has been done, particularly by >> Heather Leslie and Sebastian Garde. It is not easy to develop a >> first-of-kind product. >> > I think we have a great opportunity to discuss how to expand CKM >> editorial capacity, review current editorial policy around community >> involvement and to see how other non-CKM applications might fill some of >> the gaps that have been identified. I will certainly raise this via the new >> Board and, of course, discuss further with Heather in our capacities as CKM >> editors and Heather's position as Clinical program lead. >> > Let's not mix that discussion up with an equally important issue of how >> we can secure the funding necessary to sustain development and support for >> repository tooling in the future. I don't think there would be much >> objection to the principle that an open-source licensing model would be >> preferred but that can only happen if the commercial model makes sense for >> potential providers. >> > >> > Ian >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > Dr Ian McNicoll >> > mobile +44 (0)775 209 7859 >> > office +44 (0)1536 414994 >> > skype: ianmcnicoll >> > email: ian at freshehr.com >> > twitter: @ianmcnicoll >> > >> > Director, freshEHR Clinical Informatics >> > Director, openEHR Foundation >> > Director, HANDIHealth CIC >> > Hon. Senior Research Associate, CHIME, UCL >> > >> > On 14 March 2015 at 13:20, Marcus Baw <marcusbaw at gmail.com> wrote: >> > >> > On 14 March 2015 at 04:53, pablo pazos <pazospablo at hotmail.com> wrote: >> > For me the biggest concern, besides the limited publishing capabilities >> or non editors, is that the CKM is made over proprietary software, that >> doesn't allow us to create our own instances of the CKM for free, and share >> archetypes in a distributed / versioned way, like GitHub does. >> > >> > ?Pablo, you've nailed the problem here. The CKM is proprietary. >> > >> > Yet: >> > "All contributions to CKM is on a voluntary basis, and all CKM content >> is >> > open source and freely available under a Creative Commons licence?" >> From openEHR Foundation website: >> http://www.openehr.org/programs/clinicalmodels/documentation >> > >> > There's a disconnect there. I have in the past been in the middle of >> trying to explain openEHR to open source 'purists' and been left with some >> uncomfortable questions to answer about the tooling used not being freely >> available. (no, despite what may appear to be my OSS zealotry I am >> actually not even close to being a Richard Stallman-esque OSS purist) >> > >> > 'community' computing is very definitely moving away from anything that >> is dependent on proprietary platforms, towards cross-platform, open source, >> generic systems. Open source languages, and Git for version control. >> > >> > If we could find some way to wrap ADL in a more readable language then >> perhaps we really could just use GitHub for archetype sharing one day! One >> of the primary reasons for reliance on a GUI is that ADL in its raw form is >> so unreadable. If it could be read and understood in a text editor then >> there would be less need for a GUI. I accept that clinician led review >> would still benefit from a GUI. >> > >> > Another benefit of using a mature version control system such as Git is >> that some of the metadata about archetype authoring and details of who did >> a certain translation could reside in the version control commit history >> and would therefore not need to reside inside the archetype itself. This >> would reduce the size of archetypes, and would also obviate some of the >> problems such as the one Silje mentioned on another thread - in which there >> isn't room to record more than one translator. >> > >> > BTW this post is very definitely not intended as a criticism of any >> individuals, and I recognise the massive amount of hard work that has gone >> before to even get where we are now. >> > >> > Marcus >> > >> > >> > _______________________________________________ >> > >> > openEHR-clinical mailing list >> > >> > openEHR-clinical at lists.openehr.org >> > >> > >> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >> > >> > >> > >> > _______________________________________________ >> > openEHR-clinical mailing list >> > openEHR-clinical at lists.openehr.org >> > >> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >> > -------------- next part -------------- >> > An HTML attachment was scrubbed... >> > URL: < >> http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150314/8fb32974/attachment.html >> > >> > >> > ------------------------------ >> > >> > Subject: Digest Footer >> > >> > _______________________________________________ >> > openEHR-clinical mailing list >> > openEHR-clinical at lists.openehr.org >> > >> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >> > >> > ------------------------------ >> > >> > End of openEHR-clinical Digest, Vol 35, Issue 38 >> > ************************************************ >> >> _______________________________________________ >> openEHR-clinical mailing list >> openEHR-clinical at lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >> > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150315/4f32abc9/attachment-0001.html>
