OHDSI Home | Forums | Wiki | Github

Definition of Visit, transfers and referrals, and distinction of ER from hospital visits

CDM Builders
#1

Friends:

Transferring a discussion from the CDM working group here:

@rimma said:

Hi @zwbutt :

Could you please elaborate your concerns about the current proposal? It seems to me that we are on the same page, but I may be wrong.

@Christian_Reich said:

I think you are on the same page. I am the one who is trying to avoid these claim-based or encounter-based approaches.

I was thinking that each exposure of a patient to an organizational unit providing care is a visit. So, those units would be doctor’s offices, wards, clinics, the ER. Hospitals usually are composed of many units, outpatient offices only of one. A hospitalized patient goes through several such units, or not, each representing a visit. They could belong to different hospitals, or the same. And each move from one to the next is a transition. The last transition would be a discharge.

@rimma said:

I thought so.

What you are proposing is a complete re-definition of a visit as it exists in the CDM now and being perceived by everybody not just by the claims. (Just think about calculating your inpatient admissions, handling hospital readmissions, and so on, and so forth) if it is handled in the same way as we are doing AD transfers. This proposal has not been either thought through or discussed at any level, it needs a very thorough consideration.

The ADT transfer proposal on the other hand addresses transfers between visits as they exist now. It’s been discussed at length, vetted by a relatively large group of people, and ready to go, with the change that you suggested today to handle the visit links in the Visit_Occurrence now.

I suggest moving it without further delays and addressing the transition of care separately and carefully.

What do you think?

@zwbutt said:

I agree @Christian_Reich, your definition of “visits” within the generally accepted visit/encounter certainly added a new dimension to the discussion. Rimma my understanding of the original issue and solution presented is the inability of some EHR’s to identify an ER encounter separately from the “true inpatient” part of an inpatient visit that originated from an ER visit. That was certainly true in the past on the clinical side and is still true for the claims data but as I mentioned any ONC Certified EHR that is also doing eCQM’s is forced to implement workflow that assigns two SNOMED Encounter codes, one for the ER and the other for the inpatient and in most cases the eCQM specifications then have logic to link these two into one unit using timing relationships because many measures apply to both visits. So my guess is the newer data would have these two encounter types. What I said initially was that such encounters would be similar to this new “conjoined” visit type, however in response to Patrick’s question regarding how this would play out in the real world I was trying to point out that for this to work the underlying EHR would have to have an ability to differentiate inpatient visits with an ER visit “attached” from inpatient visits without the ER visit in the source data. If however, the initial problem is the EHR’s inability to do this than I am not sure if this solution would really solve that problem. As was mentioned by someone this could be a way to express those visits that have already been identified using the timing logic as ER+inpatient visit but that would be a different use case. Hope that clarifies what I was trying to say. I am happy to discuss this further as this has been one of the biggest headaches in implementing eCQMs.

@Christian_Reich said:

@rimma: Explain:

How do you transfer between visits, if visits are hospitalizations from beginning to end? Patients go either home or to a nursing facility. What’s the transfer here?

@rimma said:

Transfers indicate transition from one health care provider/facility to another. Not all visits have transfers. Some examples of transfers: ED->Inpatient, sometimes Outpatient -> Inpatient is a transfer, Inpatient -> Rehab or other long term facility. In your examples, patient’s encounter with a provider/facility ends at discharge, discharge disposition indicating how/where it ended.

We may need to look at the various definitions of encounters and their attributes to solve the entirety of use cases. Here is one of them: https://www.hl7.org/fhir/encounter.html

However, ADT are well defined and widely used, they are basis for analyses and delineations, let’s solve what’s easy first. Is not that what your motto?

Capturing more than one care_site_id or provider_id per visit_occurrence
Mapping for patient referrals to specialist, etc
#2

We have this problem, and we have the similar problem distinguishing subsequent “visits” within the same hospitalization (congregations of healthcare activities provided in hospital departments other than the ERs, I am trying to avoid the claims-term “encounter”). The choices are:

  1. A visit is a set of healthcare provided by the smallest organizational unit we can identify. That is usually a hospital ward or department, with the same set of doctors and nurses, where the patient is usually in the same bed. This is very real to patients.
  2. A visit is a hospitalization as a single hospital stay, which starts with admission to the hospital and ends with discharge from the hospital. Within that hospital visit, you could go through several different wards or departments, with transfers between them.

If we want to be able to understand the effect of different types of departments (e.g. comparing surgical or medical oncology) we need to do option 1. If we want to distinguish patients coming through the ER or not, we need option 1 (even though Zahid had an idea how we could make it work in option 2). I don’t know when you would prefer option 2, but I understand the data are usually easier to get.

