OHDSI / Themis

Repository for OMOP CDM conventions as defined by THEMIS. These can be reference lists of concepts, pieces of standardized code for data generation or quality certification, and debates.
Apache License 2.0
27 stars 8 forks source link

Article on how to represent a person's medical history ('history of') #89

Open clairblacketer opened 3 years ago

clairblacketer commented 3 years ago

We need an article for the CDM website on how to handle a person's prior medical history. See this forum post for details and the conclusion reached.

dimshitc commented 3 years ago

Well, there's no ready solution on this: current approach is to use the postcoordinated expression of the observation concept indicating the domain of event, while the historical event goes into OBSERVATION.value_as_concept_id. The corresponing observation concepts: 4215685 Past history of procedure 4207283 History of drug therapy 4214956 History of clinical finding in subject

But people don't follow this strictly. The proposed approach is to create 1 OMOP Extension concept "Personal history of" that will be used as a universal Observation_concept_id regardless of a historical event domain.

clairblacketer commented 3 years ago

@dimshitc can we use the concept History of? It seems to fit the bill here.

Alexdavv commented 3 years ago

The only problem why this isn't working is the historical events that can't be pre-coordinated and require their own value, like Measurements, Drug Allergies, the Need for an immunization, etc.

@cgreich I think we discussed a couple of solutions:

Thoughts?

Alexdavv commented 3 years ago

@dimshitc can we use the concept History of? It seems to fit the bill here.

No. The qual value concept class doesn't imply an event. It should be normally in the Meas Value or some other new Modifier/Qualifier-like Domain.

dimshitc commented 3 years ago

The only problem why this isn't working is the historical events that can't be pre-coordinated and require their own value, like Measurements, Drug Allergies, the Need for an immunization, etc.

@cgreich I think we discussed a couple of solutions:

  • new historical table;
  • another way to store the dates in the past, like nullable dates or dates with modifiers.
  • history flag/modifier;
  • additional value field.

Thoughts?

This is the change of the model, thus hard to swallow pill. Now we have to come up with relatively simple solution (even with some limitations), people will use.

clairblacketer commented 3 years ago

The solution I see is this:

  1. Choose a concept that we want to use to mean "History of", whatever it is
  2. Use the fields OBSERVATION_EVENT_ID and OBSERVATION_EVENT_FIELD_CONCEPT_ID to link to the event the person has a history of. We already allow records that occur outside of an observation period so this seems like a natural extension
Alexdavv commented 3 years ago

This is the change of the model, thus hard to swallow pill.

Exactly. That's why we postponed the splitting task of the pre-coordinated SNOMED terms.

Alexdavv commented 3 years ago

2. OBSERVATION_EVENT_ID and OBSERVATION_EVENT_FIELD_CONCEPT_ID

Do we have them in 5.4? In 5.3.1 we don't. And can you please share the actual descriptions/conventions on these fields?

2. to link to the event the person has a history of.

Didn't really understand what we're linking. The whole point is we can't record the histories as independent events since we don't know the actual dates. That's why we move them to the value_as_concept_id field of the same Observation record that captures the "Personal history of" event.

clairblacketer commented 3 years ago

Ok let's hold off on this one for now. Once we are done with v5.4 we will have a combination session with the vocabulary group about conventions

cgreich commented 3 years ago

Well, the convention really is independent from 5.4, unless we want to change the model. That will take time. So, let's put down what we already have.

We have the problem of which concept indicates history of, and two solve storage problems:

  1. The approximate timing of the event (in the past, a year in the past, 10 years in the past)
  2. Post-coordinated extra values (e.g. Measurement results)

The current and simple solution is to drop either. I.e., if we know the rough timing, ignore it (history of = any time before the recording), and if we have a post-coordinated pair ignore it.

So, let's write that down this as the convention as of today.

Alexdavv commented 3 years ago

if we know the rough timing, ignore it (history of = any time before the recording)

Actually, we already have a way to address this a bit: https://forums.ohdsi.org/t/history-of-condition-with-age/11470/18

Now we just need to come up with the branch of insensitive to the event type ones.

cgreich commented 3 years ago

We still need to write the convention article. And since this wasn't officially released we need to write the article the way it is now, and then write an update.

Alexdavv commented 3 years ago

Alright. But first we create this “one single history” concept branch and then document it? Or another way around?

clairblacketer commented 1 year ago

The answer we came to is located here: https://forums.ohdsi.org/t/family-history-extension-model/17947/5

This just needs to be officially documented.

clairblacketer commented 5 months ago

I am moving this to Themis, I think this is still in flux.

Alexdavv commented 5 months ago

Hi @clairblacketer We went in detail through the personal history use case, and finalized it in vocabularies.

The answer we came to is located here: https://forums.ohdsi.org/t/family-history-extension-model/17947/5

The discussion here is mostly about the family history. I think we don't have a decision yet since there are options how to pre-coordinate. Also, it was de-prioritized in vocabulary work, so for some time we stay with what SNOMED gives us.