Unofficial Developer’s Guide to CDA/CCD on Mirth Connect

Shamil Nizamov
<strong>Unofficial</strong> <strong>Developer’s</strong> <strong>Guide</strong> <strong>to</strong>
<strong>CDA</strong>/<strong>CCD</strong> 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, <strong>CDA</strong>, <strong>CCD</strong> 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, statu<strong>to</strong>ry, or implied warranties. The author, Mirth
Corporation, Health Level Seven International, resellers and distribu<strong>to</strong>rs will NOT be held
liable for any damages caused or alleged <strong>to</strong> 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 Administra<strong>to</strong>r .................................................................................... 14
Channels .................................................................................................................. 15
Connec<strong>to</strong>rs............................................................................................................... 16
Filters ...................................................................................................................... 17
Transformers............................................................................................................ 17
Scripts...................................................................................................................... 18
Chapter 2 What is a <strong>CCD</strong>?......................................................................................................... 20
<strong>CCD</strong> 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
<strong>CCD</strong> BUILDER SERVER IMPLEMENTATION
Chapter 5 Query Sender Channel.............................................................................................. 42
Summary Tab ........................................................................................................... 42
Source Connec<strong>to</strong>r ..................................................................................................... 43
Destinations Connec<strong>to</strong>r............................................................................................. 45
Summary ................................................................................................................. 49
Chapter 6 <strong>CCD</strong> Builder Channel – Header ................................................................................. 50
3 Introduction

Summary Tab ........................................................................................................... 51
Source Connec<strong>to</strong>r ..................................................................................................... 52
Destinations Connec<strong>to</strong>r............................................................................................. 54
Code Templates........................................................................................................ 63
Global Scripts .......................................................................................................... 65
Channel Implementation Verification ........................................................................ 65
Summary ................................................................................................................. 66
Chapter 7 <strong>CCD</strong> Builder Channel – Allergies ............................................................................... 68
Destinations Connec<strong>to</strong>r............................................................................................. 69
Code Templates........................................................................................................ 76
Global Scripts ........................................................................................................... 78
Channel Implementation Verification......................................................................... 79
Summary ................................................................................................................. 80
Chapter 8 <strong>CCD</strong> Builder Channel – Medications ......................................................................... 81
Destinations Connec<strong>to</strong>r............................................................................................. 83
Global Scripts ........................................................................................................... 89
Channel Implementation Verification......................................................................... 90
Summary ................................................................................................................. 90
Chapter 9 <strong>CCD</strong> Builder Channel – Problems .............................................................................. 91
Destinations Connec<strong>to</strong>r............................................................................................. 92
Global Scripts ........................................................................................................... 97
Channel Implementation Verification ........................................................................ 98
Summary ................................................................................................................. 98
Chapter 10 <strong>CCD</strong> Builder Channel - Results................................................................................. 100
Destinations Connec<strong>to</strong>r........................................................................................... 101
Global Scripts ......................................................................................................... 106
Channel Implementation Verification....................................................................... 107
Summary ............................................................................................................... 107
PART III
<strong>CCD</strong> VALIDATION
Chapter 11 <strong>CCD</strong> Validation Tools .............................................................................................. 110
XML Schema Validation........................................................................................... 110
Introduction 4

Schematron Validation............................................................................................ 111
MIF Validation ........................................................................................................ 113
Conformance Validation.......................................................................................... 113
Summary ............................................................................................................... 114
Chapter 12 <strong>CCD</strong> Validation Au<strong>to</strong>mation .................................................................................... 115
XML Schema Validation........................................................................................... 116
Schematron Validation............................................................................................ 119
Summary ............................................................................................................... 124
Book Resources.............................................................................................................................. 125
APPENDICES
A: <strong>CCD</strong> 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 <strong>to</strong>ols for developing, testing, deploying, and moni<strong>to</strong>ring 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 <strong>to</strong> 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 <strong>to</strong> the point that reader are confident
enough <strong>to</strong> start building their own healthcare data exchange interfaces and transforming
HL7 messages <strong>to</strong> <strong>CDA</strong>/<strong>CCD</strong> documents.
As you read this book, you will be implementing a fictitious <strong>CCD</strong> Builder Server. Each
connection point (channel and destination) is explained in a separate chapter, which in
turn provides step-by-step instructions on how <strong>to</strong> 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 integra<strong>to</strong>rs who have
found the online Mirth Connect documentation lacking and needed a guidebook that
covers <strong>to</strong>pics 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 <strong>to</strong>, 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 <strong>to</strong>
exchange healthcare data, both version 2 and version 3. I assume you also familiar with
Clinical Document Architecture (<strong>CDA</strong>) and, hopefully, Continuity of Care Document
(<strong>CCD</strong>).
Who should not read this book?
As mentioned earlier, the purpose of this book is <strong>to</strong> provide the reader with a high-level
overview of the capabilities and features in Mirth Connect v3.x. This book is not intended
<strong>to</strong> 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 tu<strong>to</strong>rial on a specific messaging or middleware technology such
Model Driven Health Tools (MDHT) or Mirth <strong>CDA</strong>PI. 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 <strong>to</strong> 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
moni<strong>to</strong>ring activities for system administra<strong>to</strong>rs.
Errata and Book Support
I have made every effort <strong>to</strong> 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 <strong>to</strong> educate and entertain. Every effort has been made <strong>to</strong>
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 <strong>to</strong> any person or entity for any loss or damage caused, or alleged <strong>to</strong> 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 <strong>to</strong> 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 <strong>to</strong> 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 thirdparty
sites.
Furthermore, this book contains information on the subject only up <strong>to</strong> the publication
date.
Acknowledgements
Like most books, this guide has been a long time in the making. I would like <strong>to</strong>
acknowledge everyone who has assisted in this project. I could not have done this
without you.
I’d like <strong>to</strong> thank Philip Helger for his contribution <strong>to</strong> the development of the open-source
Schematron valida<strong>to</strong>r.
My biggest thanks go <strong>to</strong> 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 in<strong>to</strong> three parts:
Part I provides an introduction <strong>to</strong> Mirth Connect and a high-level overview of the <strong>CCD</strong>
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 <strong>CCD</strong>
Provides an overview of the Continuity of Care Document or <strong>CCD</strong>, the XML-based
markup standard intended <strong>to</strong> 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 <strong>to</strong>
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 <strong>CCD</strong> 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 <strong>to</strong> send HL7v2 messages and handle acknowledgements.
• Chapter 6, <strong>CCD</strong> Builder Channel - Header
Explains the implementation of a channel that plays the major role in this project. The
chapter shows how <strong>to</strong> establish a MLLP connection <strong>to</strong> other channels, how <strong>to</strong> filter
messages based on some criteria and transform part of the inbound messages <strong>to</strong>
form the <strong>CCD</strong> header.
9 Introduction