Actually, this document describes exactly the same two choices, except they use “encounter” instead of “visit”, and “practitioner/location” instead of “ward/department”.

What are ADT?

#3

ADT = Admission/Discharge Transfers

#4

A VISIT as it is defined now (from admission to discharge) has a set of attributes and standard descriptors that apply to the entire visit rather than a single unit of care. Some of these are: visit type (e.g. inpatient, outpatient), length of stay, admission source/discharge disposition described by place of service. Hospital re-admissions are determined based on the entire visit. Billing diagnoses are related to the entire visit. For many types of observation (labs, findings, and even procedures), it is often hard to determine unambiguously at which hospital unit they were performed. Visit costs are also associated with the entire visit. Therefore, preserving the unity of a visit as it is currently defined is important.

Another reason for preserving the current visit definition is that extracting the smallest units of granularity of care from every data source may not be possible or practical. This may cause mixing different levels of granularity in the same data.

One solution for addressing the need for greater granularity in the transition of care is to represent these granular units of care, if available, in a separate space (additional table) linked to the Visit_Occurrence. Careful consideration of smaller unit attributes will be required.

#5

I have to agree with @rimma. The visit is defined as from admission to discharge and generally available data is applied to the whole visit. This is certainly applicable to claims data and some EHR data.

Though, I do appreciate @Christian_Reich’s visit definition as “healthcare provided by the smallest organizational unit we can identify”. I’m all for storing more granular data in the CDM. But, adding these small “visits” in the Visit Occurrence table will cause a problem because there will now be two different definitions of visits in one table (admit/discharge records vs small “visit” or healthcare-provided sessions).

However, I do believe some EHR data providers have solved this problem by creating an “encounter” table. Humedica data has a Visit table (that stores records similar to the original definition that @rimma defined) and an Encounter table. The Encounter table records every interaction a patient has had with a healthcare provider, which is similar to @Christian_Reich’s definition of a visit . And since many healthcare providers can contact a patient during an inpatient stay, you would have multiple Encounter records assigned to one Visit record. This is also similar to the U.K.'s HES data (documentation here) where they have a Spells table that records the whole inpatient admission date range and then the Episodes table that records each physician’s interaction/care/procedure done with the patient during that inpatient admission. As a bonus, this suggestion will also allow CDM to record multiple providers for one visit. And since the Encounter table has more granular data, we could include time of day, as well as dates.

For the record, I support the proposal as is.

#6

@jenniferduryea:

Yes, you nailed it.

But here is the question: What you call “encounter” I called “visit”, and what you call “visit” I wouldn’t have an equivalent. Naming conventions aside, why would you need from an analytical perspective the equivalent of the Rimma-Jen visit? Is there a use case?

#7

HAHAHA @Christian_Reich! You definitely hit the nail on the head. :wink: I can only speak for our company on this, but, no, we do not have any analytic use cases for Visits. We changed our internal conventions to create visit records similar to the definition of what you propose. For us, we are more interested connecting procedures to conditions, so we use visit records for that. In our data, the amount of “visits” a patient might have looks very inflated compared to what a patient might consider a visit. But, honestly, we don’t care because we never use visit records as what (I assume) the CDM intended.

That said, I do like the proposal because adding the admit/discharge data will help identify inpatient visit records where the admission came from the ER vs not. And that is useful because we don’t have to make assumptions that two visits with 0 days between the start date of one inpatient record and the end date of the other ER record are related. This is especially cumbersome in claims data where you only get one record for an ER admitted inpatient admission. You some how have to create two visits from one record, which has many other problems (i.e. what conditions to you assign to each visit? Are any procedures applicable to one visit over another? Should we split up the costs?). Cumbersome and vague. With this proposal, we can just see if the admission status on an inpatient visit was “from ER”.

#8

Ok. I get it. Essentially, you are saying that the combination visits are (i) much easier to build because it is hard to dicypher what activity belongs to what individual microvisit (encounter), (ii) you need it anyway because of the admission/discharge logic, and (iii) if we happen to have the granularity what’s going on inside the combination visit we can create encounters. So, in a way, you are suggesting a pragmatic two-level hierarchy: on the bottom the encounters (if possible), which then map into a combination visit. And if we don’t have the former, but there is ER involved, we create two different types of combination visits, one that starts with an ER, the other one without.

Yeah, we could. Not pretty, but much more feasible. What do other folks think?

1 Like
#9

I don’t know the answer, but I do know that I once spent $80,000 in consulting costs to adjudicate all our visits, combining pieces of admissions into whole admissions. It turned out to be a non-trivial exercise. The problem was that I did not have the resources to keep it going forward. In the long run, I just left them separate for each investigator to deal with.

George

#10

