Wednesday, September 30, 2009

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.

11 comments:

  1. How do I know what version of a particular standard is in use for a particular document?

    ReplyDelete
    Replies
    1. Here's the answer in one of his latest publications http://motorcycleguy.blogspot.com.by/2017/01/what-version-of-ccda-document-is-this.html

      Delete
  2. Hi,

    How can one differentiates between CCD C32 and CCD C48 document? Using the template ID only or any other code is used?

    ReplyDelete
  3. The template identifiers are the most precise way to determine the set of business rules that a document follows, but not necessarily the easiest way to differentiate (because you have to open the document to see them).

    When indexed in a registry, C32 and C48 have a number of different requirements on metadata which can be used to distinguish between the two.

    document Type Code: C32 is A summary of Episode note while C48 is either that or a Discharge Summary
    document Class Code: Implementation defined requirements, but often similar to type code.
    document format code: They use different format codes.

    Finally, of course, inside they use different template identifiers.

    ReplyDelete
  4. Business intelligence health care
    intelligence health care

    ReplyDelete
  5. This is very educational regarding document template IDs. I'm sure others in the industry appreciates this accessible explanation as much as I do. May I suggest two follow-on lessons that are surely needed:
    Lesson #2. Explanation of the differnt header contraint templates and their effects (2.16.840.1.113883.3.88.11.32.1)usually found with CCD document templates, (2.16.840.1.113883.10.20.3) usually found with Medical Document document templates, and (2.16.840.1.113883.10) usually found when the CDA R2 Document template is referenced. What are the differences?

    ReplyDelete
  6. Suggested Lesson #3: Explanation of how Section Parent Template IDs relate to Document Template ID's. How does this level of template ID conformance work in conjunction with the constraints inheritted through the document Template ID's?

    ReplyDelete
  7. I have a templateId question for you. I am trading C62s between various installations of my application. I would like to have a way of automatically routing those incoming C62s. Can I accomplish this via a custom templateId with my own assigningAuthority?

    ReplyDelete
  8. If you want to route a C62 Unstructured Document, the best way to route it would be based on the type of content it contained, not usually on the formatCode or templateId.

    The type of content is already described in the document in the ‹code› element of the ‹ClinicalDocument› and also appears in the classCode and typeCode metadata elements of the submission set.

    ReplyDelete
  9. This comment has been removed by the author.

    ReplyDelete
  10. Keith, Thank you for some of the best medical software information on the web. Your site is a great resource! Can the presence of template roots alone distinguish CCD from CCDA documents? If not, what elements or attributes should I use so my application can make this distinction? Thanks again.

    ReplyDelete