# What happens once the Pulse/Heart beat archetype is replaced?

**URL:** https://discourse.openehr.org/t/what-happens-once-the-pulse-heart-beat-archetype-is-replaced/11434
**Category:** Platform
**Tags:** archetype
**Created:** [26 September 2025 16:36 UTC](https://discourse.openehr.org/t/what-happens-once-the-pulse-heart-beat-archetype-is-replaced/11434 "2025-09-26T16:36:21Z")
**Posts on this page:** 1
**Showing post:** 37

<div class="post-metadata">

### Author: ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [30 September 2025 13:09 UTC](https://discourse.openehr.org/t/what-happens-once-the-pulse-heart-beat-archetype-is-replaced/11434/37 "2025-09-30T13:09:16Z")

</div>

> [@birger.haarbrandt](#):
>
> What make me curious is why some people in the community are so keen on introducing breaking changes to the RM. Just look at the HUGE problems FHIR has by introducing breaking changes across versions. As a consequence, whole countries are stuck on different FHIR versions.

[Some answers to that here](https://discourse.openehr.org/t/looking-ahead-to-openehrv2/11448). Needless to say, if we went to openEHRv2, it would be for the next 20y, not an endless rollout of breakages each 2 years…

> [@birger.haarbrandt](#):
>
> The promise of the RM is to be stable. Backward-compatibility is a huge value when we talk about **data for life**. That’s a big plus for technologies like Java. There is beauty in the fact that I can run my 20 years old java program on a recent JVM version and that I can still upload a template I did in 2013 into my openEHR server and tools, and everything just works.

That would work in an openEHRv2 system of course. Data migration from openEHRv1 to v2 would be needed for those systems and vendors that wanted to do it. But the improvements (having build quite a few of them) are definitely worth it. And it would be one of the easiest data migrations ever. People get worried about breaking changes to openEHR (and that’s reasonable, don’t get me wrong), but _routinely_ don’t think twice about endless data conversion in and out of openEHR, HL7v2, FHIR, OMOP, IHE, X12, and more - and these are not the same RM with breaking changes, but **different paradigms, generally with difficult to reconcile semantics**. Those conversions are creating errors and omissions in data all the time. So we need to be realistic.

> [@birger.haarbrandt](#):
>
> In my opinion, there is so much opportunity to improve the ecosystem, also with new specs (e.g. expanding the use of archetypes to ERP data as proposed by @thomas.beale ), without breaking stuff that is not supposed to break.

We should definitely take note of this. However there are some changes so central that they change everything. So it’s worth considering whether we hang on to openEHRv1 longer and keep grafting non-breaking improvements, and bite the bullet later (more data, larger models deployed) or do it sooner. Both paths are possible, and probably both are reasonable, but the costs and consequences need to be understood.

Breaking changes can be managed well, or badly. We need to do it well. We have coherent architectures and a good community approach to change management.

---

_[View the full topic](https://discourse.openehr.org/t/what-happens-once-the-pulse-heart-beat-archetype-is-replaced/11434)._