OHDSI Home | Forums | Wiki | Github

How to represent family history

Vocabulary Users
#1

I’m wondering if there is an established best practice for representing family history in the observation table. I can see two options that are both supported by standard concepts:

Based on a previous discussion I’m thinking Option 1 might make more sense? It’s certainly more flexible. Our data sources differ on which representation is used so we will need to do mapping from one to the other if we want to keep our cohort definitions consistent.

Additionally, it doesn’t seem obvious how we could specify the relationship of the family member in the observation record.

Using qualifier for added granularity?
Representing laterality + general questions about post-coordination
#2

Yes, Option 1 makes sense,
We actually make this kind of mappings for ICD10CM. Take a look on Z82.5 code, going through concept_relationship you’ll find Maps to “Family history of clinical finding” and Maps to value “Asthma” which will be interpreted during CDM conversion as Observation_concept_id and value_as_concept_id.

Hm. for me too:|
@IYabbarova, did you have such a cases?

#3

@Dymshyts and @rtmill:

I don’t think we have that. A good subject for THEMIS.

#4

Our clinical trials data specify even which parent has which cancer so I vote for option 1 and I would further extend it with

qualifier_concept_id = http://snomed.info/id/9947008

(biological father) concept.

(btw, it was a struggle to smuggle “value_as_concept2” into the CDM few years back. (aka. qualifier_“cid”). Here is another use case for it.

@Christian_Reich: I am hoping that in 2019, we would ingest more SNOMED CT content into OMOP Vocabulary. (not just findings and procedures)

image.png899×532 20.1 KB

#5

@Vojtech_Huser I like the idea of using the qualifier.

SNOMED also provides more specific concepts for events by relationship type but I’m not sure how well they would roll up.

e.g.

image.png880×41 2.98 KB

Survey response capture - Multiple choices as answer
#6

@rtmill, well, they have the whole list here:

so one of these is observation_concept_id and, let’s say, “cancer” will be value_as_concept_id, correct?

seems to be a good idea. But on the other hand it’s not very obvious for analysts to find these.

#7

We can write into the conventions. Perfect place for THEMIS. But: I don’t think this analytical use case is very typical. If you want to study inheritability of disease, you need stronger data than those glibly collected “family histories”. My opinion. Wasn’t there the study at Columbia where they actually took real EMR records from family members they pulled from the emergency contact information? That’s better.

#8

So somebody might want to indicate that person_1 is a parent of person_2,
and as I understand such things we put in fact_relationship table. But I don’t see any kind of such relationships existing in a concept table

#9

Currently here is the recommendation:

RECOMMENDATION
If we have a matching concept in SNOMED, then use the respective observation_ concept_id. If we do NOT have a matching SNOMED code, then observation_concept_id should be ‘4210989 Family history with explicit context’ and value_as_concept_id should be the related procedure, condition etc.

ACTION
Add as a convention under the OBSERVATION page.
There is no connection from the disease to the “family history of”. Check that all relationships exist. If they do not, then talk to SNOMED. Next step is to add SNOMED extension

I do want to bring up the WIKI has this on it:

Note that the value of value_as_concept_id may be provided through mapping from a source Concept which contains the content of the Observation. In those situations, the CONCEPT_RELATIONSHIP table in addition to the “Maps to” record contains a second record with the relationship_id set to “Maps to value”. For example, ICD9CM V17.5 concept_id 44828510 “Family history of asthma” has a “Maps to” relationship to 4167217 “Family history of clinical finding” as well as a “Maps to value” record to 317009 “Asthma”.

@aostropolets, we would still do this when we have an mapped OBSERVATION_CONCEPT_ID?

1 Like
#10

@ericaVoss: We’d have to create the definitive list of

a) pre-coordinated histories
b) split up histories.

Can’t be that many. There is is no such a thing as “History of ingrown toenail”. Only high-level diseases that have an impact on family life will get into this list. @Dymshyts: Do you have that list?

#11

Sure, we have a list of precoordinated histories - not hard to get. List of split ups: everything that have use cases ( that people consider to be important and cannot find in SNOMED). I’m as a initiator if the approach made a call for them on Themis F2F but haven’t got any so far.
@ericaVoss mmm, didn’t get the question. Could you try again? :slight_smile:

