[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] state of test results handling
From: |
James Busser |
Subject: |
Re: [Gnumed-devel] state of test results handling |
Date: |
Sat, 29 Mar 2008 12:04:20 -0700 |
Screenshot feedback:
- beneath Kirk's name, there appears a partly-formed rectangular
button (?) or am I misinterpreting? (screenshot attached)
******************************
Cells and selections and reviewing / signing:
- how did a semi-discontinuous selection of cells get highlighted
blue (RBC in the left column, together with all 4 cells in the right
column)
- if I correctly interpret that the action of the "Review" widget
will be to "set or reset" the values of all items in the table (based
on the checkbox selections within the widget), then this may be an
unwise implementation, since almost never will *all* displayed items
warrant the same attribute. Can the setting / resetting of the item
attributes be based on a multiple selection rather than based on the
total contents of the table? Under this alternative design, if
nothing had gotten selected, nothing would get coded as having been
reviewed, suggesting maybe all items in the display should be pre-
selected by default.
- would the checkbox "Technically abnormal" within the Review widget
serve to let the user overwrite (alter) whatever value had been
provided by test_org? If this ability is intended, it changes the
usage of this column relative to what is currently-defined in the
schema text!
- suggest the "Review" button be relabeled "Review..." since, after
it is clicked, it requires additional user decisions and actions
- suggest that next to the Review button be added "Abnormal-only" and
"Significant-only" which would filter (subselect) from within the
current display... these buttons would ignore whether or not any
cells had been highlighted
- in the case where the display contains a large number of items,
there won't be enough room for them to be re-displayed inside the
Review widget, which then would create a problem, therefore remove
this display from inside the widget? I suppose it would no longer
then be correct for the prompt to say "... ALL test results listed
below", it would have to say "... ALL items currently-selected." If
it is easy to implement, a "count" of the number of items currently-
selected could be performed, and if it were a single item, *that* one
could be represented in the widget, and otherwise the prompt could
say "... ALL <n> items currently-selected."
- finally (for now) there is ambiguity in English in the meaning of
the word "review" because to review can simply mean "to look at
(again)" and may or may not mean to examine critically, and even if
critical examination of the results was performed, it is possible to
choose not to record this activity. In point of fact, although not
everyone would vote in favour, it could be possible for each view to
create a row in clin.reviewed_test_results which would capture
whoever it was that "reviewed" these results. What we are really
talking about is *acknowledging* (and implying the taking of
responsibility for) the results. I am OK to leave the name "review"
in schema's columns (fields). However I think it advisable that in
the user interface we use the word "Sign.." on the button, and in the
widget change "This review" to "This signing" (and "the review" to
"this signing"). If this is agreed to be a good idea then this
revision could be similarly applied to the document signing.
******************************
Test naming that is offered in the table [presumably "code" ("name")]
- this could come from the table test_type or potentially from
test_type_unified... shall we figure on at least two scenarios...
i) when reviewing as-yet unsigned results, the user is presumably
presented with the specific test-type as returned by the test_org
from which the result came
ii) is it already possible to see lab results *not* through the
inbox, to show/see *all* existing lab results? And a future version
will permit a subselection among available results?
iii) would test_type_unified only be used through a different method
of user access, for example the user accesses a widget that presents
all test_type_unified values within which the user can select one or
multiple, and these then become the basis for the test naming in the
Test column?
******************************
Presentation of the results (suggestions):
sort order (or vertical presentation order) among the results that
are to be viewed... many of us are very accustomed to seeing tests
presented with both internal relationships (tests within a battery
like hematologic tests Hb WBC platelets) appearing together and ---
in my case --- above the "chemistry" with immunology and other
special testing and microbiology and pathology lower down. Is there
some way to establish and manage this? I do notice, within the
tooltip or right-click, the fields "Grouped under" and "Type comment"
test names in plain text, instead of bold
right-justify the results, within the cells
for non-numeric results, present the first 4 characters?
pad the right end of each result with 3 "space" characters
3rd space is populated with first character of abnormality_indicator
(dunno if this will get confused by varied indicators, like * or H
or h or upward-pointing arrow)
maybe needs to be monospace font to maintain vertical visual alignment
make technically abnormal results red
suggest clinically significant results do not affect formatting, but
only the filterability
- if it would be possible for a single view to display a mix of
already-signed plus unsigned results, is it desired that any
distinction be made visually? or just rely on persistence of the
unreviewed results line item in the inbox?