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 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 15:29, Leonardo Moretti <lmoretti at noemalife.com> wrote:

>
> 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.
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100629/710477c2/attachment.html>

Reply via email to