Template Identifiers

 Template Identifiers，Business Rules and Degrees of Interoperability

One of the concerns that many have raised about HITSP, IHE and HL7 specifications on the HL7 Clinical Document Architecture is the number of different template identifiers that are needed.  Here's an example from a conforming HITSP C32 document illustrating the issue:

‹cda:ClinicalDocument xmlns:cda="urn:hl7-org:v3"›
 ‹cda:realmCode code="US"/›
 ‹cda:typeId extension="POCD_HD000040"
  root="2.16.840.1.113883.1.3"/›
 ‹cda:templateId root="2.16.840.1.113883.10.20.1"/›
 ‹cda:templateId root="2.16.840.1.113883.10.20.3"/›
 ‹cda:templateId root="1.3.6.1.4.1.19376.1.5.3.1.1.1"/›
 ‹cda:templateId root="1.3.6.1.4.1.19376.1.5.3.1.1.2"/›
 ‹cda:templateId root="1.3.6.1.4.1.19376.1.5.3.1.1.5"/›
 ‹cda:templateId root="2.16.840.1.113883.3.88.11.32.1"/›
                           ∶

There are six different template identifiers in this document.  Each of these template identifiers asserts conformance to a collection of business rules which provide various levels of interoperability.  Let's talk about each one of the separately first:

CCD: ‹cda:templateId root="2.16.840.1.113883.10.20.1"/›

This template identifier indicates that the content of the document conforms to the rules of the HL7 Continutity of Care Document.  These rules indicate that when certain sections appear within the document they will conform to additional rules about what these sections contain, and may contain machine readable entries regarding patient problems, medications, allergies, immunizations, laboratory results, et cetera.

CDA Headers: ‹cda:templateId root="2.16.840.1.113883.10.20.3"/›

This template identifier indicates that the CDA Header will conform to certain rules regarding the inclusion of contact information for each of the individuals or organizations referenced by the document.  These rules are established by the HL7 History and Physical Note implementation guide.

IHE Medical Document: ‹cda:templateId root="1.3.6.1.4.1.19376.1.5.3.1.1.1"/›

This set of rules identifies the document as being a medical document according to the IHE PCC Technical Framework.  Medical documents under that technical framework are required to conform to the previous requirements for CDA Headers (and state that they are conformant), should include a display stylesheet accessible via a mechanism appropriate to topology of the exchange, and must clearly explain any abscence of information in any section.

IHE Medical Summary: ‹cda:templateId root="1.3.6.1.4.1.19376.1.5.3.1.1.2"/›
This set of rules identifies the document as a medical summary.  Medical summaries must conform to the IHE Medical Document rules (and state that they are conformant), and must also contain machine readable lists of problems, medications and allergies for a given patient.

IHE XPHR Extract: ‹cda:templateId root="1.3.6.1.4.1.19376.1.5.3.1.1.5"/›
This set of rules indicates that the document conforms to the IHE rules for an XPHR Extract.  The XPHR Extract defines the minumum set of information that should be present in an exchange between an EHR and PHR system (Note that the less restrictive XPHR Update template is also permissible in a HITSP C32 document).  This requires the problems, medications, allergies, personal information about the patient, healthcare providers, and if known, information about payers, patient support (emergency contacts, next of kin, et cetera), advanced directives, sugical history and immunizations.  If other information is present (e.g., vital signs, family history, hospitalizations, et cetera) it must be provided in according to other rules.

HITSP C32: ‹cda:templateId root="2.16.840.1.113883.3.88.11.32.1"/›
This set of rules requires the use of certain vocabularies when conveying the information (e.g., SNOMED CT for problems, RxNORM for medications, et cetera), according to what appears in the HITSP C80 specification.  It provides further guidance on the use of the internationally oriented IHE specification on the US.  For example, in the international realm, conveyance of race and ethnicity is subject to regional restrictions (some regions require it, other prohibit it, and others such as the US make it optional but recommended).

Now, having gone through all of these different templates and explained (at a high level) why they are there, this question often arises: "Why can't C32 just say that it conforms to all of these without requiring the additional template identifiers?"

It could, but what would that mean?
1.  We would need to duplicate conformance statements from these various specifications in the C32 specification.
2.  Software that was aware of how to process a CCD (or CDA documents conforming to any of these other rule sets) but not aware of the C32 specification wouldn't know what to do with it.
3.  Test tools for C32 would need to duplicate content found in test tools for these other rule sets.
4.  Recievers of a HITSP 32 that didn't understand C32 but did understand IHE XPHR wouldn't be able to use them (really this is the same as #2 above).

The figure below shows how various trading partners (A through F below) will have some degree of understood interoperability based upon the various business rules asserted within the document.

What this diagram shows is that any of these two trading partners will have SOME degree of interoperability, and that the two partners at the top (E and F) would have the highest level of interoperability.  This would not be possible without the inclusion of assertions of all of the business rules that the document conformed to.