Unofficial Developer Guide to HL7v3 Basics

5/25/2018 Unofficial Developer Guide to HL7v3 Basics

1/24

Shamil Nizamov

Unofficial Developers Guide

to HL7v3 Basics*

* - Preview Edition


2/24

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 authors views and opinions. The information contained in thisbook 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/24

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 .......................................................................... 26HL7 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


4/24

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/24

5 Introduction

Introduction

IntroductionBoth 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 providedin the book and those you see when using HL7v3 Normative Editions1.

1HL7 Version 3 Normative Edition, 2013is available to download for free (registration is required) at -

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=186


6/24

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

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 Webservice

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/24

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

[email protected]

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


8/24

Introduction 8

The author is not an employee or representative of Health Level Seven International or

its affiliates and never has been, and the authorsviews 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. Id 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 andeffort 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/24

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 interactionsrelated XML schema files.


10/24

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/24

11 PART IHL7V3 COMMUNICATION BASICS

PART IHL7V3 COMMUNICATION BASICS

HL7v3 CommunicationBasics

CHAPTER 1 System Integration Requirements

CHAPTER 2 HL7 Implementation Guides

CHAPTER 3 HL7v3 Messaging Basics


12/24

PART IHL7V3 COMMUNICATION BASICS 12

CHAPTER 1 Systems Integration Requirements

System Integration Requirements

his chapter is a brief overview of system design and systems integrationrequirements. 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 accompliand 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, todays 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 patientsdemographics using a getPatientDemographics()


13/24


query instead of IHEPixPdqV2BpelProcess() or getPRPATE201305UV02(). And yet, from

the given calls, I could not easily tell that IHEPixPdqV2BpelProcess() is Oracles 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 cloudsas 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? Letsadd 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)


14/24


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/24


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 patientmedical 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 belongsto 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 theremote 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?


16/24


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. Letsconsider other aspects that may influence the HL7

messaging system architecture.

System Integration Requirements

Different types of requirements shape a systemsbehaviour. Stakeholders (users,

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

typically good at eliciting all levels (organizational, system, component) of functionalrequirements. 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 projects

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/24


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 retentionperiod 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 systems messaging component performancerequirement and systems user interfaceperformance 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 Nseconds to successful conclusion of the transaction, or just Nseconds

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


18/24


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

Productionenvironment.

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/24


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 systems

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

patients personal demographic and health information specifically to prevent

disclosing either the identity or other attributes of private individuals. This is where de-

identificationcomes into play. De-identification of patientsinformation 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 quickto 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, Ill givea short quiz. Which of these three sets of personal information

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


20/24


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 source2that 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

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

2The source will not be disclosed. However, I sent them a note providing my opinion and suggestion.

3Available to download at - https://www.ehealthinformation.ca/knowledgebase/getAttach/15/AA-

00118/Tools_for_De-identification_EN-FINAL.pdf


21/24


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


22/24


CHAPTER 2 HL7 Implementation Guides

HL7 Implementation Guides

ecognizing the complexity of HL7 family of standards, Health Level 7 Internationalcame 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 XMLmessages, letsreview HDF and XML ITS. Im using HL7 Healthcare Development

Framework Version 1.5 Release 1 published on November 21st2009 and XML

Implementable Technology Specification for V3 Structures Release 1.1 published on July

20th2012.

This is a preview edition of the book.

The complete version is available to download at

http://hl7.isarp.com

R
http://hl7.isarp.com/http://hl7.isarp.com/http://hl7.isarp.com/


23/24

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.coremifDEFN=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.xsdinfrastructureRoot-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.xmlQUCR_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.xsdinfrastructureRoot-r2.xsd

iso-21090_hl7-r2_datatypes.xsd

voc-r2.xsd

NE default datatypes and

vocabulary XML schemas.


24/24

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.xmlMCCI_IN000200SN-Sample Message.xml

Accept Acknowledgement message

samples with and without defined

flavorId attribute.

../schemas MCCI_IN000200SN.xsdMCCI_MT000200SN.xsd

Localized schema for Accept

Acknowledgement message.

SourceCode Projects source codes and related

files.

../Java CopyReferences.javaRulesBuilder.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.