Design Review Schedule Relationships Redesign Notes
March 10th 2010
Currently relationships are gender neutral. We use parent/child instead of (mother/son, mother/daughter, father/son, father/daughter)
Currently we just have the two strings: a_is_to_b/b_is_to_a
So for some relationships its awkward because words are gender specific: aunt or uncle/neice or nephew is one example
Other languages have modifiers other than just male/female
Proposed solution: allow for setting the female and male name for each relationship
How to manage this with our db columns
Perhaps serialize an object to a_is_to_b
Make the a_is_to_b and b_is_to_a longer to support a serialized xml object
The first part of a_is_to_b is readable, the second part is xml serialized (parent^<xml>...</xml>)
Burke wants the serialized bit to be somewhat readable (like an hl7 type of storage) (parent^father^mother^etc^etc)
Jeremy suggests using messages.propertis type of key/value storage aka (parent|m=father|f=mother)
How to manage this in the UI
How to put this into hl7
(not related to gender) We need to specify in hl7 both sides of the relationship type
Using alternative section: 5^PersonName^99REL^B^Parent^99RELDIR
Using type+position in main: 5B^PersonName^99REL
For hl7 messages from external systems, the relationships will need to be translated to the right type before processing
For hl7 messages from external systems, we could add an h=CHLD for hl7 key code for that relationship type