Unofficial Developer's Guide to CCD on Mirth Connect

Shamil Nizamov

Unofficial Developer’s Guide to

CDA/CCD on Mirth Connect*

* - Preview Edition

Introduction 2

Copyright Page

Copyright © 2014-2015 by Shamil Nizamov

Cover image copyright © 2013 by Shamil Nizamov

All rights reserved. No part of the contents of this book may be reproduced or

transmitted in any form or by any means without the written permission of the author.

Mirth Connect is a trademark of Mirth Corporation. HL7, CDA, CCD and Health Level

Seven are registered trademarks of Health Level Seven International. All other marks are

property of their respective owners.

Any rights not expressly granted herein are reserved.

The companies, organizations, products, domain names, email addresses, logos, people,

places, and/or data mentioned herein in examples are fictitious. No association with any

real company, organization, product, domain name, email address, logo, person, place,

or data is intended or should be inferred.

This book expresses the author’s views and opinions. The information contained in this

book is provided without any express, statutory, or implied warranties. The author, Mirth

Corporation, Health Level Seven International, resellers and distributors will NOT be held

liable for any damages caused or alleged to be caused either directly or indirectly by this

book.

This is a preview edition of the book. The full version is available only at -

http://ccdonmirth.shamilpublishing.com

http://ccdonmirth.shamilpublishing.com/

3 Introduction

Contents

PART 1 GETTING STARTED

Chapter 1 Mirth Connect Basics................................................................................................ 13

Installation ............................................................................................................... 13

Mirth Connect Administrator .................................................................................... 14

Channels .................................................................................................................. 15

Connectors............................................................................................................... 16

Filters ...................................................................................................................... 17

Transformers............................................................................................................ 17

Scripts...................................................................................................................... 18

Chapter 2 What is a CCD?......................................................................................................... 20

CCD Development Approach ..................................................................................... 20

Templates ................................................................................................................ 22

Summary ................................................................................................................. 24

Chapter 3 System Integration Requirements ............................................................................ 26

Abstraction Layer ..................................................................................................... 26

System Integration Requirements.............................................................................. 29

Testing ..................................................................................................................... 31

Summary ................................................................................................................. 33

Chapter 4 Transforming Data with Mirth Connect ..................................................................... 35

Scenario Overview .................................................................................................... 36

Design Considerations............................................................................................... 38

Summary ................................................................................................................. 40

PART II CCD BUILDER SERVER IMPLEMENTATION

Chapter 5 Query Sender Channel.............................................................................................. 42

Summary Tab ........................................................................................................... 42

Source Connector ..................................................................................................... 43

Destinations Connector............................................................................................. 45

Summary ................................................................................................................. 49

Chapter 6 CCD Builder Channel – Header ................................................................................. 50

Introduction 4

Summary Tab ........................................................................................................... 51

Source Connector ..................................................................................................... 52


Code Templates........................................................................................................ 63

Global Scripts .......................................................................................................... 65

Channel Implementation Verification ........................................................................ 65

Summary ................................................................................................................. 66

Chapter 7 CCD Builder Channel – Allergies ............................................................................... 68


Code Templates........................................................................................................ 76

Global Scripts ........................................................................................................... 78

Channel Implementation Verification......................................................................... 79

Summary ................................................................................................................. 80

Chapter 8 CCD Builder Channel – Medications ......................................................................... 81


Global Scripts ........................................................................................................... 89

Channel Implementation Verification......................................................................... 90

Summary ................................................................................................................. 90

Chapter 9 CCD Builder Channel – Problems .............................................................................. 91


Global Scripts ........................................................................................................... 97

Channel Implementation Verification ........................................................................ 98

Summary ................................................................................................................. 98

Chapter 10 CCD Builder Channel - Results................................................................................. 100

Destinations Connector........................................................................................... 101

Global Scripts ......................................................................................................... 106

Channel Implementation Verification....................................................................... 107

Summary ............................................................................................................... 107

PART III CCD VALIDATION

Chapter 11 CCD Validation Tools .............................................................................................. 110

XML Schema Validation........................................................................................... 110

5 Introduction

Schematron Validation............................................................................................ 111

MIF Validation ........................................................................................................ 113

Conformance Validation.......................................................................................... 113

Summary ............................................................................................................... 114

Chapter 12 CCD Validation Automation .................................................................................... 115

XML Schema Validation........................................................................................... 116

Schematron Validation............................................................................................ 119

Summary ............................................................................................................... 124

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

APPENDICES

A: CCD Mirth Templates .......................................................................................... 127

B: Code Templates .................................................................................................. 130

C: HL7v2 Test Messages .......................................................................................... 133

D: XSLT files ............................................................................................................ 134

E: Archive Content .................................................................................................. 140

Introduction 6

Introduction

Introduction As Mirth Corporation says on their web-site, “Mirth Connect is the Swiss Army knife of

healthcare integration engines, specifically designed for HL7 message integration. It

provides the necessary tools for developing, testing, deploying, and monitoring interfaces.

And because it’s open source, you get all of the advantages of a large community of users

with commercial quality support.”

In addition, “The 2014 HL7 Interface Technology Survey Results” show that Mirth Connect

is one of the fastest growing healthcare messaging platforms due to its open-source

paradigm, and robust functionality for HL7 messaging and X12 documents. Mirth

Connect also speeds up the development of interfaces for data exchange across different

formats and diverse healthcare systems environment.

This book describes version 3.x of Mirth Connect to the point that reader are confident

enough to start building their own healthcare data exchange interfaces and transforming

HL7 messages to CDA/CCD documents.

As you read this book, you will be implementing a fictitious CCD Builder Server. Each

connection point (channel and destination) is explained in a separate chapter, which in

turn provides step-by-step instructions on how to create and code data transformation

rules.

This book is written using Mirth Connect version 3.1.1.7461. Consequently, other releases

may include new features, and features used in this book may change or disappear. You

may also notice differences between screen shots provided in the book and those you

see when using Mirth Connect.

Who is this book for?

I wrote this book primarily for application developers and system integrators who have

found the online Mirth Connect documentation lacking and needed a guidebook that

covers topics in a more detailed and organized way.

A book of this size cannot cover every feature in Mirth Connect v3.x; consequently, I

assume you already have some familiarity with its main components, functions and use.

http://corehealthtechnologies.com/main/wp-content/uploads/2014/06/2014-Healthcare-Integration-Professionals-Survey-Results.pdf

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).

Who should not read this book?

As mentioned earlier, the purpose of this book is to provide the reader with a high-level

overview of the capabilities and features in Mirth Connect v3.x. This book is not intended

