EDI Process – Positive vs Negative Confirmation: An Objection

As a follow-up to yesterday’s post, and before I get to posting some actual code, I thought I’d address what I see as the most likely objection to my combined Sender Negative/Receiver Positive confirmation scheme. It is this: “We don’t like relying on a third party for our confirmation.” Or, put another way, “Our clients don’t expect to have to watch the process constantly, they just want it to work.”

Now, to my mind, these are good, solid, sales-person type answers. Unfortunately, so is, “Absolutely we can have this new major functionality that should take about 4000 man-hours to complete ready for you and in production by Tuesday!” So you’ll excuse me if I don’t give them too much credence.

However, as they are objections that will be raised, they should be addressed. And so we will, in two parts.

The first part is this: We’re not relying on a third party for confirmation, we’re providing the confirmation that makes the most sense for us to provide- if the other guy doesn’t do his, then he’s culpable for any fall-out of a failed process. For the Sender, this means making sure you’re aware of any file that didn’t go so you can get it out the door as soon as possible. For the Receiver, this means making sure the Sender is aware that you only got files X, Y, and Z- so that if you should have received W as well (and how would you know, for sure?) that they can send file W right along.

The second part is this: If a file is important enough that it being missed would be a “resume generating event” for someone, doesn’t it make sense to confirm every major step in the process has worked? And isn’t sending the file a major step in the process? Isn’t receipt of the file a fairly major step?
Ultimately, I find this objection (or variations on the theme) fairly weak. They assume that the only person who should have skin in the game is your organization. Partnerships don’t work that way, and when you’re working with EDI, even if one group is technically a “client,” you’re working much more as a partnership than you are as an employer/employee relationship.

X12 != EDI

I had a brief discussion with a friend about this, and I think I need expound on the subject a little. In the world of Development, if you say "EDI" people automatically assume (in America) ANSI X12. Some of the more enlightened also consider EDIFACT (for our European counterparts) and HL7 (healthcare). I'm here to explain that none of these are, in fact, EDI. Yes, you read that correctly. ANSI X12, EDIFACT, HL7, and Joe-Bob's Custom Layout all share one thing in common: they are file specifications. EDI goes far beyond file specification and, in the original sense of the term (first widely used by Financial institutions, IIRC), doesn't really care about format at all. EDI is, litteraly, "Electronic Data Interchange." EDI is much more concerned with parties and transport than it is with specific layout. Indeed, my trading partners and I can choose any layout we wish - including making up our own - and we'll still be doing EDI. As long as I'm sending and receiving electronic data (in the old, CS101 sense of "raw facts given to the computer") with one or more external parties, I'm doing EDI. Now, why is this important? I don't guess it is really. On the other hand, I believe it will become increasingly important, with the myriad of file specifications in addition to transport specifications, for the demarcation to be clear. AS/1, 2 & 3 are EDI. ANSI X12 is not. FTP over SSL or SSH is EDI. EDIFACT is not. HTTPS is EDI. HL7 is not. This demarcation becomes important because there is so much to know about each world. I'm one of those who still gets FTP/SSL and FTP/SSH confused. I certainly couldn't tell you the difference between AS1 and AS2. On the other hand, I can explain in detail why I prefer XML or Looped files (Such as the X12 standard) over Fixed-Width or delimited (Comma, Tab, or otherwise) flat files. I can explain why, if I must have a flat file, I prefer delimiters to fixed-width. I do not prettend that those who can explain the difference between AS1 & AS2 are not EDI professionals. I recommend that you not do so either.

BizTalk 101 - Installment 1 - HIPAA EDI

As I mention in my bio- I'm new to this. And one thing I've found is that it is very difficult for newbies like myself to find information that everyone else 'just knows.' So, fairly frequently, I'll be posting some of these 100 & 200 level tidbits, in case some other young developer comes along and says "That's great! But how do I get from nothing to that point!?" So, the first installment has to do with HIPAA. I work for a Health Revenue Cycle Management company, so we do a lot of HIPAA EDI (ANSI X12 837, 835, etc.). For one particular client, we don't actually do anything with the files we receive except forward them on, but we do need to know what's in them so we can log them properly. Now, for any normal implementation, that would be no big deal: the filenames would follow some standard which could be used, or the ISA 05/06 & 07/08 information would be sufficient, or whatever. Oh, no. That would be too easy. Anyone already in the HIPAA EDI world may know that Medicare and Medicaid often use Third Party Administrators - sometimes including normal, commercial insurance companies - to handle their claims processing. This can mean, in the right circumstances, that a file comming from, say, CIGNA, might actually be full of Medicare claims. This prevents us from just using the ISA sender/receiver information. Instead, we have to parse out the entire file, just so we can read the first instance of a Patient level NM109 for the Insurance member Id to determine if this is a Medicare or Medicaid file, or if this is really a commercial payer. Luckilly, BizTalk is our friend in this. And this is where that long lead-off gets to some BizTalk 101. I spent the last couple of days trying to figure out how to get BizTalk 2009 to parse out those records. I knew that my friend Tim Rayburn (http://timrayburn.net) had addressed something similar, but it took me a while to find (in his blog, no less). The secret, as is said in Kung-Fu Panda, is that there is no secret. The entire process is 7 steps. 1) Open your BizTalk project (a new one, in my case) 2) Locate the HIPAA maps (harder than you'd think- look for a self extracting zip file burried in the BizTalk folder structure). 3) Add the necessary maps to your project. 4) Deploy the project. 5) Create/Configure a Receive Port & receive location. 6) Create/Configure a Send Port. 7) Restart the BizTalk application. There are a whole lot of specifics that are left out here. But this should be enough to point anyone in the right direction to get such a thing up and running. Tim calls this "From zero to Claims Processing in 15 minutes or less."