OHDSI Home | Forums | Wiki | Github

Orders Only, Documentation and catch-all historical visits mapping

CDM Builders
#1

Dear OHDSI community,

We have several kinds of “visits” where is not entirely clear what to do with them:

  1. Historical visits: These visits could be inpatient, outpatient, or pretty much anything since it is a catch-all. My initial thought is to assign this concept_id. Is that the best one?
  2. Orders-only visits: These visits do not have patient interaction. They exist usually to create lab orders or drug prescriptions. My initial thought is to use this concept. Or should we create a new one @Christian_Reich @DTorok @MPhilofsky
  3. Documentation visits: these visits usually generate clinical notes, such as letters sent to patients. Should we also create a concept_id for this?

Thanks

Jose

#2

Hi Community,

Just writing again to make this visible on the top :slight_smile:

@Christian_Reich, @DTorok, @MPhilofsky, @Vojtech_Huser

#3

I was waiting for Christian to answer :slight_smile:

What’s the use case for keeping historical, “catch all”, visits? Visits are not required in any clinical event table. The concept_id you suggest is for hospital inpatient or hospital outpatient. This won’t cover the

concept_id = 0 is the closest match for ip/op/everything visits. Curious, what percentage of these “historical” visits are linked to clinical events? If it’s a low percentage and you lack a use case, you might consider not ETLing these records.

The CDM is a person centric data model. I would say if there is not a patient-provider interaction, then it is not a visit. I wouldn’t add a record to the Visit table for this.

Colorado doesn’t consider these as Visits since they don’t truly involve a patient-provider interaction. This would require a little more digging into the actual content and/or clinical events associated with these types of Visits to appropriately define with a visit_concept_id.

#4

Hi @MPhilofsky ,

Thank you for the answer. The issue with most of those visits is that they actually generate a clinical event (e.g. a medication order, or at least a clinical note). We have a step to filter visits that do not generate an event in the clinical event tables. We have had two EHR migrations and we have quite a few second opinions. Those second opinions usually transfer data as “historical”. As a consequence, the number of visits I linked here is quite significant.

In summary, if I drop those visits I will increase significantly the number of orphan events in the clinical tables.

Thanks again,

Jose

#5

Jesus! I am late. :slight_smile:

As @MPhilofsky said. No need for my input. A catch-all visit would be a VISIT_OCCURRENCE record with a concept_id=0, just as she said. But there isn’t a use case for that as far as I can tell. You are just cluttering the table.

And no, documentations are not Visits. Visits by definition are interactions of the patient with the healthcare institution. We are not running the hospital. However, there is a Case Management Visit. But that meant the involvement of the patient.

We are finishing the definition of each of these Visits soon. After the Type Concepts are done. Stay tuned.

#6

Hi @Christian_Reich and @MPhilofsky ,

Thank you both for the answers. Setting aside visits that generate only documentation let me give a concrete example for orders only visits:

The doctor sees the patient and is waiting for some lab results in order to prescribe a drug. The result comes after the patient leaves the building and after the encounter is closed. Finally, the result comes back and the doctor decides to order a medication. An encounter is created only to put the medication order.

Given the above scenario we may have three options:

  1. Have an orders only visit_concept_id. Bring in a record in visit_occurrence and drug_exposure
  2. Do not create a visit_occurrence record but keep the prescription in drug_exposure. This effectively orphan the drug_exposure record.
  3. Do not map the visit: visit_concept_id=0. Bring in the drug_exposure record and visit_occurrence record.

Now for Historical Visits:

A patient walks into a hospital system for a second opinion. Using a magic wand(pdf… or other) records from other hospital system comes into this hospital. The records are real but the encounters created are deemed historical given the uncertainty about which type of visit generated those records.

For that use case, I believe we have similar scenarios as the prior one.

Thanks again for taking the time to answer this.

Jose

@Patrick_Ryan if you can also chime in here it would be great :slight_smile:

