OHDSI Home | Forums | Wiki | Github

New table for visits, encounters, care transitions

@Gowtham_Rao:

No more posts and “Clarify and define”? How do you suggest we do that? :smile:

What are the concepts we want to represent? Are they a service, a visit, an encounter, a mini-visit, a level-of-care, an episode. Do we need type concept? Then a hierarchy? Are there vocabularies to represent these concepts?

Since “Service” is not a separate domain in OMOP. The main clinical event domains are procedure, condition, observation, visit, measurement etc. So, maybe we can rephrase @hripcsa question as -

“So if I want to link a procedure to the visit the patient was on and to the location the patient was in at the time of the visit.”
Since most of the time a procedure is also a service.

If we want to call these services

and they dont fit in observation table - then we need a new domain called Service.

Now if we have service domain and a service table - then, going back to @hripcsa question

Now visit_occurrence has a 1:n relationship with service_occurrence table, procedure_occurrence table. We pick the visit’s that meet the criteria of having certain procedure and service.

@Gowtham_Rao:

I think @hripcsa is saying something else. He is saying that service and encounter are not hierarchical to each other. One is not nested into the other. So, our nice RxNorm-like Visit hierarchy might break.

I don’t know that. You guys know the raw data much better.

No. Service would be one of the levels of the Visit hierarchy. There would be many different services listed. All hierarchically decendents to a Visit (a Inpatient, Outpatient, ER etc. Visit).

I think @hripcsa doesn’t challenge the 1:N from Visit to Service, but the 1:N from Encounter to Service, or the other way around.

It’s too late now, but I will create a little test hierarchy, so we can play, It’s better to use an example.

Let me give an example. Someone comes in for an embolic stroke and undergoes a carotid endarterectomy. They go to the emergency department, then they are admitted but no beds so they stay in emergency for the next day, then to neuro stroke floor then to pre-op area then to operating room then to recovery room then to vascular surgery floor. They are discharged and go to a rehab center, and finally to home. They have other temporary locations during the hospitalization but don’t give up their bed. In a different patient, dialysis could be an example where they have two beds at the same time. They come in on the neuro stroke service, cardiology is brought in as a consultant. Once it is decided to do surgery, they could move to the vascular service as primary even though they are still in the neuro bed (although they will more likely stay on the stroke service until surgery). After surgery they are certainly on the vascular service.

If a test is done, you might want to assign it to a location and to a service. One does not imply the other. And it could occur during the ED assessment or during the hospitalization, even though they are in the same location.

So then the question is, why would we track all that in an OMOP database. What is its use for research? Just thinking, the main thing I want to know from locations is whether they went to the ICU, and perhaps when. Otherwise I would be using all those facts mainly to push a phenotype decision one way or another. If some other information were missing, knowing that they were at a location or on a service is evidence. But if we use OMOP for other purposes, like tracking quality, then use of the information becomes more apparent.

I am not saying necessarily that we have to track all of that. I am instead saying that if we do track, we might as well track it correctly. Don’t put a single column everywhere. Either do it right, or put in no new columns.

I guess we could make fact_relationship more explicit. Have a new bit of meta-information that tells you explicitly what pair of tables is being joined, rather than rely on the domains. E.g., add two columns, the name of the first table and the name of the second table. Then when you want to look up relationships, you have to name the two tables as data. But you don’t need a case statement.

George

@hripcsa:

Happy to consider the FACT_RELATIONSHIP route, but I don’t see a problem yet. Take the first patient:

  • In GOWTHAM_OCCURRENCE, there is a string of records for ER, Neuro Stroke, OR, Recovery Room, Vascular Surgery, Rehab, Home Service. During the same time, but not back to back, are the other activities (e.g., Psych Service (=Council)).
  • In VISIT_OCCURRENCE, we infer four records: One for the ER, one for Inpatient from the start_date of the ER to the end_date of the Vascular Surgery, another Inpatient in the Rehab, and a Long-term Care. The reason we know it is two Inpatients and not one is the admission/discharge. Each time that happens, we start/end a new Inpatient. Internal transfers don’t trigger such a break. Similarly, ER doesn’t count as Inpatient (even though the patient may end up there more than an afternoon). All of them are back-to-back, no overlaps.
  • In PROCEDURE/DRUG/CONDITION we put links to the corresponding GOWTHAM records, and links to the first or second hospitalization.

