Shamil Nizamov

Unofficial Developer’s Guide to
CDA/CCD on Mirth Connect*
* - Preview Edition

Copyright Page
Copyright © 2014-2015 by Shamil Nizamov
Cover image copyright © 2013 by Shamil Nizamov

All rights reserved. No part of the contents of this book may be reproduced or
transmitted in any form or by any means without the written permission of the author.

Mirth Connect is a trademark of Mirth Corporation. HL7, CDA, CCD and Health Level
Seven are registered trademarks of Health Level Seven International. All other marks are
property of their respective owners.
Any rights not expressly granted herein are reserved.
The companies, organizations, products, domain names, email addresses, logos, people,
places, and/or data mentioned herein in examples are fictitious. No association with any
real company, organization, product, domain name, email address, logo, person, place,
or data is intended or should be inferred.

This book expresses the author’s views and opinions. The information contained in this
book is provided without any express, statutory, or implied warranties. The author, Mirth
Corporation, Health Level Seven International, resellers and distributors will NOT be held
liable for any damages caused or alleged to be caused either directly or indirectly by this
book.

This is a preview edition of the book. The full version is available only at http://ccdonmirth.shamilpublishing.com

Introduction

2

Contents
PART 1

GETTING STARTED

Chapter 1

Mirth Connect Basics................................................................................................ 13
Installation ............................................................................................................... 13
Mirth Connect Administrator .................................................................................... 14
Channels .................................................................................................................. 15
Connectors............................................................................................................... 16
Filters ...................................................................................................................... 17
Transformers............................................................................................................ 17
Scripts...................................................................................................................... 18

Chapter 2

What is a CCD?......................................................................................................... 20
CCD Development Approach ..................................................................................... 20
Templates ................................................................................................................ 22
Summary ................................................................................................................. 24

Chapter 3

System Integration Requirements ............................................................................ 26
Abstraction Layer ..................................................................................................... 26
System Integration Requirements.............................................................................. 29
Testing ..................................................................................................................... 31
Summary ................................................................................................................. 33

Chapter 4

Transforming Data with Mirth Connect ..................................................................... 35
Scenario Overview .................................................................................................... 36
Design Considerations............................................................................................... 38
Summary ................................................................................................................. 40

PART II

CCD BUILDER SERVER IMPLEMENTATION

Chapter 5

Query Sender Channel.............................................................................................. 42
Summary Tab ........................................................................................................... 42
Source Connector ..................................................................................................... 43
Destinations Connector............................................................................................. 45
Summary ................................................................................................................. 49

Chapter 6
3

CCD Builder Channel – Header ................................................................................. 50
Introduction

Summary Tab ........................................................................................................... 51
Source Connector ..................................................................................................... 52
Destinations Connector............................................................................................. 54
Code Templates........................................................................................................ 63
Global Scripts .......................................................................................................... 65
Channel Implementation Verification ........................................................................ 65
Summary ................................................................................................................. 66
Chapter 7

CCD Builder Channel – Allergies ............................................................................... 68
Destinations Connector............................................................................................. 69
Code Templates........................................................................................................ 76
Global Scripts ........................................................................................................... 78
Channel Implementation Verification......................................................................... 79
Summary ................................................................................................................. 80

Chapter 8

CCD Builder Channel – Medications ......................................................................... 81
Destinations Connector............................................................................................. 83
Global Scripts ........................................................................................................... 89
Channel Implementation Verification......................................................................... 90
Summary ................................................................................................................. 90

Chapter 9

CCD Builder Channel – Problems .............................................................................. 91
Destinations Connector............................................................................................. 92
Global Scripts ........................................................................................................... 97
Channel Implementation Verification ........................................................................ 98
Summary ................................................................................................................. 98

Chapter 10

CCD Builder Channel - Results................................................................................. 100
Destinations Connector........................................................................................... 101
Global Scripts ......................................................................................................... 106
Channel Implementation Verification....................................................................... 107
Summary ............................................................................................................... 107

PART III

CCD VALIDATION

Chapter 11

CCD Validation Tools .............................................................................................. 110
XML Schema Validation........................................................................................... 110
Introduction

4

Schematron Validation............................................................................................ 111
MIF Validation ........................................................................................................ 113
Conformance Validation.......................................................................................... 113
Summary ............................................................................................................... 114
Chapter 12

CCD Validation Automation .................................................................................... 115
XML Schema Validation........................................................................................... 116
Schematron Validation............................................................................................ 119
Summary ............................................................................................................... 124

Book Resources.............................................................................................................................. 125

APPENDICES
A: CCD Mirth Templates .......................................................................................... 127
B: Code Templates .................................................................................................. 130
C: HL7v2 Test Messages .......................................................................................... 133
D: XSLT files ............................................................................................................ 134
E: Archive Content .................................................................................................. 140

5

Introduction

Introduction

Introduction
As Mirth Corporation says on their web-site, “Mirth Connect is the Swiss Army knife of
healthcare integration engines, specifically designed for HL7 message integration. It
provides the necessary tools for developing, testing, deploying, and monitoring interfaces.
And because it’s open source, you get all of the advantages of a large community of users
with commercial quality support.”
In addition, “The 2014 HL7 Interface Technology Survey Results” show that Mirth Connect
is one of the fastest growing healthcare messaging platforms due to its open-source
paradigm, and robust functionality for HL7 messaging and X12 documents. Mirth
Connect also speeds up the development of interfaces for data exchange across different
formats and diverse healthcare systems environment.
This book describes version 3.x of Mirth Connect to the point that reader are confident
enough to start building their own healthcare data exchange interfaces and transforming
HL7 messages to CDA/CCD documents.
As you read this book, you will be implementing a fictitious CCD Builder Server. Each
connection point (channel and destination) is explained in a separate chapter, which in
turn provides step-by-step instructions on how to create and code data transformation
rules.
This book is written using Mirth Connect version 3.1.1.7461. Consequently, other releases
may include new features, and features used in this book may change or disappear. You
may also notice differences between screen shots provided in the book and those you
see when using Mirth Connect.

Who is this book for?
I wrote this book primarily for application developers and system integrators who have
found the online Mirth Connect documentation lacking and needed a guidebook that
covers topics in a more detailed and organized way.
A book of this size cannot cover every feature in Mirth Connect v3.x; consequently, I
assume you already have some familiarity with its main components, functions and use.

Introduction

6

Assumption
This book assumes that you are dealing with applications that use message-oriented
middleware products and expects that you have at least a minimal understanding of
Web service technologies including, but not limited to, XML, XML Schemas, XPath and
XSL Transformation.
Before you start reading this book, you should have a basic knowledge of Mirth Connect
development paradigm, JavaScript, Java and E4X objects; and are familiar with operating
system environment variable settings.
You should also have basic knowledge of HL7, the standard that is being used to
exchange healthcare data, both version 2 and version 3. I assume you also familiar with
Clinical Document Architecture (CDA) and, hopefully, Continuity of Care Document
(CCD).

