openEHR Transition: Community Knowledge repository

Hi Diego,

More later but I absolutely agree on the last point, and that nothing
should be Ocean CKM specific.

But .. I think we have to accept that whatever design tool is used it
may have its own dependency on some kind of 'private, internal'
versioning scheme for the kind of design-time churn that we know
happens in any pre-release software. All I am suggesting is that the
tool concerned simply exposes that internal number in the metadata,
with only some kind of minimum commitment that this should be unique
for any commited change to the archetype.

If you are a consumer of this DRAFT archetype, this gives you some
kind of versioning control, but I don't believe it makes any sense for
us to try and micro-mamage the public versioning of a draft archetype.
If you download it and use it, you are on your own. It WILL change,
possibly dramatically and no ontological or structural commitment can
be made by the authors.

The big problem is that, for good reasons, we are exposing 'alpha'
software to public view, and in essence, mixing up the requirements of
a development environment from a publishing environment.

I think we are actually quite close to SemVer in philososphy but
openEHR need to have a much more precise definition of Version and
Revision. Could you give an example of how you think it might help in
the context above.

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

Hi Diego,

No worries. This is good, robust discussion!! Nothing is/was taken
personally :slight_smile:

I like the suggestion about inviting adoptions for new archetypes from
those with specialist interests, although it can actually be pretty
difficult to delineate these, as very many archetypes have a very
broad possible interest group, or indeed no specialist interest group.
We are aware of this when 'labelling' each archetype as relevant to a
particular speciality - where does 'Blood pressure' sit, or 'pulse
oximetry' ? Does Pregnancy summary only apply to obstetricians and
midwives? Do people want to be bombarded with CKM spam, inviting them
to adopt every new archetype?

I think we would all agree with your summary:

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

and I will encourage the new Board to make this a priority to resolve.
As ever, it is largely about resource.

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

Well, regarding

1. By invite only: I just learned yesterday of this 'editor' figure (I
thought all people were just reviewers). At this moment I don't really
know quite well which are they roles or who they are. Is there a way
to know who are the editors of an archetype? Editors must be
nominated, proposed or approved by other editors? (this is only a
hunch by reading the other replies)
2. Closed to outside participation or comment: I think this is not
intended, but currently relevant people could be left out just for not
knowing it. If only editors can nominate editors it will end being too
'endogamic'. If you don't want someone you disagree with to be part
of the archetype discussion you can potentially do that (if you don't
tell him he can be just unaware of this). You have to believe in the
good faith of the editors (and as seen on committee editing process,
this may not be the case).
3. Physical meeting based, requiring significant resource: I give you
this one :wink: although this is something that official bodies could
improve easily
4. May be backed up by private email conversations: so can this (?)

that's why I said that it was like committee-driven process

well, tagging doesn't need to be mandatory, but I think that everyone
with an specialized field should be included (or at least, invited) to
domain specific archetypes.

Hi Diego


Sebastian: 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.  ...

I know that part, and I hope editors can access that kind of
information.

Of course..they can search for users with a certain expertise etc and invite them to reviews, etc.

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.

Sure, being a specialist in one clinical field can be used as one criterion.
But being a lead editor requires good knowledge of openEHR and two-level modelling at least as much as it requires specialist knowledge in a particular clinical field.
This holds true for more general, cross-domain archetypes, but also for the more specialist ones like the visual acuity Ian mentioned.

Becoming an editor for one single archetype only is a huge overhead unless you are already VERY familiar with openEHR, other archetypes, etc.

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 :)

Actually, the archetypes are tagged with the expertise areas (e.g. right-click on an archetype and select classification or use the search facility in CKM to find appropriate resources.)
You can even export this information in an OWL format which can e.g. be read with Protégé - via Tools/Export Ontology).

You can also opt to be notified via email of any new archetype via Tools/Options.
You can also subscribe to http://twitter.com/#!/openEHRCKM to be notified of any updates (new archetypes, templates, termsets, etc or updates to them. It is also announced there when a new review round starts for an archetype).

Your idea of notifying users that have experience/interest in a certain domain when an archetype for that domain is created is interesting.
One reason we have not pursued this so far, is that although the uploader is encouraged to classify/tag the archetypes directly after uploading, you often simply don’t do this immediately…and then of course you don’t really have a basis to send these emails. Also, how to organise the ontology and consistently tag the archetypes, is often less obvious than you may think.
But maybe we should revisit how we can make this functionality work.
Another option (in addition possibly) is to display all archetypes that currently fit your profile within CKM more easily.

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...

