Re: [Gnumed-devel] clinicians: coding use case survey - please respond !

[Karsten Hilbert]

On Wed, May 04, 2011 at 02:01:14PM -0700, Jim Busser wrote:

> > Yep ... you will pick that code 20 - 100 Thousand times, by the 4th time 
> > you will memorize it and it will be faster, but in NO WAY will the program 
> > be responsible for picking a code on your behalf. We can give you some 
> > hints, maybe, but it will be widely understood that it is the USER´S job to 
> > actually put the code together with the encounter. 
> 
> I will go back to the earlier post to review method 1 vs method 2.
> 
> However on this question of populating both descriptions (episodes, Health 
> Issues) and code tags, there are two main individual-patient scenarios, and 
> the resulting across-patients-cascade scenario if it is to be implemented at 
> all.
> 
> One scenario is the legacy / late-feature / late-workflow scenario, where 
> many uncoded descriptions will already have been created in GNUmed, on 
> account of records having been imported from a legacy system and.or GNUmed 
> being in use for a while before the ability to attach codes became available. 
> this is the semi-backward-facing, semi-forward facing scenario.
> 
> The second individual-patient scenario is the forward-facing one where it is 
> at the time of adding (creating a new) or updating (improving) an episode 
> description that the opportunity to also attach one or more codes is to be 
> figured out.
> 
> Every time one of these codes gets used, and bearing in mind that an 
> associated official reference term exists, the user could save time and 
> achieve consistency if -- in the case of the so-far empty description field 
> -- the official reference term could auto-fill the description. The user 
> could then decide whether or not to modify ("tweak') it.
> 
> In the case of an already-previously-saved description, the user will have to 
> choose whether to
> 
> - keep the description, and
>       add one or more code tags, and/or
>       remove one or more code tags
> 
> - alter or improve the description, and
>       add one or more code tags, and/or
>       remove one or more code tags
> or
> 
> -     add one or more code tags, and/or
>       remove one or more code tags AND
>       overwrite the existing description with one of the codes' official 
> reference terms
>       +- tweak the official reference term
> 
> I would suggest that where the description had been
> previously created and is non-null / non-empty, the widget
> should be programmed to NOT overwrite the existing text
> however if the user knows they want to attach 3 codes, the
> user can choose to empty (select/delete or backspace over)
> text in the description field, and when in this "state" the
> widget could know that when the next code is selected the
> code's associated official reference term is to overwrite
> (populate) the description which the user had decided to
> "blank out"

All this I agree with.

But am I missing the tail of the mail ?

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346