New Microsoft Office Word Document

HL7 Integration Using Mirth

1. Introduction

1.1 About Project

The typical clinical facility or hospital has several HL7 enabled applications and devices. To

reduce data entry time and increase overall efficiency of the facility, these applications or

devices need to communicate with each other.

One way to accomplish this is by:

Using an interface engine that is placed between all the applications to aid in information

exchange and monitoring.

Facilities that use an interface engine model find that:

It is much less expensive and takes less time to initially implement an interface because

an engine allows for leveraging of data and an engine is flexible in its acceptance of data.

The cost and time required to add new or replace existing applications is frequently less

than half that required in a point-to-point model

It requires considerably less time and money to maintain and monitor the interfaces

because of the availability of centralized monitoring

Figure 1.1:DataFlow of Interface Engine

Dept Of MCA,B.I.E.T,Davangere.


An interface engine is designed to simplify connecting, maintaining, monitoring, and sharing

data between interfaces. An interface engine can take data from a sending application and

filter it or change the format of the data to match each individual application’s needs.

This feature greatly reduces the number of individual endpoints required to communicate

between applications which in turn, saves on the price of implementing of an integrated

system.

HL7 has established itself as a standard in healthcare information exchange. In order for an

electronic health record system to integrate or exchange data with HL7 systems, an adapter

layer must be implemented to transform messages.

Mirth allows messages to be filtered, transformed, and routed based on user-defined rules. A

web-based interface and channel creation wizard associates applications with Mirth engine

components.

Mirth uses a channel-based architecture to connect systems with other HL7 systems. Channels

consist of endpoints (both inbound and outbound), filters, and transformers.

Multiple filters and a chain of transformers can be associated with a channel. The Mirth web

interface allows for reuse of filters and transformers on multiple channels.

Endpoints are used to configure connections and their protocol details. Inbound endpoints are

used to designate the type of listener to use for incoming messages, such as TCP/IP or a web

service. Outbound endpoints are used to designate the destination of outgoing messages, such

as an application server, a JMS queue, or a database



1.2 Organization Profile

1.2.1 About Starmark

Starmark Services is a global services provider for software products and IT solutions

development. Our extensive business process and domain expertise helps converting client's

business requirements to technology based solutions.

The leadership team has worked together over a period of time, and the realization of

common values and beliefs evolved into the Starmark we know today. The team has a

diverse background that includes consulting, product management, product development and

corporate strategy while holding senior technology positions in Fortune 500 and Software

companies. The synergies supplemented with the breadth and depth in expertise and

experience has helped shape Starmark to be professional, credible, client focused software

Solutions Company. It is these traits that have led clients to follow us from previous

assignments.

At Starmark, we believe in the power of reaching for goals. Goals give us direction and

provide a roadmap for where we're going, where we want to be, and how we plan to get there.

Goals are also a strong motivational force - we at Starmark thrive on the challenge of meeting

goals within strict operational parameters.

Product supremacy, quality and reputation

First-class customer service and customer satisfaction

Strong, consolidated corporate profitability, financial strength and success

Honesty and integrity in all aspects of business

Recognizing and rewarding our people for dedication and high levels of achievement

Creating opportunities for our people to grow and share in the success of the enterprise

1.2.2 Our services

Leverage our specialized staff comprising of analysts, architects, managers, engineers, support

executives and testers to establish an exclusive, scalable and effective team to suit your

project needs. Customers have come to us initially to cut costs, stayed with us for quality and



moved onto investing for innovation. Starmark provides services under the following

specializations:

R&D Services

IT Services

System Integration

Maintenance & Support Services

Starmark is a premier software product development and enterprise solutions service provider.

We enable enterprises to leverage software and internet technology to build value across their

customers, partners, suppliers and employees. We supplement capabilities of software product

companies in building scalable R&D, product development, sustenance and support

operations.

1.2.3 Corporate Goals

At Starmark, we believe in the power of reaching for goals. Goals give us direction and

provide a roadmap for where we're going, where we want to be, and how we plan to get there.

Goals are also a strong motivational force - we at Starmark thrive on the challenge of meeting

goals within strict operational parameters.

We understand the axiom that companies have goals, but it's management and employees that

accomplish them. That's why our corporate goals revolve around values rather than sales

targets. We believe in:

Product supremacy, quality and reputation

First-class customer service and customer satisfaction

Strong, consolidated corporate profitability, financial strength and success

Honesty and integrity in all aspects of business

Recognizing and rewarding our people for dedication and high levels of achievement

Creating opportunities for our people to grow and share in the success of the enterprise

2. Literature Survey



2.1 HL7 Overview

Health Level Seven International (HL7) is a not-for-profit, ANSI-accredited standards

developing organization dedicated to providing a comprehensive framework and related

standards for the exchange, integration, sharing, and retrieval of electronic health information

that supports clinical practice and the management, delivery and evaluation of health services.

An international standard development organization established more then 20 years ago.

Enables interoperability of healthcare information. Creates standards for the exchange

management and integration of electronic healthcare information.

Develops specification, e.g., a messaging standards that enable disparate healthcare

application to exchange key sets of clinical and administrative data.

HL7 is an international community of healthcare subject matter experts and information

scientists collaborating to create standards for the exchange, management and integration of

electronic healthcare information.

The HL7 community is organized in the form of a global organization (Health Level Seven,

Inc.) and country-specific affiliate organizations:

Health Level Seven, Inc. (HL7, Inc.) is headquartered in Ann Arbor, Michigan.

HL7 affiliate organizations, not-for-profit organizations incorporated in local

jurisdictions, exist in over 40 countries. The first affiliate organization was created in

Germany in 1993

2.1.1 The Name "Health Level-7"

The name "Health Level-7" is a reference to the seventh "application" layer of the ISO OSI

Reference model. The name indicates that HL7 focuses on application layer protocols for the

health care domain, independent of lower layers. HL7 effectively considers all lower layers

merely as tools.

2.1.2 HL7’s Mission is:



"To provide (global) standards for the exchange, management and integration of data that

