[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Past History and Operations (was: please, we need fee

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Past History and Operations (was: please, we need feedback)
Date: Sat, 16 Apr 2005 19:24:31 +0200
User-agent: Mutt/

Well, the thing is I wasn't wondering about how or what
to present to the user under such and such circumstances.

I was wondering about data storage in the backend. Judging from
what I heard this seems agreeable:

1) Offer a place to store "major" previous problems.

    eg. "clin_health_issue" rows

    - they may be active or inactive
        - flag in clin_health_issue
    - they may be significant or not significant
        - flag in clin_health_issue
    - "not significant" comes in two flavours:
        - either marked "not significant" but still in clin_health_issue
          due to it *having been* significant
        - not even deemed significant enough to warrant a
          clin_health_issue entry, those would become
          standalone episodes of bouts of minor afflictions

3) Offer a place to store current problems.

    eg. "clin_episode" rows

    - unless already known to become a clin_health_issue
      this stores currently ongoing/to-be-dealt-with problems

2) Several *views* over "problems" is necessary.

    1) "Problem list"

        - previous significant (active+inactive) problems
        - open clin_episode rows (eg current problems)

    2) "Past Medical History list"

        - here we go ...
        - previous significant (active + inactive) problems
        - *but not* "current problems" from clin_episode

Is that an agreeable definition of Past Medical History ?

If so we would have the answer to my initial question. And in
turn we would know what a "Past Medical History" widget
produces as output data: Namely clin_health_issue instances.
>From here the next question arises: Is it mandatory to have
dedicated "laterality" and "is_operation" fields in
clin_health_issue ? I fail to see the real value. I don't
expect lot's of queries like "show me all the patients that
had a broken *left* elbow" (as opposed to right elbow). But
maybe I am wrong there. For informational purposes I would
personally name the clin_health_issue something like
"s/p appendektomy (Crohn" or "left distal radioulnar fracture".

> and as I cannot get gnumed running at all because of 
> segfaults, empty log files generated during attempts to trace this, I've just 
> about given gnumed up.
Well, we've tried to give you suggestions, feedback, and
offered the main reasons for segfaults (which are pretty much
beyond our control). We haven't received feedback though.

Also, regarding client look I am not at all averse to you
developing a much better design. All the while you (and
everyone who wants to help) works on that I will certainly try
to see to it that we release "something that does something"
while at the same time taking care that the backend is not
tailored to that "something" but rather allows for much more
sophisticated designs usch as yours.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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