1 / 50

An object oriented HL7 Framework

An object oriented HL7 Framework. 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/ 9 th HL7 Australia Conference, 9 th November 2005 Sydney, Australia.

gene
Download Presentation

An object oriented HL7 Framework

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. An object oriented HL7 Framework 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

  2. 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…

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

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

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

  6. 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)

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

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

  9. HL7 CE data type

  10. Objects are aggregated

  11. OBX data type

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

  13. HL7 Code Generation

  14. HL7 Application Server Architecture Pluggable Transport Layer HTTP LLP SMTP S/MIME Pluggable Encryption Layer PGP PKCS#7 HeSA PKI GnuPG Authentication / Access Control (Public Key Authentication) Fine grain access control LDAP Message Processing Synchronous Asynchronous Proxy Interface Engine Layer (In & Out) HL7/XML PIT Lab Specific PMS Specific ORU^R01 QRY^R02 ORM^O01 MFQ Etc.. Pluggable Message Processors HL7 file based Firebird SQL Oracle* Pluggable Persistence Layer SQL Server* Picture Archival * May be supported in future

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

  16. Server message processing

  17. Client Application Architecture Transport Layer HTTP LLP SMTP S/MIME Encryption Layer PGP PKCS#7 HeSA PKI GnuPG Presentation Persistence Presentation or Persistence Layers HL7 PIT RTF HL7 PIT DICOM JPEG HTML Offline Index HL7 Modelling Layer Archetypes SNOMED-CT LOINC HL7 Model Interface Engine Layer HL7/XML PIT Lab Specific PMS Specific Specific Message Processing ORU^R01 QRY^R02 ORM^O01 MFQ Etc..

  18. Client Application Development

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

  20. HDs & Routing

  21. Server routing report

  22. Putting it all together

  23. LOINC support

  24. ICD-10AM support

  25. SNOMED-CT support

  26. SNOMED-CT Query

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

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

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

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

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

  32. AHML Compliance Integration

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

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

  35. Medical Objects Explorer

  36. Combined results analysis showing adverse drug reactionLiver Function Tests

  37. Capsule Endoscopy

  38. HL7 Orders

  39. 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)

  40. MFQ/MFR

  41. HL7 for Mere Mortals

  42. HL7 Master Files Query

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

  44. HL7 Filter Configuration

  45. Magellan

  46. Eclipse

  47. Word Plugin

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

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

  50. Medical Objects Network Today www.medical-objects.com.au

More Related