• Chapter 7, <strong>CCD</strong> Builder Channel - Allergies
Expands functionality of the <strong>CCD</strong> Builder channel by adding a required segment <strong>to</strong>
the <strong>CCD</strong> document. Shows a simple transformation pattern using Mirth mapping and
XSL transformation.
• Chapter 8, <strong>CCD</strong> Builder Channel - Medications
Continues implementation of required section level templates. Shows iterations and
mapping of multiple segments.
• Chapter 9, <strong>CCD</strong> Builder Channel - Problems
Continues implementation of required section level templates. Shows iterations and
mapping of multiple segments.
• Chapter 10, <strong>CCD</strong> Builder Channel - Results
Shows how <strong>to</strong> iterate through segment groups each of which may contain repeating
segments. This chapter concludes implementation of the <strong>CCD</strong> document.
Part III is dedicated <strong>to</strong> verification of the <strong>CCD</strong> document implementation.
• Chapter 11, <strong>CCD</strong> Validation Tools
Introduces a message verification process using different <strong>to</strong>ols and methods such as
XML schema validation, MIF validation, Schematron validation and conformance
review. Lists some open source <strong>to</strong>ols and <strong>to</strong>olkits that readers may use <strong>to</strong> build and
test HL7v3 and <strong>CDA</strong> interfaces.
• Chapter 12, <strong>CCD</strong> Validation Au<strong>to</strong>mation
Walks the reader through the implementation of the XML Schema and Schematron
valida<strong>to</strong>r scripts using open-source libraries.
Appendices include:
• Archive Content
Lists folders and files included in the archive provided with the book.
• <strong>CCD</strong> Mirth Templates
Shows all outbound templates used by the <strong>CCD</strong> 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 <strong>to</strong> build <strong>CCD</strong> segment templates.
• HL7v2 samples
Lists ADT_A28 and ORU_R01 message samples.
11 Introduction

PART I – GETTING STARTED
Getting Started
CHAPTER 1
CHAPTER 2
CHAPTER 3
CHAPTER 4
Mirth Connect Basics
What is <strong>CCD</strong>?
System Integration Requirements
Transforming Data with Mirth Connect
PART I – GETTING STARTED 12

CHAPTER 1 Mirth Connect Basics
Mirth Connect Basics
T
his chapter outlines the Mirth Connect installation procedure and basic concepts. All
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 <strong>to</strong> run Mirth Connect on your computer. You
simply unzip and copy the package <strong>to</strong> an appropriate folder, for example <strong>to</strong> C:\Program
Files\Mirth Connect\. In the other case, there is a GUI based wizard that you start <strong>to</strong>
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 Administra<strong>to</strong>r and Mirth Connect Command Line Interface. During the
installation you have <strong>to</strong> 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 but<strong>to</strong>n 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 <strong>to</strong> continue. If not, refer <strong>to</strong> Mirth
Connect 3.1 User <strong>Guide</strong> 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 <strong>to</strong> launch Mirth
Connect Service, configure ports, allocate memories, and <strong>to</strong> establish database
connections. However, a fully-fledged configuration description is beyond the scope of
this book.
As a recommended option, add a path <strong>to</strong> the \cus<strong>to</strong>m-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 <strong>to</strong> restart the
Mirth Connect Server or Service <strong>to</strong> activate your changes.
Mirth Connect Administra<strong>to</strong>r
The Mirth Connect Administra<strong>to</strong>r 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 Administra<strong>to</strong>r matches the version
of the Mirth Connect Server being used.
To download the Mirth Connect Administra<strong>to</strong>r:
• 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 Administra<strong>to</strong>r in the Mirth Connect Administra<strong>to</strong>r launch
page;
• Click Ok <strong>to</strong> 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 <strong>to</strong> 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

Channels
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 <strong>to</strong> 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
s<strong>to</strong>red by Mirth Connect Server in the database; closing and opening the Mirth
Connect Administra<strong>to</strong>r 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 <strong>to</strong>ol used
<strong>to</strong> develop and configure channels throughout this book.
The Channel is an essential part of Mirth Connect and can be seen as one-<strong>to</strong>-many
abstract unidirectional pipes that decouple components from each other <strong>to</strong> transfer
healthcare data between two or more applications. The channel architecture
implemented in Mirth Connect can divide a large message processing task in<strong>to</strong> 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 <strong>to</strong> Mirth Connect and developed independently.
FIGURE 1-1 Mirth Connect abstract channel architecture
In general, each channel consists of inbound and outbound Connec<strong>to</strong>rs, Filters and
Transformers. The connec<strong>to</strong>r that receives inbound messages from the Sending
Application is called the Source. Similarly, the connec<strong>to</strong>r that sends outbound messages
15 PART I – GETTING STARTED

