When I talk to IT customers today, it is clear that they have to continue to “do more, with less” and squeeze value out of every penny. Not only can they not throw around the checkbook with reckless abandon, but they also have to be extremely careful that the checks they do write are going to good use. When it comes to EDI and integration, I’ve found that IT needs to avoid 3 kinds of boneheaded expenditures in particular:
- 1.Buying more than they actually need
- 2.Paying too much for what they buy
- 3.Buying something they won’t even use
I’ve seen enough dumb EDI integration expenditures (and made enough of them, in my day) to be able to tell you the six boneheaded checks that IT departments everywhere should just stop writing:
1. Standalone Managed file transfer (MFT) software
MFT is great for securely transferring data from one point to another, but it’s just one piece of a multi-step process. Since it’s a stand-alone commodity, it can’t handle a complete file transfer from end to end. Once MFT software is configured, it has to be integrated with other applications – you don’t just magically send a file from one location to another. After you send or receive a file, what’s the next step? Are you transforming the contents to a different format? Or are you importing them into a database or application? Integrating multiple applications in order to perform file transfers is time consuming and complicated. MFT capability is included within any respectable EDI integration solution and should not be purchased as a separate, standalone application.
2. Eclipse-based integration offerings
Eclipse-based integration platforms aren’t our favorite. In fact, we’d rather eat hot coals than use them. Eclipse-based software solutions are similar to MFT in the sense that they’re designed specifically for IT developers to use, and take forever to test. So companies who buy eclipse-based software end up depending on third-party solutions to complete a project. To add insult to injury, eclipse-based software does not enable collaboration. So in a nutshell, it’s a waste of time and money you’d be foolish to write a check for it.
3. Traditional EDI software
EDI software is a bad IT investment because it only works with EDI standards, meaning it doesn’t process other data formats. It’s not flexible, scalable, and can’t integrate with back-end applications. Without end-to-end automation, you lose visibility and jeopardize quality, since data has to be manually entered.
4. EDI VAN services
Value-added anything usually sounds good, but that’s not necessarily the case with value-added network services. You don’t want to write this check because the value-adds in EDI VANs can come at an even bigger added cost. During a company’s growth stage, scaling a trading partner network can add up quickly. What’s more, it’s difficult to securely control trading partner relationships – or at least not as securely as you need to, which is important because these relationships are the drivers behind your success.
5. Paying a development team to perform data integration
If you’re writing a check to outsource your data integration, costs could also add up quickly. For starters, you’ll have to pay someone else to create custom code for you. As if coding wasn’t hard enough, companies that outsource this process also have to relinquish upkeep responsibility to the developers who created it – and transparency in the entire process suffers as a result.
Speaking of which, the entire custom coding process takes close to forever if you’re having someone else do it for you. In today’s fast-paced business environment, a project that takes several weeks seems like an eternity. Think about it: You have to maintain operational functionality while testing and retesting, which doesn’t account for any kinks in the chain you may have to work out. When it’s all said and done, you could be paying more than $100,000 for something you could have avoided altogether if you had partnered with the right data integration vendor.
6. Paying a development team to onboard customer data
If you’ve paid someone to perform your data integration, you’re likely going to have to cut a check to a development team to onboard customer information as well. In addition to the heavy fee you’ll have to pay someone else to onboard your customers’ data, the process takes a really, really long time. Not only that, it’s a pain in the rear to figure out how you want that data on-boarded. Will it be via FTP? Email? Or a Web service?
The net-net
When it comes to EDI Integration, you don’t want IT writing any boneheaded checks for solutions that aren’t ultimately cost-effective (or are just plain ineffective). Be wise and take the time to research and find the EDI integration solution that delivers the ROI and scalability you need. You’ll end up saving your company a heck of a lot of time and money in the long run.
EDI 834s: A Major Highway in the Healthcare Industry
The healthcare industry makes great use of Electronic Data Interchange (EDI) transactions — understandably so, since there are many players involved at every stage of the game. The EDI 834 transaction is particularly key, as it represents a Benefit Enrollment and Maintenance document.
The information in an EDI 834 must be transmitted accurately since it contains vital member enrollment information. The EDI 834 flows between three entities:
- 1.The healthcare exchanges: Public marketplaces where consumers go and choose their health plans.
- 2.The brokers: Solution providers who ensure that enrollments made on the healthcare exchanges are correct. The brokers then map those enrollments to the preferred formats of the payers.
- 3.The payers: The insurance companies/carriers who own the insurance plans for the enrolled consumers.
Problems on the EDI 834 Highway
Unfortunately, transmission is not always easy or trouble-free, even with the EDI format. Data can get lost or corrupted in transmission, with negative impact on each of these entities and on the consumer.
For example, if an EDI 834 gets corrupted, people don’t get enrolled. Healthcare exchanges lose their credibility in the marketplace. Brokers don’t get notified of new clients. Payers can’t send invoices or get paid. The business of delivering healthcare crumbles.
Keeping the EDI 834 Highway Clear of Road Hazards
It is possible to have your EDI 834 transactions travel without any mishaps, simply by adding an EDI integration architecture with a services layer. The services layer allows you to manage the underlying flows without affecting how the EDI 834 files are transmitted. The services layer primarily consists of web services (SOAP or REST), mappings, meta-data of schemas, and business rules that are applied on the EDI 834 files.
Here’s what the architecture looks like:
The EDI 834 integration architecture removes all concerns with data formats. In fact, the data schemas of the inbound EDI 834 and outbound payer’s canonical formats do not need to be changed as you modify your underlying business processes over time.
With such an architecture in place, you can create ‘templated’ process flows to handle the common steps of data transformation and routing where the behavior of the process is determined by the type of data being received from a given source. For example, if a state sends an EDI 834 that requires specific handling in mapping, that particular map can be applied at runtime based on which state or marketplace is sending the file. Therefore, there is no need to create individual processes for each healthcare exchange.
If you are a player in the healthcare arena, an EDI 834 integration architecture is critical for your business. With data flowing effortlessly and accurately, you can deliver the service your partners, vendors, and customers are looking for.