Who should not read this book?
As mentioned earlier, the purpose of this book is to provide the reader with a high-level
overview of the capabilities and features in Mirth Connect v3.x. This book is not intended
to be a step-by-step comprehensive guide or substitute of any kind for training and
certification programs provided by Mirth Corporation.
This book is also not a tutorial on a specific messaging or middleware technology such
Model Driven Health Tools (MDHT) or Mirth CDAPI. All examples included in this book
are for illustrative purposes only. If you are interested in learning more about a specific
technology or product, please refer to one of the many on-line resources, or trainings
and certifications provided by Mirth Corporation or its affiliates.
This book does not cover any specific installation, configuration, deployment or
monitoring activities for system administrators.

Errata and Book Support
I have made every effort to ensure the accuracy of this book and its companion content.
If you find an error, please report through email - mirthconnect@isarp.com

7

Introduction

Warning and Disclaimer
The purpose of this book is to educate and entertain. Every effort has been made to
make this book as complete and accurate as possible, but no warranty or fitness is
implied.
The information is provided on an “as is” basis. The author shall have neither liability nor
responsibility to any person or entity for any loss or damage caused, or alleged to be
caused, directly or indirectly by the information contained in this book or from the use of
software mentioned in this book. The information, methods and techniques described by
the author are based on his own experience. They may not work for you and no
recommendation is made to follow the same course of action. No representation is made
that following the advice in this book will work in your case.
The author is not an employee or representative of Mirth Corporation and never has
been, and author’s views and opinions are not necessarily those of Mirth Corporation.
This book is not based on trainings or certifications provided by Mirth Corporation or its
affiliates.
This book contains links to third-party websites that are not under the control of the
author, and the author is not responsible for the content of any linked site. If you access
a third-party website mentioned in this book, you do so at your own risk. The author
provides these links only as a convenience, and the inclusion of the link does not imply
that the author endorses or accepts any responsibility for the content of those third party sites.
Furthermore, this book contains information on the subject only up to the publication
date.

Acknowledgements
Like most books, this guide has been a long time in the making. I would like to
acknowledge everyone who has assisted in this project. I could not have done this
without you.
I’d like to thank Philip Helger for his contribution to the development of the open-source
Schematron validator.
My biggest thanks go to Wayne Zafft, who was incredibly gracious with his time and
effort in reviewing the final version of the book.

Introduction

8

Roadmap
This book is divided into three parts:
Part I provides an introduction to Mirth Connect and a high-level overview of the CCD
document paradigm.

Chapter 1, Mirth Connect Basics
Introduces Mirth Connect at a high level, provides an overview of the channel
architecture implemented in Mirth Connect, walks the reader through the creation
and configuration of a simple channel.

Chapter 2, What is CCD
Provides an overview of the Continuity of Care Document or CCD, the XML-based
markup standard intended to specify the encoding, structure, and semantics of a
patient summary clinical document for exchange.

Chapter 3, Systems Integration Requirements
Provides a brief overview of system design and systems integration requirements to
demonstrate the complexity of a typical HL7 based integration project.

Chapter 4, Transforming Data within Mirth Connect
Introduces a typical scenario as it is defined in the HL7v3 Normative Edition, presents
the implementation plan for the rest of the book and walks through the required
components.

Part II focuses on the implementation of an imaginary but complete CCD document
generating server.

Chapter 5, Query Sender Channel
Walks the reader through the implementation of the first channel in a chain that
serves as an interface to send HL7v2 messages and handle acknowledgements.

Chapter 6, CCD Builder Channel - Header
Explains the implementation of a channel that plays the major role in this project. The
chapter shows how to establish a MLLP connection to other channels, how to filter
messages based on some criteria and transform part of the inbound messages to
form the CCD header.

9

Introduction

Chapter 7, CCD Builder Channel - Allergies
Expands functionality of the CCD Builder channel by adding a required segment to
the CCD document. Shows a simple transformation pattern using Mirth mapping and
XSL transformation.

Chapter 8, CCD Builder Channel - Medications
Continues implementation of required section level templates. Shows iterations and
mapping of multiple segments.

Chapter 9, CCD Builder Channel - Problems
Continues implementation of required section level templates. Shows iterations and
mapping of multiple segments.

Chapter 10, CCD Builder Channel - Results
Shows how to iterate through segment groups each of which may contain repeating
segments. This chapter concludes implementation of the CCD document.

Part III is dedicated to verification of the CCD document implementation.

Chapter 11, CCD Validation Tools
Introduces a message verification process using different tools and methods such as
XML schema validation, MIF validation, Schematron validation and conformance
review. Lists some open source tools and toolkits that readers may use to build and
test HL7v3 and CDA interfaces.

Chapter 12, CCD Validation Automation
Walks the reader through the implementation of the XML Schema and Schematron
validator scripts using open-source libraries.

Appendices include:

Archive Content
Lists folders and files included in the archive provided with the book.

CCD Mirth Templates
Shows all outbound templates used by the CCD Builder channel’s destinations.

Code Templates
Shows all mapping functions defined as Code Templates functions.

XSL transformation files
Introduction

10

Shows the XSLT file content used to build CCD segment templates.

HL7v2 samples
Lists ADT_A28 and ORU_R01 message samples.

11

Introduction

PART I – GETTING STARTED

Getting Started
CHAPTER 1

Mirth Connect Basics

CHAPTER 2

What is CCD?

CHAPTER 3

System Integration Requirements

CHAPTER 4

Transforming Data with Mirth Connect

PART I – GETTING STARTED

12

CHAPTER 1 Mirth Connect Basics

Mirth Connect Basics
chapter outlines the Mirth Connect installation procedure and basic concepts. All
This
examples in this book are based on the Windows version of Mirth Connect v3.1,
available for downloading at http://www.mirthcorp.com/community/downloads
Make sure your computer meets minimum system requirements before you start:

Oracle JRE version 1.6 or higher;

1 GB of RAM is recommended;

A web browser.

Installation
You can install Mirth Connect in either of two ways based on which package you
downloaded or which package is available on the website. In one case, the package is an
archive of all files and classes you need to run Mirth Connect on your computer. You
simply unzip and copy the package to an appropriate folder, for example to C:\Program
Files\Mirth Connect\. In the other case, there is a GUI based wizard that you start to
go through the steps in the installation. The installation process itself is quite straight
forward.
Both methods install Mirth Connect Server, Mirth Connect Server Manager, Mirth
Connect Administrator and Mirth Connect Command Line Interface. During the
installation you have to decide which port is used by the Mirth Connect Server. The
default is 8080 for unsecure communication and 8443 for the SSL connection. You can
change the ports later using the Mirth Connect Server Manager, if necessary.
To verify the installation:

Launch the Mirth Connect Server either through the Mirth Connect Server Manager
or the Mirth Connect Command Line;

Open the web browser and type localhost:8080 in the address bar;

Click the Access Secure Site button in Web Dashboard Sign In launch page;

Type admin for the user name and repeat admin as the password, click Sign in.

If you see the Dashboard statistics page with, most likely, no channels available, you have
successfully installed Mirth Connect and are ready to continue. If not, refer to Mirth
Connect 3.1 User Guide written by “the same Mirth technical experts who developed the
software” available at - http://info.mirth.com/Connect_Documentation_Download.html
13

PART I – GETTING STARTED

