OHDSI Home | Forums | Wiki | Github

Patient-Reported Drugs and Conditions

CDM Builders
#17

Should these patient reported drugs or conditions be a part of eras?

I vaguely remember discussing this at the F2F, and we decided that if, as an ETL person, you feel confident that the patient reported events should be part of standard analytic queries, then do bring them into drug_exposure / condition_occurrence, and expect them to be part of drug or condition eras. But, if you have question marks around the validity of patient reported events, then bring them in as observations. Is this correct?

#18

But @SCYou isn’t this data coming from a device? Something is counting steps?

Ugggggggggggggggggggggggggg . . . . my vote would be no, patient reported drugs should not be part of eras cause they probably don’t contain information about how much drug was consumed or when exactly it was . . . but originally I wanted to shove all patient reported items in OBSERVATION. :smile:

@bailey - I remember once you told me that you see the value in patient reported drugs, would you argue that they should be in ERAs?

All,

Could we also consider Health Risk Assessment data as patient reported?

  • 44786633 – numeric HRA values
  • 44786634 – categorical HRA values
#19

@ericaVoss Patient Generated Health Data (PGHD) not only includes step counts (activity), calories intake (nutrition), but also include patient reported condition, measurement or drug.
Since first target population is diabetic patients, we’ll start with glucose level and insulin dosages. I think these data can be captured in measurement and drug_exposure table only when the time and the dosage or the result are specified.
Otherwise, I agree with @Ajit_Londhe 's opinion, which somewhat ambiguous data would be stored in observation table.

I’m developing ETL document for accessible PGHD now. I’ll release it soon. Then, we can discuss further!

Sorry, since we don’t have these data in our data network, I don’t know… I hope these data also to be integrated within OMOP-CDM.

#20

@bailey or @karthik or @Christian_Reich

You have been randomly selected to help decided . . . should patient reported data affect DRUG_ERAs? I’m assuming yes as some datasets this is the bulk of the data.

However data that falls outside of the OBSERVATION_PERIOD should not impact the DRUG_ERA regardless of where it is from. (see this thread)

Here is the current text, but would like to add something about ERAS.

