Observation Period Flavors (First THEMIS-Focus Group 2, now discussed everywhere)

[Christian_Reich]

Responses:

@astern

I’d just like to add that use case 3 below, where some databases include data from outside the “cut”, can be an issue with U.S. EHR as well as European data. Would the ‘Pre-qualified coverage’ (period type 4) category cover all patient history events or is the term specific to certain events in European datasets? Do we need different period types for different kinds of ‘history’ events? I’m not sure we need to answer that before posting to the forum, but want to at least pose the question for further feedback.

@corina_bennett

For the Period_type_concept_id’s #6 and #7, were these descriptions developed based on HES? I ask because I don’t feel they describe the CPRD UTS case. What do you think about a “Data quality standards met” option? This description would apply to data on or after the UTS date, and apply to any other database with a data integrity certification process.

@jenniferduryea

I am open to wordsmithing these period_type_concept_ids. The current proposal:

1. Medical coverage
2. Prescription coverage
3. Medical and prescription coverage
4. Pre-qualified coverage
5. Qualified coverage
6. In practice network
7. Includes out of practice data

I am open to changing #6 and #7 to what Corina suggests as #6 = data quality standards met. The idea seems similar to #3 and #4. Maybe we can just use #3 and #4 and create an all inclusive observation period for “all available data”. Then CPRD and EHR systems will use #4, #5, and #6, where #6 will be the over-arching observation period that will include all data. Please see updated list.

1. Medical coverage
2. Prescription coverage
3. Medical and prescription coverage
4. Pre-qualified coverage
5. Qualified coverage
6. All available data

And I like Aaron’s suggestion of adding more information to use case #3 to include US EHR datasets. Aaron, would you mind referencing that dataset in the wording for use case #3? In response to your questions, I believe we were looking at the use case of data that lives outside of the “data cut”. And we can just categorize that data as “pre-qualified coverage” data. I don’t think we need to do extra categorization on this type of data – especially when it’s questionable even to include this data in current ETL standards.

@Christian_Reich

I really hate to spoil the nice conversation, particular because the proposal very eloquently summarizes the problem. And I talked too much about this subject anyway. But the flagging business is not going to fly. Because it only serves a single use case: inclusion criteria of pre-existing conditions/drugs/procedures. But it would kill every cohort we built so far, which means thousands.

Also, I think you are mixing too issues:

•      Metadata about what aspect of healthcare a database (i.e. all patients in there) captures (e.g. in-practice network)
  

•      Metadata about what domains of a specific patient are captured at a certain time (whether the camera is on or not)
  

The former is important, but it is not patient-specific. The latter – 90% of all analytics require the Drug, Condition and Procedure Domains. That’s what should be captured during the observation period. All other partial coverages should go into a separate place (e.g. a new HISTORY table), where you can satisfy the pre-existing criteria need.

Please, please, please.

@jenniferduryea

Hi Christian,

Thank you for your comments. To clarify, I do not think we are mixing the two issues. I believe we are addressing when the “camera is on” in every use case presented. The problem is, the camera can be different for every analysis because the analysis requires a different camera.

I know that I mentioned a number of claims and EHR use cases in the proposal below, but I am most familiar with U.S. claims databases, so I’m going to focus on that in my response. For U.S. claims data, where patients can have two types of health coverage (medical and prescription), the analysis may only require a patient be covered under medical insurance because the drugs and/or clinical events studied are all covered under medical insurance. However, if the observation period is limited to when a patient has both medical and prescription drug coverage, you are going to miss all drugs/clinical events that may have happened when the user did not have prescription coverage. (for people who are not familiar with claims data, certain drugs are covered under a patient’s medical insurance, such as chemotherapy and other physician-administered drugs. So only requiring medical coverage may be sufficient for analysis).

I do sympathize that this change will not be backwards compatible to previously-completed cohorts and, per your forum comments Observation Period Flavors (First THEMIS-Focus Group 2, now discussed everywhere) - #3 by Christian_Reich, OHDSI tool performance may decline.

But, let us say we take the path that you mention in your forum post - one observation type per person and no additional flags in the Payer Plan Period table. Now, let us apply this to a U.S. claim database. If users want to do analyses that require all three observation period types (medical coverage only, prescription coverage only, medical and prescription coverage only), the users will be forced to have three versions of the same U.S. claims database - one for each coverage type. So researchers will now need to house three versions of a multiple terabyte Marketscan dataset to run all of their analyses. This is not an impossible solution (and quite a financial boom to data providers). Focus Group 2 did discuss this as an alternative. But, I believe everyone in our group decided that was not feasible nor practical to ask a researcher to do this. However, I am open to getting the OHDSI community’s feedback on housing multiple versions of a dataset.

As a group, we also discussed EHR use cases having different observation period types and it also seemed to solve the use cases as well. So this change will be applicable to all datasets that OHDSI strives to cover.

So there are two proposals I see:

1. Allow different observation period types (THEMIS Focus Group 2 sponsored)
2. Restrict datasets to one observation period type and create a different dataset with a different observation period type, if needed.

Please let me know if I misunderstood anything.

@Gowtham_Rao

I think you can easily solve this using the payer plan period table. First step would be to ETL into that table such that you have separate records for pharmacy benefits and medical benefits. Then you build the cohort in temporal relation to the qualifying event built in payer plan period.

I don’t see a problem…