An object oriented HL7 Framework

Hands-on WorkshopHL7 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 2005Sydney, Australia

In the beginningThere was paperThere was PITIdea of a PIT distribution networkEnvisaged in 1997Full PIT support developed at that timeData format considered inadequate for storing endoscopy dataWe discovered HL7 during research of more rich data formats availableJoined HL7 USA as an individual member early 1998Started understanding the HL7 v2 specificationsBeen on a loop to provide full support for HL7 since

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

Initial barriersCommunications infrastructureSolved by wide spread internet availability (broadband speeds a BIG plus)SQL database serversInitially considered essential but too expensive for specialists (1997)Problem solved by availability of OpenSource Transactional SQL 3 serversEncryptionInitially technology was not generally available however this is not the case now

Initial barriersMessaging platformStandardisation of HTTP has solved thisLack of any Australian examplesPathology in HL7 format became available in Sept 2001 from QML FHS|^~\&|PRSLT|NATA^2184^N|PRSLT|hl7_am27|20010720094242||qm016082.oru||1|

Development styleDevelopment style Test drivenAgileContinuous integrationHighly object orientatedDesign patternsObject Pascal & Java

Tools have been in use in Buderim Gastroenterology Centre since 2001HL7 result delivery has been occurring since 2002Entire Sunshine Coast is a permanent trial site and test bed for new features & developmentsNow 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 HL7HL7 messages are parsed into a treeRead by message objects which are flyweightsHL7 parsing rules are respectedThis allows significant HL7 version mismatch resolutionCurrently the framework is at HL7 v2.3.1HL7 is easily downgraded if needed

HL7 AbstractionAll HL7 data types appear as native data typesAll access is via interfacesAutomatic memory managementCode generation used above data type levelAll higher level methods operate on the interfacesDevelopment 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 systemsHL7 v2 is matureadopting HL7 model reduces impedance to interoperabilityCan be extended via standards process to fill in gapsInternally linkage can be enhanced as needed

HL7 Code Generation

HL7 Application Server ArchitecturePluggable Transport LayerHTTPLLPSMTPS/MIMEPGPPKCS#7 HeSA PKIGnuPGPluggable Encryption LayerFine grain access controlLDAPAuthentication / Access Control(Public Key Authentication)SynchronousAsynchronousProxyMessage ProcessingInterface Engine Layer (In & Out)HL7/XMLPITLab SpecificPMS SpecificORU^R01QRY^R02ORM^O01MFQPluggable Message ProcessorsHL7 file basedPicture ArchivalPluggable Persistence LayerFirebird SQLSQL Server*Oracle** May be supported in futureEtc..

Server handling of messagesMachinery delivers incoming interface to be processed and provides the mechanism to return a responseMessage processors can be plugged into the framework to create specialised servicesSecurity is handled entirely by the use of Public Key Authentication & EncryptionAbstraction enables different message storage mechanismsSQL serveroffline HL7 File based storage

Server message processing

Client Application ArchitectureSpecific Message ProcessingInterface Engine LayerArchetypesHL7 Modelling LayerSNOMED-CTLOINCHL7/XMLPITLab SpecificPMS SpecificORU^R01QRY^R02ORM^O01MFQEtc..HL7 Model

Client Application Development

Hierarchic Designator (IHL7HD)The namespace ID and the combination of universal ID and universal ID type should be equivalent in meaningUsed in the framework to identify practices and institutions, or units within hospitalsCurrently 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 FormsTo 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 ProcessorThe 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 serverThis means that messaging is a core component of the framework and has had extensive real world use. It is real time messagingMessages are processed by an application server which may be quite remoteDatabase access is abstracted currently using FirebirdSQL/InterbaseService oriented message processingA particular message may be delegated for processing by another HL7 processing service eg. Provider directory, routing, terminology services, registrationThis is invisible to the client

We achieved complianceMedical 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 referralsGP referrals Captured from clinical practice softwareDigitally signed HESA PKI USB keyEncrypted with PKI certificatesEncrypted provider lookupZero configuration install

Referrals are delivered real-time

Open Spec - Inline SignatureOpen 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 directoryHL7 2.3 Master filesDefines messages for maintenance & query for providers using the STF segmentCH 8.3.3 MFQ/MFR (Master Files Query/Response)

MFQ/MFR

HL7 for Mere Mortals

HL7 Master Files Query

HL7 FilterUsing 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 VisualiserDesigned for trusted message setPart of Standards Australia work for IT-14-6-5

