I'm in Treviso, Italy this week for IHE meetings. As always, when I'm in a country that speaks a language other than my own, I make an attempt to use what I know of the language in speaking to others, at least for greeting them. However, I noted that in both Italy, and when I was in Paris previously, my greetings were inevitably responded to in English when the speaker was able to use that language.
The protocol the listener used to fall-back to English was fairly straightforward. They detected something in my accent that made it clear to them that I was not a native speaker. In the case of Italian, it was my failure to prounounce buon giorno correctly. I was missing the initial DJ sound in giorno (pronouncing it with a softer J sound), and failing to roll my R's (a failing that caused me great problems in my high school Italian class as well).
In IHE PCC, we are working on creating version aware templates as part of our ongoing work on harmonization with the Consolidated CDA. One of the things that developers routinely ask me for is how they can tell what set of templates are used in a document. This is especially important in the context of versioned templates. In this case, a developer wants to know if it is even worth their time to process a document that may contain something they don't understand.
The solution that we finally came upon is quite similar to what a Java compiler does when it creates class file. You can tell the compiler to create a class file that works with a particular version of a JVM. Newer JVM's can process class files that were compiled for older ones, but if an older JVM encounters a class file that reports itself as being built for a newer JVM, it will refuse to load it. We will enable such marking in the TF.
A content creator of a CDA document that is produced using templates from the PCC Technical Framework has a responsibility to mark the minimum version of the Technical Framework that is required to be understood. This mark will appear in a <templateId> element appearing in the header. Presence of that identifier is an indicator to the receiver that if they do not understand templates in that revision of the technical framework, they might not be able to understand the content of the document. It's not an absolute statement that they won't work, just a warning that they may not work. To parallel with the Java case, there are new structures and/or JVM operations that may appear in the class file, that older JVMs will not understand.
In this fashion, a receiver of content can examine the <templateId> associated with TF version. It can then take appropriate actions based on the root and extension values found, and as necessary (as with me to an Italian speaker), fall back to something that both parties understand, or indicate that it cannot understand the content, or determine that it will try to understand anyway (much more like my wife), and only when it fails to understand, abandon the conversation.
To actually be able to (safely) understand something even though it is written to a later version of the technical framework than the system is designed for is built into how we mark versions. Templates have a major and minor version number. The major number changes when the new template cannot be understood (safely) by a system designed to understand a previous version. Only the minor number changes when the template changes in a way that is backwards compatible, and only adds new information.
The intent of the distinctions we have created for major and minor change is to address issues of correct interpretations and thus patient safety in those interpretation of exchanged content. However, I use the term (safely) in parenthesis above, because there is no way for IHE to determine what consumers can do with exchanged content safely. We can simply advise that something may not be safe (which the major/minor change distinction does). It is, and must always be up to individual products to determine what is safe for patients based on their existing risk assessment processes.