Configuration
The Mirth Connect Server Manager can be used as a single point to launch Mirth
Connect Service, configure ports, allocate memories, and to establish database
connections. However, a fully-fledged configuration description is beyond the scope of
this book.
As a recommended option, add a path to the \custom-lib folder in the operating
system’s CLASSPATH environment variable. This is the folder where you put Java classes,
libraries and other required files that Mirth should be working with.
If any application on your computer or firewall uses ports 8080 or 8443 you can either
change Mirth’s ports by using Mirth Connect Server Manager or by manually modifying
the configuration file located in \conf\mirth.properties. Don’t forget to restart the
Mirth Connect Server or Service to activate your changes.

Mirth Connect Administrator
The Mirth Connect Administrator is a Java application that, by default, is not explicitly
installed on a local computer in a distributed environment. It is downloaded from the
Mirth Connect Server. This ensures the Mirth Connect Administrator matches the version
of the Mirth Connect Server being used.
To download the Mirth Connect Administrator:

Start Mirth Connect Server if it is not already running as a service;

Open the web browser;

Type localhost:8080 in the address bar;

Click Launch Mirth Connect Administrator in the Mirth Connect Administrator launch
page;

Click Ok to open webstart.jnlp;

Type admin for the user name and repeat admin as the password in the Mirth
Connect Login pop-up window, then click Login.

If everything is done correctly, each time you login, you will see the Dashboard as the
initial screen. The Dashboard displays two information panels:

Channels status and statistics – shows the number of messages Received, Filtered,
Queued, Sent, and Errored. The left sidebar of the Dashboard has tasks panel, with
menu options related to your current activity. For example, when you are developing
a channel, menu options such as Refresh, Send Messages, and Remove All Messages

PART I – GETTING STARTED

14

are displayed. These menu items can be also accessed by right clicking on a channel
name in the Channel List.

Logs – Server Log, Connection Log and Global Maps. The Server Log is used to debug
channel development. Double-clicking on a Server Log entry brings a pop-up
window where you can view and copy the entire log entry content. The Server Log is
stored by Mirth Connect Server in the database; closing and opening the Mirth
Connect Administrator brings back all entries not explicitly purged. To clear the
Server Log click Clear Displayed Log under the Server Log or Connection Log area.

Familiarize yourself with other navigation items and tabs since this is the main tool used
to develop and configure channels throughout this book.

Channels
The Channel is an essential part of Mirth Connect and can be seen as one-to-many
abstract unidirectional pipes that decouple components from each other to transfer
healthcare data between two or more applications. The channel architecture
implemented in Mirth Connect can divide a large message processing task into a
sequence of smaller independent steps. This affords developers the flexibility for
dependency, maintenance and/or performance. Some of the processing tasks can even
be external to Mirth Connect and developed independently.

FIGURE 1-1 Mirth Connect abstract channel architecture

In general, each channel consists of inbound and outbound Connectors, Filters and
Transformers. The connector that receives inbound messages from the Sending
Application is called the Source. Similarly, the connector that sends outbound messages
15

PART I – GETTING STARTED

is called the Destination. From the Source connector, data is passed through the channel,
where filters and transformers perform operations on the data, for example, routing a
message to one or another Destinations connector and transforming the data
representation. Deciding each channel’s tasks is when wearing an analyst's hat comes
into play.
Before you create a new channel, you need to elicit the following requirements:

Type of Application the channel reads data from (Source connector type);

Type of Application the channel sends data to (Destination connector type);

Type and format of the inbound message;

Type and format of the outbound message(s);

Mapping table(s) between inbound and outbound messages (Transformation).

Connectors
In terms of Enterprise Integration, the connector is a Message Endpoint that specifies a
particular way or, more accurately, a particular protocol Mirth Connect should use to
communicate with an external application or another Mirth Connect channel.
Mirth Connect supports sending and receiving messages over a variety of connectors
listed here in no particular order:

TCP/MLLP;

Database (MySQL, PostgreSQL, Oracle, Microsoft SQL Server, ODBC);

File (local file system and network shares);

PDF and RTF documents;

JMS;

HTTP (note that HTTPS is not supported in the free version);

SMTP;

SOAP (over HTTP).

The connector that receives the data is called a Reader, for example the MLLP Reader.
The connector that sends the data is called a Writer, the Database Writer is an example.
Connector types are configured under Source and Destinations tabs of the channel.
Obviously, some settings are common across all connectors while others are unique to a
specific connector type.
You can develop your own connector if you need one that is not shipped with the Mirth
Connect installation package, e.g., HTTPS connector. However, this is out of scope of this
book.
PART I – GETTING STARTED

16

Filters
In a real world scenario, when numerous applications and channels are connected, a
channel may receive messages from several sources and may process these messages
differently, based on the message type or other criteria.
There are two paradigms for addressing this requirement, a Router and a Filter:

Router connects to multiple outbound channels. The key benefit of the Router is that
the decision criteria for the destination(s) of a message are maintained in a single
location.

Filter, this is what Mirth Connect uses, is built into a message processing mechanism
and determines whether or not the message should be processed. The Filter inspects
message properties (segments or elements) without removing the message from the
message queue. If the message cannot be consumed by this particular pipe, it is
returned to the queue unchanged for another pipe to filter or process.

Filters can be as simple as comparing specific elements against a hard coded value or as
complex as a scripting language routine. Filters can also be omitted allowing all
messages to pass through. Some routing capabilities have been introduced in Mirth
Connect v3.1 by using a "destinationSet". If a destination is removed from the
destination set, this destination will not receive the message.
If a single channel needs to process more than one type of message, you can create any
number of separate pipes – Destinations - and specify none, one or more filters for each
pipe.

Transformers
More often than not, messages are sent between legacy systems, custom applications
and third-party solutions, each of which is built around a proprietary data model. Even
systems that claim to support a single standard may place specific requirements on data
format and content. If we could bring all legacy systems to a single format when a new
business requirement is proposed, we would avoid conversion issues. Unfortunately, for
most legacy systems, data format, content or data sequence changes are difficult and
risky, and simply not feasible.
How do we communicate data using different formats then? Mirth Connect does this in a
message Transformer that translates one data format into another. As a result, a
destination application can receive messages it understands and which can be processed
and stored in the application’s internal data format.
17

PART I – GETTING STARTED

Mirth Connect allows message transformation to occur at different levels and to chain
message transformers to achieve a required result.
Supported transformers are:

Message Builder maps segments of the inbound message to segments in the
outbound message.

Mapper maps segments of the inbound message to internal Mirth Connect variables.
These variables may be used later.

External Script, as the name suggests, employs external JavaScript routines to
transform or map the data.

XSLT Step utilizes the XSL transformation.

JavaScript, along with External Script, is where flexibility comes into play. Here any
type of (Rhino) Java Script and Java code can be used.

Scripts
Channels also support unique features called Scripts to enhance message processing
logic. Scripts apply to a channel itself and all messages that are passing through.
These scripts are:

Deploy script is executed each time Mirth Connect Server starts or a channel is
redeployed. This is the best place to initialize variables or create class objects.

Attachment script deals with a message in a native format and allows extracting part
of the message to store as an attachment or to irrevocably modify a message.

Preprocessor script also allows handling each message in a native format before
Mirth Connect starts translating it into the internal format, which is XML.

Filter & Transformer scripts are the main places for handling the inbound and
outbound messages.

Response script, as the name suggests, handles the response sent by a destination.

Postprocessor script is executed after the message has been successfully sent.