to be a step-by-step comprehensive guide or substitute of any kind for training and

certification programs provided by Mirth Corporation.

This book is also not a tutorial on a specific messaging or middleware technology such

Model Driven Health Tools (MDHT) or Mirth CDAPI. All examples included in this book

are for illustrative purposes only. If you are interested in learning more about a specific

technology or product, please refer to one of the many on-line resources, or trainings

and certifications provided by Mirth Corporation or its affiliates.

This book does not cover any specific installation, configuration, deployment or

monitoring activities for system administrators.

Errata and Book Support

I have made every effort to ensure the accuracy of this book and its companion content.

If you find an error, please report through email - [email protected]

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 accurate as possible, but no warranty or fitness is

implied.

The information is provided on an “as is” basis. The author shall have neither liability nor

responsibility to any person or entity for any loss or damage caused, or alleged to be

caused, directly or indirectly by the information contained in this book or from the use of

software mentioned in this book. The information, methods and techniques described by

the author are based on his own experience. They may not work for you and no

recommendation is made to follow the same course of action. No representation is made

that following the advice in this book will work in your case.

The author is not an employee or representative of Mirth Corporation and never has

been, and author’s views and opinions are not necessarily those of Mirth Corporation.

This book is not based on trainings or certifications provided by Mirth Corporation or its

affiliates.

This book contains links to third-party websites that are not under the control of the

author, and the author is not responsible for the content of any linked site. If you access

a third-party website mentioned in this book, you do so at your own risk. The author

provides these links only as a convenience, and the inclusion of the link does not imply

that the author endorses or accepts any responsibility for the content of those third-

party sites.

Furthermore, this book contains information on the subject only up to the publication

date.

Acknowledgements

Like most books, this guide has been a long time in the making. I would like to

acknowledge everyone who has assisted in this project. I could not have done this

without you.

I’d like to thank Philip Helger for his contribution to the development of the open-source

Schematron validator.

My biggest thanks go to Wayne Zafft, who was incredibly gracious with his time and

effort in reviewing the final version of the book.

9 Introduction

Roadmap

This book is divided into three parts:

Part I provides an introduction to Mirth Connect and a high-level overview of the CCD

document paradigm.

Chapter 1, Mirth Connect Basics

Introduces Mirth Connect at a high level, provides an overview of the channel

architecture implemented in Mirth Connect, walks the reader through the creation

and configuration of a simple channel.

Chapter 2, What is CCD

Provides an overview of the Continuity of Care Document or CCD, the XML-based

markup standard intended to specify the encoding, structure, and semantics of a

patient summary clinical document for exchange.

Chapter 3, Systems Integration Requirements

Provides a brief overview of system design and systems integration requirements to

demonstrate the complexity of a typical HL7 based integration project.

Chapter 4, Transforming Data within Mirth Connect

Introduces a typical scenario as it is defined in the HL7v3 Normative Edition, presents

the implementation plan for the rest of the book and walks through the required

components.

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

generating server.

Chapter 5, Query Sender Channel

Walks the reader through the implementation of the first channel in a chain that

serves as an interface to send HL7v2 messages and handle acknowledgements.

Chapter 6, CCD Builder Channel - Header

Explains the implementation of a channel that plays the major role in this project. The

chapter shows how to establish a MLLP connection to other channels, how to filter

messages based on some criteria and transform part of the inbound messages to

form the CCD header.

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.

Chapter 8, CCD Builder Channel - Medications

Continues implementation of required section level templates. Shows iterations and

mapping of multiple segments.

Chapter 9, CCD Builder Channel - Problems

Continues implementation of required section level templates. Shows iterations and

mapping of multiple segments.

Chapter 10, CCD Builder Channel - Results

Shows how to iterate through segment groups each of which may contain repeating

segments. This chapter concludes implementation of the CCD document.

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

Chapter 11, CCD Validation Tools

Introduces a message verification process using different tools and methods such as

XML schema validation, MIF validation, Schematron validation and conformance

review. Lists some open source tools and toolkits that readers may use to build and

test HL7v3 and CDA interfaces.

Chapter 12, CCD Validation Automation

Walks the reader through the implementation of the XML Schema and Schematron

validator scripts using open-source libraries.

Appendices include:

Archive Content

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

CCD Mirth Templates

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

Code Templates

Shows all mapping functions defined as Code Templates functions.

XSL transformation files

11 Introduction

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

HL7v2 samples

Lists ADT_A28 and ORU_R01 message samples.

PART I – GETTING STARTED 12

PART I – GETTING STARTED

Getting Started CHAPTER 1 Mirth Connect Basics

CHAPTER 2 What is CCD?

CHAPTER 3 System Integration Requirements

CHAPTER 4 Transforming Data with Mirth Connect

13 PART I – GETTING STARTED

CHAPTER 1 Mirth Connect Basics

Mirth Connect Basics 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 to run Mirth Connect on your computer. You

simply unzip and copy the package to an appropriate folder, for example to C:\Program

Files\Mirth Connect\. In the other case, there is a GUI based wizard that you start to

go through the steps in the installation. The installation process itself is quite straight

forward.

Both methods install Mirth Connect Server, Mirth Connect Server Manager, Mirth

Connect Administrator and Mirth Connect Command Line Interface. During the

installation you have to decide which port is used by the Mirth Connect Server. The

default is 8080 for unsecure communication and 8443 for the SSL connection. You can

change the ports later using the Mirth Connect Server Manager, if necessary.

To verify the installation:

Launch the Mirth Connect Server either through the Mirth Connect Server Manager

or the Mirth Connect Command Line;

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

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

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

If you see the Dashboard statistics page with, most likely, no channels available, you have

successfully installed Mirth Connect and are ready to continue. If not, refer to Mirth

Connect 3.1 User Guide written by “the same Mirth technical experts who developed the

software” available at - http://info.mirth.com/Connect_Documentation_Download.html

T

http://info.mirth.com/rs/mirthnextgen/images/MConn_v3_0_1_UserGuide.pdf

http://info.mirth.com/rs/mirthnextgen/images/MConn_v3_0_1_UserGuide.pdf


Configuration

The Mirth Connect Server Manager can be used as a single point to launch Mirth

Connect Service, configure ports, allocate memories, and to establish database

connections. However, a fully-fledged configuration description is beyond the scope of

this book.

As a recommended option, add a path to the \custom-lib folder in the operating

system’s CLASSPATH environment variable. This is the folder where you put Java classes,

libraries and other required files that Mirth should be working with.

If any application on your computer or firewall uses ports 8080 or 8443 you can either

change Mirth’s ports by using Mirth Connect Server Manager or by manually modifying

