OHDSI Home | Forums | Wiki | Github

Analyzing visits : variations by source

Researchers
#1

Apologies if this has been covered. I’ve seen some discussion of ED and IP parsing for visits, but haven’t seen as much about outpatient visits.

In essence, some sources - especially EHRs - capture all kinds of ‘visits’ that occur in ambulatory or outpatient settings and have important data associated with them, but don’t represent the archetypal care team-patient interaction that might be thought of as an outpatient visit. E.g., a visit to the office of a provider; or even a telephone call with the team or a secure electronic message. In most research that involves tracking / measuring these visits, it is important to separate these kinds of visits from other interactions. For instance, we have documentation or chart abstraction visits. The Book of OHDSI seems to imply bringing in all these visits, so I’m curious how people write analytic scripts or concept set limiters to make sure that their research is based on the appropriate qualifying visits for the research.

Are there examples out there that people would be willing to share?
Thanks.

Dave Dorr, OHSU

#2

Thank you for asking this question. We have a similar issue and haven’t really decided on the correct approach.

An office visit (or telephone visit or some other outpatient visit) may result in an order for a lab (for instance), but the encounter for the lab is different than the encounter for the office visit. It isn’t restricted to labs either. It could be a clinical documentation or a clinical support, or any number of encounter types.

Currently, we store the additional encounters in the visit_occurrence table with a visit_concept_id of zero (No matching concept). Then we’ll store visit_id in the visit_occurrence_id field of the measurement table.

This leaves us with a bunch of ‘visits’ which aren’t visits, but at least the measurement has a related record.

Since visit_occurrence_id is not a required field in the standard data tables (measurement, condition_occurrence, observation, etc.), we could leave this NULL and simply not put the related encounter in the visit_occurrence table. But this would leave the measurement record orphaned. As a database developer, this offends my deepest convictions.

#3

Yes, all our database engineers and analysts agree with you. It just makes things more complicated for researchers. Love to see some queries that facilitate cleaning up the data - for instance, counting only office visits.

#4

Friends:

I think you are mixing up two issues: The interaction of the patient with the healthcare system (Visits) and the way data get captured (Types). For interactions that don’t involve patients coming to an office, like phone or email contact, you have the Visit concept Telehealth. How the data get captured (EHR, CRF, registry) is recorded through a Type concept (which are in the process of being revamped as we speak, the release is imminent). Documentation and abstraction are data capture activities carried out by some institution, the patient has nothing to do with it.

Let us know if you need more detailed Visit or Type concepts (after the release) and we add them in.

#5

Response already obsolete. The new Type Concepts are out.

#6

Well, I can’t speak for @David_Dorr, but I am certainly mixed up. :slight_smile: I hope I am not hijacking his thread with something unrelated, but is seemed related to me. His comment above struck a nerve with me.

In essence, some sources - especially EHRs - capture all kinds of ‘visits’ that occur in ambulatory or outpatient settings and have important data associated with them, but don’t represent the archetypal care team-patient interaction that might be thought of as an outpatient visit. E.g., a visit to the office of a provider; or even a telephone call with the team or a secure electronic message. In most research that involves tracking / measuring these visits, it is important to separate these kinds of visits from other interactions. For instance, we have documentation or chart abstraction visits.

This is true in Epic. There are many encounter types which DO represent visits (like Inpatient, Outpatient, Office Visit, etc). However, there are other, non-visit encounter types (Refill, Orders Only, Clinical Support, Lab Draw, Appointment, Documentation Only, etc.) which have important information associated with them, but are not “visits” in the sense that David described.

That leaves some questions:

  1. Do I put these non-visit encounters in the Visit_Occurrence table

  2. If so, what do I put in the visit_concept_id field?

  3. If I put zero (0) in the visit_concept_id field, is that sufficient to distinguish those from real visits? (Which I believe was David’s question.)

  4. If I don’t put these non-visit encounters in the Visit_Occurrence table, I lose the relationships between Visit_Occurrence and the Standard Data tables (measurement, observation, etc.) I create orphaned records which strike me as a data validation nightmare. For instance, if I have a Refill encounter for Prednisone, and I don’t record that encounter in Visit_Occurrence, how can I validate it against my EMR? How can I be sure it isn’t an artifact created by a previous query?

So I don’t really see how the changes to the visit_type_concept_id apply. As you said (somewhere) it is really the visit provenance rather that visit type. Visit_concept_id is really what the real-world thinks of as a visit type.

Can you advise me on how to address this issue? If it’s with Type concepts, I’m not seeing how that works.

#7

@David_Dorr,

IF you believe your EHR data captures the data being produced during a Person-Provider Visit AND you ETL these clinical events to the CDM, then you can possibly eliminate all Visits that do not have a clinical event associated with the Visit record. Thinking about it from the Person-Provider point of view, at a minimum every Person-Provider interaction should at lease have a CPT code for the Visit. And almost every/every Visit will also produce vital sign records in the Measurement table. This won’t work if your billing is separate from your EHR or vital signs aren’t recorded in the EHR. Be forewarned,I haven’t implemented this suggestion.

#8

@roger.carlson,

OMOP is a Person centric data model :slight_smile:

I consider any Person-Provider (MD, RN, MA, lab tech, x-ray tech, pharmacy tech) interaction (face to face, phone, telehealth) to be a “real” Visit. These real Visits belong in the Visit table.

Non-visit encounters used for hospital workflow, tracking, documentation, etc. should NOT have a record in the Visit table. Visits are considered clinical events and inform the creation of the Observation Period table, by adding in workflow encounters to the Visit table, you are declaring a clinical event happened, which it did not, and possibly altering your Observation Period.

That’s ok, the visit_occurrence_id is only mandatory in the Visit Occurrence table.

#9

Roger 100% captured my concerns. Roger, I’ll do a sidebar with you since I have some detailed examples to share. Melanie is actually assisting us in just this endeavor and I think the filtering process she describes is just the approach we will take. No ‘abstract’; yes ‘medication dispense’

#10

@roger.carlson, I do agree with you about these visits and we haven’t come up to a consensus in AoU, so that’s for brining it up here. Right now, we do what @MPhilofsky suggested, which is keep the visit_occurrence_id null (and it bothers me too :slight_smile: ), but I don’t think all information can/should be tied to a visit; however, medication refills are one that I’m thinking should be labeled at a “Telehealth” visit like @Christian_Reich mentioned. The others data points like documentation that gets scanned before a visit/appointment, like insurance cards, don’t need to be tied to a visit in my opinion. To your point 4 of loosing information by not putting non-visit encounters in the visit_occurrence table, I think that’s okay. I personally would add extension tables/columns in my local omop to handle such validations between omop and the EHR. We’ve done this inconsistently through various mapping tables in our ETL.
I know this post is a few weeks old, but I’m curious what solution you and @David_Dorr came up with that I could adopt :slight_smile:

t