OHDSI Home | Forums | Wiki | Github

Prescribed and Dispensed Drugs in the DRUG_EXPOSURE table

Implementers
#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.

1 Like
#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
#41

Those types were old, tired, broken and corrupt. They had to go! :slight_smile:

Ok, what are you suggesting?

  • 32838 “EHR prescription”
  • New “Prescription”

32833 “EHR order” is for within the Visit. Not for another (e.g. Pharmacy) Visit. 32839 “EHR prescription issue record” I think is an artifact. No idea how it snuck in. We could kill it.

1 Like
#42

Thanks for clearing up this ‘prescription issue record’, @Christian_Reich. Couldn’t figure what that was supposed to mean…
As to the EHR prescription versus other types of prescriptions, we now have a number of new CDMs that include both hospital data (including EHR prescription records, possbily with corresponding EHR administration records) and primary care data. The latter may or may not come from the same system, but has definitely been recorded in a different setting. Would it be possible to make a distiction between the two types? Strictly speaking the term EHR is applicable to GP record systems as well, but usually it refers to hospital information systems. Perhaps ‘EHR outpatient note’ > EHR outpatient prescription would work, or, if we look for a type concept similar to ‘Pharmacy claim’, something like GP prescription.

#43

Please explain this more. I don’t understand the difference. If a Person receives an order for a drug during a Visit, we use 32833, EHR order? When do we use 32838, EHR prescription?

The drug_exposure.visit_occurrence_id is the FK to the Visit table which will distinguish an inpatient and outpatient visit. Assuming the “hospital data” = inpatient Visit and primary_care = outpatient Visit. Does that work, @Sebastiaan_van_Sandi?

#44

That could work, Melanie, were it not that the outpatient care in this case (also) refers to hospital care provided in an ambulatory setting. I did not look at visit_concepts for this, but as it appears there is no way to specifically represent GP visits there either. It may be possible to work with care_site and/or provider location information, but that would be a roundabout way - especially compared to the hospital setting and/or provenance which it is supposed to distinguish from.

t