openEHR-clinical Digest, Vol 35, Issue 38

Ian McNicoll ian at freshehr.com
Mon Mar 16 10:06:47 EDT 2015


Thanks Marcus.

I agree that the pull request model works well in Git/GitHub and the next
release of CKM will support Change requesting and submission of candidate
archetypes but that is not the real issue.

Archetypes, templates and termsets are semantic assets, not source code,
and (if you want them to be interoperable) need to be managed like APIs or
software libraries. Strict real-world versioning (not just git hashes),
strict naming, coherent dependency management. That requires specific
software support and critically it requires to people to manage the change
requests and new proposals in a timely manner

Furthermore, the key challenge in managing change requests to clinical
content is, of course, that new requests need to be put before a clinical
community which has no understanding of software development.

When the NHS toyed with openEHR several years ago, we worked with
Subversion and a wiki - CKM largely grew out of that bad experience :(

Just to be clear, I would love to see some sort of collaboration tooling
built around Git - it would solve me a lot of problems in working with
clients and vendors, and allow the kind of vibrant sharing community that
most of us agree is required but that;s a whole different kind of
application. I want GitEhr to talk to CKM (and other repo tools) so that I
can use archetypes from the CKM space and, of course submit back upwards
but trying to do this in one applicationis in my view a mistake.



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 16 March 2015 at 11:45, Marcus Baw <marcusbaw at gmail.com> wrote:

> @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
>>
>
>
> _______________________________________________
> 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/26db5cad/attachment-0002.html>


More information about the openEHR-clinical mailing list