# Empty string for DV_TEXT **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2010-06-25 15:07 UTC **Views:** 7 **Replies:** 13 **URL:** https://discourse.openehr.org/t/empty-string-for-dv-text/14990 --- ## Post #1 by @Leonardo_Moretti In http://www.openehr.org/releases/1.0.2/architecture/rm/data_types_im.pdf, DV\_TEXT is defined as a text item\. Among "Invariants" \(page 29\), I found that this data type is valid if it is not empty \(Value\_valid: value /= void and then not value\.is\_empty and then not\(value\.has\(CR\) or value\.has\(LF\)\)\)\. Does this mean empty string is not a valid value for DV\_TEXT? If so, why empty string cannot be a valid value? An empty string could be meaningful, with a different semantic than null value\! Many textual information could be an empty string \(comments, descritpions\.\.\)\. An empty string means that the value is exactly a void string, a null value means that the information is unknown, not taken, not asked\! Regards leo --- ## Post #2 by @ian.mcnicoll Hi Leo, An important principle under-pinning openEHR is that 'empty' data is not normally recorded, which is consistent with general clinical practice information recording. On this basis, I am not sure I can see the use case for recording "" i.e. Empty text. If a text data entry field is left blank, this would simply not be recorded in openEHR data. If the field is mandatory, either the user is forced to make some sort of entry or perhaps is allowed to select one of the null values as you suggest. Regards, 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 --- ## Post #3 by @Leonardo_Moretti Hi Ian, in my opinion an empty string has a semantic difference with a null value\. Empty string is however a valid value\. For example, I could have different cases for "Comment" in openEHR\-EHR\-OBSERVATION\.blood\_pressure\.v1: \- a non\-empty string with the comment on blood pressure measurement\. \- an empty string, meaning that no comment has been given from the doctor, because not needed \(doctor judges that no comment is necessary\) \- a null value, meaning that no comment has been asked to the doctor, because exluded from the template/GUI\. Or there are an other way to model these three cases? Regards, leo Ian McNicoll\-3 wrote: --- ## Post #4 by @ian.mcnicoll Hi Leo, In pure semantic terms I appreciate the difference but this is practically of no value. What does this empty string mean? Is it? a) The doctor simply did not add any comment. b) The doctor purposefully 'added an empty string' by clicking through the data entry widget, perhaps to signify 'no comment'. c) The doctor couldn't add a comment for some other technical / environmental reason. These are very subtle differences to most clinical staff and I would not want to base any safe querying on assumptions that clinicians would record these differences reliably. If there is a need to positively identify 'no comment', I would model that explicitly but this is rare in clinical practice, and usually is recorded for medico-legal reasons rather than future querying e.g. 'No known allergies' is a legitimate clinical comment but cannot ever be safely queried upon, since the next clinical statement in the record might well be 'Diagnosis = Penicillin Allergy'. The most significant principle is that we do not normally record 'empty data' at all in openEHR. The data simply does not exist in the clinical record. If some sort of comment is mandatory then using the null is the means to allow an empty comment. I have copied ot the clinical list, as it would be interesting to get some other feedback. 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 --- ## Post #5 by @Leonardo_Moretti Ok, Ian, using a null value, a null flafour is needed\.\. For your example cases: a\) The doctor simply did not add any comment\. b\) The doctor purposefully 'added an empty string' by clicking through the data entry widget, perhaps to signify 'no comment'\. c\) The doctor couldn't add a comment for some other technical / environmental reason\. and looking at codes in section 2\.3\.7 of http://www.openehr.org/releases/1.0.2/architecture/terminology.pdf, I would use: for a\) and b\): HL7\_NullFlavor::10614 \(AskedButUnknown\), but it doens't have an analogous values on opeEHR code system c\) HL7\_NullFlavor::10614 \(temporarily unavailable\), but also in this case it doens't have an analogous values on opeEHR code system Maybe my perplexity is due to an incomplete value set for Null Flavours vocabulary found in openEHR specs\.\. Should this vocabulary be extended\!? Regards leo Ian McNicoll\-3 wrote: --- ## Post #6 by @ian.mcnicoll Hi Leo, 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) for a decent discussion. My personal take is that expanding the openEHR list to cover 'asked but unknown' might be reasonable, but as Grahame Grieve suggests in one of his comments, the difficulty is that this may often be clinically insufficient or imprecise, depending on context. i.e sometimes clinicians need/want to record even more detail about the reason for the value being null. Grahame has suggested that a text attribute be useful to add to both HL7 and openEHR nulls but I think a more flexible approach is to use a 'Citation' or annotation archetype linked to the Null element via a LINK attribute. This gives systems developers complete flexibility as to the use / degree of structure of the additional data. The current approach that we tend to take with Yes/No constructs and text terms is to model the terms explicitly, according to the clinical requirement. e.g for a finding related to presence of cancer at a surgical resection margin, we have modelled this as Evidence of tumour at margin: Tumour present Tumour absent Indeterminate which matches the Snomed approach. Regards, 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 --- ## Post #7 by @Leonardo_Moretti In the case of "Comment" in openEHR\-EHR\-OBSERVATION\.blood\_pressure\.v1, the ADL definition is: ELEMENT\[at0033\] occurrences matches \{0\.\.1\} matches \{ \-\- Comment   value matches \{     DV\_TEXT matches \{\*\}   \} \} This means that here I cannot specify a null\_flavour for Comment element\! Maybe should this archetype be extended as in the following? ELEMENT\[at0033\] occurrences matches \{0\.\.1\} matches \{ \-\- Comment   value existence matches \{0\.\.1\} matches \{     DV\_TEXT matches \{\*\}   \}   null\_flavour existence matches \{0\.\.1\} matches \{     DV\_CODED\_TEXT matches \{       defining\_code matches \{           \[openehr::           271,           272,           273\]       \}     \}   \} \} Regards leo Leonardo Moretti wrote: --- ## Post #8 by @ian.mcnicoll Hi Leo, No it works the other way round. All of the null flavours are automatically available unless you specifically constrain them out. 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 --- ## Post #9 by @Leonardo_Moretti Thank you Ian, you are right, null\_flavour tag is not needed\. But in the previous post I proposed also an other change: in the original ADL code ELEMENT\[at0033\] occurrences matches \{0\.\.1\} matches \{ \-\- Comment        value matches \{                DV\_TEXT matches \{\*\}        \} \} value doesn't have the existence attribute specified\. Being the default for existence attribute \{1\.\.1\}, a DV\_TEXT value tag is required\! But when we have an empty Comment, we cannot have a DV\_TEXT value tag, so we can neither have the whole ELEMENT structure, and so we cannot specificy a null\_flavour\! To be able to do this, this extension would be needed: ELEMENT\[at0033\] occurrences matches \{0\.\.1\} matches \{ \-\- Comment        value existence matches \{0\.\.1\} matches \{                DV\_TEXT matches \{\*\}        \} \} regards leo Ian McNicoll\-3 wrote: --- ## Post #10 by @ian.mcnicoll Hi Leo, I think this wiki page probably explains this particular issue [http://www.openehr.org/wiki/display/dev/Existence+of+Attributes+(AOM,+ADL+and+XML)](http://www.openehr.org/wiki/display/dev/Existence+of+Attributes+(AOM,+ADL+and+XML)) [](http://www.openehr.org/wiki/display/dev/Existence+of+Attributes+(AOM,+ADL+and+XML))but it is pushing my technical knowledge to the limit, so I hope someone else will pitch in to any further discussion. 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 --- ## Post #11 by @Leonardo_Moretti Hi Ian, thank you very much, this is exactly my issue\! Does anyone know if it is scheduled a next release of this reference parser? Thanks again leo Ian McNicoll\-3 wrote: --- ## Post #12 by @thomas.beale why not? The value attribute is optional\. \- thomas beale --- ## Post #13 by @thomas.beale > ``` > Thank you Ian, you are right, null_flavour tag is not needed. > But in the previous post I proposed also an other change: in the original > ADL code > ELEMENT[at0033] occurrences matches {0..1} matches { -- Comment > value matches { > DV_TEXT matches {*} > } > } > value doesn't have the existence attribute specified. > Being the default for existence attribute {1..1}, a DV_TEXT value tag is > > ``` this is a problem in ADL 1.4 that will disappear in ADL 1.5 - thomas beale [details="(attachments)"] ![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg) [/details] --- ## Post #14 by @thomas.beale any day now....;-) - thomas beale --- **Canonical:** https://discourse.openehr.org/t/empty-string-for-dv-text/14990 **Original content:** https://discourse.openehr.org/t/empty-string-for-dv-text/14990