Downloading previous versions of archetypes from CKM

Hi,
I had used some archetypes from CKM in my templates some time back. Now when I am revising & reviewing them I notice that some of the archetypes have newer versions an so my templates give error as they are unable to locate the older versions that they use. So I have a few questions on the best practices for using CMK resources

  1. Can I access older versions of archetypes from CKM? and how?

  2. Should I maintain a copy of the archetype versions that are used in my templates separately?

  3. Are archetype versions incremental improvements? If yes should the AQL not support multiple versions to maintain backward compatibility as the templates evolve?
    regards

You might also have problems with some archetypes that went from .v1 to .v0

In the archetype history you can see the previous versions, but some will have a broken history, for instance some archetypes changed name and archetype id but serve the same purpose as the old archetypes, which broke any implementation of the previous archetype. Also there is no clear history of archetypes changing ID or merging archetypes.

Because of those issues is difficult to trust what is on the CKM in the long term. I decided to work with older archetypes to keep my baseline clean and stable, do modifications on those if required, and create our own archetypes when required.

I’m not sure if this is because how the CKM manages archetypes, or because the modeling process have flaws in the version management.

Hi

The v1 to v0 migration was a once off thing that was decided to be the best for never before published archetypes.

I’ve never been a big fan of v0 because of the all the complications it has, but at least it tells you clearly that all bets are off regarding this archetype because it is under development and anything goes, including changes to its archetype id, if required.

V0 is also consistent with SemVer (although you could do it differently as well, e.g. 1.0.0-alpha).

After publication to v1, the governance is more formal and follows semantic versioning of patch, minor and major versions.

It may not always be nice, but unless someone can provide a comprehensive, clean and perfect set of archetypes, that’s what life will be for a while. CKM aims to support the processes around the development, review and publication of the archetypes etc. as much as possible.

In CKM, the revision history of an archetype links back to any previous (or next) major version of the archetype. See e.g. the Blood pressure v2 archetype. You can get any (trunk) revision of the archetype that was ever uploaded to CKM from there and compare any two revisions. Archetypes that were updated in the last couple of years will have the SemVer version in it as well, and there is always the canonical hash (the one used in the template) you can use to determine the right version of the archetype if required.

I hope this answer your questions below and provides a bit of context in between.

Regards,

Sebastian

Hi,

Thank you for all the responses. It has helped me clear a couple of of things that need to be keep in mind while using resources from OpenEHR CKM. Just to summarize,

  1. Archetypes in v0 are to be treated as initial suggestions and can change anytime and without any pattern. Published ones from v1 are more stable and the changes managed better.

  2. Using V0 is at one’s own risk and so keeping a local copy would be advisable

  3. CKM allows viewing and comparing version history using archetype history

The above raises some additional questions

  1. What are the specific steps/links to download older version of archetypes from the CKM. The archetype history allows comparison between versions. But I could not find any link to view/download older versions.

  2. Majority of the archetypes in CKM are unpublished v0 versions. So it is difficult to build any meaningful CDR currently using only published archetypes. What will be the best strategy to keep moving forward with creating real solutions while keeping the spirit of OpenEHR relevant.

  3. Managing copies of the archetypes that are used separately by different users is bound to create fragmented schema across openEHR compliant CDRs, thereby defeating the fundamental premise of interoperable schema among OpenEHR CDRs.

regards

Adding to what was commented, there is a gap between implementers and the CKM/modeling process.

  • implementers will use any archetype, even drafts, that are published on the CKM, because those might match the requirements, so for that implementer the archetype might be OK.

  • implementers can’t approve archetypes to move from draft to published, can make suggestions to improve them, but not change their status.

  • the modeling process allows those draft archetypes to change anytime in any way, generating potential incompatibilities with the revisions downloaded by implementers, and that can only be checked manually, by each implementer, for each modified archetype. I did this and could take a whole day to review an archetype and analyze incompatibilities.

  • for implementers is difficult to track archetypes they (we) are using, to see when an archetype that we use changes and compare to find potential incompatibilities. Current tools allow to follow an archetype and be notified by email when changes are done, and the CKM has a compare tool, but is all a manual process. An ideal scenario would be to have a record of the archetypes someone is using, and when a new revision is published, run the diff between that and the revision the implementer is using, and notify of possible incompatibilities, that way we can know exactly what’s wrong and fix accordingly.

Another point is that AFAIK current clinical modelers are voluntary, which I think the Foundation should consider funding to have more archetypes reviewed and published, than having most in draft. There is some money on the Foundation, let’s use it to help the community, and also give something back to our core clinical modelers. We need a dedicated team for these things.

An ideal scenario would be to have a record of the archetypes someone is using, and when a new revision is published, run the diff between that and the revision the implementer is using, and notify of possible incompatibilities, that way we can know exactly what’s wrong and fix accordingly.

