Back to Pilotfish Home

How to Build a Healthcare Interface in 10 Steps

PilotFish’s Automated Interface Assembly Line

The Key to Rapid Interface Configuration and Leveraging Reuse

The eiConsole for Healthcare features a 7-stage Graphical Assembly Line where you can build any interface, no matter how complex your integration requirements. It is natively self-documenting, so you’ll never have to worry again about who built an interface or who can maintain it.

In the eiConsole, each interface is constructed from a sequence of stages that are all graphically configurable without requiring any coding or scripting. Data Mapping is accomplished in a graphical 3-pane mapper using drag & drop, where even the most complicated mappings can be created (gone are the hairballs that line drawing mapping tools create).  The eiConsole includes components that allow you to handle virtually every communication protocol, parsing, transformation or manipulation task you’ll ever need. Open source components may be leveraged, too, via our Open API – PilotFish offers the only commercially supported product that offers this tremendous advantage to easily and inexpensively extend functionality.

The eiConsole’s Graphical Automated Interface Assembly Line also makes it easy to leverage business analysts and non-developers who can do 80-90% of your interface work.

 

Stepping Through Building an Interface in the eiConsole

Step 1 – Create and Name Your Route or Interface 

When you open the eiConsole, the first screen you see is the File Management screen. This is where the interface/route configuration files can be managed. PilotFish configurations are divided into two levels. A single connection between a Source and Target system is a route, and a collection of routes working together is an interface. In the File Management screen, existing interfaces are denoted by a green box icon and routes by a puzzle piece icon. Red indicates a configured interface and blue is an unconfigured interface.

Click on the Add Route button to create a new Route, then name it and click OK. Double-click your new Route to open the interface.

 

Step 2 – Build the Route

The eiConsole opens to the main Route Grid. (Note: When creating a new interface or route, the grid will be empty except for the Route stage.) When creating integrations with the eiConsole most of the work is done building individual routes. In the eiConsole, a route is a connection between a Source and Target system. There is no limit to the number of Source and Target Systems that can be linked in this way.

In the eiConsole, routes are built configuring the stages of the Automated Interface Assembly Line. These 7 stages are laid out in a table at the top of the screen. These stages handle processing the flow of data from the Source System(s) to the Target System(s). Regardless of the type of integration or its complexity, each interface or route is created by stepping through and configuring each stage in the Assembly Line.

Healthcare Interface Listener and Receiver Defined in EMR Route

 

Step 3 – Define the Source(s) and Target System(s)

The first thing to do when building a PilotFish route is to add however many Source and Target Systems are required. Click the Add Source icon and name your Source System(s) by filling in the bottom panel. For easy reference, you should name your systems for what they are supposed to represent. Click Add Target and name your Target System(s) following the same process.

HL7 Interface Source Defined in Message Route for Software

 

Step 4 – Configure the Listeners and Processors (if needed)

Click the Listener icon and select the Listener Tab. PilotFish retrieves data from the Source system using a component called a Listener. This component communicates with the Source system at highly configurable intervals, retrieves the data, and starts a PilotFish transaction. PilotFish comes pre-bundled with 40+ Listeners, capable of handling an extensive range of system types. Included are TCP/IP, Directory, HTTP Post, SOAP Web Services, etc.

Select a Listener from the drop-down list and fill in the configuration information for the type selected. In the example below, HL7 TCP is selected.

Listeners and Processors Configured in EMR Route

After adding a Listener, Processors can then be queued up to do some initial data handling. PilotFish Processors run in between several of the larger stages to perform in-between operations. These can range from changing the encoding, handling encryption, compression/decompression, preserving metadata and so much more. View the extensive list of 140+ Processors available out-of-the-box or add your own using our Open API.

Select Preconfigured Processor in Interface or Add Your Own API

 

Step 5 – Transform the Source Data to a Common Standard

PilotFish works primarily with XML as it represents an easy-to-transform, common standard for working with data. Once data is received by the application, it goes through this conversion process in two steps. First, it goes through an automated Transformer to convert the raw content to XML, if necessary. These Transformers are pre-built modules that can be set up through a simple graphical configuration. They take a wide range of standard data types and generate an XML representation of them.  Among the included Transformers are:

  • HL7 v2
  • Fixed Width / Delimited Files (including X12 EDI)
  • CSV
  • XLS/XLSX
  • Database Result Sets

In Healthcare, one of our most popular Transformers is our HL7 Transform. This is a lenient HL7 Parser capable of working with imperfect, extended, or non-standard message flavors of HL7. Configuration requires only changing a handful of options in the application.

HL7 Interface Format Selected in EMR Interface for Message Routing HL7 Interface Transformation to XML using Friendly Names Option HL7 to XML Conversion - XSLT Configuration

 