the configuration file located in \conf\mirth.properties. Don’t forget to restart the

Mirth Connect Server or Service to activate your changes.

Mirth Connect Administrator

The Mirth Connect Administrator is a Java application that, by default, is not explicitly

installed on a local computer in a distributed environment. It is downloaded from the

Mirth Connect Server. This ensures the Mirth Connect Administrator matches the version

of the Mirth Connect Server being used.

To download the Mirth Connect Administrator:

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

Open the web browser;

Type localhost:8080 in the address bar;

Click Launch Mirth Connect Administrator in the Mirth Connect Administrator launch

page;

Click Ok to open webstart.jnlp;

Type admin for the user name and repeat admin as the password in the Mirth

Connect Login pop-up window, then click Login.

If everything is done correctly, each time you login, you will see the Dashboard as the

initial screen. The Dashboard displays two information panels:

Channels status and statistics – shows the number of messages Received, Filtered,

Queued, Sent, and Errored. The left sidebar of the Dashboard has tasks panel, with

menu options related to your current activity. For example, when you are developing

a channel, menu options such as Refresh, Send Messages, and Remove All Messages


are displayed. These menu items can be also accessed by right clicking on a channel

name in the Channel List.

Logs – Server Log, Connection Log and Global Maps. The Server Log is used to debug

channel development. Double-clicking on a Server Log entry brings a pop-up

window where you can view and copy the entire log entry content. The Server Log is

stored by Mirth Connect Server in the database; closing and opening the Mirth

Connect Administrator brings back all entries not explicitly purged. To clear the

Server Log click Clear Displayed Log under the Server Log or Connection Log area.

Familiarize yourself with other navigation items and tabs since this is the main tool used

to develop and configure channels throughout this book.

Channels

The Channel is an essential part of Mirth Connect and can be seen as one-to-many

abstract unidirectional pipes that decouple components from each other to transfer

healthcare data between two or more applications. The channel architecture

implemented in Mirth Connect can divide a large message processing task into a

sequence of smaller independent steps. This affords developers the flexibility for

dependency, maintenance and/or performance. Some of the processing tasks can even

be external to Mirth Connect and developed independently.

FIGURE 1-1 Mirth Connect abstract channel architecture

In general, each channel consists of inbound and outbound Connectors, Filters and

Transformers. The connector that receives inbound messages from the Sending

Application is called the Source. Similarly, the connector that sends outbound messages


is called the Destination. From the Source connector, data is passed through the channel,

where filters and transformers perform operations on the data, for example, routing a

message to one or another Destinations connector and transforming the data

representation. Deciding each channel’s tasks is when wearing an analyst's hat comes

into play.

Before you create a new channel, you need to elicit the following requirements:

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

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

Type and format of the inbound message;

Type and format of the outbound message(s);

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

Connectors

In terms of Enterprise Integration, the connector is a Message Endpoint that specifies a

particular way or, more accurately, a particular protocol Mirth Connect should use to

communicate with an external application or another Mirth Connect channel.

Mirth Connect supports sending and receiving messages over a variety of connectors

listed here in no particular order:

TCP/MLLP;

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

File (local file system and network shares);

PDF and RTF documents;

JMS;

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

SMTP;

SOAP (over HTTP).

The connector that receives the data is called a Reader, for example the MLLP Reader.

The connector that sends the data is called a Writer, the Database Writer is an example.

Connector types are configured under Source and Destinations tabs of the channel.

Obviously, some settings are common across all connectors while others are unique to a

specific connector type.

You can develop your own connector if you need one that is not shipped with the Mirth

Connect installation package, e.g., HTTPS connector. However, this is out of scope of this

book.


Filters

In a real world scenario, when numerous applications and channels are connected, a

channel may receive messages from several sources and may process these messages

differently, based on the message type or other criteria.

There are two paradigms for addressing this requirement, a Router and a Filter:

Router connects to multiple outbound channels. The key benefit of the Router is that

the decision criteria for the destination(s) of a message are maintained in a single

location.

Filter, this is what Mirth Connect uses, is built into a message processing mechanism

and determines whether or not the message should be processed. The Filter inspects

message properties (segments or elements) without removing the message from the

message queue. If the message cannot be consumed by this particular pipe, it is

returned to the queue unchanged for another pipe to filter or process.

Filters can be as simple as comparing specific elements against a hard coded value or as

complex as a scripting language routine. Filters can also be omitted allowing all

messages to pass through. Some routing capabilities have been introduced in Mirth

Connect v3.1 by using a "destinationSet". If a destination is removed from the

destination set, this destination will not receive the message.

If a single channel needs to process more than one type of message, you can create any

number of separate pipes – Destinations - and specify none, one or more filters for each

pipe.

Transformers

More often than not, messages are sent between legacy systems, custom applications

and third-party solutions, each of which is built around a proprietary data model. Even

systems that claim to support a single standard may place specific requirements on data

format and content. If we could bring all legacy systems to a single format when a new

business requirement is proposed, we would avoid conversion issues. Unfortunately, for

most legacy systems, data format, content or data sequence changes are difficult and

risky, and simply not feasible.

How do we communicate data using different formats then? Mirth Connect does this in a

message Transformer that translates one data format into another. As a result, a

destination application can receive messages it understands and which can be processed

and stored in the application’s internal data format.


Mirth Connect allows message transformation to occur at different levels and to chain

message transformers to achieve a required result.

Supported transformers are:

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

outbound message.

Mapper maps segments of the inbound message to internal Mirth Connect variables.

These variables may be used later.

External Script, as the name suggests, employs external JavaScript routines to

transform or map the data.

XSLT Step utilizes the XSL transformation.

JavaScript, along with External Script, is where flexibility comes into play. Here any

type of (Rhino) Java Script and Java code can be used.

Scripts

Channels also support unique features called Scripts to enhance message processing

logic. Scripts apply to a channel itself and all messages that are passing through.

These scripts are:

Deploy script is executed each time Mirth Connect Server starts or a channel is

redeployed. This is the best place to initialize variables or create class objects.

Attachment script deals with a message in a native format and allows extracting part

of the message to store as an attachment or to irrevocably modify a message.

Preprocessor script also allows handling each message in a native format before

Mirth Connect starts translating it into the internal format, which is XML.

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

outbound messages.

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

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

Undeploy script is launched each time Mirth Connect Server stops. This is the place

to, for example, release memory that was allocated for the classes used by the

channel.

Mirth Connect uses JavaScript as a scripting language with the ability to extend it by calls

of external Java classes. The latter may be one of those included to the Mirth installation

package or user defined.

