OHDSI Home | Forums | Wiki | Github

Prescribed and Dispensed Drugs in the DRUG_EXPOSURE table

Implementers
#21

Let’s learn from other CDMs. Why PCORnet has two tables? (dispensation and prescription). Because EHR sites have a use case for it.

So OMOP CDM has to decide if it is just like the others or claims to “know better” and wants to be better/different (and justify it very well).

Let’s say we don’t want death-by-too-many-tables. So if dispensation and prescription are similar, why not have just one table (drug_exposure) and have the type column serve as the “OMOP knows better” smart construct.

I argue we should embrace all records (even pill bottle sensor on the cap events (those are closest to patient experience)) and fully utilize the type concept. Let there be duplication! (two rows one for order and one for corresponding dispensation). (2 years ago, I posted this Kratos demo data idea to sandbox - see https://github.com/OHDSI/sandbox/tree/master/Kratos#days-of-supply-order-and-dispensation-1)

For analysis, it means that every drug table query must first declare the turf and stick to it. And one of the turfs can be only meds where I have order AND dispensation. (double events study)

So CDM table stays the same, type concept grows in significance and will require very specific and strong conventions and analytics will have to change to leave claims-heavy past and become claim+ehr futuristic.

So no change in CDM but change in analytics and conventions!

Once the specs are in place, I volunteer to write the first double events study. In fact I wanted for a long time do such a study but spec wise (and number of network studies in that turf)- our network did not mature there yet.

for the record: I disagree with Don. I agree with Malanie.

In fact, metadata should describe what turf a given dataset is using. (or Achilles and DQD and DataSources(atlas ) and prominently feature it to the research user of the dataset.

1 Like
#22

if convention about “duplicates” is accepted, then probably we will need to update SQL-scripts for drug_era and dose_era tables (at least add an option to exclude some records based on type_concept_id or an option to add type_concept_id to drug_era / dose_era tables and to build independent eras for each type?)

#23

@Alexandra_Orlova:

Logically true, but probably not useful. The reality is that 98% of the use cases don’t care about the Type. They assume Axiom 1: if there is a record then it happened. 2% want to go into the game of double-guessing (“do I trust EHR chief complaints?”) or the time difference between things (order and dispensing). Let’s make it easy for the 98%.

#24

I’d like to offer one use case pertaining to this question. We are doing a OneHealth antibiotic stewardship project on both the human and veterinary patients using OMOP on both sides. In this use case - on the veterinary side - we decided to only include those drugs in which there was confirmation the patient did ingest or started treatment. The ETL was written and supported by the native EHR system to include any drug (not just antibiotics) that was confirmed was “completed” - that is confirmed by the clinician the patient received the medication. The reasoning is the drug_exposure in this use case is the anchor or reference to run risk factor analysis of clinical events before the initiation of antibiotics. So our decision regarding what goes into drug_exposure is driven by need and in many ways simplify the interpretation of what is in the drug_exposure table. For clinical effectiveness type use cases - it doesn’t help (I don’t think) to know what was prescribed, but what was actually taken and what amounts. At least I can’t readily think of a use case that would be more helpful or wouldn’t muddle up the analysis by including prescribed and taken - even if it was managed through the type field. It would be another field I’d have to be aware of and interpret and communicate/coordinate with other collaborative sites.

#25

@mkwong:

I don’t get the problem. Nobody said to record or not record anything. If you have order data flag them with the right Type Concept. Same for dispensing. Same for administration. Let’s say you want to measure effectiveness of a drug, and let’s say the relative risk/benefit is 0.5 (the bad outcome is halved). And you have an adherence of 80%. Then your relative benefit will be watered down by the people who didn’t take the drug and therefore give that population a reduced effectiveness. By 20%. So, the effectiveness estimate will go from 0.5 to 0.6.

Where is the problem? Usually, your confidence interval is a lot larger than that slight difference. And these estimations jobs aren’t super precise to begin with.

Bottom line: I am not sure what problem we are solving.

#26

I’m not saying it is a problem, rather an ETL decision you have to make whether to include all types of drug exposures. I was illustrating a decision we made regarding what to put into the drug_exposure, basically all drug_type_concept_id = 38000180 “Inpatient administration” and for not bother with prescription transactions without confirmation of true exposure. Largely driven by out antibiotic stewardship needs at the moment.

If you want to use prescribing data and don’t mind as you say inherent quality limitations, then include all types. At this point in our deployment, we wanted to eliminate uncertainty. For someone else, that may not be the case and you do want to make use of the drug_type_concept_id to distinguish prescribed vs administered vs patient reported.

#27

Actually, I was saying you wouldn’t record something that you know didn’t happen (such as: you have a system were you record orders, and then the administration of the drug…and so you wouldn’t record the order if you know the administration happened later).

Christian, I’d humbly suggest you read all the messages again in this thread: we’re up to 27 messages, so based on that level of discussion, we definitely have a problem here.

#28

That’s not all:

  • CDM documention needs to be updated to not say captures records about the utilization of a Drug when ingested or otherwise introduced into the body. Now we’re saying that DRUG_EXPOSURE is both those things that are requested and things that actually happen to the patient.
  • ETL training needs to be updated to instruct implementers that DRUG_EXPOSURE records must be distinguished
  • Cohort definitions need to be updated to properly distinguish the exposures in the DRUG_EXPOSURE table as non-exposures.

And probably more that I haven’t thought of…

It would be simpler to just define a new domain of information related to ‘Treatments requested by providers to be administered to a patient’ (ie: DRUG_ORDER) which can maintain that specific type of information we are currently not capturing, and we can also put as part of the DRUG_ORDER the relationship to the DRUG_EXPOSURES that were associated to the order…vs. having to use this abstract notion of a ‘fact relationship’.

#29

Ok, I see three issues:

  1. Should analytics be careful when they see a record in DRUG_EXPOSURE, because there is no 100% guarantee that the drug was exposed to the organism?
  2. Should we record all the different capture mechanisms of that information (order, dispensing, administration)?
  3. Should we put the various mechanism into the same table or do we need DRUG_ORDER, DRUG_DISPENSING and DRUG_ADMINISTRATION?
    Anything I a missing?

To 1): I’d say yes, but not relevant to the CDM, as long as the information is there.

To 2): I’d say yes, and we are already doing it. Only question remains is if we have more than one type of record about the same drug event should there be a picking of the closest to the actual exposure, or should we record them all? Currently, the convention seems to be the latter. But yes, if we switch to the former, and say drop ordering records in light of existing administration capture - we would have the question if such elimination might kill the use cases of studying the process.