The second patient:

  • In GOWTHAM, we put Neuro Stroke, Vascular Service (not Vascular Surgery floor), OR, Vascular Surgery. In between, there are Cardio Service and Vascular Surgery Service. Plus the Dialyses every week.
  • In VISIT, we have one Inpatient from beginning to end. Plus we got Outpatient Visits for the Dialysis during the Inpatient.
  • In PROCEDURE/DRUG/CONDITION you again got one link to the various corresponding GOWTHAM records, and another to single Inpatient record.

Something like that. I am not 100% familiar with the US nomenclature, did my active medical time in England. But works?

Now the VISIT Concepts:

The Visit level is what we roll things up for placing into the VISIT_OCCURRENCE table. The GOWTHAM table keeps the others as is. These are the Concepts ER (Visit level), Vascular Surgery (Enounter level, which contains a location where the bed is) and Vascular Service (Service level).

Let me know.

The point is that in your diagram you have the services rolling up to the encounters/locations, but they can’t roll up. And there is more than one service at a time. Perhaps best to talk in person.

George

@Christian_Reich @hripcsa Do you agree with this argument?

From http://www.ohdsi.org/web/wiki/doku.php?id=documentation:cdm:visit_occurrence
A person’s care journey over time is represented in the visit_occurrence table of the OMOP common data model as “span’s of time a person continuously receives medical services from one or more providers at a care_site in a given setting within a health care system”. The unit of representation or record in visit_occurrence is thus a unique combination of person + care_site + continuous care time-span.

Argument: Relationships between Visit and Care Site:

  • Thus by definition, one visit may have only one care site (care site table) (1:1).
  • Care site is a unique combination of location_id and place_of_service_source_value
  • Location_id (location table) is street address.
  • place_of_service_source_value is sub-unit within that location_id or street address. (In a hospital these are the units or wards where beds are physically present. Eg. ER, ICU unit, med-surg beds, rehab beds)
  • Within the same location/ street address: place_of_service_source_value may have an arbitrary number of hierarchy to other place_of_service_source_value. e.g. NICU, CICU, SICU, cardiac rehabilitation unit may have a relationship with ICU. All have the same location_id but different place_of_service_source_value’s.
  • Given care_site_id = location_id + place_of_service_source_value; there is thus an arbitrary number of relationship between care_site_id’s.

Visits may thus be rolled-up or down - based on the hierarchy of place_of_service_source_value. e.g. An entire episode of care in a hospital at a given street address (location_id) may be

  • a single visit (if the whole hospital is one place_of_service_source_value), or
  • multiple visits, with multiple place_of_service_source_value such as ICU, ER, Step down unit, med-surg, rehab.

So a record in visit_occurrence table is actually mostly dependent on place_of_service_source_value? It’s not dependent on the actual service or procedure or condition or level of care or anything else. If we accept this argument to be true - then everything else becomes simple and all we have to do is represent the hierarchy between place_of_service_source_value. If we don’t accept this argument to be true - then we may have a fundamental problem.

Absolutely. It will take a big junk of the WG discussion on Friday. But we wanted to make as much progress that we can.

@Gowtham_Rao

That is one way to do it. It has a problem. The problem is that with care_site we are dependent on the definition of the claimant. A care_site as combination of location and place_of_service could be a big hospital system, or a single ward (department, floor), or even smaller. It also prevents us from really cobbling things together reliably like in @hripcsa’s example. Instead, on of those Vascular Surgery flloors would constitute a visit of their own.

