License and copyright of archetypes

[Richard_Dixon_Hughes]

Sam,

As a lawyer (among other things), I felt a burning need to make quick
comment; however, I have not had time to refresh my memory on all the
details - but here goes anyway.
As you may be aware, in Australia our copyright law has slightly
different terms and interpretations - so I have to be careful making
superficial observations on a topic that many others have studied in
considerable depth. In Australia, we only have "adaptations" but our
adaptations cover both the "adaptations" and "derivative works" found
under the US Copyright Law - Title 17 of the US Code. I am unsure of
current British Law in this area although much of our original
precedent is based on UK decisions. In all common law jurisdictions
the courts have struggled to come to grips with the digital age - so
even though all of our copyright laws are based on common WIPO
treaties - the US, UK, Australia all have strange decisions based on
technicalities that have resulted in the various laws being "patched
up" by subsequent legislative amendments (e.g. Computer Edge v Apple
(1986) in Australia).

My first reaction is to disagree with you about a form based on an
archetype not being an adaptation of an archetype - in my view that
would be at least debatable, depending on the facts of each
case. There are questions about whether copyright can subsist in a
work which infringes another (it appears it can in Australia -
provided that sufficient effort is expended in creating the
adaptation (the form in this case) as to satisfy the requirement of
originality [Redwood Music v Chappell]); whether what has been copied
is the unoriginal - rather than the original - portions of a work; or
whether it is the idea underlying the work rather than the expression
of the idea which has been taken.

In any case, there is a delicate balance and tension in the open
source licensing that allows vendors to use archetypes in commercial
products (expanding the appeal of openEHR) as against ensuring that
work contributed to the common good remains freely available to all
(ensuring ongoing community of interest support). I think that the
potential problem arises when vendor A takes an archetype and renders
it directly into a screen form and vendor B independently does the
same thing, slightly differently. If Vendor B did this without
reproducing a substantial part of Vendor A's work (and Vendor A
cannot prove otherwise) - it is OK from a copyright perspective. But
if Vendor A had gone and got an associated software patent or is able
to mount a successful "look and feel" case against vendor B - vendor
A may be able to establish a restrictive monopoly over the most
obvious way of rendering the archetype - good for vendor A but not
anyone else. Following Digital Communications Associates Inc v
SoftKlone Distribution Corp (1988) - the threshold to succeed in a
"look and feel" case in the US is very low - which is why people are
worried. The situation was almost identical to rendering an
archetype - and lawyers were surprised at the outcome as the screen
layout was so basic that it almost appeared to be protecting the use
of an idea, rather than its expression.

On the other hand, vendors naturally want to protect their
investments from theft - and to do this they would be well advised to
develop their own look and feel, copyright unique aspects of their
code and patent original software processes and use these means
(along with revenues from good service and support) to secure their
returns rather than to make claims on the basis of the rendering of
archetypes - but even this may be difficult for them - now that
clinical safety and efficiency are suggesting that we all ought be
adopting standard user interfaces. Your openEHR licences need to be
developed with good legal input to address the most obvious legal use
cases and create the type of market that you want. Unfortunately for
what openEHR Foundation is trying to achieve, there will always be
people in the commercial world (some with deep pockets) who will try
to take out competitors by mounting legal actions. You at openEHR
Foundation and your downstream developers need the best licensing
protections that you can secure, if you wish to engender strong uptake.

By the way - when you take lots of pieces of IP and build them into a
new work - such as a book - it is a "composition" not an
adaptation. There are a whole lot of rules about compositions and
the originality of compositions.

Regards Richard DH

[erik.sundvall]

Hi!

My first reaction is to disagree with you about a form based on an
archetype not being an adaptation of an archetype - in my view that
would be at least debatable, depending on the facts of each
case.

Richard, this resonates with my fears regarding SA-requirements for
Archetypes. There will be very many other cases we probably have not
thought of yet. Can a proprietary or a CC-BY-licensed openEHR template
be based on CC-BY-SA archetypes? Can a closed source medical device
(e.g. a pulse oximeter) include a transmission format based on
CC-BY-SA-archetypes? etc. etc.

Your concern seems largely to relate to the derivative works. I believe that
the Foundation is only concerned here about derivative archetypes. I would
not consider a form or other coded artefact to be a derivative work of the
archetype.