To 3): There would be two reasons for doing that: If we made the decision in 2) to keep only the “best” record but still want to keep the lower priority ones, or we fear that people will ignore the Type Concepts of DRUG_EXPOSURE and take everything face value.

Correct so far?

#30

I think you’re missing a critical piece (which is what the past few posts of mine have been focused on) which is the intent of the record in the DRUG_EXPOSURE record: is it the patient experience or is it including the provider intent (ie: it did not happen to the patient, but it was requested by a provider).

we covered that, I think we all agree that there is no 100% in observational data, and you have the flexibility of determine what strength of the evidence exists to assert the fact, but…and this is the important bit: the fact states that the patient experienced the effect of the drug.

Discussed that too in the prior point, in that different capture mechanisms will give you different levels of confidence about the fact: patient experienced the effect of the drug

#3 is the closest to the point except it’s still not clear the nature of the fact that we’re specifying in the DRUG_EXPOSURE table. ‘If i see an order for this drug, i can assume that it is taken by the patient’ is an inference about a drug being experienced by the patient. I don’t know about everyone else, but that is a big fly in my ointment about what the record in the DRUG_EXPOSURE is meant to represent. There are ideas that people would like to study the relationship between requests of treatment (aka orders) and the actual effect of treatment (aka: the exposure) and, IMO, the current CDM does not provide a place to store provider requests for treatment (in absence of the statement of if that treatment was experienced by the patient). If people want to do it today, then they can load up an auxiliary table that captures only requests by providers for a medication for a patient. If we want to support standard analytics around it, we should think about storing it in standard tables.

The crux of my argument is storing conflicting facts (order = provider request, without any statement that the patient experienced the drug; exposure = patient experienced effect of drug) in a single table is wrong, and I’d like the CDM remain ‘clean’ in that there’s no ambiguity between the facts.within each table.

It depends on what we want to capture in the CDM…currently (if I’m not mistaken), We’re simplifying those 3 mechanisms into one statement of patient exposure to a drug: orders, dispensing and administrations can infer a drug exposure. But all records in DRUG_EXPOSURE represent an inferred exposure. When people say ‘I have orders, and I know when I dispense them, should I put the order in the exposure table?’, I think the answer is ‘no’ because only one of those facts represents the patient experience of being exposed to a drug.

Maybe the answer is that I’ve been looking at that table wrong this entire time and I should have been asserting the type of evidence to use as my drug exposure. But, that really complicates my logic for selecting records: before i was simply ‘give me the observations of exposures’ but now it is going to be something like “Select drug exposures inferred from
orders that didn’t have dispensing, or dispensing without administrations, or administrations”…ugly,.and I have to tie all 3 of those mechanisms together to associate them to the single ‘this patient was exposed’ event. yuck.

1 Like
#31

You mean because it says “Exposure”, but we are not sure of it? Is the name of the table what irks you? Is this any different to “Condition Occurrence”? There, we also have a less than 100% specificity, which means we have records of Conditions which did not occur that way.