is called the Destination. From the Source connec<strong>to</strong>r, data is passed through the channel,
where filters and transformers perform operations on the data, for example, routing a
message <strong>to</strong> one or another Destinations connec<strong>to</strong>r and transforming the data
representation. Deciding each channel’s tasks is when wearing an analyst's hat comes
in<strong>to</strong> play.
Before you create a new channel, you need <strong>to</strong> elicit the following requirements:
• Type of Application the channel reads data from (Source connec<strong>to</strong>r type);
• Type of Application the channel sends data <strong>to</strong> (Destination connec<strong>to</strong>r 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).
Connec<strong>to</strong>rs
In terms of Enterprise Integration, the connec<strong>to</strong>r is a Message Endpoint that specifies a
particular way or, more accurately, a particular pro<strong>to</strong>col Mirth Connect should use <strong>to</strong>
communicate with an external application or another Mirth Connect channel.
Mirth Connect supports sending and receiving messages over a variety of connec<strong>to</strong>rs
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 connec<strong>to</strong>r that receives the data is called a Reader, for example the MLLP Reader.
The connec<strong>to</strong>r that sends the data is called a Writer, the Database Writer is an example.
Connec<strong>to</strong>r types are configured under Source and Destinations tabs of the channel.
Obviously, some settings are common across all connec<strong>to</strong>rs while others are unique <strong>to</strong> a
specific connec<strong>to</strong>r type.
You can develop your own connec<strong>to</strong>r if you need one that is not shipped with the Mirth
Connect installation package, e.g., HTTPS connec<strong>to</strong>r. 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 <strong>to</strong> 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 in<strong>to</strong> 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 <strong>to</strong> the queue unchanged for another pipe <strong>to</strong> 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 <strong>to</strong> 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 <strong>to</strong> 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, cus<strong>to</strong>m applications
and third-party solutions, each of which is built around a proprietary data model. Even
systems that claim <strong>to</strong> support a single standard may place specific requirements on data
format and content. If we could bring all legacy systems <strong>to</strong> 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 in<strong>to</strong> another. As a result, a
destination application can receive messages it understands and which can be processed
and s<strong>to</strong>red in the application’s internal data format.
17 PART I – GETTING STARTED

Scripts
Mirth Connect allows message transformation <strong>to</strong> occur at different levels and <strong>to</strong> chain
message transformers <strong>to</strong> achieve a required result.
Supported transformers are:
• Message Builder maps segments of the inbound message <strong>to</strong> segments in the
outbound message.
• Mapper maps segments of the inbound message <strong>to</strong> internal Mirth Connect variables.
These variables may be used later.
• External Script, as the name suggests, employs external JavaScript routines <strong>to</strong>
transform or map the data.
• XSLT Step utilizes the XSL transformation.
• JavaScript, along with External Script, is where flexibility comes in<strong>to</strong> play. Here any
type of (Rhino) Java Script and Java code can be used.
Channels also support unique features called Scripts <strong>to</strong> enhance message processing
logic. Scripts apply <strong>to</strong> 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 <strong>to</strong> initialize variables or create class objects.
• Attachment script deals with a message in a native format and allows extracting part
of the message <strong>to</strong> s<strong>to</strong>re as an attachment or <strong>to</strong> irrevocably modify a message.
• Preprocessor script also allows handling each message in a native format before
Mirth Connect starts translating it in<strong>to</strong> 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 s<strong>to</strong>ps. This is the place
<strong>to</strong>, 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 <strong>to</strong> extend it by calls
of external Java classes. The latter may be one of those included <strong>to</strong> 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 <strong>to</strong>
all channels.
This concludes Mirth Connect introduction section. To find out more, you may refer <strong>to</strong>
numerous web resources, including trainings and books provided by Mirth Corporation.
You may find it helpful <strong>to</strong> read “<strong>Unofficial</strong> Mirth Connect v3.x <strong>Developer’s</strong> <strong>Guide</strong>“ eBook
which covers Mirth Connect basics and advanced <strong>to</strong>pics in greater details.
This eBook is available at - http://mirthconnect.shamilpublishing.com
19 PART I – GETTING STARTED

CHAPTER 2 What is <strong>CCD</strong>?
What is <strong>CCD</strong>?
T
he Continuity of Care Document or <strong>CCD</strong>, is an XML-based markup standard intended
<strong>to</strong> 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. <strong>CCD</strong> fosters
interoperability of clinical data by allowing physicians <strong>to</strong> send electronic medical
information <strong>to</strong> other providers without loss of meaning and enabling improvement of
patient care. <strong>CCD</strong> is an implementation guide for sharing Continuity of Care Record (CCR)
patient summary data using the HL7 Version 3 Clinical Document Architecture (<strong>CDA</strong>),
Release 2.” (HL7 <strong>CCD</strong> page)
Basically, what has been done is the HL7 Clinical Document Architecture (<strong>CDA</strong>) is taken
as a document markup standard and constrained by the ASTM Continuity of Care Record
(or CCR also referred <strong>to</strong> as ASTM E2369-05) data sets in<strong>to</strong> 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 <strong>CDA</strong> and <strong>CCD</strong>. You should have following specifications
available:
• HL7v3 Normative Edition - HL7 Clinical Document Architecture, Release 2.0;
• HL7 Implementation <strong>Guide</strong>: <strong>CDA</strong> Release 2 – Continuity of Care Document (<strong>CCD</strong>).
<strong>CCD</strong> Development Approach
Besides <strong>CCD</strong> standard specifications, the <strong>CCD</strong> distribution package includes <strong>CCD</strong> and
core HL7 XML schemas, <strong>CCD</strong> XSLT stylesheets and non-normative examples of
Schematron rules required <strong>to</strong> validate documents.
From a standard developer point of view, the approach used in this book <strong>to</strong> develops
core artifacts for the document-level templates (which is <strong>CCD</strong> in our case) is by taking a
subset of classes defined in the <strong>CDA</strong> R2 R-MIM model and constraining them <strong>to</strong> reflect
the ASTM CCR specification.
PART I – GETTING STARTED 20

