Rahul Bhagat - HL7 for Busy Professionals: Your No Sweat Guide to Understanding HL7

HL7 for Busy

Professionals

Your No Sweat Guide to Understanding HL7

Rahul Bhagat

Illustration By Calvin Hui

Anchiove

2015

Copyright 2015 by Rahul Bhagat

All rights reserved. This book or any portion thereof may not be reproduced or used in any manner whatsoever without the express written permission of the publisher except for the use of brief quotations in a book review or scholarly journal.

First Printing: 2015

ISBN 978-0-9939945-1-7

Anchiove Inc.

135 Wynford Dr., Toronto, ON, Canada M3C OJ4

www.HL7Book.com

Although the author and publisher have made every effort to ensure that the information in this book was correct at press time, the author and publisher do not assume and hereby disclaim any liability to any party for any loss, damage, or disruption caused by errors or omissions, whether such errors or omissions result from negligence, accident, or any other cause

To Neelam Bhagat,

who knew this book was for real before I did.

Thank you ma.

Table of Contents

Preface

After university, I got a job with a busy, Toronto based, healthcare consulting company. On day two at work, I was handed a printout with cryptic text on it, and a document called interface spec, to read and understand.

This was my introduction to HL7. At that time, I did not realize that this obscure messaging protocol would become my ticket to far off places, and the reason to meet and work with a lot of people.

It didn't take me long to learn HL7, my programming background helped. Later, I realized that my skill is in high demand and I became a consultant. I traveled to different cities and worked on various HL7 projects.

I also started running into people from non-technical background who wanted me to explain HL7 in the elevator or while chatting in their cubicle. There wasnt any introductory book I could suggest, so the idea of writing one myself.

I'm glad I collaborated with Calvin Hui in writing this book. He not only took care of illustration and design but also nudged me when I was slacking after the first draft. My friend Erik Westermann was a great sounding board and helped me refine my ideas. And thanks to many colleagues who helped me develop my skills. In particular, Derrick Leung, who mentored me when I was just starting out.

So here it is. My idea of an introductory book on HL7. I hope you enjoy reading it.

Part I

Scratching the surface

1. Introduction

A technical book usually implies a dry subject. So its no surprise authors have a hard time figuring out ways to make the book interesting to the reader. HL7 is one such subject. It is a subject that is so high on the scale of dryness and no one comes to it willingly. The only reason someone would read a book on HL7 is because of his or her job. And if you are here, reading this book, then I assume you work in healthcare IT or intend to join the industry soon.

I have made every effort to take out the dryness of the subject and make this book interesting. There are no needless jargons or esoteric concepts thrown casually to trip you. In fact, you will see a heavy reliance on everyday examples and inclusion of background information to paint a complete picture. But HL7 and healthcare system integration are complex subjects so there will be topics that don't make sense right away. Please persevere. Tie a knot and hang in there. Gradually things will make sense.

This introductory book on HL7 goes in detail to explain what HL7 is. It gives you the basic concepts, tells you about the organization behind it and helps you create a mental map of the voluminous HL7 specification document. And, it takes you through a whirlwind tour of some of the most commonly used HL7 messages, all in a short span of time.

Early Railroads

HL7 was created to solve the problems of clinical system integration. But to truly understand the problems of system integration, lets start with another integration problem we solved centuries ago.

The 1800s were a time when railways were coming of age in America just like battery driven cars, drones and other new technologies are coming of age today.

There were literally hundreds of companies competing for a piece of the railway pie. Enterprising companies would buy up land, lay down tracks and run a transport service between cities which had no other means of transportation except for horse-drawn wagons or, if one was fortunate, steamships.

By the time American civil war started (1861), vast stretches of the continent were already connected through rail and work was well underway on the construction of the transcontinental railroad to connect California with the rest of the country.

However, there was one problem. You could not just hop on a train and get off at your destination, like you can today. Because these railroads were built and run by different companies, they used different track gauges (horizontal distance between two rails of the track). This meant you had to get off and change trains whenever you hit a junction with two different gauge widths. There were well over twenty different track gauges being used at the time of the civil war. The army had to constantly load and unload cargo in its effort to get supplies to the troops. This was a serious problem!

And it was the reason that finally made the American government to push for the conversion of all railway tracks to a standard gauge4 feet and 8.5 inches, the most commonly used gauge width. More than half of the existing tracks were built to this width so it was easiest to convert the remaining tracks to this width and achieve standardization.

Standardization of rail tracks was the first step towards creating an integrated system where goods and people could move freely across the whole network. It was followed by the development of a common signal system, time zones, harmonized train schedule, fixed coach height, a standard coal and water supply system and on and on.

It was evident that an integrated system needed a standard way of doing things.

Evolution of Healthcare IT Systems

Today, we are in a (somewhat) similar situation with the movement of healthcare information. It cannot seamlessly flow from one system to the next. Each organization has its own way of storing and sharing information. Whenever health information needs to move across organization boundaries, it hits the incompatible standards roadblock. Someone has to unload and reload the information.

Healthcare IT systems have evolved similar to railroads. Initially, hardware costs (think multi-million dollar mainframes) were the biggest factor, so only a few teaching hospitals with deep pockets had the means to build a system. These were primarily stand-alone systems meant to serve a specific purpose. For example, to manage patient population in a large hospital.

Then the hardware cost came down and minicomputers arrived on the scene. A computer could be had for less than $25,000 and didnt need a room to house it. This allowed smaller players and even departments within a hospital to purchase systems of their own. Pharmacies installed systems to track prescriptions and dispensed medication while laboratories set up systems to track requests for tests and their results.

This led to dramatic improvement in productivity for these organizations but there was no free flow of information between the clinical systems. The problem was lack of standardization. Information from one system had to be unloaded to paper and transported to where the other system was. Then a human operator would reload the information to the other system by manually typing it in.