New table for visits, encounters, care transitions

[MPhilofsky (Melanie Philofsky)]

I have volunteered to organize the proposal for visits, encounters, care transitions, etc. under @Christian_Reich’s guidance. He suggested I gather all the interested parties and pertinent use cases, lead a discussion, put together a proposal based on our use cases, create a wiki, and then present it to the CDM WG.

Our users request ADT data, specifically length of stay in a certain location (ward/unit) within the hospital, procedures that happen within a location within the hospital, and transfers between levels of care with the inpatient stay.

The only addition we would need for our use case to the PEDSnet table below would be the addition of an adt_occurrence_id FK to the PROCEDURE_OCCURRENCE table. This would allow us to link procedures to specific locations within the hospital.

These are the PEDSNet conventions for the above table. The conventions include an extension of the vocabulary to further define service_type and adt_type.

service_concept_id

select * from concept where vocabulary_id =‘PEDSnet’ and concept_class_id=‘Service Type’ and standard_concept=‘S’ yields 14 valid concept_ids.
In PEDSnet CDM v2.5, only the NICU,CICU and PICU services are included.
The value set available for PEDSnet includes:
• CICU (cardiac care) = 2000000079
• NICU (neonatal care) = 2000000080
• PICU (all other ICU) = 2000000078
• Critical care = 2000000067
• Intermediate care = 2000000068
• Acute care = 2000000069
• Observation care = 2000000070
• Surgical site (includes OR, ASC) = 2000000071
• Procedural service = 2000000072
• Behavioral health = 2000000073
• Rehabilitative service (includes PT, OT, ST) = 2000000074
• Specialty service = 2000000075
• Radiology = 2000000076
• Hospital Outpatient = 2000000077
li>Unknown: concept_id = 44814653
• Other: concept_id = 44814649
No information: concept_id = 44814650

adt_type_concept_id:

select * from concept where vocabulary_id =‘PEDSnet’ and concept_class_id=‘ADT Event Type’ yields 5 valid concept_ids.
The value set for PEDSnet includes:
• Admission = 2000000083
• Discharge = 2000000084
Transfer in = 2000000085
• Transfer out = 2000000086
Census = 2000000087

What are the other use cases? What is missing from the above? Who else is interested? Let’s get a proposal put together!

Melanie

Adding @bailey, @burrowse, @jenniferduryea, @Gowtham_Rao, @mgkahn

[Patrick_Ryan]

My two cents: I would prefer to see us develop one solution that meets
multiple use cases, rather than having different solutions for each use
case. If I’m reading this correctly, this PEDSnet table appears to be
specifically about capturing the movement of a patient within a facility,
which are basically subactivities within a VISIT_OCCURRENCE (as defined in
OMOP CDM). (so it’s really the T , not the A or the D in ADT).
Jennifer and Gowtham have been talking about something different, but
related, which is their desire to preserve claims-level referencing, which
effectively amounts to other types of subactivities within a
VISIT_OCCURRENCE record (note, a VISIT_OCCURRENCE is NOT a claims
encounter, as there are many claims encounters that roll up into one
inpatient admission). I understand there’s data in some source systems
about these subactivitiess, but I’m still not clear on the analytical use
cases for either case (what real research question are you currently facing
that can’t be answered with the current structure?)

What is the unit of observation we care about to support the specific
analytical use case that you have in mind? Is it the specific
interaction/encounter of a patient with an individual provider in a
specific care site? Or is the action of transitioning a person from one
location to another? Or something else?

[MPhilofsky (Melanie Philofsky)]

@Patrick_Ryan,

We want to know the outcomes associated with the level of care (ICU, Intermediate care, acute care), length of stay, and procedures performed on the patient within a specific location (unit,ward) within the hospital. This does also encompass the A (admit) as the first location a patient was in the inpatient setting of a VISIT_OCCURRENCE. Right now the VISIT_OCCURRENCE table only captures a high level for the care_site_id, 1 care_site_id for the entire inpatient stay, and not the levels of care a patient received.

(what real research question are you currently facing
that can’t be answered with the current structure?)

How long was the patient receiving CRRT (multi-day procedure) in the ICU? What was the patient’s total LOS in the ICU? Was the patient on another unit/ward before the ICU? What was the total LOS within the inpatient setting? What was the patient’s discharge disposition (home, death, long term care, etc.)?

What is the unit of observation we care about to support the specific
analytical use case that you have in mind?

The PEDSnet value set for service_concept_id is close to covering our current use cases. We have a few ICUs and investigators like to distinguish the different types of specialty care provided in each (Cardiac ICU, Medical ICU, etc.). The value set PEDSnet provides for adt_type_concept_id covers all our needs.

