CDA Creator

The CDA Creator component is used as an example component for creating CDA documents (via the CDA Library) to send to a downstream destination. It demonstrates how to build and map most necessary CDA elements using sample hardcoded values and can be used to build either structured or unstructured CDA documents. It is not designed to parse CDA documents.

Running the Component

Using +COMPONENT, import the CDA Creator

Set a target directory via the CDADir custom field to change where the generated sample CDA will be stored. If not specified, the file will be created in the Iguana working directory by default.

To set the component to create a CDA with an unstructured body, enter the Translator via the “Edit” option and edit the script:

Comment out mapBody() in line 36 to omit the structured body mapping logic
Uncomment mapUnstructuredBody() in line 39 to include the unstructured body mapping logic

On starting, if successful, the component will display the location of generated CDA:

You can go to the specified location and view the created CDA document.

Adapting the Component

There are two types of changes that need to be made to adapt the component to your workflow:

Replace hardcoded values with values mapped from an upstream data source
Add or remove elements and attributes

These changes need to be made in the following locations:

A standard CDA root template is provided at the top of the script and loaded into the variable CDAtemplate. It contains all the mandatory attributes for a CDA header.

local CDAtemplate = [[
<ClinicalDocument xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:hl7-org:v3"
        xmlns:cda="urn:hl7-org:v3" xmlns:sdtc="urn:hl7-org:sdtc">
        <realmCode code="US"/>
        <typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
        <templateId root="2.16.840.1.113883.10.20.22.1.1"/>
        <templateId root="2.16.840.1.113883.10.20.22.1.2"/>
        <id extension="" root=""/>
        <code/>
        <title></title>
        <effectiveTime/>
        <confidentialityCode/>
        <languageCode code=""/>
        <setId extension="" root=""/>
        <versionNumber value=""/>
</ClinicalDocument>
]]

Based on your requirements, this can be simplified or extended further. If the template needs to be extended, you can move it into a separate Lua file to keep your main.lua easy to read.

This template is used in the main function to generate an XML node tree that allows you to easily add, remove, and modify the CDA document.

local Doc = xml.parse{data=CDAtemplate}

As a guideline, the template should contain what will always be present in your CDA document regardless of what’s available in the inbound data.

Scaling Mapping Modules

Given the complex structure of CDA documents, it is important that mapping scripts are kept as modular, clear, and repeatable as possible. Let’s walk through how we might adapt the current mapVitalSigns.lua to create multiple vital sign entries.

For this example, we’ll assume we have a table T of inbound data that contains the specific data we need loaded in the structure we need. In reality, this is not always the case and you may need to load your inbound data into an intermediate table that allows for easier mapping (aka implement the Canonical Data Model design pattern).