supports clinical patient care and the management, delivery and evaluation of healthcare

services. Specifically, to create flexible, cost effective approaches, standards, guidelines,

methodologies and enable healthcare information system interoperability and sharing of

electronic health records."

2.1.3 HL7 Standards

HL7 specifies a number of flexible standards, guidelines, and methodologies by which various

healthcare systems can communicate with each other. Such guidelines or data standards are a

set of rules that allow information to be shared and processed in a uniform and consistent

manner. These data standards are meant to allow healthcare organizations to easily share

clinical information.

HL7 version 2 defines a series of electronic messages to support administrative, logistical, and

financial as well as clinical processes. The HL7 Version 2 Messaging Standard — Application

Protocol for Electronic Data Exchange in Healthcare Environments — is considered to be the

workhorse of data exchange in healthcare and is the most widely implemented standard for

healthcare information in the world.

HL7 v2.x has allowed for the interoperability between electronic Patient Administration

Systems (PAS), Electronic Practice Management (EPM) systems, Laboratory Information

Systems (LIS), Dietary, Pharmacy and Billing systems as well as Electronic Medical Record

(EMR) or Electronic Health Record (EHR) systems.

The HL7 Standard covers messages that exchange information in the general areas of:

Patient Demographics

Patient Charges and Accounting

Patient Insurance and Guarantor

Clinical Observations

Encounters including Registration, Admission, Discharge and Transfer

Orders for Clinical Service (Tests, Procedures, Pharmacy, Dietary and Supplies)

2.1.4 HL7 Messages



A message is the atomic unit of data transferred between systems. It is comprised of a group

of segments in a defined sequence. Each message has a message type that defines its purpose.

For example the ADT Message type is used to transmit portions of a patient’s ADT data from

one system to another.

Message

o Segment (Some are Repeatable)

Fields (Some are Repeatable)

Components

o Subcomponents

A segment is a logical grouping of data fields. Segments of a message may be required or

optional. They may occur only once in a message or they may be allowed to repeat. Each

segment is given a name. For example, the ADT message may contain the following

segments: Message Header (MSH), Event Type (EVN), Patient ID (PID), and Patient Visit

(PV1).

2.1.5 HL7 Message Types

ORU (Observation Result)

The ORU message transmits observations and results from the producing system/filler i.e.

LIS, EKG system) to the ordering system/placer (i.e. HIS, physician office application). It

may also be used to transmit result data from the producing system to a medical record

archival system, or to another system not part of the original order process. ORU messages are

also sometimes used to register or link to clinical trials, or for medical reporting purposes for

drugs and devices.

Types of observations reported in the ORU message include:

Clinical lab results

Imaging study reports

Patient condition or other data (i.e. vital signs, symptoms, allergies, notes, etc.)

The ORU message is a structured report where each observation is separated into an

individual entity, and then separated into fields. ORU messages do not carry images; they use

varying data types but most often use text, numbers and codes.



In the ORU message, the ORC (Common Order Segment), the OBR (Observation request)

and OBX (Observation) segments are most significant due to their functions:

The Common Order segment (ORC) is used to transmit fields that are common to all

orders (all types of services that are requested).

The OBR segment is used in all ORU messages as a report header, and contains important

information about the order being fulfilled (i.e. order number, request date/time, observation

date/time, ordering provider, etc.). This segment is part of a group that can be used more than

once for each observation result that is reported in the message.

The OBX segment transmits the actual clinical observation results as a single observation

or observation fragment.

DFT (Detailed Financial Transaction)

The DFT message describes a financial transaction that is sent to a billing system and s

used for patient accounting purposes. This message might include things like ancillary

charges or patient deposits, and is sent between the DSS/Order Filler and the Charge

Processor.

Trigger events for the DFT-P03 message include:

Procedure ordered

Procedure scheduled

Procedure completed

Future will define Report events for professional fees.

2.2 MIRTH-Interface Engine



2.2.1 IntroductionMirth is an open source cross-platform HL7 interface engine that enables bi-directional

sending of HL7 messages between systems and applications over multiple transports.

Mirth uses a channel-based architecture to connect systems with other HL7 systems. Channels

consist of endpoints (both inbound and outbound), filters, and transformers. Multiple filters

and a chain of transformers can be associated with a channel. The Mirth web interface allows

for reuse of filters and transformers on multiple channels.

The Mirth is a healthcare interface engine and interface repository created and professionally

supported by Web Reach. Mirth provides standards-based tools to develop, test, and deploy

interoperability solutions for healthcare information systems and information exchanges.

Mirth is middleware that connects health information systems so they can exchange clinical

and administrative data. Mirth is released under the Mozilla Public License v1.1 and is

professionally supported by Web Reach, a Health information technology (IT) solutions

company based in California.

There are many standards in healthcare, with a diverse range of protocols and types of data.

There are different health information systems such as labs, pharmacies, clinics, hospitals, and

many others. Each of these systems might have different protocols, mismatched versions, and

incompatible data. Some systems might actively use HL7, X12, and DICOM images, while

others simply have a database to read from or communicate with XML and comma separated

values. Add to that the lacks of control administrators have over current and legacy

applications, and the healthcare interoperability problem becomes apparent. This is where

Mirth steps in as the easy to use and deploy middleware solution. Mirth can lie between any

number of health information systems, whether they speak a standard healthcare language or

not, and help them communicate.

2.2.2 Features of mirth A rich interface channel development and monitoring environment that allows you to

generate filter rules and transformation steps using an intuitive drag-and-drop

template-based editor

Real-time connection monitoring through the interface dashboard.



Message reprocessing through the message browser.

The Channels View to created, modified, deleted, and deployed a channel.

Mirth provides the Users section for editing the set of users allowed to use the

application.

Setting area can be used to configure option values that affect the Mirth Administrator

and Mirth Server. It also can be used for configuration maintenance.

Integrated alerting based on user-defined rules to continuously monitor your interfaces

and notify users to take action.

2.2.3 Mirth provide solution for:

