Healthcare Interoperability Blog

interfaceware.com
  • Iguana Integration Engine
  • Resource Center
  • Blog
Home Selecting The Right Channel Components

Selecting The Right Channel Components

I’ve been meaning to write about this topic for a while now.  Not because I think it’s overly exciting, or because I have some amazing perspective to offer, but simply because it’s a topic that tends to throw off both new and existing users.

Selecting the right components and simply knowing what options are available to you, can often save time and ensure all your projects are set up for success.

Much of the same content can be found throughout our documentation, but I wanted to make sure it was all located in a simple, easy-to-find article for anyone who’s getting started.

So, without any further fan-fair, here’s my cheat sheet on IGUANA’s channel components.

1. What are the components and what do they do?

Source Definition
LLP Listener Listens on the specified port for HL7 messages using the LLP protocol

 

Art’s note: If someone told you that you need to start doing something with HL7 data that’s coming out of an existing system (i.e. EMR), this is probably how you’ll be receiving it.

From File For reading files and FTP operations using a few predefined options

 

Art’s note: A “From Translator” component can and should be used when a more flexible or complex solution is required.  But don’t get me wrong, this component is still very useful.

From HTTPS Receive input from a HTTP request

 

Art’s note: This is how to setup IGUANA to act as as web service.  When you use this component, you’ll get to specify a URL path (like, /art-rocks/) and that will become the entry point to the channel.  You can then GET/POST/PUT information directly to that url.

From Channel Used for routing; receives input from other channel(s)

 

Art’s note:  This is part of a 1-to-many setup.  There’s no unique source of data from this channel; it’s feeding off of a pre-existing source.  In 1-to-many for example, you’d have “many” channels that all had a source of “from channel” and they’d all be feeding from a channel who’s destination was “to channel”.

From Translator Runs a Translator script on a pre-defined interval (ex. every 10 seconds)

 

Art’s note: This is often used to poll a Database, watch for files or query some 3rd party service.  One thing of note is that this type of translator instance doesn’t use sample data, because there’s nothing passed to it directly.  It’s responsible for going out and finding its own.

Destination Definition
LLP Client Sends out HL7 messages via sockets using the LLP protocol

 

Art’s note: If someone told you you need to start sending  HL7 messages to them  (i.e. sending orders to a lab), this is probably how you’ll be sending it. It’ll take care of so many of the connection options and retry settings.  You’ll love this component.

To Translator Runs a Translator script to whenever a new event / message is processed

 

Art’s note: This is typically where you’ll be pushing data into a database, writing to files or sending data on (via API) to a cloud provider.  It’s probably the most used component of all because you can pretty much do anything here.

To File Output to files and FTP destinations using a few predefined options

 

Art’s note: A “To Translator” component can and should be used when a more flexible or complex solution is required.  Once again though, if your needs are straightforward, this is still a great choice.

To Channel Used for routing; sends output to other channel(s)

 

Art’s note: This is also used when you don’t need the channel to do any further processing.  For example, I typically use a  “From HTTPs” / “To Channel” combination when creating a web service.  The From HTTPs component does both the receiving of the request and sends back a response, so no further processing is needed by the channel.  However, if you are doing a 1-to-many routing scenario, this component is used by the original source channel.  

There are a few other components labeled as “legacy” in the product.  I highly recommend you ignore them entirely.  However,  if you’re just curious, you can learn more about them here.

2. Where are the different places I can have a translator instance; when would I use each?

This is just for bonus points.  I think I covered the main uses for the components above, but I wanted to include a 2nd table to make sure everyone was aware of where you can find Translator instances.

Translator Location Typical Usage
From Translator Event loops and regular polling
To Translator Pushing data out (to a database, file, 3rd party web service, etc)
Message Filter Verifying, filtering and augmenting data
From HTTPS Creating a web service
From LLP (ACK) Validating data and creating a custom acknowledgement

 

Well, that’s all for this week.  I hope that helps a few of you out.

If there are other areas you’d like some clarification (or “Art’s notes”) on, just leave a comment below and I’ll be happy to blog about it in the future.

Cheers.

Jun 11, 2015iNTERFACEWARE
  • Email
  • LinkedIn
  • More
  • Facebook
  • Twitter

Related

Survey: Which EMR(s) do you integrate with?Health Information Exchange: Fact or Fantasy
June 11, 2015 News, Tips and Tricks
Enjoying this blog?

Sign up to receive healthcare integration news, just like this, from iNTERFACEWARE Inc.

iNTERFACEWARE needs the contact information you provide to us to contact you about our products and services. You may unsubscribe from these communications at any time. For information on how to unsubscribe, as well as our privacy practices and commitment to protecting your privacy, please review our Privacy Policy.

Resources

Integration Resources & Guides

HL7 Resources

Iguana Case Studies

Iguana Integration Engine

Overview: Integration Engine

Features: Building HL7 Interfaces

Benefits: Why Choose Iguana

Company

About Us

Integration Services

Contact Us

Connect

LinkedIn

Twitter

YouTube

© - iNTERFACEWARE Inc.