OHDSI Home | Forums | Wiki | Github

How to represent family history

There is an option to include non-standard concepts in Usagi:

Including non-standard concepts in the STCM table (does anyone already do this?) would add an extra step but seems doable, given the self-referencing relationships that exist in the concept_relationship table (i.e. x maps to x).

Something along the lines of:

INSERT INTO [observation]
           (
		   ...
           ,[observation_concept_id]
           ,[value_as_concept_id]
           ...
		   )
SELECT 
		...
		,obs_concepts.concept_id_2
		,value_concepts.concept_id_2
		....
FROM
	(
		...
	) source_data
	INNER JOIN source_to_concept_map stcm
	ON source_data.code = stcm.source_code
	INNER JOIN
	(
		SELECT concept_id_1, concept_id_2
		FROM concept_relationship cr
		INNER JOIN concept c
		ON cr.concept_id_2 = c.concept_id
		WHERE cr.relationship_id = 'Maps to'
		and c.domain_id = 'Observation'
		and c.standard_concept = 'S'
	) obs_concepts
	ON stcm.target_concept_id = obs_concepts.concept_id_1
	LEFT OUTER JOIN
	(
		SELECT concept_id_1, concept_id_2 
		FROM concept_relationship cr
		INNER JOIN concept c
		ON cr.concept_id_2 = c.concept_id
		WHERE cr.relationship_id = 'Maps to value'
	) value_concepts
	ON stcm.target_concept_id = value_concepts.concept_id_1

Anyway, as @schuemie has advocated above, it would benefit us in the long term to be consistent and choose a single method to represent the data.

But then you need mapping to standard concepts for everything else exept family history. How would you suggest handling this issue?

I’m not sure what you mean. Could you elaborate?

Sure. I have a set of free-text rows that I need to map. Usually, a large time-consuming set. I run Usagi with non-standards concepts and get a) non-standard concepts with ‘Maps to’ relationship b) non-standard concepts with no relationships c) good standard ones.
So I spend time, upload the file, join with concept_relationship to find standard counterparts. Then I’m left with bunch of non-standard concepts that I need to remap manually. Keeping in mind that a set is large, the valuable time will be spent on potentially useless work.
Or I need to use patterns to find these histories, extraxt them and run Usagi on other non-standard concept again. Doesn’t seem like a simple manual for mapping, don’t you think?

The debate as I understand it : For the precoordinated family history concepts that exist in SNOMED, do we (v1) make them standard or (v2) leave them non-standard with both ‘Maps to’ and ‘Maps to value’ relationships.

In this situation, is the issue that:
a) Usagi cannot find a mapping to any concept
or
b) Usagi mapped to a non-standard concept without any relationships to standard concepts

if a)
v1 : SNOMED concept doesn’t exist, data goes unmapped
v2 : SNOMED concept doesn’t exist, manual mapping needed

if b)
v1 : N/A
v2 : vocabulary additions needed

Just the opposite. They are standard now and we map to them.
What I try to show you is that any other way will be a mess until Usagi supports mappings to Maps to/Maps to value and ATLAS knows how to handle them.

Has this topic died or gone to a Themis group? Will the ‘Maps to value’ set of relationships be expanded? What should ETL do for concepts that ‘Maps to’ a Condition or Procedures that also have a ‘Maps to value’ relationship?

They shouldn’t exist. Please share the examples

He is a query. Run against March 2018 vocabulary it returned 176 rows

SELECT count(*)
FROM
(
select source.concept_code,source.concept_name as source_name, source.domain_id AS source_domain
, target.concept_name AS target_name, target.domain_id AS target_domain
, value.concept_name AS value_name, value.domain_id as value_domain
FROM concept source
JOIN concept_relationship maps_to ON maps_to.relationship_id = ‘Maps to’ AND maps_to.concept_id_1 = source.concept_id
JOIN concept target ON target.concept_id = maps_to.concept_id_2
JOIN concept_relationship map_value ON map_value.relationship_id = ‘Maps to value’ AND map_value.concept_id_1 = source.concept_id
JOIN concept value ON value.concept_id = map_value.concept_id_2
WHERE source.vocabulary_id IN( ‘ICD10CM’, ‘ICD9CM’ ) AND target.domain_id IN( ‘Condition’, ‘Procedure’ )
– and source.concept_code = ‘O26.21’ test case
)

Can you help with other questions: Has this gone to a Themis group? Do you plan to support and expand the ‘Maps to value’ relationship?

Thanks for noticing! Will take look.

It came from Themis group and it’s decision was as I posted above.

It seems like the stumbling block here is the ability of Usagi to recognize those concepts.
I don’t think that it’s necessary to expand “Maps to value” until they can be actually useful.

So, is it the final decision?

This way we need to remap all such ICDs to support this decision

Yep, correct. It’s 4210989 Family history with explicit context’ + value. We are almost compliant with it as we already have this structure in ICDs, just need to polish :slight_smile:

1 Like

Hello,

My name is Wilma. I am an Intern in Big Data Vanderbilt University Medical Centre. I need to working on family history - for designated ICD codes, and I am new for working on this. Am I in the correct room to asking how the concept for the family history been established? I understand from the previous conversation that there are some concepts, but how could you find the code for the family history?

I appreciate everyone response for this. Thanks so much!

Best,
Wilma

Welcome @wilma !

There are a couple different ways family history data can be coded in the CDM.

The first is with observation.observation_concept_id = 4210989, family history with explicit context, and the disease/condition is found in the observation.value_as_concept_id.

Or the data might be pre-coordinated as seen with this concept_id.

Hi Melanie @MPhilofsky ,

Thanks so much for your response! I designted it as a concept_ID.

Thanks,
Wilma

1 Like

Be careful with the Family history with explicit context. One of the descendant branch is No family history of. So when you pick the top-level guy you don’t actually say whether it’s happened or not :smile:

So it’s better to pick more specific, e.g. Family history of clinical finding or Family history with explicit context pertaining to mother.

2 Likes

We need to create a convention around these.

1 Like

Thanks @Alexdavv!

Were anyone of you understand if there is a way to indicate age of family member at diagnosis?
I am still confused working on mapping this family history to OMOP - still need to understand better the concept! :relieved:

Please if anyone of you already working on this longer so I may need your help as you have better understanding!

Thanks,
Wilma :grin:

Even though some FH concepts have an indication that age is known (e.g.
FH angina female first degree age known
), there’s no such indication that age can be recorded as the value.
Also, there’s no such convention in OMOP, so nobody will be looking the age in the value_as_number fields.

The only option that comes to my mind:
If you already have the relatives in the PERSON table (or you can create the records for them), you can calculate the dates and add the Condition records for them. Then just link persons to their relatives using the fact_relationship table.

1 Like

Thanks so much @Alexdavv ! for your insight!

Best,
Wilma

t