Re: [Gnumed-devel] test-area/sjtan

[Hilmar Berger]

> I have been thinking of storing the scores in link tables but
> haven't fully thought through that yet. Let's consider
> diagnosis strings as an example. One has two sources for
> matches: the previously used diagnoses and the official ICD-10
> table (here in Germany, that is, where we use ICD-10-GM).
> 
> My idea so far is to make the widget
> 
> a) get matches from both sources and merge/sort them
I personally would consider all sources as just one large list (that is,
there should be no need to name the single lists it consists of, i.e.
DiagnosisMatchList instead of (ICD-10,UserDefinedDiagnoses)).
Maybe we need some class to transparently handle a number of sources.
> b) store the selected diagnosis in the patient-related table
>    - this may be an ICD-10 string, a previously used
>      non-ICD-10 string, or a completely new phrase
> c) update the score in a link table linking patient-related
>    diagnosis, score and user
Link tables seem to be a reasonable solution, on the other hand we have to
make sure that the references to the source table never get wrong. 

One could additionally make a distinction between queries that should run on
the whole list from the very
beginning and those that should first search in a reduced set (the
favourite/known entries) and continue to search on the whole list only after 
failing
to find the term in the first set.

> Does that make sense ?
> 
> (Of course, scores don't make all too much sense with things
> like streets and urbs, I'd say.)
Why not ? Usually your patients come from a particular region with a limited
number of streets/urbs. Inside this limited number the probability between
individual locations will be more or less equal, but compared to the rest of
the street/urbs you will get a clear peak in this probability distribution.
You can treat this peak as a special case (that is, limit your search to only
this set where the probability is higher than a threshold, e.g. streets of
your town) and don't use scores at all. Then you will need some way to 'switch'
to a general search method that takes the whole list into account if you
don't find the string in this limited set. Or you can search the whole list from
the very beginning. Or even have a mixture of both. In the latter case, you
would limit the first set to entries with a *score* higher than a given
threshold, in which case new streets will automagically show up next time, but 
you
will find them at the end of the list because of the low score. That way you
wont need different lists for "known" and "unknown" streets, you just
preselect the "known" from the whole list and keep the set to search small. I 
don't
know if this makes sense performance-wise, but well, just wanted to add my
0.01$ :)

Hilmar

-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++