Shamil Nizamov

Unofficial Developer’s Guide
to HL7v3 Basics*
* - Preview Edition

Introduction 2

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

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

HL7 and Health Level Seven are registered trademarks of Health Level Seven
International. All other marks, logos, quotes, pictures 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,
Health Level Seven International, resellers and distributors are NOT 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.


3 Introduction

Contents

PART 1 HL7V3 COMMUNICATION BASICS
Chapter 1 Systems Integration Requirements ................................................................................. 12
Abstraction Layers ............................................................................................................ 12
Systems Integration Requirements .................................................................................. 16
Testing ............................................................................................................................... 18
Summary ........................................................................................................................... 20
Chapter 2 HL7v3 Implementation Guides ........................................................................................ 22
Reference Information Model .......................................................................................... 22
HL7 Development Framework Overview .......................................................................... 26
HL7 XML Implementation Technology Specification Overview ........................................ 30
Summary ........................................................................................................................... 36
Chapter 3 HL7v3 Messaging Basics ................................................................................................... 38
Transport Wrapper ........................................................................................................... 40
Control Act Wrapper ......................................................................................................... 44
Domain Content ................................................................................................................ 51
Summary ........................................................................................................................... 55

PART II DESIGNING HL7V3 MESSAGES
Chapter 4 Introduction to Domain ................................................................................................... 58
Eligibility Service Introduction .......................................................................................... 58
Scenario Overview ............................................................................................................ 59
Interactions Overview ....................................................................................................... 61
Summary ........................................................................................................................... 63
Chapter 5 Building UV Realm Interactions ....................................................................................... 64
UV Schemas vs. Localized Schemas .................................................................................. 64
Locating Schemas .............................................................................................................. 65
Building Templates ........................................................................................................... 69
Summary ........................................................................................................................... 72
Chapter 6 Designing Localized Interactions ..................................................................................... 74
Locating Models ................................................................................................................ 75

Introduction 4

Localizing Models .............................................................................................................. 76
Serializing Models ............................................................................................................. 79
Building Message Profile ................................................................................................... 80
Summary ........................................................................................................................... 81
Chapter 7 HL7 Conformance Concepts ............................................................................................. 83
Schema Validation ............................................................................................................ 84
MIF Validation ................................................................................................................... 86
Schematron Validation ..................................................................................................... 87
Conformance Validation ................................................................................................... 93
Summary ........................................................................................................................... 93

PART III HL7V3 IMPLEMENTATION TOOLS
Chapter 8 HL7v3 Implementation Toolkits ...................................................................................... 96
HL7v3 Software Development Frameworks ..................................................................... 97
HL7v3 Interface Engines ................................................................................................... 98
HL7v3 Message Validation Tools ...................................................................................... 99
CDA Development Frameworks ...................................................................................... 100
CDA Documents Validation Tools ................................................................................... 100
Summary ......................................................................................................................... 100

APPENDICES
A: Archive Content .......................................................................................................... 103
B: XML Schemas automated copy routine ...................................................................... 105
C: XML Schema validation ............................................................................................... 109
D: Schematron validation ............................................................................................... 111



5 Introduction

Introduction
Introduction
Both the HL7 standard and software development methodology exist at a sufficiently
high level of abstraction to support multiple interoperability requirements, even when
these requirements conflict with each other. Some newbies portray HL7v3 as a “silver-
bullet” solution. Unfortunately, neither HL7v3 nor separate components of the standard
such as HL7 Reference Information Model (aka RIM) are “solutions”. They are just new
layers that separate end-user applications from the communication media, not a
fundamental change in how data is communicated in existing computing infrastructure.
These new layers provide new functions and integration mechanisms defined at higher
level of abstraction. Many software developers of traditional communication applications
or Web services try to understand HL7 standards as if they are written for typical
distributed software systems. This may lead to obstacles to successfully implement
HL7v3 based solutions.
The focus of this book is to introduce readers to HL7 version 3 to the point that they
confident enough to start building their own healthcare data exchange interfaces.
The goal of this book is to convince HL7 gurus to write comprehensive, complete,
illustrative books on topics of interest to people who implement and support HL7v3 (and
sooner FHIR) software solutions, rather than people who develop HL7 family standards
itself.
This book strives to teach you HL7v3 standard conventions by referencing to HL7v3
Normative Edition and implementing request and response messages for a fictitious
Eligibility Query Service. The implementation of the service is based on default (universal)
and localized schemas. The conformance of the implemented messages with the HL7v3
standard is also reviewed.
This book is written for the HL7v3 Normative Edition 2013 version of the HL7v3 standard.
Other HL7 editions may include additional features, and features described in this book
may change or disappear. You may also find differences between screen shots provided
in the book and those you see when using HL7v3 Normative Editions
1
.


