Streamlining X12 EDI HIPAA Data Integration
with Validation, Code Set Maintenance & Reporting

EDI SNIP4+ Overview

An overview of the EDI SNIP4+ workflow is shown in the initial slides. EDI SNIP4+ from PilotFish is a complete solution suite for X12 EDI HIPAA integration with validation and code set maintenance that supports all X12 EDI transactions. As part of the SNIP validation process, a SNIP rules file (1-7) is parsed during validation. This rules file is generated from X12 schemas and documentation and is included inside the SNIP validation processor.

The EDI Codes Database (optional yearly subscription) is a separate application outside of the eiPlatform (EIP) runtime, which continually polls for code sets used during SNIP validation. If any updates are found – they are pushed to the server and generated into a codes file. The eiDashboard is another PilotFish component of the EDI workflow that is a dashboard that is used for real-time operational interface reporting and management of EDI messages.

eiConsole Demo using EDI 837 Claims Transaction

Welcome to this comprehensive overview of the eiConsole, the PilotFish Graphical Integrated Development Environment (IDE). In this video, we’ll take you through the key features and functionalities of the eiConsole, designed to streamline data integration processes. We will walk you through the 7 stages of the eiConsole using an EDI 837 claims transaction as an example. We are an X12 partner and can handle any X12 EDI transaction in a similar manner.

Route File Management Screen

When you launch the eiConsole, you’ll arrive at the Route File Management screen. Think of this as a repository for your project folders, each containing a set of routes. These routes are instrumental in managing various aspects of Electronic Data Interchange (EDI).

Working Behind the Scenes

Behind the scenes, the eiConsole IDE writes configuration files to a working directory or file system. These files are later pushed to source control, where the eiPlatform component picks them up for unattended execution.

Exploring EDI 837 Transactions

For this video, we’ll focus on EDI 837 transactions. Navigating to the 837 folder, we find several routes representing client work and common scenarios. We’ll delve into one route demonstrating how to take EDI 837 data and load it into a database, whether SQL or non-SQL.

Route Configuration

Once you open a route, you’ll work within this graphical interface throughout the process. It offers an intuitive assembly line approach, guiding you through 7 stages for end-to-end workflow creation.

Source System Stage

The Source System stage, primarily for documentation, allows you to name and tag your Source System resource(s) for clarity. It includes options for specifying the connectivity protocol for retrieving data. It helps team members understand the workflow without providing any functionality.

Listener Stage

In the Listener stage, you configure how the system listens for and receives incoming data. Here, you define the connectivity protocol for the Source System. Options range from local file pickups to accessing resources in AWS S3 buckets, querying databases, handling email, etc. Here are some examples: HL7 LLP, HTTP/HTTPS, FTP/SFTP/FTPS, Kafka, RabbitMQ, MSMQ, Hadoop, SOAP, RESTful, cloud storage and more. Complete list of 40+ Listeners. Pre-processors are available for data cleanup and validation, including extensive EDI validation options. PilotFish offers EDI SNIP Validation Levels 1-7 and 140+ Processors.

Source Transform Stage

In this stage, you specify the data format you expect from the source system, such as EDI or HL7, CSV, JSON, delimited files, value pairsetc. The system automatically converts this data into an XML representation. Data mapping can be performed on either the Source or Target side.

Route Stage

This is where you set routing rules using XPath expressions to determine where data should go based on attributes within the message. You can send data to one or multiple Targets and you can also configure transaction monitors to respond to errors with custom actions.

Target Transform Stage

Like the Source Transform stage, this stage handles data mapping, but in reverse. You map data onto the Target format, preparing it for the final destination.

Transport Stage

Define the connectivity protocol for the Target System. Options mirror those in the Listener stage, covering a wide range of protocols, including SQL databases, web services, FTP, HTTP and more. Like pre-processors, you can apply post-processing tasks before or after the data is sent to the Target System. List of 35+ Transports.

Inline Testing and Debugging

Switching to testing mode, you can run tests, save them for future use, and view results, including success and failure indications. The eiConsole offers inline testing and debugging capabilities, allowing you to test your data integration routes and identify issues.

Deployment

Routes created in the eiConsole are saved as configuration files in the file system. They can be deployed to a source control system or a location where the eiPlatform runtime engine can pick them up and execute them unattended or hot deploy if needed.

Summary

By mastering the eiConsole, you can efficiently manage data integration, especially when dealing with any EDI transactions. It’s a powerful tool that streamlines workflows and empowers your data integration tasks.

Overall, the video demonstrates the EDI SNIP4+ workflow and how to use the eiConsole to create data integration workflows, configure various stages, apply transformations, and handle data processing tasks efficiently.

X12, chartered by the American National Standards Institute for more than 35 years, develops and maintains EDI standards and XML schemas.