Unofficial Developer's Guide To Ccd On Mirth Connect

Transcript

Shamil Nizamov Unofficial Developer’s Guide to CDA/CCD on Mirth Connect* * - Preview Edition Copyright Page Copyright © 2014-2015 by Shamil Nizamov Cover image copyright © 2013 by Shamil Nizamov All rights reserved. No part of the contents of this book may be reproduced or transmitted in any form or by any means without the written permission of the author. Mirth Connect is a trademark of Mirth Corporation. HL7, CDA, CCD and Health Level Seven are registered trademarks of Health Level Seven International. All other marks are property of their respective owners. Any rights not expressly granted herein are reserved. The companies, organizations, products, domain names, email addresses, logos, people, places, and/or data mentioned herein in examples are fictitious. No association with any real company, organization, product, domain name, email address, logo, person, place, or data is intended or should be inferred. This book expresses the author’s views and opinions. The information contained in this book is provided without any express, statutory, or implied warranties. The author, Mirth Corporation, Health Level Seven International, resellers and distributors will NOT be held liable for any damages caused or alleged to be caused either directly or indirectly by this book. This is a preview edition of the book. The full version is available only at http://ccdonmirth.shamilpublishing.com Introduction 2 Contents PART 1 GETTING STARTED Chapter 1 Mirth Connect Basics................................................................................................ 13 Installation ............................................................................................................... 13 Mirth Connect Administrator .................................................................................... 14 Channels .................................................................................................................. 15 Connectors............................................................................................................... 16 Filters ...................................................................................................................... 17 Transformers............................................................................................................ 17 Scripts...................................................................................................................... 18 Chapter 2 What is a CCD?......................................................................................................... 20 CCD Development Approach ..................................................................................... 20 Templates ................................................................................................................ 22 Summary ................................................................................................................. 24 Chapter 3 System Integration Requirements ............................................................................ 26 Abstraction Layer ..................................................................................................... 26 System Integration Requirements.............................................................................. 29 Testing ..................................................................................................................... 31 Summary ................................................................................................................. 33 Chapter 4 Transforming Data with Mirth Connect ..................................................................... 35 Scenario Overview .................................................................................................... 36 Design Considerations............................................................................................... 38 Summary ................................................................................................................. 40 PART II CCD BUILDER SERVER IMPLEMENTATION Chapter 5 Query Sender Channel.............................................................................................. 42 Summary Tab ........................................................................................................... 42 Source Connector ..................................................................................................... 43 Destinations Connector............................................................................................. 45 Summary ................................................................................................................. 49 Chapter 6 3 CCD Builder Channel – Header ................................................................................. 50 Introduction Summary Tab ........................................................................................................... 51 Source Connector ..................................................................................................... 52 Destinations Connector............................................................................................. 54 Code Templates........................................................................................................ 63 Global Scripts .......................................................................................................... 65 Channel Implementation Verification ........................................................................ 65 Summary ................................................................................................................. 66 Chapter 7 CCD Builder Channel – Allergies ............................................................................... 68 Destinations Connector............................................................................................. 69 Code Templates........................................................................................................ 76 Global Scripts ........................................................................................................... 78 Channel Implementation Verification......................................................................... 79 Summary ................................................................................................................. 80 Chapter 8 CCD Builder Channel – Medications ......................................................................... 81 Destinations Connector............................................................................................. 83 Global Scripts ........................................................................................................... 89 Channel Implementation Verification......................................................................... 90 Summary ................................................................................................................. 90 Chapter 9 CCD Builder Channel – Problems .............................................................................. 91 Destinations Connector............................................................................................. 92 Global Scripts ........................................................................................................... 97 Channel Implementation Verification ........................................................................ 98 Summary ................................................................................................................. 98 Chapter 10 CCD Builder Channel - Results................................................................................. 100 Destinations Connector........................................................................................... 101 Global Scripts ......................................................................................................... 106 Channel Implementation Verification....................................................................... 107 Summary ............................................................................................................... 107 PART III CCD VALIDATION Chapter 11 CCD Validation Tools .............................................................................................. 110 XML Schema Validation........................................................................................... 110 Introduction 4 Schematron Validation............................................................................................ 111 MIF Validation ........................................................................................................ 113 Conformance Validation.......................................................................................... 113 Summary ............................................................................................................... 114 Chapter 12 CCD Validation Automation .................................................................................... 115 XML Schema Validation........................................................................................... 116 Schematron Validation............................................................................................ 119 Summary ............................................................................................................... 124 Book Resources.............................................................................................................................. 125 APPENDICES A: CCD Mirth Templates .......................................................................................... 127 B: Code Templates .................................................................................................. 130 C: HL7v2 Test Messages .......................................................................................... 133 D: XSLT files ............................................................................................................ 134 E: Archive Content .................................................................................................. 140 5 Introduction Introduction Introduction As Mirth Corporation says on their web-site, “Mirth Connect is the Swiss Army knife of healthcare integration engines, specifically designed for HL7 message integration. It provides the necessary tools for developing, testing, deploying, and monitoring interfaces. And because it’s open source, you get all of the advantages of a large community of users with commercial quality support.” In addition, “The 2014 HL7 Interface Technology Survey Results” show that Mirth Connect is one of the fastest growing healthcare messaging platforms due to its open-source paradigm, and robust functionality for HL7 messaging and X12 documents. Mirth Connect also speeds up the development of interfaces for data exchange across different formats and diverse healthcare systems environment. This book describes version 3.x of Mirth Connect to the point that reader are confident enough to start building their own healthcare data exchange interfaces and transforming HL7 messages to CDA/CCD documents. As you read this book, you will be implementing a fictitious CCD Builder Server. Each connection point (channel and destination) is explained in a separate chapter, which in turn provides step-by-step instructions on how to create and code data transformation rules. This book is written using Mirth Connect version 3.1.1.7461. Consequently, other releases may include new features, and features used in this book may change or disappear. You may also notice differences between screen shots provided in the book and those you see when using Mirth Connect. Who is this book for? I wrote this book primarily for application developers and system integrators who have found the online Mirth Connect documentation lacking and needed a guidebook that covers topics in a more detailed and organized way. A book of this size cannot cover every feature in Mirth Connect v3.x; consequently, I assume you already have some familiarity with its main components, functions and use. Introduction 6 Assumption This book assumes that you are dealing with applications that use message-oriented middleware products and expects that you have at least a minimal understanding of Web service technologies including, but not limited to, XML, XML Schemas, XPath and XSL Transformation. Before you start reading this book, you should have a basic knowledge of Mirth Connect development paradigm, JavaScript, Java and E4X objects; and are familiar with operating system environment variable settings. You should also have basic knowledge of HL7, the standard that is being used to exchange healthcare data, both version 2 and version 3. I assume you also familiar with Clinical Document Architecture (CDA) and, hopefully, Continuity of Care Document (CCD). Who should not read this book? As mentioned earlier, the purpose of this book is to provide the reader with a high-level overview of the capabilities and features in Mirth Connect v3.x. This book is not intended to be a step-by-step comprehensive guide or substitute of any kind for training and certification programs provided by Mirth Corporation. This book is also not a tutorial on a specific messaging or middleware technology such Model Driven Health Tools (MDHT) or Mirth CDAPI. All examples included in this book are for illustrative purposes only. If you are interested in learning more about a specific technology or product, please refer to one of the many on-line resources, or trainings and certifications provided by Mirth Corporation or its affiliates. This book does not cover any specific installation, configuration, deployment or monitoring activities for system administrators. Errata and Book Support I have made every effort to ensure the accuracy of this book and its companion content. If you find an error, please report through email - [email protected] 7 Introduction Warning and Disclaimer The purpose of this book is to educate and entertain. Every effort has been made to make this book as complete and accurate as possible, but no warranty or fitness is implied. The information is provided on an “as is” basis. The author shall have neither liability nor responsibility to any person or entity for any loss or damage caused, or alleged to be caused, directly or indirectly by the information contained in this book or from the use of software mentioned in this book. The information, methods and techniques described by the author are based on his own experience. They may not work for you and no recommendation is made to follow the same course of action. No representation is made that following the advice in this book will work in your case. The author is not an employee or representative of Mirth Corporation and never has been, and author’s views and opinions are not necessarily those of Mirth Corporation. This book is not based on trainings or certifications provided by Mirth Corporation or its affiliates. This book contains links to third-party websites that are not under the control of the author, and the author is not responsible for the content of any linked site. If you access a third-party website mentioned in this book, you do so at your own risk. The author provides these links only as a convenience, and the inclusion of the link does not imply that the author endorses or accepts any responsibility for the content of those third party sites. Furthermore, this book contains information on the subject only up to the publication date. Acknowledgements Like most books, this guide has been a long time in the making. I would like to acknowledge everyone who has assisted in this project. I could not have done this without you. I’d like to thank Philip Helger for his contribution to the development of the open-source Schematron validator. My biggest thanks go to Wayne Zafft, who was incredibly gracious with his time and effort in reviewing the final version of the book. Introduction 8 Roadmap This book is divided into three parts: Part I provides an introduction to Mirth Connect and a high-level overview of the CCD document paradigm.  Chapter 1, Mirth Connect Basics Introduces Mirth Connect at a high level, provides an overview of the channel architecture implemented in Mirth Connect, walks the reader through the creation and configuration of a simple channel.  Chapter 2, What is CCD Provides an overview of the Continuity of Care Document or CCD, the XML-based markup standard intended to specify the encoding, structure, and semantics of a patient summary clinical document for exchange.  Chapter 3, Systems Integration Requirements Provides a brief overview of system design and systems integration requirements to demonstrate the complexity of a typical HL7 based integration project.  Chapter 4, Transforming Data within Mirth Connect Introduces a typical scenario as it is defined in the HL7v3 Normative Edition, presents the implementation plan for the rest of the book and walks through the required components. Part II focuses on the implementation of an imaginary but complete CCD document generating server.  Chapter 5, Query Sender Channel Walks the reader through the implementation of the first channel in a chain that serves as an interface to send HL7v2 messages and handle acknowledgements.  Chapter 6, CCD Builder Channel - Header Explains the implementation of a channel that plays the major role in this project. The chapter shows how to establish a MLLP connection to other channels, how to filter messages based on some criteria and transform part of the inbound messages to form the CCD header. 9 Introduction  Chapter 7, CCD Builder Channel - Allergies Expands functionality of the CCD Builder channel by adding a required segment to the CCD document. Shows a simple transformation pattern using Mirth mapping and XSL transformation.  Chapter 8, CCD Builder Channel - Medications Continues implementation of required section level templates. Shows iterations and mapping of multiple segments.  Chapter 9, CCD Builder Channel - Problems Continues implementation of required section level templates. Shows iterations and mapping of multiple segments.  Chapter 10, CCD Builder Channel - Results Shows how to iterate through segment groups each of which may contain repeating segments. This chapter concludes implementation of the CCD document. Part III is dedicated to verification of the CCD document implementation.  Chapter 11, CCD Validation Tools Introduces a message verification process using different tools and methods such as XML schema validation, MIF validation, Schematron validation and conformance review. Lists some open source tools and toolkits that readers may use to build and test HL7v3 and CDA interfaces.  Chapter 12, CCD Validation Automation Walks the reader through the implementation of the XML Schema and Schematron validator scripts using open-source libraries. Appendices include:  Archive Content Lists folders and files included in the archive provided with the book.  CCD Mirth Templates Shows all outbound templates used by the CCD Builder channel’s destinations.  Code Templates Shows all mapping functions defined as Code Templates functions.  XSL transformation files Introduction 10 Shows the XSLT file content used to build CCD segment templates.  HL7v2 samples Lists ADT_A28 and ORU_R01 message samples. 11 Introduction PART I – GETTING STARTED Getting Started CHAPTER 1 Mirth Connect Basics CHAPTER 2 What is CCD? CHAPTER 3 System Integration Requirements CHAPTER 4 Transforming Data with Mirth Connect PART I – GETTING STARTED 12 CHAPTER 1 Mirth Connect Basics Mirth Connect Basics chapter outlines the Mirth Connect installation procedure and basic concepts. All This examples in this book are based on the Windows version of Mirth Connect v3.1, available for downloading at http://www.mirthcorp.com/community/downloads Make sure your computer meets minimum system requirements before you start:  Oracle JRE version 1.6 or higher;  1 GB of RAM is recommended;  A web browser. Installation You can install Mirth Connect in either of two ways based on which package you downloaded or which package is available on the website. In one case, the package is an archive of all files and classes you need to run Mirth Connect on your computer. You simply unzip and copy the package to an appropriate folder, for example to C:\Program Files\Mirth Connect\. In the other case, there is a GUI based wizard that you start to go through the steps in the installation. The installation process itself is quite straight forward. Both methods install Mirth Connect Server, Mirth Connect Server Manager, Mirth Connect Administrator and Mirth Connect Command Line Interface. During the installation you have to decide which port is used by the Mirth Connect Server. The default is 8080 for unsecure communication and 8443 for the SSL connection. You can change the ports later using the Mirth Connect Server Manager, if necessary. To verify the installation:  Launch the Mirth Connect Server either through the Mirth Connect Server Manager or the Mirth Connect Command Line;  Open the web browser and type localhost:8080 in the address bar;  Click the Access Secure Site button in Web Dashboard Sign In launch page;  Type admin for the user name and repeat admin as the password, click Sign in. If you see the Dashboard statistics page with, most likely, no channels available, you have successfully installed Mirth Connect and are ready to continue. If not, refer to Mirth Connect 3.1 User Guide written by “the same Mirth technical experts who developed the software” available at - http://info.mirth.com/Connect_Documentation_Download.html 13 PART I – GETTING STARTED Configuration The Mirth Connect Server Manager can be used as a single point to launch Mirth Connect Service, configure ports, allocate memories, and to establish database connections. However, a fully-fledged configuration description is beyond the scope of this book. As a recommended option, add a path to the \custom-lib folder in the operating system’s CLASSPATH environment variable. This is the folder where you put Java classes, libraries and other required files that Mirth should be working with. If any application on your computer or firewall uses ports 8080 or 8443 you can either change Mirth’s ports by using Mirth Connect Server Manager or by manually modifying the configuration file located in \conf\mirth.properties. Don’t forget to restart the Mirth Connect Server or Service to activate your changes. Mirth Connect Administrator The Mirth Connect Administrator is a Java application that, by default, is not explicitly installed on a local computer in a distributed environment. It is downloaded from the Mirth Connect Server. This ensures the Mirth Connect Administrator matches the version of the Mirth Connect Server being used. To download the Mirth Connect Administrator:  Start Mirth Connect Server if it is not already running as a service;  Open the web browser;  Type localhost:8080 in the address bar;  Click Launch Mirth Connect Administrator in the Mirth Connect Administrator launch page;  Click Ok to open webstart.jnlp;  Type admin for the user name and repeat admin as the password in the Mirth Connect Login pop-up window, then click Login. If everything is done correctly, each time you login, you will see the Dashboard as the initial screen. The Dashboard displays two information panels:  Channels status and statistics – shows the number of messages Received, Filtered, Queued, Sent, and Errored. The left sidebar of the Dashboard has tasks panel, with menu options related to your current activity. For example, when you are developing a channel, menu options such as Refresh, Send Messages, and Remove All Messages PART I – GETTING STARTED 14 are displayed. These menu items can be also accessed by right clicking on a channel name in the Channel List.  Logs – Server Log, Connection Log and Global Maps. The Server Log is used to debug channel development. Double-clicking on a Server Log entry brings a pop-up window where you can view and copy the entire log entry content. The Server Log is stored by Mirth Connect Server in the database; closing and opening the Mirth Connect Administrator brings back all entries not explicitly purged. To clear the Server Log click Clear Displayed Log under the Server Log or Connection Log area. Familiarize yourself with other navigation items and tabs since this is the main tool used to develop and configure channels throughout this book. Channels The Channel is an essential part of Mirth Connect and can be seen as one-to-many abstract unidirectional pipes that decouple components from each other to transfer healthcare data between two or more applications. The channel architecture implemented in Mirth Connect can divide a large message processing task into a sequence of smaller independent steps. This affords developers the flexibility for dependency, maintenance and/or performance. Some of the processing tasks can even be external to Mirth Connect and developed independently. FIGURE 1-1 Mirth Connect abstract channel architecture In general, each channel consists of inbound and outbound Connectors, Filters and Transformers. The connector that receives inbound messages from the Sending Application is called the Source. Similarly, the connector that sends outbound messages 15 PART I – GETTING STARTED is called the Destination. From the Source connector, data is passed through the channel, where filters and transformers perform operations on the data, for example, routing a message to one or another Destinations connector and transforming the data representation. Deciding each channel’s tasks is when wearing an analyst's hat comes into play. Before you create a new channel, you need to elicit the following requirements:  Type of Application the channel reads data from (Source connector type);  Type of Application the channel sends data to (Destination connector type);  Type and format of the inbound message;  Type and format of the outbound message(s);  Mapping table(s) between inbound and outbound messages (Transformation). Connectors In terms of Enterprise Integration, the connector is a Message Endpoint that specifies a particular way or, more accurately, a particular protocol Mirth Connect should use to communicate with an external application or another Mirth Connect channel. Mirth Connect supports sending and receiving messages over a variety of connectors listed here in no particular order:  TCP/MLLP;  Database (MySQL, PostgreSQL, Oracle, Microsoft SQL Server, ODBC);  File (local file system and network shares);  PDF and RTF documents;  JMS;  HTTP (note that HTTPS is not supported in the free version);  SMTP;  SOAP (over HTTP). The connector that receives the data is called a Reader, for example the MLLP Reader. The connector that sends the data is called a Writer, the Database Writer is an example. Connector types are configured under Source and Destinations tabs of the channel. Obviously, some settings are common across all connectors while others are unique to a specific connector type. You can develop your own connector if you need one that is not shipped with the Mirth Connect installation package, e.g., HTTPS connector. However, this is out of scope of this book. PART I – GETTING STARTED 16 Filters In a real world scenario, when numerous applications and channels are connected, a channel may receive messages from several sources and may process these messages differently, based on the message type or other criteria. There are two paradigms for addressing this requirement, a Router and a Filter:  Router connects to multiple outbound channels. The key benefit of the Router is that the decision criteria for the destination(s) of a message are maintained in a single location.  Filter, this is what Mirth Connect uses, is built into a message processing mechanism and determines whether or not the message should be processed. The Filter inspects message properties (segments or elements) without removing the message from the message queue. If the message cannot be consumed by this particular pipe, it is returned to the queue unchanged for another pipe to filter or process. Filters can be as simple as comparing specific elements against a hard coded value or as complex as a scripting language routine. Filters can also be omitted allowing all messages to pass through. Some routing capabilities have been introduced in Mirth Connect v3.1 by using a "destinationSet". If a destination is removed from the destination set, this destination will not receive the message. If a single channel needs to process more than one type of message, you can create any number of separate pipes – Destinations - and specify none, one or more filters for each pipe. Transformers More often than not, messages are sent between legacy systems, custom applications and third-party solutions, each of which is built around a proprietary data model. Even systems that claim to support a single standard may place specific requirements on data format and content. If we could bring all legacy systems to a single format when a new business requirement is proposed, we would avoid conversion issues. Unfortunately, for most legacy systems, data format, content or data sequence changes are difficult and risky, and simply not feasible. How do we communicate data using different formats then? Mirth Connect does this in a message Transformer that translates one data format into another. As a result, a destination application can receive messages it understands and which can be processed and stored in the application’s internal data format. 17 PART I – GETTING STARTED Mirth Connect allows message transformation to occur at different levels and to chain message transformers to achieve a required result. Supported transformers are:  Message Builder maps segments of the inbound message to segments in the outbound message.  Mapper maps segments of the inbound message to internal Mirth Connect variables. These variables may be used later.  External Script, as the name suggests, employs external JavaScript routines to transform or map the data.  XSLT Step utilizes the XSL transformation.  JavaScript, along with External Script, is where flexibility comes into play. Here any type of (Rhino) Java Script and Java code can be used. Scripts Channels also support unique features called Scripts to enhance message processing logic. Scripts apply to a channel itself and all messages that are passing through. These scripts are:  Deploy script is executed each time Mirth Connect Server starts or a channel is redeployed. This is the best place to initialize variables or create class objects.  Attachment script deals with a message in a native format and allows extracting part of the message to store as an attachment or to irrevocably modify a message.  Preprocessor script also allows handling each message in a native format before Mirth Connect starts translating it into the internal format, which is XML.  Filter & Transformer scripts are the main places for handling the inbound and outbound messages.  Response script, as the name suggests, handles the response sent by a destination.  Postprocessor script is executed after the message has been successfully sent.  Undeploy script is launched each time Mirth Connect Server stops. This is the place to, for example, release memory that was allocated for the classes used by the channel. Mirth Connect uses JavaScript as a scripting language with the ability to extend it by calls of external Java classes. The latter may be one of those included to the Mirth installation package or user defined. Besides the channel level, Mirth Connect employs Global Scripts that play the same role as channel scripts and help in separating the business logic. They have the same Deploy, PART I – GETTING STARTED 18 Undeploy, Preprocessor and Postprocessor scripts; the only difference is that they apply to all channels. This concludes Mirth Connect introduction section. To find out more, you may refer to numerous web resources, including trainings and books provided by Mirth Corporation. You may find it helpful to read “Unofficial Mirth Connect v3.x Developer’s Guide“ eBook which covers Mirth Connect basics and advanced topics in greater details. This eBook is available at - http://mirthconnect.shamilpublishing.com 19 PART I – GETTING STARTED CHAPTER 2 What is CCD? What is CCD? Continuity of Care Document or CCD, is an XML-based markup standard intended Theto specify the encoding, structure, and semantics of a patient summary clinical document for exchange. (Wiki) From the standard development perspective “the Continuity of Care Document is a joint effort of HL7 International and ASTM. CCD fosters interoperability of clinical data by allowing physicians to send electronic medical information to other providers without loss of meaning and enabling improvement of patient care. CCD is an implementation guide for sharing Continuity of Care Record (CCR) patient summary data using the HL7 Version 3 Clinical Document Architecture (CDA), Release 2.” (HL7 CCD page) Basically, what has been done is the HL7 Clinical Document Architecture (CDA) is taken as a document markup standard and constrained by the ASTM Continuity of Care Record (or CCR also referred to as ASTM E2369-05) data sets into specific headers and templates. The resulting semantic equivalent was called the Continuity of Care Document. In the U.S., this specification has been refined further by U.S. federal incentives known as Meaningful Use stages 1 and 2. Prerequisites In case of any discrepancies found in this book, implementers must follow the conformance requirements of CDA and CCD. You should have following specifications available:  HL7v3 Normative Edition - HL7 Clinical Document Architecture, Release 2.0;  HL7 Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD). CCD Development Approach Besides CCD standard specifications, the CCD distribution package includes CCD and core HL7 XML schemas, CCD XSLT stylesheets and non-normative examples of Schematron rules required to validate documents. From a standard developer point of view, the approach used in this book to develops core artifacts for the document-level templates (which is CCD in our case) is by taking a subset of classes defined in the CDA R2 R-MIM model and constraining them to reflect the ASTM CCR specification. PART I – GETTING STARTED 20 In general these steps are:  CDA document derives its classes and machine-processable meaning from the HL7 Reference Information Model (RIM) in conjunction with HL7v3 Data Types.  CCD document derives its classes from CDA Refined Message Information Models (R-MIM).  CCD R-MIM classes are constrained by the ASTM CCR data requirements.  As CCD R-MIM is finalized, the XML schema(s), possibly with other artifacts such as Model Interchange Format (MIF) files and Hierarchical Message Descriptor (HMD) views, are generated.  As the last step, CCD XML schema is manually updated to include extensions required to map ASTM CCR components for which there is no suitable mapping in CDA R2. Schematically this may be represented as Figure 2 -1. FIGURE 2-1 CCD development approach As you can see, the CCD R-MIM, derived from the CDA R-MIM, follows the same structure, i.e., it contains a required header to identify the document and participants, and a body to represent a generic structure of a clinical content. 21 PART I – GETTING STARTED This method for creating CCD XML schema is based on HL7v3 refinement and localization mechanism and can be applied to any RIM based artifact (messages or documents). Templates The next level of constraint is based on logical groupings or patterns defined at the sections and entry levels to provide specific clinical context. Thus, as the HL7 NE states: “The CDA specification is richly expressive and flexible. Document -level, section-level and entry-level templates can be used to constrain the generic CDA specification.” Such patterns, called templates, can “comply with a detailed implementation guide that details the manner in which structured elements are to be represented and their intended interpretation to a level sufficient to ensure a degree of clinical safety that is appropriate to the use case that it is designed to address.” (HL7v3 NE) This approach brings extended flexibility and allows the creation of a wide variety of templates which still follow the HL7 standard and CDA defined structure. If you think this is not enough, CDA allows including both structured and unstructured information at the CDA Level. The CDA specification distinguishes three incremental levels of conformance for semantical interoperability. CDA Level 1: The simplest form of CDA, also known as CDA Level 1, includes the header and unstructured block where the “NonXMLBody class represents a document body that is in some format other than XML”. (HL7v3 NE) The CDA Level 1 is not allowed as defined in the Meaningful Use initiative. CDA Level 2: Next form is “the CDA specification with section-level templates applied”. (HL7v3 NE) Section level templates are identified by an associated templateID and represented in XML. CDA Level 3: At this level “the CDA specification with entry-level (and optionally sectionlevel) templates applied.” (HL7v3 NE) At this level some section templates contain discrete data elements called CDA entries. Thus, built on templates, the CDA R2 implementation guide defines nine document-level templates, where CCD is only one of them (others include Consultation Note, Diagnostic Imaging Report, Procedure Note, Discharge Summary, etc.). Potentially they may be represented as separate XML schemas. PART I – GETTING STARTED 22 Section-level templates CDA R2 defines more than 65 section-level templates. Among these are Allergies, Encounters, Medications, Problem List, etc. This is schematically 1 shown in Figure 2-2. For simplicity some section-level templates are not explicitly shown in the figure but represented with … titles. CDA Sections CCD sections MU2 ... ... Allergies Medical Equipment Advance Directives ... Medications ... ... Discharge Diet Problems Payers Results Consultation Notes sections MU2 Family History ... ... Immunizations Social History Physical Exam Present Illness Past Illness Reason for Referral Encounters Vital Signs Plan of Care Reason for Visit General Status ... ... FIGURE 2-2 CDA section-level templates Document-level templates can exclusively use some section-level templates and share others. For each document in US Realm, some subsets of section-level templates are mandatory according to Meaningful Use Stage 2 (MU2). Entry-level templates CDA does not stop at the section level but additionally defines up to one hundred entrylevels templates. Examples include, Age, Observation, Encounter Diagnosis, Immunization Activity, etc. 1 This diagram is for illustrative purpose only. Any discrepancies depicted in the diagram and in the base specifications are inadvertent and in all cases implementers must follow the conformance requirements of CCD, CDA and MU2. 23 PART I – GETTING STARTED As the name suggests, entry-level templates apply to one of the clinical act statements: Observation, Substance Administration, Supply, Procedure and so on. All entry-level templates are meant to be machine-processable parts of the document. Some entry-level templates are used exclusively in one type of CDA document templates. For example, Discharge Diet template is used only in Discharge Summary. Reason for Referral entry-level template is required only in Referral Summary (HITSP 2 C48) document template, etc. Other entry-level templates such as Allergies or Diagnostic Results are shared among all CDA document level templates. For illustrative purpose only, an example of the Body Temperature entry-level template is given in the code snippet below (see Source 2-1). SOURCE 2-1 BodyTemperature entry-level template US Realm related CCD Implementation Guide may recommend additional sections for conveying healthcare data that conforms to MU2 requirements. MU2 also applies additional constrains on all template levels. Summary This chapter has barely scratched the surface, providing a general overview of one of the CDA family templates called Continuity of Care Document (CCD) which is semantically equivalent of ASTM Continuity of Care Record (CCR). Rather than explaining CCD in depth, which requires a book by itself, this section gives you a basic road map for exploring and understanding CCD. If you are not familiar with HL7 and HL7v3 in particular, you may start with HL7v3 Normative Edition and move towards Clinical Document Architecture domain. I wrote another book, called “Unofficial Developer's Guide to HL7v3 Basics 3” to help you in this endeavour. 2 3 HITSP - Healthcare Information Technology Standards Panel Available to download at - http://hl7basics.shamilpublishing.com PART I – GETTING STARTED 24 Below is a non-exhaustive list of other resources to help you educate yourself on various aspects of CDA and CCD. Primary Standard is available on the HL7.org site. You need to register to get access.  CDA® Release 2; CDA and CCD Implementation Guides are also available on the HL7.org site.  HL7 Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD) 4;  HL7 Implementation Guide: S&I Framework Transitions of Care Companion Guide to Consolidated-CDA for Meaningful Use Stage 2, Release 1 – US Realm; Additionally you may find samples of section and entry level templates.  IHE CDA Section Templates wiki.ihe.net/index.php?title=Category:CDA_Section_Templates Below are listed quite a few books that I found helpful in this topic. If you are not familiar with HL7 or CDA in particular, start with Tim Benson’s book then continue with the book written by Keith Boone.  Principles of Health Interoperability HL7 and SNOMED by Tim Benson.  The CDA Book by Keith W. Boone. You may also find some technical files. These are provided in the package that is part of this book:  Non-normative MU2 constrained CCD R-MIM diagram in Visio format (for illustrative purpose only);  Hierarchical Message Descriptions (HMD) in Excel View derived from the CCD RMIM (for illustrative purpose only). 4 Referred in this book as HL7 CCD. 25 PART I – GETTING STARTED CHAPTER 3 Systems Integration Requirements System Integration Requirements chapter is a brief overview of system design and systems integration requirements This for implementing the CDA based system. If you are more or less familiar with HL7 systems implementation you are free to skip it. As you surmise, I have not started from interoperability in general, or HL7 as a standard, or HL7 Reference Information Model (RIM) in particular. Undoubtedly, HL7 interoperability is crucial to the integration of clinical health information systems. It is the cornerstone of HL7v3 and may be used as a key selling point of HL7v3. But my experience shows that focussing on interoperability adds little value for software developers. For them, HL7v3 format, which CDA and CCD are based on, is a fait accompli and the task at hand is to implement it. Abstraction Layers As a software developer you know that building an enterprise level information system requires proper layers of abstraction. N-tier architecture provides a high degree of decoupling, separating presentation, business logic and data tiers. Information technology came to this solution after much trial and error. If business needs were stable such a solution would not be required. However, today’s business, eHealth in particular, faces constant change from new regulatory requirements (e.g., EHR Meaningful Use stage 1 to 3 in the USA), market changes and improvements in operational processes. To achieve flexibility, various types of abstraction layers are possible to hide the implementation details of particular functions and integrate them based on their purpose. The Abstraction Layer shown in Figure 3-1 hides the complexity of the back-end system, letting the application request the data using well-organized meaningful calls and without having to worry about the actual data location and structure. In this diagram, data is stored in the Data Repository. The purpose of it is to show that medical data may be located in different sources: relational databases, spreadsheets, documents, flat files and “clouds” as more mobile applications emerge. Consider the notional flow of data for such a simple system: 1. The Application makes a request to the Abstraction Layer to retrieve the patient medical information; 2. The Abstraction Layer makes a request to the Data Repository; PART I – GETTING STARTED 26 3. If data is available, the Data Repository returns it to the Abstraction Layer; 4. The Abstraction Layer forms the data in the way the Application expects and sends it to the Application; 5. The Application processes the data and uses it as intended. FIGURE 3-1 Simple system architecture using an abstraction layer Even this simple scenario is missing key elements: the alternative and exception flows are not shown, leaving the Application unaware if data is unavailable for one reason or another; also, this scenario does not tell if data sources are physically distribu ted or hosted on different operating systems and/or or data storage environments (e.g., databases from different vendors). What if the Abstraction Layer cannot find the data in the Data Repository? If business logic allows there will be additional steps to request data from a remote system probably using one of the HL7 messaging standards. Figure 3-2 schematically shows an abstract system with added CCD document building capability. If you are not familiar with the HL7 and CDA standards, you may wonder why there are several streams (only four are shown but there may be more), each of which has its own message translator and content enricher. Also, what data sources are these two streams are using? We will explore this in following chapters. You may think of the Abstraction Layer as a Database Access Layer (DAL) that encapsulates all requests to data sources. It may also function as an Enterprise Service Bus (ESB) in a message-oriented processing model that supports synchronous or asynchronous communications, content-based message forwarding and filtering, transformation functionalities and mapping between different interfaces. Since DALs or ESBs are often implemented in very different ways, requiring a broad range of specific functionalities and operating characteristics, I will use the term Abstraction Layer to avoid confusion with vendor-specific implementations. 27 PART I – GETTING STARTED FIGURE 3-2 System architecture with CDA builder capability Assuming a Web Service is used to deliver a document, the notional data flow with added CCD Builder functionality may be described as: 1. The Application makes a request to the Abstraction Layer to retrieve the patient medical information. 2. The Abstraction Layer makes a request to the Data Repository. 3. If data is available, the Data Repository returns it to the Abstraction Layer. 4. The Abstraction Layer forms the data in the way the Application understands and sends it to the Application. The latter sends the data to the CCD Builder component. 5. The CCD Builder component, in turn, forms parts of the document, aggregates them into a single document, wraps the message in a SOAP envelope or other transport mechanism, and sends it to the remote system or storage. 6. The HL7v3 Receiver component gets the response, verifies that the response belongs to this destination, extracts the payload and passes it to the Abstraction Layer. 7. The remote system processes the data and uses it as intended. Besides typical alternative and exception flows related to communication, questions that left unanswered are:  If the patient medical information is not available in the Data Repository, what should the system do? PART I – GETTING STARTED 28  If the local Data Repository contains data that differs from data in the remote system, and the local data is older, what should the system do?  If the remote system asks for a set of data but CCD is not capable of conveying such data to fulfil the remote system need, what should the Application do? Such questions may significantly affect the architecture, implementation and ultimately the functionality of the system. Let’s consider other aspects that may influence the HL7 based system architecture. System Integration Requirements Different types of requirements shape a system’s behavior. Stakeholders (users, sponsors, clients, etc.), healthcare practitioners and subject matter experts (SMEs) are typically good at eliciting all levels (organizational, system, component) of functional requirements. Undoubtedly, developers will be provided with a huge list of functional system requirements, probably with a great number of use cases. Presumably, these requirements are complete, consistent, unambiguous, feasibly implemented and verifiable. As such, they provide a concrete basis for the developed system. Customers are usually not interested in seeing how functional requirements are implemented. The terms they use to describe system functionality, more often than not, apply to direct or indirect non-functional requirements (NFR), such as qualities and constraints. NFRs represent a significant delivery risk to a project since neglecting or improperly dealing with NFRs during the initial requirements elicitation process, or during the system development lifecycle, leads to inaccurate estimation of project’s scope and efforts. Errors due to omitting NFRs or to insufficient attention paid to their analysis are among the most expensive and difficult problems to correct. Among a huge list of non-functional requirements, there are some that affect healthcare systems integration. A few, for illustrative purposes, are discussed here to show the consequences of (not) implementing them. NFRs are listed in no particular order. Auditability Auditability is the ability of the system to keep the audit logs so that interactions with other systems can be inspected. Unlike other communication systems, HL7 messages often include sensitive medical information (also see Security). Meeting the legal requirements for auditability leads to a number of questions such as what data to collect, how to store it, how to prevent unauthorized access to audit records, and how to maintain data integrity. Depending on workflow, the number of messages exchanged by 29 PART I – GETTING STARTED systems can be significant and the number of transactions will grow over time. This raises the issue of predicting hardware capacity growth, particularly if the legal requirement is to keep all communicated messages for several years. Additional implementation considerations arise from backup, disaster recovery plan and retention period requirements. Performance Performance is one of the most ambiguous runtime non-functional requirements. The user expectation is typically characterized as “the system should be fast” and written as “a transaction should take less than N seconds to complete”. However neither specifies if a transaction is considered complete when a response message enters a system, or when the end-user sees the result of the initial (for example, search query) request. If it is the latter, does it consider both the system’s messaging component performance requirement and system’s user interface performance requirement? If there is another requirement to put mechanisms into place that automate some levels of conformance testing of incoming messages, does the original “… N seconds to complete” still apply during peak hours? If a transaction has timed out, does the original “… N seconds to complete” mean N seconds to successful conclude the transaction, or just N seconds before the end-user receives some kind of feedback? Decisions made here also affect scalability. Security Security in healthcare systems is paramount given the sensitive, personal information maintained and communicated and to protect from fraud and other breaches. There are many great books that cover security from different aspects and levels of granularity. If you are new to the healthcare industry, you need to know that, besides typical computer systems security requirements, national health sectors often specify their own security requirements (e.g., Health Insurance Portability and Accountability Act or HIPAA in the USA) to protect highly sensitive medical information from fraud and security breaches . Violations of such regulations can lead to lawsuits and other enforcement actions. Even if not applied directly to the CDA standard, some of the security rules that HIPAA regulates are: audit controls to review healthcare system activities, and transmission security which includes integrity controls and encryption/decryption during transmission. Other countries may apply other international and local legislation acts, which can greatly affect the way HL7 messages are structured, processed or communicated (e.g., Personal Health Information Protection Act or PHIPA, and Personal Information Protection and Electronic Documents Act aka PIPEDA in Canada). PART I – GETTING STARTED 30 Transactional Reliability Transactional reliability determines the portion of successfully completed transactions, (i.e., number of messages delivered to, processed, and returned by a remote system). Transactional reliability is measured, from a positive perspective, as service availability, for example, 99.998%. This metric, however, may affect transaction timeout settings and performance. Testing Be it through a waterfall, agile or another approach to system development, sooner or later functional and non-functional aspects of the system need to be tested. You may already use or be familiar with such widely adopted agile practices as Test-Driven Development and Behavior-Driven Development aimed at creating reliable and maintainable code. Whatever testing strategy you choose, they can probably be categorized as using business-facing and technology-facing test models (introduced by Brian Marick). On the business-facing side, functional acceptance testing verifies how the system is built, including functionality, capacity, usability, security, modifiability, availability, etc. The technology-facing tests are commonly used by developers during the development process: unit tests, component tests, and deployment tests. Integration testing Integration testing is especially crucial for a system that communicates with other systems using different protocols, or for a system consisting of loosely coupled components (units, modules). Integration testing is generally performed in these different contexts:  Test Harness – an environment that developers build to test the system. It may be part of unit testing.  User Acceptance Testing (UAT) environment which is as similar to a production environment as possible.  Production environment. Ideally, you would be provided with a replica of a system that behaves exactly like the production system and allows performance, capacity, security and other functional and non-functional requirements to be tested. However, in the real world, you will often need to develop such an environment on your own. It is therefore essential that your environment allows for the testing of unexpected situations such as network transport problems, protocol problems and external systems (logic) problems. 31 PART I – GETTING STARTED Test data Performing business-facing tests (acceptance testing) and technology-facing tests (integration testing and sometimes unit testing) is not possible without test data, which raises the issue of managing test data. The test team is often provided with a dump of data from the production environment. These data usually consist of three broad groups: test specific data, test reference data and application reference data. For technology-facing tests such as unit tests, the developer may create a smaller dataset of fake test data that covers all three groups. Other types, such as acceptance-testing, integration testing, non-functional testing need more sophisticated test data to verify desired behavior against the system’s integration requirements. Capacity testing unveils the issue of scaling up existing data to create sufficient volumes of representative data for different performance-related test cases. A key challenge for managing test data in a healthcare systems development environment is to comply with current legislations and regulations aimed at protecting the privacy of patient’s personal demographic and health information – specifically to prevent disclosing either the identity or other attributes of private individuals. This is where de-identification comes into play. De-identification of patients’ information is essential where data is disclosed for testing (and also often analytical) use. Deidentification of health data is an important topic by itself and requires separate books. Reasons for healthcare data de-identification include: developers’ laptops, hard disks or USB flash drives may be lost or stolen; a company may experience "sophisticated computer security attack" against their servers; and other breaches (recent breach reports may be found at databreachtoday.com website). Indeed, media outlets are quick to report data breaches involving (stolen) patient health data. Additionally, many jurisdictions have breach notification laws that requires notifications to be sent to regulatory bodies, including media, if data breaches occur. Before I continue, I’ll give a short quiz. Which of these three sets of personal information is de-identified? Consult the White Pages if you want. Rhonda James; DOB: 08-Sep-1988; Address: 71 Ansubet Dr, Charleston, WV Denise Lewis; DOB: 03-Mar-1976; Address: 23 Adams Chapel Rd, Mankato, MN Rosemarie Hardy; DOB: 14-Nov-1985; Address: 310 Camp Creek Rd, Weston, MA And so, how many Denise Lewis’s live in Minneapolis? PART I – GETTING STARTED 32 In fact, the source 5 that provided these samples suggested that all three are de-identified data. Imagine if such de-identified datasets are stolen and reported as “the data breach” by the media. The company may face severe fines and damage to its reputation long before it can be proven that the stolen datasets are fictitious and do not represent any real person. There are different algorithms for record-level data de-identification such as: data reduction, data modification and data suppression. Before you start implementing your own, I recommend you read the Tools for De-Identification of Personal Health Information6 report written by Ross Fraser and Don Willison for the Pan Canadian Health Information Privacy (HIP) Group. This report explains major techniques, requirements f or health data de-identification tools, and some of the commercially available tools. Other sources worth reading:  A Canadian standard: “Best Practice” Guidelines for Managing the Disclosure of DeIdentified Health Information.  A standard from US Department of Health and Human Services: Guidance Regarding Methods for De-identification of Protected Health Information in Accordance with the Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule.  Guidance from the UK Information Commissioner's Office: Anonymisation: managing data protection risk code of practice. Summary This chapter shows that in addition to typical software development issues, the HL7based development project has layers of additional complexity due to interconnected functional and non-functional requirements. Healthcare by itself is a difficult domain. Software developers that see CDA documents as yet another XML-based feed system run the risk of significantly underestimating the effort needed to complete a project. HL7 development requires not only properly eliciting and documenting functional and non-functional requirements, but also the eHealth landscape in which the project operates. You may be committed to build a scalable application capable of constructing countrywide level CDA document and processing all section-level templates, but your local regulatory restrictions may prevent sharing personal information with other 5 The source will not be disclosed. They received my opinion and suggestion. Available to download at - https://www.ehealthinformation.ca/knowledgebase/getAttach/15/AA00118/Tools_for_De-identification_EN-FINAL.pdf 6 33 PART I – GETTING STARTED jurisdictions. Consider time and effort spent on building unnecessary functionality before it becomes obvious. Testing HL7-based systems is a separate (sub) project by itself. It must conform to eHealth industry and local regulatory auditing and security requirements to protect sensitive information, and may require test data sets to be prepared upfront. Before you start building HL7 messaging application, it is essential that you understand the full complexity of HL7v3 based development work. PART I – GETTING STARTED 34 CHAPTER 4 Transforming Data with Mirth Connect Transforming Data with Mirth other universal domains in the HL7v3 Normative Edition , the Clinical Document Unlike Architecture does not specify storyboards, interactions and participants. This domain deals only with the CDA document exchange markup. On the other side, Mirth Connect provides greater freedom in data transformation since it allows using different techniques for data mapping such JavaScript, XSLT and Java. “Messaging” and “document” are understood differently by developers, end users and clinicians. A lab report in PDF format sent as an attachment by email is one of the options but such scenarios are not what I want to explore in this book. Before implementing an imaginary CCD Builder Server using Mirth Connect, we need to examine what we are trying to build. Also, it is good to note that this s erver is “imaginary” because the goal is to fully concentrate on Mirth Connect features rather than on actual CCD or MU2 business rules. Note: Before we start, I would like to stress that HL7 interactions and templates (in terms of CDA) shown in this book do not represent a real implementation and should not be used “as is”. Some words of caution should be raised before delving any deeper. The Mirth Connect HL7v2 messages parser is based on HAPI API which uses HL7 organization specified data types. However, in a real word scenario, it is rare that HL7v2 (and HL7v3) messages match the HL7 defined standard exactly. There are always some differences between a particular message type and the industry standard. The same is true about HL7 RIM based messages and document templates. Prerequisites Mirth Connect: All source code samples in this book are based on Mirth Connect scripts. Make sure that Mirth Connect is installed and properly configured on your computer. It is also assumed that you have basic understandings of features and techniques that Mirth Connect uses. HL7v2: Data source for the CCD will be based on incoming HL7v2 messages therefore a working knowledge of the HL7 v2.x message structure and messaging protocols is required. 35 PART I – GETTING STARTED HL7v3: Readers are assumed to know HL7v3 concepts and the Reference Information Model (RIM), as well as HL7v3 data types. Additionally, readers should have an understanding of vocabularies and terminologies such as SNOMED CT, LOINC, ICD, etc. Scenario Overview To give you a sense of how CCD Builder Server may work in a real life scenario, I would like to quote several narratives of relevant interactions from the HL7v3 Normative Edition 2014. If you are not familiar with this concept, the storyboard in HL7 terms is “a narrative of relevant events defined using interaction diagrams or use cases. The storyboard provides one set of interactions that the modeling committee expects will typically occur in the domain.” (HL7NE) To begin with: “Mr. Adam Everyman's physician, Dr. Patricia Primary, called the Good Health Hospital to schedule an inpatient visit for Mr. Everyman for lung surgery. The clerk verified that Mr. Everyman was not already registered as a patient in the GHH Patient Registry and created a new patient record for him then scheduled the admission for two weeks from that day.” (HL7NE > Patient Registry Record Added > PRPA_ST201301UV01) Later on, Mr. Adam Everyman “presents at Good Health Hospital Outpatient Clinic and is seen by Dr. Bill Beaker. Adam reports extreme thirst, fatigue, and recent unexplained weight loss. He also reports having a family history of diabetes. Dr. Bill Beaker wants to rule out diabetes mellitus by performing a GTT2HR. Upon the release of the results for the complete GTT2HR test, the laboratory system reports all the results in a single message.” (HL7NE > Complex Laboratory Result > POLB_ST221000UV01) Once laboratory results are available, Dr. Bill Beaker observes them as a single document and submits them to the Good Health Hospital for use during the scheduled inpatient visit for Mr. Everyman. (Patient and doctors names in storyboards are changed to match one another.) As you can see, several parties, also called Application Roles, are involved in this process. Application role is “an abstraction that expresses a portion of the messaging behavior of an information system.” (HL7NE) Thus, we may identify the following application roles that will be represented as system components: PART I – GETTING STARTED 36 Message Originator – creates messages and publishes (sends) them to a receiver (played by Patient Registry or Document Originator in our case). Patient Registry – represents the Patient Demographics Management System. Document Originator – creates a CCD document. The next step is to depict interactions between these three application roles. An interaction is “a single, one-way information flow that supports a communication requirement expressed in a scenario.” (HL7NE) Interaction model The Interaction Model for storyboards defined above shows interactions between application roles and is described using the sequence diagram (Figure 4-1). Message Originator Document Originator Patient Registry ADT_A28 ACK ORU_R01 ACK query response FIGURE 4-1 Interaction diagram As a base for the model’s interactions I have chosen to use HL7v2 transactions, though the same can be done using relevant HL7v3 transactions. Thus, the Patient Registry Record Added (PRPA_IN201301UV01) may be used instead of ADT_A28, along with the Result Complete with Fulfillment (POLB_IN224200UV01) instead of ORU_R01. The reason why HL7v3 messages are not used is because they are already in a format that is very 37 PART I – GETTING STARTED close to the final CCD document. This may over simplify this project and hide important Mirth Connect details. The interaction model has been intentionally complicated by adding an interim step to store patient demographics instead of sending it directly to the Document Originator. So let us quickly go through this sequence diagram to see how it works. 1. The Message Originator does a preliminary step by sending an ADT_A28 (Add Person or Patient Information) message to a temporary storage which plays the role of the database that holds patient-related information. Jumping ahead, I know that we will not be using any databases though you are free to try. The Patient Registry, in turn, may acknowledge the message. 2. The Message Originator sends an ORU_R01 (Unsolicited Observation Message) message to the Document Originator. The latter may acknowledge this message and then starts transforming and compiling the CCD document from the data it has received. At some point, the Document Originator may require patient demographic data if it was not fully provided in the ORU_R01 message. In such a case, the Document Originator makes an (internal) request to the Patient Registry and uses the data that the Patient Registry returns. Design Considerations There are many ways to accomplish the same task in Mirth Connect. In addition, there are many ways to build a valid CDA/CCD document. However, the main idea of this book is to explore Mirth Connect features, NOT to implement the service in a correct way using standard de-facto libraries such as Model Driven Health Tools (MDHT). The actual implementation of a real system most likely is different from this one. The diagram in Figure 4-2 illustrates the game plan for next parts of the book and mimics the scenario of sending the HL7v2 messages to the CCD Builder. The implementation plan is based on followings channels:  Sender – a channel that plays a role of the Message Originator and serves as an interface to handle and place an original ADT or ORU messages into the pipe using the MLLP Message Transport protocol.  CCD Builder – a channel that does all heavy lifting. Later we will see that this channel builds separate section-level templates and then compiles them into a single CCD document. This channel plays the role of the Document Originator. PART I – GETTING STARTED 38  Global Map – the Global Map, in Mirth Connect terms, represents the Patient Demographics Management System. Its main duty is to temporary store patient demographic data. Global Map HL7v2 (ADT_A28, ORU_R01) MLLP MLLP Reader Sender File Writer CCD Builder Transform ACK / NACK Transform CCD File Writer ACK / NACK FIGURE 4-2 CCD Builder Server channels implementation plan Throughout this implementation we will explore some major connectors: Channel Reader, TCP/IP Listener and Sender and File Writer. We will use all techniques explained earlier in this book which includes, but is not limited to: filters, transformers, code templates, maps, global and channel scripts. At this point it is assumed that you are comfortable with the Mirth Connect Administrator. Recommended tools and packages To make the development easier and less tedious, here is a list of recommended tools and packages. You are free to use any other tools that suit you better.   HL7v2 viewer such as Messaging Workbench or HL7Spy by Inner Harbour Software; HL7v3 viewer such as Altova XMLSpy by Altova GmbH; And last but not least, use the XML schemas and other related files from the archive provided with this book. Summary This section identified players and outlined the game plan. To do this we went through the storyboards as they are defined by HL7v3 Normative Edition, identified application 39 PART I – GETTING STARTED roles and interactions between them. This helped us depict the interaction model and translate it to the Mirth Connect channels implementation plan. In the next part of the book, we will implement these channels in Mirth Connect. This is a preview edition of the book. The full version with all related files is available to download at http://ccdonmirth.shamilpublishing.com PART I – GETTING STARTED 40 Book Resources Book Resources Other titles you may be interested in: Unofficial Mirth Connect v3.x Developer's Guide This book introduces readers to version 3.x of Mirth Connect to the point that they are confident enough to start building their own healthcare data exchange interfaces. By implementing an imaginary Eligibility Query Service, this book covers some of the topics on XML schema and Schematron validation, XSL Transformation, database connection pool creation, acknowledgements implementation, Mirth Connect extensions implementation and sending objects via the ActiveMQ Message Broker. The book is available to download at – http://mirthconnect.shamilpublishing.com Unofficial Developer's Guide to HL7v3 Basics This book introduces readers to HL7 version 3 to the point that they are confident enough to start building their own healthcare data exchange interfaces. The book provides clear and easy to use, step-by-step guidance for learning the standard, with numerous examples covering many topics. The book is available to download at – http://hl7basics.shamilpublishing.com APPENDICES Appendices A: CCD Mirth Templates B: Code Templates C: HL7v2 Test Messages D: XSLT files E: Archive Content These are files provided as supplementary materials required for parts II and III. Folder ..\Channels\ ..\Models\coreschemas\ ..\Models\Schemas\ ..\Models\ExcelView\ ..\Models\HTMLView\ ..\Models\MWBModels\ ..\Models\PictureView\ ..\Models\VisioModels\ ..\SampleMessages\CCD\ Files CCD Builder.xml Code Templates.xml Global Scripts.xml Query Sender.xml datatypes-base.xsd datatypes-rX-cs.xsd datatypes.xsd infrastructureRoot.xsd NarrativeBlock.xsd voc.xsd CCD-Body.xsd CCD-Header.xsd POCD_MT000041SN.xsd POCD_MT000042SN.xsd POCD_MT000041SN.xls POCD_MT000042SN.xls POCD_MT000041SN.htm POCD_MT000042SN.htm Add Person or Patient Information.mwb Unsolicited Observation Message.mwb MsgStructure.txt POCD_RM000041SN-Header.png POCD_RM000042SN-Body.png POCD_RM000041SN-Header.vsd POCD_RM000041SN-Header.xml POCD_RM000042SN-Body.vsd POCD_RM000042SN-Body.xml CCD_Allergies_Mirth_Template.xml CCD_Body_Mirth_Template.xml CCD_Header_Mirth_Template.xml Comment Mirth Connect channels, code templates and global scripts discussed in this book HL7 core XML schema files required to validate CCD document instances Localized, non-normative XML schemas for CCD header and CCD body parts. Document element descriptions in MS Excel format Document element descriptions in HTML format Messaging Workbench (MWB) models to validate ADT and ORU message samples. CCD header and body R-MIM representation CCD header and body R-MIM models in Visio format Parts of CCD document to serve as outbound Mirth Connect templates for the CCD Builder channel’s \SampleMessages\HL7v2 ..\XSLT\ 43 APPENDICES CCD_Header_Template_annotated.xml CCD_Medications_Mirth_Template.xml CCD_Problems_Mirth_Template.xml CCD_Results_Mirth_Template.xml ADT_A28.hl7 ORU_R01.hl7 Allergies_Entry.xslt Medications_Entry.xslt NoResults_Entry.xslt Problems_Entry.xslt Results_Entry.xslt destinations Samples of HL7v2.6 messages (uses v2.7 datatypes) XSL Transformation scripts required for CCD Builder channel’s destinations