Contents

• Creating a Non-Coded CDA Document: The easy way
• Creating a Non-Coded CDA Document: The more complex way
• Parsing a Non-Coded CDA Document
• List of Non-Coded CDA Document Fields

Background

The CDA specifications allow for differing maturity in the approaches for representing clinical documents. Within ITK it is possible to send a simple PDF or Word document as a payload, but CDA allows for more structured data to be included alongside the clinical information to allow for some machine processing at the receiving end.

The highest maturity is to use a structured, coded CDA document (such as the End of Life Care document), which fully specifies the information and clinical coding to use, and allows that to be safely and consistently interpreted by a receiving system.

In moving towards this fully structured approach however, there is also an interrim step which can be used to incorporate unstructured content (or content whose structure is locally defined), but also include enough structured content to allow for consistent processing by a recipient. This is exactly what the Non-Coded CDA specification supports.

There are two main ways that the Non-Coded CDA specification can be used:

1. To send a binary attachment such as a PDF document (or locally defined text/xml), with some standard structured information about the author, recipients, patient to whom it relates, etc. This is referred to in the specs (and in this Java library) as a “NonXML Body”.
2. To send a set of human readable sections that can be rendered to a user using the standard XSLT transforms provided by HSCIC – again supported by structured information about author, recipients, patient, etc. This is referred to in the specs (and in this Java library) as a “Structured Body”.

Home