# Modelling not-applicable fields **Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153) **Created:** 2010-06-25 10:58 UTC **Views:** 5 **Replies:** 3 **URL:** https://discourse.openehr.org/t/modelling-not-applicable-fields/14993 --- ## Post #1 by @user3 Hi all! 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? Thank you for answers. --- ## Post #2 by @ian.mcnicoll Hi Igor, 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: [http://www.openehr.org/wiki/display/spec/Null+Flavours+and+Boolean+data+in+openEHR](http://www.openehr.org/wiki/display/spec/Null+Flavours+and+Boolean+data+in+openEHR) 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.. 1. Add a 'reason for null' text attribute in the Reference model alongside the null itself. 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? Ian Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll [ian.mcnicoll@oceaninformatics.com](mailto:ian.mcnicoll@oceaninformatics.com) [ian@mcmi.co.uk](mailto:ian@mcmi.co.uk) Clinical Analyst Ocean Informatics openEHR Archetype Editorial Group Member BCS Primary Health Care SG Group [www.phcsg.org](http://www.phcsg.org) / BCS Health Scotland 2010/6/25 Игорь Лизунов <[i.lizunov@infinnity.ru](mailto:i.lizunov@infinnity.ru)> --- ## Post #3 by @thomas.beale Igor, 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. - thomas beale --- ## Post #4 by @thomas.beale > > 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\. \- thomas beale --- **Canonical:** https://discourse.openehr.org/t/modelling-not-applicable-fields/14993 **Original content:** https://discourse.openehr.org/t/modelling-not-applicable-fields/14993