How to fix CKM biggest issue

Ian McNicoll ian at
Sat Mar 14 12:13:18 EDT 2015

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

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

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.


Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: ian at
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> wrote:

> On 14 March 2015 at 04:53, pablo pazos <pazospablo at> 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:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openEHR-clinical mailing list