1
HL7 Version 3 Normative Edition, 2013 is available to download for free (registration is required) at -
http://www.hl7.org/implement/standards/product_brief.cfm?product_id=186

Introduction 6


Who is this book for?
I wrote this book primarily for software developers, software testers, interface analyst,
system integrators and others who need an organized guide to the HL7v3 standard
documentation.
I realize that this book may be criticized by software developers and interface analysts.
Software developers may criticize it for not covering specific implementation details, or
for omitting source code and XML schema/MIF based code generation techniques.
Interface analysts may complain that this book skips steps in gathering requirements,
thereby ignoring some types of interactions necessary to meet real world scenarios. I
tried to include as much detail as possible but a book of this size cannot adequately
cover all HL7v3 standard features, as well as tons of additional information that very
talented people have provided in their blogs or discussed on forums. After all, this book
is not a substitute for the standard itself or for the official training materials provided by
HL7 and affiliates. And there are implementation and verification topics not covered well,
or covered at all, in the HL7 standard documentation.
Instead, I tried to organize the HL7 standard learning process to show the topics I
recommend you - as a software developer, who has just started and wants to learn
HL7v3 basics as quickly as possible - read first, read next, and what topics can be skipped
at the moment.
Assumption
This book assumes that you are dealing with applications that use message-oriented
middleware products. You should have at least a minimal understanding of Web service
technologies including, but not limited to, XML, XML Schemas, XPath, XSL
Transformation and Schematron.
Before you start reading this book, you should also have a basic knowledge of Open
Systems Interconnection (OSI) model, Unified Modeling Language (UML), Enterprise
Integration Patterns (EIP) and Java programming language.
And you should have basic knowledge of HL7, the standard that is being used to
exchange healthcare data, both version 2 and version 3.


7 Introduction

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 of HL7v3. This book is not intended to be a
step-by-step comprehensive guide or substitute of any kind to original training and
certification programs provided by Health Level Seven International, its affiliates or
numerous local providers.
This book is also not a complete tutorial on a specific domain messaging or middleware
technology implementation. All examples, scenarios, scripts and source codes 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 Health Level Seven International website
as a primary source of knowledge.
This book does not cover any specific system architecture, programming language,
development frameworks or tools to build a domain specific HL7v3 based healthcare
system. However, it provides references to some of them which you may explore further.
Errata and Book Support
I have made every effort to ensure the accuracy of this book and its companion content.
If you find errors or have comments or suggestions, please report through email –
hl7@isarp.com
Your feedback is highly appreciated!
Warning and Disclaimer
The purpose of this book is to educate and entertain. Every effort has been made to
make this book as complete and as accurate as possible, but no warranty or fitness is
implied.
The information is provided on an “as is” basis. The author shall have neither liability nor
responsibility to any person or entity 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.

Introduction 8

The author is not an employee or representative of Health Level Seven International or
its affiliates and never has been, and the author’s views and opinions are not necessarily
those of Health Level Seven International.
This book contains links to third-party Web sites 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, the 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.
Elliot Freedman volunteered to review early versions of a few chapters. Your feedback
helped steer me in the right direction. I’d like to thank Philip Helger in making an active
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.
Roadmap
This book is divided into three parts:
Part 1 provides an introduction to HL7v3 messaging and a high-level overview of
systems integration.
 Chapter 1, System Integration Requirements
Provides a brief overview of system design and systems integration requirements to
demonstrate the complexity that a typical integration project may encounter.
 Chapter 2, HL7 Implementation Guides
Provides an overview of implementation guides and methodologies designed and
supported by Health Level 7 International. Shows that these methodologies are

9 Introduction

