[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] clinician input wanted: how to implement "coding"
From: |
Jim Busser |
Subject: |
Re: [Gnumed-devel] clinician input wanted: how to implement "coding" |
Date: |
Sun, 29 May 2011 22:12:53 -0700 |
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