From a SQL, programming perspective either approach is fine. As was said - using “vocabulary_id in (‘RxNorm’,‘RxNorm Extension’)” construct is common. For how folks are using and constructing SQL now, I think one concept principal is the preferred method. It also simplifies the decision logic of choosing which vocabulary to to map the example “Sepsis” to and maintaining the consistency if the query is run on both the human and animal sides. This also impacts on the application side as well - displays one concept choice instead of two and have to display which vocabulary the concept is attached - more screen space required.
Using a union of SNOMED and SNOMED Vet is perfectly acceptable. In fact, that is how VMDB incorporates SNOMED and the veterinary extension. Just to state the obvious since I am a bit of a newbie to OHDSI, to use the CDM, veterinarians would use both the SNOMED vocabulary and the SNOMED veterinary extension vocabulary. If the veterinary vocabulary contains only those with the moduleId for the veterinary extension, then there will not be any duplicate concepts and fits the principles for OHDSI? Is that stated correctly?
Thanks again.
Exactly. Thanks guys.
We found a typo:
there’s concept_code =‘89001000009106’ with description = ‘Cracticus mentalis (oranism)’
- oranism instead of organism.
Where to report it?
Hi, not knowing the context, here’s what I did to come up with my below suggestion.
89001000009106, clearly a SNOMED-code.
But not in international release.
Looked at 1000009 here: https://cis.ihtsdotools.org/info/index.html?home=namespaces
This shows it’s VetMed.
Had downloaded that extension, and saw the error was there too (so not a copy-paste error).
So either you approach info@snomed.org, as mentioned on the site mentioned earlier.
Or, contact the owner mentioned in previous versions of the list found here: https://confluence.ihtsdotools.org/download/attachments/6160816/SNOMED_CT_Namespace_Registry%20-%20OFFICIAL%2020141021.pdf?version=1&modificationDate=1426061583000&api=v2&download=true
That gives the answer:
Email: jwilcke@vt.edu
Best, Ronald
Thanks @ronaldcornet.
I like really like your logic, you act like a detective here:)
We found a bunch of other innaccurracies, so we’ll report them.
I’m happy to inform that Veterinary Extension is available for download in Athena.
Vocabulary_id =‘SNOMED Veterinary’
This is great! Thanks for getting the vocabulary setup.
1 Like
Just want to add my thanks for creating that.
1 Like
You’re welcome:)
With the Veterinary extension in place (thanks Dmytry!), can we look again at the structure for storing Species and Breed?
Wayde originally suggested 2 options:
- Use existing Person table and add Species and Breed columns which would include OHDSI concept IDs (from SNOMED / Vet Extension)
- Rename Person tables/fields to represent Animal. Create additional tables to represent owner and link with many-many relationships
Michael Kahn proposed:
3) Leave OMOP tables/columns “as is” with their intended semantics and add satellite table(s) linked to the standard OMOP tables for all animal-specific attributes.
I agree with Manlik’s comment:
“Utilizing Observations to hold species and breed is certainly one viable approach, but species and breed are at level of the patient’s demographics along with age and sex.” So I feel like option 2 provides a simple way to add this critical data for veterinary use. Yes, animal data would be housed in a table labeled ‘Person’, but I think if we’re going to be using Atlas and the other tools for Veterinary use, we’ll need to be flexible in the labels for things. I’m not expecting the icon next to ‘Cohort Definitions’ to change from 3 people to a picture of a dog, cat, and horse 
Let’s assume (for a moment) that we were able to convince the community that Option 2 was the right way to go… We then need to look at modifying the code for Atlas to use that data appropriately. One of my developers has looked at this and found adding Breed and Species to the initial Demographic Picker was relatively easy. Well – easy to ADD it to the list… we still need to wire it up so that it knows how to store the cohort definition and how to construct appropriate queries to return results for the cohort.
It seems that having a very similar structure to race/ethnicity criteria would allow this feature to be added more easily than if it was a completely separate construct. I’m sure someone with existing Atlas development knowledge could do this rather easily, but we’re willing to put in the effort if necessary.
My REAL question is this – what is the right way to get these changes integrated into the core product? I would be very sad to do a lot of work to integrate breed/species only to have Atlas 2.x come out an completely invalidate that work.
Is it possible to come to agreement on
a) how the data is stored
b) how the data is added to a cohort definition
Thanks All!
Chris - thanks for laying out the issues and I would support Option 2 as the most practical and viable. As with efforts to address adjacent clinical populations - I look forward to hearing what the Atlas/Tools team suggests as a long term approach to support in a sense “plug-ins” to enable utilizing adjacent clinical data to the core human CDM. I wonder if we can conceptually adopt what mobile device applications developers (ex Java J2ME) utilize - different profiles that help describe the target - in this case the core CDM and additional support tables. That is a Human CDM Profile and a Veterinary CDM Profile.
I’m not sure we need both Species and Breed columns.
Species is an ancestor of Breed concepts, please look here:
select * from concept_ancestor
join concept on concept_id = descendant_concept_id
where ancestor_concept_id = 40491509 -- Canis lupus familiaris
order by min_levels_of_separation
;
select * from concept_ancestor
join concept on concept_id = descendant_concept_id
where ancestor_concept_id = 40488452 -- Felis catus
order by min_levels_of_separation
the output (descendant_concept_id) has all dog and cat breeds, while the ancestor concept stands for Species.
You are bringing up an important point: How can we tweak ATLAS to a special use case that the community overall doesn’t care about, without cluttering it completely. This is a question for the folks who are thinking about the architecture and approach to Open Source development.
Tagging @gregk, @Chris_Knoll, @Frank, @anthonysena and @Ajit_Londhe. Can you guys talk to Chris?
To your questions, @Chris_Brandt:
- I’d also think Option 2. The “human” community shouldn’t be confused with breeds, and the “animal” community can tolerate the semantic abberation of calling an animal a person. After all, we are all animals, too.
- Cohorts are stored with subject_id, cohort_id (containing the definition), start_date and end_date. The subject_id contains the person_id. So, you don’t have a problem here.
Hi @waydes, @Chris_Brandt, et al.,
I’m starting to explore the possibility of using the CDM and ATLAS with animal health data and am wondering if there is additional progress or experience that you can share since this discussion? Did any of you try out option 2 and have success?
Hi Steve,
We (Chris Brandt, Allison Zwingen both at UC Davis, and Joe Strecker at CSU) have been meeting twice monthly on these CDM issues. Chris/Allison has proposed implementing support for breed and species in two places within our version of the OMOP CDM - based on version 5.2 with the following modifications:
-
We added species and breed fields in the person table, along with foreign keys to a new owner table. This keeps patient demographics contained in one table instead of creating a new Animal table. Obviously ATLAS and other OHDSI tools can’t see these fields. However, our veterinary specific applications can use these fields without having to include #2 below to simplify SQL construction.
-
We added species and breed in the observation table not tied to a visit_occurrence_id. The observation_concept_id are SNOMED concepts already in the standard vocabulary. So ATLAS and other existing OHDSI tools can use this information, thus providing a backwards compatibility. One secondary benefit of storing breed information in the observation table is we can support multiple-breed patients. For example a EHR documented “German Sheppard/Cross” can register two concepts in the observation table - one for “German Sheppard” and a second “Mixed breed dog”. This use case came up when we wanted to only include pure breeds in a query.
The above is going into production at Tufts Cummings Veterinary School next week. We have over 340,000 patients and over 816,000 visits.
I’m also in the process of integrating ongoing research data - case reports (surveys) from REDCap - into our CDM as part of our expanding implementation of OMOP CDM to support veterinary research.
Are you a member of the CTSI OneHealth Alliance (COHA)?
- MK
1 Like
Hi Steve,
Are you already using this CDM vet?
Hi steve…
i really appreciate your effort. you are doing great job.As someone who is intreseted in pets and want to knows about pet diseases and health you can visit this website Dog Health - The Veterinary Student
As of late last year, I read that the community is starting to consider moving the Race and Ethnicity columns to the Observation table as it is becoming increasingly common that 1 person reports multiple values in both of these fields (and that the additional values are collected!)
https://forums.ohdsi.org/t/race-and-ethnicity-in-the-omop-cdm/
Given this conversation, I wonder if we could treat the idea of “Breed” similarly as often times more than 1 breed is reported (mixed breed dog for example), and the reported breed can change over time. It seems like it would make sense to enter this information as Observations. This also avoids the need for the veterinary community to create something outside of the CDM which may be implemented differently across the organizations.
In terms of edits to the Person table, I think it would make sense to add a Species column to the CDM. For organizations with only human persons, it would be easy to populate the column with a concept for human, but for other organizations it allows the flexibility to add patients of all species. In terms of software edits, the Species column could be added to Atlas and used to define a cohort.
Looks like there are two different problems you are trying to solve:
- Species information, which is missing at the OMOP CDM.
- Breed information within a species, which you want to handle like human races.
For 1, you are right. It would be an OMOP CDM Expansion (extra tables and fields that won’t make it into the general model, but is supported for those who might need it). Just add something like “species_concept_id” and people will stop making it up. @clairblacketer will help you. The vocabulary should be there already.
For 2, the discussion might indeed be similar. But you know better. Obviously, the breed cannot change, since it is laid down in the genes. If it does in the data then it is probably just an update of the existing information. I don’t know if you have a use case where the “change” of breed is something you are studying. You tell us. If not, I would not bother with making it complicated.
For humans, race is not just biological, but as much a socioeconomical concept that is somehow both self-assigned and determined by the society you are living in. A change in race could mean a new awareness or identity of the holder. Animals cannot have those. So, I think the analogy is not that useful.