mostly aimed at HL7 standard developers and domain working groups, not at HL7v3
message implementers.
 Chapter 3, HL7v3 Messaging Basics
Walks the reader through basic messaging concepts and HL7v3 message building
blocks aka wrappers. This chapter also explains some concepts unique for HL7v3
standard.
Part 2 focuses on the implementation of an imaginary Eligibility Service.
 Chapter 4, Introduction to Domain
Introduces the Eligibility Service as defined in the HL7v3 Normative Edition, presents
the implementation plan of an imaginary Eligibility Service and walks through the
main components.
 Chapter 5, Building UV Realm Interactions
Walks the reader through building actual messages representing selected interaction
based on Universal (UV) realm XML schemas.
 Chapter 6, Designing Localized Interactions
Explains the implementation of a localized version of one of the Eligibility Query
Service interactions using HL7 tools such as RoseTree, RMIM Designer and
V3Generator.
 Chapter 7, HL7 Conformance Concepts
Introduces a message verification process using different tools and methods such as
XML schema validation, Schematron validation and conformance review.
Part 3 is dedicated to HL7v3 messages implementation aspects.
 Chapter 8, HL7v3 Implementation Toolkits
Lists some open source tools and toolkits that readers may use to build and test
HL7v3 and CDA interfaces.
Appendices include:
 Archive Content
Lists folders and files included to the archive provided with the book.
 XML Schemas automated copy routine
Lists the source code to locate and copy interaction’s related XML schema files.

Introduction 10

 XSLT scripts
Lists the XSLT scripts required for projects.
 Schematron scripts and Schematron code file
Lists scripts and source codes to validate messages against schematron rules.


11 PART I – HL7V3 COMMUNICATION BASICS








PART I – HL7V3 COMMUNICATION BASICS
HL7v3 Communication
Basics
CHAPTER 1 System Integration Requirements
CHAPTER 2 HL7 Implementation Guides
CHAPTER 3 HL7v3 Messaging Basics







PART I – HL7V3 COMMUNICATION BASICS 12

CHAPTER 1 Systems Integration Requirements
System Integration Requirements
his chapter is a brief overview of system design and systems integration
requirements. You may be surprised that I have not started from interoperability in
general, or HL7 as a standard, or HL7 Reference Information Model (RIM) in
particular. This differs from how HL7 messaging is usually taught in workshops or
learning courses, where interoperability is the first thing to learn, followed by the RIM.
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 is a fait accompli and the task at
hand is to implement it.
Similarly, starting with the RIM may look very promising but it only adds confusion in the
end.
In order to facilitate HL7 broader implementation, this book takes a bottom-up approach
to building a system to communicate HL7v3 messages.

Abstraction Layers
As a software developer you know that building an enterprise level information system
requires proper leyers of abstraction. N-tier architecture provides a high degree of
decoupling, separating presentation, business and data tiers. Information technology
came to this solution after many trials and errors. If business needs were stable then such
a solution would not be required. However, today’s business, eHealth in particular, faces
constant change caused by new regulatory requirements (e.g., EHR Meaningful Use stage
1 to 3 in the USA), adapt to market changes and advance improvements of operational
processes. To achieve flexibilility, various types of abstraction layers are possible to hide
the implementation details of particular functions and integrating it based on its
purpose.
The Abstraction Layer, shown in Figure 1-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. As an example, the
application may request patient’s demographics using a getPatientDemographics()
T

13 PART I – HL7V3 COMMUNICATION BASICS

query instead of IHEPixPdqV2BpelProcess() or getPRPATE201305UV02(). And yet, from
the given calls, I could not easily tell that IHEPixPdqV2BpelProcess()is Oracle’s BPEL
(Business Process Execution Language) process to handle the patient demographics
query. Could you?

FIGURE 1-1 Simple system architecture using an abstraction layer
The place where data stored is called the Data Repository. The purpose of this 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 a such 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;
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.
You may already noticed that 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; 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? Let’s add a
level of complexity to allow the Abstraction Layer to request data from a remote location
using an HL7v3 messaging system. (see Figure 1-2)

PART I – HL7V3 COMMUNICATION BASICS 14


