It is often a common practice of organizations to develop new EDI trading partners and transaction sets from within the same environment where production EDI trading partners and transaction sets already exist.
While this is possible, it can often be disruptive and dangerous as the results of test and modifications could inadvertently result in problems with production data.
Employing multiple EDI environments will make it possible for a single EDI translator to have access to (and use) two or more “EDI configuration areas”; for example, to separate all production configurations and data from development (or production division 1 from production division 2). Continue reading
Integration of data is the process of combining different data types into one or more shared universal formats. This process is integral to business as each unit within an organization can use different data types and therefore lack a unified view. Data itself can be of various types such as flat files defined externally or delimited by a common data separator. Data can also be stored in various kinds of databases, each with a unique method for defining and storing data.
For users of differing applications to view and use each others’ data it must be converted to the format of the other applications or to a universally defined format as is done through EDI transmissions. A data integration product makes this process seamless and fully integrated into a user application system. The software can either convert each application data type into every other type (a many to many conversion) or from one data type to a universal format – then from the universal format to a specific data type (a many to one conversion).
The use of a universal format is preferred as this makes it possible for each user to create applications and conversions based on an agreed upon standard (such as EDI: X12, EDIFACT, etc.). This will also removes the requirement that each system be aware of the file formatting or application setup/configurations used by the remote system. Each user employs the Integration software to map their data into a common and agreed upon standard…and vice-versa.
Successful EDI implementations must begin with the development and employment of proper naming conventions and best practices. Too often a company will make hasty decisions in an effort to implement an EDI customer quickly only to find that good practices were not put to use and the bad habits are then continued for all remaining EDI implementations.
When mapping, it is important to develop and standardize in-house naming conventions that can be used for all maps. This will help to identify maps and keep them organized. One recommendation is to use some variation or reference to the trading partner the map will be used for. Other suggestions may include using the document type, version, or division references in conjunction with the trading partner name. By using some of these methods in your map naming you will make it easier to identify the purpose of the map. Continue reading
The Healthcare industry is being mandated by the Government and HIPAA legislation to convert from X12 version 4010 to version 5010. Most companies aren’t being mandated by the government to switch versions, but by their strongly influential Trading Partners.
I think back to the late nineties when version 4010 came out and what a struggle it was for many Trading Partners to convert to that version. Most EDI Coordinators are fearful of those same struggles when going from 4010 to 5010 or any other version. Converting from one version to another version doesn’t have to be a major headache.
There are two main areas of consideration during your Version Conversion project: translation support and application support. Continue reading
If your company uses Electronic Data Interchange (EDI), reconciling Functional Acknowledgements, or “FAs”, or “997s” is important and often overlooked. Just because the FA is a small document that is automatically generated from your translator, doesn’t mean that it should be ignored.
The FA provides information on problems found with the structure or content of EDI transactions, such as a mandatory segment or element missing, or invalid code. It isn’t just a data receipt. So, FA reconciliation should not just ask the question, “Did I get an FA?” It should also ask whether the document has been validated. There are four validation statuses: A – Accepted; E – Accepted with Errors; P – Partially Accepted (at Least One Transaction was Rejected); and R – Rejected.
Your reconciliation process should be checking for Rejections, at a minimum, but also for Error and Partially Accepted states. Those states may reflect a change in standards or in your partner’s requirements that you haven’t taken into account or may not be aware of. They can also mean that you have provided incomplete or incorrect data. If E, R and/or P statuses are received on a regular basis, it may be time to check your mapping and application data for those transactions.
Ignoring the Error and Rejected statuses may be costly to your company, as those EDI transactions may not be fully processed by your partner.
So, remember the next time you consider the humble FA: reconciliation means more than, “Did I get an FA?”