OHDSI Home | Forums | Wiki | Github

'Follow up' concepts usage in CDM


(Oleg Zhuk) #1

Hello, everyone.

I need to hear some thoughts from the community on the mapping of events follow-up.

According to Merriam-webster, follow up is a maintenance of contact with or reexamination of a person (such as a patient) especially following treatment, in CDM we usually consider follow up a visit. But SNOMED offers us a lot of concepts like 4198115 Retinopathy follow up, 4214589 Asthma follow-up, etc.

Is there any place for them in CDM?

Currently we map follow-ups to the history of event as it comes from event-related source tables. Should we also duplicate information in the Observation table as 4147571 Follow-up + event in value or with help of concepts I showed above?

Thanks a lot!


(Christian Reich) #2

@zhuk

We define the period where we observe a patient in the OBSERVATION_PERIOD: A Concept about that same fact is not very useful. That would be like having an OBSERVATION record about a Drug Exposure where the OBSERVATION_CONCEPT_ID contains a Concept called “Drug Exposure”.

What does the source say about that follow up? Can you just add the time to Observation Period?


(Oleg Zhuk) #3

All concepts come from the table with meaningful description: ‘all diagnosis, signs, symptoms and reasons for consultation’

Examples include: Follow-up of arterial hypertension, Follow-up of ischemic heart disease, Follow-up Sleep Apnea Syndrome, etc.

It is possible to include concepts in Observation table like 4147571 Follow-up + ‘EVENT’ or just 4198115 Retinopathy follow up for example and that will lead to extending of Observation period.

Should we also create visits for them?

Thanks for the reply


(Melanie Philofsky) #4

Hi @zhuk,

I was just looking at some billing “visit” concepts coming from EHR Billing tables, two separate data sources, same EHR system. Anyways, these CPT4/HCPCS codes originate from a Provider-Person “visit”. They are used by the Provider’s institution to get paid. These data sources also have finer granularity for Visits which include start datetimes, Location, Care Site, Provider, etc. So, we don’t use these billing visit codes to create a record in the Visit table. I mention all this because it is similar to your

examples.

Based on this:

“reasons for consultation” make me think this is the same situation as the data I am analyzing. It’s what I refer to as a “billing visit”. Perhaps the Condition is in a source diagnosis table? And the Visit is in a source visit/encounter table? If you have the Visit record and the Condition record, do you really need another record in the Observation table?

Well, if the Person had a Visit, then it is appropriate to extend the Observation Period because the Person was observed. However, if these are scheduled or future Visits and this is the reason for the future Visit, then don’t add it.

I’d take a few of the Persons with these source codes and look at all their data on the same day as the follow-up code. This should give you a clue to the real meaning of the data and/or it may lead you down a rabbit hole with all sorts of discoveries :slight_smile:

Here are a few of my billing visit codes I referenced above: 97760 (may be present multiple times for one visit because it is billed in 15 minute increments), G0390, 99223, 99291, 94799, 99215, G0463. They have domain_id = Procedure and Observation.


(Kristin Kostka, MPH) #5

Not that anyone really asked my opinion BUT for epidemiology nerds what Melanie says is a non-trivial statement.

If you were to catalog “future visit” observations, you now are misclassifying the observed person time for these patients. This has downstream implications on any analysis you do on these data. The presence of a future appointment should not be logged as a real visit. We cannot assume that they a) live to their next visit or b) continuing to see this provider long enough to follow through with this visit.

This is a new twist on immortal person time. :jack_o_lantern: Spooooooky.


t