Best type for encoded values including "other" (implying free text)

Athanasios Anastasiou athanasios.anastasiou at plymouth.ac.uk
Wed Oct 3 06:21:10 EDT 2012


Hello Thomas

Thank you for your response. I think that i should have provided a bit 
more information indeed. Here are the possible responses:

1) House
2) Condo/Co-op (owned)
3) Apartment (rented)
4) Mobile Home
5) Retirement Community
6) Assisted Living
7) Skilled Nursing Facility
*) Other (specify)

So, it is a case of "other" requiring a response.

I suppose that it is one of these fields where, it is good to keep that 
information to refer to it back after performing some data analysis and 
finding some discrepancies. That information may be useful in this case. 
(Rather than expecting someone to query for that free-text "other")

 > Now, I realise that the situation as you describe it probably is a
 > relatively common pattern, and there is probably an argument for making
 > ....
 > only need one data point; the free text one is left empty.

It wasn't so much of a feature request :-)
But having been reminded of the Choice element by Peter, maybe what you 
explained here could be added anyway and automatically resolve to a 
"Choice" field.

All the best
Athanasios Anastasiou





On 03/10/2012 11:06, Thomas Beale wrote:
> On 03/10/2012 10:43, Athanasios Anastasiou wrote:
>> Hello everyone
>>
>> I have come across this situation where one of the fields i need to
>> describe in an archetype (Residence Status) contains 8 strictly
>> encoded values, one of which is "Other" implying that besides the
>> encoded values, free-text would also be acceptable.
>
> the first thing I would check is whether that is actually true - or if
> 'other' is just another code, and there is no expectation of expressing
> the actual value separately. Because in the first 7 cases, the data
> structure is
>
> DV_CODED_TEXT = <
>      value = <"code description for 1234567">
>      defining_code = <
>          terminology_id = <"residence_status_codes"> -- or whatever it is
>          code_string = <"1234567">
>      >
>  >
>
> (assuming you want the code rubric to be available), and in the 8th, if
> you want an actual value, it is
>
> in the 8th case, you are implying it is something like:
>
> DV_CODED_TEXT = <
> *    free_text_value = <"some other kind of residence status">*
>      value = <"other">
>      defining_code = <
>          terminology_id = <"residence_status_codes"> -- or whatever it is
>          code_string = <"99999">
>      >
>  >
>
> which doesn't really work. You would need two data points to do this
> properly in an archetype, so no tool is going to be able to do this job
> with a single data point (i.e. a single DV_TEXT or DV_CODED_TEXT).
>
> Now, I realise that the situation as you describe it probably is a
> relatively common pattern, and there is probably an argument for making
> the archetype editor support it in a way that allows the user to just
> specify it in a logical way, and the editor creates the appropriate
> constraints on two data points to cover the 'other' case. It's not a
> completely obvious construct however, since for the other 7 codes, you
> only need one data point; the free text one is left empty.
>
> - thomas
>
>
>>
>> I am a bit puzzled as to how to represent this through the archetype
>> editor and would appreciate your help with the following:
>>
>> *) The type is clearly DV_TEXT ("free text or encoded")
>>
>> *) DV_TEXT does not allow one to constrain the encoded part ("internal
>> codes") through the archetype editor (i think)
>>
>> *) DV_CODED_TEXT is a descendant of DV_TEXT
>>
>> *) DV_CODED_TEXT has stricter semantics than DV_TEXT
>>
>> 1) If this was declared as DV_TEXT "free text or encoded" how can one
>> constrain its content? (Through the archetype editor)
>>
>> 2) If this was declared as DV_CODED_TEXT, should "other" be part of
>> the "internal codes" in a DV_CODED_TEXT? (I am not sure this would be
>> right because in this case, you can't store the actual free-text
>> "value" anywhere. The "value" of this will be "other")
>>
>> 3) Is this situation expected to be resolved at the template level? If
>> yes, how is that achieved? (What i mean is, how do you decide if this
>> is a "strictly multiple choice field" or "multiple choice with
>> optional free text"
>> *
>> *




More information about the openEHR-clinical mailing list