Ok, I subscribe to what Ian has said about how design by committee and the ckm process are different.

Very few people is only true for the editors, not the reviewers.
I am confident that anybody putting her or his hand up and willing to invest the kind of time required to become an editor for a series of archetypes will be more than welcome.
But let me assure you it requires a lot more time than you likely think.
Yes, timelines are an issue - again one reason why I think the archetype development and reviewing should be made one of the top priorities and we need to look how we can resource this internationally.
In national programs, where this is properly resourced, timelines seem to work quite well and a lot of progress has been made.

There could of course be a different more democratic approach to who is an editor of an archetype, and I am sure that the current process can be improved.
You may have seen the Orphan team on CKM - our initial idea here was that any team could pick up archetypes that are in there (and not being under the auspices of another team/editor).
If a team/editor would not act on it for too long, it would go back into this pool of orphaned archetypes for others to pick up.
However, the team approach never actually worked very well (it is too design-by-committee like if you so like) and therefore we more and more use ad-hoc teams of reviewers that differ for each and every archetype.

Cheers
Sebastina

Cheers
Sebastian

Hi Diego,

1. By invite only: I just learned yesterday of this 'editor' figure (I
thought all people were just reviewers). At this moment I don't really
know quite well which are they roles or who they are. Is there a way
to know who are the editors of an archetype? Editors must be
nominated, proposed or approved by other editors? (this is only a
hunch by reading the other replies)

{IAN] The editors responsible for any Archetype review are very
clearly identified in CKM.

See http://openehr.org/knowledge/OKM.html#showArchetype_1013.1.484 and
press Team.

2. Closed to outside participation or comment: I think this is not
intended, but currently relevant people could be left out just for not
knowing it. If only editors can nominate editors it will end being too
'endogamic'. If you don't want someone you disagree with to be part
of the archetype discussion you can potentially do that (if you don't
tell him he can be just unaware of this). You have to believe in the
good faith of the editors (and as seen on committee editing process,
this may not be the case).

[IAN] You will see from the example above or many of the NEHTA
examples that we do invite other people with special interest or
expertise to jointly edit many archetypes. In due course, with the
right resource and training, many of these people would become primary
editors.

We do try to get as an inclusive an audience as we can into archetype
reviews, balancing this against unwelcome 'spamming'. Sebastian can
detail the very many ways that CKM communicates new archetypes and new
archetype reviews to as wide an audience as possible, including
Twitter, RSS, emails etc etc.
Other suggestions would be very welcome.

As part of the review process we ask people to suggest others who
might become involved, and others are invited as a result.

Of course, in any governed space (and a CKM has ultimately to be
governed), one relies on the good faith of the editors, but that in
turn needs oversight and governance from the Foundation, so that if
these editors are felt to be acting inappropriately, action can be
taken. The relationship between the Foundation and the CKM Editorial
team will be part of the new Board discussions.

3. Physical meeting based, requiring significant resource: I give you
this one :wink: although this is something that official bodies could
improve easily

4. May be backed up by private email conversations: so can this (?)

[IAN] By this I meant that private email was very much part of the
normal business of standards development, not on any sense of 'deals
being done behind closed doors', although this of course can take
place. It is however closed to a wider audience who might want to
participate.

We do also sometimes communicate with reviewers privately, but only in
specific circumstances where such a private conversation is necessary
because the person involved does not want to derail the review process
with 'out of scope' concerns or has personal, commercial or
organisational reasons for not wanting to discuss this publicly. This
is very rare and we would always try to take any important and
relevant concerns back to the wider community in a de-identifiable
fashion. It is not part of the 'normal business' of a CKM review but
is part of the real-world experience of managing this kind of
activity.

I think we need to be careful to separate issues that arise from a
flaws in the CKM approach (there are some and we will identify more
with experience), from those which arise from not being able to fund
or resource this properly, including building up and training a bigger
editorial team, and the oversight of that team.

In Formula 1 terms, don't attack the car designer if it runs out of petrol :wink:

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

well, tagging doesn't need to be mandatory, but I think that everyone

with an specialized field should be included (or at least, invited) to
domain specific archetypes

That is exactly what does happen. Are you aware of any examples where
it has not?

It does, of course rely on people identifying their special interests
correctly and us tagging the archetypes appropriately (not always
easy). We are always very keen to have speciality experts involved,
since it reduces the editorial burden of doing background research and
of course lends credence to the resulting model.

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

Hi David,