FIGURE 1-2 System architecture with HL7v3 request capability
Figure 1-2 schematically shows an abstract system with added HL7v3 messaging
capability. If you are not familiar with the HL7v3 standard, you may be wondering why
there are three streams, each of which has its own message translator and content
enricher. Also, what are data sources that these two streams are using? We will explore
this in following chapters. Figure 1-2 shows only the sending component. The receiving
component will be a little bit different. (see Figure 1-3)

FIGURE 1-3 System architecture with HL7v3 messaging capability

15 PART I – HL7V3 COMMUNICATION BASICS

Figure 1-3 schematically shows both the HL7v3 sending and receiving components of
our abstract system.
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.
Assuming a Web Service is used to make a request, the notional data flow with added
HL7 functions may be:
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. If data is not available, the Abstraction Layer sends a request to the HL7v3 Sender
component.
5. The HL7v3 Sender component, in turn, forms parts of the HL7 message, aggregates
them into a single message, wraps the message in a SOAP envelope (or MLLP or
other transport mechanism) and sends it to the remote system.
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 Abstraction Layer forms the data in the way the Application understands and
sends it to the Application.
8. The Application processes the data and uses it as intended.
Besides typical alternative and exception flows related to communication, questions that
left unanswered are:
 Should the Abstraction Layer store the received data in the local Data Repository?
 If the local Data Repository contains data that is not in sync with data from the
remote location, and the local data is newer than received, what should the system
do?
 If the local Data Repository is not in sync and local data is older than what is
received, what should the system do?

PART I – HL7V3 COMMUNICATION BASICS 16

 If the Application asks for a set of data but HL7v3 messaging component is capable
to retrieve only a chunk at the time and must make several requests to fulfil the
Application need, what should the system 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
messaging system architecture.

System Integration Requirements
Different types of requirements shape a system’s behaviour. 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 along 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 the illustrative purpose, 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 the 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

17 PART I – HL7V3 COMMUNICATION BASICS

maintain data integrity. Depending on workflow, the number of messages exchanged by
systems can be significant and the number of transactions will probably 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 characterised as “the system should be fast” and written as “a
transaction should take less than N seconds to complete”. However neither specify 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 automates 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 conclusion of the transaction, or just N seconds
before the end-user receives some kind of feedback? Decisions made here also affects
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 HL7v3 messaging, 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

PART I – HL7V3 COMMUNICATION BASICS 18

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 develop the system, 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 Behaviour-Driven Development aimed at creating highly 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

19 PART I – HL7V3 COMMUNICATION BASICS

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 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 to cover all three groups. Other types,
such as acceptance-testing, integration testing, non-functional testing need more
sophisticated test data in order to verify desired behavior against the system’s
integration requirements.
Capacity testing unveils another issue of scaling up existing data to create sufficient
volumes of representative data for different performance-related test cases.
A key challenge 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. The de-identification of
the 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.

PART I – HL7V3 COMMUNICATION BASICS 20

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 live in Minneapolis?
In fact, the source
2
that provided these samples suggested that all three are de-identified
data. Imagine if such de-identified datasets being 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
Information
3
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 tries to show 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 HL7v3 messaging
as yet another XML-based feed system run the risk of significantly underestimating the
effort needed to complete a project.

2
The source will not be disclosed. However, I sent them a note providing my opinion and suggestion.
3
Available to download at - https://www.ehealthinformation.ca/knowledgebase/getAttach/15/AA-
00118/Tools_for_De-identification_EN-FINAL.pdf

21 PART I – HL7V3 COMMUNICATION BASICS

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 sending HL7
messages across the country and processing all versions of incoming messages, but your
local regulatory restrictions may prevent sharing personal information with other
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 obligates to consider
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 – HL7V3 COMMUNICATION BASICS 22