Undeploy script is launched each time Mirth Connect Server stops. This is the place
to, for example, release memory that was allocated for the classes used by the
channel.

Mirth Connect uses JavaScript as a scripting language with the ability to extend it by calls
of external Java classes. The latter may be one of those included to the Mirth installation
package or user defined.
Besides the channel level, Mirth Connect employs Global Scripts that play the same role
as channel scripts and help in separating the business logic. They have the same Deploy,
PART I – GETTING STARTED

18

Undeploy, Preprocessor and Postprocessor scripts; the only difference is that they apply to
all channels.
This concludes Mirth Connect introduction section. To find out more, you may refer to
numerous web resources, including trainings and books provided by Mirth Corporation.
You may find it helpful to read “Unofficial Mirth Connect v3.x Developer’s Guide“ eBook
which covers Mirth Connect basics and advanced topics in greater details.
This eBook is available at - http://mirthconnect.shamilpublishing.com

19

PART I – GETTING STARTED

CHAPTER 2 What is CCD?

What is CCD?
Continuity of Care Document or CCD, is an XML-based markup standard intended
Theto specify
the encoding, structure, and semantics of a patient summary clinical
document for exchange. (Wiki) From the standard development perspective “the
Continuity of Care Document is a joint effort of HL7 International and ASTM. CCD fosters
interoperability of clinical data by allowing physicians to send electronic medical
information to other providers without loss of meaning and enabling improvement of
patient care. CCD is an implementation guide for sharing Continuity of Care Record (CCR)
patient summary data using the HL7 Version 3 Clinical Document Architecture (CDA),
Release 2.” (HL7 CCD page)
Basically, what has been done is the HL7 Clinical Document Architecture (CDA) is taken
as a document markup standard and constrained by the ASTM Continuity of Care Record
(or CCR also referred to as ASTM E2369-05) data sets into specific headers and
templates. The resulting semantic equivalent was called the Continuity of Care
Document. In the U.S., this specification has been refined further by U.S. federal
incentives known as Meaningful Use stages 1 and 2.

Prerequisites
In case of any discrepancies found in this book, implementers must follow the
conformance requirements of CDA and CCD. You should have following specifications
available:

HL7v3 Normative Edition - HL7 Clinical Document Architecture, Release 2.0;

HL7 Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD).

CCD Development Approach
Besides CCD standard specifications, the CCD distribution package includes CCD and
core HL7 XML schemas, CCD XSLT stylesheets and non-normative examples of
Schematron rules required to validate documents.
From a standard developer point of view, the approach used in this book to develops
core artifacts for the document-level templates (which is CCD in our case) is by taking a
subset of classes defined in the CDA R2 R-MIM model and constraining them to reflect
the ASTM CCR specification.
PART I – GETTING STARTED

20

In general these steps are:

CDA document derives its classes and machine-processable meaning from the HL7
Reference Information Model (RIM) in conjunction with HL7v3 Data Types.

CCD document derives its classes from CDA Refined Message Information Models
(R-MIM).

CCD R-MIM classes are constrained by the ASTM CCR data requirements.

As CCD R-MIM is finalized, the XML schema(s), possibly with other artifacts such as
Model Interchange Format (MIF) files and Hierarchical Message Descriptor (HMD)
views, are generated.

As the last step, CCD XML schema is manually updated to include extensions
required to map ASTM CCR components for which there is no suitable mapping in
CDA R2.

Schematically this may be represented as Figure 2 -1.

FIGURE 2-1 CCD development approach

As you can see, the CCD R-MIM, derived from the CDA R-MIM, follows the same
structure, i.e., it contains a required header to identify the document and participants,
and a body to represent a generic structure of a clinical content.

21

PART I – GETTING STARTED

This method for creating CCD XML schema is based on HL7v3 refinement and
localization mechanism and can be applied to any RIM based artifact (messages or
documents).

Templates
The next level of constraint is based on logical groupings or patterns defined at the
sections and entry levels to provide specific clinical context. Thus, as the HL7 NE states:
“The CDA specification is richly expressive and flexible. Document -level, section-level and
entry-level templates can be used to constrain the generic CDA specification.” Such
patterns, called templates, can “comply with a detailed implementation guide that details
the manner in which structured elements are to be represented and their intended
interpretation to a level sufficient to ensure a degree of clinical safety that is appropriate to
the use case that it is designed to address.” (HL7v3 NE)
This approach brings extended flexibility and allows the creation of a wide variety of
templates which still follow the HL7 standard and CDA defined structure. If you think this
is not enough, CDA allows including both structured and unstructured information at the
CDA Level. The CDA specification distinguishes three incremental levels of conformance
for semantical interoperability.
CDA Level 1: The simplest form of CDA, also known as CDA Level 1, includes the header
and unstructured block where the “NonXMLBody class represents a document body that is
in some format other than XML”. (HL7v3 NE) The CDA Level 1 is not allowed as defined in
the Meaningful Use initiative.
CDA Level 2: Next form is “the CDA specification with section-level templates applied”.
(HL7v3 NE) Section level templates are identified by an associated templateID and
represented in XML.
CDA Level 3: At this level “the CDA specification with entry-level (and optionally sectionlevel) templates applied.” (HL7v3 NE) At this level some section templates contain
discrete data elements called CDA entries.
Thus, built on templates, the CDA R2 implementation guide defines nine document-level
templates, where CCD is only one of them (others include Consultation Note, Diagnostic
Imaging Report, Procedure Note, Discharge Summary, etc.). Potentially they may be
represented as separate XML schemas.

PART I – GETTING STARTED

22

Section-level templates
CDA R2 defines more than 65 section-level templates. Among these are Allergies,
Encounters, Medications, Problem List, etc.
This is schematically 1 shown in Figure 2-2. For simplicity some section-level templates are
not explicitly shown in the figure but represented with … titles.

CDA Sections
CCD sections
MU2
...
...

Allergies

Medical
Equipment

Advance
Directives

...

Medications

...

...

Discharge Diet
Problems

Payers

Results

Consultation Notes sections
MU2
Family History
...
...

Immunizations

Social History

Physical Exam

Present Illness

Past Illness

Reason for
Referral

Encounters

Vital Signs

Plan of Care

Reason for Visit

General Status

...
...

FIGURE 2-2 CDA section-level templates

Document-level templates can exclusively use some section-level templates and share
others. For each document in US Realm, some subsets of section-level templates are
mandatory according to Meaningful Use Stage 2 (MU2).

Entry-level templates
CDA does not stop at the section level but additionally defines up to one hundred entrylevels templates. Examples include, Age, Observation, Encounter Diagnosis,
Immunization Activity, etc.

1

This diagram is for illustrative purpose only. Any discrepancies depicted in the diagram and in the base
specifications are inadvertent and in all cases implementers must follow the conformance requirements of CCD,
CDA and MU2.
23

PART I – GETTING STARTED