Sam, what matters here is not what _you_ think would be OK, but what
the license says if somebody wants to go to court e.g. to create
trouble for a competitor, and how that potentially scares
people/organisations away from using openEHR-hosted archetypes and
might instead build momentum for an alternative archetype community
using licenses that allow more freedoms.

If we want to use a simple well known CC-license, then CC-BY, (or
possibly CC-0, http://creativecommons.org/about/cc0) would avoid these
issues. But the interesting thing here is probably not to make a list
of potential problems, but instead to see if there really are any real
benefits of a CC-BY-SA requirement that can't be met by just using
e.g. CC-BY.

So the 'SA' license is really there to ensure that specialised or
adapted archetypes based on openEHR archetypes remain freely available.

If you select CC-BY you can still require that any specialised or
adapted archetypes _hosted_ by openEHR should be free under CC-BY.

Exchanging archetype based health data between organisations is pretty
pointless if you don't share the archetypes somehow, so I don't quite
see the driving force for organisations _not_ to use CC-BY for
archetypes used in data that they want to exchange with others. (For
commercial clinical trials there may be a case for secret/private
archetypes during the trial though since the archetype may reveal
things about the trial structure. Do we really want to forbid these to
in some cases be be specialisations of openEHR-hosted archetypes?)

As a director of the openEHR Foundation, I am concerned that we
do not set up a situation where people merely collect or make minor
adaptations of an archetype and make it commercially available.

Sam could you clarify: Do you mean that your main worry is that you
are afraid that somebody will take CC-BY-licensed archetypes from the
openEHR-hosted repository, modify them a bit, and then redistribute
under a less free license and start charging for it? Or do you have
any other concerns that you can clarify?

Won't your feared modified redistribution only be a problem to
interoperability if, all the following comes true:
a) If users will really consider the "commercial" versions to be a lot
better than the openEHR-hosted versions and are willing to pay for
something they used to get for free.
b) If the adaptations, if found useful by openEHR, are of such
innovation height that the modifying company can claim
copyright/patent on the changes and somehow block openEHR from
incorporating similar features in their revised archetype versions.
c) If national programmes/authorities etc. will start telling people
to use the "commercial" versions instead of the openEHR ones for
national exchange use. (Or more likely they would start their own
repository for international archetypes under e.g. OHT or some other
organisation.)
d) If the really valuable clinical community creating and maintaining
archetypes etc. stop supporting the work in the openEHR repository in
favour of other alternatives.

