gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jim Busser
Subject: Re: [Gnumed-devel] clinicians: coding use case survey - please respond !
Date: Wed, 04 May 2011 14:01:14 -0700

On 2011-05-04, at 11:17 AM, Rogerio Luz Coelho 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"






reply via email to

[Prev in Thread] Current Thread [Next in Thread]