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