OHDSI Home | Forums | Wiki | Github

Handling Patient linkage in CDM 6.0

Implementers
#1

We are working with EHR data, where one patient can visit multiple care sites and each care site maintains his record as a different patient ID.

We also have a linkage table that indicates this linkage information.

So, in our data-set each patient has multiple care sites and his records are specific to that care site.

My first question is, how do I map this patient in PERSON table? As according to wiki and Themis discussion there can be only one unique record per patient.

My second question is, Since he visits multiple care sites which one should I choose as CARE_SITE_ID?

Can someone help me with this? How do you handle this in case of your data-set?

#2

You should merge the multiple person ids into a single person prior to adding that person to the OMOP CDM. As for the care_site_id in the person table, just pick one from the possible set. You can be specific about the care site in the visit occurrence table.

2 Likes
#3

Thanks @DTorok for your help! This answers my questions.

#4

Question in follow-up to this one.
We are working with a very large (4M+ unique individuals) dataset, but there are ~250 sources for this population with multiple source-Medical Record Number pairs.
We use a master person index and maintain it daily. Identities (not many, but some) are merged and split every day. Thus an entry in the CDM could move from one individual to another.
Your suggested approach of resolving all identities and then loading the CDM seems impractical since we would need to update all new identities every day, and it’s not clear to me how a merge or split could be handled.
Our plan had been to load source/MRN pairs to the CDM, acknowledging that it would create multiple copies of the same individuals, and then maintain the eMPI list to resolve identities as a final step in any analysis. This, it seems, would render use of the Atlas and other out-of-the-box tools useless.

What is the best way to solve this problem?
Thanks in advance-- this is a crucial rate-limiting step to use of OHDSI by health information exchanges.
Cheers,
DK

#5

Are you creating an OMOP CDM instance every day? People typically don’t do that, because population-level research doesn’t need that - the resulting stats will not change much on a day-to-day basis. And OMOP is not built for individual patient care.

Not a good idea. All methods rely on the fact that the data are patient-centric. When you declare the cohorts you say things like “give me all patients that have …”. That only works if you can join the various tables by a common patient ID. You do not want to do that at the end.

What are you trying to achieve? What’s your use case?

#6

Our use case is somewhere in the middle. OMOP helps us to structure many different sources of data in a standard way, and the vocabulary helps with deduplication. Our use case is not-quite real time analytics like clinical quality measures and daily population health dashboards. Ideally we could get to the point of daily updates to the OMOP model.

As I reflect on it, perhaps the best approach would be to flag all identities that change and for merges, simply update the person table with the merged identity. For splits, the task is harder. In the case of splits we would

  1. determine which sources go with each of the split identities,
  2. find the identity to be split,
  3. create the new identities for each split,
  4. find all entries in other tables tied to the original identity,
  5. find all entries tied to the original identity and each of the sources and map to the appropriate new identity.

Is this possible (let alone practical) in the OMOP structure?

#7

That’s exactly right. You’d have to write a script “Follow the patient into the past”, and run it after mergers or splits, to attach the right clinical events to the correct Person. It’s not that bad and has been done before. Unless you merge and split large amounts every day. Which I don’t think is likely.

#8

Thanks for the response-- can you point me to someone or some group who has done this in the past?

t