What are the data dictionary components required for interoperability?

Is a dictionary of standard end-user facing terms what we should be focusing on, or should we be putting our efforts into ensuring that the underlying codes are managed in a way that supports semantic interoperability? I'm not convinced that a single set of terms to be used in the front-end of all systems a desirable thing. Systems for different audiences may have different needs (e.g., low health literacy) and different jurisdictions may have regional characteristics that demand variety in the terms. If instead we focus efforts on ensuring that jurisdictions/systems can translate their own terms to standard, unambiguous coding sets, we create a framework that can allow different sectors and jurisdictions to evolve over time.

I've said in the CD naming discussions, by allowing ambiguity in the reference sets that were recently released, the meaning cannot be clearly communicated between systems. For example, does SNOMED-CT code 792004 mean that the system is reporting combined Classic and Variant CJD cases, CJD with unknown classic/variant (because there is no code to indicate unknown CJD), or Classic CJD (because a separate code exists for Variant)? Automated interpretation of the message is lost. With this kind of ambiguity in the code sets, standardizing end-user terms is not going to improve semantic interoperability or it will lead to a situation where the end-user terms have been mapped so tightly that they can't evolve. If we focus on the meaning of the standard messages and let jurisdictions map their own terminologies to that, we may be more successful and sustainable.

I also think you need to define carefully the concept of a data dictionary. The blog post is interesting, but it is by a vendor selling a product. Should a data dictionary contain specific terminologies, or should it reference terminologies and ensure the data elements that are necessary to support interoperability are present and well understood?

Thanks Karen for sharing the article and for opening this discussion!

Mapping SNOMED CT vaccine terminology agent codes to GTINs (Trade Names) is a great example of where we can start. I believe it would also be helpful to (as the article suggests) include a synonym library of client or public facing terms which are linked back to the standards.

Has anyone explored this area yet, or would be interested in collaborating on this? It would be great to have an agreed upon set of terms which are simple and most recognized by the public as well as other immunization providers outside of public health (e.g. pharmacists) as a part of the data dictionary.

What are your thoughts on the components of a data dictionary that are required to support interoperability?

This blog article shows an American health care perspective on the question: blog.healthlanguage.com/what-is-a-data-dictionary-and-what-role-does-it-play-in-semantic-interoperability

Semantic interoperability-- "the ability for IT systems to understand the meaning of the data that is being shared"-- is something we discuss a lot on the PHS community calls. Our recent conversations about the need to map the SNOMED-CT vaccine terminology Agent codes to GTINs (vaccine Trade Names) is a good example of work that we have identified that will support this aim.

What would a good data dictionary look like to support our goal of pan-Canadian vaccine bar coding? Who would maintain it? Where would it be hosted?