EXTOL Technology Blog

For this discussion, a “Staging Database” refers to any intermediate database that would fill the gap between Electronic Data Interchange (EDI) transactions and the backend business application. Whether obtained through a third party or developed in-house, some applications provide interface files that are “EDI Intelligent” and support the required EDI transactions. For applications that do not, the Staging Database should be considered for the following reasons and with the following purposes:

Data Grouping/Restructuring: Spreadsheet-type (SDQ) orders, where a single purchase order describes multiple ship-to destinations, might not be supported in the application because many applications define an order as a single ship-to destination. In this case, the single spreadsheet order needs to be broken down into separate orders by ship-to destination prior to insertion into the application. A multi-line order could have the same ship-to destination repeated several times. Therefore, data grouping would be required for later reorganization of all lines (for each ship-to) and transforming into a single order within the application.

The Staging Database would provide sorting/grouping functionality to support such reorganization. For example, an order with two lines, each having three SDQ pairs (defines the “ship-to location” and “quantity” breakdowns), and where one location is repeated on both lines, might result in six orders instead of five without such grouping.

Read more…

On January 16, 2009, United States Department of Health and Human Services published a final rule adopting X12 Version 5010 for HIPAA transactions.   

The compliance dates for Version 5010 for all covered entities, is January 1, 2012.  This gives the industry time to test the standards internally to ensure that systems have been appropriately updated, and then to test with trading partners before the compliance date.

This final rule adopts updated versions of the standards for electronic transactions originally adopted under the Administrative Simplification Subtitle of the Health Insurance Portability and Accountability Act of 1996.  In addition, this final rule adopts two standards for billing retail pharmacy supplies and professional services, and clarifies who the ‘‘senders’’ and ‘‘receivers’’ are in the descriptions of certain transactions.

The improved eligibility responses will improve efficiency for providers and reduce phone calls for both providers and health plans. Read more…

Throughout my time at EXTOL, I’ve been in close contact with the customer base. One topic of conversation that has consistently come to the forefront over the years is understanding exactly how much data your business integration software needs to “consume and digest.” In more cases than you would expect, a semi-understanding or lack of understanding exists in this area.

The true problem here is that if you don’t know how much you need to process and how it needs to be processed, future decisions will be difficult to make. Even if you believe that you understand your data requirements, perhaps a review is still worth your time, as it is much cheaper to pay now than later. Just this year alone, I’ve been involved with about ten customers who decided to review their consumption requirements. The research was positive in 100% of the cases. Even customers who were confident that they really knew their system came away with valuable information.

How do you truly know what your system needs to consume? Read more…

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.   Read more…

User (backend) applications are built using many approaches…and for many purposes. From database to flat-file to XML, and from third-party-acquired to in-house-developed, the solutions vary greatly. In-house-developed applications are typically the result of several hasty decisions made by organizations that generally include either or both of the following reasons:

1. The requirement (for now) is small – it will be quicker and less-costly to build an in-house solution while a long-term resolution is examined. Unfortunately, more often than not, the short-term solution becomes the long-term resolution, and ongoing challenges will bring about more long-term bandages.
2. It is believed that a third-party solution certainly could not provide the customization needed for the company’s business and therefore it would be most beneficial to build an in-house-designed application rather than buying and re-customizing portions of an available third-party system.

When coupled with the varying Business-to-Business (B2B) data formats and production requirements that frequently change from customer to customer, a company can quickly find itself trapped in situations where it becomes more costly to implement and maintain a new customer than the gained revenue by adding that new customer. Read more…

For my inaugural post on this blog, I want to revisit one of those “solved problems” that still dogs many of the companies we talk with, namely, how to handle B2B integration requirements that don’t involve standard EDI. Companies still find it difficult to cope with the full range of B2B connections and content types needed to integrate with large and small trading partners, including:

• Standard EDI (and in some cases, EDI that does not fully conform to standards)
• “Standard” XML, which ranges from well-developed, horizontal standards like RosettaNet to hundreds of loosely-defined vertical transaction sets
• EDI-like flat file standards (most of these are older, vertically-focused cases)
• EDI-based web forms
• Proprietary, partner-defined flat files
• Proprietary, partner-defined spreadsheets
• Proprietary, partner-defined web portals
• Proprietary, partner-defined documents sent by email or fax

Did I miss any? Probably. But the point is that standard EDI is just one of numerous conventions used for B2B integration.  Of course, standard X12 and EDIFACT EDI are still the mainstay of B2B integration. And there is little evidence to suggest that companies are ready to invest in replacing all of their EDI connections with something “better”.  In fact, EDI adoption is increasing.

Read more…