# Heartbeat and Pulse **Category:** [Clinical](https://discourse.openehr.org/c/clinical/5) **Created:** 2024-04-11 07:45 UTC **Views:** 1044 **Replies:** 39 **URL:** https://discourse.openehr.org/t/heartbeat-and-pulse/5092 --- ## Post #1 by @siljelb Hi all! Based on [this discussion](https://discourse.openehr.org/t/pulse-and-heart-beat-conundrum/4692/6) and discussions in other fora, we've created two new archetypes intended to replace the current [OBSERVATION.pulse.v2](https://ckm.openehr.org/ckm/archetypes/1013.1.4295): * [OBSERVATION.heartbeat (Heartbeat)](https://ckm.openehr.org/ckm/archetypes/1013.1.7154) * [OBSERVATION.heartbeat-pulse (Pulse)](https://ckm.openehr.org/ckm/archetypes/1013.1.7153) 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. --- ## Post #2 by @joostholslag 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: [quote="siljelb, post:1, topic:5092"] in some specific use cases this is vitally important [/quote] 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. --- ## Post #3 by @ian.mcnicoll 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. --- ## Post #4 by @siljelb Super quick response to a couple of points only: [quote="joostholslag, post:2, topic:5092"] you can have a pulse without a heartbeat (eg cpr) [/quote] Agree. This (and other possible cases where the heart is known not to be beating) should probably be excluded from the concept. [quote="joostholslag, post:2, topic:5092"] you can have a heartbeat without a pulse (eg VT) [/quote] Agree. This is one of the cases where it's vital to be able to clearly tell them apart. --- ## Post #5 by @joostholslag [quote="siljelb, post:4, topic:5092"] Agree. This (and other possible cases where the heart is known not to be beating) should probably be excluded from the concept. [/quote] 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. --- ## Post #6 by @heather.leslie I endorse this approach @siljelb 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. --- ## Post #7 by @joostholslag [quote="heather.leslie, post:6, topic:5092"] but never really worked well. [/quote] 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’. --- ## Post #8 by @heather.leslie [quote="joostholslag, post:7, topic:5092"] Could you please share some information on in which way it doesn’t work well? [/quote] 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. --- ## Post #9 by @heather.leslie [quote="joostholslag, post:7, topic:5092"] Universally adopted, stable models focussed on real world use cases is imho what sets CKM apart. [/quote] 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. --- ## Post #10 by @joostholslag [quote="heather.leslie, post:9, topic:5092"] I’m not sure that stability is so important - rather governance, quality and credibility. [/quote] 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? --- ## Post #11 by @joostholslag [quote="heather.leslie, post:8, topic:5092"] 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. [/quote] 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. [quote="heather.leslie, post:6, topic:5092"] In the meantime, perhaps we can offer a mapping between the two generations of models. [/quote] 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. [quote="siljelb, post:4, topic:5092"] [quote="joostholslag, post:2, topic:5092"] you can have a pulse without a heartbeat (eg cpr) [/quote] Agree. This (and other possible cases where the heart is known not to be beating) should probably be excluded from the concept. [/quote] 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](https://browser.ihtsdotools.org/?perspective=full&conceptId1=78564009&edition=MAIN/2024-04-01&release=&languages=en), 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. --- ## Post #12 by @bna 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. --- ## Post #13 by @heather.leslie [quote="bna, post:12, topic:5092"] The previous archetype must be really really bad to propose a change in core archetypes like this. [/quote] This is the nub of the problem. 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. [quote="bna, post:12, topic:5092"] The cost of change is enormous. [/quote] 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. --- ## Post #14 by @Gunnar_Klein 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 --- ## Post #15 by @thomas.beale [quote="heather.leslie, post:13, topic:5092"] 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? [/quote] 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**. [quote="heather.leslie, post:13, topic:5092"] 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. [/quote] 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. [quote="heather.leslie, post:13, topic:5092"] 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. [/quote] 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. --- ## Post #16 by @heather.leslie [quote="thomas.beale, post:15, topic:5092"] This is a question of **release management**. [/quote] Disagree. This is about the purpose of CKM. 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. [quote="thomas.beale, post:15, topic:5092"] 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. [/quote] This has been the CKM practice for many years - clearly documented here: https://specifications.openehr.org/releases/AM/Release-2.0.6/Identification.html, and underpinning CKM functionality. Authored by you, contributed to by myself and knowledge governance experts, and used everyday. [quote="thomas.beale, post:15, topic:5092"] 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). [/quote] 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. [quote="thomas.beale, post:15, topic:5092"] 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. [/quote] 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. [quote="thomas.beale, post:15, topic:5092"] In sum, both points of view are valid - we need **a strategy to allow both stability and innovation to co-exist**. [/quote] 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. [quote="thomas.beale, post:15, topic:5092"] We need a place to do those things [/quote] Yes, a neutral, well-governed CKM. [quote="thomas.beale, post:15, topic:5092"] such that they don’t break things already deployed [/quote] 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. [quote="thomas.beale, post:15, topic:5092"] [quote="heather.leslie, post:13, topic:5092"] 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. [/quote] 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. [/quote] 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. --- ## Post #17 by @heather.leslie 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. --- ## Post #18 by @thomas.beale [quote="heather.leslie, post:16, topic:5092"] 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. [/quote] 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. [quote="heather.leslie, post:16, topic:5092"] 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 [/quote] Such users will just use the latest baseline. In the specifications website, we have two views of the specs: * [development baseline](https://specifications.openehr.org/development_baseline) * [latest releases](https://specifications.openehr.org/release_baseline) 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. [quote="heather.leslie, post:16, topic:5092"] 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. [/quote] 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. [quote="heather.leslie, post:16, topic:5092"] 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. [/quote] 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). [quote="heather.leslie, post:16, topic:5092"] 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 [/quote] Probably not just industry members - org members would be very interested in stability in their environments. [quote="heather.leslie, post:16, topic:5092"] 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. [/quote] Every new major version of an archetype should routinely do that anyway I would think. [quote="heather.leslie, post:16, topic:5092"] Knowledge governance of archetypes in systems is the responsibility of the vendor, which could be eased with purpose-specific vendor-level knowledge governance tooling [/quote] 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. [quote="heather.leslie, post:16, topic:5092"] 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. [/quote] 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. --- ## Post #19 by @heather.leslie [quote="thomas.beale, post:18, topic:5092"] 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. [/quote] Cool. No objection from me if this is developed as an additional approach to support vendor consumption of the available CKM archetypes. [quote="thomas.beale, post:18, topic:5092"] [quote="heather.leslie, post:16, topic:5092"] 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. [/quote] 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. [/quote] 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. [quote="thomas.beale, post:18, topic:5092"] [quote="heather.leslie, post:16, topic:5092"] 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. [/quote] It doesn’t need to. [/quote] :star_struck: :fireworks: :sparkler: [quote="thomas.beale, post:18, topic:5092"] [quote="heather.leslie, post:16, topic:5092"] 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. [/quote] Every new major version of an archetype should routinely do that anyway I would think. [/quote] Agree. CKM can definitely do better in this area, **when** there are funded resources to support this. [quote="thomas.beale, post:18, topic:5092"] [quote="heather.leslie, post:16, topic:5092"] Knowledge governance of archetypes in systems is the responsibility of the vendor, which could be eased with purpose-specific vendor-level knowledge governance tooling [/quote] That would imply that each vendor has to study the contents of CKM and create their own releases. [/quote] All I know is that it is not the CKM responsibility. If vendors develop an agreed way to do this together - even better! [quote="thomas.beale, post:18, topic:5092"] I am saying that innovation should go ahead as usual, breaking changes included. [/quote] Excellent. Sounds like we might have a plan. --- ## Post #20 by @thomas.beale 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. --- ## Post #21 by @bna [quote="thomas.beale, post:20, topic:5092"] 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 [/quote] This is a very good point. The purpose of openEHR.CKM or for Norway arketyper.no versus the library of all clinical models containing both bad patterns and also the ideal/good ones which represents the future of modelling for specific purposes. I tend to look at the CKM as the reference library of what is in use in different domains. openEHR.CKM is the international go-to reference and the Norwegian one for national models. Any actor who wants to develop, use or mandate the use of clinical concepts should be safe picking one archetype from those services. The problem here is how to do release management. For archetypes which is widely used the cost of breaking change is big. Sometimes the cost of change is higher than the benefits of the improved model. How do we as a community choose the right way to cope with such changes. It is hard and the complexity of different interests/views will impact the decisions. --- ## Post #22 by @heather.leslie The tensions are real, but CKM is not the single solution here and it is not the Editors' role to keep everyone happy - that will fail for sure. As a broad community, we need to be able to disambiguate all the stakeholders, especially focusing on how each needs to use/consume the archetypes, and potentially develop solutions to support each use case. CKM should be the 'source of truth', or best practice or however you want to phrase it, neutral to how end users use them in practice. If release sets or similar solutions are developed, they also have value for measuring conformance etc. It could be a good thing in more ways than one... --- ## Post #23 by @thomas.beale [quote="bna, post:21, topic:5092"] The problem here is how to do release management. For archetypes which is widely used the cost of breaking change is big. Sometimes the cost of change is higher than the benefits of the improved model. [/quote] A simplistic process would be to take a baseline (= list of {archetype id, version} pairs) today, or at some known date where no major version changes to archetypes had occurred for a while. And then to compute a new baseline each time a new major version of anything is published (or perhaps a set of new versions on the same day or whatever). Additions of new v0 archetypes would not cause new baselines. Incubator and local project archetypes would be ignored. Then a simple means of tagging baselines would be useful. This could be done in CKM, but it could be done more easily, probably in the CKM-mirror Git repo, and indeed could be retrospectively computed back to the start of that repo. This would provide a means for user orgs to identify what release they are using, and to decide whether to stick with it. In the Git repo some releases (identified by their tags) could have a branch created for them, with the only additions on the branches being 'fixes' - minor & patch version republications of included archetypes. --- ## Post #24 by @ian.mcnicoll [quote="joostholslag, post:10, topic:5092"] Saying this it would be good to get input from implementers (software engineers) on the impact and willingness to upgrade for this change, agreed? [/quote] Just a few thoughts on what is a really helpful discussion. 'Implementers' are increasingly not software engineers or vendors - they are actually healthcare organisations. Perhaps 'consumers' rather than 'implementers' and certainly not vendors. The cost (money and clinical risk/upheaval) of managing breaking changes essentially lands at their door. This was one of the issues that emerged from the ADL2 discussions - that while some openEHR implementations are essentially single vendor systems (and therefore the vendor can take a view on the cost/risk of handling a breaking change, but in many more, it is the hc provider that will make that decision and they are quite likely to operate much more tactically. The risk is that the vast majority might decide **never** to adopt a breaking change whose change seems an edge case, so we end up with all of the established systems using the old version, whilst new entrants, not unreasonably are likely to adopt the new version. The current approach to model governance, as Heather outlined, is I agree, pretty well optimal, but I don't think it can work without any regard for 'consumer impact'. Now, I know that is not the case .... the CKAs, as Heather has said do recognise the significance of breaking changes and the fact that this Discourse topic exists at all is due to a recognition by the CKAs that this is a tricky modelling problem and may have a potential impact. So thanks for raising it. I do wonder though, if this good and welcome practice might need to be underpinned by a more formal process that ensures widespread community engagement. Doing that for every breaking change would be both counter-productive and unsustainable but perhaps we can define a small set of 'premium / mature' archetypes, where really wide community reflection is sought before publication, including a deep-dive into the challenges which the modellers faced which led to the recommendations. --- ## Post #25 by @ian.mcnicoll @Siljeb @heather.leslie - can you help us better understand why the current model could not be made to work, or was problematic? As Joost said earlier, it was possible to differentiate heartbeat vs. pulse by the device or location used, but I would certainly have supported a specific new 'mode' element which explicitly allowed us to record 'pulse' vs 'heartbeat' vs 'electrical RR rate' to make the usage crystal-clear where necessary. I saw in @siljelb original post that the need to use differential term bindings to support export to FHIR Observations may have been a factor. This might also be relevant to separate discussions about how bindings relate to run-time mappings. --- ## Post #26 by @siljelb Hi again all, and thanks for your responses in this thread and in [the separate thread specifically about the semantics of "pulse" and "heart beat"](https://discourse.openehr.org/t/practical-semantics-of-heart-rate-and-pulse/5239). Based on the responses we've received from clinicians and others that "pulse" and "heart beat" are conceptually different, it's looking more and more likely that we'll end up with two completely separate archetypes. Then there is the "ontology of practical clinical recording" view than Ian mentioned in the other thread: The issue of mixing up these concepts has been present since the days of paper record forms with limited flexibility and limited space. The data written in paper forms will always be subject to human interpretation both when captured and when used, while digital forms are much more dependent on clearly defined information concepts for computer reuse. On the other hand, digital forms make it much easier to allow the user the option of choosing which of the two concepts they're observing and recording. Additionally, it seems likely that in most use cases you can make good assumptions about which of the two concepts should be the default choice presented in a user interface. On this basis, we're proposing to remodel the concepts as two completely separate archetypes. Are there any *practical* uses, apart from existing applications, where this approach would be problematic? --- ## Post #27 by @siljelb Just to bump this question a bit, and since there was a significant amount of pushback when this topic was initially posted: Should we interpret the silence now as "No, this suggestion is fine!" :innocent: --- ## Post #28 by @ian.mcnicoll Duly bumped. Sorry I still feel this is going in an unhelpful direction but was bending to majority views. To be clear, I absolutely understand and support the need to be able to clearly distinguish between heart beat, pulse and indeed electrical heart rate in some clinical circumstances. However, I feel that forcing designers to actively choose the particular flavour 'up front' will be confusing, or where there is a potential switch between e.g. a single -lead ECG to pulse oximetry, then there is now a need need to carry 2 different archetypes in any template to represent Artery site, plus a set of guidance to the developers. I still don't really understand why the simple of addition of the Method element in the new heat beat archetype to the existing archetype could not have solved the problem, along with a couple of embedded templates to show how to represent 'pure heart beat' vs 'pure pulse' and 'pure heart rate' if people want to model them as specific artefacts. That's it - no more from me!! If I'm in the minority, so be it .... @joostholslag was, I think, the other rebel ?? --- ## Post #29 by @Leuschner Hi Silje I agree with the proposed solution. A segunda, 10/06/2024, 14:56, Silje Ljosland Bakke via openEHR <[discourse@openehr.org](mailto:discourse@openehr.org)> escreveu: --- ## Post #30 by @thomas.beale [quote="siljelb, post:27, topic:5092, full:true"] Just to bump this question a bit, and since there was a significant amount of pushback when this topic was initially posted: Should we interpret the silence now as “No, this suggestion is fine!” :innocent: [/quote] We do not yet have a simple solution to the competing needs, which are: * being able to model 'properly' what is in reality, including things that are needed 1% of the time, but when they are needed, we need them done right (and in healthcare, 1% is still big - so it matters. 1% of 100m health visits is a million visits...) * making the 99% need (here: record heart rate in 'normal' situation; peripheral pulse is an acceptable surrogate for heartbeat) easy and obvious * not breaking existing software and systems. All of these really matter. In the 'real world' of economics, business, purchasing, keeping customers happy, the last one has some priority, since vendors and procurers tend to vote with their feet, not their hearts (see what I did there), so we can't ignore it. I have not followed the detailed modelling discussion all the way through, but some way of allowing a 'simple heart rate' (usually by peripheral surrogate, i.e. standard pulse oximeter or manual count) and a 'detailed heart rate' (all the other non-routine stuff) is needed. To me this seems similar to the common modelling situation of 'simple body location' and 'structured body location', which is currently achieved with two separate Elements in openEHR (in S2, we have fixed this, and it is very nice), and a couple of others that have a pair of 'simple' and 'structured' (Person address, is another example from memory). I don't have a proposal, but I would counsel against ignoring the last bullet above. If the modelling approach is too complex to do the 99% of routine heart rate easily, vendors & implementers will just do something else, and the beautiful new models are for nothing. --- ## Post #31 by @siljelb [quote="ian.mcnicoll, post:28, topic:5092"] I still don’t really understand why the simple of addition of the Method element in the new heat beat archetype to the existing archetype could not have solved the problem [/quote] The 'Method' element doesn't really differentiate between the two concepts, especially the 'Palpation' value is common between both. [quote="ian.mcnicoll, post:28, topic:5092"] where there is a potential switch between e.g. a single -lead ECG to pulse oximetry, then there is now a need need to carry 2 different archetypes in any template [/quote] In use cases where this switch is likely to happen, that would certainly be a necessity. But which cases are we talking about then? Most monitoring in a perioperative or ICU setting would use both of these (although usually more than a single lead) at the same time, and it would be important to be able to tell them clearly apart. Or are we talking about exercise watches? [quote="thomas.beale, post:30, topic:5092"] not breaking existing software and systems. [/quote] We've discussed this earlier, and while I agree we shouldn't break anything existing, I don't agree publishing new major revisions of any archetype "breaks" anything. It's not like we're removing the older revisions from existence, they're even still in the CKM although in a deprecated state. Vendors will in any case have to make decisions about which archetypes they use and don't use. [quote="thomas.beale, post:30, topic:5092"] I don’t have a proposal [/quote] Tbh it's a struggle trying to consolidate all of these requirements and issues when so many of the responses are of the form "I don't know how to do this, but it's definitely not this way". I do appreciate everyone's participation, but I'd also very much appreciate suggestions on how to solve the problem. --- ## Post #32 by @heather.leslie This kind of conversation is difficult and hard work, and this is why the thread exists. Personally, behind the scenes the investigation and proposal of alternative models for these concepts has taken more days of my life than I care to think about - many iterations over many years to try to 'nail it'. We make some progress with each iteration, understanding the use cases better but still butting up against the messy current clinical documentation. It would have been far easier to take the lazy way out and leave well enough alone, except it doesn't work for the less frequent yet clinically critical use cases. This is the responsibility for each Editor/CKA to try to create modelling patterns that work for all. As @siljelb says, nothing is broken if the current model remains, even if deprecated to indicate this is not best practice, and we replace with new models that best reflect best practice documentation as a road map for new vendors and existing vendors to use as a roadmap for future development. If clinicians were offered these alternative models as options, it is very possible they would be preferred. It would promote discussions on how to differentiate the edge cases and document them more clearly, and accurately. This approach improves the quality of our data, decreases variability, and can positively impact on health outcomes. And after all, this is why I am a clinical modeller. We really need to question the acceptance of having a deliberately vague or 'muddy' archetype that 'does it all', but is possibly not fit for the job. Especially if we are to rely on it for CDS, AI and personalised medicine. In which case, lets agree and publish the 'gold standard' archetype for each concept, even if it is not yet a popular implementation choice, leave the existing archetype in the CKM, and let the market and associated rise of knowledge-driven activities naturally drive the changes in implementations. --- ## Post #33 by @heather.leslie What is the extent of current implementations? Is it only the rate (heart or pulse) or is it more of the existing model? Does anyone have a good insight into the level of detail of implementation? --- ## Post #34 by @thomas.beale [quote="siljelb, post:31, topic:5092"] Tbh it’s a struggle trying to consolidate all of these requirements and issues when so many of the responses are of the form “I don’t know how to do this, but it’s definitely not this way”. I do appreciate everyone’s participation, but I’d also very much appreciate suggestions on how to solve the problem. [/quote] Fair enough. Well, as you can see my view above is (and remains) 'release management'. @heather.leslie thinks that's not a function of 'clinical modelling', which I probably agree with, and/or something that should be in CKM. I don't agree with the latter - CKM is just a tool. Heather said earlier that vendors should define releases. I can see that that might be useful, but vendors won't be the definers of something like a LTS (= Long Term Support, a term used in general IT to refer to long term stable versions of things like Linux) release of 'models for core general medicine' or similar. So arguably our real task is to figure out who defines such releases and for what purpose. openEHR should be the coordinating org, but we might take the approach that we get input from Org partners and similar orgs (even if not currently a paid up org partner), e.g. Karolinska, various UK trusts etc. If such orgs + vendors (we need them because it's their code and other products that are directly affected) could help us define releases that everyone can use as the baseline for the future. If we could actually start defining these releases, bleeding edge clinical modelling activities can keep going with no worry of breaking anything or getting pushback. This overall situation is really no different from general adoption of IT products, where 10% are always using the latest beta of some tool (Firefox or whatever), 75% use the LTS release and 15% are laggards stuck on ancient versions. --- ## Post #35 by @thomas.beale [quote="heather.leslie, post:32, topic:5092"] In which case, lets agree and publish the ‘gold standard’ archetype for each concept, even if it is not yet a popular implementation choice, leave the existing archetype in the CKM, and let the market and associated rise of knowledge-driven activities naturally drive the changes in implementations. [/quote] We should definitely do this; but we need to be super careful that breaking changes are always recognised with major version change. Otherwise release management can't be implemented. --- ## Post #36 by @heather.leslie [quote="thomas.beale, post:34, topic:5092"] Fair enough. Well, as you can see my view above is (and remains) ‘release management’. @heather.leslie thinks that’s not a function of ‘clinical modelling’, which I probably agree with, and/or something that should be in CKM. I don’t agree with the latter - CKM is just a tool. Heather said earlier that vendors should define releases. I can see that that might be useful, but vendors won’t be the definers of something like a LTS (= Long Term Support, a term used in general IT to refer to long term stable versions of things like Linux) release of ‘models for core general medicine’ or similar. [/quote] @thomas.beale I'm not sure you've understood me correctly. I suggest that: - the publication of 'gold standard' archetypes is the domain of the CKAs in CKM. - In parallel, the development and publication of release sets as combinations of archetypes via CKM is another layer of governance. Who is responsible and what the purpose is obviously yet to be defined. It may be best done by those with skin in the game, whether for conformance testing of 'core' or for specific use cases, as you suggest. Maybe this is a role for the new Software Board, on behalf of the implementers and orgs. - IMO I believe there is a need for an additional tool that supports implementation governance at vendor or org level across all of their applications eg the situation where v1 of an archetype is implemented in one application and when a new application developed by the same vendor it uses the latest version, a v2. When any update in CKM, whether a revision or v3, occurs it helps inform the vendor if and when they need to update either or both archetypes. --- ## Post #37 by @heather.leslie [quote="thomas.beale, post:35, topic:5092"] but we need to be super careful that breaking changes are always recognised with major version change. [/quote] This has been standard practice since 2008. --- ## Post #38 by @thomas.beale [quote="heather.leslie, post:36, topic:5092"] IMO I believe there is a need for an additional tool that supports implementation governance at vendor or org level across all of their applications eg the situation where v1 of an archetype is implemented in one application and when a new application developed by the same vendor it uses the latest version, a v2. When any update in CKM, whether a revision or v3, occurs it helps inform the vendor if and when they need to update either or both archetypes [/quote] Agree with the preceding bit. This kind of functionality is mainly tooling, that doesn't yet exist. But at a minimum, some API calls could be developed for CKM that allowed an external party to subscribe to a) an archetype or other single artefact, b) a release, c) a 'project' or other grouping of artefacts. For any of these, the subscriber would receive a notification for any change to the published form of any constituent artefact. That would at least be a start. --- ## Post #39 by @ian.mcnicoll [quote="thomas.beale, post:38, topic:5092"] For any of these, the subscriber would receive a notification for any change to the published form of any constituent artefact. [/quote] AD does actually support this moderately well already via the 'Updates' option, This needs to be enabled in Settings. If enabled, a new tab appears which shows if there are any differences between the versions of archetypes used in the locla repo vs. the versions in CKM (via the Github repo). Clicking on the tab then gives you detailed 'diff' information on each archetype, based on semver, and the opportunity to update and outdated archetype very cleanly. This actually fits our current practice more cleanly, than a simple notification of a change, as almost certainly we will want to review use (or not) of the latest version of archetypes at the start of a new round of development , and perhaps near the end before we need to lock things down. The diff feature is not perfect but it is proving very helpful and definitely going in the direction that @heather.leslie rightly expects - something much more project orientated than CKM is intended (at least for now). I also think this 'project tool' is quite likely to be something much broader than just openEHR as it will need to handle Valuesets, mappings, and various other dependencies. ![image|690x325](upload://m5ExHwV3AH25FcSlLj9rWsulB2u.png) ![image|690x317](upload://oMKc2x74ZrpHm5UcZQaTVByWTde.png) --- ## Post #40 by @thomas.beale [quote="ian.mcnicoll, post:39, topic:5092"] AD does actually support this moderately well already via the ‘Updates’ option, This needs to be enabled in Settings. If enabled, a new tab appears which shows if there are any differences between the versions of archetypes used in the locla repo vs. the versions in CKM (via the Github repo). [/quote] Very nice, I didn't know about that. [quote="ian.mcnicoll, post:39, topic:5092"] This actually fits our current practice more cleanly, than a simple notification of a change, as almost certainly we will want to review use (or not) of the latest version of archetypes at the start of a new round of development , and perhaps near the end before we need to lock things down. [/quote] I suspect this is the POV of an author / editor more than an organisation though. Consider if (say) Sweden) decided to use some Release called 'Models for General medicine 2024 LTS'. Over time, models in that release will get new versions and there will also be new models added for general medicine. It would be very helpful to have automated notifications that don't rely on a human working on a particular model in a tool. [quote="ian.mcnicoll, post:39, topic:5092"] I also think this ‘project tool’ is quite likely to be something much broader than just openEHR as it will need to handle Valuesets, mappings, and various other dependencies. [/quote] Good point - those things should normally be considered as contents of a 'Release' as well. --- **Canonical:** https://discourse.openehr.org/t/heartbeat-and-pulse/5092 **Original content:** https://discourse.openehr.org/t/heartbeat-and-pulse/5092