Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Contract_owner in payer_plan_period table #107

Closed
gowthamrao opened this issue Aug 22, 2017 · 10 comments

Comments

Projects
5 participants
@gowthamrao
Copy link
Contributor

commented Aug 22, 2017

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

This comment has been minimized.

Copy link

commented Aug 22, 2017

  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

This comment has been minimized.

Copy link
Contributor Author

commented Aug 22, 2017

@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

This comment has been minimized.

Copy link
Contributor

commented Aug 23, 2017

@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

This comment has been minimized.

Copy link
Contributor Author

commented Aug 24, 2017

@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 gowthamrao changed the title Subscriber and dependent relationship in payer_plan_period table Contract_owner in payer_plan_period table May 31, 2018

@gowthamrao

This comment has been minimized.

Copy link
Contributor Author

commented May 31, 2018

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

@clairblacketer

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2018

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

@clairblacketer clairblacketer self-assigned this Jun 13, 2018

@vojtechhuser

This comment has been minimized.

Copy link
Collaborator

commented Jul 6, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Jul 6, 2018

1 similar comment
@gowthamrao

This comment has been minimized.

Copy link
Contributor Author

commented Jul 6, 2018

@gowthamrao gowthamrao closed this Jul 6, 2018

@gowthamrao gowthamrao reopened this Jul 6, 2018

@clairblacketer clairblacketer added this to In progress in CDM v6.0 Jul 16, 2018

@clairblacketer clairblacketer moved this from In progress to To do in CDM v6.0 Jul 16, 2018

@clairblacketer clairblacketer moved this from To do to on Dev in CDM v6.0 Jul 25, 2018

@clairblacketer clairblacketer moved this from on Dev branch/in development to Done in CDM v6.0 Sep 25, 2018

This was referenced Oct 11, 2018

@clairblacketer

This comment has been minimized.

Copy link
Contributor

commented Oct 25, 2018

added in v6.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.