Let me start with a scenario from Europe. A patient in Germany/France/Czech rep has chest pain. On Tuesday arrives (e.g., by ambulance or otherwise) to ER and needs surgery, and after surgery goes to ICU and after ICU goes to regular ward. He leaves hospital later that week (e.g., Saturday).

Since the billing in EU is rather different, from a point of view of the patient and the system - it is one healthcare encounter (macro-“regular”-visit).

I don’t like the notion of micro-visits. I do like the concept for an encounter.

Hospital ADT system clearly records transitions to different hospital units. In US, it may be also viewed as one macro-visit with “included” micro-visits.

My vote would be against micro-visits and clearly capturing ADT data somehow. I support the current proposal.

#11

Friends:

Is our understanding compatible with what Erica has put down in her Truven ETL description? I don’t have an easy access to Truven anymore.

#12

The visit description defined in Erica’s Truven ETL is consistent with @rimma’s definition of a visit (definition: one visit record for the whole hospital admission). I believe this is how OHDSI has chosen to define “visits”. There is, currently, no table that stores @Christian_Reich’s definition of visit (definition: one visit record per the smallest organization unit we can identify), which we can refer to as “micro-visit” or “encounter”.

That is why I propose we create an “encounter” table where we can capture these “micro-visits” at the smallest organization unit and then link those encounter records to one visit record.

Personally, I’ve seen/done a number of ETL’s where each ETL has defined their visit record as something slightly different due to the nature of the data and the needs of the client. And the variance in these visit record definitions are due to the different use cases involved with @rimma and @Christian_Reich different interpretations of a visit. It would be nice to store data using both visit definitions (visit occurrence and encounter table), in the hopes to normalize the visiti definition, overall.

3 Likes
#13

Has there been any work in support of @Christian_Reich’s definition of visit i.e. encounter or micro-visit? Is there an interest to discuss this transition of care use-case further?

#14

@jenniferduryea and @Gowtham_Rao:

Actually, more importantly, what are the use cases? What are the analytic questions you are trying to address?

1 Like
#15

@Christian_Reich - Looks like a use case for using encounters was just entered into the forums here. Creating mico-visits or encounters would solve the problem of multiple providers and multiple care_sites at one visits_occurrence record.

Our internal use case is to specifically like a condition_occurrence record with a procedure_occurrence record, similar to recording an indication for a drug. To reword this for @Gowtham_Rao, we create a visit_occurrence record to link the line diagnosis (stored in the condition_occurrence table) to the CPT/HCPCS code (stored in the procedure_occurrence table) from HCFA 1500 claims.

#16

@jenniferduryea Thanks for the pointer. We’d reviewed that discussion, but ultimately decided that the semantics were just different enough that fitting them into visit_occurrence was causing more complication than benefit. But happy to keep discussing as we get more experience!

#17

Thank you @jenniferduryea

Is this link done thru fact_relationship table? If so, what relationship_id do you use to associate condition_occurrence, procedure_occurrence, drug_occurrence to visit_occurrence (or even a claim_occurrence - custom table?)

visit_detail / visit_occurrence domains
#18

@Gowtham_Rao we create one visit_occurrence record to link the condition_occurrence and procedure_occurrence record together. This creates a number of “micro-visits” in the visit_occurrence table. That is how we defined visit records in our data - on a service-level (not patient experience level). We do not use the fact_relationship table. Hope that helps!

#19

Was this issue ever resolved for the CDM v 5.0 (or 5.1)? I’m working with Humedica/Optum EHR data and it is as Jen described earlier. Our basic unit is an encounter (called a visit in the CDM). For inpatient encounters, we use an algorithm to group the encounters into visits and we store that information in a different table. If possible, we want to preserve our notion of visits because it is analytically important and it allows us to give an end date. At the same time, we don’t want to duplicate information in visit_occurrence by putting in both visits and encounters. Is there any guidance on what we should do?

New table for visits, encounters, care transitions
#20

We’re running into this as well: we want to create cohorts based on the number of inpatient visits, but when an encounter with a healthcare provider is embedded in the visit, it looks like the person had 3 inpatient visits when they really only entered the hospital once but met with 3 care providers.

I sense that what we need is to separate a Visit from an Encounter, a visit represents a patient stay in the hospital, and an encounter is just in interaction with a person.

In this model, however, it seems you’d only have a visit if it resulted in an in-patient stay (where you need a multi-day duration of time) while an encounter could be stand alone (and represent an out-patient event…but not a visit). However, we record visits as ‘emergency room’ events and that gets put into the visit table, i wonder if we did rework the visit model, visits would be simply a way to determine periods of time a person was in a room (or building) and you can optionally associate condition/drug exposures/encouters to a visit occurrence. and in the encounter you can specify if it was an emergency room setting or otherwise.

1 Like
t