Besides the channel level, Mirth Connect employs Global Scripts that play the same role

as channel scripts and help in separating the business logic. They have the same Deploy,


Undeploy, Preprocessor and Postprocessor scripts; the only difference is that they apply to

all channels.

This concludes Mirth Connect introduction section. To find out more, you may refer to

numerous web resources, including trainings and books provided by Mirth Corporation.

You may find it helpful to read “Unofficial Mirth Connect v3.x Developer’s Guide“ eBook

which covers Mirth Connect basics and advanced topics in greater details.

This eBook is available at - http://mirthconnect.shamilpublishing.com

http://mirthconnect.shamilpublishing.com/


CHAPTER 2 What is CCD?

What is CCD? he Continuity of Care Document or CCD, is an XML-based markup standard intended

to specify the encoding, structure, and semantics of a patient summary clinical

document for exchange. (Wiki) From the standard development perspective “the

Continuity of Care Document is a joint effort of HL7 International and ASTM. CCD fosters

interoperability of clinical data by allowing physicians to send electronic medical

information to other providers without loss of meaning and enabling improvement of

patient care. CCD is an implementation guide for sharing Continuity of Care Record (CCR)

patient summary data using the HL7 Version 3 Clinical Document Architecture (CDA),

Release 2.” (HL7 CCD page)

Basically, what has been done is the HL7 Clinical Document Architecture (CDA) is taken

as a document markup standard and constrained by the ASTM Continuity of Care Record

(or CCR also referred to as ASTM E2369-05) data sets into specific headers and

templates. The resulting semantic equivalent was called the Continuity of Care

Document. In the U.S., this specification has been refined further by U.S. federal

incentives known as Meaningful Use stages 1 and 2.

Prerequisites

In case of any discrepancies found in this book, implementers must follow the

conformance requirements of CDA and CCD. You should have following specifications

available:

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

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

CCD Development Approach

Besides CCD standard specifications, the CCD distribution package includes CCD and

core HL7 XML schemas, CCD XSLT stylesheets and non-normative examples of

Schematron rules required to validate documents.

From a standard developer point of view, the approach used in this book to develops

core artifacts for the document-level templates (which is CCD in our case) is by taking a

subset of classes defined in the CDA R2 R-MIM model and constraining them to reflect

the ASTM CCR specification.

T


In general these steps are:

CDA document derives its classes and machine-processable meaning from the HL7

Reference Information Model (RIM) in conjunction with HL7v3 Data Types.

CCD document derives its classes from CDA Refined Message Information Models

(R-MIM).

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

As CCD R-MIM is finalized, the XML schema(s), possibly with other artifacts such as

Model Interchange Format (MIF) files and Hierarchical Message Descriptor (HMD)

views, are generated.

As the last step, CCD XML schema is manually updated to include extensions

required to map ASTM CCR components for which there is no suitable mapping in

CDA R2.

Schematically this may be represented as Figure 2-1.

FIGURE 2-1 CCD development approach

As you can see, the CCD R-MIM, derived from the CDA R-MIM, follows the same

structure, i.e., it contains a required header to identify the document and participants,

and a body to represent a generic structure of a clinical content.


This method for creating CCD XML schema is based on HL7v3 refinement and

localization mechanism and can be applied to any RIM based artifact (messages or

documents).

Templates

The next level of constraint is based on logical groupings or patterns defined at the

sections and entry levels to provide specific clinical context. Thus, as the HL7 NE states:

“The CDA specification is richly expressive and flexible. Document -level, section-level and

entry-level templates can be used to constrain the generic CDA specification.” Such

patterns, called templates, can “comply with a detailed implementation guide that details

the manner in which structured elements are to be represented and their intended

interpretation to a level sufficient to ensure a degree of clinical safety that is appropriate to

the use case that it is designed to address.” (HL7v3 NE)

This approach brings extended flexibility and allows the creation of a wide variety of

templates which still follow the HL7 standard and CDA defined structure. If you think this

is not enough, CDA allows including both structured and unstructured information at the

CDA Level. The CDA specification distinguishes three incremental levels of conformance

for semantical interoperability.

CDA Level 1: The simplest form of CDA, also known as CDA Level 1, includes the header

and unstructured block where the “NonXMLBody class represents a document body that is

in some format other than XML”. (HL7v3 NE) The CDA Level 1 is not allowed as defined in

the Meaningful Use initiative.

CDA Level 2: Next form is “the CDA specification with section-level templates applied”.

(HL7v3 NE) Section level templates are identified by an associated templateID and

represented in XML.

CDA Level 3: At this level “the CDA specification with entry-level (and optionally 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.


Section-level templates

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.

FIGURE 2-2 CDA section-level templates

Document-level templates can exclusively use some section-level templates and share

others. For each document in US Realm, some subsets of section-level templates are

mandatory according to Meaningful Use Stage 2 (MU2).

Entry-level templates

CDA does not stop at the section level but additionally defines up to one hundred 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.

CDA Sections

Advance

Directives

Reason for

ReferralPresent Illness

Discharge Diet

General Status

Immunizations

CCD sections

Results

Allergies

Medications

Problems

MU2

Social History

Vital Signs

Consultation Notes sections

Encounters

Past IllnessFamily History

Plan of Care Reason for Visit

Physical Exam

MU2

... ...

......

...

... ...

Medical

Equipment

Payers

......


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).

SOURCE 2-1 BodyTemperature entry-level template <observation classCode="OBS" moodCode="EVN"> <templateId root="2.16.840.1.113883.3.1937.99.60.5.10.126"/> <id root="....."/> <code code="8310-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Body temperature"/> <statusCode code="complete"/> <effectiveTime> <low value="....."/> </effectiveTime> <value xsi:type="PQ" value="....." unit="Cel"/> </observation>

US Realm related CCD Implementation Guide may recommend additional sections for

conveying healthcare data that conforms to MU2 requirements. MU2 also applies

additional constrains on all template levels.

Summary

This chapter has barely scratched the surface, providing a general overview of one of the

CDA family templates called Continuity of Care Document (CCD) which is semantically

equivalent of ASTM Continuity of Care Record (CCR). Rather than explaining CCD in

depth, which requires a book by itself, this section gives you a basic road map for

exploring and understanding CCD.

If you are not familiar with HL7 and HL7v3 in particular, you may start with HL7v3

Normative Edition and move towards Clinical Document Architecture domain. I wrote

another book, called “Unofficial Developer's Guide to HL7v3 Basics3” to help you in this

endeavour.

2 HITSP - Healthcare Information Technology Standards Panel 3 Available to download at - http://hl7basics.shamilpublishing.com