CHAPTER 2 HL7 Implementation Guides
HL7 Implementation Guides
ecognizing the complexity of HL7 family of standards, Health Level 7 International
came up with a number of implementation guides and methodologies. The vast
majority of them support HL7v2 due to a number of legacy systems still using HL7v2
as a messaging standard. Another HL7 standard well covered by implementation guides
is Clinical Document Architecture (CDA), which serves as a basis for Continuity of Care
Document (CCD) and other similar specifications in US.
There are quite few implementation guides specifically aimed at HL7v3. Unfortunately,
many of them are written for people developing the HL7v3 standard, not on using HL7v3
as a tool. One of them is HL7 Development Framework (HDF), which is a methodology
how to develop any HL7 standard, including v2 and v3 messaging, CDA and others. It
proposes a Project Life Cycle for Product Development divided into 7 areas such as
project initiation, domain analysis, specification design and others. More on this below.
Another HL7v3 related implementation guide is HL7v3 XML Implementable Technology
Specification (ITS) for v3 Structures. The XML ITS is more technical than the HL7
Development Framework and describes how initial HL7 v3 models can be serialized using
XML.
To better understand the HL7v3 standard and how to translate HL7v3 models to XML
messages, let’s review HDF and XML ITS. I’m using HL7 Healthcare Development
Framework Version 1.5 Release 1 published on November 21
st
2009 and XML
Implementable Technology Specification for V3 Structures Release 1.1 published on July
20
th
2012.


This is a preview edition of the book.

The complete version is available to download at
http://hl7.isarp.com



R

23 DICES

DICES
Appendices

A: Archive Content
The archive provided with this book contains a set of files required for Part II projects
and implementations.
Eligibility.HL7Model.zip
Folder Files or Folders Comment
CDA CDA folder is included for the
reference only.

CDA/MIF2
DEFN=UV=DT=1.0.coremif
DEFN=UV=DT=1.1.coremif
DEFN=UV=DT=2.0.coremif
DEFN=UV=IFC=1.8.3.coremif
DEFN=UV=RIM=0219.coremif
DEFN=UV=VO=1062-20101110.coremif
DEFN=UV=VO=R02.04.00.coremif
POCD_RM000040 - CDA.mif
POCD_RM000040 - CDA R-MIM.mif

Contains MIF and related files
generated using V3Generator and
NE default CDA RMIM model.

Note: It uses old datatype schema.

HL7v3 NE2013 Eligibility Service messages based
on NE default schemas.

../coreschemas
datatypes-rX-cs.xsd
infrastructureRoot-r2.xsd
iso-21090_hl7-r2_datatypes.xsd
voc-r2.xsd

NE default datatypes and
vocabulary XML schemas.
../Samples_
Annotated
QUCR_IN200101UV01_Request_Annotated.xlm
QUCR_IN210101UV99_Error_Annoteated.xml
QUCR_IN210101UV99_Success_Annotated.xml
Annotated Eligibility Query Request
and Eligibility Query Response
samples.
../schemas
COCT_MT030203UV07.xsd
[…]
QUQI_MT120001UV99.xsd

NE default UV schema files. Most of
the schema files are skipped in this
table for brevity.
../Templates
MCCI_IN000002UV02_template.xml
QUCR_IN200101UV01_template.xml
QUCR_IN210101UV99_template.xml
Eligibility Query Request, Eligibility
Query Response and Accept
Acknowledgement templates.



HL7v3 SN

Acceptance Acknowledgement
message based on localized
schema.

../coreschemas
datatypes-rX-cs.xsd
infrastructureRoot-r2.xsd
iso-21090_hl7-r2_datatypes.xsd
voc-r2.xsd

NE default datatypes and
vocabulary XML schemas.

DICES 24

../MessageSpecs
../Business-html
../ExcelFiles
../ImageViews
../Schema-html
../TableViews
../VisioModels
../WordViews

Accept Acknowledgement message
profile specifications and models.
Folders content is skipped in this
table for brevity.
../Samples
MCCI_IN000200SN-flavorId.xml
MCCI_IN000200SN-Sample Message.xml
Accept Acknowledgement message
samples with and without defined
flavorId attribute.
../schemas
MCCI_IN000200SN.xsd
MCCI_MT000200SN.xsd
Localized schema for Accept
Acknowledgement message.



SourceCode

Projects source codes and related
files.

../Java
CopyReferences.java
RulesBuilder.java
SchematronValidation.java
XML_Validation.java
Java source codes for copy routines,
schematron rule builder,
schematron and schema validation
projects.
../Schematron
_elements.sch
_mcci_in000200sn.sch
datatypes.sch
Schematron files used in the
projects.
../XSLT
_extractRules.xslt
_include.xslt
XSL Transformation files used in the
projects.