[Top][All Lists]

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

[Gnumed-devel] need-to-know change to backend

From: Karsten Hilbert
Subject: [Gnumed-devel] need-to-know change to backend
Date: Fri, 17 Sep 2004 23:46:37 +0200
User-agent: Mutt/

Hi all,

in the recent weeks I have read many papers on medical records
implementation and structuring of data, including the Belgian
model posted here a while back. Quite funnily we invented
pretty much exactly the same concept, eg. we are
consistent. Also I have discussed our concept with Marc
Verbeke, one of the driving professors for the Belgian model.
Also, recently I had the opportunity to compare our model with
a (commercial research) implementation. I can happily report
we are in good shape and conceptually on top.

On thing I learned in discussion with Marc Verbeke was that
our (my) current idea of where the problem list is to be
located conceptually or IOW what a clin_health_issue is in
GnuMed needs a bit of review. I eventually decided to slightly
relax the association between episode and health issue:

- a health issue is a "significant" "problem"

- a health issue must not necessarily have an episode
  - this allows us to enter "proven" diagnoses from the past
    history as "problems" or IOW as health issues

- an episode must not necessarily be linked to a health issue
  - when the link is NULL this means it isn't decided yet
    whether that episode of, say, cough is related to any
    problem (health issue)

Hence we don't need the "default health issue" anymore.
However, we need a fk_patient field in clin_episode now.
Fortunately, PostgreSQL's power allows us to still not suffer
redundancy and thus possible sync errors. The updated view
v_pat_episodes now either pulls the patient from the
associated health issue (in which case clin_episode has no
patient) or from it's own patient field (in which case there
is no associated health issue).

I am sure this feels more natural to most of us. We did have
the question of where to put our problem list come up before.
Eventually we have an answer! :-)

When encountering a new problem it should be stored as a new
episode - unless immediately recognized as belonging to an
existing health issue. Later on, when an episode is recognized
to be a problem that will cause several episodes it might get
promoted to become a clin_health_issue.

The "problem list" is a view over issues and episodes
selectable by is_active and is_significant.

Commentary please !

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]