The modelling of the clinical concepts ‘pulse’ and ‘heart beat’ has been contentious for a long time. The original published archetype combined these two related concepts into one:
In practice, the terms ‘heart rate’ and ‘pulse rate’ are often used interchangeably, although they may be measured at different body sites. This archetype allows either term to be used when the measurement site is not specified, to suit clinician preferences.
This v1 archetype allowed the concept to be further specified to specifically either ‘pulse’ or ‘heart beat’ by the use of two runtime name constraints. This method was later changed to using the ‘Body site’ in the second published version of this archetype, because the two separate runtime name constraints allowed the recording of for example the presence of a pulse and the rate of the heart in the same instance of the archetype.
For a while now we’ve been struggling with how to represent these concepts since there’s been new requirements from an intensive care use case, where it’s vital to be able to tell these two concepts apart. This is further compounded by the need to exchange this information using FHIR observation profiles, where each data element needs its own terminology code. We’d really like to be able to add these terminology bindings to the archetype(s) to facilitate mapping, but the current modelling pattern makes this harder to achieve.
The discussion about how to best represent these requirements has been going around in circles for years, and we can’t seem to be able to reach a conclusion that holds up, so we’re asking the community for help
Our current identified options are:
Leave the archetype as is, and leave differentiation to implementers
Specialise the current archetype for ‘pulse’ and ‘heart beat’, respectively
Create and publish templates that differentiate the current archetype for ‘pulse’ and ‘heart beat’, respectively
Create two completely new, separate archetypes for ‘pulse’ and ‘heart beat’, and deprecate the current archetype
To help the community to give input, we’ve made some questions that are key to our discussions. We’d really appreciate it if you would give some responses to the questions below, hopefully with examples
Do we ever need to record a ‘pulse or heart beat’, in a context where neither the implementer nor the clinician know or care if the actual measurement performed is one or the other?
Do we ever need to record specifically ‘pulse’ or specifically ‘heart beat’, in a context where mixing them up could be a patient safety issue?
Should we have one place to record heart rate no matter how or where it’s measured, excluding the ventricular heart rate/RR rate/QRS rate from a point in time ECG procedure?
Results from pulse watches, which could be either measured by pulse oximetry or by single lead “ECG”, should these be recorded as different types of measurements or as the same?
For continuous electric heart monitoring, do we record the heart rate as “ECG” or “heart rate”
Do we ever need to record the heart apex beat measured by palpation?
Which details do we need to record about the method of measurement for pulse or heart rate? Manual vs device? Palpation/auscultation/pulse oximetry/direct intra-arterial measurement? Are these requirements different between pulse and heart rate?
To me, option 4 is not realistic, since it will make for an unfeasible migration scenario, which means present data cannot be compared with new data. This goes against the ‘life long record’ principle of openEHR. Off course sometimes there’s a need for breaking changes, but I don’t see much reason here. And the other three options are much more feasible.
Regarding the ICU use case, what is the problem with the current design, where pulse is differentiated from heart rate by measurement location?
Re FHIR with specific codings: I think many data sources (non-openehr) have this issue, so I think it’s something to solve for FHIR/implementation guides/specific implementations. They can usually make assumptions about the safety of something ambiguous (pulse or heartbeat) to something specific (pulse). The way to do it is quite clear in openEHR: record the measurement location and differentiate based on that. So I’d advocate for option 1, but I’m open to option 2 and 3.
Regarding the questions:
1: in my experience this is the default for most care scenarios.
2: probably yes, in specific cases. E.g. pulse deficit.
3: ideally yes, why excluding the ECG procedure, I think it’s the most used heart rate measurement procedure?
4: different
5: both?
6: probably rare, but according to our maximal modelling strategy I’d say yes.
7: hmm, I think the suggestions are good. I think only specific combinations make sense, but not sore requirements are different other than that. @johngrant4est don’t you have an anaesthesiology background? I’m interested in your practical experience.
Edit: in ADL2 (and upcoming 3) templates are technically specialisations, so option 2 and 3 will be technically similar.
From an ontology perspective, I would say that what we have is one way to characterise any ‘pulsation’, of which heart rate and (usually peripheral) pulse are two examples. In the physiology we are talking about the pulse generator (the heart) and the pulse further out in a structure of fluid-carrying vessels.
So for situations where there is a difference (various conditions, presumably including AFib and other arrhythmias etc) the two phenomena have to be distinguished.
For ‘normal’ situations where none of those pathologies is suspected, ‘pulse’ is normally used as a proxy for heart rate.
The theoretically correct archetype model is something like:
parent archetype: ‘pulsation’ (or stick with the current name) - include all the common attributes here, plus make it clear that ‘body site’ refers to any location from heart (the origin of pulsation)
pulse - meaning peripheral pulse at some site -
heart rate - meaning a relatively direct measurement of the heart beat
(Another instance of specialisation !)
In the pathological or diagnostic situations where the difference matters, the user will be anle to create instances of both pulse and HR; for all other situations, the application should just create a pulse instance.
The original design does essentially specialise from an abstract idea of pulse by allowing run-time name constraInts to specify either pulse or heart beat, where this is felt important.
Perhaps we could simply add ‘heart rate’ to these options, to explicitly cover the use of a simple ECG monitor.
We needot be careful not to be drawn into a biomedical ontological perspective which is scientifically accurate but actually unhelpful in this case.
There is a big difference between measuring/recording a pulse/heart beat, as a estimate/ proxy estimate of the person’s heart rate. or indeed using a pulse oximeter or ECG monitor to assess heart rate. rhythm and cardiac efficiency vs for example estimating the foot pules in someone wit impaired circulation, or monitoring their foot perfusion after vascular surgery.
The further complication is that heart rate is also often measured via ECG and there is not always a direct correspondence between an electrical ‘beat’ and a heart beat. plus there is not always a detectable pulse for every physical heart beat.
I actually think the original design of pulse/heart beat was pretty good, since it recognises the criticality of estimating heart rate as a quite distinct clinical idea. but also that in probably ?99% of usage, the exact means of measurement is not at all critical, and measurement technique may be very fluid for a single patient.
There are exceptions where the exact measurement of electrical heart rate vs direct heart impulse vs peripheral impulse are significant but these are IMO quite readily handled with the combination of heart/pulse and ECG archetypes plus the device/method attributes that Joost was talking about.
That would work but it only distinguishes the two things on runtime name, not design time code, which sort of implies that they are thought to be the same phenomenon, called by different names.
On the contrary, I’d say we should always look at the ontological perspective to see if it tells us anything. In the current case, we are distinguishing between epistemic means of obtaining a ‘heart rate’ measurement, which for the most part area treated as equivalents - i.e. the true ontic difference can be safely ignored. That’s fine. But for when the intention is really to distinguish ‘pulse’ in some downstream location in the vascular network versus central heartbeat, then the difference does matter.
Sure - distinguishing the true physical phenomena probably only needed 1% of the time.
Using just the names to distinguish does mean however that querying just for measurements marked as ‘heart rate’ are difficult because you presumably have to catch both true heart rate measurements (done centrally or via ECG) as well as peripheral pulse rates that are assumed to accurately reflect heart rate. In a diagnostic situation where it is not yet suspect that there is a difference between the two, the data won’t be accurate. This might be ok - one could argue it correctly reflects the lack of knowledge about the patient’s condition prior to diagnosing it.
Inclined to agree with @thomas.beale on the question of ontology. Would be good to see the use case from ITU and I can also revisit how the concepts are modelled in FHIR from a Devices perspective (if that helps).
It’s tempting to think of Pulse and HR as synonyms but as outlined above, Pulse can be an observation of rate, quality and rhythm. HR in ITU is usually observed from the output of a device, using either the ECG, Pulse Oximeter, or sometimes both, as they are measuring different variables (electrical activity vs pulsatility at the periphery).
I think I’m saying in favour of specialising the current archetype somehow, to take account of the ontological difference between the two concepts.