In general these steps are:
• <strong>CDA</strong> document derives its classes and machine-processable meaning from the HL7
Reference Information Model (RIM) in conjunction with HL7v3 Data Types.
• <strong>CCD</strong> document derives its classes from <strong>CDA</strong> Refined Message Information Models
(R-MIM).
• <strong>CCD</strong> R-MIM classes are constrained by the ASTM CCR data requirements.
• As <strong>CCD</strong> R-MIM is finalized, the XML schema(s), possibly with other artifacts such as
Model Interchange Format (MIF) files and Hierarchical Message Descrip<strong>to</strong>r (HMD)
views, are generated.
• As the last step, <strong>CCD</strong> XML schema is manually updated <strong>to</strong> include extensions
required <strong>to</strong> map ASTM CCR components for which there is no suitable mapping in
<strong>CDA</strong> R2.
Schematically this may be represented as Figure 2-1.
FIGURE 2-1 <strong>CCD</strong> development approach
As you can see, the <strong>CCD</strong> R-MIM, derived from the <strong>CDA</strong> R-MIM, follows the same
structure, i.e., it contains a required header <strong>to</strong> identify the document and participants,
and a body <strong>to</strong> represent a generic structure of a clinical content.
21 PART I – GETTING STARTED

This method for creating <strong>CCD</strong> XML schema is based on HL7v3 refinement and
localization mechanism and can be applied <strong>to</strong> 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 <strong>to</strong> provide specific clinical context. Thus, as the HL7 NE states:
“The <strong>CDA</strong> specification is richly expressive and flexible. Document -level, section-level and
entry-level templates can be used <strong>to</strong> constrain the generic <strong>CDA</strong> specification.” Such
patterns, called templates, can “comply with a detailed implementation guide that details
the manner in which structured elements are <strong>to</strong> be represented and their intended
interpretation <strong>to</strong> a level sufficient <strong>to</strong> ensure a degree of clinical safety that is appropriate <strong>to</strong>
the use case that it is designed <strong>to</strong> 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 <strong>CDA</strong> defined structure. If you think this
is not enough, <strong>CDA</strong> allows including both structured and unstructured information at the
<strong>CDA</strong> Level. The <strong>CDA</strong> specification distinguishes three incremental levels of conformance
for semantical interoperability.
<strong>CDA</strong> Level 1: The simplest form of <strong>CDA</strong>, also known as <strong>CDA</strong> 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 <strong>CDA</strong> Level 1 is not allowed as defined in
the Meaningful Use initiative.
<strong>CDA</strong> Level 2: Next form is “the <strong>CDA</strong> specification with section-level templates applied”.
(HL7v3 NE) Section level templates are identified by an associated templateID and
represented in XML.
<strong>CDA</strong> Level 3: At this level “the <strong>CDA</strong> specification with entry-level (and optionally sectionlevel)
templates applied.” (HL7v3 NE) At this level some section templates contain
discrete data elements called <strong>CDA</strong> entries.
Thus, built on templates, the <strong>CDA</strong> R2 implementation guide defines nine document-level
templates, where <strong>CCD</strong> 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
<strong>CDA</strong> 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.
<strong>CDA</strong> Sections
<strong>CCD</strong> sections
MU2
Medical
Equipment
...
...
Payers
Allergies
Medications
Problems
Advance
Directives
Discharge Diet
...
...
...
Results
Consultation Notes sections
MU2
Family His<strong>to</strong>ry
Immunizations
Social His<strong>to</strong>ry
Physical Exam
Present Illness
Past Illness
Reason for
Referral
... Encounters Vital Signs
Plan of Care Reason for Visit General Status ...
... ...
FIGURE 2-2 <strong>CDA</strong> 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
manda<strong>to</strong>ry according <strong>to</strong> Meaningful Use Stage 2 (MU2).
Entry-level templates
<strong>CDA</strong> does not s<strong>to</strong>p at the section level but additionally defines up <strong>to</strong> 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 <strong>CCD</strong>,
<strong>CDA</strong> and MU2.
23 PART I – GETTING STARTED

