10 Easy Steps to Building a Healthcare Interface
Leverage streamlined interface creation through a unique methodology and feature set with the eiConsole for Healthcare. Benefit from its natively self-documenting 7 stage Assembly Line that makes team collaboration and maintenance easy while also dramatically increasing productivity
In the eiConsole Healthcare Interface Engine IDE, each interface is constructed from a sequence of stages that are all graphically configurable and extensible. In fact, you will configure interfaces, on average, 10x faster using our drag & drop Data Mapper and expansive HL7-specific features. Components included in the eiConsole handle virtually every common communication protocol, parsing, transformation or manipulation task – all graphically configured with virtually no coding or scripting. Open source components may be leveraged via our Open API – and we are the only commercially supported product to offer this advantage.
Step 1: Select the Interface
The eiConsole File Management Screen provides a single place to manage all of an organization’s interfaces (in the eiConsole an interface is a Route). Note the menu options: Select the interface/route and right click, a drop down menu opens. You can add, edit or delete a Route, copy one, edit the description and do things like Define Global Transaction Monitors and Stage Listeners. You can also perform search functions, export components, and rename your route.
When an existing interface is selected, such as EMR-to-Clinic (shown), or you click “New”, a graphical representation of that end-to-end interface is presented. Here you see the eiConsole’s “Assembly Line” with all of its configurable components (see below). Components of the interface, going left to right, include the Source System, Listener, Source Transform, Route, Target Transform, Transport, and Target System – these comprise the eiConsole “Assembly Line”. In this interface you see only one Source and Target. An Interface can have as many Source and Target Systems as you wish. To add more simply click “Add Source” and “Add Target”.
Step 2: Identify the Source System
Click the “Source System” icon and fill in descriptive information about the system outputting the interface data. This information is user defined and might include the system name and owner, format type, etc. Later, this information can be used to search for interfaces maintained in the eiConsole.
Step 3: Select the Listener (Adaptor) Icon
Choose the Listener Tab
Click the “Listener” icon and choose the Listener Tab. Select a Listener from the drop-down-list and fill in the configuration information for the type of Listener selected. In the example below, HL7 TCP is selected.
The eiConsole supports all the popular connectivity types and comes with over 25 out of the box, among them TCP/IP, Directory, HTTP Post, SOAP Web Services, etc.
Processors can also be configured at this stage. Processors perform operations that affect all of the incoming data and may be layered in any order. Over 75 are included, among them: Asymmetric Decryption/Encryption, Authentication, Base64 Encoder/Decoder, etc.
Step 4: Map the Source Data to the Common Standard
The eiConsole for Healthcare supports data transformation using a point, click, drag and drop visual interface. Clicking the “Source Transform” icon presents you with a two step process for the transformation of the data format output from the Source System into a common standard format. First, we’ll look at transforming to XML.
Transformation to XML
The first step in eiConsole data transformation is to bind the incoming data into a corresponding XML representation. If the data is already in XML, no work needs to be done. To convert data in other formats, select the appropriate Transformation Module from a drop-down (see the example below).
Among other data representations, modules exist to painlessly convert:
- HL7 v2
- Fixed Width / Delimited Files (including ANSI X.12)
- Database Result Sets
NOTE: anywhere there is a drop down list in the product you can easily extend it using our Open API.
When working with HL7, the HL7 V2 Transformation Module is particularly important. It boasts a proprietary “Lenient HL7 Parser” capable of working with imperfect, extended, or non-standard message flavors. You can also select which version of HL7 you wish to parse. Choose from 2.2 all the way to 2.7. You can also check the “Friendly Names” option which replaces cryptic HL7 names with simple, understandable synonyms. It’s a huge help for those less familiar with the standard.
The Data Mapper
Clicking the “Edit” button on the XSLT Configuration panel opens the Data Mapper. The Data Mapper is a graphical editor used to generate the XSLT transformations that transform any data format to any other data format. Typically this is used to transform data from a proprietary format to a common format such as HL7, but can also be used to transform data to another proprietary format, a company’s common model, other standards, or different versions or interpretations of a standard. This is particularly useful when working with HL7 formats where custom extensions are common.
The Data Mapper utilizes a unique “triple-pane” mapper. 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. (Click on the graphic below for a detailed look at the Data Mapper.)
In the Data Mapper relating Source formats to Target formats is accomplished by simply dragging the corresponding fields from the Source and the Target to the map in the middle. This approach is of particular advantage when the Source and Target have repeating or recursive elements. When mapping between two different versions of a standard such as HL7 version 2.3 and version 2.4, a Differencing Engine will automatically map matching fields so the user only needs to work with the remaining deltas.
In addition to dragging Source and Target elements onto the map, users can also take advantage of a “computationally complete” Palette of XSLT Structures, Functions, and custom “macros”, to speed the development of high quality transformations. Developers can also switch back and forth from a graphical view of the transformation to an XSLT view. Changes made in one are immediately and automatically reflected in the other.
The XSLT Transformations created using the Data Mapper are W3C-compliant. They can be deployed to an existing Enterprise Service Bus (ESB), an “XSLT crunching” appliance, or with one mouse-click, to the eiPlatform Java framework to support run-time transformations. Data formats are loaded into the Source and Target panels by clicking the “Open Source / Target” icon, selecting the format, browsing for the file, and clicking “Read Format”.
Some of the Source & Target format readers included with the eiConsole are the HL7, XSD Format Builder, Flat File, XML, HTML, SQLXML and WSDL Format Builders.
Step 5: Configure the Route
The Route stage serves several purposes: You can maintain general metadata describing the Route, specify routing rules and configure Transaction Monitoring. To configure the Route, click the Route icon, and click the appropriate tab. The “General” tab lets you turn on and off transaction logging and debug tracing. It also lets you create your own metadata describing the Route – useful for documenting the interface.
The “Routing Rules” tab enables you to route messages to the appropriate target or targets based on the content of the message. A facility for configuring XPath-based routing rules is included with the eiConsole for Healthcare. While XPath is the most commonly used means to route transactions, you can also configure your own routing rules program call out to another program, or integrate with popular workflow, and message orchestration programs.
The “Transaction Monitoring” tab lets you customize the error notification system used by this interface when in production. This proactive alerting supplements the traditional, passive logging and audit trail supported and configurable in the eiPlatform run-time. A few examples of the transaction monitors included are:
• Email Alert
• SNMP Trap
• Error Route Trigger
Step 6: Map the Data to the Exact Format Required by the Target System
Clicking the “Target Transform” icon will again present you with the two step process for transformation. This time, however, the purpose is to transform the current or canonical format to the format of the Target System. If the Target System is capable of accepting the industry-standard, simply click the “Use Direct Relay” check box and no data transformation will occur.
Step 7: Configure the Transport
Click the “Transport” icon, select a Transport method from the drop-down list and fill in the configuration information for the type of Transport selected. Some of the Transport types for the eiConsole include: TCP/IP, Command Line, Database Polling SQL Listener, Email (SMTP), FTP(S), Generic Socket Transport and HTTP(S), etc.
Processor Configuration Tab
As in the Listener stage Processors can also be configured at this stage. Here the Processors perform operations that affect all of the ougoing data and may be layered in any order. The same 75 Processors, as in the Listener Stage, are available.
Step 8: Identify the Target System
Click the “Target System” icon and fill in descriptive information about the system receiving the interface data. This information is user defined and can be used later to search for interfaces maintained in the eiConsole for Healthcare.
Step 9: Test the Interface
Select “Switch to Testing Mode” from the main menu. Select the Stage at which to begin the testing, provide sample input data, and click the “Execute Test” icon.
You can click any of the Stages and view the output of each Stage as the data undergoes the transformation and delivery process. For example, you can see the data in a flat file format transformed to generic XML, then to a health standard format, and then to a proprietary format of the Target.
You can even establish a “live” connection to the Target system to test successful connectivity. Any Stages that fail provide detailed error messages. The failures can be quickly corrected and retested.
Step 10: Deploy the Interface to the eiPlatform Server (Run-time)
Once an interface has been tested from end-to-end, the final step is deployment to an eiPlatform run-time environment. The completed interface is saved as a set of discrete, easily shared, easily managed configuration files. Interfaces can be deployed by copying the configuration files that now exist in the Working Directory, or by connecting to an eiPlatform server, and dragging & dropping into an eiPlatform panel, accessed via a tab on the bottom panel.
With the eiConsole for Healthcare your interface can be built and deployed into production 10 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 Your Interface Management and Maintenance!
The eiConsole is also designed to simplify ongoing management and maintenance of interfaces. The Route File Management screen allows you to view all of the interfaces for the entire enterprise 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.
Back to eiConsole for Healthcare…