Electronic Data Interchange (EDI)
Healthcare runs on Electronic Data Interchange files like 837 v5010. We are the experts.
Shouldn't this be easier?
Depending on how you count, EDI has been in use for 40 years. You would think use of Electronic Data Interchange would be "solved" by now. While we love teaching how EDI works (and are pretty great at it), most of the problems come from the fact that modern databases and standards are just not good at taking in the complex hierarchical data structures that make up EDI.
Where to find the data needed and what data will be present is not fixed like a database or a delimited file. Location and content of data are dependent on the data itself. The next name found in the file might be a patient or a provider. Figuring that out depends on the data itself in addition to where it was found. As such, the very best people at handing EDI are those that not only understand the arcane formatting rules, but truly understand how the data is USED.
The EDI Project™ has been working with EDI since 1996 and can solve any problem your organization might be facing with consuming or creating EDI files.
Understanding EDI can be daunting. Trying to read and ingest the files themselves can be very frustrating. But despite the crucial role EDI plays in every singe doctor visit across the country, developing specialized EDI expertise in house may just not be worth it for some. The standards themselves change very slowly and give lots of warning before they do. If developed properly (perhaps a big "if" for some companies. . . ) EDI ingestion and creation routines can run for years with little or no updates to them. Once the data is in a customer's database / line of business system, it can be used just like any other data despite where it came from.
The combination of highly specialized expertise required and the potential for infrequent changes in many environments, make EDI related areas perfect places to bring in reliable outside help.
EMBEDDED TECHNOLOGY
"I need to send and receive EDI"
This is something that we hear a lot. However, the needs of a healthplan who might require a full EDI Gateway may be different than a manufacturer of say an insulin pump that has to send a fairly limited set of specific encounter data back to be billed.
Behind the scenes, we have embedded into various healthcare vendor's products the abilities they need. Healthcare informatics companies that manage Medicare Advantage Enrollment use code The EDI Project™ created to create and send EDI X12 834 v5010 files to CMS as well as process all the related acknowledgments. We also have created the entire infrastructure in multiple cases to handle all the submission of risk adjustment data for both Medicaid at a state level and Medicare advantage using EDI X12 837 v5010. Often, this involves not only the validation work, but creation of a data store to use in production efforts.
EDI Gateway
It turns out that "correct" and "valid" EDI are slightly different things. Putting three EDI Experts in a room to discuss which is which really doesn't matter unless you enjoy pedantic conversations. But from a practical standpoint, understanding that a health plan needs different ways to respond to problems in submitted EDI is important.
Imagine a claim is submitted with the value "CLOWN" for a treatment code. It is a required field which is present. It also is 5 characters Alpha-numeric and so it is valid. Obviously though this is not a real treatment code. So where should this be rejected? If codes are checked by the EDI Gateway, it can be REJECTED as a 277CA error. If they are not and the gateway only is checking to see that the EDI is formed properly, it can be DENIED and the EOB / EOP EDI x12 835 v5010 would show a claim line or claim that was not paid. Making the proper decision to where to validate and respond to problems can be very important.
One of our customers is a major Commercial, Medicare Advantage and Medicaid payer spanning multiple lines of business. When they would get claims that contained invalid members, they would DENY the claim and send it back with an EDI 835 and or paper EOP / EOB. However, many state Medicaid programs track denial rates knowing that the poor or uneducated often don't know to fight improperly denied claims. If a plan has a high denial rate, they are audited or fined.
A few years ago, they were mistakenly sent an EDI file with 10,000 Medicaid claims that were intended to go to another similarly named health plan. After import, it led to 10,000 denied claims that wrecked their overall denial rates. They contacted The EDI Project™ shortly thereafter.
We created a new EDI Gateway that was capable of selecting which validations to fire at the gateway level specific to each line of business. Among other things, membership problems were moved from a DENIAL event to a REJECTION event so that improperly routed claims could be REJECTED up front using a 277CA instead of affecting their denial rates with the state.
Often, if a system is collecting risk adjustment encounters in a capitated environment, there is no ability to deny any submissions which makes this sort of architecture very useful in managing collection of EDI encounters as well.