After the Transformer, the data is mapped using XSLT. This is a logical mapping from one data structure to another and is easily accomplished using the eiConsole’s Data Mapper. The eiConsole’s Data Mapper is a tool that generates W3C compliant XSLT using a simple, 3-pane, graphical, drag & drop interface.

Using the Data Mapper is simple, involving nothing more than loading up sample files of the Source and Target formats and then dragging and dropping the content into the center panel to map them together. The pane on the left represents the Source format, the pane on the right represents the Target format and the pane in the middle represents the relationship between the Source and the Target.

A panel of powerful XSLT functions and custom PilotFish add-ons is included above the main mapping panel for more advanced functionality. And if a developer wants to dive deep into the mapping process, a tab for an XSLT IDE is also provided for viewing and editing the code generated by the graphical mapping.

Data Mapper using XSLT structure

 

Step 6 – Configure the Routing Module

The Routing Module is the control point for the entire route. It is a gateway that determines which of the Target systems the data is sent to. The data can be sent to all Targets, or it can be restricted to one or several Targets using a series of Routing Rules that can be defined.

Also, the Routing Module controls the error handling for PilotFish. Should any errors occur while the route is processing, those errors are sent to a PilotFish Transaction Monitor. These components take the error and provide an alert that something has happened in a variety of different ways. As in all areas of the application, several pre-built Transaction Monitors have been provided.

HL7 Interface Routing Module for Route Selected

A few examples of the transaction monitors included are:

• Email Alert
• SNMP Trap
• Error Route Trigger

 

Step 7 – Transform the Data for the Target System

Once the data is on the Target side of the PilotFish workflow, it’s time to transform it so it’s ready to be received by the Target System. This is done the same way as the transformation on the Source side; only the order of operations is reversed. First, a logical mapping is done using XSLT in the PilotFish Data Mapper. This process is identical to the mapping on the Source side, with the only difference being the formats used.

Then, the mapped data is sent to another Transformer. On the Source side, Transformers automate the process of converting non-XML files into XML. These same Transformers do the reverse on the Target side, converting the XML data into a non-XML format.

XSLT to XML File Conversion for Target System

 

Step 8 – Configure the Transport and Processors (if needed)

PilotFish Transports communicate with the Target systems and deliver the data to them. As with the Listeners, PilotFish provides a wide range of Transports capable of handling a diverse array of connections to many different systems. Over 30+ Transport Types are included, among them, TCP/IP, Command Line, Database Polling SQL Listener, Email (SMTP), FTP(S), Generic Socket Transport and HTTP(S), etc. Configuring a Transport in the eiConsole is as easy as filling out the configuration panel. Once configured, the Transport will deliver any transactions sent to that Target System.

Configure the Transport and Processors for EMR to Clinic Route

Before and after the Transport executes, additional Processors can be added if required. These Processors can handle the final small tasks around the delivery of the data to the Target system. The Processors available are the same as those available after the Listener on the Source side.

HL7 Transport Add Processor in Route

 

Step 9 – Test the Route

Once the Route has been built, it’s time to test it. The eiConsole comes bundled with a powerful graphical Testing Mode. This mode not only allows the route to be run from end-to-end, but it provides an in-depth look at the processing that occurs each step of the way, making it easier to debug and solve problems. Any Stages that fail provide detailed error messages so that failures can be quickly corrected and retested. You also can start and end the tests at any stage in the Route and manually define the data being sent through. The Testing mode offers these and other functions to ensure that the Route works just as expected before deployment.

Test the Message Route from EHR to Clinic Before Deploying

 

Step 10 – Deploy the Interface

The eiConsole is used to develop the routes and interfaces, but they need to be deployed to the eiPlatform server once they are ready. In the eiConsole, configurations are simply files on the filesystem. Simply navigate to the root directory chosen for these configurations and copy the files over to the other server.

HL7 Route File Management and Deployment

With the eiConsole for Healthcare, your interface can be built and deployed into production 10x to 100x faster! Often you can leverage an existing interface by cloning, tweaking and you’re done.

The eiPlatform is scalable, reliable, manageable and secure. Combined with the eiConsole for Healthcare, it offers a truly enterprise-class middleware solution for your integration needs.

 

Simplify Interface Management and Maintenance with the eiConsole

The eiConsole for Healthcare is also designed to simplify the ongoing management and maintenance of interfaces. The Route File Management screen allows you to view all of the entire enterprise’s interfaces on one screen. As the number of interfaces increases, you can filter and sort the interfaces using user-defined fields. Once you have identified a particular interface, it can be “downloaded” from the production eiPlatform, cloned, tweaked, and “uploaded” back to the eiPlatform with just a few mouse clicks.

If you’re curious about the software features, free trial, or even a demo – we’re ready to answer any and all questions. Please call 813 864 8662 or click the button.

This is a unique website which will require a more modern browser to work! Please upgrade today!