Pharmacy claims -> Drug exposure. How to identify the dispensing/billing pharmacy

[Gowtham_Rao]

Assumption:
- pharmacy claim is not a visit.
- pharmacy claims may have a record in drug_exposure, but no record in visit_occurrence (no visit_occurrence_id for a given drug_exposure_id)

In v5.2 of OMOP, there is no care_site or location_id or pharmacy_id to identify which pharmacy billed/dispensed the drug. There is a provider_id but that is for who prescribed the drug.

provider_id - A foreign key to the provider in the provider table who initiated (prescribed or administered) the Drug Exposure.

Question to initiate the discussion: Do we need a field in drug_exposure for care_site_id. A FK to care_site table that has information about the pharmacy?

Alternative: Assumption above is not valid. Pharmacy claims is a visit.
So, drug_exposure --> visit_occurrence --> care_site --> location_id
For this we will need a new visit_type_concept_id 'Visit derived from encounter on pharmacy claim'. This will be a OMOP maintained concept.
Potential confusion with concept_id 44818517 'Visit derived from encounter on claim'. We need a THEMIS convention that this concept_id always is a 'medical claim', and not a 'pharmacy claim'.

@Christian_Reich thoughts? Should this be a CDM proposal?

[Christian_Reich]

@Gowtham_Rao:

It's the former. And yes, we could introduce pharmacy visits, covering dispensings that way. The CARE_SITE record would be connected through the VISIT_OCCURRENCE record as you said. But what about mail order dispensings?

Pharmacy claims or medical claims: Doesn't matter. If it is derived so be it. The visit_concept_id would be "Pharmacy Visit".

[Gowtham_Rao]

To address a question, "Is pharmacy dispensation a visit?" My opinion (now, after thinking about this) is the pharmacy dispensations may be considered a visit. The argument against it is that it is not a true face to face visit where a treatment decision was made. But it may be argued that it is a visit, because an intervention was made (dispensation of drug). So based on the 'intervention' it may be considered a visit. Drugs may be picked up by (or mailed by) anyone authorized - but since the intent is that it will be used by the prescribed recipient starting the date of dispensation. So, based on the intent to intervene and the intent to be used by prescribed - we may argue that pharmacy dispensation is a visit. The date of dispensation transaction is the visit-date, and visit-start-date = visit-end-date.

But what about mail order dispensings?

To address "Retail dispensation vs mail-order": I think we differentiated them by using drug_type_concept_id
visit derived from EHR vs medical claims vs pharmacy claim maybe differentiated by visit_type_concept_id

care_site for the mail-order pharmacy, would be whatever entity that mailed the drug.
place_of_service would be pharmacy.

The visit_concept_id would be "Pharmacy Visit".

So we need to add two concepts

1.visit_type_concept_id (omop concept) = 'Visit derived from encounter on pharmacy claim'

new visit_type_concept_id 'Visit derived from encounter on pharmacy claim'

2.visit_concept_id (omop concept) = 'Pharmacy visit'

So, should this be CDM proposal or Themis proposal or both?

[Mark_Danese]

I think the purpose of a "visit" in the OMOP CDM should be defined first. A visit seems to have at least 2 purposes.

First, the visit table is a join table that allows the data model to connect information (e.g., procedures and conditions).
Second, the visit table allows researchers to estimate the number and type of interactions with the health system (often needed in health services research).

Pharmacy records don't seem to have much information in them, making reason #1 less important. Having said this, some data sources will have prescriptions attached to visits, and it would make sense to link them.

It would seem that, from a health services research perspective, pharmacy visits are a real thing. While many people don't talk to the pharmacist, there is certainly a level of interaction that can be as important as other provider visits.

Mail order dispensing seems useless to measure from either perspective. There is no new information other than the prescription details. A drug table is sufficient to capture this. I can see an argument that they be visits of a particular type, for consistency reasons, but that is about it.

Having said all this, I believe this is a THEMIS issue and will probably be resolved there.

[Patrick_Ryan]