As the name suggests, entry-level templates apply to one of the clinical act statements:
Observation, Substance Administration, Supply, Procedure and so on. All entry-level
templates are meant to be machine-processable parts of the document.
Some entry-level templates are used exclusively in one type of CDA document templates.
For example, Discharge Diet template is used only in Discharge Summary. Reason for
Referral entry-level template is required only in Referral Summary (HITSP 2 C48)
document template, etc. Other entry-level templates such as Allergies or Diagnostic
Results are shared among all CDA document level templates.
For illustrative purpose only, an example of the Body Temperature entry-level template is
given in the code snippet below (see Source 2-1).
SOURCE 2-1 BodyTemperature entry-level template
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1937.99.60.5.10.126"/>
<id root="....."/>
<code code="8310-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="Body temperature"/>
<statusCode code="complete"/>
<effectiveTime>
<low value="....."/>
</effectiveTime>
<value xsi:type="PQ" value="....." unit="Cel"/>
</observation>

US Realm related CCD Implementation Guide may recommend additional sections for
conveying healthcare data that conforms to MU2 requirements. MU2 also applies
additional constrains on all template levels.

Summary
This chapter has barely scratched the surface, providing a general overview of one of the
CDA family templates called Continuity of Care Document (CCD) which is semantically
equivalent of ASTM Continuity of Care Record (CCR). Rather than explaining CCD in
depth, which requires a book by itself, this section gives you a basic road map for
exploring and understanding CCD.
If you are not familiar with HL7 and HL7v3 in particular, you may start with HL7v3
Normative Edition and move towards Clinical Document Architecture domain. I wrote
another book, called “Unofficial Developer's Guide to HL7v3 Basics 3” to help you in this
endeavour.
2
3

HITSP - Healthcare Information Technology Standards Panel
Available to download at - http://hl7basics.shamilpublishing.com
PART I – GETTING STARTED

24

Below is a non-exhaustive list of other resources to help you educate yourself on various
aspects of CDA and CCD.
Primary Standard is available on the HL7.org site. You need to register to get access.

CDA® Release 2;

CDA and CCD Implementation Guides are also available on the HL7.org site.

HL7 Implementation Guide: CDA Release 2 – Continuity of Care Document
(CCD) 4;

HL7 Implementation Guide: S&I Framework Transitions of Care Companion Guide
to Consolidated-CDA for Meaningful Use Stage 2, Release 1 – US Realm;

Additionally you may find samples of section and entry level templates.

IHE CDA Section Templates wiki.ihe.net/index.php?title=Category:CDA_Section_Templates

Below are listed quite a few books that I found helpful in this topic. If you are not familiar
with HL7 or CDA in particular, start with Tim Benson’s book then continue with the book
written by Keith Boone.

Principles of Health Interoperability HL7 and SNOMED by Tim Benson.

The CDA Book by Keith W. Boone.

You may also find some technical files. These are provided in the package that is part of
this book:

Non-normative MU2 constrained CCD R-MIM diagram in Visio format (for
illustrative purpose only);

Hierarchical Message Descriptions (HMD) in Excel View derived from the CCD RMIM (for illustrative purpose only).

4

Referred in this book as HL7 CCD.
25

PART I – GETTING STARTED

CHAPTER 3 Systems Integration Requirements

System Integration Requirements
chapter is a brief overview of system design and systems integration requirements
This
for implementing the CDA based system. If you are more or less familiar with HL7
systems implementation you are free to skip it. As you surmise, I have not started
from interoperability in general, or HL7 as a standard, or HL7 Reference Information
Model (RIM) in particular. Undoubtedly, HL7 interoperability is crucial to the integration
of clinical health information systems. It is the cornerstone of HL7v3 and may be used as
a key selling point of HL7v3. But my experience shows that focussing on interoperability
adds little value for software developers. For them, HL7v3 format, which CDA and CCD
are based on, is a fait accompli and the task at hand is to implement it.

Abstraction Layers
As a software developer you know that building an enterprise level information system
requires proper layers of abstraction. N-tier architecture provides a high degree of
decoupling, separating presentation, business logic and data tiers. Information
technology came to this solution after much trial and error. If business needs were stable
such a solution would not be required. However, today’s business, eHealth in particular,
faces constant change from new regulatory requirements (e.g., EHR Meaningful Use
stage 1 to 3 in the USA), market changes and improvements in operational processes. To
achieve flexibility, various types of abstraction layers are possible to hide the
implementation details of particular functions and integrate them based on their
purpose.
The Abstraction Layer shown in Figure 3-1 hides the complexity of the back-end system,
letting the application request the data using well-organized meaningful calls and
without having to worry about the actual data location and structure.
In this diagram, data is stored in the Data Repository. The purpose of it is to show that
medical data may be located in different sources: relational databases, spreadsheets,
documents, flat files and “clouds” as more mobile applications emerge.
Consider the notional flow of data for such a simple system:
1. The Application makes a request to the Abstraction Layer to retrieve the patient
medical information;
2. The Abstraction Layer makes a request to the Data Repository;
PART I – GETTING STARTED

26

3. If data is available, the Data Repository returns it to the Abstraction Layer;
4. The Abstraction Layer forms the data in the way the Application expects and sends it
to the Application;
5. The Application processes the data and uses it as intended.

FIGURE 3-1 Simple system architecture using an abstraction layer

Even this simple scenario is missing key elements: the alternative and exception flows are
not shown, leaving the Application unaware if data is unavailable for one reason or
another; also, this scenario does not tell if data sources are physically distribu ted or
hosted on different operating systems and/or or data storage environments (e.g.,
databases from different vendors).
What if the Abstraction Layer cannot find the data in the Data Repository? If business
logic allows there will be additional steps to request data from a remote system probably
using one of the HL7 messaging standards.
Figure 3-2 schematically shows an abstract system with added CCD document building
capability. If you are not familiar with the HL7 and CDA standards, you may wonder why
there are several streams (only four are shown but there may be more), each of which
has its own message translator and content enricher. Also, what data sources are these
two streams are using? We will explore this in following chapters.
You may think of the Abstraction Layer as a Database Access Layer (DAL) that
encapsulates all requests to data sources. It may also function as an Enterprise Service
Bus (ESB) in a message-oriented processing model that supports synchronous or
asynchronous communications, content-based message forwarding and filtering,
transformation functionalities and mapping between different interfaces. Since DALs or
ESBs are often implemented in very different ways, requiring a broad range of specific
functionalities and operating characteristics, I will use the term Abstraction Layer to avoid
confusion with vendor-specific implementations.
27

PART I – GETTING STARTED

FIGURE 3-2 System architecture with CDA builder capability

Assuming a Web Service is used to deliver a document, the notional data flow with
added CCD Builder functionality may be described as:
1. The Application makes a request to the Abstraction Layer to retrieve the patient
medical information.
2. The Abstraction Layer makes a request to the Data Repository.
3. If data is available, the Data Repository returns it to the Abstraction Layer.
4. The Abstraction Layer forms the data in the way the Application understands and
sends it to the Application. The latter sends the data to the CCD Builder component.
5. The CCD Builder component, in turn, forms parts of the document, aggregates them
into a single document, wraps the message in a SOAP envelope or other transport
mechanism, and sends it to the remote system or storage.
6. The HL7v3 Receiver component gets the response, verifies that the response belongs
to this destination, extracts the payload and passes it to the Abstraction Layer.
7. The remote system processes the data and uses it as intended.
Besides typical alternative and exception flows related to communication, questions that
left unanswered are:

If the patient medical information is not available in the Data Repository, what should
the system do?
PART I – GETTING STARTED

28

If the local Data Repository contains data that differs from data in the remote system,
and the local data is older, what should the system do?

