From HL7 & EDI to SQL + JSON Delivery — Repeatable, Testable, Deployable

SNIP Types 1–5 are available out-of-the-box. Types 6–7 are supported via custom configuration.

40+ Listeners, 35+ Transports and 100+ Processors spanning modern protocols, queues, cloud and databases.

Declare the inbound format in Source Transform and the engine canonicalizes payloads to XML. Use the three-pane Data Mapper with Friendly Names for drag & drop mapping or edit the generated W3C XSLT directly.

Yes. Use XPath-based routing rules to send transactions to specific targets. Add transaction monitors and error route triggers to alert teams or kick off recovery workflows.

Hot-deploy routes to eiPlatform from the eiConsole IDE or upload via eiDashboard. Keep configurations in source control for promotion through environments. PilotFish is optimized for Docker containerization for consistent builds and repeatable ops.

HL7, EDI Routed to Database and Web Services

This is a demonstration of the PilotFish eiConsole IDE, a graphical integrated development environment for the rapid configuration of any Healthcare interface. This demo walks you through the 7 stages of interface building with HL7 and X12 EDI data sources that are routed to a database and a web service.

When you open the eiConsole IDE…

When you open the eiConsole IDE you’ll come here to the route file management screen, kind of the home screen. You can think of these as project folders pointing to some directory as you’ll see above. These project folders are full of different routes that we have done for other clients, just some representative routes are shown such as HIE integration, where we take data acquisition and normalization of health information exchange data. The receipt of laboratory information for orders and results. We’ve done some on-premise medical equipment integrations such as smart cards and hospitals that must be integrated with pharmacy or EMR billing systems. Also an example of some work with the acquisition of clinical and administrative data for reporting and analytics. We’ll jump into this route to go ahead and walk through an entire route with you.

Opening the Interface Project Folder with Multiple Routes

You can see once we open a project folder, we might have multiple routes within that. I’m going to open up this one to walk through it. When you open this main screen, this is the type of screen that we work from. You can think of us moving through an assembly line approach of stages moving from left to right, down the screen through each of these 7 stages to create an end-to-end route. Everything here on my left-hand side has to do with my Source System and where I’m getting that data from, and everything here on the right has to do with my Target System or where I’m sending that data.

Defining 3 Incoming Feeds of HL7, EDI and FHIR JSON Data

In the case of this interface, we have some HL7 coming in, maybe from some hospital over MLLP. We are also dealing with some EDI, maybe coming in from a provider practice that we’re going to be picking up from FTP or SFTP. Then, we have some FHIR and JSON formats that we’re receiving over web service. We’re going to take those three feeds of data and transform them into something that we can then send on.

First, on this second target line, we will send it to a SQL database to store it in and then we are going to send a copy of that information to a web service in JSON. I’m just going to walk through each of these 7 stages from front to back, describing what they do and what the features are as well as what’s happening within this interface.

Documenting the Source System

This first stage called Source System is just for documentation purposes so that when you open up any given route you can see graphically what’s happening within the route. If you have multiple resources working on the interfaces, everyone can be on the same page. We’ll just give it a name and optionally add an icon to represent it. You can even tag some metadata below if we want to search for it later, but no functionality yet, other than just documentation purposes.

Defining Connectivity Protocols for the Listener Stage

I’ll move to the first actual functional stage which is called the Listener stage. What we’re doing here is defining what the connectivity protocol is to receive that source data. You can see here in this drop-down that we have a lot of different connectivity protocols out-of-the-box, probably all that you can think of. Here we can just pull some AWS buckets if we need to or a database or we can pick things out of email and all the flavors of FTP and SFTP as well.

In this case, we’re using HL7 over LLP or MLLP as we call it. All the flavors of HTTP as well – even some more esoteric things that we have from working with clients – cueing systems such as Kafka, RabbitMQ, MSMQ, maybe some offshoot databases like MongoDB or Hadoop all the varieties of SOAP and REST as well and pretty much any other thing you can think of.

If you don’t see a connectivity protocol here, anytime you see ellipses like this, it’s just a point of extension which you can do in Java or .NET. And you’ll see below here, just simple configuration boxes. Once I choose the connectivity protocol I’m going to be working with, it may have some kind of required fields to fill in but we try to keep all the defaults in line for use. Also, I’ll point out that within this stage we do have what we call pre-processors. We have a lot of them out-of-the-box. Just think of these as things to do clean-up to data such as decompression, decryption, maybe pulling out a PDF or working with things like that, you can apply them here.

Incoming EDI Data and Applying the SNIP Validation Processor

Here on my second source, you can see that I’m working with EDI and for this Listener I do have an FTP/SFTP Listener where I’ve filled in some of the required fields. I just want to point out that we do have a processor applied in this case. This is kind of a new feature that we’re coming out with for EDI, which includes a SNIP Validation Processor so we can apply SNIP validation by selecting the checkboxes.

Within this EDI SNIP Validation Processor, you can see that we do have Types 1-5 here available with a checkbox. So if we’re working with Types 1-3 you know these are built-in rules delivered directly from the X12 implementation guides and schema. With Type 4 we’re working with more robust semantic rules, and with Type 5 we provide all external codes in the database. We can also handle Type 6 and Type 7 as a custom configuration defined when you work with our services team.

Transforming All Data into a Common XML Format

So moving on to our next stage here – the Source Transform stage. So what happens here, happens in two parts. First down here (below on the left), you will see our transformation module as we call it. This drop-down will just define what the inbound data format is so that we can work with it. Really what’s going to happen here is it’s going to take that data, it’s going to automatically transform that into an XML representation of that, so that we can work with it in the transformation.

You can see in this drop-down that we have all the formats you could think of whether it’s CSV or some delimited file, EDI, HL7 version two and three, as well as JSON or maybe even just name-value pairs or Excel sheets. I’m going to choose HL7 so it’ll automatically transform that for me. I can even define what my version of HL7 is although I don’t have to since our HL7 parser is extremely lenient.

Mapping HL7 Transactions with the Data Mapper in Source Transform Stage

Over here on the right-hand side is where I’m going to do my data transformation in our data mapper. So I’m going to pop that open right now… (transcript continues with the remaining sections you provided — unchanged for accuracy and SEO depth).