This is a thought-provoking thread. After @Christian_Reich reply, I was about to be trigger-happy and disagree, but on reflection, I'm not sure what best path forward is. My immediate inclination was that we shouldn't have 'pharmacy visits', but at a pharmacy, there is an interaction between a patient and a healthcare provider and there is an intervention (dispensing of drug), so it seems arbitrary to exclude this as a visit. If I go to the MinuteClinic inside of a CVS, I would clearly consider it an 'outpatient visit', and the only difference there is seeing a nurse practitioner or medical doctor vs. a clinical pharmacist (and often, the clinician is referring me to the next door over to pick up a script for something anyway); given my PhD is from a School of Pharmacy, I think I'm obligated to cry discrimination if we let clinical credentials be the only differentiation. An interesting aspect of this is that 'ideally', you would construct one pharmacy visit for the encounter, which might result in having multiple dispensings for that visit. However, it's unclear to me whether most datasets have the true fidelity to know which dispensings came with each encounter (vs. making an generally-good-but-not-strictly-correct inference based on dispensings on same day from same care site). It would be bad practice to assume each dispensing was its own visit, so we should avoid that. Now, mail order pharmacy seems logically different, there is no encounter between provider and patient, so it doesn't seem that would warrant a visit record.

One thing to remember, any foreign key link to a VISIT_OCCURRENCE_ID from a domain table (CONDITION, PROCEDURE, MEASUREMENT, and now possibly, DRUG) is optional, and in some databases, there may not be the ability to explicitly link the domain data to a particular visit. So, while I can support using this construct, just a footnote that we shouldn't get too reliant on an optional field if we are planning to do international network studies.

[mvanzandt]

@Gowtham_Rao. This is something we brought up at the THEMIS face-to-face. I would suggest the sub-group leader take this to continue the conversation.

[Gowtham_Rao]

Thank you @Mark_Danese @Christian_Reich @Patrick_Ryan - maybe we should look at this from a different angle. The use case is, support analysis where the unit of analysis is the pharmacy itself. i.e. for every drug_exposure record, we need to identify the entity that dispensed the drug. If i fill a prescription at my local CVS pharmacy, in the US the pharmacy will have a NPI/NCPD id that will help uniquely identify the pharmacy. Is this a care_site? I think, care_site table would be excellent to capture the pharmacy identifier. care_site_source_value will be the source identifier (NPI or NCPDP), location_id will be the physical address. (care_site table https://github.com/OHDSI/CommonDataModel/wiki/CARE_SITE)

We have two options to support this use case:
1. Assume that pharmacy dispensation records are not always a visit. If it is not a visit, then we need to make a change to drug_exposure and add care_site_id to drug_exposure table.
2. Require that pharmacy dispensation records are always a visit. Then we don't need to make change to structure of the CDM, because drug_exposure --> visit_occurrence --> care_site --> location_id

visit seems to have at least 2 purposes.
the visit table is a join table
the visit table allows researchers to estimate

agree on both cases. In this use-cases, where we want to identify pharmacy as a care_site_id, based on current drug_exposure structure - we have to use visit table as the join table. Alternative, is to add care_site_id to drug_exposure.

it's unclear to me whether most datasets have the true fidelity to know which dispensings came with each encounter

In claims data source: The classic example is chemotherapy infusion at an Oncologist office is billed as a medical claim using HCPCS code to indicate the drug. In this example, you would know which dispensing came from which visit encounter.
However, I agree, that source data derived from current US claims, don't allow for a systematic way to definitively link an encounter derived from a medical claim to an encounter derived from a drug claim.

It would be bad practice to assume each dispensing was its own visit, so we should avoid that.

I started with that assumption - but then revised my thinking on this based on

My opinion (now, after thinking about this) is the pharmacy dispensations may be considered a visit. The argument against it is that it is not a true face to face visit where a treatment decision was made. But it may be argued that it is a visit, because an intervention was made (dispensation of drug). So based on the 'intervention' it may be considered a visit. Drugs may be picked up by (or mailed by) anyone authorized - but since the intent is that it will be used by the prescribed recipient starting the date of dispensation. So, based on the intent to intervene and the intent to be used by prescribed - we may argue that pharmacy dispensation is a visit.

@Patrick_Ryan could you elaborate why you think using pharmacy records as its own visit is a bad practice. Wouldnt it be just a new visit_concept_id = pharmacy (not an outpatient, inpatient, etc)

and now possibly, DRUG) is optional

Just a clarification - current drug_exposure table already has the fk visit_occurrence_id and visit_detail_id

we shouldn't get too reliant on an optional field if we are planning to do international network studies.

Yes, current drug_exposure table has visit_occurrence_id as an optional field. If we deem that pharmacy is a visit, then we will have to visit_occurrence_id in pharmacy table required. This would avoid this confusion.

