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
{"serverDuration": 16, "requestCorrelationId": "ec386e1e34bb42fe8a6a5bdb1bf3bc2b"}