openEHR Transition: Community Knowledge repository

Clinical (archive)
1

Hi Diego,

I am strongly in favour of establishing a community-led/
lightly-governed clinical knowledge repository as suggested by Shinji,
particularly if we can arrange some sort of federation between this
and a number of locally or regionally managed repositories.

However, these must sit quite separately from the openEHR CKM or any
other nationally governed repositories. I would anticipate that many
of the archetypes from this repositories would find there way into the
governed CKMs but Shinji's comments about needing the freedom to
experiment outside the necessary restrictions of CKM are absolutely
correct. I appreciate that many of the current archetypes are still in
draft and as you say 'use at your own risk' but we are trying to avoid
having competing representations in this 'interoperability' space.
That is not to imply that Shinji's work is poor or incorrect, just
that it often uses different design patterns and approaches. If we
adopt a free-for-all approach to CKM now, it will become impossible to
resolve later. However, IMO, this also makes the establishment of a
community repository even more essential so that some of the excellent
ideas that Shinji and others are developing have a place to grow and
flourish.

I would welcome suggestions for a repository framework e.g GitHub that
might support a community repository, particularly one that supports a
distributed/federated approach.

Snowcloud have an open-source collaborative tool that has been used by
both ICNP (nursing terminology) and Wm Goosen's Netherland's DCM group
as a front end for their collaborative working. Derek Hoy, who runs
Snowcloud, would be happy to assist in setting up an instance for
openEHR, though we would have to consider hosting etc.

This would not be trying to compete with the governed CKMs, rather
allow more free-flowing collaboration and early work-up of ideas. The
Foundation should, I believe, be prepared to support and endorse this
effort but I would expect it to be almost wholly community-driven and
governed.

Further thoughts would be very welcome.

Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org

2

Meant to add

Snowcloud Clinical Templates http://www.clinicaltemplates.org/

Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org

3

I completely agree with you, but if we do that, we need a very clear
governance and versioning policy (and be willing to stick to it).
And define the minimal access API as soon as possible :wink:

4

Hi,

I agree that we need localized CKM’s and clear governace rules technical (e.g. free&open tools, common API) and behavioral (e.g. versioning).

I’ve answered this on other thread, I think this is the correct one:

5

Hi Pablo - re- your important observation below.

It was a difficult decision to go with a proprietary product to underpin the openEHR CKM, but at the time there was no apparent open source tool to provide the first stage functionality required. It is complex and expensive software to develop and maintain and, through the good offices of Sam and Ocean, we secured a free license to support the CKM repository, which we were thereby enabled to make quickly available for experimental use. Of course, open-source tools are not cost and resource neutral options, but it is certainly easier for many to engage along an open source pathway of development. That said, I believe that going with the proprietary CKM was a sensible decision at the time (it was and had to be Dipak’s and mine, I should say, and in no way an Ocean decision). It has certainly been fully vindicated, in my eyes, by the free use that has been made of it, which we can observe day by day, within both the openEHR community and several cognate groupings, all over the world, exploring and working with the archetypes now residing in the public CKM repository that Ocean has generously created and maintained throughout, for the openEHR community.

Looking forward, Ian’s link with Derek Hoy/Snowcloud and the offer he has made, is interesting and potentially a very useful new thread in the tooling agenda for openEHR. I don’t think anyone imagines we are near to an ideal tooling environment to support effective clinical engagement with archetype/template/terminology development and support. The field will undoubtedly benefit from concerted and coordinated efforts to create new and better open source tooling in this area - a goal that is dear to many clinicians’ hearts, I know - Tony Shannon and Dipak Kalra, to name but two!

Forgive my inquisitiveness, Pablo, but I have just located and read your impressive CV and you seem exactly the right sort of person to join with others discussing here, in taking forward an initiative like that for the openEHR community. Once Sam and the new board (fully operational from October 1st) has given time for its current consultation about future governance to evolve into decisions about next steps, I very much hope there will be a way for you to do so.

David I

6

Hi Pablo,

I think we do have very good versioning / revisioning rules and CKM
has implemented these within its comparator function when we upload a
modified archetype.

There is active work exploring how to tighten up the governance
issues, especially around namespaces but I think we are pretty close
to having this worked out.

Once you consider the potential dependencies of templates, archetypes,
specialisations and termsets, there are some interesting challenges
ahead in understanding how best to keep good blend of agile
development and the kind of stability that vendors and other projects
will require.

