Call for CKM Editors
heather.leslie at oceaninformatics.com
Mon Jul 9 03:05:48 EDT 2012
Pablo Pazos has prompted me to raise the issue of raising the CKM modelling
and review activity again. His message prompted me to search for my last
call to the community for Editors - it was longer than I remembered, way
back in June last year - see below.
The response was... zero.
The major bottleneck remains the same - limited content Editorial resources.
Our long standing issue is that a lack of Editorial skills is holding back
the ability to review, refine and publish archetypes. We are really
fortunate to have a community of willing volunteers to review archetypes and
to translate them, but Ian and I have been the only Editors to date and no
additional Editors have been forthcoming.
I have to admit that I have pulled back on my volunteer efforts - it took
its toll in the early days - and Ocean has funded a considerable amount of
Ian and my work to get CKM to the point that it is. That is not a good or
sustainable model for the future.
And there is no doubt that CKM is a high profile resource - we know vendors
are implementing the drafts, despite knowing that they are not yet stable.
We see the archetypes being referred to in many academic papers and used as
resources for other work in HL7 and other organisations.
We need to share the load with other volunteers - it's that simple! Or we
need funding resources to pay for and prioritise Editorial efforts - I
believe that this is an issue that has been on the agenda for the Foundation
for some time.
We have had some recent success in mentoring another Editor - models for
assessment of MS were submitted, for use in a specific research project in
Germany. Ian has mentored Michael Braun through the Content review process
for one of those models - recently published. Others are now in process but
the Editorial commitment and domain knowledge is limited to that MS project.
I think Michael found it a positive experience and I am trying to persuade
Michael to write up his thoughts on the experience, with the intent of
sharing them with others.
Ian McNicoll and I are happy to continue acting as Clinical Knowledge
Administrators (CKAs) for CKM for now, until we can upskill others to take
on that role. The CKAs have the responsibility for ensuring the coherence of
the models in the repository and having oversight to the review and
Ian and I are keen to spread the archetype Editorial load and are very keen
to find individuals who are interested in a medium- to long-term volunteer
commitment, supported by a mentoring process by CKAs until the new Editor is
confident. It is probably realistic to assume that potential Editors would
prefer to work on the refinement of a group of models that are of interest
to them or their work. It is in the interest of CKM governance to keep the
Editorial team well-trained and uniform in approach - we don't want hundreds
of people as that will make it harder to ensure consistent Editorial
Editors take responsibility for the review process for each archetype -
initially content reviews, but later this will happen for translations and
terminology binding as well. There is always at least two Editors, often
three, appointed per archetype - ensuring that between the Editors there is
sufficient domain, openEHR technical and CKM governance knowledge to be able
to make reasonable Editorial decisions and not be driven or dominated by any
one individual. Provision of the technical and governance oversight is
relatively easy to provide, but we really do need extra Editorial input from
the clinical and informatics domains especially. The transparency of CKM
will also work to ensure that the Editors are accountable for making
reasoned and appropriate decisions. Clearly we are looking for individuals
who are happy and willing to work collaboratively and to support the
CKM-wide principles of modelling and governance, or to actively contribute
to the processes to improve them.
Indicative workload estimates for an archetype review, based on experience
to date, but varying enormously from archetype to archetype:
. Initiating a review - 3.25 hours:
o Initial finessing and upload to CKM - 2 hours
o Build a review team - 0.5 hours
o Initiate the review, including introduction and identifying specific
issues for resolution - 45 minutes
. Facilitating each review round - 3.75 hours
o Respond to comments - average of 2 hours (but can be quite a bit more
for the initial review round where there might be considerable design
modification and much quicker in the final review rounds where there is
mostly word-smithing, typo and grammar corrections)
o Update the archetype - 1 hour
o Review and update the review team - 15 minutes
o Initiate the follow-up review round, including identifying specific
issues for resolution - 0.5 hours
Now, a typical review process consists of 6-8 review rounds - the first 3-
more intensive due to design modification, the others less demanding.
So an estimate of average Editorial workload per archetype is 25.75 hours:
. Initial - 3.25 hours, plus
. Following - 6 rounds x 3.75 hours
For models such as Adverse Reaction, Problem/Diagnosis, Medication it has
taken much longer. For others like weight and height it is much shorter.
We are keen to build up a cohesive and like-minded team from all
Please, let me know if you are interested.
Dr Heather Leslie
MBBS FRACGP FACHI
Director of Clinical Modelling - <http://www.oceaninformatics.com/> Ocean
Clinical Program Lead - openEHR Foundation
Phone (Aust) +61 (0)418 966 670
Skype - heatherleslie
Twitter - @omowizard
From: Heather Leslie [mailto:heather.leslie at oceaninformatics.com]
Sent: Tuesday, 21 June 2011 2:03 PM
To: 'For openEHR technical discussions'; 'For openEHR clinical discussions'
Subject: CKM progress and RE: Archetype versioning on CKM
And this leads in to my related third point - the apparent lack of progress
on the openEHR CKM re archetype publication. To me it is the proverbial
'elephant in the room'. I am somewhat embarrassed, but we have not been
resourced to be able to continue this work directly in the volunteer openEHR
space. The Ocean team did a lot of huge amount of work in the early days to
get CKM up and running - Sam, Ian and Sebastian in particular - please don't
underestimate it. That burned me out, and I had to cut back; now paid work
has become busier - I have had to prioritise just like everyone else.
I would love to see the openEHR CKM flourishing but the Foundation and the
community needs to take it on and resource it, not just rely on Ocean
resources to drive it or do the actual work. The Editorial resources are
largely the bottleneck. It does take a particular personality and mindset,
attention to detail and a considerable time commitment to become an Editor.
Ian McNicoll and I took these roles on originally - we were learning and
needed to establish some processes. This is still being fine-tuned but we
are certainly in a position to mentor and train others who might be
interested in taking on some Editorial responsibilities and have the time to
do the job properly - it is never done in isolation, and the Editorial team
approach is proving very successful. I have approached some individuals who
I have thought might be suited but unfortunately most have baulked at the
potential time commitment. We have had one Editor start but they have
drifted off with other priorities. So we are absolutely open to more efforts
and probably should have been making this more public for some time now.
And the modelling efforts have not disappeared totally. There is active
modelling and reviewing of archetypes happening in the Australian NEHTA CKM
<http://dcm.nehta.org.au/ckm/> . Many of the archetypes in here have been
drawn from the openEHR CKM and are now undergoing review and fine-tuning by
stakeholders in Australia. NEHTA's approach to development of a clinical
model library and publication of their specifications are found here
tailed-clinical-models> . As we undertook this work with NEHTA we understood
that the models published in their CKM would be able to be shared back to
the international community - we are seeking confirmation of this, and hope
to be able to update the openEHR models with these more mature ones soon.
They are making good progress.
Ultimately we need the community more active in the openEHR CKM - make it
yours! Take the initiative. Volunteer as an Editor. Send us candidate
archetypes. Tell your colleagues. Translate the published archetypes from
inside CKM - simply select 'Translate archetypes' from within the
Interestingly one member has been busy translating archetypes into Arabic
(Syrian) - both the draft and published. I did email them to advise they
prioritise the published archetypes to ensure they realised that if the
draft archetypes change, the translation will potentially need to be
re-done, yet they keep coming;-)
I'm still excited. the more I'm involved, the more I'm convinced that this
work has great potential to make a real difference. Please join in.
From: openehr-technical-bounces at openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale
Sent: Thursday, 16 June 2011 6:25 PM
To: For openEHR clinical discussions; Openehr-Technical
Subject: Re: Archetype versioning on CKM
thanks for the pointer. I like this set of rules. It is not too different
from the current draft identification spec
nowledge_id_system.pdf> , and it would be easy to upgrade it to reflect the
SemVer rules more faithfully. In the openEHR spec, major.minor.patch is
referred to as version.revision.build. I seem to remember a discussion where
we thought about renaming these. Do people think we should just stop
mentioning version/revision/build with respect to archetypes? Or is it
helpful to think of an openEHR 'revision' as being the same as a 'minor'
version (personally I think yes)?
The only thing I don't like that much is going back to putting 'draft' etc
on the end of the version string, but I guess it is so common, that we
should just go with the flow.
If we can get a bit of consensus here, I can update this draft proposal to
reflect it pretty quickly.
On 14/06/2011 09:24, Erik Sundvall wrote:
I came to think of this openEHR versioning discussion thread when I
read about the Semantic Versioning initiative at http://semver.org/
I think the reasoning there is very appropriate also for openEHR artifacts.
The problem for openEHR might be that there are so many seemingly
usable archetypes in the openEHR-hosted CKM that are neither modified
for a long time nor officially tagged as "published". It is
understandable if it's tempting to start using them in real systems
already now. After all the alternative is to reinvent the wheel
locally and is that really better? Perhaps there should be a time
limit on how long artifacts in the CKM can stay at a version below
Perhaps things would become easier if we break the link between an
artifact having "published" status (as in being CRB approved) and the
fact that an artifact has a version over 1.0.0. That way systems can
start using archetypes past 1.0.0 knowing that non-compatible changes
will have new major version numbers (irrespective of if they are
published or not).
Keeping approval "badges" like "ARB published", "NHS approved" or "WHO
2011 Certified" separate from technical version numbers might be a
good idea anyway... (Example: the first "ARB published" version of
Archetype X might be 2.4.2 and the next time it's awarded an "ARB
published" badge again might be when the ARB has time to get around to
looking at version 2.8.4 or 7.8.9). Likely, agencies will want to
approve sets of artifacts on a regular basis like tagging a number of
mutually compatible archetypes and templates as "NHS 2012-Q1
The reasoning under #3 at http://semver.org/ (regarding 1.0.0beta1 <
1.0.0beta2 < 1.0.0.) might solve the "draft problem" discussed in this
openEHR thread previously. (Provided that beta versions etc. don't get
used/abused in live EHR systems.)
The Semantic Versioning specification formalism is also machine
processable in a nice way.
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733
On Thu, Apr 28, 2011 at 13:41, Thomas Beale
<mailto:thomas.beale at oceaninformatics.com>
<thomas.beale at oceaninformatics.com> wrote:
On 28/04/2011 02:07, Heather Leslie wrote:
I think you are missing some of the further complexity here. There is a
definite need for differentiation between draft and published archetypes for
which a version number alone is not enough.
Currently we are talking only about v1 archetypes and how to manage them,
and to a degree it makes sense. We certainly considered using v0.x for
drafts but it doesn't solve the downstream problems - once a v1 archetype is
published, the non-breaking revisions will become v1.1, 1.2 etc. No problem
But when we make a breaking change it becomes v2 (or v3 or v4 or 125), but
it needs to be clear that it is v2 *draft* initially and not v2 *published*
until we have completed the neccessary collaborative reviews.
There are two ways to look at this:
A - 'draft' is only possible at the notional v0 or first version stage;
after initial publication, it can't be used, since the archetype is now 'in
B - it is possible to go back to 'draft' status when the major version
number is incremented on the basis that a new major version is a new
archetype, and authors need to be able to go back into 'initial development'
I can see arguments for both. What we need to decide on as a community is
what rule we want here, and to stick to it. If we can decide that, we can
document it and post it in a new draft of the identification specification.
Diego's problem of knowing what archetype one is actually using is real and
needs to be solved. CKM does track revision numbers, but they are not part
of the version id, and you have to go into the revision history view to see
them. However the above-mentioned identification draft spec indicates a
system of referencing to do this such that an archetype whose id is
currently shown as openEHR-EHR-EVALUATION.diagnosis.v1 would be referenced
from data and / or software (i.e. in any operational context) as
openEHR-EHR-EVALUATION.diagnosis.v1.29.0, or in the future with a namespace
as well, i.e. org.openehr.ehr::openEHR-EHR-EVALUATION.diagnosis.v1.29.0
Note that in this system of identification, if the final part of the
revision number is a '0', i.e. the '0' above in '1.29.0', it means that the
archetype is published; if it is anything else it is draft or some other
pre-release state (this corresponds with view B above). Changes in the
lifecycle state of the archetype are assumed to always cause an increment in
final number of the extended version id.
A fuller idea of referencing archetypes from from data is described in this
spec, exemplified by the following:
se.skl.epj::openEHR-EHR-EVALUATION.genetic_diagnosis.v1.12, -- some Swedish
org.openehr.ehr::openEHR-EHR-EVALUATION.diagnosis.v1.29, -- its parent,
the CKM diagnosis archetype
org.openehr.ehr::openEHR-EHR-EVALUATION.problem.v2.4 -- the ultimate
parent, the CKM problem archetype
here the whole specialisation lineage has been included. The reason for
doing this are a) if the archetype lineage information is not shared between
sender and receiver (maybe the receiver can't see the Swedish CKM) and b) to
enable the receiver to know what archetypes could be used for querying the
data, assuming it was not going to use the most specialised one (e.g. the
data might have been sent from Sweden to Denmark, and the Danish system
doesn't use the Swedish genetic diagnosis archetype, but does use the other
Note that the version ids above only have 2 parts, because the final part is
always '0' for published archetypes (but it could be included for better
Assuming this kind of system was used, then supporting it requires some
changes in CKM to a) make the full version + revision id visible.
Note that the 'identifiers' above are just strings. Even in a future where
Oids were used for identifying artefacts, you still need to generate the
above strings, or the equivalent, from meta-data - essentially as composite
keys (in the relational sense) so that comparisons can be made between
artefacts. (Or they might also be obtainable from some Oid-keyed meta-data
repository). In other words, embedding such strings in data isn't making a
statement about how archetypes are identified, it is just one useful means
of referencing archetypes.
Finally, to be sure that the archetype you have in your environment is
indeed what you think it is, digital signing, or at least hashing, is needed
such that published archetypes are posted with their signatures alongside
for verification by accessing systems. MD5-based hashing is already in use
in some openEHR-based products, but it has not been properly described (an
initial idea is in section 8 of the identification spec doc).
It seems that there is enough use of archetypes now to finalise many of
these issues, and describe them in a new issue of the identification
specification. We then need to work out an implementation plan, mostly to do
with changes to CKM to support the decisions.
There are two ways to go about this:
interested parties review the identification spec, and provide feedback
we work out the details on the technical list + wiki via discussion and then
update the spec.
Key things that need decisions:
do we go with starting at v0 or v1 (I still like v0 because it implies 'you
will most likely get burnt by using this archetype in a real system, but
have fun and tell us your experience')?
can we agree on the archetype life-cycle states and the idea that a change
in state always causes an increment in minor revision number?
how should archetypes be referenced from data?
what system of hashing and signing should be used?
openEHR-technical mailing list
openEHR-technical at openehr.org
openEHR-clinical mailing list
openEHR-clinical at openehr.org
Chief Technology Officer, Ocean Informatics
Chair Architectural Review Board, <http://www.openehr.org/> openEHR
Honorary Research Fellow, University College London
Chartered IT Professional Fellow, BCS, British Computer Society
Health IT blog <http://www.wolandscat.net/>
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5828 bytes
Desc: not available
More information about the openEHR-clinical