Hands-on Workshop

HL7 Version 2.x Implementation Tools

An object oriented HL7 Framework

Andrew McIntyre & Jared Davison

Medical Objects
http://www.medical-objects.com.au/

9th HL7 Australia Conference, 9th November 2005

Sydney, Australia

In the beginning
There was paper
There was PIT
Idea of a PIT distribution network
Envisaged in 1997
Full PIT support developed at that time
Data format considered inadequate for storing
endoscopy data
We discovered HL7 during research of more rich data
formats available
Joined HL7 USA as an individual member early 1998
Started understanding the HL7 v2 specifications
Been on a loop to provide full support for HL7 since

In the beginning
Researched available toolkits for HL7 v2 &
DICOM during May 1998
Largely the cost (particularly royalties) made it
impossible to write systems for specialists & GPs
Decision made to write a HL7 processing
framework
The development effort has had full time staff
members since 1998
Development has been ramped up since wide
availability of fast internet connectivity & open
source SQL servers

Initial barriers
Communications infrastructure
Solved by wide spread internet availability
(broadband speeds a BIG plus)

SQL database servers

Initially considered essential but too expensive
for specialists (1997)
Problem solved by availability of OpenSource
Transactional SQL 3 servers

Encryption
Initially technology was not generally available
however this is not the case now

Initial barriers
Messaging platform
Standardisation of HTTP has solved this

Lack of any Australian examples

Pathology in HL7 format became available in
Sept 2001 from QML
FHS|^~\&|PRSLT|NATA^2184^N|PRSLT|hl7_am27|
20010720094242||qm016082.oru||1|

Development style
Development style

Test driven
Agile
Continuous integration
Highly object orientated
Design patterns
Object Pascal & Java

Tools have been in use in Buderim Gastroenterology

Centre since 2001
HL7 result delivery has been occurring since 2002
Entire Sunshine Coast is a permanent trial site and test bed
for new features & developments
Now have users from as far North as PNG, south to
Geelong, west to Esperance WA (as part of DoHA Eastern
Goldfields Regional Reference project)

Parsing HL7
HL7 messages are parsed into a tree
Read by message objects which are
flyweights
HL7 parsing rules are respected
This allows significant HL7 version
mismatch resolution
Currently the framework is at HL7 v2.3.1
HL7 is easily downgraded if needed

HL7 Abstraction
All HL7 data types appear as native data
types
All access is via interfaces
Automatic memory management
Code generation used above data type
level
All higher level methods operate on the
interfaces
Development is totally isolated from
encoding of HL7

HL7 CE data type

Objects are aggregated

OBX data type

HL7 v2 is Object Oriented!

Framework fully supports the HL7 v2 Information Model
HL7 v2 information model predates UML modelling
techniques, however, refined & proven via real use
We have adopted the HL7 v2 Information Model as the
native framework model
why?

because HL7 is used in real world systems

HL7 v2 is mature
adopting HL7 model reduces impedance to interoperability
Can be extended via standards process to fill in gaps
Internally linkage can be enhanced as needed

HL7 Code Generation

HL7 Application Server Architecture

HTTP

SMTP

S/MIME

Pluggable Transport Layer

PKCS#7 HeSA PKI

GnuPG

Pluggable Encryption Layer

LLP

PGP

LDAP

Authentication / Access Control

Asynchronous

Proxy

Message Processing

Lab Specific

PMS Specific

Interface Engine Layer (In & Out)

MFQ

Pluggable Message Processors

Fine grain access control

Synchronous
HL7/XML
ORU^R01

PIT

QRY^R02

HL7 file based

SQL Server*
* May be supported in future

ORM^O01

Firebird SQL

Etc..

Oracle*

Picture Archival

(Public Key Authentication)

Pluggable Persistence Layer

Server handling of messages

Machinery delivers incoming interface to be
processed and provides the mechanism to
return a response
Message processors can be plugged into the
framework to create specialised services

Security is handled entirely by the use of

Public Key Authentication & Encryption
Abstraction enables different message
storage mechanisms
SQL server
offline HL7 File based storage

Server message processing

Client Application Architecture

Presentation

Persistence

HL7

PIT

RTF

DICOM

JPEG

HTML

