Family history is now directly supported.

This page needs work, particularly with respect to the push only paradigm with respect to privacy concerns.

Family History

The handling of family history in version 0.3 of GNUmed is described in an archive message dated ~ August 23 2008 from James Busser with subject line Re: fields in health issues here

An earlier archive message from 2006 here provides some idea how Family History may be handled once we are able.

The archival message is, by the way, outdated on the question of allergy support... we use a double approach: explicitly model known-ness of allergic state as well as storing actual allergy data. There is a trigger syncing the two tables with each other.

The technical notes below had no better place. Suggestions accepted.

'> It seems to be a single table.
Yes, so far. We may want to add a link to a relationship_type table but that does not change the general concept. The current, enhanced layout was posted to the list by Karsten as "Family History Table" Thu, 17 Mar 2005 18:06:51 +0100

'> I do not some sort of ?external key (fk_relative??)
Yes, fk_relative can point to another identity in the database. It's either fk_relative OR relative_name and relative_dob but not both.

'> One of the major bugbears of my system is the inability to import family
'> history data from within the database from related persons, although when I
'> set the tables up which I've shown you before (and enclose below), they were
'> normalised to do so, I never got it finished.
'> This has caused endless unnecessary repeative copying from one instance of my
'> program to another - instead of being able to have an import wizard come up
'> with all related family members and let you click on a checkbox to include a
'> particular history problem in the persons notes you are working on.
Ah, that is how I know Richard talking design smile

'> Have you included this ability in your table design?
I should think so. For one thing we have the ability to store links to relatives (independant of family history). Also, we can directly point to a relative from fHx.

There are two conceputally conflicting design goals (that I am aware of).

1) family history item integrated into a patient's EMR - searching a patient's EMR for family history narrative is easy - a condition of my grandparents can be of significance to my health but not to that of my sister (gender-wise) - may require repeated input of the same condition when linking to different patients unless intelligently supported by the frontend

2) "generic" family history item outside any patient's EMR - can be linked to from several EMRs since my grandma may suffer a hereditary disease no matter whether that's linked to me or my sister as a family history item - requires non-neglectable hoops to jump through to allow for appearance in searches over the EMR narrative

Now, what are the suggestions here ? I am feeling like favouring 1) at the moment.
Topic revision: 25 Jun 2011, KarstenHilbert
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark