[Gnumed-devel] Thoughts about social history

[richard terry]

Could we have a little debate about the following please. I think we need a 
dedicated gmSocialHistory.py (split from the combined social and family 
history)

 I'd appreciate replies from Horst, David, Tony, Malcolm, Karsten, Ian, and 
Liz (How's that for being demanding). The purpose of my question is around 
the gui presentation of some of the stuff below. I would assume storing this 
stuff is not an issue. As it can take many many hours of fiddling with the 
gui to get ideas, I don't want to waste these hours.

This will be a bit waffly, so bear with me.

There will be a number of situations using gnuMed where the user/recipient of 
information from the user will want snapshots of different parts of the 
patients social history, and these snapshots may often have country specific 
components

-E.g in Oz we need to be able to identify racial origen of  say aboriginals, 
Torres straight islanders, because they have different health problems/ 
immunization shedules etc

-In antenatal history (which may be say shared with a hospital, forwarded to a 
consultant, given to patient etc) we need (or the system demands) such 
diverse things such as religion, marital status, ethnicity, spouses name, 
type of work, spouses ethnicity, patients living conditions, social support,  
etc.

-any system needs to both display the current subset of social history but 
keep accessible/display past values of the same items.
-items must be sql searchable, e.g we will need to be able to find all the 
single mothers with one previous pregnancy with a large baby without social 
support etc. 


In terms of data entry we could have one of several options.
1) Dedicated text boxes and labels
  - unmaintainable? and not very elegant
2) Free text in a single mutli line text box which is intelligently parsed to 
extract the information. great in theory, I can imagine the chaos in 
practice.
3) Grid Display with the left hand column displaying the item (locked) and the 
right hand column allowing data entry.
 - this would be my preference, as it is easy to make this site/user/country 
configurable. I.e a query pulls in all the required items to request which 
are listed squentialy down the columns. This has the added advantage that one 
can pre-define mutliple choices where indicated because a control can be 
attatched to the grid square eg option box., drop down combo box.
4) Labels and  Text boxes generated on the fly from the above database schema
   - this could get a bit messy.

?any other paradigms?

Regards and Thanks for replying.

Richard