We are looking to derive a set of surgeries that are of interest to our researchers from the procedure_occurrence table. For the CPT4 target vocabulary, it looks as though there is already a one to many mapping in the concept relationship table between CPT4 surgery codes and their respective SNOMED-CT procedures? I am finding that the “CPT-4 to SNOMED equivalent (OMOP)” relationships created between CPT4 and SNOMED are not always equivalent. It could be that I am not using these relationships as they were intended or missing something…hoping to get some guidance here. How were these “CPT-4 to SNOMED equivalent (OMOP)” relationships created between CPT4 and SNOMED? How are they intended to be used? Is there documentation I can review on this? Much appreciated! Thank you.
Welcome to the community, @tsandler ! The forum notifies it’s your first post:)
Those relatinships haven’t maintained for years, thus they are not 100% correct.
Anyway, it would be better to use not a concept_relationship, but concept_ancestor table as it has multiple levels of separation.
Actually, you can share some of your use cases so as a community we can help doing this little excercise of concept set definition.
Thanks Dima!
Sure thing, one use case is identifying patients that had a Gastrectomy (regardless whether it was subtotal, total, proximal, or distal). You’re suggesting that there is a better level of accuracy using the concept_ancestor table? I’m going to explore that further and see how far I can get.
You’re welcome @tsandler !
The concept ancestor goes through different layers, so you don’t need to pick the closest parents, but just use a generic top level SNOMED concept:
select c.concept_id , c.concept_name from concept_ancestor ca
join concept c on c.concept_id = ca.descendant_concept_id
where ca.ancestor_concept_id = 4203442 – Gastrectomy (SNOMED)
and c.vocabulary_id =‘CPT4’
;
And unfortunately, concept_ancestor is build from the same relationships that are in concept_relationship table. So you have to review the results manually anyway.
For example the result of the script above contains such a concepts:
2108862 Partial esophagectomy, thoracoabdominal or abdominal approach, with or without proximal gastrectomy; with colon interposition or small intestine reconstruction, including intestine mobilization, preparation, and anastomosis(es)
2109007 Revision of gastrojejunal anastomosis (gastrojejunostomy) with reconstruction, with or without partial gastrectomy or intestine resection; without vagotomy.
And there are couple of other concepts like this, where we don’t know for sure whether there was gastrectomy performed.
I would exclude them from the analysis.
And also to get the proper concept set I would clarify whether you include patients who got the gastrectomy as a part of esophagectomy, Pancreatectomy or duodenotomy
This was really helpful and seems like a good starting point. On the other hand, when I compared the results using the query against the list of codes I manually curated for Gastrectomy cpt codes, there were 4 CPT codes missing (43287, 43288, 43638, 43639); 24% missingness and 8 that would need to be removed (1 seems to be completely erroneous (0051T), and 7 are those instances that you’ve mentioned above “with or without” the surgery performed); 38% of the results. As I move to other surgeries, this query will be very handy. What would be the process to correct the issues of missing codes and false positive codes in the omop vocabulary ontology? Thanks!
We have to run some kind of collaboration in cleaning up that hierarchy.
So you can post cleaned up hierarchy for your use cases and at some point of time we can reflect them in the OMOP vocabulary.
@mik do we have some community google drive where people can post their findings and we can encorporate them into vocabulary later?