On Parameterizing Templates in HL7

One of the outstanding discussions on QRDA was my negative comment on how they proposed to create dynamic templates.  I think the editors understand my comment a little bit better, but thought it would be worth writing down.

The current proposal was to create a template in QRDA that could support multiple measures with a similar structure, with the exception of the value set it used.  That template ID would just have specified root value (say 2.16.840.1.113883.19.4.21.13.2).  Then, you could "bind" the value set to the template by putting the value set OID (say 2.16.840.1.113883.19.9.4.5.1) in the extension.  So, now we have two templates:

<templateId root='2.16.840.1.113883.19.4.21.13.2'/>
<templateId root='2.16.840.1.113883.19.4.21.13.2' extension='2.16.840.1.113883.19.9.4.5.1 '/>

You'd never implement the first one.  The second one is what you would implement.  The challenge here (besides the fact that it is an egregious abuse of the HL7 II Data type), is that it doesn't support cases where there are multiple value set bindings to different components in the template.

I propose something a little bit different.  How about constructing the structural template so that it uses concept domains (a concept domain is an abstract definition of a value set or code system).

I'm going to create a new template (call it 2.16.840.1.113883.19.19.13.1.18.20) for a lab result observation structure that has bindings to a concept domains.

Asserting conformance to this template means that:
1.  The observation/code element shall contain a value  bound to the test result type concept domain.
2.  The observation/value element shall contain a value  bound to the test result value concept domain.
2.  The observation/interpretationCode element shall  shall contain a value bound to the test interpretation concept domain.

Now, we can create a couple of new value sets and a new template (2.16.840.1.113883.19.19.13.1.18.20.5.18).  Let's create a value set called detection tests.  Tests in this value set detect the presence of absence of a particular analyte or disease agent.  We'll also create a value set called "positive/negative results" which gives the two SNOMED CT codes used to report a positive or negative result, and a third value set (called "+/-") which gives the two HL7 codes used to interpret these results.

Asserting this new template means that:
1.  Data elements using the test result type concept domain shall use values in the detection tests value set.
2.  Data elements using the test result value concept domain shall use values in the positive/negative results value set.
3.  Data elements using the test interpretation concept domain shall use values bound to the "+/-" value set.

Now, where you find:
<templateId root='2.16.840.1.113883.19.19.13.1.18.20'/>
You can check the structure, and where you find:

<templateId root='2.16.840.1.113883.19.19.13.1.18.20.5.18'/>
You can check the values give come from the appropriate value sets.

Putting both of these together on the same template "binds" the value sets in the second template to the items in the first through concept domains.

Why is this important?  Well, you don't actually need to use the template ID to make these "binding assertions".  You could say:  If <realmCode code='US'/> then
1.  Data elements using the problem concept domain shall use (this value set) from SNOMED CT.
2.  Data elements using the lab result concept domain shall use (this value set) from LOINC.

Etcetera, all the way down through smoking status...

Aligning through Concept domains allows the vocabulary binding mechanisms to be reused, and supports all of the use cases.  It also doesn't abuse something in a way that will only further confuse people about the right way to use the II data type.

   Keith