Summary
As the name suggests, entry-level templates apply <strong>to</strong> one of the clinical act statements:
Observation, Substance Administration, Supply, Procedure and so on. All entry-level
templates are meant <strong>to</strong> be machine-processable parts of the document.
Some entry-level templates are used exclusively in one type of <strong>CDA</strong> 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 <strong>CDA</strong> 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
US Realm related <strong>CCD</strong> Implementation <strong>Guide</strong> may recommend additional sections for
conveying healthcare data that conforms <strong>to</strong> MU2 requirements. MU2 also applies
additional constrains on all template levels.
This chapter has barely scratched the surface, providing a general overview of one of the
<strong>CDA</strong> family templates called Continuity of Care Document (<strong>CCD</strong>) which is semantically
equivalent of ASTM Continuity of Care Record (CCR). Rather than explaining <strong>CCD</strong> in
depth, which requires a book by itself, this section gives you a basic road map for
exploring and understanding <strong>CCD</strong>.
If you are not familiar with HL7 and HL7v3 in particular, you may start with HL7v3
Normative Edition and move <strong>to</strong>wards Clinical Document Architecture domain. I wrote
another book, called “<strong>Unofficial</strong> Developer's <strong>Guide</strong> <strong>to</strong> HL7v3 Basics 3 ” <strong>to</strong> help you in this
endeavour.
2 HITSP - Healthcare Information Technology Standards Panel
3 Available <strong>to</strong> download at - http://hl7basics.shamilpublishing.com
PART I – GETTING STARTED 24

Below is a non-exhaustive list of other resources <strong>to</strong> help you educate yourself on various
aspects of <strong>CDA</strong> and <strong>CCD</strong>.
Primary Standard is available on the HL7.org site. You need <strong>to</strong> register <strong>to</strong> get access.
<strong>CDA</strong>® Release 2;
<strong>CDA</strong> and <strong>CCD</strong> Implementation <strong>Guide</strong>s are also available on the HL7.org site.
HL7 Implementation <strong>Guide</strong>: <strong>CDA</strong> Release 2 – Continuity of Care Document
(<strong>CCD</strong>) 4 ;
HL7 Implementation <strong>Guide</strong>: S&I Framework Transitions of Care Companion <strong>Guide</strong>
<strong>to</strong> Consolidated-<strong>CDA</strong> for Meaningful Use Stage 2, Release 1 – US Realm;
Additionally you may find samples of section and entry level templates.
IHE <strong>CDA</strong> Section Templates -
wiki.ihe.net/index.php?title=Category:<strong>CDA</strong>_Section_Templates
Below are listed quite a few books that I found helpful in this <strong>to</strong>pic. If you are not familiar
with HL7 or <strong>CDA</strong> 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 <strong>CDA</strong> 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 <strong>CCD</strong> R-MIM diagram in Visio format (for
illustrative purpose only);
Hierarchical Message Descriptions (HMD) in Excel View derived from the <strong>CCD</strong> R-
MIM (for illustrative purpose only).
4 Referred in this book as HL7 <strong>CCD</strong>.
25 PART I – GETTING STARTED

CHAPTER 3 Systems Integration Requirements
System Integration Requirements
T
his chapter is a brief overview of system design and systems integration requirements
for implementing the <strong>CDA</strong> based system. If you are more or less familiar with HL7
systems implementation you are free <strong>to</strong> 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 <strong>to</strong> the integration
of clinical health information systems. It is the corners<strong>to</strong>ne 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 <strong>CDA</strong> and <strong>CCD</strong>
are based on, is a fait accompli and the task at hand is <strong>to</strong> 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 <strong>to</strong> this solution after much trial and error. If business needs were stable
such a solution would not be required. However, <strong>to</strong>day’s business, eHealth in particular,
faces constant change from new regula<strong>to</strong>ry requirements (e.g., EHR Meaningful Use
stage 1 <strong>to</strong> 3 in the USA), market changes and improvements in operational processes. To
achieve flexibility, various types of abstraction layers are possible <strong>to</strong> 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 <strong>to</strong> worry about the actual data location and structure.
In this diagram, data is s<strong>to</strong>red in the Data Reposi<strong>to</strong>ry. The purpose of it is <strong>to</strong> 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 <strong>to</strong> the Abstraction Layer <strong>to</strong> retrieve the patient
medical information;
2. The Abstraction Layer makes a request <strong>to</strong> the Data Reposi<strong>to</strong>ry;
PART I – GETTING STARTED 26

3. If data is available, the Data Reposi<strong>to</strong>ry returns it <strong>to</strong> the Abstraction Layer;
4. The Abstraction Layer forms the data in the way the Application expects and sends it
<strong>to</strong> 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 distributed or
hosted on different operating systems and/or or data s<strong>to</strong>rage environments (e.g.,
databases from different vendors).
What if the Abstraction Layer cannot find the data in the Data Reposi<strong>to</strong>ry? If business
logic allows there will be additional steps <strong>to</strong> request data from a remote system probably
using one of the HL7 messaging standards.
Figure 3-2 schematically shows an abstract system with added <strong>CCD</strong> document building
capability. If you are not familiar with the HL7 and <strong>CDA</strong> 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 transla<strong>to</strong>r 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 <strong>to</strong> 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 <strong>to</strong> avoid
confusion with vendor-specific implementations.
27 PART I – GETTING STARTED

FIGURE 3-2 System architecture with <strong>CDA</strong> builder capability
Assuming a Web Service is used <strong>to</strong> deliver a document, the notional data flow with
added <strong>CCD</strong> Builder functionality may be described as:
1. The Application makes a request <strong>to</strong> the Abstraction Layer <strong>to</strong> retrieve the patient
medical information.
2. The Abstraction Layer makes a request <strong>to</strong> the Data Reposi<strong>to</strong>ry.
3. If data is available, the Data Reposi<strong>to</strong>ry returns it <strong>to</strong> the Abstraction Layer.
4. The Abstraction Layer forms the data in the way the Application understands and
sends it <strong>to</strong> the Application. The latter sends the data <strong>to</strong> the <strong>CCD</strong> Builder component.
5. The <strong>CCD</strong> Builder component, in turn, forms parts of the document, aggregates them
in<strong>to</strong> a single document, wraps the message in a SOAP envelope or other transport
mechanism, and sends it <strong>to</strong> the remote system or s<strong>to</strong>rage.
6. The HL7v3 Receiver component gets the response, verifies that the response belongs
<strong>to</strong> this destination, extracts the payload and passes it <strong>to</strong> the Abstraction Layer.
7. The remote system processes the data and uses it as intended.
Besides typical alternative and exception flows related <strong>to</strong> communication, questions that
left unanswered are:
• If the patient medical information is not available in the Data Reposi<strong>to</strong>ry, what should
the system do?
PART I – GETTING STARTED 28

