openEHR-clinical Digest, Vol 35, Issue 38

Marcus Baw marcusbaw at gmail.com
Mon Mar 16 07:45:45 EDT 2015


@Ian, I guess that is what I meant but I explained it wrongly.

GitHub's free if you're sharing publicly, and paid-for if you want a
private repo. So it wouldn't matter if for-profit or non-profit, it's all
about whether you're sharing archetypes or not.

I agree Ian that defining whether openEHR contributor organisations are
'for-profit' or 'not-for-profit' is a) compicated and b) unhelpful in this
context, not to mention being c) divisive when there's no need to be.

Pablo nailed it when he said that the Git/GitHub model still allows for
central curation of a 'master' branch - but the process of 'forking' a
repo, making some changes, and submitting a 'pull request' allows for
literally anyone to partake in the development process of an open source
project. I don't feel as though we're at the same point with archetypes
though.

M

M



On 15 March 2015 at 22:58, Ian McNicoll <ian at freshehr.com> wrote:

> 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
>>
>
>
> _______________________________________________
> 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/20150316/e2f30765/attachment-0002.html>


More information about the openEHR-clinical mailing list