I think c and d would only happen if openEHR messes up their
governance and/or community support, and if that is the case, then it
is actually a good thing that the community, using CC-BY, can take the
archetype collection and keep innovating elsewhere. CC-BY might
actually pressure the openEHR foundation to do a better job than if
feeling too "safe" behind CC-BY-SA. (No matter what you think of
Google, have a look at their Data Liberation Front
http://www.dataliberation.org/ )

The more formal power you try to cling on to, the more informal power
you risk to lose.

In any case, there is a delicate balance and tension in the open
source licensing that allows vendors to use archetypes in commercial
products (expanding the appeal of openEHR) as against ensuring that
work contributed to the common good remains freely available to all
(ensuring ongoing community of interest support).

Yes, this is the core of the problem. Will a SA-requirement really be
necessary to keep the community interested? I believe not.

Today the situation of the archetype development in the (closed
source, Ocean created CKM tool) at http://openehr.org/knowledge/ is
only marked "copyright (c) 2009 openEHR Foundation", so legally it
seems like we don't know if those archetypes can be used in any system
without explicit permission from the openEHR Foundation, the
foundation is also of course now free to upon request grant permission
to any commercial or derivative use of the current archetypes. Still
people are happily engaged in the work, there is some kind of
community trust, which is a nice thing. Some companies with close
connections to the foundation also seem to be comfortable with using
these archetypes within their products and services, nice for them. I
believe this proves that there might be an interested community even
under very unclear licensing conditions and that they don't seem to
mind if their contributions may be used commercially without a licence
guarantee demanding derivative works also to be open. The observation
can of course also be used to prove that they might accept
contributing to something that they don't know if they can use in
non-SA-like systems themselves later if the foundation would elect to
use SA.

The private contributions from people using their un-paid spare time
to help openEHR are wonderful, let's do all we can to encourage it
that continue. I also believe more health professionals will be
allowed to engage in archetype authoring on paid work time once
openEHR's importance starts to increase. One of the best things that
can happen to an open source software project is that some powerful
entities start investing engagement an developer time in the project,
that happens today also in openEHR (sometimes indirectly) where e.g.
state-run agencies have paid consultancy and research to the people
doing a lot of the openEHR specification work and
validation/implementation (e.g. through Ocean Informatics and academic
research institutions). It will be wise to keep those state &
commercial payers/players happy and assured that they and all their
subcontractors can use the time/money/engagement invested in openEHR
without any additional legal hassle and special permissions from the
openEHR foundation board.

The target is to keep archetypes available for free. And to put them
under a strict management.
...
Developers might be charged a small licensing fee, similar to what you
pay when you buy a standard from IEEE or CEN or ISO.

Stefan, I and many others believe licensing fees for standards are
counterproductive. It would be better to charge for voluntary
certification that proves if products adhere to standards, in case you
need additional ways to make money. I am glad licensing fees have not
been suggested by the openEHR foundation. And what would the process
be, would it be as for standards documents, no access to
documents/archetypes before payment?

Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733
(Mail & tel. recently changed, so please update your contact lists.)

[system]

Thanks Erik and Richard,

Richard has raised the issue of people copyrighting forms and other derived
works based on archetypes and perhaps claiming these cannot be copied. This
seems to be an argument in favour of SA...

Perhaps I could state what I personally see as the ideal state of
archetypes:

1) That there is a community commitment to develop a shared set of
archetypes as well as detailed and summary display scripts (including
transforms to and from HL7 CDA, v2, CCR etc) which are freely available.
2) That these archetypes can be specialised for local use but that these
specialisations, should they be published, remain freely available to others
and under copyright of the openEHR Foundation so that other people can
specialise them further if appropriate.
3) That as many archetypes are copyright openEHR Foundation as possible to
simplify the management of access and change, and certainly any released on
the openEHR CKM.
4) That repositories for archetypes are federated to allow searching and
that specialisation is possible for any one searching these without seeking
permission from anyone (ie federated CKMs, national etc, use openEHR
copyright and licenses).
5) That no one using archetypes could be accused of copying someone else's
forms or screen rendering based on archetypes.

So the tension here is between companies using archetypes being able to
secure their investment in the software they produce and no one feeling
threatened to use archetypes in their system.

I must say, after reading Richard's post that I do think that the SA has
advantages in not leading to legal issues when companies use archetypes.
More on Eric's comments.

Sam, what matters here is not what _you_ think would be OK, but what
the license says if somebody wants to go to court e.g. to create
trouble for a competitor, and how that potentially scares
people/organisations away from using openEHR-hosted archetypes and
might instead build momentum for an alternative archetype community
using licenses that allow more freedoms.

I agree.

If we want to use a simple well known CC-license, then CC-BY, (or
possibly CC-0, http://creativecommons.org/about/cc0) would avoid these
issues. But the interesting thing here is probably not to make a list
of potential problems, but instead to see if there really are any real
benefits of a CC-BY-SA requirement that can't be met by just using
e.g. CC-BY.

If you select CC-BY you can still require that any specialised or
adapted archetypes _hosted_ by openEHR should be free under CC-BY.

Well, what if the specialised archetype is hosted in Brazil for instance.
What if you receive data from there?

Exchanging archetype based health data between organisations is pretty
pointless if you don't share the archetypes somehow, so I don't quite
see the driving force for organisations _not_ to use CC-BY for
archetypes used in data that they want to exchange with others.

I think this needs to be explicit - you can use the data and archetypes.

  (For

commercial clinical trials there may be a case for secret/private
archetypes during the trial though since the archetype may reveal
things about the trial structure. Do we really want to forbid these to
in some cases be be specialisations of openEHR-hosted archetypes?)

Surely the data is what must be secret, but if the archetypes are not
published anywhere then I agree it would not be an issue.

> As a director of the openEHR Foundation, I am concerned that we
> do not set up a situation where people merely collect or make minor
> adaptations of an archetype and make it commercially available.

Sam could you clarify: Do you mean that your main worry is that you
are afraid that somebody will take CC-BY-licensed archetypes from the
openEHR-hosted repository, modify them a bit, and then redistribute
under a less free license and start charging for it? Or do you have
any other concerns that you can clarify?

Yes

Won't your feared modified redistribution only be a problem to
interoperability if, all the following comes true:
a) If users will really consider the "commercial" versions to be a lot
better than the openEHR-hosted versions and are willing to pay for
something they used to get for free.