• If the local Data Reposi<strong>to</strong>ry 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 <strong>CCD</strong> is not capable of conveying such
data <strong>to</strong> 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.
Cus<strong>to</strong>mers are usually not interested in seeing how functional requirements are
implemented. The terms they use <strong>to</strong> describe system functionality, more often than not,
apply <strong>to</strong> direct or indirect non-functional requirements (NFR), such as qualities and
constraints. NFRs represent a significant delivery risk <strong>to</strong> a project since neglecting or
improperly dealing with NFRs during the initial requirements elicitation process, or
during the system development lifecycle, leads <strong>to</strong> inaccurate estimation of project’s
scope and efforts. Errors due <strong>to</strong> omitting NFRs or <strong>to</strong> insufficient attention paid <strong>to</strong> their
analysis are among the most expensive and difficult problems <strong>to</strong> 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 <strong>to</strong> show the
consequences of (not) implementing them. NFRs are listed in no particular order.
Auditability
Auditability is the ability of the system <strong>to</strong> 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 <strong>to</strong> a number of questions such as what data <strong>to</strong> collect,
how <strong>to</strong> s<strong>to</strong>re it, how <strong>to</strong> prevent unauthorized access <strong>to</strong> audit records, and how <strong>to</strong>
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
<strong>to</strong> 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 <strong>to</strong> 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 <strong>to</strong> put mechanisms in<strong>to</strong> place that au<strong>to</strong>mate some levels of conformance
testing of incoming messages, does the original “… N seconds <strong>to</strong> complete” still apply
during peak hours? If a transaction has timed out, does the original “… N seconds <strong>to</strong>
complete” mean N seconds <strong>to</strong> 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 <strong>to</strong> 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 <strong>to</strong> the healthcare industry, you need <strong>to</strong> know that, besides typical computer
systems security requirements, national health sec<strong>to</strong>rs often specify their own security
requirements (e.g., Health Insurance Portability and Accountability Act or HIPAA in the
USA) <strong>to</strong> protect highly sensitive medical information from fraud and security breaches.
Violations of such regulations can lead <strong>to</strong> lawsuits and other enforcement actions. Even if
not applied directly <strong>to</strong> the <strong>CDA</strong> standard, some of the security rules that HIPAA regulates
are: audit controls <strong>to</strong> 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

Testing
Transactional Reliability
Transactional reliability determines the portion of successfully completed transactions,
(i.e., number of messages delivered <strong>to</strong>, 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.
Be it through a waterfall, agile or another approach <strong>to</strong> system development, sooner or
later functional and non-functional aspects of the system need <strong>to</strong> 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 pro<strong>to</strong>cols, 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 <strong>to</strong> test the system. It may be
part of unit testing.
• User Acceptance Testing (UAT) environment which is as similar <strong>to</strong> 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 <strong>to</strong> be tested. However, in the real world, you will often need
<strong>to</strong> 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, pro<strong>to</strong>col 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 <strong>to</strong> verify desired behavior against the system’s integration
requirements.
Capacity testing unveils the issue of scaling up existing data <strong>to</strong> 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 <strong>to</strong> comply with current legislations and regulations aimed at protecting
the privacy of patient’s personal demographic and health information – specifically <strong>to</strong>
prevent disclosing either the identity or other attributes of private individuals. This is
where de-identification comes in<strong>to</strong> 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 <strong>to</strong>pic by itself and requires separate books.
Reasons for healthcare data de-identification include: developers’ lap<strong>to</strong>ps, hard disks or
USB flash drives may be lost or s<strong>to</strong>len; a company may experience "sophisticated
computer security attack" against their servers; and other breaches (recent breach
reports may be found at databreach<strong>to</strong>day.com website). Indeed, media outlets are quick
<strong>to</strong> report data breaches involving (s<strong>to</strong>len) patient health data. Additionally, many
jurisdictions have breach notification laws that requires notifications <strong>to</strong> be sent <strong>to</strong>
regula<strong>to</strong>ry 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, Charles<strong>to</strong>n, WV
Denise Lewis; DOB: 03-Mar-1976; Address: 23 Adams Chapel Rd, Manka<strong>to</strong>, MN
Rosemarie Hardy; DOB: 14-Nov-1985; Address: 310 Camp Creek Rd, Wes<strong>to</strong>n, MA
And so, how many Denise Lewis’s live in Minneapolis?
PART I – GETTING STARTED 32