[Christian_Reich]

If it is not a visit, then we need to make a change to drug_exposure and add care_site_id to drug_exposure table.

and

Assume that pharmacy dispensation records are not always a visit. If it is not a visit, then we need to make a change to drug_exposure and add care_site_id to drug_exposure table.

I would not do that. We'd create total chaos about where to look for information. Sometimes we have to go through VISIT_OCCURRENCE to find care sites, sometimes we can jump directly. We already have that with the provider.

Require that pharmacy dispensation records are always a visit.

and

If we deem that pharmacy is a visit, then we will have to visit_occurrence_id in pharmacy table required.

Well, we might have data sources where nothing is known about the source of a dispensation. So, we cannot make it required. Or, if we make it required, we have to put in the value 0. We are discussing this in THEMIS (no null values, 0 if we don't know). But there is no difference.

[Gowtham_Rao]

Well, we might have data sources where nothing is known about the source of a dispensation. So, we cannot make it required. Or, if we make it required, we have to put in the value 0. We are discussing this in THEMIS (no null values, 0 if we don't know). But there is no difference.

Lets discuss this.
1. Pharmacy claim with no linked medical claim, pharmacy claim has dispensation date. Here we have two dates, visit_start_date and drug_exposure_start_date -- both are drug dispensation dates. This is the most common scenario.
2. Pharmacy claim that is actually part of a medical claim. This is the scenario where a medical claim is filed for infusing chemotherapy at oncologist office. In this case, visit_start_date is generally equal to drug_exposure_start_date. Exceptions are if this is a multi-day visit, and the drug_exposure happens on subsequent dates.
3. Pharmacy claims without the date of dispensation -- i dont think we can use this source data, because drug_exposure_start_date is a required field.

[Gowtham_Rao]

We already have that with the provider.

Good point. But we also have provider_id with condition_occurrence, procedure_occurrence, etc. and also in visit_occurrence and visit_detail. In this particular case, I think -- we should not use provider_id in procedure_occurrence, condition_occurrence etc.. but populate that information in visit_occurrence or visit_detail only.

The argument here is that - condition_occurrence, procedure_occurrence is a detail of a visit_occurrence. visit_detail is the detail of the visit_occurrence record. So condition_occurrence and procedure_occurrence should be linked to the visit_detail.

To allow for

planning to do international network studies.

and avoid

I would not do that. We'd create total chaos about where to look for information. Sometimes we have to go through VISIT_OCCURRENCE to find care sites, sometimes we can jump directly. We already have that with the provider.

we need to develop THEMIS conventions around the visit_detail IMO.

Enforce in omop version 6.x

[Christian_Reich]

1. Pharmacy claim with no linked medical claim, pharmacy claim has dispensation date.

Yes.

1. Pharmacy claim that is actually part of a medical claim.

Also yes.

1. Pharmacy claims without the date of dispensation

That's not what I am talking about. There might be source data that have a dispensation date, but no pharmacy information at all. Or where it happened. For those, we cannot create a pharmacy Visit, and we needn't, since we don't have CARE_SITE information anyway.

But we also have provider_id with condition_occurrence, procedure_occurrence, etc. and also in visit_occurrence and visit_detail.

Exactly. And one stands for the provider of a particular Condition, Procedure etc. record, and the Visit provider is more generic, but ill-defined doctor representing the entire Visit. And yes, before we go V6 we need to revisit this duplication, maybe do some "network studies" to see what folks actually populate.

[Gowtham_Rao]

The fundamental question as @Mark_Danese points out is purpose of records in visit domain. Should we make it a required central "join table" that relates all clinical event records in all Omop tables. I.e. all other event tables should not have a record without a record in visit domain, and all analysis should use visit table in joins

i.e. for every record in drug_exposure there should be a visit_occurrence record. Extending this logic to labs or anthropometric measurements, these events should also have a visit domain record.

If visit_occurrence_id is made required, then we can consistently use care_site_id, location_id, provider_id linked thru visit domain in network studies, and remove them from the other tables like condition, procedure etc. reducing ambiguity.

In first two cases, of the pharmacy example, i think we should create a record in visit table. In the third case,

There might be source data that have a dispensation date, but no pharmacy information at all. Or where it happened. For those, we cannot create a pharmacy Visit, and we needn't, since we don't have CARE_SITE information anyway.

I think we should still have a visit record, but the respective fields with missing information (care_site, provider_id, location_id etc) should be either null or 0 in the visit table.

one stands for the provider of a particular Condition, Procedure etc. record, and the Visit provider is more generic, but ill-defined doctor representing the entire Visit.

I think visit_detail is the solution here. Visit_detail is not a visit, but a generic detail of a visit record in visit_occurrence. So, the visit_detail is not a visit by itself, but something within a visit i.e. its detail.

So if a record in condition_occurrence, procedure_occurrence is also a detail of the visit_occurrence record, the best way to handle this is to use visit_detail as the anchor for the condition_occurrence, procedure_occurrence etc.

This avoids ambiguity

[Christian_Reich]

The fundamental question as @Mark_Danese points out is purpose of records in visit domain. Should we make it a required central "join table" that relates all clinical event records in all OMOP tables

Good point. Currently, the (unspoken) convention is this: Beyond person_id and date (datetime) no two medical events have mandatory and explicit links. Because most data sources don't care providing them. We have a whole lot of Analytics, which attempt to link things implicitly, like through cohort definitions and estimations. The reason we have visits, again unspoken, is to determine which kind of healthcare interaction was had during some clinical event, and to draw two types of conclusions: Severity of a Condition (ER and hospital are bad) and, much less common if your name is not @Mark_Danese, effectiveness of the healthcare organization: cost, location, specialty, etc.

If you want a "central join table" you'd have to explain what that means and what the analytical use case would be.

If visit_occurrence_id is made required, then we can consistently use care_site_id, location_id, provider_id linked thru visit domain in network studies, and remove them from the other tables like condition, procedure etc. reducing ambiguity

Yes, we could. But we cannot. Because the data are notoriously bad providing this information, even though you'd think it'd be pretty central to what happens to those patients. The reason is that the primary use of the data is for managing the healthcare organization or payment for healthcare, not for capturing the patient experience. Even medical charting should play a big role in the EHRs: A big chunk of what's in the raw Cerner/EPIC/Allscripts etc. is about scheduling, ordering, billing and communication between providers. Claims data are not better: they are organized around how the organizations want to get their money, not how the patients got diagnosed and treated.

Making a field in the OMOP CDM mandatory will not change that. All you get is a bunch of NULLs or 0s.

I think we should still have a visit record, but the respective fields with missing information (care_site, provider_id, location_id etc) should be either null or 0 in the visit table.

Well, that alone is of questionable value, but even if you want to create those zombie visits - you need to have the information what belongs to a Visit, and cobbling it together from VISIT_DETAIL we know can be a crap-shoot.

I think visit_detail is the solution here. Visit_detail is not a visit, but a generic detail of a visit record in visit_occurrence. So, the visit_detail is not a visit by itself, but something within a visit i.e. its detail.

Yes, but if you abolish the direct link from the event tables you force VISIT_DETAIL to be a carbon copy of those. Each time a psych counsel or radiological report comes in you'd force a new VISIT_DETAIL record. That was not the idea of that table.

@Gowtham_Rao: I have a lot of sympathy for what you are trying to do, but making visit_occurrence_id mandatory will not solve the problem. It's like a prohibition law.

On the other hand, allowing for pharmacy visit records is totally fine and supported by the current model. A pharmacy visit (derived from a pharmacy claim) would be independent from the doctor's visit (from a medical claim), and care_site and location will tell you which pharmacy the patient went to. In EHR records, we won't have these. So, what's the problem?

[Sigfried_Gold]

I don't know if this is helpful, but if one objection to counting a mail order dispensing as a visit is that no human interaction occurs (as might in a retail dispensing), we could counter that mail order dispensing generally includes many pages of drug advice as well as phone numbers for pharmacy questions.

[Gowtham_Rao]

allowing for pharmacy visit records is totally fine and supported by the current model. A pharmacy visit (derived from a pharmacy claim) would be independent from the doctor's visit (from a medical claim), and care_site and location will tell you which pharmacy the patient went to. In

Agree with you @christian_reich . I am going to request for new concepts on GitHub.

visit_concept_id (omop concept) = 'Pharmacy visit'

visit_type_concept_id (omop concept) = 'Visit derived from encounter on pharmacy claim'

[Christian_Reich]

Probably the former, because the other Type Concepts are rather brief as well ('Inpatient Visit").