[Gnumed-devel] Richard's phrase wheel comments

[richard terry]

snip:

>In general IMHO we shouldn't make the phraseweels too smart because this
>will always limit the number of matches found in a certain situation. 
>Therefore
>we will have to find a  balance between further decreasing result sets and
>finding the wanted item in the result set at all.

Guys,

Take care with all this. SIMPLICITY should be the key.

Please refer back to the section documentation. For example when prescribing, 
say for gout in the example below, on an actual paper script, we don't write 
the first line as 'gout', we write
 Rx
 Allopurinol (or Brand eg Zyloprim) 
300mg tabs
1 mane
for gout

ie the phrase wheel dosn't need much intelligence here. It is simply a vehicle 
to pop up lists - it needs to troll the database for all drugs starting with 
'a...' if generically prescribing, or 'z..' if brand name prescribing'

Now, if you may be prescribing from the SOAP notes end of things, and not the 
prescribing section where you have just made the diagnosis of gout, this are 
different:

Subjective:painful toe
Objective :red swollen ist i-p joint;left side;
Assessment:Gout

As the cursor hits the Plan line we need some intelligence, part of which can 
be learned intelligence if needed. The wheel could contain several plans 
single or combined for the user to choose eg:

- script indomethacin 25mg caps 2 tds for 2/7 then qid;
- dietry information sheet
- script allopurinol 100mg 1 mane start in 1 week
- colchicine  2 stat, 1 2nd hrly till diarrhoea then 1 tds
- appointment 2 weeks

This info could be different if say patient has peptic ulceration history etc.

I think it is a mistake to try and build too much complexity into this at the 
first stage - think simple - think trawling database for simple lists.

Regards

richard




On Fri, 10 Oct 2003 01:21 am, Karsten Hilbert wrote:
> > > For example, if a patient has gout, and the user types "a", the
> > > phrasewheel should return "allopurinol" as its first guess, but
> > > if the disease is depression, the guess should be, say, 
> > > "amitryptaline"
> >
> > One way to do this could be to store score-tables for every unique
> > combination of the relevant entry fields.
> >
> > create table score_gmpw_sql_prescriptions (
> >     id serial primary key,
> >     fk_gmpw_sql_test integer not null references gmpw_sql_test(id),
> >     "user" name not null default CURRENT_USER,
> >     score bigint not null default 0,
> >       fk_entry_fields_combination not null references
> > gmpw_combinations_prescriptions(id); );
> >
> > create table gmpw_combinations_prescriptions (
> >                 id serial primary key,
> >                 entry_field1_term text default null,
> >                 entry_field2_term text default null,
> >                 ...
> >                 entry_fieldn_term text default null,
> >                 unique(entry_field1_term, entry_field2_term, ...,
> > entry_fieldn_term)
> > );
>
> Holy cow ! :-))  Am I missing something if I suggest using a
> "cookie" text default null column in score_(*)_prescriptions
> which is a concatenated string of the appropriate values and
> let the widget care about which field the actual values are
> taken from in which order ?  Of course, without a clear
> definition of a separator character (newline ?) this would be
> a one-way field (albeit sufficient lest I be mistaken).
>
> > -we must choose the number of relevant entry fields carefully (note that
> > the number of possible combinations is
> > (num_of_entry_fields)^(num_of_possible terms)).
>
> That's IMHO inherent to the approach and not really avoidable.
>
> > In general IMHO we shouldn't make the phraseweels too smart because this
>
> Absolutely agree !
>
> > will always limit the number of matches found in a certain situation.
>
> The matches needn't be hard limits. If the user keeps typing
> after exhausting the matches the match provider can broaden
> its search space.
>
> Karsten