At Regenstrief, the concept dictionary started out much like in OpenMRS but later evolved to a model where the “local” concept dictionary (equivalent to OpenMRS’ Concept) became just one source (one dictionary) and other sources/dictionaries could easily be added & used as needed for things like metadata.
In effect, imagine adding a concept.source attribute and populating it with “1” for all existing concepts. In turn, what we see as the dictionary now becomes the “primary dictionary” and code that uses concepts evolves from asking for “concept 123” to asking for “concept 123 from the primary dictionary.” When you need a new value set or metadata dictionary, you add a new source (e.g., “2” or “3”). Eventually, a universal concept ID was added that could map to a source + concept ID (similar to how we use UUIDs to map to concepts).
The challenge with using concepts for metadata (and why there is ongoing debate on our choice to leverage them for i18n of programs/workflows/states) is conflating local metadata with a central/primary concept dictionary that typically needs higher rigor than local metadata.
I bring this up because this thread reminds me of my attempts many years ago to evolve the OpenMRS model toward Regenstrief’s – i.e., adding a “source” column to our concept table. Unfortunately, the extra complexity wasn’t justifiable at the time. That said, if we had managed to do it, I don’t think we’d be having this conversation; rather, people would just be adding a new source for metadata when needed.