RECOMMENDATION
Patient reported data recommendation should land in the appropriate domain table (e.g. if a patient reports they had lymphoma it should land in the CONDITION_OCCURRENCE table. These data should be strongly typed so that it easily known which records are patient reported. Type concepts include 44814721-Patient reported 44818706-Patient reported device 44818704-Patient reported value 45905770-Patient Self-Reported Condition 44787730-Patient Self-Reported Medication 44786633 – numeric HRA values 44786634 – categorical HRA values

NEXT STEPS
Ask the CDM WG to add this to the FAQ https://github.com/OHDSI/CommonDataModel/wiki/Frequently-Asked-Questions

#21

I think for condition_era, you’d include it into the observation_period, but it is tricky for drug_era. For drugs, unless the information from PGHD can give us an accurate duration, I don’t think it should be included. Obviously, there are exceptions and if we believe a dataset his reliable and granular enough, then it should be included in the observation table, but I don’t see that happening.

1 Like
#22

Thank you @cukarthik. @Christian_Reich help us finish up this ticket. What should we do in terms of eras for patient reported drugs/conditions.

#23

There was an earlier question from @Christian_Reich on whether we need any additional patient reported types. We just found that we have a need for a patient reported procedure. Can we get a concept added to the Procedure Type vocabulary?

#24

@sblyman Can’t you use 581412 Procedure Recorded from a Survey for now? The underlying meaning is the same: it’s used when a patient reports a history of procedure.

#25

Thanks for the suggestion @aostropolets. We’ll go ahead and use that concept for now. Longer term, it would be nice to have something more in line with what other domains provide for general patient reported events.

#26

Will add, @sblyman. Actually, we are supposed to overhaul all of them and potentially make them domain-independent. That’s a THEMIS job that’s still open. So, you will just have “Patent reported”, irrespective of what table it is in. Let’s see if this will work.

#27

Hi @ericaVoss - sorry to revive an old thread but I’m hoping to gain some clarification on this. The FAQ’s link in this thread appears to have been replaced by https://ohdsi.github.io/CommonDataModel/ but I don’t see a corresponding FAQ item for this there – doing some digging around I can see the conventions include some details on this (e.g. the DRUG_EXPOSURE user guide) but the associated ETL Conventions for DRUG_TYPE_CONCEPT_ID has a link to Athena that doesn’t include a query term.

I’m wondering - what’s the best resource for conventions and approaches for handling patient reported data that falls into domains like drugs and conditions?

Thanks in advance!
Will

#28

@wtroddy

Tagging @clairblacketer, she’ll have the OFFICIAL answer . . . . .

We’ve updated a lot of our documentation in the time since the post was written. However this specific point doesn’t seem to be in the conventions. Here is where I would expect to see it:
https://ohdsi.github.io/CommonDataModel/dataModelConventions.html#Data_Model_Conventions

Now that being said, I think this recommendation still holds true - with the exception that the TYPE concepts have also updated. Here is the list of valid types:
https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=

So I’ll update the original text:
RECOMMENDATION
Patient reported data recommendation should land in the appropriate domain table (e.g. if a patient reports they had lymphoma it should land in the CONDITION_OCCURRENCE table. These data should be strongly typed so that it easily known which records are patient reported. Use type 32865-"Patient Self-Report" to identify these records.

1 Like
#29

@wtroddy I agree with @ericaVoss’s assessment. Patient reported data should land in the proper domain as specified by the Standard Concept you assign it. For example, if a patient reports a history of hodgkin’s lymphoma, you could either assign concept 43021273 for “History of Hodgkin’s Lymphoma” or concept 35610328 for “B-cell Hodgkin Lymphoma”. Concept #1 would go to the OBSERVATION table while Concept #2 would go to the CONDITION table based on domain. In both cases I would do as Erica suggests and assign a type concept representing the fact that it was patient reported.

Clair

1 Like
#30

All Of Us data do not follow this convention (btw). Their conditions reported by patients (in patient facing CRFs) DO NOT make it into condition_occurrence table. (at least that is our impression from researching this). @Craig_Mayer

#31

Good morning!
Let me ask a question that seems to be relevant to this discussion.

There is a source table (ST) that stores an information about patients diseaseses.
For every record from ST presented a pair of dates:

  1. first is just a year and a month which is a description for actual visit (date1)
  2. and the second is exact date (day, month, year) which is relevant to disease (date2)
    So, when date2 < date1, differencies can be months, can be years, but I understand it exactly as patient-reported condition during the visit.
    The question is - what is the best approach to handle this information?

I can see following options:

  1. Creating a record in cdm.condition_occurrence (most records have target_domain_id = ‘Condition’) where condition_start_date = date1, meaning that we take into account that patient reported that he had a condition for the date of the visit, and this date is unclear, because we have only year and a month.
  2. Creating a record in cdm.condition_occurrence where condition_start_date = date2, meaning that patient reported that he had a condition for the day of the date2.
  3. Creating a record in cdm.condition_occurrence where condition_start_date = date2 and condition_end_date = date1, meaning that patient reported that he had a condition from the day of the date2, and we presume that either a condition was confirmed by medical specialist, then we should see a new record in ST where date1 and date2 are from the same year and month, or the condtion was not confirmed and we can just keep it as patient-reported condition for some period of time from date2 to date1.
  4. Creating two records in cdm.condition_occurrence one with the condition_start_date = date2 (with type_concept_id like ‘patient self-reported’) and the other with condition_start_date = date1 (with the same or different type_concept_id), meaning that patients had a condition both on date1 and on date2.

Hope, I described it pretty clear, if not - please feel free to ask.
Thank you!

#32

It might be taken from previous medical notes as well.

It looks more like date1 is just a date of visit when this history fact was obtained.

And date2 is usually far before the start of the observation period, right?

Do you have any documentation that better explains what it’s in your source table, so we can know for sure?

#33

I wouldn’t put in a condition_end_date unless your data specifically states a condition has stopped. The condition_end_date is not mandatory and most conditions do not have a known end date for 2 reasons.

  1. Chronic conditions are usually life long events: high blood pressure, diabetes, asthma, etc.

  2. If the condition is not chronic (sprained wrist, influenza, etc.), the Person doesn’t visit the medical institution to declare their disease free state.

#34

@Dymshyts Thank you for the reply!
The descriptions are:
date1 - “Month of hospital visit with some kind of medical treatment or fees”
date2 - "Starting date of the following.

  • treatment for the specified disease
  • hospitalization for the specified disease"

The differencies between date2 and obs_p_start_date may vary from half-month to 10 years, but, as i can see, the most common are from 6 months to 2 years.

@MPhilofsky Thank you! I won’t populate condition_end_date then.

1 Like
#35

Right, neither of these stands for the end of the condition.
Based on your description of dates fields, it doesn’t look as a classical use case of a personal history.
Unlike history, a condition is present at the moment of date1 and date2.
So the date2 seems to be an a actual start of the disease. But what is date1? Some subsequent visit date?

Is the date2 6 month - 2 years before obs_p_start_date or after?

#36

I’d say that date1 is the date (to be precise it is year and month) when patient actually iteract with medical facility.

For the following I did a comparison of years and month for pairs: date1 and date2.
There are 3 cases:

  1. When date2 belongs to obs_p. It’s a bit tricky, because there is no difference between date1 and date2 only in 70%. Seems that 30% are just reports of conditions, but inside the obs_p.
  2. When date2 before obs_p_start_date. Here date1 and date2 are different in 100% and here we can see the most common difference between date 1 and date 2 as 6-24 months.
  3. When date2 after obs_p_end_date. The numbers are very low - less than 0,1% of all records. And in 99,99% cases the date1 are equal to the date2.
    So it seems that patient had a visit on date1, but some condition (from date2) was mentioned as relative to the current visit.
    Either patient had a condition and mentioned it, or it is some kind of medical history from some papers.

Forgot to mention that about 1/3 of all records are where date2 before obs_p_start_date.

Is the following make sense:
IF date1 = date2 and dates belong to obs_p THEN create single event for current visit
IF date1 = date2 and dates don’t belong to obs_p THEN make a single event without a visit and outside obs_p (or single history of?)
IF date1 != date2 THEN create a “history of” observation event for a current visit (and maybe store date2 as value_as_string)

t