Hospitals face increasing pressure to drive down cost and improve both safety and clinical

quality while becoming the preferred practice venue for providers and the most convenient

and service-friendly place for patients and their families.

Mirth can help in streamlining the flow of information across departments and legacy systems

within the organization, speeding results delivery to clinicians across the community, or

becoming part of a community-wide health information exchange.

Labs compete on timeliness, service and accuracy, and to a growing degree to how they

enable results delivery directly into referring physicians’ EHR systems.

Mirth can help in connecting LIS to other units within an integrated delivery system or to

practice locations across the community.

2.2.4 Mirth Architecture



Figure 2.1: Mirth Architecture

2.3 JAVA

The Java programming language is a high-level language that can be characterized by all of

the following buzzwords:

Simple Architecture-neutral

Object-oriented Portable

Distributed High-performance

Interpreted Multithreaded

Robust Dynamic

Secure

In the Java programming language, all source code is first written in plain text files ending

with the .java extension. Those source files are then compiled into .class files by the javac

compiler. A .class file does not contain code that is native to your processor; it instead

contains bytecodes — the machine language of the Java Virtual Machine (Java VM).

2.3.1 The Java Platform

A platform is the hardware or software environment in which a program runs. Most platforms

can be described as a combination of the operating system and underlying hardware. The Java

platform differs from most other platforms in that it's a software-only platform that runs on

top of other hardware-based platforms.

The Java platform has two components:

The Java Virtual Machine

The Java Application Programming Interface (API)



A Java Virtual Machine is the base for the Java platform and is ported onto various hardware-

based platforms.

The API is a large collection of ready-made software components that provide many useful

capabilities. It is grouped into libraries of related classes and interfaces; these libraries are

known as packages.

2.3.2 Features of Java

Platform Independent

The concept of Write-once-run-anywhere (known as the Platform independent) is one of the

important key feature of java language that makes java as the most powerful language. Not

even a single language is idle to this feature but java is more closer to this feature. The

programs written on one platform can run on any platform provided the platform must have

the JVM.

Simple

There are various features that makes the java as a simple language. Programs are easy to

write and debug because java does not use the pointers explicitly. It is much harder to write

the java programs that can crash the system but we can not say about the other programming

languages. Java provides the bug free system due to the strong memory management. It also

has the automatic memory allocation and deallocation system.

Object Oriented

To be an Object Oriented language, any language must follow at least the four characteristics.

Inheritance: It is the process of creating the new classes and using the behavior of the existing

classes by extending them just to reuse the existing code and adding the additional features as

needed.

Encapsulation: It is the mechanism of combining the information and providing the

abstraction.



Polymorphism: As the name suggest one name multiple form, Polymorphism is the way of

providing the different functionality by functions having the same name based on the

signatures of the methods.

Dynamic binding: Sometimes we don't have the knowledge of objects about their specific

types while writing our code. It is the way of providing the maximum functionality to a

program about the specific type at runtime.

Distributed

The widely used protocols like HTTP and FTP are developed in java. Internet programmers

can call functions on these protocols and can get access the files from any remote machine on

the Internet rather than writing codes on their local system.

Dynamic

While executing the java program the user can get the required files dynamically from a local

drive or from a computer thousands of miles away from the user just by connecting with the

Internet.

Multithreaded

Java is also a multithreaded programming language. Multithreading means a single program

having different threads executing independently at the same time. Multiple threads execute

instructions according to the program code in a process or a program. Multithreading works

the similar way as multiple processes run on one computer.

2.3.3 JDBC-ODBC Bridge

The JDBC-ODBC bridge, is a database driver implementation that employs the ODBC driver

to connect to the database. The driver converts JDBC method calls into ODBC function calls.

The driver is platform-dependent as it makes use of ODBC which in turn depends on native

libraries of the underlying operating system the JVM is running upon. Also, use of this driver

leads to other installation dependencies; for example, ODBC must be installed on the

computer having the driver and the database must support an ODBC driver. The use of this



driver is discouraged if the alternative of a pure-Java driver is available. The other implication

is that any application using a type 1 driver is non-portable given the binding between the

driver and platform. This technology isn't suitable for a high-transaction environment. Type 1

drivers also don't support the complete Java command set and are limited by the functionality

of the ODBC driver.

Figure 2.2:JDBC_ODBC Driver

Functions

Translates query obtained by JDBC into corresponding ODBC query, which is then

handled by the ODBC driver.

Sun provides a JDBC-ODBC Bridge driver. sun.jdbc.odbc.JdbcOdbcDriver. This

driver is native code and not Java, and is closed source.

Client -> JDBC Driver -> ODBC Driver -> Database

There is some overhead associated with the translation work to go from JDBC to

ODBC.



Advantages

Almost any database for which ODBC driver is installed, can be accessed.

A JDBD-ODBC driver is easy to install.

2.4 Introduction to SQL Server 2008

Microsoft SQL Server 2008 is a family of products that meet the data storage requirements of

the largest data processing systems and commercial Web sites, yet at the same time can

provide easy-to-use data storage services to an individual or small business.

Figure 2.2 SQL Server Environment

The data storage needs of a modern corporation or government organization are very complex.

Some examples are:

Online Transaction Processing (OLTP) systems must be capable of handling thousands of

orders placed at the same time.

Increasing numbers of corporations are implementing large Web sites as a mechanism for

their customers to enter orders, contact the service department, get information about

products, and for many other tasks that previously required contact with employees. These

sites require data storage that is secure, yet tightly integrated with the Web.



Organizations are implementing off-the-shelf software packages for critical services such

as human resources planning, manufacturing resources planning, and inventory control. These

systems require databases capable of storing large amounts of data and supporting large

numbers of users.

Independent Software Vendors (ISVs) must be able to distribute data storage capabilities

with applications targeted at individuals or small workgroups. This means the data storage

mechanism must be transparent to the users who purchase the application. This requires a data

storage system that can be configured by the application, and then tune itself automatically so

that the users do not need to dedicate database administrators to constantly monitor and tune