Agree 100%. Clair is at it. In fact, the next session (1st Tuesday of every month at 1 pm) or the one thereafter will be about this table.

The question is what it should say. Right now, the general assumption is that it contains records about the intention or process of the exposure of drug to a patient.

Exactly. But that’s all we have. We don’t know if the drug even made it into the patient with administration records. Patients receive the pill, keep them in their mouths and spit them out as soon as the nurse leaves the room. Happens all the time, especially in the psych wards.

So, I agree “Drug Exposure” is a simplification, and we need to know what evidence we actually have. But if this is organized through Type Concepts or separate tables I feel is secondary. No?

#32

Thanks, Christian, this was very helpful.

I guess you could say that, but it’s not so much ‘irks’ as ‘misleads’…and it is irksome if records that would never represent an exposure to a drug would be found in this table. But, table names is the least of my problems here…I feel like I’ve been misinterpreting the data since day one.

That’s what I was looking for: the ‘intention’ which I’ve been saying thus far should not be in this table you’re saying we should assume that those kind of observations could be there…and so when querying the table you need to restrict your search.

Yes, I’d only be arguing for separate tables if the information was a different form or function from our existing tables…and the ‘flexibility’ of the drug_exposure table lets you represent different things in the same form.

So, just like you might have multiple records representing the same drug episode, this is similar to seeing multiple diagnosis codes in the condition_occurrence table…someone may have 5 records of AMI on the same day, but it probably only happened once. But, the difference is that when you’re doing things like dose strength and continuous exposure, you have to be more selective about which events you’re going to incorporate into the analysis and my gut says that you have to be more selective about the drugs then the diagnosis codes (usually 1 AMI is enough to know you had that, but 5 records about an exposure looks like an overdose).

1 Like
#33

I interpreted the table as literal per its name for our data - only those drugs that were in part or completely taken by the patient. Since the drug type concept was optional - I didn’t consider using it to distinguish intent to treat vs treated. This has been a good topic and clears up a few things for me. If this is what was intended per table contents - then that is fine. I just need to make notes of this in my ETLs and educate users of this table to be sure they are writing the SQL properly for what they expect to get. Thanks all.

#34

Let’s make it crystal clear in the revised documentation, I agree.

Probably a good time to look at that DOSE_ERA table and the way we create it. That could happen there easily.

We need to do that at the CDM documentation level, too. Please watch out when it comes and comment.

#35

In EHR data ordered drugs may have two dates, the date the order/prescription was written and the date the Person is to start taking the Drug. ETLs normally use a COALESCE (“date the Person is to start taking the Drug”, “date the order was written”) since “date the Person is to start taking the Drug” is not always provided and users want to preserve all the data, and it’s allowed in specs.

The time interval between 2 dates may be delayed in time. And the worse scenario is when a treatment plan for >2-6 months will be recorded on 1 single day ahead of time. Types are already used in cohort building and I see, there is a plan to consider them in DRUG_ERA / DOSE_ERA constructor.

In light of this, don’t we want to have 2 separate Type concepts:

  • one to represent an intent to treat the patient on the specified date (e.g. ‘Prescription derived’ exposures);
  • another one to represent an intent to treat the patient sometime in the future (e.g. Prescription written’ exposures).

The same might be applied to Procedure orders.

1 Like
Important vocabulary release: Type Concept and Condition Status
#36

@Christian_Reich, @MPhilofsky

What is the DRUG_TYPE_CONCEPT_ID for “prescription written”? How do I handle this with the current type concepts?

Could we resurrect 38000177 Prescription written?

Tagging friends, @Sebastiaan_van_Sandi, @Rijnbeek

#37

Luckily, your original choice with a new concept_id is still there. And there are other options, too. I’m unsure which concept_id to use when, since the original discussion was to make the type concept_ids domain agnostic and not duplicative. And now we have ‘prescription ___’ which is essentially an ‘order’ for a drug or device. What’s the difference, @Christian_Reich?

  • concept_id = 32838, ‘Prescription written’
  • concept_id = 32839, ‘Prescription issue record’
  • concept_id = 32833, ‘EHR order’
#38

Wait these are what my Vocab 20200910 says:

  • 32838 EHR prescription
  • 32839 EHR prescription issue record
  • 32833 EHR order

I didn’t necessarily like these because I needed them for the outpatient setting so I’m not sure if the EHR generated the prescription or not. I still think a generic “prescription written” would be best.

#39

Sorry, my bad. ‘EHR’ should precede ‘prescription’. Your vocabulary is correct.

I think all the truly generic type concept_ids are gone. I’ll let Christian answer from here :slight_smile:

#40

He who destroyed all my TYPES

image

1 Like
t