Documente Academic
Documente Profesional
Documente Cultură
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.
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, NextGen, Quality Systems Inc., 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
3 Introduction
Source Connector ............................................................................................................. 52
Destinations Connector .................................................................................................... 54
Code Templates ................................................................................................................ 63
Global Scripts ................................................................................................................... 65
Channel Implementation Verification .............................................................................. 65
Summary ........................................................................................................................... 66
Chapter 7 CCD Builder Channel – Allergies ..................................................................................... 67
Destinations Connector .................................................................................................... 68
Code Templates ................................................................................................................ 75
Global Scripts .................................................................................................................... 77
Channel Implementation Verification .............................................................................. 77
Summary ........................................................................................................................... 78
Chapter 8 CCD Builder Channel – Medications ............................................................................... 79
Destinations Connector .................................................................................................... 81
Global Scripts .................................................................................................................... 87
Channel Implementation Verification .............................................................................. 87
Summary ........................................................................................................................... 88
APPENDICES
5 Introduction
C: HL7v2 Test Messages .................................................................................................. 157
D: XSLT files ..................................................................................................................... 158
E: Archive Content .......................................................................................................... 164
Introduction 6
Introduction
Introduction
As Mirth Corporation said earlier 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.”
Mirth Connect, or NextGen Connect as it is called now, was and still 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 3.6.1 version of the product. Consequently,
other releases may include new features, or features used in this book may change or
disappear. You may also notice some differences between screen shots provided in the
book and those you see when using Mirth Connect.
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
explains things in a more detailed and organized way.
In a book of this size, I cannot cover every feature that Mirth Connect v3.x or previous
versions have; consequently, I assume you already have some familiarity with Mirth
Connect.
7 Introduction
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).
As mentioned earlier, the purpose of this book is to provide the reader with a high-level
overview of the capabilities and features associated with Mirth Connect v3.6. This book is
not intended to be a step-by-step comprehensive guide or substitute of any kind to
original training and certification programs provided by Mirth Corporation (Quality
Systems, Inc.).
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.
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
Introduction 8
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 as 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 with respect to 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.
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, then 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.
The Mirth Connect is officially called “NextGen® Connect Integration Engine” now.
However, this book continues to use Mirth Connect for breviety and familiarity.
Furthermore, this book contains information on the subject only up to the published
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.
9 Introduction
My biggest thanks go to Wayne Zafft, who was incredibly gracious with his time and
effort in reviewing the final version of the book.
Roadmap
Part I provides an introduction to Mirth Connect and a high-level overview of the CDA
document paradigm taking Continuity of Care Document (CCD) as an example.
Introduction 10
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.
Part III describes the process of building a proof of concept JavaScript library to parse
CDA Header participants.
11 Introduction
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.
Appendices include:
Archive Content
Lists folders and files included in the archive provided with the book.
Code Templates
Shows all mapping functions defined as Code Templates functions.
HL7v2 samples
Lists ADT_A28 and ORU_R01 message samples.
Introduction 12
PART I – GETTING STARTED
Getting Started
CHAPTER 1 Mirth Connect Basics
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.
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.6 User Guide written by “the same Mirth technical experts who developed the
software”.
PART I – GETTING STARTED 14
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.
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.
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.
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
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.
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
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
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.
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.
PART I – GETTING STARTED 18
Mirth Connect allows message transformation to occur at different levels and to chain
message transformers to achieve a required result.
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.
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,
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.
What is CCD?
Theto specify
Continuity of Care Document or CCD, is an XML-based markup standard intended
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.
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).
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.
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.
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 section-
level) 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.
CDA R2 defines more than 65 section-level templates. Among these are Allergies,
Encounters, Medications, Problem List, etc.
This is schematically1 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 Advance
Directives
...
Medical Medications ...
...
Equipment
Discharge Diet
Problems
Payers
Results
... Encounters Vital Signs Plan of Care Reason for Visit General Status ...
... ...
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 entry-
levels 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.
PART I – GETTING STARTED 24
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 (HITSP2 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).
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 Basics3” to help you in this
endeavour.
2
HITSP - Healthcare Information Technology Standards Panel
3
Available to download at - http://hl7basics.shamilpublishing.com
25 PART I – GETTING STARTED
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.
Additionally you may find samples of section and entry level 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.
You may also find some technical files. These are provided in the package that is part of
this book:
Hierarchical Message Descriptions (HMD) in Excel View derived from the CCD R-
MIM (for illustrative purpose only).
4
Referred in this book as HL7 CCD.
PART I – GETTING STARTED 26
This is a preview edition of the book.
The full versions of this and other related books are available to
download at
http://ccdonmirth.shamilpublishing.com
Book Resources
Other titles you may be interested in:
Appendices
A: CCD Mirth Templates
B: Code Templates
D: XSLT files
E: Archive Content
These are files provided as supplementary materials required for parts II, III and IV.
31 APPENDICES