| OHDSI Home | Forums | Wiki | Github |
The data I usually see looks just like ‘family history/FH of something/ relatives with something’ etc. 
And we can put it the way that people can use both pre- and post-coordinated concepts.
the simplest way is to get all descendants of 4210989. There will be social history though (like Parent unemployed ) or even a couple of concepts like ‘Family counseled’
Just to be clear: I’m not sure what the right way is. I also don’t have a clear use-case in mind.
I do want to add two additional arguments to the table:
Just because something currently is hard in Usagi doesn’t mean it has to be. I’m sure that with some simple regular expressions we can automatically catch >95% of family history-related concepts, and map them using VALUE_AS_CONCEPT_ID.
As an application developer, I want to make a strong plea not to choose to allow both options. Please pick one, so we can develop applications based on that choice.
@SCYou: Yes, building features based on the combination of CONCEPT_ID and VALUE_AS_CONCEPT_ID is definitely on my wish list. The biggest challenge is a dumb one: we don’t really have enough digits to create unique covariate IDs. But we can discuss elsewhere.
I agree. The mixed model is kludgy.
We’d have to do that. Because of:
@aostropolets is referring to the mapping of local codes and free text. Generic vocabularies like the ICDs are already split up. But having people having to do that for their ETL means we need to support this process with some reasonable Usagi functionality.
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)
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.
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? 
@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).
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?
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.
It needs to be implemented by Usagi first, or instead of “hodgepodge” you’ll get missing data
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?