The Family History feature allows the user to record or update the patient's family history SNOMED-CT problems. The Family History Changed Subscription feature will allow the user to retrieve changes to the family history data (not including any deleted information). For more information about subscriptions, please refer Changed Data Subscriptions.

FAMILY
The beta practice setting 'Family History Reconciliation Update' must be turned on.  

Make sure you support multiple relations of the same type having the same issue (two brothers both having high blood pressure), and a single person having an issue more than once (the mother having two instances of cancer). The family history section is structured differently than other sections. Other sections have question fields that contain a list of single question/answer pairs with some metadata. For the family history section, each of those question/answer entries is itself an array of data, one sub-entry per relation or per occurence. The relations do not specify biological vs logical (step/adoptive/etc.) relations. Biological relations are assumed. In general, practices only track relations that have problems, although they can be configured to have an Alive and Well status. 

• 'snomedfamilyhistoryproblemid' ties it to the practice-specific family history element and can be used to tie the same question across multiple forms. 
• 'snomedcode' is the SNOMED code value for this particular problem. 
• 'text' is the patient-friendly name of the problem. 
• 'origtext' is the SNOMED term for this problem, which almost always matches text. We recommend you use text and not origtext. 
• 'fields' contains a list of problem instances, each of which contains: 
• 'default' is the Y/N checkbox that indicates whether this person has this problem. 
• 'relation' is the relation this person has with the patient (mother, sister, etc.). 
• 'relationkeyid' is the ID of the particular relation. Each relation type has its own keyspace. This means you can have a Brother 1, Brother 2, Sister 1, etc. 
• 'onsetage' is the age when the problem started. 
• 'diedofage' is the age when the relation died from this particular problem. 

'relationkeyid' is a REQUIRED field. 
If you add a new relation, specify the next available numerical value for relationkeyid. It’s possible to receive a missing/null relationkeyid. This is always from the portal. Until that is fixed, assign the next available relationkeyid to that empty value. We do not cross check between entries. This  means a particular relative could be specified to have died at two different ages from two different problems. We match on problem/relation/relationkeyid/onsetage. This means that a given person (e.g., Brother 2) can have two instances of the same problem (e.g., two instances of cancer).