# ECG archetype advice required
**Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153)
**Created:** 2018-09-05 05:59 UTC
**Views:** 1
**Replies:** 12
**URL:** https://discourse.openehr.org/t/ecg-archetype-advice-required/15541
---
## Post #1 by @system
Hi everyone,
I’ve just been facilitating the most recent reviews on the ECG archetype and would appreciate some advice on two issues.
The current atrial and ventricular rates are modelled as a Quantity (frequency) ie 1/min. However UCUM is unclear and there seems to be a few options, including {Beats}/min, {beats}/min and {H.B} is represented in another context, so maybe {H.B}/min is valid as well. Note that if we decide that it is appropriate to modify to one of these specific UCUM units, then to be consistent we will need to consider modifying the Pulse/heartbeat OBSERVATION as well – currently also modelled as a frequency of 1/min.
In addition, I’d appreciate some advice as to how we could get access to the latest draft of the ISO/IEEE standard for ECG – I think it is ISO/IEEE 11073-10406. We’d like to make sure there is alignment between the standard and the archetype before further reviews.
Kind regards
Heather
**Dr Heather Leslie**
MB BS, FRACGP, FACHI, GAICD
M +61 418 966 670
Skype: heatherleslie
Twitter: @atomicainfo, @clinicalmodels & @omowizard
[www.atomicainformatics.com](www.atomicainformatics.com)
(frequ
---
## Post #2 by @Ivar_Yrke
1/min, definitely!
Cardiac output is measured as liters/minute. Liters of what? We could have used the unit liters{blood}/minute, but I have never seen that done. It is considered obvious from the context. Likewise with other units. Velocity is measure as meters/second, not meters{travelled}/second. One could argue that meters{travelled} makes it clear that it is not meters{altitude}, but that is generally considered obvious from the context.
For some reason there is this temptation to add a fictive unit ({beats}, {count} etc.) when the number itself is unit less. This is not necessary. The context is always sufficient, just like in the cases that have a unit. Let us cut through the unclarity of UCUM and keep it simple and basic.
My argument is probably influenced by my background as a physicist. But if no one has objected to 1/min in pulse/heartbeat, then I see no reason to deviate from the basics in ECG or to modify pulse/heartbeat.
[details="(attachments)"]
[/details]
---
## Post #3 by @system
I agree with Ivar. In fact, UCUM has the unit /min to represent frequencies without a numerator unit.
[details="(attachments)"]
[/details]
---
## Post #4 by @marcusbaw
+1
I would echo Ivar's comments - keep it simple and use 1/min. It is clear we are talking about the rate of cardiac electrical activity from the context. The use of the word 'beats' would also undoubtedly (rightly) come under fire from cardiological/intensivist pedants like me - as a 'beat' is an old word deriving from the *observation of heart sounds*, whereas what you are measuring is cardiac electrical activity - and it's perfectly possible for the two to be different things, as in a PEA cardiac arrest.
Also, any of the more specific units such as '{beats}/min' could possibly confuse and make it harder to programmatically compare or display alongside other clinically relevant 'frequencies' expressed as 1/min such as: frequency of ventricular pacing spikes, frequency of aortic balloon pump counterpulsations, etc
Marcus
[details="(attachments)"]
[/details]
---
## Post #5 by @system
Hi everyone,
Thanks for the rapid response and clinical/modeller consensus of 3, regarding units of frequency for heart rate as 1/min
I’ve now included the technical list in this thread as I’ve found this reference to a DICOM standard - [http://dicom.nema.org/medical/dicom/current/output/html/part16.html#sect_CID_3230](http://dicom.nema.org/medical/dicom/current/output/html/part16.html#sect_CID_3230) – particularly Table TIC 3713, see below.
Atrial heart rate is a synonym of at0094 ‘PP rate’ in the latest version of the archetype - [https://ckm.openehr.org/ckm/#showArchetype_1013.1.276](https://ckm.openehr.org/ckm/#showArchetype_1013.1.276)
Ventricular heart rate is a synonym of at0013 ‘RR rate’.
In both examples the units from this Dicom document are {H.B.}/min.
Thoughts?
Regards
Heather
---
## Post #6 by @Ivar_Yrke
Give people options and they will end up with variation. It is NOT WRONG to use {H.B.}/minute, nor would it be wrong to use liters{blood}/minute or meters{travelled}/second. It is just unnecessary overkill(!). Adding {H.B.} to a value that is itself a pure dimensionless number only adds value when the magnitude is taken out of context. But out of context the magnitude itself becomes meaningless, whichever meaning you add to the number.
No need to follow the path of Dicom here, converting between the two is trivial.
[details="(attachments)"]
[/details]
---
## Post #7 by @system
Give people options and they will end up with variation. It is NOT WRONG to use {H.B.}/minute, nor would it be wrong to use liters{blood}/minute or meters{travelled}/second. It is just unnecessary overkill(!). Adding {H.B.} to a value that is itself a pure dimensionless number only adds value when the magnitude is taken out of context. But out of context the magnitude itself becomes meaningless, whichever meaning you add to the number.
No need to follow the path of Dicom here, converting between the two is trivial.
[details="(attachments)"]
[/details]
---
## Post #8 by @system
In human communication it many times is clear what is meant.
Of course Cardiac Output = 2 liters / minute means 2 liters of blood and not Oxygen.
In both cases the unit is liters of something per period of time; many times for instance: liters / minute or liters / day, etc.
We are always tempted to pre-/post-coordinate and make the unit Liters (blood) or liters (O2).
In my SIAMM way of modelling I abstain as much as possible from pre- and post-coorodinated codes.
The unit is generically a volume/time period specialised as liters/minute
In the archetype the context must make it clear that it is about the Cardiac Output of Blood.
In this way, making these choices, the Boundary problem between structure and coding system is avoided.
Gerard Freriks
+31 620347088
[gfrer@luna.nl](mailto:gfrer@luna.nl)
Kattensingel 20
2801 CA Gouda
the Netherlands
---
## Post #9 by @system
Hi Ian,
FHIR has included {Beats}/min in its limited demo list at [https://www.hl7.org/fhir/valueset-ucum-units.html](https://www.hl7.org/fhir/valueset-ucum-units.html).
/min is in artefacts too.
So the message is a little confusing.
H
[details="(attachments)"]
[/details]
---
## Post #10 by @system
Hi Ivar,
Thanks
In principle, we want these archetypes to be able to be used with device data. So where we can sensibly do so, we need to aspire towards alignment with published standards such as DICOM/ISO etc.
That said, alignment for alignment’s sake is also not a good way to go. There are many standards that have been published but never get implemented.
This email thread is just trying to get as broad a consensus as possible.
If the consensus is that this is trivial, I am very happy to continue as we are.
Regards
Heather
[details="(attachments)"]
[/details]
---
## Post #11 by @system
I would not want to see anything like liters\{blood\}/minute or meters\{travelled\}/second getting into openEHR \- that kills the basic notion of representing and processing scientific units\.
openEHR always works on the principle that the identity of the thing being measured is already established, normally by the ELEMENT\.name and archetype\_node\_id fields\.
Whether this kind of thing was displayed on screens by apps is another question of course\.
\- thomas
---
## Post #12 by @SEABURY_Tom_NHS_DIGI
Hi Ian
Just to add, as I didn’t see it on the thread anywhere else, the classical notation in engineering used in the dimensional analysis would be min-1 which I believe UCUM would allow as min-1
This may not be relevant, its for use in a different context than engineering. In UCUM Part 14: Telebiometrics related to human physiology seems the most relevant section and appears there as /min
Tom Seabury
[details="(attachments)"]
[/details]
---
## Post #13 by @system
OK, thanks everyone\.
It seems like there are zero voices supporting the \{H\.B\} or \{beats\} variations\.
So I'll send out a new review on the latest version of the ECG archetype\.
Please adopt the archetype if you'd like to participate in the review and we'll add you in\.\.\. See https://openehr.atlassian.net/wiki/spaces/healthmod/pages/2949159/Adopt+an+Archetype for instructions
Regards
Heather
---
**Canonical:** https://discourse.openehr.org/t/ecg-archetype-advice-required/15541
**Original content:** https://discourse.openehr.org/t/ecg-archetype-advice-required/15541