The point is the collective investment in archetypes will be massive. How do
we deal with the situation where someone creates a good archetype as a base
idea and posts it on openEHR. Then someone specialises it quickly on the web
and copyrights the archetype saying this is their archetype and no one else
can make one like that? As someone said earlier on the list - these are all
our collective ideas and it is inappropriate for anyone to claim them. But
we have to have a collective governance structure that works and supports
the processes that support communication of health records.

b) If the adaptations, if found useful by openEHR, are of such
innovation height that the modifying company can claim
copyright/patent on the changes and somehow block openEHR from
incorporating similar features in their revised archetype versions.

Again, it might be quite small and malicious.

c) If national programmes/authorities etc. will start telling people
to use the "commercial" versions instead of the openEHR ones for
national exchange use. (Or more likely they would start their own
repository for international archetypes under e.g. OHT or some other
organisation.)

This scenario does not bother me really for the reason's you put in
brackets). There could be two sites for archetypes but sharing a single core
set is likely to remain attractive.

d) If the really valuable clinical community creating and maintaining
archetypes etc. stop supporting the work in the openEHR repository in
favour of other alternatives.

Again, this is not of great concern to me. I am happy not to protect for
this as the clinical community has to go where it thinks is best.

I think c and d would only happen if openEHR messes up their
governance and/or community support, and if that is the case, then it
is actually a good thing that the community, using CC-BY, can take the
archetype collection and keep innovating elsewhere.

I agree.

CC-BY might
actually pressure the openEHR foundation to do a better job than if
feeling too "safe" behind CC-BY-SA. (No matter what you think of
Google, have a look at their Data Liberation Front
http://www.dataliberation.org/ )

I think it is the participants and the users that need to feel safe.

The more formal power you try to cling on to, the more informal power
you risk to lose.

I hope my ambition is for people to share health records. Having worked on
the technical side for some time I believe the it is the community of
clinicians and software companies that should answer this question to
everyone's satisfaction. I am sure that clinicians will want their work to
remain freely available and not to lead to any wars between implementing
companies. As a company CEO I want to make sure I can create forms and other
derived works from archetypes and no-one can sue me for look and feel
software.

I appreciate people sharing their ideas. It is on the basis of these sorts
of inputs that we need to make a decision.

Cheers, Sam

[erik.sundvall]

Hi Sam!

Richard has raised the issue of people copyrighting forms and other derived
works based on archetypes and perhaps claiming these cannot be copied. This
seems to be an argument in favour of SA...

I'm not sure I understand your reasoning.

1. It seems to me that previously when you argued for Share Alike (SA)
you said that derivative works (like GUIs) that were not archetypes
should not be seen by the foundation as derivative works covered by
the SA-requirement. (It still remains to be detailed if/how such a
position by the foundation should be formalised.)

2. Now it sounds like you say that forms based on archetypes really
should be considered derivative works and thus need to be released
under SA too. Somehow you seem confident that this would solve more
potential copyright issues than it would create.

Don't you find the views 1 & 2 conflicting? Could you also detail how
SA (in 2 above) would stop copy-fights in this setting, is it by
disallowing all archetype based systems that are not published under
a SA-license, leaving only open source solutions as permitted to use
openEHR-hosted archetypes? (Since I like to use and create open source
I would find this interesting, but I doubt it would be realistic in
today's health care setting :-))

> If you select CC-BY you can still require that any specialised or
> adapted archetypes _hosted_ by openEHR should be free under CC-BY.

Well, what if the specialised archetype is hosted in Brazil for instance.
What if you receive data from there?

I assume you don't have a certain issue with projects based in Brazil
(or do you?) and that you instead mean something like:

"What if you receive data from a stupid organisation that wants to
share data with you and does not understand that they need to release
the related archetypes under a licence that allows you to use the
related archetypes too?"

The above situation may occur no matter what what licence the
openEHR-hosted archetypes use (as long as openEHR does have a global
monopoly on archetype creation). The way to cure this is not by SA,
but by trying to educate stupid organisations on matters of reality.

[Now jumping back to a previous part of the discussion...]

Perhaps I could state what I personally see as the ideal state of
archetypes:
1) That there is a community commitment to develop a shared set of
archetypes as well as detailed and summary display scripts (including
transforms to and from HL7 CDA, v2, CCR etc) which are freely available.

This I believe is a goal for most of us involved in openEHR. It is the
rules regarding the way to the goal that we are discussing. I question
the value of SA as a means for this purpose and I think that a
"community commitment" will be based on other things.

If you don't have formal powers to force organisations to use your
archetypes, and you don't have that since the openEHR specifications
are OPEN, then you need to be as attractive as possible by other means
(e.g. by having the most interesting and active community). Earlier I
have stated why I think SA might make you less attractive and that it
might provide a good starting ground for a competing non-SA
community.

A licence was not the tool to check integrity of archetypes (instead
digital signing etc was). Likewise I doubt that a SA-licence would be
the right tool to fight fragmentation of efforts.

2) That these archetypes can be specialised for local use but that these
specialisations, should they be published, remain freely available to others
and under copyright of the openEHR Foundation so that other people can
specialise them further if appropriate.

