Contract_owner in payer_plan_period table

[gowthamrao]

Request to add the following fields to the OMOP Common Data Model's payer-plan-period

Use case:
In US (and many other countries) health insurance products are sold to families, where one person is the primary subscriber (or contract owner) and rest of the family members are dependent of the contract owner. E.g. in a two parent two child family, if one parent has an employer sponsored insurance, and other spouse does not, then the spouse and the two children are dependents of the primary subscriber/contract owner. This information is important for health economic calculations such as out of pocket spend for a family.

Request

1. Add two new fields - contract_person_id: this is the person_id of the person that is the primary subscriber/contract owner in the family. This is a new optional field. contract_person_source_value: this is the person_source_value of the person who is the primary subscriber/contract owner in the family. This is a new optional field.
2. Add two new fields - contract_source_value and contract_concept_id - that justifies the contract relationship.
3. Relationship from the person_id to contract_person_id. We will use SNOMED vocabulary of the Relationship Domain and Social Context concept class id (see here). Relationship will point from person_id to contract_person_id (i.e. child to parent) . i.e. person_id 1 is the spouse (4132413) of contract_person_id 100 or person_id 2 is the child (4285883) of the contract_person_id 100
4. remove existing field: family_source_value. The word family is ambiguous. Use contract_person_source_value instead

Please note - contract_concept_id is to be used to related person's on contractual basis only for health economic analysis. Biological relationship between person's should be managed using Fact-relationship table.

Field	Required	Type	Description
payer_plan_period_id	Yes	integer	A identifier for each unique combination of payer, plan, family code and time span.
--------	--------	--------	--------
contract_person_source_value	No	varchar(50)	The source value for the person who holds the contract for the benefit of the person_id in the record.
contract_person_id	No	integer	A foreign key identifier to the person_id in person table, for the person who is the primary subscriber/contract owner for the record in the payer_plan_period table. Maybe the same person or different person, depending on who is the primary subscriber/contract owner.
contract_source_value	No	varchar(50)	The source code representing the reason justifying the contract. Usually it is family relationship like a spouse, domestic partner, child etc.
contract_concept_id	No	integer	A standardized concept_id representing the reason justifying the contract between person_id and contract_person_id.
family_source_value	No	varchar(50)	The source code for the Person's family as it appears in the source data.

[don-torok]

1. Can you use a name other than relationship concept id since there is already a column with the same name in the vocabulary relationship table.

2. It will make it easier for those that have to populated these table if whenever a concept_id is required some guidance is provided such as the allowable domain.

3. The family source value was suppose to provide some information about the relationship between family members. Do the proposed changes make this attribute obsolete? If not, how does the family source value work with added fields.

[gowthamrao]

@don-torok agree with 1 & 2 - how about sub_relationship_concept_id and sub_relationship_source_value -- too long? What is the max character size?

family_source_value there is two way of looking at it. Is it the source-id of the primary subscriber or is the source-id of the family? If the source-data does not identify a family based on the id of the primary subscriber, then this is not a redundant information, but if it does - then yes, it becomes redundant information. Now, redundancy is not uncommon in OMOP CDM - e.g. we have person_id and person_source_value. Also, people in the same family may belong to different payers (e.g. husband and wife have different health insurance coverage from different carriers because of different place of work) - so a family-indicator does not necessarily mean same health-insurance card.

[cgreich]

@gowthamrao:

Hang on a sec. Hold the horses. The PAYER_PLAN_PERIOD is for determining the insurance plan for each person. The biological relationship between different persons is recorded in the FACT_RELATIONSHIP table. That fact that you can infer the latter from the former through the insurance numbers is a US-only artifact, and it doesn't belong into that table. Not sure why we would piggyback that on if we already have a way for the latter.

[gowthamrao]

@cgreich sure, but fact_relationship table only represents 'fixed' relationships, not time-varying relationship. i.e. fact_relationship table does not have a start_date and a end_date. So if the dependent is getting a benefit because of time-varying legal relationship (< 26 year old child, spouse not yet divorced etc) then if we want to know the relationship that justified the dependency benefit - this becomes an essential field. These are standard constructs in health-insurance, the source data being ETL'd will have this relationship as the justification for the dependency - very valuable, lot of use cases.

[gowthamrao]

@don-torok @cgreich @clairblacketer please see first post. It has been updated and cleaned up based on feedback.

[clairblacketer]

This looks great @gowthamrao ! Let's talk about it at the July meeting.

[vojtechhuser]

Just to note that I can have a dependent (adopted son) on my insurance and it would not be recorded in the biological relationship.

The biological relationship between different persons

[gowthamrao]

@vojtechhuser sounds like the following snomed concepts (proposed above), helps with that use case

http://athena.ohdsi.org/search-terms/terms?vocabulary=SNOMED&domain=Relationship&conceptClass=Social+Context&page=1&pageSize=15&query=

[gowthamrao]

@vojtechhuser sounds like the following snomed concepts (proposed above), helps with that use case

http://athena.ohdsi.org/search-terms/terms?vocabulary=SNOMED&domain=Relationship&conceptClass=Social+Context&page=1&pageSize=15&query=

[clairblacketer]

added in v6.0