HL7 is a messaging environmentHL7 predates Web Services and many of the commercial messaging environmentsThere is no need to wrap HL7 inside another messaging environments as it is already richer than services such as SOAP/WSDLThe 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.txtOpen standards are essential to avoid vendor lock in and to enable interoperabilityUse of HL7 as messaging environment ensures the messages can be read at the destination

Medical Objects Network Today

www.medical-objects.com.au

The base level is a data type. These objects and interfaces were created manually.From CE the basic data types. We build segments and using the HL7 message structure we build interfaces into messages.All structures in the message are fully represented by objects.Framework fully supports the HL7 v2 Information ModelSo we dont manually write code for every segment we cheat a bit and get computers to write our code for us! This is also the way we move the framework forward to a new version.When we finally do get to handle messages each layers role is well define and relatively small.

A lot of code reuse.This is an illustration of how server does processing of an Outstanding order message query. It starts by checking for security context. Eventually talks to the database layer via the pluggable database interfaces. It returns HL7 Messages. Exception handling adds the appropriate HL7 error segments.Processing is similar, except we add a presentation layer that allows us to directly render HL7 directly from our HL7 object model.Unlike the majority of clinical applications available, our client applications are highly multithreaded, this is an absolute necessity for working in an Asynchronous messaging environment.Here we have a HL7 form designer. The programmer at design time can add HL7 model controls, which at run time have their values directly connected to HL7 fields in the segments underlying HL7 information model.For routing we use HD. HDs appear in message header, OBR, ORC.These HDs are used to identify entities for message routing.All our report delivery is traceable and an audit trail exists. In the case of receiving systems running medical objects software, we have the ability to know when a user has reviewed a result.Well after 8 years of work, this is where we are at. We have tied a set of open standards based technologies together in a way that allows the vision to be realised. We tie it all together in a way so that the user doesnt need to understand or even know about the underlying technologies, we just let the user get on with what they want to do.

When we started the project, not all of these things were available. But, one by one, each has come into reach to us as developers and users at a reasonable cost. Many already existed, but were far too expensive technologies to be reasonable for all in the medical community to buy, let alone single doctor practices. One of the most significant things is the internet itself, this makes communication quite cheap comparative to what would have been necessary before. What we have been able to achieve is building a software product which is royalty free, based on open, standards based technologies.The framework supports LOINC terminologyICD10-AMSNOMED-CTClinical Terminology queries are quite easy using the framework.This code snippet illustrates how terminology services can be used to calculate if certain relationships exist between Despite the widespread use of HL7, the quality of HL7 production is variable depending on implementation. The certificate here is simply proof that Medical Objects are 100% compliant to Australian Standards. In fact we were the first organisation in Australia to achieve certification.The server & clients can enable automatic posting of their messages in real time to AHML for compliance testing.And this is what sending a referral if you were a GP looks like from the Trinity referral client. We have cut this one down to the bare basics.This is what it looks like when you get the referral at the specialist end. The program verifies the legitimacy of the document, so it is a valid legal referral for HIC purposes. The inline signature is an open specification that we have developed it is available from our web site.Here is a quite preview of some of the capabilities of some of the applications. Including X-Ray via DICOM images are supported. This illustrates how we can leverage the HL7 information model to provide advanced decision support functionality.Everyone always asks us the question Do you support images?. So heres the answer.We have automated support for capsule endoscopy reports.The framework allows the creation of HL7 orders for X-RAY, Pathology, and clinical tests.We have implemented centralised and localised provider lookups using HL7 master files. The STF (Staff) segment defines all necessary information required.This is what the user experiences when they look up a doctorHere is an example of an HL7 provider lookup message and the response from the directory service with the STF records for matches for the query.We have built utility applications using the framework that can do HL7 related tasks. This particular tools manipulates HL7 from a pathology system and fixes it to comply with the AS4700.2We took 6 months worth of messages and converted their local codes to LOINC & SNOMED-CT codes. This directly reads the Auspath file. (This is what Clem McDonald from Regenstrief Institute spoke about the last week at the LOINC workshop.)Magellan is a secure HL7 download client that we have built using the framework.This is a utility application which performs message routing, transformations built with the framework.So this is what it looks like to your day surgeries when you want to send your reports. This is the word processor plug-in that integrates with your existing report writing software enabling you to send your reports & letters without changing your current processes.Another utility application that generates HTML views of HL7 messages. It is for use by standards committees that want to illustrate how HL7 messages should be displayed.So this is what the distributed network is capable of today.