NEHTA Clinical Documents: Notes on the usage of templateIds

Sep 26, 2012

Normal NEHTA CDA Clinical Documents carry two templateId values at the root of the document:

One of the templateIds (the first, in this case) indicates which CDA implementation guide that document is based on, and the other indicates which version of the rendering specification the document conforms to.

Note that there is no order associated with the templateId entries – they can come in any order. Also note that while NEHTA only describes two templateIds for each document, other implementations are permitted to add their own templateIds – which would have to be different root/extension values, of course. At present, there is no known use for this, but implementers should be aware that it is possible and legal.

Both templateIds are used to indicate that the document conforms to a set of rules on the content of the document. Knowing that the document conforms to the rules about the content enables the receiving/displaying system to safely handle the document. The following sections describe the use of the CDA implementation guide identifier and the rendering specification identifier respectively.

CDA Implementation Guide Identifier

Each NEHTA CDA Implementation guide specifies a particular root/extension combination that must be found in the ClinicalDocument.templateId list. The root identifies the kind of document (eReferral, Discharge Summary, etc), and the extension identifies the version release of the CDA implementation guide. In theory, if non-version backwards compatible changes are made between successive releases of the same CDA IG, then the root value will change (this is current NEHTA versioning policy), but implementers would be wise not to assume that this would be the case.

This template Id identifies a particular document type, and therefore overlaps with the LOINC code in ClinicalDocument.code which identifies the document type. However the two fields are not equivalent in meaning. To illustrate this, consider an institution producing a discharge summary – it should use the LOINC code “18842-5 (Discharge Summarization Note)” to identify the document – this is whether it uses the NEHTA design for a discharge summary or not.

So if you see a document with a LOINC code of 18842-5, then you know it’s a discharge summary. That tells you more or less what the document’s going to have in it, but not exactly what the section and data contents are. To know what they are, you have to know exactly what implementation guide the document conforms to – the templateId.

CDA compliant systems can process documents by simply rendering them for a human. In this case, the CDA Implementation Guide is irrelevant and can be ignored. Such systems might use the document code to categorise a document in a human display. But if a system wants to extract data from the document, it needs to note the CDA Implementation Guide and act accordingly.

Rendering Specification Identifier

The rendering system Id has a root  of “1.2.36.1.2001.1001.100.149” and an extension which is the version of the rendering specification.

A CDA document requires a stylesheet – a piece of executable code that readies it for display to a human. In an ideal world, the author could simply send this code along with the document, but this is not possible for security and engineering reasons. However there must be a way to manage the display safety – it cannot simply be a matter of tossing a document into the pcEHR and hoping for the best.

The solution that NEHTA used is the Rendering Specification – this specifies the base set of rules that must be implemented by any system that displays CDA documents. These rules have a matching set of constraints on the CDA document itself, the things it can try and use from a rendering system. So when a document declares that it conforms to a particular set of constraints from a particular rendering system specification, it means that it is safe to display it in any rendering system that also conforms to the matching set of rules.

NEHTA publishes a stylesheet (XSLT transform) along with the rendering specification. The stylesheet is a partial implementation of the rendering specification - does all the things that can be done in the stylesheet, but there are other obligations that have to be handled outside the stylesheet, so it’s not a full solution. When an implementer engineers the stylesheet into their system, they know which rendering specification the stylesheet is associated with. Note, though, that implementers are not required to use the NEHTA provider stylesheet, or even any stylesheet - as long as the document is presented according to the rules defined in the Rendering Specification, and that the version of the rendering specification is known so it can be checked.

What this means is that the system that is displaying the CDA document knows the rendering specification(s) to which it conforms.

If a document conforms to a more recent rendering specification than the system – i.e. it uses a style that wasn’t defined and isn’t known, then it’s not safe to show the document.

So a system that wants to display the document needs to check the Rendering Specification Identifier, but can ignore the CDA Implementation Guide Identifier.

The PCEHR Template Service

The PCEHR includes a template service that returns a package containing details about each template by the templateId. So you could retrieve a package for each of these two template Ids when a CDA document is encountered.

But it’s not clear exactly what you will get if you retrieve that package for either of the two templateIds described here, and even more, what would be the point? For the CDA Implementation Guide, you might get a set of schematron that can validate the document – but the pcEHR has already done that for you. And that doesn’t help you navigate the document and process it’s contents.

As for the rendering specification templateId – perhaps you could get a stylesheet that’s a partial implementation of the rendering specification – NEHTA provides one – but you would still need to engineer this into your system to be sure that it’s a proper implementation that can be relied on – and you can’t do this on the fly.

So there’s no a lot of point retrieving content from the PCEHR template service for these two identifiers – they are hard coded into the application. Note that gateway services and the PCEHR do retrieve the schematrons by CDA IG TemplateId from the template service for validation, but this is probably not useful functionality for clinical information systems.

Note: This is a draft of text that is proposed to be included in a forthcoming Australian standard explaining the use of the CDA templateIds. It will change somewhat in form to integrate properly into the document context, but is published here to get early comment - comments on the blog or to me personally are welcome.