Adapting Common Data Model to Animal Health Records in Veterinary Practices

[waydes]

I am the current president of VMDB - Veterinary Medical Databases. A group of veterinary schools and veterinary organizations are considering the Common Data Model for animal records. I have some thoughts on how to do this and would like to bounce ideas of off others.

Discussion within the groups has involved two approaches:

1. Using the tables as they exist and only add fields for unique characteristic to animals such as breed as species. In this approach, person_id would be an alias for animal_id. The main argument presented is the current tools such as Atlas could be used with very minimal modification.

2. The second approach would rename all fields and tables with person to animal and all foreign keys corrected to reflect those changes. The arguments for this approach is it a better database design since it follow first normal form and is tables and fields accurately reflect what they model. I have reviewed the source code for White Rabbit / Rabbit in a Hat and I think the database tables are described in csv files and that can be modified to accept the changes. I am not sure what modifications would be required for Atlas and other software packages.

Suggestions and comments appreciated.

There are several motivations to adapt the Common Data Model:

1. Creating cohorts to analyze animal health records.
2. Comparing disease incidence and associations between animal and human populations.

[mgkahn (Michael Kahn)]

Wayde: I had placed a different option on the table during last week’s meeting. I don’t claim that this is any better or worse than the two in your post. Just wanted to get this one into the conversation:

Option 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.

Advantages:

• When OMOP updates the core CDM, no change to the core OMOP tables to implement
• The OMOP tools will run (albeit with the disadvantage mentioned below)
• We can add as many satellite tables and columns as we wish and violate every rule that Christian Reich keeps admonishing folks about violating…

Disadvantages:

• We have to ensure that we manage the OMOP primary keys that link to the satellite tables whenever tables are refreshed or updated. This will be no small feat to do correctly.
• None of the information present in the satellite tables are available to any of the OHDSI tools
• None of the queries that use these tables will execute with other OMOP sites but I suspect we would create human-only versions of these queries when we wanted to do animal-human correlation studies.

[esholle (Evan Sholle)]

It looks like there are already SNOMED concepts for most of the breeds - why not just throw all the animal-specific stuff in OBSERVATION, using custom 2billion+ concepts for anything that isn’t in a standard vocabulary? I realize as I prepare to hit the “reply” button that this may be driven by my naivete around the intricacies of veterinary care but sometimes from the mouths of babes, etc, etc.

[shawndolley]

It is so great to see the expansion of OHDSI tools to new spaces, use cases, subjects (non-human!). One Health is such a crucial part of our global health going forward, anti-microbial resistance, etc. I have firm faith that OHDSI’s governance and free and open source situation could make it a benefit to the veterinary or animal health informatics community. Bravo!

[mkwong (Manlik Kwong)]

Michael and Wade - thank you both for your thoughts and suggestions last week and others who are contributing to this conversation.

While I admit to doing this in my past, I would recommend not overloading existing fields with data that wasn’t intended. It ends up confusing everyone long term and tools. 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 from the design perspective, this is where I added new fields to the OMOP person table along with supporting the concept of 1:many owner to patient relationship - thus introducing a new owner table.

Re ant-microbial resistance - we are working in this area having both our human and veterinary utilizing the OMOP common data model. Waiting for a grant assessment. Stay tuned.

[waydes]

Manlik,
I found the meeting last week thought provoking and hope to get ideas from those that have been involved with the Common Data Model previously.

I want to propose a separate animal table that is essentially identical to the person table but has breed and species added. I think trying to use the person table with breed and species added will solve short term problems but create longer term issues. Then a many:many owner to animal table can connect owners to animals if there is every a desire to compare owner and animal data. A many:many owner table in veterinary practice will reflect the fact that there are typically several members in a family or owners of an animal. If a person table is used without changing the name of the table, then there would a be an owner relationship between people which again would be confusing. A basic tenet of good database design is First Normal form requires each field to be atomic. Using the person table for animals unchanged violates that since the entire table could stand for either a person or an animal.

I am wondering an animal table as an extension by the veterinary community would need to occur in isolation of if it could be a part of the overall Common Data Model. We also need to add a Veterinary Vocabulary as either an extension of the content maintained by the Veterinary Terminology Services Laboratory(VTSL) at Virginia Tech or a refset developed that incorporates all the veterinary extension plus that portion of SNOMED CT applicable to veterinary medicine.

Looking forward to improving data analytics with animal data in general and specifically from private practice. The relationships between animal health and human health is a field ripe for discovery.

[Christian_Reich]

@waydes

Very interesting discussion. The way to resolve these options is by checking the use cases: What analyses do you want to run, what questions do you want to ask? That usually clears it all up nicely.

So: What use cases do you want to run? Exposure/intervention - outcome research? Or something animal specific like questions about the owners? In the first case, the existing structures would just work, and changing them for the purity of the model is probably not warranted. In the latter, you’d have to go wild anyway.

[mkwong (Manlik Kwong)]

Hi - thanks for reminding me we need a many:many relationship between owner to patient. Given the relative short lifespan of most domestic pets, my head was stuck in the 1:many thinking.

The only reason I didn’t create a new animal table is so I can still use the OHDSI tools on the veterinary version of the common data model I’ve implemented so far - a balance of backward support of data and tools with a evolutionary path forward as we work through the process of introducing this new use path to the OHDSI and veterinary communities. I think as others here at Tufts and CSU suggested, it is probably best to propose and make incremental proposals to the OHDSI community as the end-point use cases will involve coordinating and utilizing both the human and veterinary data - anti-microbial, cross comparative effectiveness, and emerging disease/events.

