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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
