OHDSI Home | Forums | Wiki | Github

CDM person record not structured to capture patient mobility

CDM Builders
#1

The structure of the CDM does not appear to support capturing where a patient lives over time. That is, a person has a location_id that captures their place of residence, but this would presumably only be their most current one, and there does not appear to be a mechanism to capture changes of address.

Physical location of a patient can be important for addressing important biases, and can be useful in geotemporal modeling. For example, I have seen that there are biases in the CCAE data, such as less diagnoses of certain mental disorders per capita in counties with lower income (determined by joining FIPS codes with census data). Changes in environmental exposures over time also cannot be studied within the CDM framework.

There is a mechanism for capturing location for every patient visit, but in examining CCAE data, the county of care is often different from county of residence (even different states).

I know that the Veteran’s Health Administration patient database has a history of all past addresses, though it does include in the patient record a link to the current address.

In designing the CDM, has this issue ever come up?

One potential solution could be to have an additional table containing the following fields: person_id, location_id, residence_start_date, and residence_end_date.

Thanks,
Christophe Lambert

Person location over time?
#2

Good point, I agree this may be useful, the change in a person’s location (changing zip) if used some predictive models to assess things like readmission risk.
L

Lisa Schilling, MD, MSPH
Associate Professor of Medicine
ph 303- 724-5138 (COHO)
ph 303- 724- 2254 (General Internal Medicine)

Department of Medicine
Mail Stop- B180, Building AO1
12631 E. 17th Ave, Room 8219
Auora, CO 80045

[Description: http://www.ucdenver.edu/about/departments/oiuc/brand/downloads/branddownloads/branddocuments/E-mail%20Signatures/emailSig_Anschutz.png]

#3

Yes this has come up in prior cdm discusssions, but most data holders said
they only had ‘current location’ information (if anything), and we didn’t
want to infer ‘length of residence’ if there was no data to support. So
instead, to your analysis use case, you’d make the assumption that a
person’s location is stable for their observation period. While that’s
clearly not always true, it’s likely mostly correct for the majority of
patients in the majority of our data sources. In a private payer dataset,
if you move a large geographic distance (maybe taking a new job), then
there’s a good chance you have a new insurance payer and your observation
period would be truncated. If you’re a patient in a regional health system
like columbia or regenstrief, then if you move a large distance, you’d be
lost to follow up as well. I’m not sure if anyone in the community has a
large amount of transient patients with large coverage of observation time
across each geography? Maybe va or cms medicare?

In either case, it seems your analysis of geographically defined
environmental factors over time can be done in cdm, under the assumption of
stable location, and it’d just be a limitation to recognize that the
location may be subject to some transient misclassification. If your
environmental factors were very specific (more granular than 3 digit zip),
then I suppose small geographic movements (like between neighboring towns)
may have a larger impact.

#4

Agreed. We’re dealing with a lot of cancer data which includes historic location information.

I think we would have to reverse the association between location and person to enable person id on each location records as well as add location concept ids. This, of course would cause issues with care site, which shares the same location table.

Bill

#5

I am working with the CMS max data set. The patient demographic information is repeated in each yearly file. I was thinking to associate the person’s yearly location information with an observation period ( obs period type = 44814724 - period covering healthcare encounters or 45890994 - Period of complete data capture based on geographic isolation ). Basically, create an observation period for each year/patient and then associate it with the location ID with a fact relationship between the observation period and the location.

#6

Hi @Richard_Starr, my two cents: even though the raw data comes in yearly
files, I would not recommend keeping them that way. Instead, I would
contacenate the adjacent years to create observation period records for
person that span the entire duration that you have data. Observation
periods are used in all of the standard OHDSI tools to define the period of
time you can look forward and back for a given individual to define
healthcare activities, and so preserving that continuity will be important
to getting the most out of your data. Here’s link to the
OBSERVATION_PERIOD table spec for most context:
http://www.ohdsi.org/web/wiki/doku.php?id=documentation:cdm:observation_period.
Note, this will mean you will need to make decisions about how to
identify the person-level demographic information (e.g. gender, year of
birth, current location), which can be different across the yearly
enrollment records. The Truven and Optum ETL examples are are out on
github may be useful perspective about how others have tackled this in
other claims databases:
https://github.com/OHDSI/ETL-CDMBuilder/tree/master/man.

t