IHE PCC Profile Requirements for Templates

I just finished an interesting discussion with an IT Architect who is implementing some of the HITSP Constructs (C32 Summary Documents using the HL7 Continuity of Care Document).  He identified a significant gap in explanation or detail for the various specifications that HL7, IHE and HITSP have produced.

There are at least three parts to the problem:

• Template Inheritance
  What does it mean when template A from one specification requires conformance to template B from another?
• Required Templates
  What does it mean when an XML element adhering to template A requires the presense of template  B inside it?
• Use of Additional Constructs
  If you want to include additional XML structures inside a template, is that allowed?

Template Inheritance
HL7, IHE and HITSP have all made use of template inheritance in their specifications.  This creates a layering of constraints on the information that is allowed to be present in the final XML.  I talk about the layering of these constraints previously when I discussed Template Identifiers, Business Rules and Degrees of Interoperability.

When HL7, IHE or HITSP requires the use of a previously defined template, they never intentionally create a situation where newly imposed constraints conflict with preexisting requirements.  There have been a few mistakes (which is normal in the course of human events), but these are technical errors, not intentional overrides of any requirements.   I do use the term "requirement" advisedly, because any one of these organizations may override a MAY or SHOULD if they deem it necessary.  MAY and SHOULD are not taken to be absolute requirements, only guidance (see RFC 2119)


Required Templates
For example, the IHE PCC Technical Framework indicates that for the History of Past Illness Section:

"The History of Past Illness section shall contain a narrative description of the conditions the patient suffered in the past. It shall include entries for problems as described in the Entry Content Modules."

And further down in the table requires the presense of the Problem Concern Entry.

Must that entry appear directly within the section, as given in the example?

The answer to that question is no, which would only be apparent if you read the conformance tests we provided in schematron in previous editions of the technical framework.  The requirement is that the specified template must be contained within the section, but it need not be explicitly a direct child.  The rationale for this choice in IHE was that Sections and entries may have subcomponents which contain the necessary material. For example, Sections may have sub-sections containing the necessary details.

Suppose for example that you wanted to insert an organizer to collect a bunch of problem concern entries.  Would that be legal?  Yes it would.

Doesn't that create more ways to represent the information and more optionality?  It does create more optionality, but the IHE constraints are sufficient to enable the location of the required entries. They can be found using an XPath expression rooted in the context of the outer template (which is in fact how the validation schematrons test for this).

So, if you want to find the Problem Concern Entries of the section, you can use the following XPath expression to find them: .//cda:act/cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.4.5.2"] 
This basically says to find the CDA Act elements that assert conformance to the Problem Concern template that are descendants of this element.

Use of Additional Constructs
HL7, IHE and HITSP do NOT forbid the use of anything otherwise allowed by the underlying standard except in VERY limited cases (I personally can only identify one instance, in the CCD Payer Section).  Anything not explicitely prohibited by the templates (or the underlying standard) is allowed.  The rationale for this rule is that we cannot predict the new use cases that will appear for one of these templates, and this maximizes interoperability of the specification.

In HL7 specifications, this resulted in the specification of originator and reciever responsibilities in several HL7 CDA Implementation Guides.  I've summarized these below, but you can find the full text in the History and Physical Implementation Guide DSTU.
Originator Responsibilities
The originator shall apply a template identifier to assert conformance to that template.  It need not assert a template identifer if it chooses not to assert conformance.

Reciever Responsibilities
A recipient may reject an instance (e.g., a document) that does not conform to a particular template, but it need not reject instances if it so chooses.  It SHALL NOT reject an instance that is not explicitely required to assert conformance to a template.

NOTE:  These responsibilities would appear in the Platform Independent Business Viewpoint of the SAEAF Matrix I depicted here.

So, yes, you are allowed to include additional entries, subsections or section content within a document if it is otherwise allowed. A caveat to that is that the CCD Specification does classify a document as being a summary of episode note. If you delve into areas where other clinical notes better represent the information you are lookinf for, read what I have to say about hammers here.