[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Measurements and Documents and associations
From: |
Jim Busser |
Subject: |
Re: [Gnumed-devel] Measurements and Documents and associations |
Date: |
Thu, 02 Jul 2009 17:19:04 -0700 |
Except for "in praxis" measurements (blood pressure etc) which
would be
taken during an encounter, the other ("out of praxis")
measurements would
be imported.
Well, but if someone manually imports them from, say, a file
on disk they should surely be part of that already-existing
encounter and not some artificial secondary encounter. After
all that is the truth. That same encounter can very well
also contain document imports or whatever else.
I agree with your point. I should better have said "except for in-
praxis measurements and user-operated-manual imports of measurements"
...
The test results summary under encounter shows two lines per
result: first the value and unit, then the review status
- should we reduce that to just the first line at the
episode level ?
I think single lines are both more space-efficient, and much easier
to brain-parse. I would suggest that, at any higher-than-encounter
level of the tree, the interest is to be able to answer
- for this episode (or health issue), did we yet already do X test?
- was it technically normal?
... if abnormal, the measurement may warrant a closer review of its
details (including the time if this level of detail was not
displayed), along with any comments from the lab or clinician
I notice that an indicator (+, -) , if present, will be appended
inside ( ) however when there is only ( ) this is visually
distracting, is it agreeable to conditionally omit the ( ) when the
indicator is absent or null?
Also, within the encounter detail (as shown in the right of the EMR
tree) the date formatting is different for measurements than for
documents... can they be made consistent? Do we want the precise
times shown in the abstracted/pooled listings, or do we wish to
display times only inside the encounter-level?
Measurements and Results:
17.09. 18:17 PLT (platelets): 282 Gpt/l ()
MTA: test_comment
LMcC 2009-06-19 09:15: normal but relevant
Documents:
2009-06-17 patient photograph: "Captain Kirk pictures"
Something weird happens inside the 0.5.rc2 client when (inside the
measurements editor) I assign the measurement to an episode that is
sitting among unattributed, because when I selected such an
episode from
the drop-down menu, what is returned into the "Problem" field is
<name of my selected unattributed episode> / <name of an episode
belonging to a health issue>
or
<name of my selected unattributed episode> / <name of health issue>
although the unwanted fragment does not get saved... it is only
confusing in the widget.
---> is this reproducible by others, and is any log and launchpad
report
needed?
I cannot reproduce it. Only for episodes belonging to a
health issues does it show the issue description after a
hyphen.
Will inform, if I can further reproduce it
In the measurement editor, there is only enough room to label one
of the
fields "Problem" and not to label it (as with the Notelet editors):
Problem (episode) name
However in the Attach documents plugin, we presently have
Associate to episode:
---> can this be made Associate to problem (episode)
since this hints that a new problem (episode) can be created right in
this field, if none of the dropdown items match.
In fact, it should be the other way round: This field allows
selection of *episodes* not problems !
Episodes and problems are not the same thing ...
Well, they are not *exactly* the same, but an episode *can* be a
problem. An active episode of something which is *unattributed* still
remains something clinical (in my thinking, a problem) that is to be
dealt with, for as long as it remains active/open, which is why I
believe these show up in the first place, under the current Notes
editor, top left corner, under the column "Problems" ;-)
So maybe what you are saying is that a document might get associated
with a now-closed *unattributed* episode which, being closed, is no
longer a problem. But then, the same could be true for a measurement.
Maybe you are also arguing that a document could be attached to a not-
yet-existing Past History item, however I am not sure that the widget
supports converting what can (presently within the Attach documents
plugin) only be newly created as an Unassociated episode. BTW we seem
to have lost the ability to post-hoc make an episode into a Health
Issue?
I would agree that an unattributed episode that is inactive
(*closed*) is *no longer* a problem. An episode that is attributed
under a health issue, even when the episode is active, may or not be
a problem over and above (additional) to the health issue itself,
athough I suppose the health issue is the *state* of having the
issue, and the episode is a record (and state) of the issue having
causing at least one of potentially multiple problem(s). So, episodes
and *health issues* are not the same thing.