I’m modelling “Blood Circulation System Examination” archetype and it’s components like “Arterial Pressure” archetype.
The arterial pressure measurement is required for every examination in my particular hospital.
So, I need to enforce constraint for this archetype from [0..] to [1..] in my template .
But I have counterargument for this.
Some of the hospital’s patients are disabled armless people, so arterial pressure couldn’t bee measured at examination. And this must became empty.
There are many examples like this. So my question is: How I can model it with openEHR?
This is a common issue and is a good argument for not mandating data entry in electronic clinical systems!! There is no equivalent mandation for paper records - clinicians would normally just leave the fileds blank and make some sort of comment in the margin of the form.
In your example I will assume that it is the systolic and diastolic elements that are mandatory and set as such at template level. It is still permissible for the element to be left empty and for a null flavour to be set, in this case ‘not applicable’ see:
The reason for the null could be documented in the Blood pressure archetypes Comment element.
We recognise a need to find a way of easily adding a comment to any node, when a null is recorded - a similar issue arose recently with the Glasgow Coma Scale when e.g. Eyes could not be observed.
There are 2 potential solutions..
Add a ‘reason for null’ text attribute in the Reference model alongside the null itself.
Use the link attribute available to every node to attach an ‘annotation’ - this will be recorded in a separate archetype, which allows considerable flexibility as to whether a simple text field is required or perhaps more complex, structured ‘reasons for null’ are required. This approach is being investigated as a means of annotating data elements for quality or ‘fitness-for-purpose’. e.g. Is a device obtained blood pressure valid fro graphing or should it be excluded?
I might be talking out of turn here, but an archetype for systemic arterial BP is still valid for a person with no arms. The measurement just has to be done with a cuff on the leg or in some other way, i.e. the protocol of the measurement is different. So if your hospital says ‘there must always be a systolic BP’, then for amputees, it is just a question of how, not, if, you obtain it. Now, if I read carefully below, i think you are saying that there are examination events at which a disabled person turns up, and the examining doctor is not equipped to do a BP for that kind of person. In that case, you do have a situation where the BP data won’t be filled out, and instead the ‘null-flavour’ value needs to be set to ‘not available’ (or maybe some richer value as has been suggested recently). Either way, Systolic BP can still be set to mandatory, since even an ELEMENT with no value attribute but with a null-flavour will satisfy this.
We recognise a need to find a way of easily adding a comment to any
node, when a null is recorded - a similar issue arose recently with
the Glasgow Coma Scale when e.g. Eyes could not be observed.
There are 2 potential solutions..
1. Add a 'reason for null' text attribute in the Reference model
alongside the null itself.
I think this would be practical and easy. I don't see the need for each
of the 100 posible reasons for null to be computable, just the fact of
being not applicable, not available or unknown should be enough for
computing purposes (but - maybe some researcher will show why this is
wrong). An additional text attribute would seem a good start.
2. Use the link attribute available to every node to attach an
'annotation' - this will be recorded in a separate archetype, which
allows considerable flexibility as to whether a simple text field is
required or perhaps more complex, structured 'reasons for null' are
required. This approach is being investigated as a means of annotating
data elements for quality or 'fitness-for-purpose'. e.g. Is a device
obtained blood pressure valid fro graphing or should it be excluded?
I think this is not a good idea, as it complicates the recording of even
simple data with Links, which are essentially cross-references, which
are more difficult to process.