Whether the copyright of a CC-BY licenced archetype is assigned to
openEHR or somebody else is irrelevant for this purpose. Anybody is
free to build anything from a CC-BY work (including archetype
specialisations) the same goes for a CC-BY-SA provided you release the
new work as CC-BY-SA.

4) That repositories for archetypes are federated to allow searching and
that specialisation is possible for any one searching these without seeking
permission from anyone (ie federated CKMs, national etc, use openEHR
copyright and licenses).

Again, the copyright assignment is not an issue if you go for CC-BY.

A well specified way/interface to query each others repositories
(machine-to-machine, not GUI) would be a good thing here though. How
do you for example query Ocean Informatics closed-source proprietary
CKM (used by openEHR) from another program? Is there a specification
published? Being able to extract the entire content contributed by the
community would raise the credibility of the currently employed
solution.

5) That no one using archetypes could be accused of copying someone else's
forms or screen rendering based on archetypes.

We could wish for this no matter what archetype licensing we use.
Don't you think people might try to make trouble no matter what
licence we use. Even if a system was based a different underlying
information model companies might complain if a competitor's system's
screen forms are direct copies of their well researched and mostly
manually crafted GUI. (I feel sorry for countries like USA that have
strong software patents.)

Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733
(Mail & tel. recently changed, so please update your contact lists.)

[thomas.beale]

Sam Heard wrote:

Thanks Erik and Richard,

Richard has raised the issue of people copyrighting forms and other derived
works based on archetypes and perhaps claiming these cannot be copied. This
seems to be an argument in favour of SA...

Perhaps I could state what I personally see as the ideal state of
archetypes:

1) That there is a community commitment to develop a shared set of
archetypes as well as detailed and summary display scripts (including
transforms to and from HL7 CDA, v2, CCR etc) which are freely available.
2) That these archetypes can be specialised for local use but that these
specialisations, should they be published, remain freely available to others
and under copyright of the openEHR Foundation so that other people can
specialise them further if appropriate.

I think that if archetypes are published by organisations other than openEHR.org, e.g. Swedish Health and Welfare, the copyright naturally will be to that organisation. If the archetype is offered to openEHR.org to be published as a global archetype (necessitating at least translation and possibly more stringent quality review), then the copyright could be re-assigned. To me it makes sense that whoever is the publishing / managing organisation should have copyright, which is to say, the right to be identified with the work. Users of the work have some right to know who this is.

3) That as many archetypes are copyright openEHR Foundation as possible to
simplify the management of access and change, and certainly any released on
the openEHR CKM.

on the openEHR.org CKM (or other tool of the future), yes; on the publishing repository of another organisation, I don’t think so. Assigning copyright to openEHR Foundation when the archetype is created, published and managed by a Swedish, Brazilian, or other organisation makes no sense to me. It doesn’t gain anything.

4) That repositories for archetypes are federated to allow searching and
that specialisation is possible for any one searching these without seeking
permission from anyone (ie federated CKMs, national etc, use openEHR
copyright and licenses).

this of course is a desirable functional requirement of tooling. What is attractive here is to have the same (open) license in the federation (indeed, it might reasonably be made a condition of federation).

5) That no one using archetypes could be accused of copying someone else's
forms or screen rendering based on archetypes.

A user of archetypes can do what the license allows (which is nearly anything); if they copy someone else’s screen design or technology, that is another matter, and it won’t be archetypes that gets them out of it…

• thomas beale

[system]

Hi Erik,

