The openEHR Clinical Knowledge Manager (CKM) is a unique resource for the specification of health information that will become part of people’s lifelong health record. The work raises questions. What more do we need to develop and manage high quality specifications for health information suitable for sharing between clinical applications? How do we manage the tension between harnessing the richness of contributions from the large and enthusiastic community of clinicians and health informaticians and ensuring that the specifications are comprehensive and internally consistent? This has been weighing on my mind over the past couple of years as our team have developed a Web 2.0 approach to openEHR clinical knowledge collaboration.
CKM is an international, online clinical knowledge repository providing digital asset management throughout the authoring, reviewing, publication and update lifecycle of these specifications. It has been designed to provide governance capabilities, and facilitates collaboration by registered participants. The full range of openEHR clinical knowledge resources – archetypes, templates and terminology subsets – are now managed in this environment.
Under the auspice of the openEHR Foundation, our goal is to offer a clinical knowledge management ecosystem in which: the knowledge artefacts are based on open specifications; the service and programming interfaces are openly specified; and the production data representations are also openly specified. Archetypes are freely available under a Creative Commons license.
The focus of CKM to date has been to publish a coherent set of archetypes that can be use by national body or health application developers in projects that involve shared EHRs. These archetypes have developed in different projects, including work in partnership with the UK, Singapore, Australian and Swedish eHealth Programs and in collaboration with clinical application developers building working systems. The work has also been influenced by the openEHR international community’s proposal to develop a set of high quality archetypes to support a shared Emergency summary. These ‘top 10’ archetypes define core clinical content in many common clinical scenarios.
The intent for current CKM archetype design is to make it possible for them to be used across any and all clinical systems – ‘global’ archetypes. By design these archetypes:
- Are a maximal dataset to maximise inclusiveness and uptake;
- Are re-usable across universal use cases;
- Are an internally consistent set;
- Minimise model overlap;
- Are based on generic patterns (which are evolving and design pattern principles are becoming clearer);
- Support further specialisations to meet local or specific domain requirements; and
- Provide design guidance for archetype development for similar concepts.
The draft archetypes currently in CKM do not meet all these requirements but as they progress through the publication process are brought closer to this ideal. As requirements develop (and health care changes) the archetypes will be revised always seeking to maintain universal sharing of the very important health information held in a lifelong record.
At the time of writing CKM has acquired, largely by word of mouth, 556 registered users from 62 countries, including 179 people who have volunteered to review archetypes, and 72 who have volunteered to translate archetypes. The repository contains 273 archetypes, of which 15 have content that are in team review and 9 published. Two example templates have been uploaded, and we await final publication of the template specification before we expect to see templating activity increase. Terminology subset functionality has been added only this week and our first SNOMED subsets uploaded. This enables CKM to become a ‘one stop shop’ for clinical knowledge resources online.
Current CKM functionality includes:
- Display of artefacts including structured views, technical representations and mind maps to make it easy for clinicians and others to review;
- Uploading of new knowledge artefacts – archetypes, templates and terminology subsets – for review and publication;
- Archetype metadata supporting classification, ontological relationships and repository-wide searches;
- Digital asset management including provenance and artefact audit trail;
- Integration with openEHR tools supporting quality assessment & technical validation checks;
- Review and publication process for clinical content – draft, team review, published and reassess states
- Terminology binding and terminology subset reviews;
- Online archetype translation with review;
- Community engagement via threaded discussions, repository downloads, attached resources, watch lists, email notifications, user dashboards and release sets;,
- Editorial support via do lists, user and team administration, review management, artefact modification, classification management, broadcast emails etc;
- Subscriber auto-notification including Twitter and email
- Reports – Archetypes, Templates and Registered users
Transparency is a key principle within CKM. Editors are accountable to the community at every step; all comments, review rounds, changes etc. within CKM can be seen by the users. This ensures that if a user flags an issue, it is managed publicly and the user community can comment on the resolution.
Editorial work and fine-tuning the archetypes towards publication takes time and with a small number of volunteer editors the work has been a little slower than anticipated. Interestingly the rate limiting step at present is availability of the editorial support, NOT an interested community willing to contribute their expertise – joining the community largely only by word of mouth, they are motivated and willing to contribute whenever requested!
Yet we are very pleased with our modest achievements to date:
- A reasonably robust tool built through real experience;
- Established processes for the transparent governance of the range of openEHR-related clinical knowledge artefacts; progressively fine-tuned as we identify and understand the issues involved; and
- A motivated community supporting us and keen to participate in a web 2.0 environment.
Perhaps most important is what has been learned about knowledge governance – a relatively new domain. We anticipated complexity and the more we advance the CKM tool, the more we discover! This is an exciting and challenging journey.
We are ready now to encourage and embrace greater participation – harnessing the collective intelligence of the CKM community – through development of an archetype ‘pool’ where users can share their work on archetypes, templates and terminology subsets – a stepping stone into the tightly governed ‘global’ archetype pool. Some of these community archetypes will be developed for other purposes than the ‘maximal data set, universal use case’ scenario and provide valuable intermediate steps to support existing protocols and work to be used in a shared health record. We want to enable these to be shared and reused while at the same time encouraging work towards more general and broadly shareable solutions – all will benefit if we can share and learn from each other.
We continue to look for ways to help developers and implementers get what they need from CKM and this is an ongoing work. One important development is the ability to federate instances of CKM with the international openEHR service which offers a way of keeping national/jurisdictional efforts aligned but independently managed. Release sets of coherent archetypes are also a high development priority.
There are a diverse set of requirements and a growing set of artefacts – no simple one size solution that fits all. We can’t simply declare that we need a ‘top down’ or ‘bottom up’ approach. Sometimes leadership will be key, sometimes democracy.We are aiming for a pragmatic mix, with accountability to the community through transparency of process being paramount.
To our thinking, generating formal and computable health information specifications conveniently and openly on the web by a motivated, international community of grassroots clinicians, informaticians and implementers is potentially world-changing. And perhaps even more exciting, we are enabling our domain experts, the clinicians themselves, to make sure that the data within our EHRs is safe and ‘fit for purpose’.
We are on a journey to create a clinical knowledge ecosystem – and this is the state of the CKM!
Special thanks to Sam Heard for his editorial assistance.
And to the CKM team – Sam Heard (@samheardoi) in Australia, Ian McNicoll (@ianmcnicoll) in Scotland and Sebastian Garde (@gardes) in Germany.
Don’t forget to follow @openEHRckm for notification of CKM activity and updates.