the application.

2.4.1 Database Architecture

Microsoft SQL Server 2008 data is stored in databases. The data in a database is organized

into the logical components visible to users. A database is also physically implemented as two

or more files on disk.

When using a database, you work primarily with the logical components such as tables, views,

procedures, and users. The physical implementation of files is largely transparent. Typically,

only the database administrator needs to work with the physical implementation.

Each instance of SQL Server has four system databases (master, model, tempdb, and msdb)

and one or more user databases. Some organizations have only one user database, containing

all the data for their organization.

Some organizations have different databases for each group in their organization, and

sometimes a database used by a single application. For example, an organization could have

one database for sales, one for payroll, one for a document management application, and so

on. Sometimes an application uses only one database; other applications may access several

databases.

It is not necessary to run multiple copies of the SQL Server database engine to allow multiple

users to access the databases on a server. An instance of the SQL Server Standard or



Enterprise Edition is capable of handling thousands of users working in multiple databases at

the same time. Each instance of SQL Server makes all databases in the instance available to

all users that connect to the instance, subject to the defined security permissions.

When connecting to an instance of SQL Server, your connection is associated with a

particular database on the server. This database is called the current database. You are usually

connected to a database defined as your default database by the system administrator,

although you can use connection

options in the database APIs to specify another database. You can switch from one database to

another using either the Transact-SQL USE database name statement, or an API function

that changes your current database context.

SQL Server 2008 allows you to detach databases from an instance of SQL Server, then

reattach them to another instance, or even attach the database back to the same instance. If you

have a SQL Server database file, you can tell SQL Server when you connect to attach that

database file with a specific database name.

3. Software Requirement Specification

Software Requirement Specifications is the starting point of the software development

activity. It allows the developer/analyst to understand the system, functions to be carried out,

performance levels to be maintained and corresponding interfaces to be established.

Software requirement specification is the medium through which the client and the user needs

are accurately specified. An SRS convey information about the application’s requirements,

both functional and nonfunctional.

3.1 Purpose

The purpose of HL7 Integration is to develop an Outbound Interface from a Laboratory

Information System(Vitalaxis) to Electronic Medical Record System(NextGen).



3.2 Scope

The Result Outbound integration would help laboratories to send the result for the cases

in LIS to hospital’s EMR system. A result hl7 file and the PDF report would be sent to EMR

system.

The DFT outbound integration intends to help laboratories send out the billing information to

the Ordering facility in order to create charge transactions. Billing information would be in

hl7 file format.

3.3 Functional Requirement

Functional requirement for Result Outbound

Laboratory Information system (LIS) should have a background job that insert’s every new case into database with proper caseid and status=’new’.

HL7 integration framework retrieves all the information related to that case from the database in the form of an XML

Create a ORU^R01 (Observation Result) message using dedicated mirth channel.

The successful creation of HL7 file should update the status to ‘generated’.

Generated HL7 file and the related pdf is uploaded into specified EMR system.

Functional requirement for DFT Outbound