If the remote system asks for a set of data but CCD is not capable of conveying such
data to fulfil the remote system need, what should the Application do?

Such questions may significantly affect the architecture, implementation and ultimately
the functionality of the system. Let’s consider other aspects that may influence the HL7
based system architecture.

System Integration Requirements
Different types of requirements shape a system’s behavior. Stakeholders (users, sponsors,
clients, etc.), healthcare practitioners and subject matter experts (SMEs) are typically
good at eliciting all levels (organizational, system, component) of functional
requirements. Undoubtedly, developers will be provided with a huge list of functional
system requirements, probably with a great number of use cases. Presumably, these
requirements are complete, consistent, unambiguous, feasibly implemented and
verifiable. As such, they provide a concrete basis for the developed system.
Customers are usually not interested in seeing how functional requirements are
implemented. The terms they use to describe system functionality, more often than not,
apply to direct or indirect non-functional requirements (NFR), such as qualities and
constraints. NFRs represent a significant delivery risk to a project since neglecting or
improperly dealing with NFRs during the initial requirements elicitation process, or
during the system development lifecycle, leads to inaccurate estimation of project’s
scope and efforts. Errors due to omitting NFRs or to insufficient attention paid to their
analysis are among the most expensive and difficult problems to correct.
Among a huge list of non-functional requirements, there are some that affect healthcare
systems integration. A few, for illustrative purposes, are discussed here to show the
consequences of (not) implementing them. NFRs are listed in no particular order.

Auditability
Auditability is the ability of the system to keep the audit logs so that interactions with
other systems can be inspected. Unlike other communication systems, HL7 messages
often include sensitive medical information (also see Security). Meeting the legal
requirements for auditability leads to a number of questions such as what data to collect,
how to store it, how to prevent unauthorized access to audit records, and how to
maintain data integrity. Depending on workflow, the number of messages exchanged by
29

PART I – GETTING STARTED

systems can be significant and the number of transactions will grow over time. This raises
the issue of predicting hardware capacity growth, particularly if the legal requirement is
to keep all communicated messages for several years. Additional implementation
considerations arise from backup, disaster recovery plan and retention period
requirements.

Performance
Performance is one of the most ambiguous runtime non-functional requirements. The
user expectation is typically characterized as “the system should be fast” and written as “a
transaction should take less than N seconds to complete”. However neither specifies if a
transaction is considered complete when a response message enters a system, or when
the end-user sees the result of the initial (for example, search query) request. If it is the
latter, does it consider both the system’s messaging component performance
requirement and system’s user interface performance requirement? If there is another
requirement to put mechanisms into place that automate some levels of conformance
testing of incoming messages, does the original “… N seconds to complete” still apply
during peak hours? If a transaction has timed out, does the original “… N seconds to
complete” mean N seconds to successful conclude the transaction, or just N seconds
before the end-user receives some kind of feedback? Decisions made here also affect
scalability.

Security
Security in healthcare systems is paramount given the sensitive, personal information
maintained and communicated and to protect from fraud and other breaches. There are
many great books that cover security from different aspects and levels of granularity. If
you are new to the healthcare industry, you need to know that, besides typical computer
systems security requirements, national health sectors often specify their own security
requirements (e.g., Health Insurance Portability and Accountability Act or HIPAA in the
USA) to protect highly sensitive medical information from fraud and security breaches .
Violations of such regulations can lead to lawsuits and other enforcement actions. Even if
not applied directly to the CDA standard, some of the security rules that HIPAA regulates
are: audit controls to review healthcare system activities, and transmission security which
includes integrity controls and encryption/decryption during transmission. Other
countries may apply other international and local legislation acts, which can greatly
affect the way HL7 messages are structured, processed or communicated (e.g., Personal
Health Information Protection Act or PHIPA, and Personal Information Protection and
Electronic Documents Act aka PIPEDA in Canada).
PART I – GETTING STARTED

30

Transactional Reliability
Transactional reliability determines the portion of successfully completed transactions,
(i.e., number of messages delivered to, processed, and returned by a remote system).
Transactional reliability is measured, from a positive perspective, as service availability,
for example, 99.998%. This metric, however, may affect transaction timeout settings and
performance.

Testing
Be it through a waterfall, agile or another approach to system development, sooner or
later functional and non-functional aspects of the system need to be tested. You may
already use or be familiar with such widely adopted agile practices as Test-Driven
Development and Behavior-Driven Development aimed at creating reliable and
maintainable code. Whatever testing strategy you choose, they can probably be
categorized as using business-facing and technology-facing test models (introduced by
Brian Marick). On the business-facing side, functional acceptance testing verifies how the
system is built, including functionality, capacity, usability, security, modifiability,
availability, etc. The technology-facing tests are commonly used by developers during
the development process: unit tests, component tests, and deployment tests.

Integration testing
Integration testing is especially crucial for a system that communicates with other
systems using different protocols, or for a system consisting of loosely coupled
components (units, modules).
Integration testing is generally performed in these different contexts:

Test Harness – an environment that developers build to test the system. It may be
part of unit testing.

User Acceptance Testing (UAT) environment which is as similar to a production
environment as possible.

Production environment.

Ideally, you would be provided with a replica of a system that behaves exactly like the
production system and allows performance, capacity, security and other functional and
non-functional requirements to be tested. However, in the real world, you will often need
to develop such an environment on your own. It is therefore essential that your
environment allows for the testing of unexpected situations such as network transport
problems, protocol problems and external systems (logic) problems.
31

PART I – GETTING STARTED

Test data
Performing business-facing tests (acceptance testing) and technology-facing tests
(integration testing and sometimes unit testing) is not possible without test data, which
raises the issue of managing test data.
The test team is often provided with a dump of data from the production environment.
These data usually consist of three broad groups: test specific data, test reference data
and application reference data. For technology-facing tests such as unit tests, the
developer may create a smaller dataset of fake test data that covers all three groups.
Other types, such as acceptance-testing, integration testing, non-functional testing need
more sophisticated test data to verify desired behavior against the system’s integration
requirements.
Capacity testing unveils the issue of scaling up existing data to create sufficient volumes
of representative data for different performance-related test cases.
A key challenge for managing test data in a healthcare systems development
environment is to comply with current legislations and regulations aimed at protecting
the privacy of patient’s personal demographic and health information – specifically to
prevent disclosing either the identity or other attributes of private individuals. This is
where de-identification comes into play. De-identification of patients’ information is
essential where data is disclosed for testing (and also often analytical) use. Deidentification of health data is an important topic by itself and requires separate books.
Reasons for healthcare data de-identification include: developers’ laptops, hard disks or
USB flash drives may be lost or stolen; a company may experience "sophisticated
computer security attack" against their servers; and other breaches (recent breach
reports may be found at databreachtoday.com website). Indeed, media outlets are quick
to report data breaches involving (stolen) patient health data. Additionally, many
jurisdictions have breach notification laws that requires notifications to be sent to
regulatory bodies, including media, if data breaches occur.
Before I continue, I’ll give a short quiz. Which of these three sets of personal information
is de-identified? Consult the White Pages if you want.
Rhonda James; DOB: 08-Sep-1988; Address: 71 Ansubet Dr, Charleston, WV
Denise Lewis; DOB: 03-Mar-1976; Address: 23 Adams Chapel Rd, Mankato, MN
Rosemarie Hardy; DOB: 14-Nov-1985; Address: 310 Camp Creek Rd, Weston, MA
And so, how many Denise Lewis’s live in Minneapolis?

