If the ‘family source value’ is a value that allows you to identify members of the same family, then it would be an attribute of the person. If the argument that a family membership can change in time, then take the same approach as for other person attributes such as location that may change with time, take the latest. I realize that coming from claims data, the ‘family source value’ may be defined at the plan level, but OMOP CDM is intended to abstract away those details and present the data in an analysis ready format.
I’m somewhat new to the OHDSI community, but I can speak from a plan-payer data perspective.
This source value is likely an internal family identifier such as an identifier for “subscriber” within the family. As such the “family” may change over time as the subscriber changes between spouses, or different dependents are covered over time as college students “age out” of their parents coverage for example.
Unfortunately, this is not always a static number within a single payer and will definitely change over time if you have different payer sources of data.
The family_source_value is a payer artifact and was added to capture the fact that several family members might be covered under the same plan, which may have an effect on outcome. And yes, those families cannot be taken as evidence for the true families, as there are all sorts of rules and personal decisions influencing who ends up in a family. And it is not guaranteed to be unique, so if you want to collect the family members you need to make sure it’s the same payer_source_value and plan_source_value.
Thank you both for explaining the peculiarities of family source value. Given that the family source value can apparently NOT be used to confidently identify members of the same family, and its specificity to a particular payer/plan and time period are there sufficient ‘use cases’ to justify its inclusion in the common data model?
Hi @DTorok, I use family_source_value in source-specific analyses. For
example, just this last week, I wrote an algorithm to infer mother-child
relationships in Truven MarketScan using the family_source_value field. I
have a few different databases that allow me to infer mother-child linkage
in different ways, but then I’m saving those linkages so that I can
continue forward with standardized analyses after I’ve done that
source-specific step. Hope that provides a useful motivation.
Is the Mother Child link plan specific? 
If not, back to my argument that family source value should NOT reside in the payer plan table. Truven is the example we use for the family relationship, but in Truven the family identifier is the initial part of the unique patient identifier. That means that the relationship is an attribute of the patient, NOT the plan, and that the relationship cannot change over time. I understand that conceptually 1) a family relationship may be defined by ones insurance plan, but I have not seen any data source that provides family relationship definition at the level of a plan; and 2) that family relationships may change over time i.e. a couple gets divorced and now they may have separated insurance plans, but this change in the relationship is not a function of their insurance plans, is not necessarily true that if a couple switched from a common insurance plan to individual plans it does not mean they are divorced. Just arguing that the family relationship is modeled incorrectly in the CDM.
Reviving this old thread . . .
In EHDEN I have a data partner that has some family information not associated to a payer. I mean I guess we can just use the PLAN_PAYER_PERIOD to track the family, but that feels weird. Has there been any discussion about best ways to store, otherwise I’ll just force it into the PLAN_PAYER_PERIOD for now.
Tagging @Rijnbeek , @clairblacketer
1 Like
That’s the only use case for FACT_RELATIONSHIP where I don’t cringe. Connect the mother and child and uncle and mother-in-law in the PERSON table.
So how would this work?
The RELATIONSHIP_CONCEPT_ID would be SNOMED / SOCIAL CONTEXT? LIke:
Uncle
https://athena.ohdsi.org/search-terms/terms/4244225
But how do you know which person is the uncle? Because wouldn’t DOMAIN_CONCEPT_ID_1 = PERSON and FACT_ID_1 = PERSON 1 and DOMAIN_CONCEPT_ID_2 = PERSON and FACT_ID_2 = PERSON 2. Which is the uncle?
Just below in the hierachy, there’s
Uncle of subject concept.
Looks nice at a first glance:
concept_id_1 (Uncle) - Uncle of subject - concept_id_2 (Niece)
Such relationships exist for the most of relatives (grandparents, siblings, children, parents, aunt).
The problem is that not all reverse relationships exist like a ‘Niece of a subject’, for example.
And if we even create them as new concepts, we end up with not a fully reversed ones.
Uncle of subject can have reverse ‘Niece of subject’ or ‘Nephew of subject’.
Thus we have to use not fully reversal relationships and you need to take the gender into account, or introduce some gender-neutral relationships.
The uncle is the guy who shows up to the family reunions, drinks a lot there and doesn’t vote for the same candidate at the general election than you do. 
Otherwise: As Dima said. We should probably consolidate these and make them gender-independent.
1 Like
I don’t see any problem from the modeling perspective:
In SNOMED (and in particular in OMOP) “Uncle of subject” means the same as what “Uncle” means. They just created it as an alternative to other siblings: “Maternal uncle” and “Paternal uncle”.
So it’s always “…of subject”, where the subject is fact_id_2.
Literally, we need to create:
fact_id_1 (Uncle) - Uncle - fact_id_2 (Niece)
with a symmetrical link:
fact_id_1 (Niece) - Niece - fact_id_2 (Uncle).
And right, you’re good if you know the genders.
If not, we still may want to add some general concepts, e.g. Nibling.
why does not “Uncle” means ‘Has Uncle’?
I always learn something new on the forum:)
Do we have a gender-neutral aunt or uncle?
1 Like
By default (if otherwise is not specified) the SNOMED concepts (and all others, I believe) describe the facts about the patient they’re recorded for.
Since fact_id_1 stands first, I’d assume relationship_concept_id describes fact_id_1 rather than fact_id_2.
So the statement from the specs
Person, 1, Person, 2, parent of
is just shortened to simple:
Person, 1, Person, 2, parent
what’s completely the same as:
Person, 1, Person, 2, parent of subject
While we don’t want to use:
Person, 2, Person, 1, has parent
I’m afraid no, and we can create a general one “aunt/uncle”.
That’s obscure.
Even SNOMED creates separate concepts like ‘Parent of’ or ‘Uncle of’.
It’s easier to create couple of additional concepts than to explain that ‘Uncle’ means ‘Uncle of’, and ‘Uncle of’ is not used because we decided that ‘Uncle’ is just enough.
‘Aunt/uncle of’
Let’s not mix up the things. These are not in the “Person” hierarchy that is supposed to be used for Relationships between persons. Those you’ve mentioned are really obscure, but they are in
the “Observable entity” hierarchy, so just ignore them.
But when you look up the “Person” hierarchy, you can see that
Uncle of subject (person) is a Uncle (person)
So,
I’m pretty sure they will be cleaned up due to duplication. We can ask SNOMED.
Are you sure? 
Sorry, I meant we use ‘Uncle of subject’ concept. Not that ‘Uncle of’ from the the “Observable entity” hierarchy indeed.
Payer plan period is intend to capture administrative relationship over potentially overlapping spans of dates. It is not intended to represent real han relationship between person’s e.g. biological relationship. Please don’t use payer plan period to capture non administrative relationships.
The two types of relationships MAYBE related - as in most cases biological relationship confers privileges to create administrative relationships e.g. a person has the privilege to add their spouse on the plan, but that privilege maybe administratively disqualified e.g. if the spouse is independently eligible for another health plan. The rules are complex, variable, custom and inconsistent. That’s why I did not think we could even assign a OMOP source concept id for such variation, and thought the best way is to capture it as source value