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