Summary
In fact, the source 5 that provided these samples suggested that all three are de-identified
data. Imagine if such de-identified datasets are s<strong>to</strong>len and reported as “the data breach”
by the media. The company may face severe fines and damage <strong>to</strong> its reputation long
before it can be proven that the s<strong>to</strong>len 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
Information 6 report written by Ross Fraser and Don Willison for the Pan Canadian Health
Information Privacy (HIP) Group. This report explains major techniques, requirements for
health data de-identification <strong>to</strong>ols, and some of the commercially available <strong>to</strong>ols.
Other sources worth reading:
• A Canadian standard: “Best Practice” <strong>Guide</strong>lines for Managing the Disclosure of De-
Identified 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.
This chapter shows that in addition <strong>to</strong> typical software development issues, the HL7-
based development project has layers of additional complexity due <strong>to</strong> interconnected
functional and non-functional requirements.
Healthcare by itself is a difficult domain. Software developers that see <strong>CDA</strong> documents as
yet another XML-based feed system run the risk of significantly underestimating the
effort needed <strong>to</strong> 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 <strong>to</strong> build a scalable application capable of constructing
countrywide level <strong>CDA</strong> document and processing all section-level templates, but your
local regula<strong>to</strong>ry restrictions may prevent sharing personal information with other
5 The source will not be disclosed. They received my opinion and suggestion.
6 Available <strong>to</strong> download at - https://www.ehealthinformation.ca/knowledgebase/getAttach/15/AA-
00118/Tools_for_De-identification_EN-FINAL.pdf
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 <strong>to</strong>
eHealth industry and local regula<strong>to</strong>ry auditing and security requirements <strong>to</strong> protect
sensitive information, and may require test data sets <strong>to</strong> 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
U
nlike other universal domains in the HL7v3 Normative Edition , the Clinical Document
Architecture does not specify s<strong>to</strong>ryboards, interactions and participants. This domain
deals only with the <strong>CDA</strong> 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 unders<strong>to</strong>od 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 <strong>to</strong> explore in this book. Before
implementing an imaginary <strong>CCD</strong> Builder Server using Mirth Connect, we need <strong>to</strong>
examine what we are trying <strong>to</strong> build. Also, it is good <strong>to</strong> note that this s erver is
“imaginary” because the goal is <strong>to</strong> fully concentrate on Mirth Connect features rather
than on actual <strong>CCD</strong> or MU2 business rules.
Note:
Before we start, I would like <strong>to</strong> stress that HL7 interactions and templates (in
terms of <strong>CDA</strong>) 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 <strong>CCD</strong> will be based on incoming HL7v2 messages therefore a
working knowledge of the HL7 v2.x message structure and messaging pro<strong>to</strong>cols is
required.
35 PART I – GETTING STARTED

