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

Payer_plan_period - new fields to allow standardized health economic analysis #120

Closed
gowthamrao opened this issue Sep 23, 2017 · 5 comments

Comments

Projects
3 participants
@gowthamrao
Copy link
Contributor

commented Sep 23, 2017

Use case:

  • Allows for standardized health economic analysis about contractual relationship between a person and their health care experience
  • Using the constructs of payer, plan and sponsor allows the use of standard OHDSI tools like Atlas and R-packages for cohort-build and cohort charcterization.
  • Addresses a key concern among OHDSI community around limited representation from health-plan, health-economics and actuarial science.
  • Address forum discussions: here and here

Proposal overview

Introduces, clarifies and standardizes the representation of four new constructs using _source_concept_id, _type_concept_id and _concept_id
sponsor: who finances the transaction
payer: who administers the transaction
plan: the actual contract being administered by the payer and agreed by the sponsor
stop reason: reason for termination of the contract

Changes are only additions of fields. Additions are in bold
Backward compatibility = Yes

Proposed 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.
person_id Yes integer A foreign key identifier to the Person covered by the payer. The demographic details of that Person are stored in the PERSON table.
payer_plan_period_start_date Yes date The start date of the payer plan period.
payer_plan_period_end_date Yes date The end date of the payer plan period.
payer_concept_id No integer A foreign key that refers to a Standard Payer concept identifiers in the Standardized Vocabularies
payer_source_value No varchar(50) The source code for the payer as it appears in the source data.
payer_source_concept_id No integer A foreign key to a payer concept that refers to the code used in the source.
plan_concept_id No integer A foreign key that refers to a Standard plan that represents the health benefit plan in the Standardized Vocabularies
plan_source_value No varchar(50) The source code for the Person's health benefit plan as it appears in the source data.
plan_source_concept_id No integer A foreign key to a plan concept that refers to the code used in the source.
sponsor_concept_id No integer A foreign key that refers to a Standard plan that represents the sponsor in the Standardized Vocabularies
sponsor_source_value No varchar(50) The source code for the Person's sponsor of the health plan as it appears in the source data.
sponsor_source_concept_id No integer A foreign key to a sponsor concept that refers to the code used in the source.
family_source_value No varchar(50) The source code for the Person's family as it appears in the source data.
stop_reason_concept_id No integer A foreign key that refers to a Standard termination reason that represents the reason for the termination in the Standardized Vocabularies.
stop_reason_source_value No varchar(50) The reason for stop-coverage of the record.
stop_reason_source_concept_id No integer A foreign key to a stop-coverage concept that refers to the code used in the source.

Proposed vocabulary

To help with standardized analysis, we will need to introduce into the OMOP CDM vocabulary, new concepts. Only omop standard concepts may be used in plan_concept_id, payer_concept_id, sponsor_concept_id and stop_reason_concept_id.

plan_concept_id

plan_source_concept_id

  • depends on the vocabulary used by source data, not designed/useful for standardized analysis

sponsor_concept_id

  • self-insured

  • fully-insured

  • individual

  • small group

  • large group

sponsor_source_concept_id

  • depends on the vocabulary used by source data, not designed/useful for standardized analysis

payer_concept_id

http://www.phdsc.org/standards/pdfs/SourceofPaymentTypologyVersion7FINALJune27_2016.pdf
Reference: payer types

payer_source_concept_id

stop_reason_concept_id

  • Termination of the employee's employment for any reason other than gross misconduct;
  • Reduction in the number of hours of employment.
  • Termination of the covered employee's employment for any reason other than gross misconduct;
  • Reduction in the hours worked by the covered employee;
  • Covered employee becomes entitled to Medicare;
  • Divorce or legal separation of the spouse from the covered employee; or
  • Death of the covered employee.
    Reference: group coverage termination vocabulary
  • Termination of all group health plans by sponsor
  • Failure to pay premiums
  • Coverage under another plan
  • Loss of Social Security disability status
  • Entitlement to Medicare
    Reference: opm
  • termed by person
  • termed by subscriber
  • termed by payer
  • termed by sponsor

Related proposal

The proposal is related to but not dependent on #107 .

@clairblacketer clairblacketer added this to the CDM vTBD milestone Oct 11, 2017

gowthamrao added a commit to gowthamrao/CommonDataModel that referenced this issue Nov 6, 2017

clairblacketer added a commit that referenced this issue Nov 9, 2017

Addresses #64, #70, #79, #92, #120, #132, #131 in code, documentation…
… is still being updated to reflect these changes.

@gowthamrao gowthamrao closed this Dec 29, 2017

@clairblacketer clairblacketer added this to In progress in CDM v5.3 Bugfixes Jan 9, 2018

@clairblacketer clairblacketer moved this from In progress to Done in CDM v5.3 Bugfixes Feb 7, 2018

@cgreich

This comment has been minimized.

Copy link
Contributor

commented Apr 19, 2018

@gowthamrao:

This is a good start. But I think we need to bring it to the Forum to do a couple things:

  1. Generally get folks' feedback, including use cases
  2. Ask the international folks what they think, and how we can create a nomenclature that is generally applicable. "Platinum" as a concept is not very interoperable.

Thoughts?

@clairblacketer

This comment has been minimized.

Copy link
Contributor

commented Jun 13, 2018

@gowthamrao have these concepts been added to the vocabulary?

@gowthamrao

This comment has been minimized.

Copy link
Contributor Author

commented Jun 13, 2018

I don't think so. @cgreich wanted to bring this up for more community feedback

@clairblacketer

This comment has been minimized.

Copy link
Contributor

commented Jun 13, 2018

We should bring it back up, there are THEMIS questions coming up about them

@clairblacketer clairblacketer modified the milestones: CDM vTBD, CDM v6.0 Jul 16, 2018

@clairblacketer clairblacketer added this to To do in CDM v6.0 via automation 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

@clairblacketer clairblacketer referenced this issue Oct 11, 2018

Merged

Cdm v6 #218

@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.