The other ways to define Visits are:

  • Admission to Discharge
  • Location only (in one location usually is only one hospital

We may not get to a common definition, and it may be database-dependent. But we need to instruct the ETLers what we want to see.

And yes, we do have a fundamental problem. :slight_smile: Because we are trying to both standardize to a meaningful high level (Visit) and be true to the source (GOWTHAM, or whatever we are going to call it).

We are tracking again :smile:

This is the way we do it :slight_smile: and yes, that is dependent on place_of_service_source_value.

All of these different care_site because they have the same location_id but have different place_of_service_source_value’s :smile: And yes, you are correct

we overcome that problem by cross-walking place_of_service_source_value to place_of_service_concept_id during ETL time. This concept_id approach overcomes

by the way we decide to standardize place_of_service_concept_id during ETL, we can roll-up or roll-down a visit_occurrence.

Because place_of_service_source_value needs to be cross-walked to place_of_service_concept_id, and its up-to us to control the hierarchy of place_of_service_concept_id, and this hierarchy is what defines the granularity of the visit_occurrence

Note: I purposefully said _SOURCE_VALUE not _CONCEPT_ID in my previous post to draw this point. We control the process of standardizing the source_values by cross-walking them during ETL into concept_id. Its the place_of_service_concept_id that helps us standardize our definitions and allows us to do common analytics. If we have a good list of place_of_service_concept_id’s and a hierachy in it – then we may solve many use cases. So, we have to invest time to define many new OMOP standard place_of_service_concept_id’s very well along with its hierarchy.

Sounds like we are saying that we will use the new table to only store things that are hierarchically linked. If it doesn’t fit in the hierarchy, then it belongs in another table, either another new table or the observation table.

I am still not thrilled with sprinkling columns everywhere. Any way to reuse the current column? It either points to the visit or the encounter. No need to point to both because they are hierarchical.

George

@hripcsa - not fully understanding @Christian_Reich proposal of adding columns to the events tables (procedure, condition, device etc) - i dont know if this is a good or bad idea. We will have to see the proposal in detail and why it is needed.

Regarding hierarchically linked - by using the place_of_service_source_value and place_of_service_concept_id approach we could accommodate non-hiearchial too

I think the word “service” is confusing us. Is service a verb or a noun in this case? A Medical-ICU is a noun for a location in the hospital, but we also use it to describe ICU services (verb) like ventilation with continuous BP monitoring and support etc.

The place_of_service_source_value represents the noun and not the verb.

I think you guys are supporting the location version of services but that the verb version is not included because it is not hierarchical (does not fit Christian’s figure).

George

@Gowtham_Rao, @hripcsa:

Just got scolded by the Forum website:

Let others join the conversation
This topic is clearly important to you – you’ve posted more than 28% of the replies here.
Are you sure you’re providing adequate time for other people to share their points of view, too?

So, this is the last one before I shut up. :smile:

@Gowtham_Rao: I got what you are doing. You want to do the level transformation during the mapping from source_value to source_concept. We can do that. However, I was thinking we doing the level transition when we go from NEWTABLE (no longer abusing your name) to VISIT. Becasue there we can do it officially, and not hidden in some ETL. NEWTABLE would contain place_of_service logic the way it came in with the data.

@hripcsa: We could drop the duplicate links, and only link to NEWTABLE. No longer to VISIT. And then we could link from NEWTABLE to VISIT. The consequences would be on more join, and a backward incompatibility. But I could be convinced.

@hripcsa: Why can’t a service (like a physician’s organization’s claim) not be a descendant of a location+service? Why can’t Psych Councils not be the descendant of Psychiatry (which implies a location - the loony bin)? It’s a conceptutal descendency. It means, Psych Council (=Service) and Psychiatric Ward (Service+Location) share the Service aspects, but only one has a location where we assume the patient is lying in bed. It’s not a actual dependency. The Resident in the Psych Ward doesn’t have to be the one who is doing the Councils. Do I make sense at all?

Maybe. After reading and re-reading, I re-wrote the proposal proposal.

Friends:

The discussion has continued on email, which is a bad no-no! :smiley:

Here is the back and forth:

Has anyone started DDLs or ETLs for this now that it is accepted? If not, we will start soon.

1 Like

Hi @daniellameeker,

As far as I can tell no one has started on the DDL for the VISIT_DETAIL table or for the changes that need to be made to the VISIT_OCCURRENCE table. If you would like to start please create a pull request on the github and Christian/Patrick/I will review and pull it in when we are ready to release v5.3.

Clair

hi that pull request https://github.com/OHDSI/CommonDataModel/pull/114
provides visit_details DDL for postgres and various improvements.

However, it has not yet been reviewed

t