Heartbeat and Pulse

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.

1 Like

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…

1 Like

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.

1 Like

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.

1 Like

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

1 Like

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


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:

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

1 Like

Hi Silje
I agree with the proposed solution.

A segunda, 10/06/2024, 14:56, Silje Ljosland Bakke via openEHR <discourse@openehr.org> escreveu:

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.