HL7v3: Readers are assumed <strong>to</strong> 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 <strong>CCD</strong> Builder Server may work in a real life scenario, I would
like <strong>to</strong> quote several narratives of relevant interactions from the HL7v3 Normative Edition
2014.
If you are not familiar with this concept, the s<strong>to</strong>ryboard in HL7 terms is “a narrative of
relevant events defined using interaction diagrams or use cases. The s<strong>to</strong>ryboard 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 <strong>to</strong> 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 his<strong>to</strong>ry of diabetes. Dr. Bill Beaker wants <strong>to</strong>
rule out diabetes mellitus by performing a GTT2HR. Upon the release of the results for the
complete GTT2HR test, the labora<strong>to</strong>ry system reports all the results in a single message.”
(HL7NE > Complex Labora<strong>to</strong>ry Result > POLB_ST221000UV01)
Once labora<strong>to</strong>ry results are available, Dr. Bill Beaker observes them as a single document
and submits them <strong>to</strong> the Good Health Hospital for use during the scheduled inpatient
visit for Mr. Everyman.
(Patient and doc<strong>to</strong>rs names in s<strong>to</strong>ryboards are changed <strong>to</strong> 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 Origina<strong>to</strong>r – creates messages and publishes (sends) them <strong>to</strong> a receiver
(played by Patient Registry or Document Origina<strong>to</strong>r in our case).
Patient Registry – represents the Patient Demographics Management System.
Document Origina<strong>to</strong>r – creates a <strong>CCD</strong> document.
The next step is <strong>to</strong> 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 s<strong>to</strong>ryboards defined above shows interactions between
application roles and is described using the sequence diagram (Figure 4-1).
Message
Origina<strong>to</strong>r
Patient Registry
Document
Origina<strong>to</strong>r
ADT_A28
ACK
ORU_R01
ACK
query
response
FIGURE 4-1 Interaction diagram
As a base for the model’s interactions I have chosen <strong>to</strong> 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 <strong>to</strong> the final <strong>CCD</strong> 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 <strong>to</strong>
s<strong>to</strong>re patient demographics instead of sending it directly <strong>to</strong> the Document Origina<strong>to</strong>r. So
let us quickly go through this sequence diagram <strong>to</strong> see how it works.
1. The Message Origina<strong>to</strong>r does a preliminary step by sending an ADT_A28 (Add Person
or Patient Information) message <strong>to</strong> a temporary s<strong>to</strong>rage 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 <strong>to</strong> try. The Patient Registry, in turn,
may acknowledge the message.
2. The Message Origina<strong>to</strong>r sends an ORU_R01 (Unsolicited Observation Message)
message <strong>to</strong> the Document Origina<strong>to</strong>r. The latter may acknowledge this message and
then starts transforming and compiling the <strong>CCD</strong> document from the data it has
received. At some point, the Document Origina<strong>to</strong>r may require patient demographic
data if it was not fully provided in the ORU_R01 message. In such a case, the
Document Origina<strong>to</strong>r makes an (internal) request <strong>to</strong> the Patient Registry and uses the
data that the Patient Registry returns.
Design Considerations
There are many ways <strong>to</strong> accomplish the same task in Mirth Connect. In addition, there
are many ways <strong>to</strong> build a valid <strong>CDA</strong>/<strong>CCD</strong> document. However, the main idea of this book
is <strong>to</strong> explore Mirth Connect features, NOT <strong>to</strong> implement the service in a correct way
using standard de-fac<strong>to</strong> 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 <strong>to</strong> the <strong>CCD</strong> Builder.
The implementation plan is based on followings channels:
• Sender – a channel that plays a role of the Message Origina<strong>to</strong>r and serves as an
interface <strong>to</strong> handle and place an original ADT or ORU messages in<strong>to</strong> the pipe using
the MLLP Message Transport pro<strong>to</strong>col.
• <strong>CCD</strong> Builder – a channel that does all heavy lifting. Later we will see that this
channel builds separate section-level templates and then compiles them in<strong>to</strong> a single
<strong>CCD</strong> document. This channel plays the role of the Document Origina<strong>to</strong>r.
PART I – GETTING STARTED 38

• Global Map – the Global Map, in Mirth Connect terms, represents the Patient
Demographics Management System. Its main duty is <strong>to</strong> temporary s<strong>to</strong>re patient
demographic data.
HL7v2
(ADT_A28,
ORU_R01)
Global Map
Reader
MLLP
MLLP
File Writer
Sender
<strong>CCD</strong> Builder
Transform
ACK / NACK
Transform
<strong>CCD</strong>
File Writer
ACK / NACK
FIGURE 4-2 <strong>CCD</strong> Builder Server channels implementation plan
Throughout this implementation we will explore some major connec<strong>to</strong>rs: 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
<strong>to</strong>: filters, transformers, code templates, maps, global and channel scripts.
At this point it is assumed that you are comfortable with the Mirth Connect
Administra<strong>to</strong>r.
Recommended <strong>to</strong>ols and packages
To make the development easier and less tedious, here is a list of recommended <strong>to</strong>ols
and packages. You are free <strong>to</strong> use any other <strong>to</strong>ols that suit you better.
Summary
• HL7v2 viewer such as Messaging Workbench or HL7Spy by Inner Harbour Software;
• HL7v3 viewer such as Al<strong>to</strong>va XMLSpy by Al<strong>to</strong>va GmbH;
And last but not least, use the XML schemas and other related files from the archive
provided with this book.
This section identified players and outlined the game plan. To do this we went through
the s<strong>to</strong>ryboards as they are defined by HL7v3 Normative Edition, identified application
39 PART I – GETTING STARTED

oles and interactions between them. This helped us depict the interaction model and
translate it <strong>to</strong> 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 <strong>to</strong> download at
http://ccdonmirth.shamilpublishing.com
PART I – GETTING STARTED 40

Book Resources
Book Resources
Other titles you may be interested in:
<strong>Unofficial</strong> Mirth Connect v3.x Developer's
<strong>Guide</strong>
This book introduces readers <strong>to</strong> version 3.x of Mirth
Connect <strong>to</strong> the point that they are confident enough
<strong>to</strong> start building their own healthcare data exchange
interfaces.
By implementing an imaginary Eligibility Query
Service, this book covers some of the <strong>to</strong>pics 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 <strong>to</strong> download at –
http://mirthconnect.shamilpublishing.com
<strong>Unofficial</strong> Developer's <strong>Guide</strong> <strong>to</strong> HL7v3 Basics
This book introduces readers <strong>to</strong> HL7 version 3 <strong>to</strong> the
point that they are confident enough <strong>to</strong> start building
their own healthcare data exchange interfaces. The
book provides clear and easy <strong>to</strong> use, step-by-step
guidance for learning the standard, with numerous
examples covering many <strong>to</strong>pics.
The book is available <strong>to</strong> download at –
http://hl7basics.shamilpublishing.com

APPENDICES
Appendices
A: <strong>CCD</strong> 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 Files Comment
..\Channels\
<strong>CCD</strong> Builder.xml
Code Templates.xml
Global Scripts.xml
Query Sender.xml
Mirth Connect channels, code
templates and global scripts
discussed in this book
..\Models\coreschemas\
..\Models\Schemas\
..\Models\ExcelView\
..\Models\HTMLView\
..\Models\MWBModels\
..\Models\PictureView\
..\Models\VisioModels\
..\SampleMessages\<strong>CCD</strong>\
datatypes-base.xsd
datatypes-rX-cs.xsd
datatypes.xsd
infrastructureRoot.xsd
NarrativeBlock.xsd
voc.xsd
<strong>CCD</strong>-Body.xsd
<strong>CCD</strong>-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
<strong>CCD</strong>_Allergies_Mirth_Template.xml
<strong>CCD</strong>_Body_Mirth_Template.xml
<strong>CCD</strong>_Header_Mirth_Template.xml
HL7 core XML schema files required
<strong>to</strong> validate <strong>CCD</strong> document instances
Localized, non-normative XML
schemas for <strong>CCD</strong> header and <strong>CCD</strong>
body parts.
Document element descriptions in
MS Excel format
Document element descriptions in
HTML format
Messaging Workbench (MWB)
models <strong>to</strong> validate ADT and ORU
message samples.
<strong>CCD</strong> header and body R-MIM
representation
<strong>CCD</strong> header and body R-MIM models
in Visio format
Parts of <strong>CCD</strong> document <strong>to</strong> serve as
outbound Mirth Connect templates
for the <strong>CCD</strong> Builder channel’s

\SampleMessages\HL7v2
..\XSLT\
<strong>CCD</strong>_Header_Template_annotated.xml
<strong>CCD</strong>_Medications_Mirth_Template.xml
<strong>CCD</strong>_Problems_Mirth_Template.xml
<strong>CCD</strong>_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 <strong>CCD</strong> Builder channel’s
destinations
43 APPENDICES