I would also like to only see one solution/additional table in the OMOP CDM. I would like @jenniferduryea and @Gowtham_Rao to chime in with their use cases. This may or may not solve the discussion here. It will create “micro-visits” as discussed. And other tables could be linked to the “micro-visits” created by this table through a FK placed in another table. Direct patient care is my native language and data modeling is my second language, so I may be off on how this all fits together.

[bailey (Charles Bailey)]

@Patrick_Ryan,

I’d also be in favor of a unified solution if we can find one. As might be evident from notes in our conventions, the first use case was identifying a) whether a patient required “ICU level care” (we have a couple studies that define that as “in the ICU” as distinct from a specific drug/procedure footprint) and b) what portion of an inpatient admission was in the ICU. So this is both a presence-of-patient and a duration-of-even question. Our second, for PCORnet, will be characterizing stays (parts of?) that are “observation level” (less sure of PCORnet’s application here). So this one is close to a visit-concept_id, assuming the patient doesn’t transition to acute care. Finally, we had one proposal come through that wanted to track ADT down to bed level to do infection surveillance, but we haven’t signed on to do that yet. That’s a what’s-your-address-when-the-culture-was-obtained use case, so the closest to the traditional definition of ADT. Generally, the questions have been more about a patient’s service level at a given time, and less about the transition itself. We’re not recording a lot of metadata about the transition event, but we’re using the A, 1 or more Ts, and the D as ends of adjacent segments.

After considering several alternatives, we eventually concluded that the solution needed to be separate from visit_occurrence for two reasons. First, on a semantic level, it felt more consistent to keep an inpatient admission together as one row, rather than a series of adjacent segments. Second, many of our use cases don’t require ADT-level detail, and we were worried about impact on performance and query overhead or merging the two levels in one table. That balance is almost surely different for different users, depending on typical queries; it’s just where we ended up based on our mix.

Regards,
Charlie

[Gowtham_Rao]

Friends – please give me a few days to think thru this. Been a little less active these days because of some pressings topics at work.

Gowtham

[Mark_Danese]

For what it is worth, I will describe how we handle this in our data model (which we then convert to OMOP or Sentinel as needed).

We have one table (Contexts) that we use group related items together. This can be a diagnosis code and a procedure code, a set of laboratory values, or data from an ICU stay, for example. This record id from the Contexts table is linked to each record in each table that shares the same context. This Contexts record also contains provenance about why the records are related (i.e., a type concept id in OMOP parlance) and the file from which they are taken.

Then we have another table where we collect these contexts (Collections). The Collections table allows us to combine contexts into inpatient stays, office visits, or, for billing data, claims. It would probably not be difficult to make this strictly a “visit” table if one were to combine claims data together as typically done in OMOP. (This would be combining facility and provider records in some rational way.)

I am not proposing this as the solution for OMOP v5. This is just an example illustrating a 2-level grouping of information which could be adapted to solve the problem. This can probably be done in a number of ways. It may require additional joins to work though, so it may not be completely backwards compatible. A different version where both levels of aggregation are in the visit_occurrence table might also work and avoid joins.

[Daniella_Meeker]

An analytic use-case for more granularity is detecting risks associated with handoffs. The broader use case is is attribution to a care team or provider. This is important for all performance and program eval use cases.

[Mark_Danese]

@Daniella_Meeker
Good point. We also use a contexts_providers table to allow multiple physicians to be associated with specific groups of records.

[Christian_Reich]

Friends:

Reading all this, and the other Forum Post, I think the underlying problem is this: We have a hierarchy of these visit-type entities. There is a nice example provided in the FHIR Encounter description example, which is copied in here:

As stated, Encounter allows a flexible nesting of Encounters using the partOf element. For example:

• A patient is admitted for two weeks (blue in the graph) - This could be modeled using a single Encounter instance, in which the start and length are given for the duration of the whole stay. The admitting doctor and the responsible doctor during the stay are specified using the Participant component.
• During the encounter, the patient moves from the admitting department to the Intensive Care unit and back (green) - Three more detailed additional Encounters can be created, one for each location in which the patient stayed. Each of these Encounters has a single location (twice the admitting department and once the Intensive Care unit) and one or more participants at that location. These Encounters may use the partOf relationship to indicate these movements occurred during the longer overarching Encounter.
• During the last part of the stay, the patient is visited by the members of the multi-disciplinary team that treated him for final evaluation (red P) - If relevant, for each of these short visits, an Encounter may be created with a single participant. Since these took place during the last part of the stay, the partOf element can be used to associate these short visits with either the third patient movement or the bigger overall encounter.

The following graph illustrates the situation:

In our lingo we call blue a visit, green a micro-visit or service, and red a single procedure or individual provider encounter. The ADT life cycle can happen at any of these levels.

