Context Sensitive Templates

One of the things that you learn about in Computer Science is the use of context free grammars.  There is a good deal of research on making highly efficient parsers for these grammars.  However, anyone who deals with real language also understands that there are parts of language that are highly context sensitive, and that in fact, is one of the reasons why natural language is and can be so much more expressive that computer languages.  It can also be more ambiguous, which is yet another challenge.

In the HL7 RIM, and in CDA Templates, we've taken the approach that what you say and what you do is not affected by context.  So, a problem, is a problem, is a problem, no matter where you find it.  And the semantics used to communicate it, and the templates used to constrain it are consistent across many implementations.

But when we go to create an implementation guide for cancer treatment plan, or HIV services, quite often, those very general sections we described in a general way now need to be specialized.  So now we wind up with specialized templates for the Breast Cancer Problems Section appearing in a Breast Cancer Treatment plan, or an HIV Problems Section specialized for an HIV Services document.

And the HIV problems section doesn't conform and cannot be used within the Breast Cancer problems section, and vise verse.  We could proliferate these context dependent specializations of the problem section, but I'm playing around with another idea.

What if instead, we developed some context sensitive templates.  Here's an example of one for a Breast Cancer Treatment Plan:

Breast Cancer Treatment Plan:
1.  In a breast cancer treatment plan, the problems section will include BCTS specific entries for problems relevant to Breast Cancer Treatment.
2.  In a breast cancer treatment plan, the encounters appearing in the encounters section may include a reason for hospitalization entry that specifies that the reason is due to toxicity.

These are just a couple of examples.  The constraints themselves are attached to the breast cancer treatment plan document, and add to existing constraints of existing sections.

This is all very computable, and achieves the same goals, but it has a couple of added benefits:
It begins to attach context specific constraints to a higher level element defining the context, the document (remember that context is one of the six properties of a CDA document).  I've been tossing this idea around for quite some time.  The examples I gave above are derived from real work going on in HL7 ballots.  I like the idea that we could say: In this context, we need information about X, Y and Z.  And from a healthcare perspective, that is actually a quite useful piece of clinical knowledge.  That X, Y, and Z are important in a particular context probably remains true where-ever that context exists.  So even though we start off with a context of "Breast Cancer Treatment Plan", we could probably later rationalize that to cases of "Patients with Breast Cancer", and various flavors of that.

Then, the context drives the documentation, and when that happens, what you have is clearly an instance of clinical decision support.  It's worth looking into.

   Keith