I think Release Sets will play an important part here by giving
different projects a fixed, coherent set of artefacts to work with,
even as the leading-edge development moves on. I think it is much more
likely that connections between repositories will be through Release
Sets than by full 'current' access. We are starting to look at this
issue of 'federation' in CKM but current thinking is that a simple
view of, or reference to, assets in another repository is really not
going to help real development very much. The key issue is how to
request and acheive change in a non-native artefact, and how to handle
the inevitable mismatch in development cycles between native and
non-native artefacts.

Although the Ocean CKM is a pretty unique product for now, I am sure
alternatives, quite possibly open source, will emerge but as David
Ingram suggested this kind of functionality is complex and will take
time to develop.

I would be much more interested in starting with a light-weight
community repository tool, without the burden of tight governance
requirements of a CKM-like application. I think this can get started
with relatively low development requirements based around Derek's
Snowcloud template tool.

Ian

Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org

7

Just for curiosity, is that license available anywhere?

8

Well Ian, even having perfect versioning/revisioning rules is useless
if users just keep updating and modifying the archetypes without
changing version numbers, status, etc.
I think CKM has one big challenge:
We want it to be the reference repository for archetypes, but at the
same time we are discouraging the use of most of the currently
available archetypes.
Should we do a CKM 'archetype cleanup' as soon as test repositories arise?

PD: The day I see one v2 archetype on the CKM I will be happier :slight_smile:

9

Hi Diego,

