Are 100's of concept sets a maintenance nightmare?

1

I am a data architect. I have proposed that we need hundreds of concept sets at a low grain. For example, a concept set could be ER (which might be a couple of concept_ids). I like this approach because it moves lists inside the code to ATLAS. I feel like my approach will be “set it and forget it.”

For those who want more context, I need these concept sets to populate a custom data model (with many more tables that OMOP) using a OMOP data source as the backend.

2

There is no such thing in the quickly evolving landscape of medical / healthcare data where the underlying source data model expands, the source vocabularies advance, the OMOP CDM evolves, and the OHDSI standardized vocabularies mature which is all driven by science which progresses at a faster pace every year.

100’s of concept sets is not a nightmare if properly maintained with a well thought out lifecycle approach created by a project manager, analyst, medical data, your custom data model, OMOP CDM expert.

3

Having hundreds of low-grain concept sets isn’t necessarily a problem if they’re well-named, organized, and version-controlled. The real challenge might be governance, making sure the sets stay accurate as vocabularies evolve or as data requirements shift.

If you’re using them to feed a custom model, it could help to group them logically (e.g., prefixing with domains or use cases) and maybe even automate checks or exports using the WebAPI to track changes. That way, it doesn’t turn into a manual upkeep burden over time.