PART I – GETTING STARTED

32

In fact, the source 5 that provided these samples suggested that all three are de-identified
data. Imagine if such de-identified datasets are stolen and reported as “the data breach”
by the media. The company may face severe fines and damage to its reputation long
before it can be proven that the stolen datasets are fictitious and do not represent any
real person.
There are different algorithms for record-level data de-identification such as: data
reduction, data modification and data suppression. Before you start implementing your
own, I recommend you read the Tools for De-Identification of Personal Health
Information6 report written by Ross Fraser and Don Willison for the Pan Canadian Health
Information Privacy (HIP) Group. This report explains major techniques, requirements f or
health data de-identification tools, and some of the commercially available tools.
Other sources worth reading:

A Canadian standard: “Best Practice” Guidelines for Managing the Disclosure of DeIdentified Health Information.

A standard from US Department of Health and Human Services: Guidance Regarding
Methods for De-identification of Protected Health Information in Accordance with the
Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule.

Guidance from the UK Information Commissioner's Office: Anonymisation: managing
data protection risk code of practice.

Summary
This chapter shows that in addition to typical software development issues, the HL7based development project has layers of additional complexity due to interconnected
functional and non-functional requirements.
Healthcare by itself is a difficult domain. Software developers that see CDA documents as
yet another XML-based feed system run the risk of significantly underestimating the
effort needed to complete a project.
HL7 development requires not only properly eliciting and documenting functional and
non-functional requirements, but also the eHealth landscape in which the project
operates. You may be committed to build a scalable application capable of constructing
countrywide level CDA document and processing all section-level templates, but your
local regulatory restrictions may prevent sharing personal information with other
5

The source will not be disclosed. They received my opinion and suggestion.
Available to download at - https://www.ehealthinformation.ca/knowledgebase/getAttach/15/AA00118/Tools_for_De-identification_EN-FINAL.pdf
6

33

PART I – GETTING STARTED

jurisdictions. Consider time and effort spent on building unnecessary functionality before
it becomes obvious.
Testing HL7-based systems is a separate (sub) project by itself. It must conform to
eHealth industry and local regulatory auditing and security requirements to protect
sensitive information, and may require test data sets to be prepared upfront.
Before you start building HL7 messaging application, it is essential that you understand
the full complexity of HL7v3 based development work.

PART I – GETTING STARTED

34

CHAPTER 4 Transforming Data with Mirth Connect

Transforming Data with Mirth
other universal domains in the HL7v3 Normative Edition , the Clinical Document
Unlike
Architecture does not specify storyboards, interactions and participants. This domain
deals only with the CDA document exchange markup. On the other side, Mirth
Connect provides greater freedom in data transformation since it allows using different
techniques for data mapping such JavaScript, XSLT and Java.
“Messaging” and “document” are understood differently by developers, end users and
clinicians. A lab report in PDF format sent as an attachment by email is one of the
options but such scenarios are not what I want to explore in this book. Before
implementing an imaginary CCD Builder Server using Mirth Connect, we need to
examine what we are trying to build. Also, it is good to note that this s erver is
“imaginary” because the goal is to fully concentrate on Mirth Connect features rather
than on actual CCD or MU2 business rules.
Note:

Before we start, I would like to stress that HL7 interactions and templates (in
terms of CDA) shown in this book do not represent a real implementation and
should not be used “as is”.

Some words of caution should be raised before delving any deeper. The Mirth Connect
HL7v2 messages parser is based on HAPI API which uses HL7 organization specified data
types. However, in a real word scenario, it is rare that HL7v2 (and HL7v3) messages
match the HL7 defined standard exactly. There are always some differences between a
particular message type and the industry standard. The same is true about HL7 RIM
based messages and document templates.

Prerequisites
Mirth Connect: All source code samples in this book are based on Mirth Connect scripts.
Make sure that Mirth Connect is installed and properly configured on your computer. It
is also assumed that you have basic understandings of features and techniques that
Mirth Connect uses.
HL7v2: Data source for the CCD will be based on incoming HL7v2 messages therefore a
working knowledge of the HL7 v2.x message structure and messaging protocols is
required.

35

PART I – GETTING STARTED

HL7v3: Readers are assumed to know HL7v3 concepts and the Reference Information
Model (RIM), as well as HL7v3 data types. Additionally, readers should have an
understanding of vocabularies and terminologies such as SNOMED CT, LOINC, ICD, etc.

Scenario Overview
To give you a sense of how CCD Builder Server may work in a real life scenario, I would
like to quote several narratives of relevant interactions from the HL7v3 Normative Edition
2014.
If you are not familiar with this concept, the storyboard in HL7 terms is “a narrative of
relevant events defined using interaction diagrams or use cases. The storyboard provides
one set of interactions that the modeling committee expects will typically occur in the
domain.” (HL7NE)
To begin with: “Mr. Adam Everyman's physician, Dr. Patricia Primary, called the Good
Health Hospital to schedule an inpatient visit for Mr. Everyman for lung surgery. The clerk
verified that Mr. Everyman was not already registered as a patient in the GHH Patient
Registry and created a new patient record for him then scheduled the admission for two
weeks from that day.” (HL7NE > Patient Registry Record Added > PRPA_ST201301UV01)
Later on, Mr. Adam Everyman “presents at Good Health Hospital Outpatient Clinic and is
seen by Dr. Bill Beaker. Adam reports extreme thirst, fatigue, and recent unexplained
weight loss. He also reports having a family history of diabetes. Dr. Bill Beaker wants to
rule out diabetes mellitus by performing a GTT2HR. Upon the release of the results for the
complete GTT2HR test, the laboratory system reports all the results in a single message.”
(HL7NE > Complex Laboratory Result > POLB_ST221000UV01)
Once laboratory results are available, Dr. Bill Beaker observes them as a single document
and submits them to the Good Health Hospital for use during the scheduled inpatient
visit for Mr. Everyman.
(Patient and doctors names in storyboards are changed to match one another.)
As you can see, several parties, also called Application Roles, are involved in this process.
Application role is “an abstraction that expresses a portion of the messaging behavior of
an information system.” (HL7NE)
Thus, we may identify the following application roles that will be represented as system
components:
PART I – GETTING STARTED

36

Message Originator – creates messages and publishes (sends) them to a receiver
(played by Patient Registry or Document Originator in our case).
Patient Registry – represents the Patient Demographics Management System.
Document Originator – creates a CCD document.
The next step is to depict interactions between these three application roles. An
interaction is “a single, one-way information flow that supports a communication
requirement expressed in a scenario.” (HL7NE)

Interaction model
The Interaction Model for storyboards defined above shows interactions between
application roles and is described using the sequence diagram (Figure 4-1).

Message
Originator

Document
Originator

Patient Registry
ADT_A28

ACK

ORU_R01

ACK
query

response

FIGURE 4-1 Interaction diagram

As a base for the model’s interactions I have chosen to use HL7v2 transactions, though
the same can be done using relevant HL7v3 transactions. Thus, the Patient Registry
Record Added (PRPA_IN201301UV01) may be used instead of ADT_A28, along with the
Result Complete with Fulfillment (POLB_IN224200UV01) instead of ORU_R01. The reason
why HL7v3 messages are not used is because they are already in a format that is very
37

