Software developers use programming languages in idiomatic ways all the time. The infamous "endless" loop in C/C++ looks like this:
Most programmers will learn to recognize these common idioms and move on. Sometimes the idiomatic use so simple that it never needs to be codified, and is easily understood (like the endless loop above). At other times, the idiom is rather complicated and in some ways, inexplicable.
Here is an example from XSLT. See if you can figure out what it does before I explain it:
This particular idiom is one I use regularly. For a string X, it first translates any occurrence of '+' into a '-'. Then it appends a '-' to the string. Then it extracts whatever string appears before the '-' character. If X is an ISO 8601 formatted date-timestamp with an optional time zone, this expression will extract just the date-timestamp portion of it without the timezone.
Language developers will often take common idioms and use them to develop new language features that re-implement the idiomatic usage. If I were writing an XSLT library, I'd certainly put in some timestamp manipulation functions to avoid having to write this in its idiomatic (and idiotic) form.
Idioms are important because they identify common patterns of use. In looking over a number of templates in IHE, HL7 and HITSP, and identified a bakers dozen of common idioms. From that, and a review of the documentation, we have enough information to put together a template meta-model.
Earlier today I was on a call talking about clinical decision support and GELLO. GELLO has to be my least favorite language for expressing things in a clear form. It shares a common feature with XSLT which is that it is declarative. Declarative programming is counter-intuitive for most people when the first encounter it. SQL is also a declarative programming language. The benefit of declarative programming languages is that they specify what the result looks like, not how to generate it, or the order of the steps needed to accomplish the task. The counter-intuitive part is that you have to think "backwards" and "upside-down" or "inside-out" and forget procedures. It takes a while to learn that skill (or at least it did for me).
One of the pieces of feedback that the speaker had gotten about GELLO was the love/hate, and mostly hate relationship that non-technical people had with GELLO when examining clinical decision support rules. I feel almost the same way about OCL as I do about GELLO, which isn't surprising since GELLO is derived from OCL (and should become a proper subset of it some day).
Having recently had a similar experience with OCL (because MDHT expresses constraints in OCL), and having figured out that the idioms used are a key to figuring out the meta-model, what I realized was that the same was also true in Clinical Decision Support. The idioms used in clinical decision support are what will be important to providers when we finally figure out what it's meta-model is. For Templates, we had to get to over a hundred of them before I could see (and use) common idioms. Having over 1000, I'm pretty certain we have all the key ones nailed down. I suspect we'll need to do the same for Clinical Decision Support.
There's still some odd-ball stuff that we'd have to represent directly for templates in a "low-level" construct like Schematron/XPath or OCL. We can live with that. After all, sometimes you need to call into an assembly language routine from a high level language too. I'm certain the same will be true for clinical decision support as well.
As I think about this even more, I'm struck by yet another similarity. High level languages (and from them Object-oriented languages) originated from assembly. If you think of GELLO or Schematron as the assembly language, you can see where models and high level languages for templates (or CDS) will finally emerge.
I love it when separate activities come together like this.