As the well-versed in archetype ID conventions will have noticed, Pulse is a specialisation of Heartbeat. This is based on the intent behind most pulse measurements, which are intended to be a least-invasive proxy to observe the action of the heart, contrasted with observing the heartbeat at or close to the heart itself.
The requirements in this area are partly conflicting, where in most use cases there is no need to clearly differentiate between the two, in some specific use cases this is vitally important. The archetypes have been designed so that Heartbeat, as the parent concept, will be used for most recordings, to represent any observation of the action of the heart, whether observed via the proxy of a peripheral pulse or at the heart itself. Pulse will only be used for recording specifically the observation of a peripheral pulse. However, in use cases where the two archetypes are both recorded in the same context, Heartbeat should be understood as representing the heart action specifically at the heart.
We’d like to get some feedback from the community before moving on with this pattern.
I have concerns, primarily around this being a breaking change, for a widely used archetype, without an easy migration path. I like the idea of mitigating this by using specialisations. But fundamentally they are different concepts that can be unrelated: you can have a pulse without a heartbeat (eg cpr) and you can have a heartbeat without a pulse (eg VT). So at least conceptually the specialisation pattern doesn’t hold.
But I agree it usually is used interchangeably and most use cases don’t care. And up till now the conclusion was: where it does matter, the measurement location is used to determine which of the two concepts is intended. You’re reason for making this change is stated as:
I’d like to know which use cases and why the current pattern of differentiating using measurement location doesn’t work there.
I’d also like to share that the Dutch zibs (clinical information models) have separate models for these two concepts, and it doesn’t work well in practise and is considered a legacy problem.
I haven’t made up my mind on the solution and I’m open for reopening this discussion, but I do feel strongly there should be a wide review round in CKM if we do make changes. The impact is (potentially) too big to rely only on an editorial decision with community input.
Really appreciate the effort to resolve this tricky conundrum.
I think I’m very much with Joost on this.
I’m reluctant to see such a significant breaking change on a very commonly used archetype without a clear need.
Whilst undoubtedly ontologically correct, the difference between heartbeat and pulse is really not significant or recorded in the vast majority of usages, and generally not predictable ahead of time.
Devices will be swapped or not, patients will develop conditions where the difference does become critical (or not), but we cannot know that ahead of time.
I do understand the need to differentiate clearly in some contexts, per patient or clinical setting but I don’t understand why that extra information could not be applied to the existing archetype, with a new optional element if required, that would allow pulse/heartbeat to be differentiated cleanly in those few cases where it is significant.
I’m not sure that’s practically feasible. For example when data is automatically entered coming from a vital signs monitor. And even with user selection, how do you create an interface that makes this distinction clear to a user?
And it’s not always black and white wether the heart is beating I think.
The previous archetype was always an awkward fudge but never really worked well.
This topic seems to polarise people - those who want one model that does it all and others who clearly want to separate the pulse from central measurements. This will only become better over time if we offer the approach we think will take us forward towards better data in the future and I agree that the separation will be an improvement.
We still have a messy area where it is not specified whether it is a heart observation or arterial, but if we offer the models, then we have a chance that UX design will change accordingly for the semantic good. In the meantime, perhaps we can offer a mapping between the two generations of models.
In principle, the job of the CKM and the International Editors is to promote best practice/data quality. It is then a choice for implementers to update or not. While there may be many systems using the current dodgy model, that is not a justification for perpetuating a model that is not doing the job as best it could. For every new system that implements the dodgy version, we accumulate technical debt and potential ambiguity, and the difficult decision to make the change becomes harder as time passes.
Let’s make the hard decision sooner rather than later. Future systems, clinicians. AI, CDS, research etc will thank you.
Could you please share some information on in which way it doesn’t work well?
In my moderate experience with the model, the only issue I found was not being able to map to the zib models which separates the concepts. But based on what I shared before, I don’t think that in itself is a reason to make this change.
I don’t have experience with advanced cases, mentioned before. So I’m curious to learn more about the real world impact of the current design.
Btw I don’t find myself on a polar side on the issue itself. My main worry is the breaking change leading to fractured adoption. Universally adopted, stable models focussed on real world use cases is imho what sets CKM apart.
This fear is heavily influenced by the ADL2 coding system situation, which is definitely better practice over ADL1, but given the prohibitive migration costs, after 10 years, it’s being ‘reversed’.
This is the only archetype that tries to capture two concepts, very similar but quite distinct, at the same time. Problem/Diagnosis is slightly different in that it models a continuum.
It has become increasingly obvious to me that a critical modelling principle is that we should be painfully unambiguous in our modelling of clinical concepts and semantics and let the issues of how messily this gets recorded to be pushed to the UX and system implementation level. The data structures should not be compromised or we will always have compromised/messy data.
I’ve been heavily involved in trying to make the original mixed model clearer from 2006. Despite many attempts, it has never felt comfortable and clear how it should be used.
I’m not sure that stability is so important - rather governance, quality and credibility.
I have no problem with redoing models if we find they’re not right. That is what good governance is all about in this domain. And the other side of that is also to design carefully, make sure it is reviewed properly, and not rushed to publication with controversial data elements, exactly because of all of the downstream implications.
I don’t make recommendations to deprecate a published archetype lightly. We’ve learned a lot since the Pulse/Heartbeat was first published - in design, review and governance. I am also much more rigorous in trying not to let something be published that we suspect is not designed to withstand the test or time or be extendable. Let us learn from the Pulse/heartbeat archetype saga, to avoid technical debt, and not perpetuate troublesome models for the next 50 years if we can create a better solution.
I agree stability is not too important in itself. It’s about adoption. If something is so unstable it doesn’t get adopted you lose the mission of the lingua franca of healthcare, right?
And if it happens too much or to models that are widely used, we risk that CKM as a collection of archetypes looses credibility and that would be an even bigger issue.
I actually regularly point to pulse/heartbeat as to why CKM has better models than zibs. Because CKM models are designed for real world implementation and zibs are designed “conceptually” (and the designers are not very accountable to the real world of implementations).
All this is not to say we shouldn’t change a model if we know it’s not right. As said I haven’t made up my mind on what would be the best pattern. And moreover in the end you have much more experience in this regard than I do, so it shouldn’t even be about convincing me.
I’m just saying that, the adl2 experience taught us, if the benefits of changes to a model are too small compared to the cost of migration, it will get reversed (n=1, but still an expensive one).
On the other hand if the editors agree that the benefits will outweigh the risks, leading to adoption over time, of course historical legacy is less important than future benefits. Because historical data is limited to what is there today, and the future is (hopefully:p) much longer. Saying this it would be good to get input from implementers (software engineers) on the impact and willingness to upgrade for this change, agreed?
Could you please share a bit more on why this is obvious to you in this case? I agree in principal, but I’m worried in this specific case that the clinical reality of pulse/heartbeat as a recording concept is so messy itself that it will be too hard to solve at the UX level. Do you have thoughts on what interactions patterns could solve this? I’m thinking ‘adl expression language in rules’ could help a lot, that depending on the measurement location the right archetype is selected for you. Unfortunately that’s not been implemented outside of Nedap.
If we could do this, this would help a lot. My worry is that it is only possible in the small minority of cases where the method/body site unambiguously implying either a pulse or a heartbeat (palpation of art. radialis is sufficiently conclusive to be a pulse, but palpation itself could also be palpation of the heart (usually indirectly, but not exclusively: I’ve done direct cardiac palpation once during cardiac surgery:B). Would be good to get some statistics from deployments.
So if we agree the move here is to make the archetype more correct and we agree the pulse isn’t always a heartbeat, would it be an alternative to make pulse/heart beat the parent and and specialise it into two children: pulse and heartbeat?
That way we can keep the current archetype and data, and importantly AQLs working (assuming specialisation is implemented in the AQL implementation).
And it offers a clear point for situations that require strict distinctions. And it will be more ontologically correct imho than specialising a heart beat into a pulse.
Interestingly snomed disagrees with me here, they define pulse as a “Heart rate measured at systemic artery”. I still believe this is conceptually wrong, as explained above, but it’s definitely interesting to hear there experiences, especially around querying.
And if we learn that the pulse/heart beat parent isn’t working well anymore, we can deprecate it later. If we do this, it will be important to have a very clear description in the use/misuse sections.
As an implementer I find this change dramatic. The previous archetype must be really really bad to propose a change in core archetypes like this. I assume its being used in all openEHR based systems all over. The cost of change is enormous.
And for newbies to openEHR it will be hard to know which of the archetypes should be used in the models (templates), the new ones or the old ones depending on the capabilities and roadmap of the different implementations you will run your applications on.
Should the CKM serve as a repository for existing clinical system models (similar to FHIR), or should it act as a blueprint for future system enhancements, research, data aggregation, knowledge activities, and innovation such as AI and personalized medicine?
Is CKM’s role to maintain the status quo or to encourage the adoption of evolving best practices in modelling and data representation?
Each approach has an inherent cost, but continuing to use models that are considered outdated and in need of revision goes against the vision of a cohesive data ecosystem.
After all, there is no requirement for vendors to implement the proposed new models.
It troubles me that this reason is used as an excuse not to advance public models. The cost of updating this archetype is trivial compared to the technical debt accumulating in systems that implement ‘quick and dirty’ archetypes, never intended to shared, much less proposed to CKM.
The community would be better served by initiating an open discussion about the hidden archetypes, their costs and their adverse impact on interoperability, rather than obstructing the progress of an ‘OK’ archetype into one that offers clearer semantics.
I would like to join this discussion after also consulting my anaestiologist wife. I think these two should separate conceptually. Pulse is in most clinical contexts the important one in itself. Because it reflects circulation and perfusion not as a proxy variable to the heart function. The heart rate which most call it rather than heart beat is of course also often interesting but if not leading to significant pulse not so much. Note that peripheral pulse maybe absent in many cases when blood preassure is low or when there maybe is a clot in one artery.
I also want to add the discussion that change of an archetype already in use is a big problem. There must ve a very good reason.
Cheers Gunnar
This is a question of release management. Just like in software or standards development (ADL2 versus ADL1.4 for example), we need two things: stability and space to innovate. These can only co-exist with a proper system of releases, where a new ‘major version’ (see http://semver.org) is required for breaking changes.
User organisations can then choose which release to use, and can control their adoption of newer releases.
Adopting a new major release is still a painful thing but it’s a) under control of the adopting org and b) the differences are clearly documented (one hopes).
The practical question for us here is the concept of ‘releases’ for the totality, or perhaps large sub-components of what is in CKM. At the moment we only do version control on a per model basis, as far as I am aware. I know that @sebastian.garde and others have thought about this a lot in the past, but we have not solved it.
Being able to independently release large components, probably defined on the basis of specialty (e.g. ‘core’, ‘lab’, ‘paediatric’, ‘oncology’, etc) would be better than having to manage everything in a release. We would need a method of dependency analysis to determine what the knock-on effects of a new release of one component (e.g. containing heart rate/ pulse) on all others. Again, I know CKM have capabilities in this area.
In sum, both points of view are valid - we need a strategy to allow both stability and innovation to co-exist.
We certainly don’t want to prevent the creation of better archetypes. It’s the same with a better version of ADL, or a better Reference Model. We need a place to do those things, such that they don’t break things already deployed.
It’s not quite so simple - because once models are published, they get turned into software, data, queries and so on, and all this creates inertia, such that breaking changes can be very costly. Many ‘good enough’ models serve 99% of many user needs perfectly well, so a high cost change that addresses something in the 1% of use cases is not going to look very attractive.
Clinical knowledge governance in CKM is not focused on the release management of collections of archetypes or the whole of CKM. The focus on agile governance of individual knowledge assets (archetypes) has been one of our main success factors, in stark contrast to the way most other software or specification standards operate.
This has been the CKM practice for many years - clearly documented here: Archetype Identification, and underpinning CKM functionality. Authored by you, contributed to by myself and knowledge governance experts, and used everyday.
I am very empathetic to the concerns of the software vendors, but I don’t believe that the solution is to limit archetype progress in CKM. Many other stakeholders have competing requirements that also need to be factored into CKM knowledge governance decisions. The change management issues of a single archetype for a vendor is a symptom of a much bigger issue. Our clinical colleagues would recommend treating the condition, not the symptom.
For CKM to maintain its credibility and reputation as an international resource of high-quality information models, it must maintain a neutral position, not aligned with any single stakeholder, yet simultaneously trying to balance the needs of all. Our primary focus remains the design, develop and govern a coherent ecosystem of archetypes.
Many other stakeholders need or want access to high-quality archetypes. Some will go on to deployment, such as developers of new systems and national programs setting up their CKMs such as Catalonia. Some will never deploy openEHR directly - CKM is the ‘go to’ place for many other stakeholders, including FHIR, and it is in the interests of global good to produce and publish the best archetypes we can produce.
In turn, each type of stakeholder needs to take some responsibility for how they access or use CKM artifacts according to their requirements. There is a significant opportunity for openEHR or others to offer tools and guidance to support vendors and software developers in managing the complexity of their archetype libraries. CKM is not the right tool for this task.
The vendor-level knowledge governance challenges include:
local or ‘quick and dirty’ archetypes that begin as temporary fixes but become deployed, especially when they evolve locally without governance or rigor;
CKM draft (v0) archetypes that were the best available option at the time, but eventually got published and evolved further;
published CKM archetypes, including tracking and alerts for new revisions or versions - to make informed decisions on whether to adopt and implement, or wait; and
identify/track downstream consequences of all of the above on queries, clinical decision support, artificial intelligence, etc.
So many moving parts. Even if CKM never changes again, as software evolves, the knowledge governance within any application will always be a gnarly problem.
Given that chaotic context, let’s acknowledge that a breaking change in a single archetype in CKM is really not so catastrophic that it warrants blocking progress, improvement or correction of an archetype.
I was one of the ‘others’ who you referenced. As product manager for CKM at the time, a major government client wanted to package multiple artefacts together - a collection of archetypes and templates (including a selection of specific, older versions of artefacts when the public/trunk models had progressed) plus implementation guidance and other documentation - to publish as a governed release set for a specific purpose, at that point targetting a national standard for a versioned message/document. The release set functionality was designed as a selected subset of CKM assets for a very specific purpose, never intended as a version of all CKM artefacts. It has never been used in practice as far as I’m aware.
If the industry members want to package up a release, as you suggest, including a selection of outdated artefacts known to be deployed within certain implementations, the tooling potentially makes it possible. However, this activity is separate and should not interfere with the governance and progress of individual archetypes. Feel free to explore.
The current knowledge governance process does not take a stance on whether outdated archetypes need to be upgraded or not. It is quite reasonable that archetypes don’t get updated immediately within a clinical system; in fact, some may never need to be updated. In practice, outdated archetypes can continue to be used in systems for as long as the vendor desires; even if deprecated as part of the CKM governance process, the archetypes remain available within CKM.
In the case of these Heartbeat and Pulse archetypes, let’s face it, the far majority of clinical systems will only be using the ‘Heart rate’ and ‘Pulse rate’ data elements and the new and old archetype design is very closely aligned. If we can provide mapping guidance about when to map the current fields to an equivalent field in one of two archetype options, it will help ease the pain for existing deployments.
Yes, a neutral, well-governed CKM.
That is not the responsibility of CKM and its Editors. Knowledge governance of archetypes in systems is the responsibility of the vendor, which could be eased with purpose-specific vendor-level knowledge governance tooling.
If we follow your logic, then there would be zero progress, not even publication of draft archetypes in case v0 drafts have been deployed by some vendor, somewhere. And further, with that mindset, even adding a draft archetype to CKM is potentially a threat to existing deployments that have not shared their archetype libraries.
I didn’t say anything was simple.
My point about the ‘elephant in the room’ of unshared or hidden archetypes remains a significant knowledge governance problem that is outside of the scope or control of CKM and its Editors.
I’m glad to have the confirmation that the heart rate and pulse rate are conceptually separate.
The awkward naming of ‘Heartbeat’ comes after extensive anguish - after all rate is only one data element within an observation about the heart rate and regularity and etc, so the overall archetype concept needs an umbrella term. If you have an alternative suggestion, please feel free to offer.
There is no dispute that making major changes to an archetype, especially splitting one concept into two, is significant. Hence the initiation of this thread.
But what warrants a ‘very good reason’ depends on your point of view. From a CKM POV, the Editors think it necessary.
From a vendor point of view, the pushback is understandable. Perhaps this thread might trigger more thinking about the need for a knowledge governance layer focused on vendor-level, independent of CKM, that will help improve all flavours and degrees of vendor archetype change management and the downstream consequences.
Right. All I am saying is that ‘releases’ (of large groups of archetypes, or even all of them) need to be defined somewhere, in a similar way to the releases of the components of the specifications - e.g. RM Release-1.1.0, AM Release-2.3.0 etc.
Whether that kind of release management is done in CKM or elsewhere is another question. If it were, there is no reason for it to limit ‘progress in CKM’. We routinely create specifications that are ahead of the current release of a component, or are even a new component, as was the case when we created the PROC component for Task Planning.
Defining releases is just about creating baselines of coherent versions of individual artefacts and naming them, and providing a way for users to obtain that particular baseline. There is always a notional ‘development’ baseline, which is just the latest versions of everything. A new heart-rate archetype that breaks previous ones can live there, no problem, with the current one being in a defined release.
Such users will just use the latest baseline. In the specifications website, we have two views of the specs:
If you look carefully down the right hand side of each, you’ll see that the latter doesn’t include work in progress, while the former does.
Well, CKM itself does not currently have that functionality, but it could be added. Or it could be added elsewhere. It would be a bit odd though if visitors to CKM had to be redirected elsewhere.
It doesn’t need to. That’s what release management does: defines multiple baselines, including ‘latest’. But don’t underestimate the costs of a breaking change to a core archetype like heart-rate to existing users. Having defined releases enables them to choose when and if to move to the next release, and to handle the impact of the change. That doesn’t stop you going ahead with what probably is a better design.
It would even be possible to write a tool that scans all archetypes, and defines a new baseline every time a new major version of anything was published (other than newly added v0 archetypes).
Probably not just industry members - org members would be very interested in stability in their environments.
Every new major version of an archetype should routinely do that anyway I would think.
That would imply that each vendor has to study the contents of CKM and create their own releases. This will almost certainly involve replication of effort but with incompatible results. Would there be a Code24 mental health release and a Better mental health release, containing different contents and versions? That will not be sustainable.
Not at all: I am saying that innovation should go ahead as usual, breaking changes included. It’s just that those breaking changes will appear in a ‘development’ baseline, but not in previously defined baselines i.e. releases.
Release management is the practice that allows unlimited innovation without breaking everyone’s systems and applications in unknown ways.
Cool. No objection from me if this is developed as an additional approach to support vendor consumption of the available CKM archetypes.
My suggestion is that this is another independent tool that is specific for each vendor to support their internal knowledge governance. It will be connected to CKM or the Git repository so that it knows what/when CKM changes are made but is actually supporting each vendor with their local knowledge artefact governance, including all the non-CKM archetypes etc they have deployed or in various stages of development.
Agree. CKM can definitely do better in this area, when there are funded resources to support this.
All I know is that it is not the CKM responsibility. If vendors develop an agreed way to do this together - even better!
The only additional thing I would say is that we probably should distinguish the ‘purpose of CKM’ (which is a tool) from the ‘purpose of clinical modelling’, which is a process. I think the development of clinical models should find the best representations it can of real world phenomena as recorded in clinical practice. As it progresses will being to approach an ontology of epistemology of clinical practice.
But there is also (obviously) a pragmatic need to make models created over time available to user organisations that are stable, usable, documented and so on.
CKM (or a future derivative) might end up taking care of both these functions, or perhaps other tools will take care of some of them.
