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â.
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â.
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.
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.
So we need to add two concepts
1.visit_type_concept_id (omop concept) = âVisit derived from encounter on pharmacy claimâ [quote=âGowtham_Rao, post:1, topic:3795â]
new visit_type_concept_id âVisit derived from encounter on pharmacy claimâ
[/quote] 2.visit_concept_id (omop concept) = 'Pharmacy visitâ
So, should this be CDM proposal or Themis proposal or both?
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.
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.
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:
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.
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
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.
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.
I started with that assumption - but then revised my thinking on this based on
@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)
Just a clarification - current drug_exposure table already has the fk visit_occurrence_id and visit_detail_id
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.
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.
and
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.
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.
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.
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.
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
and avoid
we need to develop THEMIS conventions around the visit_detail IMO.
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.
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.
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,
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.
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.
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.
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.
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.
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?
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.
Probably, itâs time to revive this topic and bring the Themis convention in. So we definitely can use âPharmacy visitâ to organize DRUG_EXPOSURE events into visits, but should it be obligatory to create those visits? We also can use the costs to define them; should we also suggest using a date of dispensing to group the events into a visit?
From cost and utilization perspective, maintaining record level referential integrity to the source data becomes important.
I.e. when drug_exposure is joined to visit_occurrence/visit_detail joined to cost_event_id, it should not increase or decrease record count or cost values.
