openEHR-clinical Digest, Vol 35, Issue 38

Marcus Baw marcusbaw at gmail.com
Sat Mar 14 18:01:07 EDT 2015


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150314/f67e383a/attachment-0002.html>


More information about the openEHR-clinical mailing list