#7

@jposada:

The best way to decide these are based on the use cases. Do you have a use case where you want to study those activities outside a patient encounter? These theoretical debates are not that fruitful.

Your first question: A visit is an interaction between the patient and the healthcare system. If the doctor does something in the middle of the day - there is no visit. You record the events, and that’s it. I can’t see an analytical use case to create a pseudo visit just because something happened. You already know it did.

Your second question. Yes, doesn’t look like those pieces of information are solid enough to become data. And then yes, you make them historical. Makes sense.

#8

To those of us who do ETL, “use cases” are theoretical. What is concrete is the number of errors we produce. And often there are competing errors.

For instance, in this situation, if I tie the drug to the original visit (even if it is ordered later in the day), I get a Visit Date Disparity error. If I tie it to the pseudo-visit (Orders Only), then I get a Zero-Concept ID error. If I don’t tie it to a visit at all, the orphaned drug record results in a Null Foreign Key error.

I know, I know, visit_occurrence_id is not required, but bosses often don’t care about why a measure might be yellow or red. They just want to see green.

I’ve noticed that these types of problems most often occur in the Ambulatory setting, rather than the Hospital setting… OMOP seems to me to be fitted mostly to hospital type visits.

In the hospital, when a patient is admitted, the attending may order a test, wait for the results, examine the patient, order a medication and then administer it, all in one “visit”.

In the ambulatory setting, a doctor may order a blood test prior to the visit, go over the results during the examination, order another test, and then order a medication the next day. It’s essentially the same process. However, in the hospital, it’s considered a single visit. In the ambulatory setting, the tests and drugs are not part of the “visit”.

Why should an ambulatory visit be only “face-to-face”? Most of the time in a hospital visit, the patient doesn’t actually see the attending. Most of the work is done by surrogates or outside of the patient’s room. What difference if they’re sitting in a hospital bed or their own bed at home?

2 Likes
#9

Hi @Christian_Reich,

Regarding this

Yes, we have. A lot of data pertaining to outpatient / ambulatory research that is generated this way. This is, all researchers that want to study an outpatient population want this data and they want to know if the data happened as part of the “visit”. In conclusion, we would want to represent these visits somehow and not with concept_id = 0. This is because the “care” for this patient happens in disjoint encounters

#10

@roger.carlson:

I understand your problem. I am not dismissing it. But you have to understand that we have to have a way to make these decisions, otherwise we don’t have an OMOP CDM, and everybody just wants their specific data represented 1 to 1. Not sure why we would need a CDM in that case.

The principles are:

  • We build the CDM for an analytical use case. What are you trying to analyze, and what data do you need to represent for that. Data that are not necessary are not in.
  • We have the patient perspective in mind. Not the provider’s or the institution’s. When the attending checks the order is irrelevant for the health of the patient.
  • Whatever we decide has to be standardized so it works for everybody in a network where the data are not accessible to researchers.

According to the documentation, Visits are “events where Persons engage with the healthcare system for a duration of time. Visits are defined by a configuration of circumstances under which they occur, such as (i) whether the patient comes to a healthcare institution, the other way around, or the interaction is remote, (ii) whether and what kind of trained medical staff is delivering the service during the Visit, and (iii) whether the Visit is transient or for a longer period involving a stay in bed.” Providers doing some administrative act are not Visits according to this definition.

@jposada. Hm. What is the scientific question here that results in evidence to improve patient care? What work the provider accomplishes while the patient is still in the office?

Look: Right now those activities are explicitly not a Visit, but they can still be in the data (just without a Visit). If you think you have a use case and you want to push a change to make it work please come to the CDM WG. @clairblacketer will take it on.

1 Like
#11

Thank you @Christian_Reich this was indeed a very interesting conversation. Let me loop back with all this valuable info. If our community at Stanford is interested in pushing this after all the clarifications, I will certainly attend the CDM working group meetings.
Thanks again

t