To represent this, and to cover all the use cases, we have two choices:

1. We introduce three different explicit hierarchical levels, maybe called VISIT_OCCURRENCE (blue), SERVICE_OCCURRENCE (green) and INDIVIDUAL_ENCOUNTER (red). We can word smith these. Each of them has ADT datetimes and links to the next, if appropriate. And we have hierarchical links between the hierarchical levels. Procedure, Condition and Drug records can be linked to any of them.
2. We don’t create three distinct levels, but instead introduce one generic ENCOUNTER (again, word smithing encouraged) table. It will contain any of the hierarchies and you can have several of them in parallel for overlapping datetimes. We adopt the HL7’s partOf links to relate them to each other, as well as optional ADT links to each other. Procedure, Condition and Drug records can be linked to them according to the source data.
   The existing VISIT_OCCURRENCE we use for a kind of DRUG_ERA-style summary by cobbling together whatever we can make sense of in ENCOUNTER. A visit will then inherit all Procedure, Conditions and Drug records linked to the ENOUNTERS, which means, we have to have two parrallel links in those tables.The encounter_type_concept_id denotes what level it is (like @MPhilofsky’s list) , and the visit_type_concept_id contains the same Inpatient, Outpatient, ER and Long Term Care choices.

Both options are backwards compatible, but I like the second option a lot more: it allows to represent whatever partial or idiosyncratic data we find in the sources. Because it is not straightforward to assign blue, green and red to the claims or EMR data we get in reality. On the other hand, it might duplicate the information a little bit.

I’ll create a graph for both of them to make it easier to understand.

Does that work for people?

[Chris_Knoll]

Both options are backwards compatible, but I like the second option a lot more: it allows to represent whatever partial or idiosyncratic data we find in the sources.

I’m not sure how to provide standardized analyses when we allow the idiosyncrasies of the source data into the model. I like how you depicted the different elements in your picture, Christian, but i’m inclined to go the #1 route by introducing CDM concepts that we can all standardize our analytics on, and leave the idiosyncrasies of the data an ETL exercise to standardize it into the CDM form.

[Christian_Reich]

@Chris_Knoll:

You are right. If we could, that is. The problem is that we usually cannot. The way a claim comes in you can’t tell wether it came from a hospital, a department of a single provider (which color it is). Therefore, it is better to keep them as is (like we do in DRUG_EXPOSURE) and then figure out a standardized procedure to convert them. That will get us regular critique, but at the end of the day everybody uses it.

I’ll draw the options out. You’ll see they are not that terribly different.

[MPhilofsky (Melanie Philofsky)]

@Gowtham_Rao,

Have you had a chance to think through this more?

[MPhilofsky (Melanie Philofsky)]

Friends,

The discussion has dropped off, so I will continue with my opinion

I agree with @bailey:

@bailey

First, on a semantic level, it felt more consistent to keep an inpatient admission together as one row, rather than a series of adjacent segments. Second, many of our use cases don’t require ADT-level detail, and we were worried about impact on performance and query overhead or merging the two levels in one table.

Especially the impact on performance and query overheard if the ADT data is merged into the VISIT_OCCURRENCE table.

Let’s continue the conversation or fine tune this as a proposal on the wiki. I’d like to get this nailed down in the next week or so. The F2F is only a couple weeks away.

[Gowtham_Rao]

I think we as a community, need to first agree on some conventions (applicable when using claims data): I would like to propose a convention based on the questions “Whose point of view?”

Please see Google docs Please review, edit or offer comments. This point of view based approach, maybe generalize-able to US and non US settings

Matching to HL7 world: https://www.hl7.org/fhir/encounter.html#examples

Encounter = “An interaction between a patient and healthcare provider(s) for the purpose of providing healthcare service(s) or assessing the health status of a patient.” A patient encounter is further characterized by the setting in which it takes place. Among them are ambulatory, emergency, home health, inpatient and virtual encounters. An Encounter encompasses the lifecycle from pre-admission, the actual encounter (for ambulatory encounters), and admission, stay and discharge (for inpatient encounters). During the encounter the patient may move from practitioner to practitioner and location to location.

For example, each single visit of a practitioner during a hospitalization may lead to a new instance of Encounter, but depending on local practice and the systems involved, it may well be that this is aggregated to a single instance for a whole hospitalization.

We may need to word-smith the ideas in Google doc above to be as close to the descriptions in HL7. I think, as a community, agreeing on conventions is important - and this will help us represent the data with semantic accuracy while retaining lineage to source.

[Gowtham_Rao]

length of stay in a certain location (ward/unit) within the hospital, procedures that happen within a location within the hospital, and transfers between levels of care with the inpatient stay.

capturing the movement of a patient within a facility

I think this is tough to be sourced from claims data

