New table for visits, encounters, care transitions

[Christian_Reich]

@Gowtham_Rao:

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

[Gowtham_Rao]

How do you suggest we do that?

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?

[Gowtham_Rao]

So if I want to link a procedure to the medical service the patient was on and to the location the patient was in at the time, I would have to pick one or the other to represent.

That one I am not sure. Because the raw data usually give us one such link, even if it could give us more. At least in claims (@Gowtham_Rao, true?) In HL/7 we could have a many to many, I agree.

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

1013774 Home Services CPT4 CPT4 Hierarchy
1013775 New Patient Home Services CPT4 CPT4 Hierarchy
ET Emergency services HCPCS HCPCS Modifier
G0108 Diabetes outpatient self-management training services, individual, per 30 minutes HCPCS HCPCS

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

So if I want to link a procedure to the medical service the patient was on and to the location the patient was in at the time, I would have to pick one or the other to represent.

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.

[Christian_Reich]

@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.

If we want to call these services
…
and they dont fit in observation table - then we need a new domain called Service.

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).

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.

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.

[hripcsa (George Hripcsak)]

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

[Christian_Reich]

@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.

[hripcsa (George Hripcsak)]

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

[Gowtham_Rao]

@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.

[Christian_Reich]

Perhaps best to talk in person.

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

[Christian_Reich]

@Gowtham_Rao

@Gowtham_Rao

he unit of representation or record in visit_occurrence is thus a unique combination of person + care_site + continuous care time-span.

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. 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).

[Gowtham_Rao]

We are tracking again

@Gowtham_Rao

The unit of representation or record in visit_occurrence is thus a unique combination of person + care_site + continuous care time-span.

@Christian_Reich

That is one way to do it. It has a problem.

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

@hripcsa

They go to the emergency department
, then 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.

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

@Christian_Reich

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.

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

@Christian_Reich

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.

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.

[hripcsa (George Hripcsak)]

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

[Gowtham_Rao]

@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.

[hripcsa (George Hripcsak)]

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

[Christian_Reich]

@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.

@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?

[Gowtham_Rao]

Do I make sense at all?

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

[Christian_Reich]

Friends:

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

Here is the back and forth:

@Christian_Reich

@Gowtham_Rao, @MPhilofsky: Do you have any progress or results? Do you to get the work organized and maybe call for a subgroup?

@Gowtham_Rao

Here is my recollection of the f2f:

Basically every encounter has a location id, place Id, care site id, place of service type id, specialty type id, intensity amount or administrative service rendering the care. Location id and care site id already exist. Place Id is new, to represent an individual room in a hospital that we discussed. We tried to clarify the ambiguity around place of service.

We all agreed that it is not OHDSI role to standardize “place” eg. Create concept of with hierarchy for Room, on a floor, in a wing, in a building. If we need to represent place then we need a new place table, for places within a street address. Location_id would be street address. Place_id would be subunit within location_id. Combination of location_id and place_id is care_site_id.

We did agree that “service” is being also being used ambiguously as a label for an administrative team eg oncology service, nephrology service. A nephrology clinic is a labeled administrative group in a hospital. So a “service” is being used for a labeled administrative group. In nephrology administrative group, a primary care specialist may practice and provide primary care. The actual care although strongly correlated to administrative service may be independent. The actual care may be deduced from diagnosis or procedure codes. If we want to capture “service” then we will need a new field called service to represent administrative units. We did not discuss if service needs to be standardized into a concept id or do we just create a service table with service_id?.

We did not talk about intensity of care e.g. RVUs.

We did say that representing hierarchy is very difficult.

@MPhilofsky

We are so close to nailing this down!

I just reviewed the wiki page for encounters. Is the place id you mention below the equivalent to encounter id on the wiki page? And what is the vocabulary that will represent the concepts in encounter_concept_id?

Regarding “service”, we would like to distinguish between ICU level care/general acute care/rehab/etc. Is there a way to represent it in your encounter_occurrence table? Transitions in care have been shown to have negative outcomes for patients. An investigator wants to know which persons were admitted to a general acute care floor and were subsequently transferred to an ICU level of care within 6 hours. What are the common attributes among the transferred patients? How can the current guidelines be improved upon? A diagnosis or procedure code won’t accurately represent this.

@Gowtham_Rao

http://www.ohdsi.org/web/wiki/doku.php?id=documentation:next_cdm:visits_microvisits

i really like visit_occurrence and visit_occurrence_era - we drop encounter_* name

– visit_occurrence would be our proposed encounter_occurence table
– visit_occurrence_era will be our current visit_occurrence table.

Regarding - “what are your thoughts on the intensity of care/acuity of care field, vocabulary, and domain?” if the question is how to solve for representing that as a separate domain
– we need new table by domain, e.g. we will need a 'intensity" domain with intensity_occurrence table.
– introducing a new table or a new domain is a major change to OMOP – and what I learnt at F2F is this a big consensus building exercise in the community. i.e. its a lot of thinking, vetting, etc
– we will need to create a workgroup and clearly outline the use-cases and clearly articulate the problems we are trying to solve. We have describe the problem to the community. I dont think we have done that yet.
– Then, we will need to defend as to why current tables/fields cannot solve this problem. e.g. why cant intensity of care be represented in OBSERVATION table?

@MPhilofsky

Thanks for pointing me in the correct direction!