On the licensing front, I was taken by some of the issues that Richard
raised and the concern I was expressing was the possibility of people
claiming that a particular template was their design - a group of archetypes
and then creating a form based on that. This looked particularly problematic
for clinical users from my perspective. SA seems to offer some protection
for that scenario. I think you are focussing of the users in the traditional
software sense (a very important group if you want uptake) and not the
clinicians and other expert users who create the archetypes and who I want
to be the leaders in both creation and use.

Your arguments for not using SA are well put. I do not want to force people
to use openEHR Foundation archetypes - we all want the best ones to be out
there in use. If, as you say, a commercial effort created the best set and
everyone started using it, then that will be the interoperability space.

At the moment archetypes are freely available. The idea here is to get the
best possible license to help the develop the sort of community activity
that is what we want to see. BY alone is clearly a choice, SA adds a major
condition that we need to consider carefully.

Thanks for your challenging response.

Regarding CKM. I sense that you would prefer it was open source and that is
where I started as well. Ocean worked on that basis with Central Queensland
University for 3 years and had an academic team using the usual stack
(mySQL, Apache etc) and just couldn't get there. We chose to use a closed
source asset management engine from a small company in Australia to get
something working and I believe our team, led by Sebastian, Heather and Ian,
have created something wonderful. It might be that there will be open source
tools that do this job in the future but I suspect these will flourish in
the commercial sector for the time being (Arcitecta's clients are largely
research institutes and universities!).

It would be good to have a list of interfaces for CKM people would like from
this service. You can look in the Archetype Editor for some specs
immediately as this pulls web-based files from CKM. I will ask Sebastian to
put the interfaces on the openEHR wiki. The things you can do already:
1. Pull down all the archetypes in a zip file.
2. Get a list of archetypes as a web service and download any you want.

Any refinements of the interface people would like to have, put it on the
list or send it to Sebastian.

The platform CKM is running on is Linux and Java (Could be Windows Server)
with this component in the middle. We should have a plug-in framework going
shortly as this is basically how the underlying engine operates anyway.

Cheers, Sam

[system]

Sam Heard wrote:

Regarding CKM. I sense that you would prefer it was open source and that is
where I started as well. Ocean worked on that basis with Central Queensland
University for 3 years and had an academic team using the usual stack
(mySQL, Apache etc) and just couldn't get there. We chose to use a closed
source asset management engine from a small company in Australia to get
something working and I believe our team, led by Sebastian, Heather and Ian,
have created something wonderful. It might be that there will be open source
tools that do this job in the future but I suspect these will flourish in
the commercial sector for the time being (Arcitecta's clients are largely
research institutes and universities!).

It would be good to have a list of interfaces for CKM people would like from
this service. You can look in the Archetype Editor for some specs
immediately as this pulls web-based files from CKM. I will ask Sebastian to
put the interfaces on the openEHR wiki. The things you can do already:
1. Pull down all the archetypes in a zip file.
2. Get a list of archetypes as a web service and download any you want.

Any refinements of the interface people would like to have, put it on the
list or send it to Sebastian

Hi Eric and all,

The web service interface of CKM is described here:
http://www.openehr.org/wiki/display/healthmod/CKM+Webservices

If you are missing something let me know or raise a Jira issue in CKM:
About/Suggest new feature (when logged in).

In addition to what Sam has mentioned, from the CKM GUI you can also get
selected classes of archetypes, archetypes that have been created or
modified after a certain date, etc.
You can also get an OWL ontology of all archetypes and their
classifications (e.g. Health Domain = Adolescent Health, Profession =
Nurse, ...).

Cheers
Sebastian

[system]

Hi Sam and Sebastian!

[...] I was taken by some of the issues that Richard
raised [...] the possibility of people claiming that a particular template was
their design [...] SA seems to offer some protection
for that scenario.

You still have not explained how/why you mean that CC-BY-SA offers
better protection against this than just CC-BY.

Regarding CKM. I sense that you would prefer it was open source

No, I don't have the view that the CKM or anything else used by the
foundation necessarily needs to be open source.

But I do think that openEHR is about open specifications and open
content though, and that it is very important that
work/discussions/experiences produced by the community are openly
accessible so that they can be reused in many environments and that
they can survive tool changes and to avoid vendor lock-in.

We chose to use a closed
source asset management engine from a small company in Australia to get
something working and I believe our team, led by Sebastian, Heather and Ian,
have created something wonderful.

