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