Re: [Gnumed-devel] Measurement workflows

[Karsten Hilbert]

On Mon, Jul 08, 2013 at 05:49:18PM +0000, Jim Busser wrote:

> Now that I am at a point to want to manually enter at
> least *some* patient measurements, I wanted to review the
> intended relationships between the kinds of measurements and
> it may be best to visit how the data entry is so far
> designed to work …

Review is good.

> Currently, when a patient and the Measurement plugin are
> in focus, clicking the Add button prompts user input.
> 
> 1) first in the tab order is the Test name … here a
> single letter is enough to activate the word-match
> phrasewheel.

Do we want it to be 2 letters ?  Note that 1 letter only
shows matches which *start* with that letter. By that I mean
the *very* first letter, not even the first letter of a word
within the test type string.

        "u" will match "urine dip"

but

        "d" will NOT match "urine dip"

> Test names (types) which I have previously
> entered, when selected, appear as
>
> foo (your own practice @ your own practice)

Because they are - when created - assumed to be in-house
lab, because the (more or less conscious) assumption was
that external results will come in bulk and will need to be
imported by scripts in order to make using them feasible
(despite me having entered quite a few external values in my
own installation).

> which assigns many characters to the test org and IMO
> distracts from the primary item of interest (the test type)
> so maybe later we can visit alternative representation of
> this information.

Agreed.

> 2) I have the impression that this "Add" widget has been
> coded so as to assume measurements that originated in the
> praxis, such as Weight or Blood pressure.

More or less, yes, see above.

> 3) The tooltip for the Test field says "The type of test
> or measurement this result is about." which does not inform
> me whether I can, via my input, create a new test or whether
> I can only select from among existing tests.

You can, as you found out. New ones will be assumed to be
in-house results. Feel free to suggest an improved tooltip ;-)

> To me, this kind of test result is a "state" and can be
> only positive, negative or indeterminate. I am not sure how
> "Units" apply.

There's your unit right there: "State"  :-)

> It seems to me that these Units should be allowed to be
> "null".

It is already - for non-numeric results, however. I only
checked at the DB level, though. Ah, I see, the edit area
enforces non-NULL uniformly.

I have improved that part.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346