User can have an option to maintain this list in their CKM account and use it for comparison

regards

To download, for example click on the Details Button underneath each archetype revision in the revision history.

You can also keep track of all the changes in the git repository at https://github.com/openEHR/CKM-mirror

While I obviously agree with the aim of everybody using the same archetypes, it is probably still a bit of a lofty aim.

Nonetheless a lot of progress has actually been made and it is my understanding at least that many of the more commonly required archetypes are published. Even so, I would see the RM as the core schema, and that doesn’t change if you use different archetypes.

Pablo, yes, agree with funding, but it always seems that everybody wants something.

Re automating comparisons, maybe we should look into exposing this via the api as well somehow.

Nonetheless, the semantic version and also the log message should at least give an indication of the type of change and impact.

I think Ian and Bjorn have some packaging ideas to better support implementers – this is somewhat the other side of the modelling coin, but important of course as well.

Sebastian

to download, for example click on the Details Button underneath each archetype revision in the revision history.

You can also keep track of all the changes in the git repository at https://github.com/openEHR/CKM-mirror

Thanks Sebastian. That is what I was looking for

regards

I’ll let Silje and Heather talk more about overall progress with the publication [process but we all have ot recognise that this is a huge job which just takes time. As Sebastian has said most of the work done, even at an editorial level is done by volunteers, in particular, the Norwegian CKM team are giving a lot of their time for joint development. The Foundation has been able to fund particular work that Heather is picking up right now and broadly speaking the Clinical and Specification sides have a similar budget. This is all down to vendors, organisations recognising the huge value that we all gain from this collaborative effort. Yes it takes time, and yes we can always do more but I do see steady and useful progress.

I would say that no developer should be relying on any CKM or indeed any remote repository as their source of truth. These artefacts should all be regarded in exactly the same way as a third-party software library. Download and maintain local copies, in whatever environment you prefer (I use git). There is definitely a gap in having some developer-tooling to support this, and as Sebastian says, we do need something more akin to Maven or NPM to manage the increasingly complex dependencies.

I am more confident than Sebastian that we will reach a high degree of alignment of versions of archetypes as these mature in CKM and in vendor systems but it will take time and effort. This is a vastly complex world. The openEHR process my seem slow and a bit chaotic but I still believe it has shown itself, so far to be the only means of tackling this complexity at any sort of scale.

So sign up, get involved.

Ian

Thanks both,

Very helpful. Just in case folks get too negative about what we have achieved, I am currently working on 4 different regional/national EHR projects. On all 4 projects, 80% of the content is covered by published (or at least very stable) international CKM archetypes. Once you get to local, detailed applications coverage drops but it is here where the ability to develop and deploy local or vendor level archetypes really shines. In my view the ability to rapidly deploy local or evolving archetypes is at least as useful as broad interoperability per-se. The latter is also always going to be dependent on the alignment of clinical practice, legislative change, terminology use etc,etc none of which are directly within our control. We have a set of medication archetypes that are being used right now in multiple systems to deliver full hospital and comunity prescribing systems, supporting structured dosage and timing - that alone is a very significant achievement

Given the minimal resource we have had to work with, nearly all coming from supportive commercial organisations, I think we should be pretty proud of what has been achieved, and it is getting better all the time.

We do need to have better dependency management and better tools for local deployment but ultimately this is a community effort, so if you have ideas or software resource, please pitch in.

Ian

Very timely discussion as we are hitting this issue right now in Scotland, and meeting together tomorrow to agree an approach - hopefully Silje and Ian joining us for that.

We need not just versioning management of the content but also a way to agree a coherent set of archetypes and templates for our national CDR.

So these are two things: #1 models versioning and management and #2 content management.

CKM it seems will let us handle some of the versioning and it definitely will help us with the review processes / editorial / reaching consensus but we need other things for handling which version of which model is actually deployed in our CDR, and then we need something else for handling ‘here is all the content for your EHR’ to establish gaps and avoid duplication.

All these things need to be joined up so that it can make sense to clinical and developer teams using it. That joining up process seems likely to be fairly bespoke - combination of tools like CKM /GitHub / others? and also needing a human being or two being in charge, or at least having oversight of the whole process.

If and as we evolve our processes I will update the list.

Paul

Hi Paul,

Nicely summed up.

You definitely need to manage your CDR artefacts in just the same way as any other software libraries. This is currently more manually intensive than it should be but one can see how it could be largely automated

However, maintaining coherent semantics is much more challenging as you need to consider how each new app or datastream fits into both some sort of attempt to keep a longitudinal record, with the need to preserve condition/ episode or pathway data quality. That is hard and will require human beings to design and continually adapt. For LHCRE purposes and beyond I have made a start at a baseline architecture of templates that should be applicable to a broad set of communities but it will require customisation, depending on local circumstances. e.g can we apply the rule that there should only be a single allergies list for the whole community? Do we have sufficient vendor buy-in, and clinical buy-in, and the governance structures to resolve any differences of opinion or to challenge poor data quality. As GPs we have been used to this sort of challenge within our own practices - are we able to scale up to a wider community of practice.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: ian@freshehr.com
twitter: @ianmcnicoll

Director, freshEHR Clinical Informatics Ltd.
CCIO inidus Ltd. ian@inidus.com
Co-Chair, openEHR Foundation ian.mcnicoll@openehr.org
Hon. Senior Research Associate, CHIME, UCL

Interesting discussion and I agree with Ian that the openEHR community should remember to give itself credit for what HAS been done, with very little resource, rather than beating themselves up about what tooling is missing from the ecosystem.

An automated archetype package and dependency manager, as well as archetype version migration tools, would be great to have. It should work like package managers in other language ecosystems such as NPM, RubyGems, PyPi etc. We need to get some resources behind this idea, maybe we could collectively encourage the new NHSx to think in this direction?

Marcus

Hi Marcus,

Thanks for your support.

I would love to see NHSX support something like this, especially as I know the FHIR folks are going down that road and we need something that goes well beyond just openEHR artefacts and into termsets, valuesets, rules etc. Every community working on health semantics will need something like this, and we will all need to be able to reference artefacts from other standards groups.

I have been looking at NPM but Bit https://bit.dev/ might be interesting and fit better with our paradigm which is more about components than code per-se.

Ian

Ian

Hi Ian/Marcus,

Thanks everybody for a healthy discussion that I am sure will help many implementors.

My idea was not to belittle what the community has achieved with the limited resources. That would be unkind on my part to all the community members who have(and continue to) invested their time and knowledge to get to where we are today. But as more an more real world implementors are beginning to commit to the OpenEHR philosophy, it is important for them to be aware of it’s limitations and hedge adequately against them. So if we are able to evolve some best practice recommendations out of this discussion, we would have taken one more step forward.

My two bits after reading through the discussions. This is a complex problem that may not have a full solution immediately. It is going to be a combination of tools, people & processes for some more time till the tools mature. CKM does some bits and the implementors need to take over from there and evolve local processes. Sharing of such local processes will help others and mature the community tooling over time.

Thanks once again

regards

Hi all

A welcome discussion.

CKM is the public face of much of the openEHR community’s work but it is not the only solution required for seamless archetype management from design through to system development.

At present each vendor is managing their own archetype repository individually, as they should. However requirements for local governance will have lots of commonality. Some vendors suggested that they needed a lite version of CKM for the purpose but I’ve always pushed back because it needs to be connected to CKM to be informed of any changes and updates (or via GIT or whatever tool we use). But the critical thing is the ability to know which archetype version is in which application, which version of each application, where there might even be differences between modules etc. Then if there is a CKM change, the vendor can make an informed decision whether to update or not, and that clearly has significant downstream costs and implications.

I suspect that the reality is that when each new module or app is built everyone uses the latest version of an archetype, whether published or not – from a pragmatic point of view it is an implementer’s best bet of having the most future proof archetype, despite knowing that a draft could evolve and diverge significantly. But the alternative of making a local one will absolutely guarantee a divergent model, so we’re talking about making least worst decisions here.

As curators of CKM Silje and I are very mindful of this. More recently, as a new archetype has been proposed or developed we are trying to ensure it fits with existing patterns and how we perceive (from experience) that the archetype might evolve, to try to mitigate major changes. So it is probably fair to say that as a general rule, the more recent drafts are possibly better quality and less likely to diverge drastically, but there are no guarantees. And of course there is a pool of draft archetypes that have been in CKM for some time, before these patterns were identified - we will gradually endeavour to clean these up, but it will take time.

This clinical modelling effort is clearly still a work in progress. Archetype by archetype the CKM offering is improving and becoming more stable. The famous (infamous) archetype sprint is nearly over, despite the effort being underestimated, the goal, intent and focus was always good. We only need to finalise lab test results and apply those learnings/patterns to imaging, if memory serves me correctly. That will signify completion of an initial core set of archetypes with broad reuse over any EHR application.

Our collection of archetypes is something we should be immensely proud of. This really is a world first - there is no equivalent effort to compare with in terms of public clinical information models. And the repository will continue to evolve and improve, both in terms of numbers of models and quality.

I’ve nearly completed an estimate of the number of hours of modelling effort for the archetypes governed in the international CKM to date. The calculations need some final tweaks, confirmation by some of my co-editors and we’ll make the findings public.

But we do need to consider the other tools required to support and manage the complex governance that has to happen for each implementer, each application, each module etc.

Kind regards

Heather