#12

@ericaVoss @Christian_Reich @aostropolets
I used following concept_id lists for the family history in observation table for converting results from national survey
(we released this in github . I’m sorry it’s in Korean…)

  1. Family history of liver disease
    -Yes: 4144266
  2. Family history of hypertension
    -Yes: 4050816
    -No: 4053372
  3. Family history of stroke
    -Yes: 4169009
    -No: 4175587
  4. Family history of heart disease
    -Yes: 4173498
    -No: 4050792
  5. Family history of diabetes
    -Yes: 4051114
    -No: 4051106
  6. Family history of cancer
    -Yes: 4171594
    -No: 4051100
#13

@SCYou and you’ve never experience need in other concepts, right?

#14

I’m glad to see this is being addressed. I’d like to advocate against defaulting to SNOMED’s “family history of X” concepts at all and simply stick to the latter format (‘family history with explicit context’ + value_as_concept_id).

This subset of SNOMED concepts is much less comprehensive than we have available in the condition domain. While the “family history of X” concepts are hierarchical (though I don’t see the relationships in ATHENA), the number of concepts are far fewer.

To stick with the same example, say your source data contains:

“Family history of asthma” has no child concepts where “Asthma” has over a hundred descendants. You could either lose information by mapping all three to “family history of asthma”, or use the proposed “when available” approach which would prevent you from leveraging the concept hierarchy:

From an ETL and cohort definition perspective this seems unnecessarily complicated when compared to:

Additionally, if we are strictly using this format we can specify the relation of the relative with a more specific observation concept, e.g. "family history with explicit context pertaining to father".

1 Like
#15

@aostropolets I needed ‘no Fx of liver disease’, but I couldn’t find it. I’ve never required anything else.

I agree with the necessity for revision of family history in observation table. But we need to think about the feature extraction package in OHDSI ecosystem, @schuemie . Current feature extraction package distinguish observations by only concept_id. If we revised the rule for family history, the feature extraction package should be changed, too.

#16

Yes @SCYou, you’re right, FeatureExtraction would need to be adapted. But the nice thing of consistently coding family history using ‘Family history with explicit context’ is that we could create an analysis in FeatureExtraction that creates features for every family history concept. You could then for example set useFamilyHistory = TRUE to use these features.

#17

@schuemie Or we can revise the basic algorithm of FeatureExtraction for observation to distinguish every different value_as_concept among the identical observation_concept_ids.

1 Like
#18

I will copy the answer I gave on Github.
Originally, all the FHs (and PH) that went beyond SNOMED were left unmapped. We felt like people may not want to lose the data, at which point we suggested using the mixed approach. On the one hand, it’s definitely important to ensure consistency. On the other hand, we still want to keep precoordinated SNOMED concepts for two
main reasons:
-When we break down source concepts it occurs as a quite time-consuming task. Not all are prepared to that, especially taking into account that this time can be allocated to more important and clinically relevant mappings.
-Usagi will map source concepts to the direct SNOMED counterparts, which will be useless and will need manual review; this again leads us to the first paragraph.
So I think that many people will still stick to SNOMED option. Should we outlaw them? :slight_smile:

#19

Agreed. Perhaps the next step should be to share the rough format we are seeing in the source data. For instance, the format I’m seeing would make it more time consuming to use the approach you are suggesting, as the condition is in a separate field.

As in:

I’m not sure how extensive it is but I’ve seen the mappings in place to go from the precoordiated SNOMED concepts to the value_as_concept representation, so wouldn’t Usagi be just as effective?
e.g.

#20

@rtmill, in the case you state above, I would total just do what @schuemie was saying family history with explicit context + VALUE_AS_CONCEPT_ID. Your data looks to come across in the format perfect for that.

Question, how would one code “family history of late onset asthma”? All the ICD9/ICD10s look pretty broad.

@aostropolets - is there an easy way find all concepts that are related to family history? I think that would solve @schuemie & @SCYou thought with using Feature Extraction

t