Re: [Gnumed-devel] clinician input wanted: how to implement "coding"

[Jim Busser]

On 2011-05-29, at 3:07 PM, Karsten Hilbert wrote:

> On Fri, Jun 18, 2010 at 08:15:15AM -0700, Jim Busser wrote:
> 
>> I am thinking that even if I knew that in ICD9 the code
>> "401" refers to essential hypertension, maybe it is a bad
>> idea to offer a codewheel as the primary basis for inputting
>> diseases or conditions.
> 
> Why would anyone ever consider doing any such thing ?

+1

(You ask from the forward-looking, sensible perspective.)
( I had posted from the backward-looking "let us not repeat what others have 
actually done in other projects / software".)

> 
>> Ideas:
>> - prebuilt query to find patients somehow attached (related) to the current 
>> user who lack any codes
> 
> The report generator can be used for that.

+1

> 
>> - within-patient
>>      - (1) visual indicator that is always in view or is that distracting
>>      - (2) "peek" view that exposes what is present and missing, which 
>> disappears on release of mouse or key?
>>      - (3) button that *alters* the view to present a different view that 
>> relists the problems as
>>              problem 1 as original text
>>                      1st of n codes attached, plus word equivalent
>>                      2nd of n codes attached...
>>                      ...
>>              problem 2
>>                      etc
> 
> The problem list will always show the problems as original text.

What I listed above as (1) (2) (3) were all options. Even just one would be 
helpful. What I intended with option (3) included to still see *most* of the 
original problem as text… I was only thinking that the limitations of screen 
and column width – a column wide enough to display multiple codes would 
severely constrain the width that remained to still show the problem text.

A way to handle the above would be to keep the column for the display of codes 
narrow, because in the situation where more than one existed per problem it may 
be enough for the user to see the first one followed by ellipses, so

        <code_system:code1>…

but this would still considerably limit the ability to read problem name text. 
That is why I was thinking some kind of toggle button – toggle to see a column 
of codes, despite that this column limits what can be seen of the problem text, 
and then toggle back again to enjoy the full with of being able to read the 
problem text.

This still leaves the challenge of how to easily see (without having to hover 
over every single health issue) whether none, some, or all have codings against 
them.

Here is an idea… what if the basic display, which would still preserve nearly 
the full width of the problem text, could dedicate a thin strip of a column 
either to the left or right of the descriptive text? I am thinking a thin 
column "strip" that would require only 5 pixels in width:

        - one pixel vertical border on each side of a 3-pixel-wide space that 
is white by default. When one or more codes have been inputted, the "strip" 
next to the problem text would be filled with a colour, I would suggest grey 
might be least distracting. Toggling would show more column width (enough to 
show one code, stealing width from the display of the problem text).

-- Jim