Without knowing what the origin concept set expression is, I can’t comment on which concepts may be improperly mapped.
What I can say is that Atlas isn’t applying any special logic on top off the CDM vocabulary tables. When yous ay:
I’m not sure what trickery you’re referencing but when looking at the included source codes, you’re simply looking at the source codes that map over (via source-to-concept-map) to the standard concepts that are included from the concept set expression.
To put it another way (on how we get to included source concepts) we:
- Resolve the concept set expression into included conepts (uses CONCEPT_ANCESTOR)
- From the result of 1, find concepts via source_to_concept_map.
If the concept set expression wanted to include complications and excluded T1 concepts, then it makes sense that you got the complication included that happens to reference a T1DM cause…because the concept set expression is puling in any concept that’s a complication but the complication itself is not a T1DM diagnosis…
This is just some of the interesting side-effects you get from using the CDM vocabulary, and this is specifically why we give you the ‘included concepts’ and ‘included source code’ views in Atlas.
The likely conclusion here is that the vocabulary mapping is correct, and the concept set expression has to be more specific about which complications you want to find (such as only complications related to T2DM). But this is really a wild guess as I don’t know the specific code list and clinical concept you’re trying to model.