My two cents: I would prefer to see us develop one solution that meets
multiple use cases, rather than having different solutions for each use
case.

Agree - we need to preserve claims level referencing.

What is the unit of observation

i.e. whose point of view? Claims will help answer some of the points of view as posted above.

@bailey @MPhilofsky Reading your use-cases, i think the unit of analysis is care_site (site of care) , where the care-site generally refers to the ‘level of care’ e.g. ICU vs step down.

After considering several alternatives, we eventually concluded that the solution needed to be separate from visit_occurrence for two reasons. First, on a semantic level, it felt more consistent to keep an inpatient admission together as one row, rather than a series of adjacent segments. Second, many of our use cases don’t require ADT-level detail, and we were worried about impact on performance and query overhead or merging the two levels in one table.

When representing data in OMOP common data model - I think it is critical to represent the data in a such a way that is semantically represents the source data and is at the same atomic level of granularity as the source data. This will retain lineage/provenance to the source 1:1. Any ‘inferred’ information should be done at the analytic time. If we represent inferred or calculated information in the OMOP CDM, then we are saying that information came from the source - which is not true.

@Mark_Danese - can we use the Contexts and Collections approach to derive visits, encounters, services as described above? @jenniferduryea this is an opportunity to be able to represent claims data accurately in OMOP CDM like @Patrick_Ryan said

In our lingo we call blue a visit, green a micro-visit or service, and red a single procedure or individual provider encounter.

The visit vs. micro-visit lingo may confuse some - what do you think about service, encounter, visit framework above using whose point of view? More word-smithing?

The way a claim comes in you can’t tell wether it came from a hospital, a department of a single provider (which color it is)

You can know the following:

• Facility claim vs professional claim atleast in USA by using UB04 vs CMS 1500 claim information or pharmacy/vision/dental claim etc.

@Gowtham_Rao,

Have you had a chance to think through this more?

• Other important things in claims are HIPAA place of service, Type of bill, revenue code, admit type that help define it further
  Yes finally!

Especially the impact on performance and query overheard if the ADT data is merged into the VISIT_OCCURRENCE table.

I think we should first agree on conventions, then find an efficient way to represent the data

[Mark_Danese]

Just to answer the question you directed at me. Yes, visits can be derived in the way we handle data. For EHR data, a Collection is a visit. For claims data, a Collection is a claim. If we need to count unique visits for a patient for some reason, we group items using specific rules related to the research question (e.g., using unique dates, places of service, and providers).

In fact, in my experience a uniquely defined visit is almost never needed in research. Usually, we want a specific clinical event – a diagnosis, procedure, drug, or lab – and the date it occurred. The notion of a visit in most data models is generally used as a convention to link information together.

I think the process begins with establishing what we are trying to do with visits.

[Gowtham_Rao]

Thanks @Mark_Danese

I think, if if i understand you correctly, your way allows flexibility to the community of ‘deriving’ the visit, encounter, service etc. based on rules defined by researcher at the analytics time rather than ETL time.

Is the collection/contexts something we an work more on?

[Mark_Danese]

If the community wants to go this direction, I am happy to help. We built our own data model so we could more easily convert raw data to OMOP and Sentinel. If you want to see how it all fits together, it is publicly available: GitHub - outcomesinsights/generalized_data_model: Outcomes Insights' Data Model for Clinical Research

Purely selfishly, the more similar the data models are, the easier my job is. But what we are doing is very specific to our needs and I recognize that OMOP has a fundamentally different goal. That is, OMOP is designed to be an “analysis ready” representation of the data. By definition, decisions related to analyses are baked into the data model. Otherwise it isn’t “analysis ready”.

[Gowtham_Rao]

@Mark_Danese

Purely selfishly, the more similar the data models are, the easier my job is. But what we are doing is very specific to our needs and I recognize that OMOP has a fundamentally different goal. That is, OMOP is designed to be an “analysis ready” representation of the data. By definition, decisions related to analyses are baked into the data model. Otherwise it isn’t “analysis ready”.

Our mission is to be able to do reproducible, collaborative, large scale research. We use a common data model to standardize the structure, content, representation of data. I don’t think that implies “analytics ready”. We have packages and tools that convert the data in CDM into analytics ready, but the CDM itself is not analytics ready. I don’t think our mission calls for baking in analytic use-cases into CDM so that those use cases are easier; what we do is, collaboratively understand multiple usecases and enhance the CDM such that multiple use cases maybe supported.

Atleast that’s my understanding. @Patrick_Ryan thoughts?

[Christian_Reich]

@Gowtham_Rao:

You are absuing @MPhilofsky’s thread to define visits and its hierarchy here for a general ideological discussion. I am going to move it to a new Forum posting, if you don’t mind. See you there.