Archetypes

SNOMED-CT

HL7/XML

PIT

ORU^R01

QRY^R02

PGP
HTTP

ORM^O01

PKCS#7 HeSA PKI

SMTP

PIT

Offline Index

LOINC

Lab Specific

LLP

HL7

Presentation or Persistence Layers

HL7 Model

PMS Specific
MFQ

Etc..

HL7 Modelling Layer

Interface Engine Layer
Specific Message Processing

GnuPG

Encryption Layer

S/MIME

Transport Layer

Client Application Development

Hierarchic Designator (IHL7HD)

The namespace ID and the combination of universal ID

and universal ID type should be equivalent in meaning
Used in the framework to identify practices and
institutions, or units within hospitals
Currently we use GUIDs as universal ID type, but OIDs
(assigned by HL7 Australia) are a potential option in the
future.

HDs & Routing

Server routing report

Putting it all together

LOINC support

ICD-10AM support

SNOMED-CT support

SNOMED-CT Query

SNOMED-CT Canonical Forms

To leverage the full power of SNOMED-CT terminology services that make
concepts computable are required. The Medical Objects framework provides
internet terminology services using HL7 Master Files messages as transport.
Medical Objects also provides full LOINC, ICD-10AM, and MBS support using
real-time HL7 master files messaging services

HL7 Word Processor

The word processor is HL7 data field aware. Set up templates and populate them
directly from HL7 messages.

Blood Pressure Archetype

Meta data in the form of Archetypes potentially enrich HL7 v2.x to remove
any limits on semantic interoperability.
Archetypes & Terminology overlap in applicability but are complimentary

Service Oriented Architecture (N-tier)

Early in development, a decision was made to use HL7 as
the only protocol/middle-ware between client and server
This means that messaging is a core component of the
framework and has had extensive real world use.
It is real time messaging
Messages are processed by an application server which
may be quite remote
Database access is abstracted currently using
FirebirdSQL/Interbase
Service oriented message processing
A particular message may be delegated for processing by another
HL7 processing service eg. Provider directory, routing,
terminology services, registration
This is invisible to the client

We achieved compliance
Medical Objects was the first messaging
service and organization in Australia to
receive Australian Standards AS4700.2
HL7 v2.3.1 certification, awarded by the
National Association of Testing Authorities
(NATA) approved Australian Healthcare
Messaging Laboratory (AHML).
Both our Orders & Results are compliant
To date Medical Objects are the only
organisation to have completed
certification.

AHML Compliance Integration

Sending GP referrals
GP referrals
Captured from clinical
practice software
Digitally signed HESA PKI
USB key
Encrypted with PKI
certificates
Encrypted provider lookup
Zero configuration install

Referrals are delivered

real-time

Open Spec - Inline Signature

Digital
Signature
Block
Open Specification: http://download.medical-objects.com.au/docs/api/MO-Signature-v2.zip

Medical Objects Explorer

Combined results analysis showing adverse drug reaction

Liver Function Tests

Capsule Endoscopy

HL7 Orders

Provider directory
HL7 2.3 Master files
Defines messages for maintenance & query for
providers using the STF segment
CH 8.3.3 MFQ/MFR (Master Files Query/Response)

MFQ/MFR

HL7 for Mere Mortals

HL7 Master Files Query

HL7 Filter
Using the framework to bring existing non-compliant messages up to HL7 2.3.1.
Improving the quality of the terminology coding

HL7 Filter Configuration

Magellan

Eclipse

Word Plugin

HL7 Visualiser
Designed for trusted
message set
Part of Standards
Australia work for
IT-14-6-5

HL7 is a messaging environment

HL7 predates Web Services and many of the commercial
messaging environments
There is no need to wrap HL7 inside another messaging
environments as it is already richer than services such as
SOAP/WSDL
The combination of compliant HL7 encryption and digital
signatures along with a URL or email address is all that is
required. (Assuming the HL7 is processed!)
Open Specification: http://download.medical-objects.com.au/docs/api/MO-Connect.txt

Open standards are essential to avoid vendor lock in and

to enable interoperability
Use of HL7 as messaging environment ensures the
messages can be read at the destination

Medical Objects Network Today

www.medical-objects.com.au