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

Sam Heard sam.heard at oceaninformatics.com
Wed Oct 3 17:03:24 EDT 2012


Hi Mads

The DV_TEXT in openEHR is unique in that it can meet your needs. This IS 
a free text field but it can be replaced with a DV_CODED_TEXT whenever 
needed. This is because DV_CODED_TEXT inherits from DV_TEXT and offers 
the same interface. The modeller can insist on coded values if appropriate.

The sort of coded value and other - or typing text and then having it 
coded etc are all useful user interface options. How this is done will 
depend on the application. So our models do not say anything about that: 
only if it can be free text or it must be coded. If it must be coded we 
do allow an internal code set.

Cheers, Sam

On 4/10/2012 5:09 AM, Ian McNicoll wrote:
> This was bounced for some reason - reposted.
>
> Ian
> --------- Forwarded message ----------
> From: Mads Hjorth <MALH at ssi.dk <mailto:MALH at ssi.dk>>
> To: For openEHR clinical discussions 
> <openehr-clinical at lists.openehr.org 
> <mailto:openehr-clinical at lists.openehr.org>>
> Cc:
> Date: Wed, 3 Oct 2012 19:17:13 +0000
> Subject: RE: Best type for encoded values including "other" (implying 
> free text)
> Hi list,
>
> It has been very interesting for me to follow your discussion about 
> modeling of health data. I do not have a much health-data-specific 
> experience to offer (yet), but I do recognize a few patterns from 
> modeling in many other domains.
>
> Allow me to pitch in with an idea for solving the specific problem in 
> this thread.
>
> Why not always allow free-text and ask the user to use her own words 
> first, then ask to pick from a set of restricted classes incl. the 
> famous 'other'?
>
> I understand there can be reasons that has to do with 'effective 
> typing'. It might be faster to pick from a list of codes, than to 
> write a few words. But I think a well-designed html-application would 
> allow a user to click the text field, type in a few letters, get 
> suggestions from previously used phrases, then tab on to dropdown next 
> to, select from a list of available classes and then move on.
>
> Another argument against "free text first, then selection of class" 
> could be the unease of free text in registers and databases. But I 
> would consider the free text a very valuable piece of information and 
> I don't see any reasons not to collect as many as possible. They don't 
> cost much in terms of either bandwidth or storage in modern it-systems.
>
> What do you think about this idea?
>
> Mads Hjorth
> it-architect
> National Board of E-Health, Statens Serum Institut
>
> T (direkte) 7221 6816 | E mah at nsi.dk <mailto:mah at nsi.dk> | W ssi.dk 
> <http://ssi.dk/>
> Adresse:  Islands Brygge 67 | 2300 København S
>
> -- 
> 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 
> <mailto:ian.mcnicoll at oceaninformatics.com>
>
> Clinical Modelling Consultant, Ocean Informatics, UK
> Director openEHR Foundation www.openehr.org/knowledge 
> <http://www.openehr.org/knowledge>
> Honorary Senior Research Associate, CHIME, UCL
> SCIMP Working Group, NHS Scotland
> BCS Primary Health Care www.phcsg.org <http://www.phcsg.org>
>
>
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20121004/2c093fd9/attachment.html>


More information about the openEHR-clinical mailing list