I propose adding a drug benefit flag to the Payer Plan Table, for details see Drug Benefit Indicator. Please register any comment: pro/con/improvements, so that we can gauge OHDSI community opinion for this change. Thanks.
Hi @DTorok! This is interesting. But what makes the Drug Benefit Indicator different than adding a record (row) to the Payer Plan Period table, specifically for drug coverage? So a patient can have two records in the payer_plan_period table: one for medical coverage and one record for rx coverage. This would allow patients to have different medical and rx coverage dates. This tends to happen with Medicare patients where their medical coverage can be covered under the government but their Part D (aka prescription coverage) is covered under a third party insurance company (aka Blue Cross). So coverage dates may not line up between medical and prescription coverage.
We currently use multiple payer_plan_period records for one patient for the following reasons:
- the patient has two or more insurance coverages (primary and secondary).
- the patient has two different types of insurance coverage (medical and prescription; or Part A and Part B - for Medicare patients).
@jenniferduryea, @DTorok, friends:
The problem with this flag is the following: It it is not set, what does that mean? We have no drug benefit in the observation period? So, if there is no drug record, it is not becasue the patient never set foot into a pharmacy, but because there was no payer to record it?
That would render the observation period completely useless. It should tell us that during an active period absence of data means no drugs were prescribed. If we have this flag, we would have to join the PAYER_PLAN_PERIOD each time we use the observation period. 100% of all existing drug analytics tools and methods would cease to work.
Don’t go there.
During an observation period data are collected. All of it.
Adding a record row to represent an overlapping benefit is the right approach. Is this an efficient approach from computation point of view, I dont know; but it is the right approach to semantically represent real-life.
From documentation - “allows identifying the unique combination of Payer (insurer), Plan (determining healthcare benefits and limits) and Person”
@Christian_Reich - absence of utilization does not always mean absence of benefit. Knowing who has benefit is extremely important for a payer to compute ‘exposure’ or denominator as member months. The numerator is the realized expense such as total cost, count of healthcare services etc. So if health-economic analysis needs to be done - payer-plan-period is important
My wish is for a standardized representation of Payer (insurer) and Plan (determining healthcare benefits and limits). Payers (atleast the major payers) - may be reprsented in standardized way using ‘Electronic Payer IDs’. I dont know of any standardized way to represent plan benefits.
1 Like
@Gowtham_Rao, thanks for the confirmation. And, I love the idea of payer_ids representing payers. I believe we talked about this a year ago (the original poster being @aguynamedryan here) and I still stand by the recommendation. We now have to create concept_ids for payers using the payer ids. We may have to add a field to the payer_plan_period table.
First to Christian’s point (someone has to show me syntax to the the @Christian_Reich link) . I agree that all data could and should be collected, that would not change as a result of the Rx flag. But if a person did not have drug benefits, it might help to explain why they do not have any drug exposures even though you might have expected them to. You might want to exclude someone from a study if they do not have drug benefits, because it is unlikely that you are capturing their drug history. I don’t see how adding this extra bit of information will hinder any existing analytics other than adding a feature to a cohort tool to allow filtering patients that do or don’t have a drug benefit within a study period.
As for @jenniferduryea, I think having multiple and possibly overlapping payer plan records may be a better approach than what I proposed. You have already provided a ‘use case’ from the modeling perspective, although, I think an analytic use case carries more weight. My problem with that solution is that it requires special knowledge to know what plan_source_value represents a plan that includes prescription coverage as opposed to one that doesn’t. ‘Part D’ might be obvious, but commercial insurance plans with or without coverage would not be. Seems like with your solution, it would be helpful to have a ‘plan_type_concept_id’. But that gets into the need for types such as ‘commercial w/drug’, commercial wo/drug’, ‘primary w/drug’ …
Friends:
That is my point, not yours. 
Which is why I don’t want this flag, because I need to check whether absence of data means absense of exposure or lack of benefit. The OMOP CDM assumes benefit as a default for an existing OBSERVATION_PERIOD, and you don’t want to have to test each time.
Can you open a request in the WG? If it is not in that list, it won’t happen. Also: Where are these payer IDs? And do we have them in all the data?
Guys: The CDM is not a sandbox for a bunch of analysts who go on an fishing expedition to bump into interesting facts. It’s for standardized tools and methods. Today, all incidence and prevalence calculators (like in ATLAS) assume that patients have benefit so they can be used for the denominator if they have an OBERSERVATION_PERIOD record. All Study Workbenches (like ATLAS) assume that during an OBSERVATION_PERIOD you can look for exposure or outcome. With your flag or @jenniferduryea’s extra records, you have to join each time you use that table to see whether the OBSERVATION_PERIOD is the real thing.
Bottom line: Everything we have today will break. You guys need to come up with a better idea of how to handle it so it is backwards compatible.
The relationship between OBSERVATION_PERIOD and PAYER_PLAN_PERIOD are not very clear – the way i see it, PAYER_PLAN_PERIOD is a detail (i.e. subset components of) of OBSERVATION_PERIOD. So PAYER_PLAN_PERIOD cannot be outside OBSERVATION _PERIOD. If this assumption is true - then the tools should not break.
Right now, they are not connected at all. But even if they were: The OBSERVATION_PERIOD should give you freedom to operate. You shouldn’t have to double-check whether or not it is active for all domains, Drug, Condition or Procedure. Also, this whole enrolment business is relevant for payer-based data (claims), only. In an EMR-derived database, even if it has payer information, whether or not a patient has coverage it is irrelevant for the administration of healthcare services, and therefore a Don flag as proposed makes no sense.
But: We really would like to have a better handle on payer information, driven by your use cases. The current PAYER_PLAN_PERIOD solution was designed in the absence of such use cases. So, go wild with it.
To @Christian_Reich, your statement:
“The OMOP CDM assumes benefit as a default for an existing OBSERVATION_PERIOD”
Implies that during any period that a person does not have Rx benefits, their medical events should be excluded from the CDM. That is, the Observation period should not include the time span where a person was without Rx benefits. Is that correct?
Hello all, I’m new to the forums. Excited to see this discussion.
The presence of a standardized vocabulary for field period_type_concept_id in table OBSERVATION_PERIOD already acknowledges that persons will have varying levels of probability to have services or care sites recorded in the OMOP instance. The available values for period_type_concept_id could be further developed to provide more granular detail on any systematic variations in ability to observe/record services (e.g., full insurance benefits vs. medical only). Given that the standards allow start and end dates for OBSERVATION_PERIOD records to be inferred by algorithm, the source data informing that algorithm can exist outside of the OMOP CDM instance, regardless of how well it fits in the PAYER_PLAN_PERIOD table.
Systematic variation in access to service records is not just an issue for insurance claims. EHR system upgrades to include e-prescribing confirmation could change likelihood of capturing DRUG_EXPOSURE records. Interoperability projects at an integrated delivery network could change one EHR database’s ability to capture records from other care sites. MHRA or NHS could expand data capture activities that would affect which patients have linked CPRD-HES data over time. I would hope that, as a best practice, implementers with specific knowledge of such changes would create different OBSERVATION_PERIOD records for patients each time IT or delivery system changes alter the quality of what can be observed. Expanding the range of concepts recorded in period_type_concept_id would improve interpretation of event rates observed in OMOP cohorts.
The idea of expanding the use of period_type_concept_id is interesting!
However, it may simply shift the problem from the proposed column to the of problem of checking the correct type in OBSERVATION_PERIOD.
For example, people create a one day observation period just to cover the date of death of the patient. (data from some death source that per data quality check are now outside official observation period). To me, this seems like “cheating” and “covering up a data quality problem”.
Correct, @DTorok. You either have all the database can give, or nothing. If a database only has Drug (like IMS’s LRx), then of course you are not throwing out everything with the bathwater because you have no Medical. But for Claims only the complete patient is useful.
@schabert: You are totally right. We don’t have databases that truly project the entire patient. However, what I am fighting against is the inflation of all sorts of little flags here and there. The camera is either on (with all flaws the database might have) or off.
@Vojtech_Huser: Use case??
Use cases
The Effect of Prescription Drug Insurance on Utilization and Health among the Elderly
the authors examine hospital admissions, in order to test whether having drug coverage allows beneficiaries to better manage their health problems and avoid costly hospitalizations.
… explore the effects of drug coverage on health, using both self-reported health status and the ability to perform activities of daily living as measures of health outcomes. They find little evidence that prescription drug coverage is associated with an improvement in these measures of health, although they note that it would also be useful to look at disease-specific outcomes, such as reduction in blood pressure for hypertensive patients.
All,
We have a data source that has a flag which indicates which type of benefit the Payer is tied to - Rx, Medical, Hospital, etc. How do we capture that benefit type? Our business and analytics teams uses this flag to determine if a patient qualifies for a study. For example, continuous enrollment with both Rx and Medical benefits. When we converted it over in 4.0, we couldn’t find a spot for it, so the team who did the conversion added extra fields to capture this information. Now we are upgrading it to 5.0 and I want to make sure we are storing it properly.
We haven’t. Today, OBSERVATION_PERIOD means no restrictions to data. See the rationale above. However, this is a subject that comes up, so I am going to see whether we can have a subgroup formed thinking of how to solve it without breaking the current CDM.
@Christian_Reich Please let me know when this subgroup is going to be formed. This is something we keep getting asked and would like to be able to resolve.
Friends:
Using this Post to finish this problem, which is waiting resolution in CDM Proposal #120 “Payer_plan_period - new fields to allow standardized health economic analysis #120”:
We are planning to add to the Vocabulary: https://docs.google.com/spreadsheets/d/1CA2QUFXeT_nrbMyyqHkeOWx-RpDSTsbGxd6DXZmzXJM/edit#gid=292519905. Note that the last three are flavors of zero, so no standard concept.
Please check it out and let us know if you disagree with the proposed. It’s a very US-centric list, in future, we’ll need to incorporate international ways to call these things.
For dental data and dental domain, please add dental-only plan bought via health exchange (not via employer)
Same for vision plan only.
So the insurance space has several lanes - medical, dental and vision and we shoudl target and cover all of those lanes.