Below is a non-exhaustive list of other resources to help you educate yourself on various

aspects of CDA and CCD.

Primary Standard is available on the HL7.org site. You need to register to get access.

CDA® Release 2;

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

HL7 Implementation Guide: CDA Release 2 – Continuity of Care Document

(CCD)4;

HL7 Implementation Guide: S&I Framework Transitions of Care Companion Guide

to Consolidated-CDA for Meaningful Use Stage 2, Release 1 – US Realm;

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

IHE CDA Section Templates -

wiki.ihe.net/index.php?title=Category:CDA_Section_Templates

Below are listed quite a few books that I found helpful in this topic. If you are not familiar

with HL7 or CDA in particular, start with Tim Benson’s book then continue with the book

written by Keith Boone.

Principles of Health Interoperability HL7 and SNOMED by Tim Benson.

The CDA Book by Keith W. Boone.

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

this book:

Non-normative MU2 constrained CCD R-MIM diagram in Visio format (for

illustrative purpose only);

Hierarchical Message Descriptions (HMD) in Excel View derived from the CCD R-

MIM (for illustrative purpose only).

4 Referred in this book as HL7 CCD.


CHAPTER 3 Systems Integration Requirements

System Integration Requirements his chapter is a brief overview of system design and systems integration requirements

for implementing the CDA based system. If you are more or less familiar with HL7

systems implementation you are free to skip it. As you surmise, I have not started

from interoperability in general, or HL7 as a standard, or HL7 Reference Information

Model (RIM) in particular. Undoubtedly, HL7 interoperability is crucial to the integration

of clinical health information systems. It is the cornerstone of HL7v3 and may be used as

a key selling point of HL7v3. But my experience shows that focussing on interoperability

adds little value for software developers. For them, HL7v3 format, which CDA and CCD

are based on, is a fait accompli and the task at hand is to implement it.

Abstraction Layers

As a software developer you know that building an enterprise level information system

requires proper layers of abstraction. N-tier architecture provides a high degree of

decoupling, separating presentation, business logic and data tiers. Information

technology came to this solution after much trial and error. If business needs were stable

such a solution would not be required. However, today’s business, eHealth in particular,

faces constant change from new regulatory requirements (e.g., EHR Meaningful Use

stage 1 to 3 in the USA), market changes and improvements in operational processes. To

achieve flexibility, various types of abstraction layers are possible to hide the

implementation details of particular functions and integrate them based on their

purpose.

The Abstraction Layer shown in Figure 3-1 hides the complexity of the back-end system,

letting the application request the data using well-organized meaningful calls and

without having to worry about the actual data location and structure.

In this diagram, data is stored in the Data Repository. The purpose of it is to show that

medical data may be located in different sources: relational databases, spreadsheets,

documents, flat files and “clouds” as more mobile applications emerge.

Consider the notional flow of data for such a simple system:

1. The Application makes a request to the Abstraction Layer to retrieve the patient

medical information;

2. The Abstraction Layer makes a request to the Data Repository;

T


3. If data is available, the Data Repository returns it to the Abstraction Layer;

4. The Abstraction Layer forms the data in the way the Application expects and sends it

to the Application;

5. The Application processes the data and uses it as intended.

FIGURE 3-1 Simple system architecture using an abstraction layer

Even this simple scenario is missing key elements: the alternative and exception flows are

not shown, leaving the Application unaware if data is unavailable for one reason or

another; also, this scenario does not tell if data sources are physically distributed or

hosted on different operating systems and/or or data storage environments (e.g.,

databases from different vendors).

What if the Abstraction Layer cannot find the data in the Data Repository? If business

logic allows there will be additional steps to request data from a remote system probably

using one of the HL7 messaging standards.

Figure 3-2 schematically shows an abstract system with added CCD document building

capability. If you are not familiar with the HL7 and CDA standards, you may wonder why

there are several streams (only four are shown but there may be more), each of which

has its own message translator and content enricher. Also, what data sources are these

two streams are using? We will explore this in following chapters.

You may think of the Abstraction Layer as a Database Access Layer (DAL) that

encapsulates all requests to data sources. It may also function as an Enterprise Service

Bus (ESB) in a message-oriented processing model that supports synchronous or

asynchronous communications, content-based message forwarding and filtering,

transformation functionalities and mapping between different interfaces. Since DALs or

ESBs are often implemented in very different ways, requiring a broad range of specific

functionalities and operating characteristics, I will use the term Abstraction Layer to avoid

confusion with vendor-specific implementations.


FIGURE 3-2 System architecture with CDA builder capability

Assuming a Web Service is used to deliver a document, the notional data flow with

added CCD Builder functionality may be described as:

1. The Application makes a request to the Abstraction Layer to retrieve the patient

medical information.

2. The Abstraction Layer makes a request to the Data Repository.

3. If data is available, the Data Repository returns it to the Abstraction Layer.

4. The Abstraction Layer forms the data in the way the Application understands and

sends it to the Application. The latter sends the data to the CCD Builder component.

5. The CCD Builder component, in turn, forms parts of the document, aggregates them

into a single document, wraps the message in a SOAP envelope or other transport

mechanism, and sends it to the remote system or storage.

6. The HL7v3 Receiver component gets the response, verifies that the response belongs

to this destination, extracts the payload and passes it to the Abstraction Layer.

7. The remote system processes the data and uses it as intended.

Besides typical alternative and exception flows related to communication, questions that

left unanswered are:

If the patient medical information is not available in the Data Repository, what should

the system do?


If the local Data Repository contains data that differs from data in the remote system,

and the local data is older, what should the system do?

If the remote system asks for a set of data but CCD is not capable of conveying such

data to fulfil the remote system need, what should the Application do?

Such questions may significantly affect the architecture, implementation and ultimately

the functionality of the system. Let’s consider other aspects that may influence the HL7

based system architecture.

System Integration Requirements

Different types of requirements shape a system’s behavior. Stakeholders (users, sponsors,

clients, etc.), healthcare practitioners and subject matter experts (SMEs) are typically

good at eliciting all levels (organizational, system, component) of functional

requirements. Undoubtedly, developers will be provided with a huge list of functional

system requirements, probably with a great number of use cases. Presumably, these

requirements are complete, consistent, unambiguous, feasibly implemented and

verifiable. As such, they provide a concrete basis for the developed system.

Customers are usually not interested in seeing how functional requirements are

implemented. The terms they use to describe system functionality, more often than not,

apply to direct or indirect non-functional requirements (NFR), such as qualities and

constraints. NFRs represent a significant delivery risk to a project since neglecting or