Medical assistant at ordering facility enters the patient’s, case information into the specified EMR system. The system generates a unique id for each patient (#account No) and orders the case to specified LIS.

Case is assigned to a proper pathologist and the pathologist performs diagnosis and will sign-out the case. When a case is signed-out, a job running in the background populates the database.

The Claims table gets populated with the values for Financial Transactions carried out or as mentioned by the Pathologist.

The pathologist, once done with the Diagnosis, would charge for the tests conducted at the laboratory. The financial transaction details would be updated under FT1 segment of the HL7 file and is sent to the Ordering facility.



Create a DFT^P03 (Detailed Financial Transaction) message using dedicated mirth channel.

Generated HL7 file is uploaded into specified EMR system.

3.4 Non-Functional Requirements

Reliability

Reliability is the correlation of an item, scale, or instrument with a hypothetical one,

which truly measures what it is supposed to. Since the true instrument is not available, the

program according to the requirement can perform the intended function

Backup option for backing up the database etc.

Error-handling-exception occurring while accessing database need to be addressed

Usability

Usability refers to the capability of the product to be understood, learned, and used. It

must be user friendly, when used under specified conditions. This section should include all of

those requirements that affect usability. Specify the required training time for a normal users

and a power user to become productive at particular operations.

Maintainability

Maintainability is the ease with which a program / specification can be corrected if an

error occurs desires a change in requirements. Specify attributes of software that relate to the

ease of maintenance of the software itself.

Performance

Performance is measured in terms of the output provided by the application. Requirement

specification plays an important part in the analysis of a system. Only when the requirement

specifications are properly given, it is possible to design a system, which will fit into required

environment. The requirement specification for any system can be broadly stated as given

below:



The system should be able to interface with the existing system.

The system should be accurate.

3.5 Requirements for Result Outbound

3.5.1 Introduction

The software (Theranostics Lab Results Application) that is outlined in these specifications will enable

the NextGen Electronic Medical Records (EMR) System to receive lab results from an external lab

system via the HL7 communications standard. Rosetta lab results interface application is based on the

2.3 version of the HL7 Standard.

Both systems will execute concurrently and continually, exchanging information when entered by the

computer operator.

3.5.2 Operational Concerns

Using TCP/IP protocol to exchange information.

The systems will transfer information through TCP/IP with Minimal Lower Level Protocol (MLLP).

The format is based on HL7 version 2.3.

Using files to exchange information.

The systems will transfer information through ASCII files.

Two directories will exist, one directory for each direction of the transfer.

Each system will poll the retrieval directory for new data files to load into the system.

Each system will name the transfer files with a unique name.

Transfer file names will begin with a letter followed by a sequential number that is right justified

to seven digits and zero filled.

Files will be imported into the database on a first-in first-out order.

A new line character will terminate each record.

Message Segment Layouts

Sequence This is the order in which the fields should be sent to/from the external system.



Max Size Although HL7 allows for variable length fields within each record type, this column represents the maximum length for each data element as set in the HL7 manual. This is the size that is guaranteed to be placed in NextGen® records in its entirety. If there are sizes indicated for sub-components, it means that each sub-component is placed in a separate column in the database. If there is only one value for the maximum size for the composite field, it means that the entire composite field is placed in a single column in the NextGen® database (the field is not parsed). If the maximum sizes are provided for certain sub-components of the composite field only, it means that only these sub-components are saved in the NextGen® database.

REQUIRED If this column contains the value of “R”, then this field is required by Rosetta (always sent). If this column contains the value of “C”, then this field is sent conditionally, depending on value in some other field. If this column contains the value of “O”, then this field is optional.

REPEATS Contains the maximum number of times the field can be repeated. If this field is left blank, there are no repeats.

DATA TYPE Contains an HL7 data type that is used for this field.

DESCRIPTIO

N

This column contains the name of the data element to be sent or received in this field and, if applicable, its sub-components.

COMMENT Contains additional information about the field. If the comment has the text in quotation marks, then the corresponding field will contain exactly this text, or, in case of multiple texts, one of them as it appears inside quotation marks. For example, “MSH” in the comment column means that this field will always contain the following value: MSH

Table 3.1 Segment Layout

When a field is completely shaded, this indicates that NO data will be expected or sent in this

field. The receipt of data in this field by Rosetta will be discarded. The HL7 Segments

outlined below contain all of the fields in the HL7 specification. Many fields are not used by

NextGen® or Vital axis and are therefore ignored.


Notation:

[ ]

Optional elements

{ }

Repeating elements


Message Format:

HL7 ORU Transmission of Lab Observation Message HL7 ORU messages will be received by the Theranostics Lab Results Application either via TCP/IP

communication or whenever a batch file containing lab results is placed in the input directory.

NextGen Healthcare must be informed whether the lab intends to send lab results via TCP/IP or

through batch files in order to install the appropriate version of the Vital Axis software at the client

site.

Segments listed in the table below are the only ones that are processed by Theranostics lab.

Grayed out fields are received by Theranostics, but not processed. Always optional. Segment Name Require

d

MSH

Message Header Yes

[{EVN}] Event Type

[{NTE}] Notes and Comments (Header specific)

{

PID Patient Identification Yes

[PD1] Additional Demographics

[{NTE}] Comments (Patient specific)

PV1 Patient Visit

[{NTE}] Comments (for Patient Visit)

{

[ORC] Common Order



[{NTE}] Notes and Comments (for Common Order)

{

OBR Order Request Yes

[{NTE}] Notes and Comments (for Order Request)

{

[{OBX}] Observation/Result

[{NTE}] Notes and Comments (for Observation/Result)

}

[ZPS] Place of Service Facility Information

}

}

}

[{DSP}] Display Segment (handled conditionally)

[BTS] Batch Trailer Segment

[FTS] File Trailer Segment

Table 3.1: Result OutBound Segments Format

4. Hardware and Software Specification

4.1 hardware Requirements

Processor : Pentium 4

RAM : 1 GB

Hard Disk : 40 GB



4.2 Software Requirement

Platform : Windows 98/2000/XP

Languages : Java 1.6

Interface Engine : Mirth

Database : MS-SQL Server

Environment : Eclipse & MS-SQL Server 2008

5. System Definition

5.1 Existing System

Paper Based Record

The existing system requires personally carrying paper medical records from laboratory to

hospital.

Disadvantages of paper based record are:



Using paper medical records increases the risk of grammar errors, improper data entry

and other record inaccuracies.

Paper also requires physical storage, which could be a costly expense for businesses.

Productivity decreases because paper records are often unavailable, important

information may not be written on them, or the handwriting of a health professional may not

be legible.

Information in paper records are often duplicated, either by health professionals from

different departments because of the luck of concordance among specialists, or during the

time spans in the same department.

5.2 Proposed System

Proposed system is providing an interface between Theranostics laboratory (VitalAxis, a LIS) and Mid

Atlantic Urology Associates (NextGen, a EMR) using HL7 protocol

The typical clinical facility or hospital has several HL7 enabled applications and devices. To reduce

data entry time and increase overall efficiency of the facility, these applications or devices need to

communicate with each other.

This can be accomplished by:

Using an interface engine that is placed between all the applications to aid in information exchange

and monitoring.

A HL7 interface engine is an interface or integration engine built specifically for the

healthcare industry. It connects legacy systems by using a standard messaging protocol.

Because hospitals and other healthcare providers usually have different systems for different

aspects of services, they are often unable to communicate with each other. HL7 gets around

that problem by providing the framework for the exchange, integration, sharing and retrieval

of electronic health information. These standards are most commonly used throughout the

world.

Advantages Of Proposed System:

Effortless: Complete and fully functional HL7 interfaces can be configured within hours.

Using an interface engine translates into huge savings in both time and costs.



Easy to Use: An HL7 interface engine minimizes the internal work required to establish and

maintain HL7 communication channels.

Electronic medical files are readily transferable from one doctor or hospital to another.

Electronic filing also eliminates the physical space needed to retain patient records and

facilitates more accurate documentation of medical files.

HL7 interface engine provides more control and saves time and money in a clinical or

healthcare environment

The following figure shows workflow diagrams for interface engine model:

Figure 5.1: Workflow of Interface Engine

6. Detailed Design

System design describes overall architecture of the system. It guides the design process and

provides details about how to translate functional requirement of the user into design

specification. This phase is a transition from the user’s perspective of the system to the

developer’s viewpoint. System definition helps in developing a logical design of the system.

The design phase is with the requirement specification for the software to be developed.

Design is the first step to moving from the problem domain towards the solution domain.



Design is essentially the bridge between requirements. It is the most critical factor affecting

the quality of the software.

In detailed design the interconnection of the modules or how the specification of the modules

can be satisfied is decided. Some properties for a software system design are:

Verifiability

Completeness

Consistency

Traceability

Simplicity

The following guidelines were taken into account while designing the system:

A design should exhibit hierarchical organization that makes intelligent use of control

among the components of the software.

A design should be modular i.e., that software should be logically partitioned into

components that perform specific function and sub function.

A design should contain distinct and separable representation of data and procedure.

A design should lead to interface that reduces the complexity of connections between and

modules and with the external environment.

6.1 Data Flow Analysis

As information moves through software, it is modified by a series of transformations.

Data flow Diagrams is a graphical technique that depicts the information flow and transforms

that are applied as data move from input to output. The data flow diagram may be used to

represent a system or software at any level of abstraction. In fact, DFD may be partitioned

into different levels that represent increasing information flow and functional detail. A

functional DFD also called a Context Model which represents the entire software element as

a single bubble with input and output data indicated by incoming and outgoing arrows



respectively. Additional processes and information flow paths are represented in different

levels.

DFD for HL7 Integration

Level-1

Laborotary Information system(LIS)

HL7 Database

Mirth

populates

Sending process

Electronic Medical

Record(EMR)

uploads it to

Figure 6.1: DFD for HL7 Integration.

DFD of HL7 Integration From VitalAxis to NextGen

Level -2



Mirth

Pre-configured LocationVitalAxis

Distridution Framework

PathologistSigns out

populates

HL7Integartionlog Table

Creates HL7 file

W700 Framework

Gets data

Local Folder

Places HL7 file

Figure 6.2.:Level 2-Data Flow Diagram

The MAUA Medical Assisstant (MA) would requisition a case and order the case to Theranostix (THX).

The THX Lab Technician would accession that case and perform grossing and processing for that case. The Pathologist would SignOut that case Or correct the Signed-Out case.

The distribution framework would populate the hl7IntegrationLog table for this signedOut case with the status = 'New' and the handler = 'THX_VA-MAUA_NextGen-Results_Outbound' and direction = 'Out Bound'

The dedicated VA-Mirth channel (THX_VA-MAUA_NextGen-Results_Outbound) would generate the result hl7 file and place that hl7 file along with the PDF report in a pre-configured location.

DFD of Interface Engine



Mirth

Billing

HIS

EHR

Labarotary

EMR

RIS

Charges/ADT

Lab Results/charges

ADT

ADT/ORU/DFT

Charges/Result ORU

ADT

ORU/Charges

ADTORU

Figure 6.3: DFD of Mirth

Example workflow: The workflow of an example small acute care setting is shown in the following table:

Information Type Workflow

Demographics Entered in registration system and sent to all ancillary systems.

Orders Lab – Orders entered on order entry system (EMR/HIS) and ORM messages delivered electronically to both systems. An order response is sent from the Lab back to EMR/HIS.

Radiology – Entered on HIS but printed and re-entered into radiology. Once typed into radiology an electronic confirmation is sent to the HIS.

Results Lab – Sent to EMR System/HIS

6.2 Database Design



Database designing is all about designing the tables with the required fields, data type and

proper relationship between them. Database schema describes the physical structure of the

database. That is, it gives details of all the tables that form the database of the application. The

tables that form SPINeeds database are login and request tables.

6.2.1 Cases Table

Table 6.1:Design of Cases Table

Cases Table stores details of case like casetype, extraction procedure used to extract the

specimen, number of specimens collected and etc.

6.2.2 Patients Table



Table 6.2:Design of Patients table

Patients table stores patient information like name of the patient, address, responsible person

name, insurance policy number and etc.

6.2.3 Diagnosis Table



Table 6.3:Design Diagnosis Table

Diagnosis table contains diagnosis details like summary, final icd9 codes and etc.

6.2.4 HL7IntegrationLog Table



HL7IntegrationLog is monitored by mirth, whenever a case is inserted with status as ‘new’

mirth pick up related caseid and logid. Case, patients and diagnosis details are retrieved using

the caseid.

Cases, patients and diagnosis are primary table from which details related to patient’s case are

retrieved. There are many other tables, namely specimens, test, case assignments, casetype,

organization, accounts, user, userroles, varules, VAintevent, hl7IntegartionMaster, etc, which

are used to create HL7 files.



7. SYSTEM IMPLEMENTATION

Implementation is the stage of the project where the theoretical design is turned into working

system. At this stage the main work load, the greatest upheaval and the major impact on the

existing system shifts to the customer department. If the implementation is not carefully

planned a controlled it can cause chaos and confusion.

Implementation includes all those activities that take place to convert from the old system to

the new one. The new system may be totally new, replacing an existing manual or automated

system or it may be a major modification to an existing system. Proper implementation is

essential to provide a reliable system to meet the organization requirements. Successful

implementation may not guarantee improvement in the organization using the new system, but

improper installation will prevent it.

Implementation Procedures

Implementation of software refers to the final installation of the package in its real

environment, to the satisfaction of the intended users and the operation of the system. In many

organizations some one who will not be operating it, will commission the software

development project. The people are unaware that the software is meant to make their job

easier. In the initial stage, they doubt about the software but we have to ensure that the

resistance does not build up as one has to make sure that

- The active user must be aware of the benefits of using the system

- Their confidence in the software is built up

- Proper guidance is imparted to the user so that he is comfortable in using the

application.

User Training

To achieve the objectives and benefits expected from computer based system, it is essential

for the people who will be involved to be confident of their role in the new system. As

systems become more complex, the need for education and training is more and more

important.



Operational Documentation

Once the implementation plan is decided, it is essential that the user of the system is

made familiar and comfortable with the environment. Education involves right atmosphere &

motivating the user. A documentation providing the whole operations of the system is being

developed.

Points to consider while implementing HL7 Integration

1. HL7 Interfaces are not plug and play

Unfortunately the HL7 V2 standard is interpreted in different ways by implementers and

software developers. The outcome is two similar but not exactly matching interfaces that

require analysis in order to identify the differences.

2. Translation of HL7 messages

Once the differences have been identified, the messages from one application needs to

modified before they can be processed by the other application. Some translations may be

relatively simple, such as moving a particular field from one place in the message to another.

For example the sending system may place an insurance number in the insurance segment

(IN1). However another vendor may not support that segment and instead expects the

insurance number to be placed in the patient identification segment (PID) or perhaps in a

proprietary segment.

3.Code table mismatching

HL7 messages are littered with coded data. For example the martial status field contains a

coded value such as ‘M’ for Married, ‘D’ for divorced and so on. However the receiving

system may expect ‘1’ for married and ‘2’ for divorced.

4.HL7 PID Identifier List

The patient identification segment has three fields dedicated to identifiers. PID-2 Patient ID

(external ID), PID-3 Patient ID (internal ID) and PID-4 Alternative Patient ID. The

recommended use of these fields has changed with successive revisions of HL7 ( HL7 V2.1,

HL7 V2.2, HL7 V2.3, HL7 V2.3.1, HL7 V2.4). Different vendors have interpreted these

fields differently. Almost everyone puts the patient’s medical record number (MRN) in PID-3.



5. Repeating segments

Segments that repeat, such as Observation segment(OBX) depends on the number of

specimens sent for diagnosis.

Repeating segment such as ‘Next of Kin’ (NK1) also pose similar challenges to repeating

fields.

Different systems support different numbers of repeats. For example the sending system

may support 7 patient contacts (sent as 7 NK1 segments) and the receiving system may

support only 2.

The sending system may add, update or delete the repeating field. Deleting a field can

cause headaches for the downstream system. Sometimes this is overcome by the downstream

system replacing the entire set of repeating fields each time.



8. Testing

8.1 HL7 Interface Testing

HL7 interface testing is part of the overall HL7 interface planning process, which includes

HL7 interface analysis, HL7 interface requirements, HL7 interface specification, and HL7

interface testing.

HL7 interface testing is linked to other project testing activities and typically includes:

HL7 interface unit testing - typically interface specification based aiming to confirm that

HL7 messages sent and/or received from each application conform to the HL7 interface

specification.

HL7 interface integration testing - testing of business scenarios to ensure that information

is able to flow correctly between applications.

HL7 interface system testing - end-to-end scenario testing focused on ensuring all

relevant modules of all relevant applications are able to integrate correctly.

Other testing such as additional application functional testing and end user acceptance

testing would typically follow interface testing.

8.2 Test cases

Test cases for ORU

Positive Test cases

1.HL7 and PDF files should be copied to the pre-configured local file system

2. HL7 file should be generated at the pre-configured location.

2. PDF Report file should be generated and stored at the pre-configured location.

4. Hl7Integration log table should be updated with summary =New Hl7 file: generated and

uploaded successfully.' and status='Uploaded'



Negative Test cases

1. HL7 file should not be generated.

2. PDF report file should not be generated.

3. Hl7Integration log table should be updated with summary =' Failed to generate Hl7File.'

and status='Failed'

Test cases for DFT

Positive Test cases

1. DFT HL7 file should be generated at the pre-configured location.

2. The DFT HL7 files should be copied to the pre-configured local file system

3. Claims table should be populated with all the relevant billing details.

4. Hl7Integration log table should be updated with Summary ='New DFT Hl7 file: generated.'

and status='Uploaded'

Negative Test cases

1. HL7 file should not be generated.

2. Hl7Integration log table should be updated with Summary =' Failed to generate Hl7File.'

and status='Failed'



9. Conclusion and Future Enhancement

9.1 Conclusion

A HL7 interface has been developed and implemented successfully. HL7 interfaces are

running successfully between Theranostics laboratory (VitalAxis LIS) and Mid Atlantic

Urology Associates (NextGen EMR).

The main objective of the HL7 Integration is to generate HL7 file along PDF report. Once

case is created and pathologist sign out then data will save in the database, then mirth will

pick the data through source and generates result set in form of XML. Using this result set

mirth destination will generates an HL7 message along with PDF report and place it specified

directory.

By using a HL7 interface engine, Theranostix laboratory can realize the benefits of existing

legacy information systems without major re-investment in new technologies, lowering costs

and extending the life and efficiencies of current systems. There is also opportunity to link to

systems outside the healthcare provider such as providers of outsourced services like

radiology

HL7 interface engines are software, which works as a go-between for different systems. They

monitor different types of interfaces and communication points and perform actions according

to rules defined by the organization.

HL7 works with a number of standards (Conceptual Standards, Document Standards,

Application Standards and Messaging Standards). Messaging standards define how

information is packaged and communicated from one system to another

The Mirth Interface Engine is a simple and effective solution to the problems of healthcare

interoperability. The unique design of the Mirth HL7 Interface Engine allows for seamless

routing and transforming of HL7 data with minimal setup required.

The Mirth HL7 Interface Engine has been designed to make it exceptionally easy to configure

and maintain HL7 interfaces.



9.2 Future Enhancement

Currently HL7 version 2, which supports hospital workflows, is being used. HL7 version 3,

which supports any and all healthcare workflows, can be used.

Key differences between HL7 V2 and HL7 V3 are

HL7 V2

Not “Plug and Play” – it provides 80 percent of the interface and a framework to

negotiate the remaining 20 percent on an interface-by-interface basis

Historically built in an ad hoc way because no other standard existed at the time

Generally provides compatibility between 2.X versions

Messaging-based standard built upon pipe and hat encoding

HL7 V3

Approaching “Plug and Play” – less of a “framework for negotiation”

Many decades of effort over ten year period reflecting “best and brightest” thinking

NOT backward compatible with V2

Model-based standard built upon Reference Information Model (RIM) provides

consistency across entire standard



10. Screen Shots

10.1 Login Page

Figure 10.1:Mirth Login page

This page is used to login.



10.2 Channel

Figure 10.2: Channel

The Channels View is where channels are created, modified, deleted, and deployed.



10.3 Summary

Figure 10.3:Summary

Summary page is used to entry basic information about the channel like name, incoming data format and initial status of the channel.



10.4 Source Connector

Figure 10.3 Source –Database Reader

Source connector is used to configure database. By selecting connector type as database reader we can specify the driver using which data can be retrieved from the database. Using Javascript database configuration is done.



10.5 Source Transformer

Figure 10.4 Source Transformer

Source transformer is used maps values to variable which can be used in destination connector.



10.6 Destination Connector

Figure 10.4: Destination-File Writer

A File Writer connector writes messages to files located on the machine running the Mirth

server.



10.7 Destination Transformer-ORU

Figure 10.7: ORU Destination Transformer

ORU transformer processes the incoming XML data and creates an HL7 file and places HL7 file in the pre-configured location. .



10.8 Destination Transformer –Updater

Figure 10.8: Updater

HL7 IntegrationLog Updater transformer update the Log table in the database with status field

set to ‘Success’ and processingnotes to Hl7 and pfd files generated.



10.9 DashBoard

Figure 10.2: DashBoard

When the channels are deployed, the status of the channels is shown in dashboard. Dashboard

is used to monitor the channels. Deployed channels status is started. Started channels create

HL7 files and deploy the files in pre-defined location.



10.10 Result Outbound

HL7 Message:

MSH|^~\&|VitalAxis|Theranostix|NextGen|MAUA|201006021147||ORU^R01|7|T|.5||Report_7.pdf|AL

PID|1|205320|||Robert^Wadra^T||19901010|M|||8401 GARLAND AVE^^Takoma Park^MD^20912||301-585-2292|464-45-9748|||||

OBR|1||THS10-00001|THS10-00001^Bladder Biopsy^VitalAxis|||20100601000000|||||||20100602000000|^^^^^Forcep Biopsy|^Melograna^Frank^S|||||||||F

OBX|1|ST|1^Urachus^VitalAxis||Urothelial mucosa without significant histopathologic abnormalities.||||||F

OBX|2|ST|2^Posterior Wall^VitalAxis||Follicular cystitis.||||||F

OBX|3|ST|3^Right Ureteral Orifice^VitalAxis||Chronically inflamed and denuded urothelium||||||F

OBX|4|ST|4^Left Ureteral Orifice^VitalAxis||Urothelial atypia, can not exclude a dysplastic or neoplastic disorder.||||||F

OBX|5|ST|5^Bladder Neck^VitalAxis||Urothelial papilloma.||||||F



PDF Report

Figure 10.8 PDF Report



10.11 DFT Outbound

HL7 Message:

MSH|^~\&|VitalAxis|MDE|NJU|MDE|200912070922||DFT^P03|237037|T|2.3|||AL

EVN|P03|20091207212256

PID|1|135664|PS0900062|3412|Test^Test^Test||19831227|F|||Addr1Âddr2^Detroit^MI^48201|TC - Breast Histology|||||200912071200||2367237623

PV1|||ABCDE1223||||^Physician^Test

OBX|1|TX|90^^BENIGN. NEGATIVE FOR INVASIVE CARCINOMA.|1|BENIGN. NEGATIVE FOR INVASIVE CARCINOMA.||||||F|||||UNKNOWN^Path^Test

OBX|2|TX|91^^BENIGN BREAST TISSUE SHOWING FIBROCYSTIC CHANGES, NEGATIVE FOR ATYPIA OR MALIGNANCY.|2|BENIGN BREAST TISSUE SHOWING FIBROCYSTIC CHANGES, NEGATIVE FOR ATYPIA OR MALIGNANCY.||||||F|||||UNKNOWN^Path^Test

OBX|3|TX|233^ÂTYPICAL LOBULAR HYPERPLASIA, NEGATIVE FOR MALIGNANCY.|3|ATYPICAL LOBULAR HYPERPLASIA, NEGATIVE FOR MALIGNANCY.||||||F|||||UNKNOWN^Path^Test

OBX|4|TX|90^^BENIGN BREAST TISSUE WITH MASTITIS IDENTIFIED. MASTITIS IS AN INFECTION COMMONLY CAUSED BY BACTERIA FOUND ON NORMAL SKIN.|4|BENIGN BREAST TISSUE WITH MASTITIS IDENTIFIED. MASTITIS IS AN INFECTION COMMONLY CAUSED BY BACTERIA FOUND ON NORMAL SKIN.||||||F|||||UNKNOWN^Path^Test

OBX|5|TX|91^^POSITIVE FOR ADENOCARCINOMA.|5|POSITIVE FOR ADENOCARCINOMA.||||||F|||||UNKNOWN^Path^Test

FT1|1|||200912061200||D|88305PC|||5|||||||||1;2;3;4|UNKNOWN^Path^Test|UNKNOWN^Physician^Test||200912061200||88305PC

FT1|2|||200912061200||D|88342PC|||2|||||||||1;2;3;4|UNKNOWN^Path^Test|UNKNOWN^Physician^Test||200912061200||88342PC

GT1|1||Last^First^Middle||Addr1Âddr2^Detroit^MI^48201|^^^^^ûndefined|||||

IN1|1||Default Payer^^^^^-100|Default Payer|^^^^|||56434||||||||Test^Test^Test|Self||^^^^|||P||||||||||||||

IN1|2||Default Payer^^^^^-100|Default Payer|^^^^|||2123||||||||Last^First^|Life Partner||^^^^|||S||||||||||||||5333

IN1|3||Default Payer^^^^^-100|Default Payer|^^^^|||53223||||||||Test^Test^Test|Self||^^^^|||T||||||||||||||



11. Bibliography

Book References:

Pressman, Roger S. "Software Engineering: A Practitioner's Approach”, 6th edition.

Herbert Schildt “The Complete Reference” Seventh Edition

Ramez Elmasri, Shamkant B. Navathe “Fundamentals of Database Systems”, 2nd Edition.

Cliff Wootton “JavaScript Programmer's Reference” 2001

Website References:

http://www.corepointhealth.com/services/implementation

http://www.hl7.org

http://www.neotool.com/resources/HL7-Overview

http://en.wikipedia.org/wiki/Health_Level_7

www.google.com

www.mirthcorp.com


New Microsoft Office Word Document

Documents

Transcript of New Microsoft Office Word Document