Minimum Necessary and Open Templates

Last week at the HL7 Working Group Meeting, I taught a class on Templated CDA.  This is a class for implementation guide developers.  You might think it applies only to the kinds of folk who go to IHE or HL7 meetings, or perhaps S&I Framework or Canadian Standards collaborative meetings, but you might be surprised.  I define "implementation guide" rather broadly.  There are implementation guides that are defined at a national level (such as in the US Meaningful Use regulations), those defined at a regional or project level (such as those defined for Healtheway), and then there are those that are included with commercial products (we call those product manuals), or which are part of an organizations internal design documentation.  The use of these documents might differ, but the kinds of content it needs to contain, and the various choices that a specification editor has about what could be done are about the same.

One of the interesting topics of discussion in the class was on the use of Open vs. Closed templates.  An open template allows anything beyond what has been explicitly prohibited in the rules expressing the template.  A closed template prohibits anything beyond what has been explicitly allowed by the rules of the template.  The former is extensible and reusable.  The latter is not.  However, the latter is quite useful in cases where minimum necessary comes into play.  This is a key phrase that shows up in various places in US regulation to mean "no more than is needed" to serve a particular purpose.  Under HIPAA, exchange of information for payment or operations falls under the rubric of "minimum necessary".  However, exchanges for treatment do not (which doesn't stop people from trying to address them as if it were a requirement).

In public health, the use of minimum necessary in exchanges also facilitates risk mitigation.  If you know that users are only communicating the minimum necessary to support a particular public health function, you can address data risks using that minimum necessary criteria.

I really don't like letting an operational requirement cross over into the data models that we use to express template content.  Basically, it means to adopt the data model for a particular use case, I also get stuck with this additional piece of baggage (minimum necessary) that gets in the way of reuse.  My recommendation to my students is to define their templates in "open" terms, and then define the characteristics of the systems that exchange them as being able to, or unable to accept open content during an exchange.

So, now I have my cake (an open template), and other systems can define how they want to eat it (with or without any additional toppings).