PART I – GETTING STARTED

close to the final CCD document. This may over simplify this project and hide important
Mirth Connect details.
The interaction model has been intentionally complicated by adding an interim step to
store patient demographics instead of sending it directly to the Document Originator. So
let us quickly go through this sequence diagram to see how it works.
1. The Message Originator does a preliminary step by sending an ADT_A28 (Add Person
or Patient Information) message to a temporary storage which plays the role of the
database that holds patient-related information. Jumping ahead, I know that we will
not be using any databases though you are free to try. The Patient Registry, in turn,
may acknowledge the message.
2. The Message Originator sends an ORU_R01 (Unsolicited Observation Message)
message to the Document Originator. The latter may acknowledge this message and
then starts transforming and compiling the CCD document from the data it has
received. At some point, the Document Originator may require patient demographic
data if it was not fully provided in the ORU_R01 message. In such a case, the
Document Originator makes an (internal) request to the Patient Registry and uses the
data that the Patient Registry returns.

Design Considerations
There are many ways to accomplish the same task in Mirth Connect. In addition, there
are many ways to build a valid CDA/CCD document. However, the main idea of this book
is to explore Mirth Connect features, NOT to implement the service in a correct way
using standard de-facto libraries such as Model Driven Health Tools (MDHT). The actual
implementation of a real system most likely is different from this one.
The diagram in Figure 4-2 illustrates the game plan for next parts of the book and
mimics the scenario of sending the HL7v2 messages to the CCD Builder.
The implementation plan is based on followings channels:

Sender – a channel that plays a role of the Message Originator and serves as an
interface to handle and place an original ADT or ORU messages into the pipe using
the MLLP Message Transport protocol.

CCD Builder – a channel that does all heavy lifting. Later we will see that this
channel builds separate section-level templates and then compiles them into a single
CCD document. This channel plays the role of the Document Originator.
PART I – GETTING STARTED

38

Global Map – the Global Map, in Mirth Connect terms, represents the Patient
Demographics Management System. Its main duty is to temporary store patient
demographic data.
Global Map
HL7v2
(ADT_A28,
ORU_R01)

MLLP

MLLP

Reader

Sender

File Writer

CCD Builder

Transform

ACK / NACK

Transform

CCD
File Writer

ACK / NACK

FIGURE 4-2 CCD Builder Server channels implementation plan

Throughout this implementation we will explore some major connectors: Channel
Reader, TCP/IP Listener and Sender and File Writer.
We will use all techniques explained earlier in this book which includes, but is not limited
to: filters, transformers, code templates, maps, global and channel scripts.
At this point it is assumed that you are comfortable with the Mirth Connect
Administrator.

Recommended tools and packages
To make the development easier and less tedious, here is a list of recommended tools
and packages. You are free to use any other tools that suit you better.

HL7v2 viewer such as Messaging Workbench or HL7Spy by Inner Harbour Software;
HL7v3 viewer such as Altova XMLSpy by Altova GmbH;

And last but not least, use the XML schemas and other related files from the archive
provided with this book.

Summary
This section identified players and outlined the game plan. To do this we went through
the storyboards as they are defined by HL7v3 Normative Edition, identified application

39

PART I – GETTING STARTED

roles and interactions between them. This helped us depict the interaction model and
translate it to the Mirth Connect channels implementation plan.
In the next part of the book, we will implement these channels in Mirth Connect.

This is a preview edition of the book.
The full version with all related files is available to download at

http://ccdonmirth.shamilpublishing.com

PART I – GETTING STARTED

40

Book Resources

Book Resources
Other titles you may be interested in:

Unofficial Mirth Connect v3.x Developer's
Guide
This book introduces readers to version 3.x of Mirth
Connect to the point that they are confident enough
to start building their own healthcare data exchange
interfaces.
By implementing an imaginary Eligibility Query
Service, this book covers some of the topics on XML
schema and Schematron validation, XSL
Transformation, database connection pool creation,
acknowledgements implementation, Mirth Connect
extensions implementation and sending objects via
the ActiveMQ Message Broker.
The book is available to download at –
http://mirthconnect.shamilpublishing.com

Unofficial Developer's Guide to HL7v3 Basics
This book introduces readers to HL7 version 3 to the
point that they are confident enough to start building
their own healthcare data exchange interfaces. The
book provides clear and easy to use, step-by-step
guidance for learning the standard, with numerous
examples covering many topics.
The book is available to download at –
http://hl7basics.shamilpublishing.com

APPENDICES

Appendices
A: CCD Mirth Templates
B: Code Templates
C: HL7v2 Test Messages
D: XSLT files
E: Archive Content
These are files provided as supplementary materials required for parts II and III.
Folder
..\Channels\

..\Models\coreschemas\

..\Models\Schemas\

..\Models\ExcelView\
..\Models\HTMLView\
..\Models\MWBModels\

..\Models\PictureView\
..\Models\VisioModels\

..\SampleMessages\CCD\

Files
CCD Builder.xml
Code Templates.xml
Global Scripts.xml
Query Sender.xml
datatypes-base.xsd
datatypes-rX-cs.xsd
datatypes.xsd
infrastructureRoot.xsd
NarrativeBlock.xsd
voc.xsd
CCD-Body.xsd
CCD-Header.xsd
POCD_MT000041SN.xsd
POCD_MT000042SN.xsd
POCD_MT000041SN.xls
POCD_MT000042SN.xls
POCD_MT000041SN.htm
POCD_MT000042SN.htm
Add Person or Patient Information.mwb
Unsolicited Observation Message.mwb
MsgStructure.txt
POCD_RM000041SN-Header.png
POCD_RM000042SN-Body.png
POCD_RM000041SN-Header.vsd
POCD_RM000041SN-Header.xml
POCD_RM000042SN-Body.vsd
POCD_RM000042SN-Body.xml
CCD_Allergies_Mirth_Template.xml
CCD_Body_Mirth_Template.xml
CCD_Header_Mirth_Template.xml

Comment
Mirth Connect channels, code
templates and global scripts
discussed in this book
HL7 core XML schema files required
to validate CCD document instances

Localized, non-normative XML
schemas for CCD header and CCD
body parts.
Document element descriptions in
MS Excel format
Document element descriptions in
HTML format
Messaging Workbench (MWB)
models to validate ADT and ORU
message samples.
CCD header and body R-MIM
representation
CCD header and body R-MIM models
in Visio format

Parts of CCD document to serve as
outbound Mirth Connect templates
for the CCD Builder channel’s

\SampleMessages\HL7v2
..\XSLT\

43

APPENDICES

CCD_Header_Template_annotated.xml
CCD_Medications_Mirth_Template.xml
CCD_Problems_Mirth_Template.xml
CCD_Results_Mirth_Template.xml
ADT_A28.hl7
ORU_R01.hl7
Allergies_Entry.xslt
Medications_Entry.xslt
NoResults_Entry.xslt
Problems_Entry.xslt
Results_Entry.xslt

destinations

Samples of HL7v2.6 messages (uses
v2.7 datatypes)
XSL Transformation scripts required
for CCD Builder channel’s
destinations