Re: [Gnumed-devel] family history table

[Karsten Hilbert]

Richard,

> We constantly change data in a medical record system - FH included. I often 
> find the one of us may have put in a history, only to find out weeks, or 
> months down the track that the information was either wrong/misdaignosed.
> 
> Have you allowed in the design for the family history condition to be 
> modified 
> in a way that will re-appear in every other related family members notes? ie 
> not have the old information still come up in someone elses notes.
No I haven't (yet). That is what I was asking about in the
other mail.

The advantage of doing it "your" way is to be more normalized
and not keep around wrong data in anyone else's notes.

The disadvantage is to have to jump through some hoops when
searching the clinical record. Another problem is that one may
want to store FH for "Martha, aunt" for several people while
all the while it's a quite different Martha. Hence we might
still have several "Martha, ..." in the table while actually
they are all the same Martha. We could solve that by putting a
unique constraint on name_relative so that people would have
to write "Martha (of Duncan family branch)" to separate the
Marthas.

The advantage of "my" way of storing FH is that the
triple-Martha issue does not arise. The other advantage is
that FH is immediately available for searching the EMR.

The big disadvantage is that changes aren't propagated to
other people's EMRs.

I see value either way so let's explore that a bit more.

Here's an example for the searching concern:

Assume I hear there's a new treatment in town for Chorea
Huntington. Now I want to find all of my patients for whom I
have ever noticed down anything of relation to that condition.
I obviously also want to find those that have a *family
history* of CH ! If the family history condition is stored
directly keyed to the patient (eg my way) I can just search
the clinical narrative and find it. If it is stored out of
line (eg your solution) I will have to use a dedicated query
to take account of that fact. Sure, one will cry out "Now,
that's the beauty of SQL that you indeed *can* do that !"
However, we aren't going to know ahead of time *which* dedicated
queries the user will need down the road. One solution is to
offer a free-form SQL searcher to users (we do). Another is to
somehow integrate the information with the clinical narrative
of the patients.

What do people think about the following:

1) Normalize tables as Richard suggests.
2) When inserting/updating family history in his out-of-EMR
   table fire a trigger to insert/update a particular
   narrative item in the corresponding patients' EMRs to
   "relationship (name): condition"
3) Rejecting direct inserts/updates to that narrative so it
   cannot get out of sync.

Sounds like a plan to me. Suggestions ?

So much for "dumb backend" :-)

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346