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

Ian McNicoll Ian.McNicoll at oceaninformatics.com
Wed Oct 3 06:16:06 EDT 2012


No don't include 'Other' as a coded text choice. That is just a UI prompt.
This does have to be explained to developers.

Ian



On 3 October 2012 11:08, Athanasios Anastasiou <
athanasios.anastasiou at plymouth.ac.uk> wrote:

> Hello Peter
>
> Thank you for the helpful response.
>
> In that case would "other" still have to be included in the DV_CODED_TEXT
> part of the CHOICE (?)
>
> All the best
> Athanasios
>
> P.S. "Choice" (as an element) has escaped my attention so far as i have
> been focusing on what constitutes about 85% of the elements currently in
> use by the archetypes at the CKM. (Purely because of time constraints)
>
>
>
>
>
>
>
>
>
>
>
> On 03/10/2012 10:55, Peter Gummer wrote:
>
>> Hi Athanasios,
>>
>> The way to do this in the Archetype Editor is by adding a "Choice"
>> element.
>>
>> With the Choice element, you can add multiple constraint types to the
>> same node. In this particular case, you would add two Text constraints, one
>> free text and the other with the internal codes.
>>
>> This is such a common scenario that there is a proposal to make it easier
>> to do this. Here is the text of the change request (which maybe someone
>> will get around to doing one day):
>>
>>
>>  Currently whenever modelling DV_coded text in an archetype, in 90+% of
>>> cases the true requirement is actually to model a choice of the
>>> DV_CodedText plus a DV_text (for the almost inevitable 'Other' options).
>>> Looks awkward and cumbersome. Additional step for nearly every one of these
>>> modelling situations.
>>>
>>> However modelling this is cumbersome for so many text situations. After
>>> discussion with Sam, an option would be to allow the modeller to select
>>> DV_coded text and at the same time the application would automatically add
>>> the DV_text choice to the ADL underlying it by default. In the less common
>>> instance where the DV_text was not desired, then the modeller could deselct
>>> this as a checkbox from the AE Text attribute interface
>>>
>>> So, request additional functionality:
>>> 1. Modeller adds a text data type, names it.
>>> 2. Selects a DV_CODEDTEXT ie Internal codes or Terminology -> Choice of
>>> DV_CODEDTEXT plus DV_TEXT is written to the ADL as default (likely 90+%
>>> likelihood that this combination is to be used)
>>> 3. Modeller deselects checkbox to remove the DV_TEXT component in less
>>> common situation that it is not desired.
>>>
>>
>>
>>
>> Peter
>>
>>
>> ______________________________**_________________
>> openEHR-clinical mailing list
>> openEHR-clinical at lists.**openehr.org <openEHR-clinical at lists.openehr.org>
>> http://lists.openehr.org/**mailman/listinfo/openehr-**
>> clinical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org>
>>
>>
> ______________________________**_________________
> openEHR-clinical mailing list
> openEHR-clinical at lists.**openehr.org <openEHR-clinical at lists.openehr.org>
> http://lists.openehr.org/**mailman/listinfo/openehr-**
> clinical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org>
>



-- 
Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
Director openEHR Foundation  www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
SCIMP Working Group, NHS Scotland
BCS Primary Health Care  www.phcsg.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20121003/7ccf255d/attachment.html>


More information about the openEHR-clinical mailing list