I think the current tools are as good as one can imagine for this moment, what I mentioned was of the tools we need to the future, and maybe some ideas to add to the whitepaper. (I wanted to be clear in this point, sometimes my bad english doesn’t let me to express my ideas in a clear way, sorry for that).

What I meant with free&open tools was ment for the local and regional CKMs, and with a clear API, we could develope local CKMs that are interoperable with the global CKM (without changing any of the current great work).

Thank you David, I’m here to help in any way I can. I’m sure that openEHR is the way to go and I’m sure that we need to move forward together. There are a lot of great professionals in this community and I have learned and grow a lot since the first time I worked with openEHR in 2006. I regret there aren’t more coleagues from south america participating on this great community, that’s why I insist with the local openEHR communities, to engage this people (and selfishly to don’t feel so lonely :D).

Cheers,
Pablo.

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.

[IAN] It is nearly solved
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?

[IAN] Coming soon!

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.

[IAN] Thanks. Once we get some coherent thoughts/ proposals properly
documented, we will definitely open this up to a wider audience, and
your input would be very welcome.

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

[IAN] Absolutely. Individual commits will always take place but will
inevitably result in a loss of coherence between dependent artefacts.
Part of the idea of Release sets is to give an extra level of
assurance to consumers that any dependency issues between artefacts
have been at least minimally resolved i.e all templates have the
correct version of archetypes, termsets available.

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

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.

[IAN] You should start a discussion with Sebastian about how this
works. There is a lot of interest in web-based openEHR
archetype/template tools. I am not personally convinced that this
makes sense, any more than web-based Eclipse or Visual Studio makes
sense, but I am willing to be convinced otherwise. We certainly need
to integrate any authoring tools, web or desktop, much better with
repositories such as yours and CKM but these have to be able to
support the local developer private authoring phase.

Is there any potential for using your work as part of the openEHR
community repository idea? Derek Hoy of Snowcloud might well be
interested in further discussion in this area. He does lurk on these
lists but I will give him a nudge.

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

federating things is always a challenge, I´m a doctor not a tecnology
guy, but I think that middlewares like an ESB helps, am I right?

Hi Jussara,

It is not really a technical problem. The platform that CKM is built
on will actually support federation fairly easily. The challenge is in
knowing what and how to federate, which itself is much more about
governance of the assets and how cross-repository change requests and
other communications will work.

We are right on the cusp of having to do this for some CKM instances,
and while hooking up a CKM with a non-CKM repository will definitely
bring some technical challenges, our feeling right now is that these
are fairly easily resolved once we get a better picture of the real
requirements.

As always, the technology is the easy bit.

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

than is about business needs

Hi all,

There are (at least) three artefact production processes:

  • one for the author('s) designing unripe artefacts. This is the initial design, authoring phase.
  • one for public, more ripe, draft artifacts that are shared with others. This is the reviewing, QA, phase.
  • one for active published artifacts, This is ‘officialpublished artifact phase.

Each of these processes has their own ‘state model’, meta-data attributes, rules, etc, that must be managed by any artifact repository via a standardized interface.

GF

Gerard Freriks
+31 620347088
gfrer@luna.nl

I think is mainly a governance issue: a set of rules and guidelines to coordinate distributed work, in order to provide solutions to business needs in a consistent and compatible way.

Governance is an internal problem, and business needs is an external one.

Hi Gerard

I think this will be too heavy a process - I would go for candidates in the first phase. Mind you for local archetypes, replicating the central process seems appropriate if there is a sufficiently large user group.

Cheers Sam

Heavy?

This reality.
Who said that real life is simple?

To provide for these three real life processes takes the correct set of attributes per artefact.
What is so complex about that?

Gd

Hi Pablo

Thank you for your warm support. Don’t be at all concerned about how you express your concerns - they are clearly stated and well-understood. I once heard it said at a conference that the universal language of international collaboration has become broken English spoken slowly! My family is half Polish and I speak very broken Polish, all over the place. I’m not sure how I’m going to manage with broken Chinese, though!

The current discussion, at all levels, is heart-warming as it confirms, to me at any rate, that now is exactly the right time to be pushing forward into new territory, and involving new people with the strategy and governance of openEHR. I might even now change my maxim about the three most important challenges faced by openEHR, from implementation, implementation, implementation (which dominated my perspective and approach and, admittedly, resulted in rather too limited a focus, in the bootstrap era of openEHR and then 13606, on important community governance issues) to implementation, clinical engagement and goverance, all of which now matter, pretty much on a par with one another, for effective and sustainable future endeavour in the field.

Best wishes,

David I