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:
>
> 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:
>>
>> 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 at oceaninformatics.com
>> ian at mcmi.co.uk
>>
>> Clinical Analyst Ocean Informatics openEHR Archetype Editorial Group
>> Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health
>> Scotland
>>
>>
>>
>> On 29 June 2010 12:26, Leonardo Moretti <lmoretti at noemalife.com> wrote:
>>
>>>
>>> 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:
>>> >
>>> > 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 at oceaninformatics.com
>>> > ian at mcmi.co.uk
>>> >
>>> > Clinical Analyst Ocean Informatics openEHR Archetype Editorial Group
>>> > Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health
>>> > Scotland
>>> >
>>> >
>>> >
>>> > On 25 June 2010 16:07, Moretti Leonardo <lmoretti at noemalife.com>
>>> wrote:
>>> >
>>> >> 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
>>> >>
>>> >> _______________________________________________
>>> >> openEHR-technical mailing list
>>> >> openEHR-technical at openehr.org
>>> >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>> >>
>>> >
>>> > _______________________________________________
>>> > openEHR-technical mailing list
>>> > openEHR-technical at openehr.org
>>> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://old.nabble.com/Empty-string-for-DV_TEXT-tp28993527p29022604.html
>>> Sent from the openehr-technical mailing list archive at Nabble.com.
>>>
>>> _______________________________________________
>>> openEHR-technical mailing list
>>> openEHR-technical at openehr.org
>>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>>
>>
>> _______________________________________________
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>
>>
>
>
--
View this message in context:
http://old.nabble.com/Empty-string-for-DV_TEXT-tp28993527p29024312.html
Sent from the openehr-technical mailing list archive at Nabble.com.