improperly dealing with NFRs during the initial requirements elicitation process, or

during the system development lifecycle, leads to inaccurate estimation of project’s

scope and efforts. Errors due to omitting NFRs or to insufficient attention paid to their

analysis are among the most expensive and difficult problems to correct.

Among a huge list of non-functional requirements, there are some that affect healthcare

systems integration. A few, for illustrative purposes, are discussed here to show the

consequences of (not) implementing them. NFRs are listed in no particular order.

Auditability

Auditability is the ability of the system to keep the audit logs so that interactions with

other systems can be inspected. Unlike other communication systems, HL7 messages

often include sensitive medical information (also see Security). Meeting the legal

requirements for auditability leads to a number of questions such as what data to collect,

how to store it, how to prevent unauthorized access to audit records, and how to

maintain data integrity. Depending on workflow, the number of messages exchanged by


systems can be significant and the number of transactions will grow over time. This raises

the issue of predicting hardware capacity growth, particularly if the legal requirement is

to keep all communicated messages for several years. Additional implementation

considerations arise from backup, disaster recovery plan and retention period

requirements.

Performance

Performance is one of the most ambiguous runtime non-functional requirements. The

user expectation is typically characterized as “the system should be fast” and written as “a

transaction should take less than N seconds to complete”. However neither specifies if a

transaction is considered complete when a response message enters a system, or when

the end-user sees the result of the initial (for example, search query) request. If it is the

latter, does it consider both the system’s messaging component performance

requirement and system’s user interface performance requirement? If there is another

requirement to put mechanisms into place that automate some levels of conformance

testing of incoming messages, does the original “… N seconds to complete” still apply

during peak hours? If a transaction has timed out, does the original “… N seconds to

complete” mean N seconds to successful conclude the transaction, or just N seconds

before the end-user receives some kind of feedback? Decisions made here also affect

scalability.

Security

Security in healthcare systems is paramount given the sensitive, personal information

maintained and communicated and to protect from fraud and other breaches. There are

many great books that cover security from different aspects and levels of granularity. If

you are new to the healthcare industry, you need to know that, besides typical computer

systems security requirements, national health sectors often specify their own security

requirements (e.g., Health Insurance Portability and Accountability Act or HIPAA in the

USA) to protect highly sensitive medical information from fraud and security breaches .

Violations of such regulations can lead to lawsuits and other enforcement actions. Even if

not applied directly to the CDA standard, some of the security rules that HIPAA regulates

are: audit controls to review healthcare system activities, and transmission security which

includes integrity controls and encryption/decryption during transmission. Other

countries may apply other international and local legislation acts, which can greatly

affect the way HL7 messages are structured, processed or communicated (e.g., Personal

Health Information Protection Act or PHIPA, and Personal Information Protection and

Electronic Documents Act aka PIPEDA in Canada).


Transactional Reliability

Transactional reliability determines the portion of successfully completed transactions,

(i.e., number of messages delivered to, processed, and returned by a remote system).

Transactional reliability is measured, from a positive perspective, as service availability,

for example, 99.998%. This metric, however, may affect transaction timeout settings and

performance.

Testing

Be it through a waterfall, agile or another approach to system development, sooner or

later functional and non-functional aspects of the system need to be tested. You may

already use or be familiar with such widely adopted agile practices as Test-Driven

Development and Behavior-Driven Development aimed at creating reliable and

maintainable code. Whatever testing strategy you choose, they can probably be

categorized as using business-facing and technology-facing test models (introduced by

Brian Marick). On the business-facing side, functional acceptance testing verifies how the

system is built, including functionality, capacity, usability, security, modifiability,

availability, etc. The technology-facing tests are commonly used by developers during

the development process: unit tests, component tests, and deployment tests.

Integration testing

Integration testing is especially crucial for a system that communicates with other

systems using different protocols, or for a system consisting of loosely coupled

components (units, modules).

Integration testing is generally performed in these different contexts:

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

part of unit testing.

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

environment as possible.

Production environment.

Ideally, you would be provided with a replica of a system that behaves exactly like the

production system and allows performance, capacity, security and other functional and

non-functional requirements to be tested. However, in the real world, you will often need

to develop such an environment on your own. It is therefore essential that your

environment allows for the testing of unexpected situations such as network transport

problems, protocol problems and external systems (logic) problems.


Test data

Performing business-facing tests (acceptance testing) and technology-facing tests

(integration testing and sometimes unit testing) is not possible without test data, which

raises the issue of managing test data.

The test team is often provided with a dump of data from the production environment.

These data usually consist of three broad groups: test specific data, test reference data

and application reference data. For technology-facing tests such as unit tests, the

developer may create a smaller dataset of fake test data that covers all three groups.

Other types, such as acceptance-testing, integration testing, non-functional testing need

more sophisticated test data to verify desired behavior against the system’s integration

requirements.

Capacity testing unveils the issue of scaling up existing data to create sufficient volumes

of representative data for different performance-related test cases.

A key challenge for managing test data in a healthcare systems development

environment is to comply with current legislations and regulations aimed at protecting

the privacy of patient’s personal demographic and health information – specifically to

prevent disclosing either the identity or other attributes of private individuals. This is

where de-identification comes into play. De-identification of patients’ information is

essential where data is disclosed for testing (and also often analytical) use. De-

identification of health data is an important topic by itself and requires separate books.

Reasons for healthcare data de-identification include: developers’ laptops, hard disks or

USB flash drives may be lost or stolen; a company may experience "sophisticated

computer security attack" against their servers; and other breaches (recent breach

reports may be found at databreachtoday.com website). Indeed, media outlets are quick

to report data breaches involving (stolen) patient health data. Additionally, many

jurisdictions have breach notification laws that requires notifications to be sent to

regulatory bodies, including media, if data breaches occur.

Before I continue, I’ll give a short quiz. Which of these three sets of personal information

is de-identified? Consult the White Pages if you want.

Rhonda James; DOB: 08-Sep-1988; Address: 71 Ansubet Dr, Charleston, WV

Denise Lewis; DOB: 03-Mar-1976; Address: 23 Adams Chapel Rd, Mankato, MN

Rosemarie Hardy; DOB: 14-Nov-1985; Address: 310 Camp Creek Rd, Weston, MA

And so, how many Denise Lewis’s live in Minneapolis?


In fact, the source5 that provided these samples suggested that all three are de-identified

data. Imagine if such de-identified datasets are stolen and reported as “the data breach”

by the media. The company may face severe fines and damage to its reputation long

before it can be proven that the stolen datasets are fictitious and do not represent any

real person.

There are different algorithms for record-level data de-identification such as: data