We need to represent individual units within a location, per your email, this is the place id and is part of location_id. Care_site and Place_of_service are too generic for EHR data and the requests we receive for healthcare data. I think we should we replace the location_id field with place_id in our new visit_occurrence table. This would provide the most accurate representation of the data within the proposed table since it directly relates to preceding_visit_occurrence_id, visit_start_datetime, visit_end_datetime, provider_id. Also, procedure_id, drug_exposure, etc. would link to the place_id. I agree with your comments regarding “place” below and place_id would not be a standard concept. Each data holder would need to create their own hierarchies for Place. Would Place require a new table? Or would the community use the Fact_Relationship table?

Should the admitting_source_concept_id and discharge_source_concept_id fields be a part of the proposed visit_occurrence table? They are already part of the proposed visit_occurrence_era table.

Gowtham wrote: “Basically every encounter has a location id, place Id, care site id, place of service type id, specialty type id, intensity amount or administrative service rendering the care. Location id and care site id already exist. Place Id is new, to represent an individual room in a hospital that we discussed. We tried to clarify the ambiguity around place of service.”

“We all agreed that it is not OHDSI role to standardize “place” eg. Create concept of with hierarchy for Room, on a floor, in a wing, in a building. If we need to represent place then we need a new place table, for places within a street address. Location_id would be street address. Place_id would be subunit within location_id. Combination of location_id and place_id is care_site_id.”

@Gowtham_Rao

Ooh good. I think what I am hearing is that the three hour arbitration about place at F2F was not a waste of everyone’s time. (I stood up on the stage and led that discussion - and felt very bad, that I might have wasted people’s time). Lol

So we have an agreement that the requirement may be met by a ID and we don’t need “concept id”.? I agree.

If yes, some rules to consider for next steps: we need to wordsmith “place”. We don’t want to propose new tables, we want to see how we can leverage current tables. Can we leverage care_site and location tables? Melanie – I think we can leverage care_site table to capture the place need…I.e we don’t need a new place table. I think we could use fact-relationship for the hierarchy among care site… which essentially solves the place problem… what do u think?

@MPhilofsky

I don’t think acuity of care needs a separate table. It would fit in nicely with visit_occurrence. It just needs a vocabulary to represent the concepts.

Which field will represent the different units (ER, ICU, Rehab) within a hospital?

@Gowtham_Rao

We talked about this for about three hours at the f2f. Is ER, ICU, Rehab – a concept id or just an idea?

If concept id then one vocabulary is place_of_service_concept_id in Care_site table. The only standard concept id is hipaa place of service. This limits your options. We don’t have a place_of_service_source_concept_id.

If just id-- then you have care_site_source_value and care_site_id. Id just represent a name in integer form.

@Christian_Reich

Mightn’t the bad outcomes for transfer be a biased artifact: Patients who don’t do well get transferred, not the other way around?

@MPhilofsky

Exactly! So, those patients should have been placed in a high acuity ward instead of a general floor ward. What are the common attributes of those that require transfer to a higher level acuity shortly after becoming an inpatient? I’ve searched all around looking for a vocabulary to represent this. I thought there would be a billing code system to represent this data, but the code systems our friends on the forum suggested don’t cover it. I’m guessing the concept_relationship table is the way to represent this data. Or just use sql. Once our data is in OMOP, the sql queries won’t be so bad.

@Christian_Reich

I know what you want. But knowing the hospital system from inside you will hardly find a acuity or severity attribute. It really depends on the local habits, the direction set by the chief, and the (invisible) division of labor between wards in a hospital. Smaller rural places do everything (even ICU) in the internal medicine ward. Now what?

We need to figure out something else.

@Christian_Reich

Couple of thoughts about the proposal:

2. Current VISIT_OCCURRENCE: We are stating in the proposal that they currently are used as aggregates (macro-visits, rather than micro-visits). Turns out, folks assumptions are all over the place. I just had a review in our own shop for PharMetrics Plus (commercial claims, mostly Blues), and the team created micro-visits. Reason is that they have more than one place_of_service, so they cut them up accordingly.
3. Renaming tables is a biggie. Gowtham already pointed that out. But because of 2) we may get away with it. In a way, we only now really define what VISIT_OCCURRENCE really means. Still, it will be stress for folks who use it to find hospitalizations (Melanie’s severity purpose).
4. BTW: The Place of Service can be inferred from other information (Procedures, Revenue Codes), and folks do that already for ER Visits. We should help them and publish common heuristics.
5. “Multiple visits must be related to each other. We can represent that in visit_occurrence and visit_occurrence_era using chaining/sequential method or parent-child/part-of” – Interestingly, we don’t do that in current ERA tables. We should do that. But not through the FACT_RELATIONSHIP_TABLE, but a direct field (e.g. contained_in_visit_era_id or so). Or is that the idea of the primary_visit_occurrence_era_id? It’s not clear right now.
6. The whole summary/detail business: Why do we need it? That is a claims artifact, and for EHR folks totally absurd. Why do we need to retain that?
7. Provider_id: Not sure what we do with this: Because there could be more than one provider in a visit, even a microvisit. The initial idea was to have a main provider per visit, like the treating resident, or something. But I am not sure it works. Thoughts?
8. PLACE and CARE_SITE: Not sure we need to duplicate that. What’s the difference again? One for microvisits, the other one for macrovisits?
9. Why do we need both admitting and discharge_to? One is enough for chaining, isn’t it?
10. We should probably also think of an improved Place of Service list. Something that truly represents the reality, not the CMS funny version. Is that HL/7? Will that work internationally?

Will probably have more ideas.

[daniellameeker]

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

[clairblacketer]

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

[parisni]

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