The EDI Project
  • Home
  • Services
    • Anonymization
    • EDI Integration
    • RA Deletes
  • About
  • Contact Us
  • More
    • Home
    • Services
      • Anonymization
      • EDI Integration
      • RA Deletes
    • About
    • Contact Us
The EDI Project
  • Home
  • Services
    • Anonymization
    • EDI Integration
    • RA Deletes
  • About
  • Contact Us

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.

The EDI Project Inc.

42526 Lyles Dr. Temecula, CA 92592

7606024394

Copyright © 2024 The EDI Project - All Rights Reserved.

This website uses cookies.

We use cookies to analyze website traffic and optimize your website experience. By accepting our use of cookies, your data will be aggregated with all other user data.

Accept