reduction, data modification and data suppression. Before you start implementing your

own, I recommend you read the Tools for De-Identification of Personal Health

Information6 report written by Ross Fraser and Don Willison for the Pan Canadian Health

Information Privacy (HIP) Group. This report explains major techniques, requirements for

health data de-identification tools, and some of the commercially available tools.

Other sources worth reading:

A Canadian standard: “Best Practice” Guidelines for Managing the Disclosure of 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.

Summary

This chapter shows that in addition to typical software development issues, the HL7-

based development project has layers of additional complexity due to interconnected

functional and non-functional requirements.

Healthcare by itself is a difficult domain. Software developers that see CDA documents as

yet another XML-based feed system run the risk of significantly underestimating the

effort needed to complete a project.

HL7 development requires not only properly eliciting and documenting functional and

non-functional requirements, but also the eHealth landscape in which the project

operates. You may be committed to build a scalable application capable of constructing

countrywide level CDA document and processing all section-level templates, but your

local regulatory restrictions may prevent sharing personal information with other

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


jurisdictions. Consider time and effort spent on building unnecessary functionality before

it becomes obvious.

Testing HL7-based systems is a separate (sub) project by itself. It must conform to

eHealth industry and local regulatory auditing and security requirements to protect

sensitive information, and may require test data sets to be prepared upfront.

Before you start building HL7 messaging application, it is essential that you understand

the full complexity of HL7v3 based development work.


CHAPTER 4 Transforming Data with Mirth Connect

Transforming Data with Mirth nlike other universal domains in the HL7v3 Normative Edition , the Clinical Document

Architecture does not specify storyboards, interactions and participants. This domain

deals only with the CDA document exchange markup. On the other side, Mirth

Connect provides greater freedom in data transformation since it allows using different

techniques for data mapping such JavaScript, XSLT and Java.

“Messaging” and “document” are understood differently by developers, end users and

clinicians. A lab report in PDF format sent as an attachment by email is one of the

options but such scenarios are not what I want to explore in this book. Before

implementing an imaginary CCD Builder Server using Mirth Connect, we need to

examine what we are trying to build. Also, it is good to note that this s erver is

“imaginary” because the goal is to fully concentrate on Mirth Connect features rather

than on actual CCD or MU2 business rules.

Note: Before we start, I would like to stress that HL7 interactions and templates (in

terms of CDA) shown in this book do not represent a real implementation and

should not be used “as is”.

Some words of caution should be raised before delving any deeper. The Mirth Connect

HL7v2 messages parser is based on HAPI API which uses HL7 organization specified data

types. However, in a real word scenario, it is rare that HL7v2 (and HL7v3) messages

match the HL7 defined standard exactly. There are always some differences between a

particular message type and the industry standard. The same is true about HL7 RIM

based messages and document templates.

Prerequisites

Mirth Connect: All source code samples in this book are based on Mirth Connect scripts.

Make sure that Mirth Connect is installed and properly configured on your computer. It

is also assumed that you have basic understandings of features and techniques that

Mirth Connect uses.

HL7v2: Data source for the CCD will be based on incoming HL7v2 messages therefore a

working knowledge of the HL7 v2.x message structure and messaging protocols is

required.

U


HL7v3: Readers are assumed to know HL7v3 concepts and the Reference Information

Model (RIM), as well as HL7v3 data types. Additionally, readers should have an

understanding of vocabularies and terminologies such as SNOMED CT, LOINC, ICD, etc.

Scenario Overview

To give you a sense of how CCD Builder Server may work in a real life scenario, I would

like to quote several narratives of relevant interactions from the HL7v3 Normative Edition

2014.

If you are not familiar with this concept, the storyboard in HL7 terms is “a narrative of

relevant events defined using interaction diagrams or use cases. The storyboard provides

one set of interactions that the modeling committee expects will typically occur in the

domain.” (HL7NE)

To begin with: “Mr. Adam Everyman's physician, Dr. Patricia Primary, called the Good

Health Hospital to schedule an inpatient visit for Mr. Everyman for lung surgery. The clerk

verified that Mr. Everyman was not already registered as a patient in the GHH Patient

Registry and created a new patient record for him then scheduled the admission for two

weeks from that day.” (HL7NE > Patient Registry Record Added > PRPA_ST201301UV01)

Later on, Mr. Adam Everyman “presents at Good Health Hospital Outpatient Clinic and is

seen by Dr. Bill Beaker. Adam reports extreme thirst, fatigue, and recent unexplained

weight loss. He also reports having a family history of diabetes. Dr. Bill Beaker wants to

rule out diabetes mellitus by performing a GTT2HR. Upon the release of the results for the

complete GTT2HR test, the laboratory system reports all the results in a single message.”

(HL7NE > Complex Laboratory Result > POLB_ST221000UV01)

Once laboratory results are available, Dr. Bill Beaker observes them as a single document

and submits them to the Good Health Hospital for use during the scheduled inpatient

visit for Mr. Everyman.

(Patient and doctors names in storyboards are changed to match one another.)

As you can see, several parties, also called Application Roles, are involved in this process.

Application role is “an abstraction that expresses a portion of the messaging behavior of

an information system.” (HL7NE)

Thus, we may identify the following application roles that will be represented as system

components:


Message Originator – creates messages and publishes (sends) them to a receiver

(played by Patient Registry or Document Originator in our case).

Patient Registry – represents the Patient Demographics Management System.

Document Originator – creates a CCD document.

The next step is to depict interactions between these three application roles. An

interaction is “a single, one-way information flow that supports a communication

requirement expressed in a scenario.” (HL7NE)

Interaction model

The Interaction Model for storyboards defined above shows interactions between

application roles and is described using the sequence diagram (Figure 4-1).

FIGURE 4-1 Interaction diagram

As a base for the model’s interactions I have chosen to use HL7v2 transactions, though

the same can be done using relevant HL7v3 transactions. Thus, the Patient Registry

Record Added (PRPA_IN201301UV01) may be used instead of ADT_A28, along with the

Result Complete with Fulfillment (POLB_IN224200UV01) instead of ORU_R01. The reason

why HL7v3 messages are not used is because they are already in a format that is very

Message Originator

Patient RegistryDocument Originator

ADT_A28

ACK

ORU_R01

ACK

query

response


close to the final CCD document. This may over simplify this project and hide important

Mirth Connect details.

The interaction model has been intentionally complicated by adding an interim step to

store patient demographics instead of sending it directly to the Document Originator. So

let us quickly go through this sequence diagram to see how it works.

1. The Message Originator does a preliminary step by sending an ADT_A28 (Add Person

or Patient Information) message to a temporary storage which plays the role of the