I think you may be misunderstanding the governance process in CKM
(which is closely aligned to openEHR specifications.

Anything that is 'draft' is subject to change, nothing can be
guaranteed. These are unstable, volatile artefacts. They have no
'official' status in the openEHR ecosystem. Having said that, I think
it would be helpful to include in ADL, the internal versioning
metadata that e.g. CKM uses to manage review rounds, but this is quite
separate from official openEHR version/revision numbers.

I am not suggesting that things are perfect. There is, as you know, a
good case to be made that we should make this 'first draft' status
more obvious, perhaps by adopting a v0 suffix or even omitting a
suffix, but the key issue is that Draft means exactly that. If you use
a draft archetype in an application, all bets are off.

Once the archetype is published we MUST, of course, adhere to the
specifications with regard to versioning and revisioning rules. So you
will see a v2 before too long, but only from a published archetype.

The real issue here is not that the rules are deficient, or that CKM
disobeys those rules but that we have been much slower than we had
hoped to convert archetypes from 'draft' to 'published', so that
consumers have currently very few archetypes which meet the strict
rules criteria.

The bottleneck is in editing, for which I as one of the editors have
to take some responsibility but editing is time-consuming and somewhat
specialised and we have not, to date, secured protected resourced time
for this activity. Apart from limiting the amount of time that Heather
and I can give to CKM, it also hampers our efforts to widen the
editorial team, as it is difficult to identify qualified clinical
people who are prepared to make the kind of commitment required
without protected and resourced time.

Ian

Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org

10

As I said before, I am perfectly fine with archetypes being volatile,
unstable, and whatever you want. What I don't like is archetypes
disappearing into the 'limbo'. Ignoring the versioning may be OK when
you are just completing the archetype (missing terms, etc.), but
surely is not OK for archetypes with big structural changes (even if
they are draft).
I'm not telling you to show it in the same way that current 'up to
date' archetypes. Hide it to most users, mark it obsolete, deprecated,
put a red flag... there are a lot of alternatives. Having the obsolete
archetypes available also helps you to understand why the new version
was needed on the first place.

I don't really see the point of leaving the drafts out of the
versioning process (why don't they have any 'official' status in the
first place? incomplete concepts are still concepts). Archetype status
(drafts, published, team review, etc.) and versioning (SemVer?) should
be two completely separated things

There is another thing I think I haven't quite understand from your
post. Is 'editing' process made by reviewers or is an additional
process to the 'review' process made by a team of editors? If the
editors are all the reviewers (currently more than 200 regarding CKM
statistics) then the real challenge is to involve them (as seems like
most of them are inactive users)

Diego

11

Hi Diego,

I'll answer your last question first, as it is easier.

Commenting on and reviewing an archetype is generally fairly
straightforward and can be done by very many clinicians without a
detailed understanding of openEHR or informatics.

In contrast, editing high-quality, universal archetypes is a fairly
time-consuming and specialised activity.

As editors we have to..

1. Author the original archetypes or source them from elsewhere,
taking into account other international standards such as HL7
2. Do research around real-world electronic documentation practice of
the concept in question.
3. Understand current clinical best-practice in the area.
4. Understand ongoing informatics discussion as they apply to the
concept e.g on the role of terminology or how best to handle allergy
recordings.
5. Set up review rounds, collate the results, contact specific users
for clarification or discussion
6. Make judgements about how best to reflect the review comments in
the archetype design, which does require a pretty good feel for
archetype best practice, and then feed back this to the review
community.
7. Make sure that the archetypes are technically correct and, of
course, adherent to the versioning rules.

There is a great deal of word-smithing and communication with
reviewers and other domain experts.

We will not need a huge number of people with these skills but they
will need protected and resourced time. The NEHTA CKM is a good
example of the kind of editorial input required at national and
international level. Of course, over time, this will reduce as more
published archetypes become available.

Ian

Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org

12

Hi Ian,

I think we do have very good versioning / revisioning rules and CKM
has implemented these within its comparator function when we upload a
modified archetype.

What I meant was that: if we, in the future, have several CKMs around the world, maybe forming a hierarchy or not, we need a clear specification of the versioning rules for this distributed CKM.
I don’t know for sure if the versioning issue is solved or not, or if it’s solved only at the CMK or if it’s part of the specifications. What we need is the latter.
Not so long ago there was a very interesting discussion about that: http://www.openehr.org/mailarchives/openehr-technical/msg05797.html

There is active work exploring how to tighten up the governance
issues, especially around namespaces but I think we are pretty close
to having this worked out.

I would love to see that. Can you point me to some information or discussions about those issues?

Once you consider the potential dependencies of templates, archetypes,
specialisations and termsets, there are some interesting challenges
ahead in understanding how best to keep good blend of agile
development and the kind of stability that vendors and other projects
will require.

Is this a closed discussion? I would like to help.

I think Release Sets will play an important part here by giving
different projects a fixed, coherent set of artefacts to work with,
even as the leading-edge development moves on. I think it is much more
likely that connections between repositories will be through Release
Sets than by full ‘current’ access. We are starting to look at this
issue of ‘federation’ in CKM but current thinking is that a simple
view of, or reference to, assets in another repository is really not
going to help real development very much. The key issue is how to
request and acheive change in a non-native artefact, and how to handle
the inevitable mismatch in development cycles between native and
non-native artefacts.

The Release Set is a nice idea. but I think CKMs should support individual artefact commits also.

Although the Ocean CKM is a pretty unique product for now, I am sure
alternatives, quite possibly open source, will emerge but as David
Ingram suggested this kind of functionality is complex and will take
time to develop.

Yep, it would take time, but is necessary if we want worldwide impact. Maybe is not only necessary, but strategic.

I would be much more interested in starting with a light-weight
community repository tool, without the burden of tight governance
requirements of a CKM-like application. I think this can get started
with relatively low development requirements based around Derek’s
Snowcloud template tool.

We (the Open EHR Gen team) have developed very basic service oriented repository, a simple web oriented template editor that communicates with the reposiotry to load archetypes and templates, and save templates. It would be nice to try other groups tools and see how we can join efforts.

regards,
Pablo.

13

Hi Pablo

If the structure and licensing proposals are generally acceptable to the community then the next step will be to agree the Associate Fee structure and the qualified Members within each group (including possibly a Localisation/Translation group).

How would you like to see us determine the qualification of Members to bootstrap the effort. The alternatives are:

  1. Seek nominations from the list and then have a poll to see who are seen as the best candidates – take the top ‘n’. (Democratic)

  2. Seek nominations from the list, have a poll and seek ‘n’ of the candidates that provide the best mix of skills. (Mix of democratic and merit)

  3. Seek nominations from the list, take the three best candidates and ask them to form a team from the rest. (Predominantly peer merit)

According to our current proposal, the group would then nominate a leader and seek approval from the Board. We would then have our Program groups.

The new direction is focussed on providing quality outputs efficiently – with Members working as individuals and being promoted by peers. From then on, the Program group would enlist and promote members, seeking direction and support from the Board. Funding for work would come either directly to team members (in kind) or through the Foundation.

Another key element is to have an annual conference. I would suggest that this should be in Europe as that is our origin. We will need a location and sponsors.

Cheers, Sam

14

Hi Diego,

Ian answered the second, I’ll have a go at your first question.

I for one believe it is ok for a DRAFT archetype to be changed in any way without increasing the version number.
I don’t think that we should start clocking up versions if a DRAFT archetype needs to change in an incompatible way or you are ending up publishing say v27, v35, and then v56 instead of v1, v2, and v3.
Technically this may be possible, but I would not see this as desirable.

However, what we have to do is to clearly differentiate between revisions and versions of an archetype.
Any change to an archetype will clock up the revision of the archetype - and will be retrievable e.g. via the CKM Revision History for each archetype.
On the other hand, the version number should be increased only occur if the following conditions are met:

  1. The publication status of the archetype has been published
  2. The archetype has changed in a backwardly incompatible way.

In this case at some stage before republishing the archetype, its version number has to be increased.
Note that IMO the version number doesn’t have to be increased immediately when the breaking change is taking place.
This is because you potentially would want to revert this change later (e.g. after a review round) and go for a less radical, non-breaking change.
So - if the currently published revision of the archetype and the new revision to be published are not compatible, then and only then should we need to increase the version number.

Imagine for example you are making a breaking change which you need to revert at a later stage. This is not an uncommon situation.
Say we start with v1 and due to this change we go to v2 in a draft archetype.
Then you make another breaking change (v3) and now during the comprehensive review of the archetype you realise that actually none of this was required and instead a compatible change from v1 (or no change at all) was all that was needed.
Now - potentially - you have to go to v4…whereas in reality you are at v1.

In this example, v2 and v3 were never intended for anybody’s use, they are just intermediate.

Of course, all revisions are always available for these archetype - a little less visible, but always accessible via the Revision History of the archetype.
This internal revision number (or some corresponding external one) could be part of an extended id of the archetype, or part of its meta data.
But it has to be clear that many of these revisions are just intermediate steps and should not be upvalued more than necessary by assigning them a version number on their own.

As Ian said in a previous post, the real problem is that we have so many DRAFT archetypes and so few published ones on CKM.
In my opinion being able to appropriately resource the editing/publishing process of ‘official’ openEHR archetypes, should be made one of the top priorities of the transitional board

Cheers
Sebastian

15

Oh, then we need more qualified editors. Shouldn't we ask also the
users which field of medicine they are specialized on and put them as
editors for that kind of archetypes?
At its current stage, archetype approval process in CKM seems to be
similar to 'design by committee' standards approval process.

16

Thanks Sebastian,

That saved me replying to Diego on the first question!

I agree that we need to make a very clear distinction between the
official 'external' openEHR version/revision number arrangement and
any internal design-space scheme, used to identify numerous
design-time revisions, which as you say may not ever appear in the
outside world, and may be quite specific to the internal operations of
the repository tool in question. I agree that it would be helpful to
carry this internal design-space numbering information in the
metadata, so that developers who did want to make use of a DRAFT
archetype could know the exact revision if necessary.

e.g.

Version = 1
Revision = 2
DesignRevision = 134567::345678

Ian

Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org

17

Oh, then we need more qualified editors. Shouldn't we ask also the
users which field of medicine they are specialized on and put them as
editors for that kind of archetypes?

We do ask the users for their profession and the health area / field of
medicine and also if they are generally available to act as a reviewer.
They are asked when they sign up, but anybody can change this at any
stage via Tools/Update my profile.

These users will be asked to act as reviewers (not editors) when an
archetype is under review that fits with their expertise.
This of course is not necessarily very precise, but gives a good
overview of what the reviewer community for this archetype was.
Therefore, the best way to make sure you won't be missed is to adopt the
archetype - this means that you are clearly stating that you have some
ownership of this archetype and want to be involved in the review for
this particular archetype.

At its current stage, archetype approval process in CKM seems to be
similar to 'design by committee' standards approval process.

I don't think that this is true at all.
But I would be very interested to know where you think the CKM process
should be improved.

Cheers
Sebastian

18

Hi Diego,

Absolutely - we need more editors.

We do ask users which fields they are interested or specialised in -
and we definitely make use of this when inviting people to review
archetypes but remember that, by definition, archetypes are designed
to be re-used by a broad range of clinicians (and indeed patients) and
the specialist view of a subject is not always the only or indeed the
'correct' view. I would certainly expect a significant opthalmology
specialist input into say a Visual Acuity archetype, including
optometrists, and would hope that it might be endorsed by a
professional opthalmological association, but I would also want to
ensure that we had input from GPs, and a broad range of many other
clinicians who might make use of the archetype.

Bear in mind too that most of the very important clinical concepts
like medication, diagnosis, adverse reaction etc have very broad
clinical use and no real natural speciality. This is what makes
development of these kind of archetypes particularly demanding.

I would disagree that current CKM development is 'by committee'.

A traditional 'design-by-committee' approach is:

1. By invite only.
2. Closed to outside participation or comment.
3. Physical meeting based, requiring significant resource
4. May be backed up by private email conversations

The CKM approach is quite different

1. Although the Editors will invite particular 'specialists' to
participate in a review, anyone wo has expressed an interest in a
particular archetype'adopted' will be invited automatically, and
anyone else is very welcome to participate. The entry barrier i.e a
free login /password is minimal.
2. The entire review process is published and viewable to anyone with
a CKM login. Those who wish to comment outside of the review process
can do so via the Discussion area.. The Editors are alerted if there
are outstanding discussions.
3. The chain of past review and archetype versions is always available.
4. Almost everything is achieved via the web, with no travel required
and minimal reviewer time commitment. No long, boring meetings.

I appreciate that the current, slow progress in the openEHR CKM may be
misleading and the activity in the current NEHTA CKM
dcm.nehta.org.au/ckm/# will give a much better idea of how we expect
things to work once the current log-jam is resolved.

We can, of course, do much better, but this is a very new kind of way
of working, and we are to some extent making up the requirements as we
go along, in the light of experience.

So, in summary, I think we have the correct approach, not
'design-by-committee', not 'design-by-expert' but something closer to
'crowd-sourcing', but it does require specialist input in the form of
Editors who understand openEHR in some depth, CKM in some depth but
crucially need a clinical informatics background. The NEHTA example
shows what is possible when the resource is available. Not perfect -
we know it can still be a bit daunting for non-informaticians, but we
think the basic philosophy is correct.

Ian

Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org

19

Well I was writing a response to Sebastian, but meantime Ian mail
arrived, so I'll answer both summarizing a little.

As I said:
changing minimally a DRAFT archetype without increasing version number--> OK
changing completely the structure of a DRAFT without increasing
version number and erasing the first one (as if it never existed) -->
Not OK
In the case I was telling, 4 archetypes were completely changed and
refactored, changing their complete structure and relationships (even
the identifier was different). The refactored archetypes were just
deleted from CKM, which is not cool

We have more publication status between draft and published. What
happens if an archetype is in 'team review' status and then we need a
new version (again, breaking changes)? we just delete it?

about versioning: I like SemVer a lot. Using that it won't be v56 but
v1.2.3 (or v0.1.4).

One last thing: In my opinion, openEHR revision policy doesn't have to
be CKM specific (and so including CKM specific metadata on the
archetype may not be the best idea)

20

First, I want to be clear in one thing: this kind of opinions are not
against the editors themselves, which I think they are doing a huge
work for the community. I appreciate them and they work, and I know
they are very busy people (you just have to follow any of them on
twitter) :wink:
comments inline:

Oh, then we need more qualified editors. Shouldn't we ask also the
users which field of medicine they are specialized on and put them as
editors for that kind of archetypes?

We do ask the users for their profession and the health area / field of
medicine and also if they are generally available to act as a reviewer.
They are asked when they sign up, but anybody can change this at any
stage via Tools/Update my profile.

These users will be asked to act as reviewers (not editors) when an
archetype is under review that fits with their expertise.
This of course is not necessarily very precise, but gives a good
overview of what the reviewer community for this archetype was.
Therefore, the best way to make sure you won't be missed is to adopt the
archetype - this means that you are clearly stating that you have some
ownership of this archetype and want to be involved in the review for
this particular archetype.

I know that part, and I hope editors can access that kind of
information. When I said put them as editors I was thinking more in
contacting them and offer them to be the lead editors of that
archetype. I can see how people can miss archetypes they would want to
review or be editors just for not knowing it has started. Maybe is
just a silly idea, but what about tagging the archetypes with
expertise areas and launch a notification to all the people registered
in that area when an archetype has been created for the first time (so
they can adopt it).
And as you said, adopting makes you a reviewer, not an editor :slight_smile:

At its current stage, archetype approval process in CKM seems to be
similar to 'design by committee' standards approval process.

I don't think that this is true at all.
But I would be very interested to know where you think the CKM process
should be improved.

summarizing: very few people (elected by other editors?), with no timelines...

will expand this on the response to Ian post