OHDSI Home | Forums | Wiki | Github

How to represent family history

Vocabulary Users
#25

I think, there is a solution:
@aostropolets, we can map everything directly and then use the script that splits the concept to its Maps to and Maps to value,

I made an analysis and figured out that descendants of such a concepts have relationships ‘Has asso finding’ or ‘Has asso proc’ given by the SNOMED.
4167217 – Family history of clinical finding
4214956 – History of clinical finding in subject
4215685 --Past history of procedure

Sometimes they might be not 100% accurate (SNOMED can have more general attribute than said in the text description of the concept), but still it looks like a solution.

4169307 Allergy to substance is a more complicated case.
All its descendants also have ‘Has causative agent’ links, but these concepts aren’t standard and additional work of standard concepts search is required (i.e. analysis of SNOMED - RxNorm mappings)

#26

Yes, it somehow helps. Still, not all of them have those relationships (and we can make people who use Usagi only write additional queries).
So, If @schuemie could somehow incorporate this “break down” feature into Usagi I believe it’d be a perfect solution to make the mapping of FH easy for everybody.

#27

I think I’m not 100% following here, but let me try to summarize.

We want to recommend that all family history get the OBSERVATION_CONCEPT_ID = 4210989 - Family history with explicit context and then if there is an associated condition it should get put into the VALUE_AS_CONCEPT_ID.

For example, if I get this ICD9 V17.5-Family history of asthma the Vocab would map it to 4210989 but there would also be a separate non-standard relationship to asthma? Any time I have a code mapped to 4210989 then I will do a separate query to get to its associated condition?

Or am I just missing what you guys are talking about? :slight_smile:

Vocab WG July 30 meeting [CPT4 visits and postcoordination]
Vocab WG Oct 29 meeting [labs and conditions postcoordination]
#28

@ericaVoss for ICDs you’ll get maps_to (FH of clinical finding) + maps_to_value Asthma (as it is now). I’m basically discussing free text mappings where you neither have existing mappings nor know to which domain value_as_concept_id will go (that’s why we put maps_to to FH with explicit content).

#29

It seems that we haven’t moved forward with this issue:)
One more thing that I want to add:

I agree that it would be perfect if Usagi can break down this concepts and find maps to and maps to value. If we think of doing it on the vocabulary side (like make SNOMED concepts non-standard with the links maps to and maps to value), this move won’t make a difference alone: Usagi won’t catch these non-standard concepts.
And, again, I truly don’t think that using the mix of precoordinated SNOMED concepts and broken down concepts will do any harm. As for me, the regulations should be easy to follow for every user, otherwise they are likely to be ignored.

@schuemie @Christian_Reich @rtmill any thoughts?

#30

It will. People will (and should) use the hierarchy. So, if there is an exclusion criterion “No history of malignant disease” they should find those through the CONCEPT_ANCESTOR table in the value_as_concept_id field. If it is a hodgepodge of precoordinated and split up chances are the precoordinated history of breast cancer won’t pull up.

[2022 US Symposium] #68 - "history of"
#31

It needs to be implemented by Usagi first, or instead of “hodgepodge” you’ll get missing data

#32

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.

#33

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

#34

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

#35

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?

#36

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

#37

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.

#38

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?

#39

They shouldn’t exist. Please share the examples

#40

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?

#41

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.

#42

So, is it the final decision?

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

#43

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
#44

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

t