database that holds patient-related information. Jumping ahead, I know that we will

not be using any databases though you are free to try. The Patient Registry, in turn,

may acknowledge the message.

2. The Message Originator sends an ORU_R01 (Unsolicited Observation Message)

message to the Document Originator. The latter may acknowledge this message and

then starts transforming and compiling the CCD document from the data it has

received. At some point, the Document Originator may require patient demographic

data if it was not fully provided in the ORU_R01 message. In such a case, the

Document Originator makes an (internal) request to the Patient Registry and uses the

data that the Patient Registry returns.

Design Considerations

There are many ways to accomplish the same task in Mirth Connect. In addition, there

are many ways to build a valid CDA/CCD document. However, the main idea of this book

is to explore Mirth Connect features, NOT to implement the service in a correct way

using standard de-facto libraries such as Model Driven Health Tools (MDHT). The actual

implementation of a real system most likely is different from this one.

The diagram in Figure 4-2 illustrates the game plan for next parts of the book and

mimics the scenario of sending the HL7v2 messages to the CCD Builder.

The implementation plan is based on followings channels:

Sender – a channel that plays a role of the Message Originator and serves as an

interface to handle and place an original ADT or ORU messages into the pipe using

the MLLP Message Transport protocol.

CCD Builder – a channel that does all heavy lifting. Later we will see that this

channel builds separate section-level templates and then compiles them into a single

CCD document. This channel plays the role of the Document Originator.


Global Map – the Global Map, in Mirth Connect terms, represents the Patient

Demographics Management System. Its main duty is to temporary store patient

demographic data.

FIGURE 4-2 CCD Builder Server channels implementation plan

Throughout this implementation we will explore some major connectors: Channel

Reader, TCP/IP Listener and Sender and File Writer.

We will use all techniques explained earlier in this book which includes, but is not limited

to: filters, transformers, code templates, maps, global and channel scripts.

At this point it is assumed that you are comfortable with the Mirth Connect

Administrator.

Recommended tools and packages

To make the development easier and less tedious, here is a list of recommended tools

and packages. You are free to use any other tools that suit you better.

HL7v2 viewer such as Messaging Workbench or HL7Spy by Inner Harbour Software;

HL7v3 viewer such as Altova XMLSpy by Altova GmbH;

And last but not least, use the XML schemas and other related files from the archive

provided with this book.

Summary

This section identified players and outlined the game plan. To do this we went through

the storyboards as they are defined by HL7v3 Normative Edition, identified application

Transform

Sender

MLLP

Transform

CCD Builder

HL7v2 (ADT_A28, ORU_R01)

Global Map

Reader MLLP

File Writer

CCD

ACK / NACK

ACK / NACK

File Writer


roles and interactions between them. This helped us depict the interaction model and

translate it to the Mirth Connect channels implementation plan.

In the next part of the book, we will implement these channels in Mirth Connect.

This is a preview edition of the book.

The full version with all related files is available to download at

http://ccdonmirth.shamilpublishing.com

http://ccdonmirth.shamilpublishing.com/

Book Resources

Book Resources Other titles you may be interested in:

Unofficial Mirth Connect v3.x Developer's

Guide

This book introduces readers to version 3.x of Mirth

Connect to the point that they are confident enough

to start building their own healthcare data exchange

interfaces.

By implementing an imaginary Eligibility Query

Service, this book covers some of the topics on XML

schema and Schematron validation, XSL

Transformation, database connection pool creation,

acknowledgements implementation, Mirth Connect

extensions implementation and sending objects via

the ActiveMQ Message Broker.

The book is available to download at –

http://mirthconnect.shamilpublishing.com

Unofficial Developer's Guide to HL7v3 Basics

This book introduces readers to HL7 version 3 to the

point that they are confident enough to start building

their own healthcare data exchange interfaces. The

book provides clear and easy to use, step-by-step

guidance for learning the standard, with numerous

examples covering many topics.

The book is available to download at –

http://hl7basics.shamilpublishing.com

http://mirthconnect.shamilpublishing.com/

http://hl7basics.shamilpublishing.com/

APPENDICES

Appendices

A: CCD Mirth Templates

B: Code Templates

C: HL7v2 Test Messages

D: XSLT files

E: Archive Content

These are files provided as supplementary materials required for parts II and III.

Folder Files Comment

..\Channels\ CCD 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\ datatypes-base.xsd

datatypes-rX-cs.xsd

datatypes.xsd

infrastructureRoot.xsd

NarrativeBlock.xsd

voc.xsd

HL7 core XML schema files required

to validate CCD document instances

..\Models\Schemas\ CCD-Body.xsd

CCD-Header.xsd

POCD_MT000041SN.xsd

POCD_MT000042SN.xsd

Localized, non-normative XML

schemas for CCD header and CCD

body parts.

..\Models\ExcelView\ POCD_MT000041SN.xls

POCD_MT000042SN.xls

Document element descriptions in

MS Excel format

..\Models\HTMLView\ POCD_MT000041SN.htm

POCD_MT000042SN.htm

Document element descriptions in

HTML format

..\Models\MWBModels\ Add Person or Patient Information.mwb

Unsolicited Observation Message.mwb

MsgStructure.txt

Messaging Workbench (MWB)

models to validate ADT and ORU

message samples.

..\Models\PictureView\ POCD_RM000041SN-Header.png

POCD_RM000042SN-Body.png

CCD header and body R-MIM

representation

..\Models\VisioModels\ POCD_RM000041SN-Header.vsd

POCD_RM000041SN-Header.xml

POCD_RM000042SN-Body.vsd

POCD_RM000042SN-Body.xml

CCD header and body R-MIM models

in Visio format

..\SampleMessages\CCD\ CCD_Allergies_Mirth_Template.xml

CCD_Body_Mirth_Template.xml

CCD_Header_Mirth_Template.xml

Parts of CCD document to serve as

outbound Mirth Connect templates

for the CCD Builder channel’s

43 APPENDICES

CCD_Header_Template_annotated.xml

CCD_Medications_Mirth_Template.xml

CCD_Problems_Mirth_Template.xml

CCD_Results_Mirth_Template.xml

destinations

\SampleMessages\HL7v2 ADT_A28.hl7

ORU_R01.hl7

Samples of HL7v2.6 messages (uses

v2.7 datatypes)

..\XSLT\ Allergies_Entry.xslt

Medications_Entry.xslt

NoResults_Entry.xslt

Problems_Entry.xslt

Results_Entry.xslt

XSL Transformation scripts required

for CCD Builder channel’s

destinations