Yes the CKM is an important tooI and it was important to get something
like this up and running quickly, the current CKM is a great
contribution.

I am also aware of some of your (Ocean Informatics') reasons for
basing the CKM on a commercial product and releasing it as a
commercial tool (although available for free to the foundation I
assume), I discussed this with Sebastian and others during and after
MIE2008. I'm not quite sure if your intention was to keep the entire
solution as closed source or if you just wanted/needed to protect the
calls made to the underlying commercial package. (Is it
http://www.arcitecta.com/mediaflux/ ?) Anyway, the reasons may be any,
the most important thing is not in this case the software licence, but
the open availability of the clinical content, discussions, reviews
etc.

(A drawback with the current situation though is that it's hard for
others than Ocean Informatics employees to contribute with
code/feature improvements or plugins to the de facto standard
archetype management tool (CKM) used by and promoted by the
foundation. The fact that such contributions would go in to a closed
commercial product also makes such contributions less likely.)

It might be that there will be open source
tools that do this job in the future but I suspect these will flourish in
the commercial sector for the time being

If the CKM content is openly available and the data formats are open,
then there is a chance that open source products (or other competing
closed source products) can be used in the future. If not, then we
actually have a "vendor lock in". The same goes for all other software
packages used by the openEHR foundation, the wiki, version management,
issue tracker, specification editing tools etc. As long as there is a
working, well documented "way out" that allows the community
contributions to be exported without too much hassle, then I believe
most people will accept the use of closed source solutions in a
setting like openEHRs.

This is also a risk management issue, a company behind a closed source
product can disappear, run out of resources or simply discontinue
support for a product. If I was heading a national program (or an
international foundation) considering to use the CKM for important
work, then I'd make sure that I either had possibilities and rights to
modify to the source code via some agreement, or that there were well
documented complete export facilities (and I'd set up a routine to
backup the exports) before investing too much time/resources in
CKM-based work.

The web service interface of CKM is described here:
http://www.openehr.org/wiki/display/healthmod/CKM+Webservices

This is a great start, thanks for documenting and announcing it!

If you are missing something let me know or raise a Jira issue in CKM:
About/Suggest new feature (when logged in).

1. I assume that developer resources are limited and that it would be
wiser to spend time on improving CKM features than to make the perfect
machine-to-machine interface for every possible content item in the
CKM. Thus in order to quickly get the complete export/backup feature
discussed above, then maybe a documented, machine readable complete
daily CKM database dump in the form of files on a public webserver
will probably do the job. (I guess excluding the stored user password
hashes might be wise for security reasons though at least until
you start using openID and can avoid storing passwords at all...)

2a. Why is reading of the archetype discussions and reviews hidden to
people not logged in? When e.g. the discussion thread "Generic name of
medication" recently moved from the mailing-list to the CKM, then at
the same time it moved from public space to private space, the
continued discussion is no longer searchable or cacheable by search
engines, internet archives etc. (The commercial wiki engine used by
the foundation is for example a lot better when it comes to this kind
of accessibility.)

2b. After opening up reading, can you make the CKM content search
engine friendly?

Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733
(Mail & tel. recently changed, so please update your contact lists.)

[thomas.beale]

regarding CKM: one key thing we want to achieve is to define an open interface for the generic notion of a ‘Clinical Knowledge Manager’, which corresponds to a ‘publishing organisation’ in the governance proposal documents I published recently. At the moment we at Ocean have built a product and it is provided for openEHR.org on a similar basis as Jira, Confluence is by Atlassian. What will clearly become important, and we want to support is the definition and evolution of two things with respect to this product:

• the service interface: how do systems talk to the CKM

• the plug-in programming interface: how can a developer build a new plug-in to fit into the CKM?
  We are trying to make this happen as fast as reasonably possible. At some point in the future, there will undoubtedly be other ‘CKM’ products; we believe that this is a good thing. We would like to think that what we are doing now - trying to develop the above two open specifications via an actual implementation rather than some theoretical process - will in the long run help to ensure that when other such products appear, they are all interoperable in the same way, and don’t lock anyone into proprietary interfaces. This will clearly take some time. I hope the community sees this as a reasonable state of affairs - the only alternative I can imagine is for significant pooled funding to be provided by governments to take care of the costs of doing this, which might make it faster. At the moment, this does not appear to be available.

• thomas beale

Erik Sundvall wrote:

(attachments)