If the use cases are such that makes technical sense to create less overlap/re-use, then that is what we will need to do. I’m rather pragmatic - let the data/use drive the design/implementation, but maintain as much backward compatibility as possible so I don’t go off the deep end and not have a way to recover from decisions.

By the way it just occurred to me the master_index table that I use to link patients to owners could provide the many:many support. Just not patient to patient relationship due to a name change or ownership+name change in which a new medical record number was generated.

[mkwong (Manlik Kwong)]

Christian - thanks as always - like the human side, topics covered by the veterinary OMOP CDM will vary across lots of topics and needs. In this work we are primarily interested in OneHealth topics that span both human and veterinary data that create knowledge and transfer of that knowledge in both directions.

[waydes]

Veterinary Medical Databases (VMDB) has collected diagnoses, procedures and treatments for over 50 years. Originally using a veterinary specific terminology (SNVDO - used until approximatly 2000, but no longer supported) and using SNOMED CT for the past 15 years. The data we currently store is limited to discharge summaries from various veterinary teaching hospitals. Database searches identify cases of interest but original records (either electronic or paper) have to be searched for more detail. Electronic health records in veterinary practices have become so prevalent, it makes sense to ETL more detailed information in the database for our contributors. Our use cases are research into animal diseases, treatments, outcomes, disease surveillance and other veterinary area. Thus, our primary focus is on animal disease with an interest in One Health and comparative and translational medicine.

If the focus is primarily on animal diseases, would that affect the model? I look forward to opinions of others. I appreciate the discussion. I was concerned there would be little or no response, so this is exciting.

[Dymshyts (Dmytry Dymshyts)]

Hi @waydes
@Christian_Reich, @aostropolets
Currently we’re working on adding SNOMED Veterinary Extension to OMOP.
Currently we have two options:
ingest Veterinary Extension under the same vocabulary_id =‘SNOMED’ like we did to SNOMED UK and SNOMED US - both of them along with International version share the same relational structure and vocabulary_id =‘SNOMED’.
This way you will not distinguish between Veterinary and Human concepts other than looking on concept names and attributes, but not a hierarchy, for example:
“106104001 Female reproductive finding” (pretty Human thing) Subsumes “44601000009107 Shock following ectopic egg” (not Human thing defintely);
“106200001 Hematopoietic system finding” Subsumes “44601000009107” Increased blood granulocyte number (both can be Human conditions)
;
Another option is to create ‘SNOMED Veterinary’ as a separate vocabulary, so users can distinguish between SNOMED Human and Veterinary concepts.
‘SNOMED Veterinary’ and SNOMED will have uniform relationships and hierarchy, for example:
“106104001 Female reproductive finding” (SNOMED) Subsumes “44601000009107 Shock following ectopic egg” (SNOMED Vet);
“44601000009107 Shock following ectopic egg” (SNOMED Vet) Has finding site “59820001 Blood vessel structure” (SNOMED)

Please advice

[Christian_Reich]

@Dymshyts

I’d probably vote for the latter:

so users can distinguish between SNOMED Human and Veterinary concepts.

A SNOMED Veterinary concept is definitely not human, even though SNOMED concept might be either or both. The reason I’d give is the user case: Almost all users will do human research, and having all sorts of diseases of wings and tails mixed in there will confuse them. It also will make conceptsets unnecessarily large.

[mkwong (Manlik Kwong)]

If the number of veterinary specific SNOMED concepts are relatively small - a few 100. I’d vote to add those to the master SNOMED vocabulary and be done with juggling any variants across queries. For OneHealth queries - I’d like to be able to construct and apply the same SQL on both human and veterinary databases and not have to define/deal with two vocabularies - simplify the construction and execution.

If the number of veterinary SNOMED concepts are in the 1000s - then I would separate them into two vocabularies as the difference is great enough to justify this approach.

[Vojtech_Huser (Vojtech (Vojta) Huser)]

Having two vocabularies will still allow same SQL to work (for most of it).
Except for FeatureExtraction package perhaps.

[ronaldcornet]

If I’m correct, the veterinary extension contains 32381 active concepts (July 2018 version).
Actually, this was set aside from “core” SNOMED CT, in which is was included up to 2014.

[mkwong (Manlik Kwong)]

I’d like to avoid the “…for most of it…” or exceptions regarding packages if possible. As Christian said in previous posts - it depends on the use cases. With that said - if I’m doing purely human query construction on a clinical topic, I think I would know enough to recognize a concept is not human related and thus would not include it in my SQL construction. Same for constructing a veterinary query. Again - need to gather more real use cases to really know.

[mkwong (Manlik Kwong)]

Thanks - if there indeed is over 32K distinct veterinary concepts - then having them in a separate SNOMED vocabulary would be fine.

[Dymshyts (Dmytry Dymshyts)]

So, it looks like we need to make two different vocabularies.
Any objections?

[waydes]

I agree that two different vocabularies are needed since the concepts are unique to veterinary medicine and due to the size. I work for Virginia Tech in the Veterinary Terminology Services Laboratory and new concepts, descriptions and relationships will be added over time. How will the vocabulary be updated? New releases occur each April and October. Will automatic updates be scheduled or will someone need to notice / reminder? Thanks for creating the vocabulary.

[Dymshyts (Dmytry Dymshyts)]

Ok, making two vocabularies.
Yes, there will be automatic updates.

Want to clarify one thing:
There are concepts in Veterinary Extension that exist in human SNOMED (terms can be applied both to humans and animals).
These concepts will exist only in SNOMED, so we’ll not have duplicates.
And if you work with veterinary data, you always specify something like vocabulary_id in (‘SNOMED’, ‘SNOMED Vet’)
Or you want to have these concepts to be duplicated, one with vocabulary_id ='SNOMED; another with vocabulary_id =‘SNOMED Vet’?