Guest Article: In a world of cloud services, are HL7 interface engines dead?

May 8, 2012

I spend a good deal of time with clients these days who are trying to connect web services, implement service oriented architecture (SOA), and moving to the cloud. All these requirements are focused on integration of multiple, sometimes legacy sometimes modern, systems but most of them still require lots of HL7 interfacing. Some of my clients start their integration efforts hoping that there is something better or more modern than HL7 but the truth is that HL7 and interfacing remains the backbone of health system integration. Choosing an integration tool is time consuming so I reached out to Craig Cunic, the Product Director of Interface Engine Team at Iatric Systems, to get some advice on how to choose an interfacing engine. Iatric has been solving complex health IT problems for a while so it’s worth following’s Craig’s advice on the Dos and Don’ts for Interface Engine Consideration. Here’s what he said:

It has been suggested that due to the advent of web services, Service-Oriented Architecture (SOA), and cloud computing, interface engines no longer serve as the proper tool for system integration. Is the interface engine dead? Yes, it is, if the interface engine does not have the necessary feature-set to support the growing number of data standards and if it can’t exchange data with today’s diverse healthcare systems and devices.

Today’s interface engine is an advanced integration engine.

The interface engine is not dead. Today’s interface engine is alive and well…and it is one with advanced features that turn it into a mighty integration engine. It is one that has extensive security and privacy features and the scalability to grow with your increased interface needs. Today’s interface engine also integrates clinical portals and medical devices, achieves other complex integration situations and supports Meaningful Use mandates. And, an advanced integration engine is easy on your IT budget: it helps control the budget because there are no ongoing interface costs.

If you are considering upgrading your current interface engine to an advanced integration engine or want to move away from point-to-point interfaces, here are the dos and don’ts to consider when researching and evaluating different integration engines:

  • Do consider engines built on modern platforms such as .NET or J2EE. These will have a leg up on the competition in terms of being able to fulfill many of the requirements mentioned above.
  • Don’t overlook the potential barriers in data sharing. Look for an engine that can simplify these types of communications: direct to database (ADBC, OLE, DB, Oracle and SQL), transfer types MLLP, TCP/IP, folder shares FTP (SFTP and FTPS) and SOAP.
  • Don’t select any engine that is built on outdated technology. Look for engines built on advanced architectures to ensure scalability and extensibility and to support new formats and new demands as they arise.
  • Do look beyond the engine’s interface capabilities – look into its ability to monitor all activity in real time and deliver exception notifications automatically. Engines using a visual IDE are best. Monitoring performance and sending problem alerts are critical for minimizing downtime, which has a negative effect on healthcare.
  • Do analyze the vendor that is offering the solution and evaluate the level of customization that the vendor provides to meet your specific security needs. Also look at how much support the vendor provides in terms of minimizing IT effort at your organization.
  • Do make sure the engine supports all major standard messaging data formats (delimited, fixed length, HL7 2.x and XML).
  • Do consider the time that must be dedicated to set up each interface, train users, record updates and generate useful reports.
  • Don’t forget that modern systems need to integrate using scripting languages such as PHP, Ruby, Perl, and Python. While .NET and J2EE are kinds of the enterprise world, scripting and glue languages are the yeoman of the integration world.

Interface engines are a core element in today’s healthcare environment, and are a requirement to achieve interoperability and meet Meaningful Use. The interface engine you choose should not only streamline your healthcare organization’s ability to share medical data with providers, patients and the community, but also minimize the IT efforts necessary to accomplish this sharing.

  • http://www.comsi.com Jeff Brandt

    Shahid,  Great article.  I would like to add one more data format, JSON which is used in many modern languages and is light-weight for mobile or low-band transition.

    Jeff Brandt 

  • http://www.shahidshah.com Shahid N. Shah

    Great point, thanks for the reminder Jeff.

  • http://taelor.myopenid.com/ Taylor Redden

     Jeff, I was going to comment the exact same thing. JSON is what most mobile devices and client side rich web applications are using to talk to back and forth from web servers.  It’s lightweight, full featured, and human readable.

  • Andrew Hallman

    The move to cloud only helps those that have applications in the cloud.  If you have a system that requires an interface and you’re using a cloud system, the interface may already be completed by another customer of the product and they may just have to “turn it on” for you.  I use that loosely because it’s never that simple.

  • Michel Floyd

    I think you meant ODBC instead of ADBC. Maybe you were also thinking ADO. REST is the much more modern replacement to SOAP. Jeff is right to bring up JSON as well, it provides a great bridge to python, PHP, javascript, node.js. Perl is pretty retro at this point although it still has its devotees.

Previous post:

Next post: