Streamlining FHIR → X12 278 Prior Authorization with Validation and Reporting

SNIP Validation Levels 1–7 are available along with EDI code set maintenance. This demo shows levels 1–3.

They are converted to XML as a canonical format, then mapped to X12 278 using XSLT.

Yes. PilotFish is optimized for Docker deployments.

40+ Listeners, 35+ Transports and 140+ Processors for modern protocols, queues, cloud and databases. See Product Specifications.

Commit configs to source control and hot-deploy to eiPlatform; monitor with eiDashboard.

Pilotfish Route File Workflow FHIR JSON to X12 278

In this demonstration, I’m going to be walking through our eiConsole IDE or integrated development environment from PilotFish. This is just a local desktop application that runs on Windows, Mac or Linux. And when I open this up, we come here to the home screen, the route file management screen. You’ll see here that I do have one route or workflow which is actually taking in FHIR JSON payloads and then we’re going to actually convert that into an outbound 278 EDI X12 file. From this home screen you’ll see I do have just one route here.

Directory

Really what that’s doing is just running config files behind the scenes that are going to be stored to some working directory. If I drop that down you can see I have many working directories, but that can be organized in any way. It’s meant to be flexible.

Route Workflow

So I’m going to pop open this route here and walk through the workflow. So, when I open up any given route, this is the kind of the editing screen that you’ll work from the entire time. We have what we call an assembly line approach to working with our workflows within the system. And we kind of move from this left-hand side to the right-hand side, step by step to go ahead and set up first our kind of Source System on what we’re getting the data from. And then as we move through the line, we move to the right-hand side on our Target System where that data is going. So, first stage here just to show you the Source System stage. This is really just for documentation purposes. I just want to give it a name. Maybe optionally an icon if I want to represent that.

Route Workflow Listener FHIR JSON File

Maybe tag some metadata so I can search for it later. But this is really just for documentation purposes. If you have multiple resources working within this tool and they open up the same route to work on, we want to know what’s happening within the workflow at a glance. But the first functional stage here, the Listener stage, you can see this is where we set our connectivity protocol for how we’re going to either receive or retrieve that data. So, so normally with a FHIR JSON file, we’re probably going to have some endpoint that’s being sent to but in this case, I am using a local directory file pickup for demo purposes. So, I can pick those up since I don’t have an active endpoint.

Connectivity Selections

I’ll just drop this down to show you that we do have probably every connectivity protocol you can think of here out of the box with just simple configuration drop-down boxes and maybe some required fields. But just to show you here, we can pick up things from, you know, AWS buckets. Obviously grab things out of email, query databases, FTP, SFTP as well. If we’re working with HL7 proper, then we can grab that over MLP or TCP IP connection. All the flavors of HTTP here. Even some more esoteric things such as queuing systems like Kafka or Rabbit MQ or MSMQ.

Some non-SQL databases like MongoDB or Hadoop, again REST and SOAP are available there even down to serial port level and if there’s something here that you would need that you don’t see anytime you see ellipses here within the tool it’s just a point of extension so you can do that either in Java or.net but again in this route here I’m just going to be picking up these two payload JSON payloads here and bringing those into work with now when I switch the tab here over to the processors This is what we call pre-processors. We probably have over 150 of them out of the box. You can think of these such as, you know, decryption, decompression, pulling out PDFs.

SNIP Validation Processor FHIR JSON XML

We also have validation levels within these processors. I can really do anything I need to do in here. And you can read more about that on our website and see all those available. In this case here though, my first processor I have here is a FHIR JSON to XML. So, what is happening within this processor is we’re just telling the system that I’m expecting inbound FHIR JSON format and it’s going to automatically behind the scenes with no latency convert that into an XML representation of that JSON object. We use XML as our canonical format that is more standard for us so that we can utilize XSLT as our transformation language and everything is repeatable.

Using Processors for Transformations

So this first processor is going to take that JSON and create XML from that. Our next processor here is where I actually get into an XSLT transformation. So I’m going to pop that open and we can walk through the data mapper and see how we actually take that FHIR object and then go ahead and map that onto a 278.

Mapping JSON FHIR to EDI 278

So at a high level, this is our three-pane data mapper. This is autonomous. It will open blank from the start. We want to define what we’re doing every time so that we can reuse mappings and not have to reinvent the wheel. You’ll see on this left-hand side, this is what I’m mapping from. In this case, I am mapping from this JSON object, which is the FHIR standard in JSON format. And on the right-hand side, I’m actually mapping onto my direct 278.

How we add those in is by hitting this button here and showing our format readers. And again, just to show you out of the box that we have probably every healthcare standard you can think of, plus some other standards from other industries that we make available for everyone. So, if I’m working even with CSVs or EDI or FHIR, it could be HL7v2 whatever version even HL7 version 3, which is your CDAS or CCDAs. Again, JSON, even Excel sheets if we’re working with even just WSDLs or schemas, that’s all available here to load. The same on the right-hand side here what I’m mapping to same format readers here with all the same available options.

But in this case this is my FHIR JSON object on the left I’m mapping from that’s inbound and on the right-hand side here I am mapping onto this 278 which I have pulled in through our format reader in EDI and you can see here that now that we’re in XML format it’s going to actually lay out all the looping structures in a more repeatable Okay, our mapping tree here in the center, all done through drag & drop is utilized to go ahead and drag & drop basically all of my nodes I’m looking for in the object onto the 278 format, which you’ll see here in green. So everything from that 278 is brought over in green.

Data Mapper and XSLT View

And then I’m basically just going to go and find the corresponding fields and drag & drop them onto the center here. This tree in the middle will only just maybe get longer and more indented with more fields I have instead of drawing lines from one node to the other like a lot of other tools. If I switch the view down here to XSLT view, you can see when I do that drag & drop, it’s really just writing the W3C compliant XSLT, which has been around since the ’90s, not proprietary to us in any way, Behind the scenes here. And so, this is a fully featured editor with autocompletion and all of those things. So if you have resources that are more familiar with that and would like this view better then you can utilize that as well. Anything you do within this view will show up in the drag & drop and vice versa.

XSLT Mapping

We also make all of those XSLT functions available in what we call a tool palette up here, where you can drag & drop those functions actually onto the mapping, which is very helpful. So we can utilize things like XPath expressions and other custom things that we want to add. We also here have an inline testing within our mapper. So I can feed it a sample file, hit a button here, and actually see the output below of what I’ve mapped so far, which is very helpful in going through our mappings to make sure that everything looks correct.

We’ve shown our mapping. You’ll see here we do have another processor. It’s going to just remove any empty nodes that we have that weren’t utilized. Not everything is required in our 278 that we have.

Processor Converts XML 278 to EDI

And lastly here as a processor. Now this processor is called our Transformer. It’s basically going to take that XML representation of the 278. It’s going to convert that into an actual EDI format.

Routing Stage for One or Many Targets

Jumping here to our middle stage, the Routing stage. Just one thing to point out our routing rules. Right now, we have it set to all targets, meaning that I have one Target being my outbound EDI file. I could have maybe multiple Targets here. So I can actually utilize also this XP path expressions or rules to show based on some attribute within the message I want it to go here but not here. Also, within this stage we do have our transaction monitors out of the box that we can utilize.

Error Trigger Route Workflow

So what happens in the event of an error? We can send maybe an email alert to a team to take action on that. But more importantly what we call air route trigger which will basically kick off a whole new route that we’ve defined on a workflow.

It can do multiple things and we can utilize those same air routes to go into other routes as well. So we don’t have to really redefine that. We can just drop them in.

Target Transport Stage

So I’ll jump now to the transport stage here. And so this works just like our listener stage. Just on the target side, we’re defining again what the connectivity protocol is for that target system.

So again, in this demo I am just dropping off the actual EDI file locally into a directory. But this could be, you know, an internal system. This could be a trading partner that we’re sending it to. Again, all those same connectivity protocols are available here out of the box to utilize.

Processors for SNIP Validation

We also have the same processors that we had before. We can choose to have those processors maybe kick off before the transport or after. Again, think about compression, encryption, base encoding, things like that. SNIP level validation. This is where we utilize that. In this case, I do have it kicking off after the Transport. So, I’ll show you what we have here first. This is our transformer. Again, this is just going to take that EDI that we actually have going outbound. Maybe make a copy of that into XML again so that we can do some SNIP validation on that utilizing our SNIP validation processors which we do have out of the box.

You’ll see here first I’m going to define which version of X12 I’m using and which transaction type this is which is the 278 and then when I add my actual SNIP validation processor here you’ll see I can choose types 1 through 7 we provide those out of the box in this case I’m just going to be utilizing SNIP levels 1 through three basic syntax checking and things like that and it’s going to go ahead and return a result on that as well as sending out this EDI document.

Inline Testing

So, I’m going to go ahead and switch it over to the testing mode now, run this through, and show you how the data moves through the system.

So, once we move into the testing stage here, you’ll see that it looks just like our editing stage, only anytime you see an arrow is where a test can potentially go. And when I click on any of the stages, it’ll drill down into our testing configuration here. So, I can go ahead and either start a test late, maybe end it early, skip a stage if I need to. Whatever I need to do can be set up here, but I’m going to go ahead and run this test through and show you how this data moved through. So, I’ll turn that on. Looks like everything went pretty quickly there.

Listener FHIR Payload

So now that our test is completed, you’ll see here from the Listener stage, we went ahead and we picked up the actual FHIR payload. So this is one of them here.

JSON Processor XML Payload Mapping

I think we have two different payloads for the same patient. Those payloads contain the resources such as patient claim and prior auth. Those are in JSON format. At this point, our processor here went ahead and converted that JSON format into XML. So, this is the same exact payload only just in XML format which we we will utilize within the actual mapping.

XSLT Mapping Payload 278 XML X12

This is our actual XSLT mapping here showing you what we’ve actually mapped from that payload onto the 278. still in XML format at this point. But you can also see here our friendly names option which will show you what each of those different segments are, since we are an X12 partner.

Processor XML EDI 278

And then here our processor did take that XML representation and then converted it back out into an actual EDI format. So this is the outbound 278 in EDI format that we’re going to be sending to the endpoint.

SNIP Validation X12 File

As I kind of move through here, through the system, you’ll see now on the transport side Since we did do some SNIP validation there. We have our outbound EDI278 X12 file here.

And then we went ahead and applied some SNIP validation here. And you’ll see since there were no errors on that SNIP level 1 through 3, you’ll see that this is blank. That means that was a pass. So, you really kind of just jump through testing mode and editing mode back and forth making small changes as you see fit. Working with our tool.

Repeatable Process for Multiple Trading Partners

Another thing to point out, if we have multiple trading partners with different FHIR JSON structures, which is very common, once we create this base template, we’re able to easily duplicate that. So, maybe there’s some small changes to the payloads. But once we have this base template, it’s as easy as us literally right-clicking on this and hitting create duplicate. And maybe this is customer number two. Now we have that automatically and we just need to go in and maybe do some small changes or tweaks there. But this makes this heavily repeatable.