This blog is to outline the 5 basic, simple and easy ways to be in compliance with EDI standards. These are generic rules and don’t pertain to any specific field or domain. While there is clear regulatory requirement for compliance with specific EDI standards, there is no such stipulation about certification, so it is the responsibility of the implementer to make their documents in compliance with EDI standards. However, on the other hand for health care HIPAA rules recommend that you do a minimum level of certification. Below are few points to consider being EDI complaint.

Knowledge : Understand your trading partner’s implementation guidelines like

  1. What version of EDI they use?
  2. What transaction sets they support?
  3. What are the sender\receiver ids?
  4. What are their segment\element delimiters and so on?

Define: Invest time to define your EDI implementation guide. This will act as a black book for your trading partner to implement documents that your system understands. Believe me it’s worth the pain. With this you are saved from not implementing multiple version of solution one for each of your trading partners to process same transaction type.

Tools: Use proper tools\technology to translate your data to given EDI standards. There are advance tools available which helps to maintain the mapping between your source and target at the same time maintaining dictionary to compliance with standards. Sterling Integrator, iWay Service Manager and BizTalk are very common tools used by many enterprises. Strict compliance with these standards is essential if EDI files are to be processed properly.

Data Validation: Validation of newly created EDI documents before transmitting ensures that the data you create conforms and does not create issues for your trading partners. As the trend in the industry is to consider fines for non-compliance, verifying that the data you create is compliant and is of key importance. Validation ensures more accurate EDI translation and a more robust automated process by detecting and rejecting EDI files with anomalies that could break the translation program and interrupt production.

Testing: Adequate testing; In case of Health care transactions, The Strategic National Implementation Process (or SNIP, the group constituted under the Workgroup for Electronic Data Interchange to guide the healthcare industry in an orderly implementation of HIPAA-compliant EDI) has recommended transaction testing prior to “going live” with standard format transactions. SNIP has recommended testing in seven categories, commonly referred to as types:

Type 1: Integrity Testing (X12 Syntax)
Type 2: Requirement Testing (Implementation Guide Syntax)
Type 3: Balancing Testing
Type 4: Situation Testing (Implementation Guide “Situational Elements”)
Type 5: Code Set Testing
Type 6: Specialty or Line of Business Testing
Type 7: Trading Partner-Specific Testing

The entire above are helpful if you are at entry level into EDI transaction management. However EDI integration is big space where plenty of tools, technologies and hosted services are used by many enterprises. The transactions types and standards are also varying depending on the industry and business operating model etc. More domains specific EDI best practices will be published soon so please keep track of our blog space.

Note: The above article is authored by Mr.Ratnavel Sundaramurthi from Enterprise Integration & Information Management Practice @ Aspire Systems.

Data 360 view connecting the data dots with boomi ipaas whitepaper