gnumed-devel
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]