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
How many times have we needed to format some data quickly and reached for our favorite spreadsheet application? I am just as guilty of this as you are. Or maybe we needed to send data to someone, but weren’t sure what capabilities they had to parse out a flat file. The spreadsheet has been the Swiss Army knife in our IT toolboxes for years.
As our businesses drive us to leverage integration to reduce costs, we typically look to the large implementations for ROI. However, there is some low-hanging fruit that just requires us to think a little differently about an age-old problem; dealing with customers that eschew technology. These are the customers that are still faxing orders to you. They do email, hopefully, but one thing they do know how to use is a spreadsheet.
Spreadsheets do have valuable integration use cases, both inside the business and externally. An application example that comes to mind is mining shipment data from a database and producing the data in a format suitable for business end-users. Dumping the data to a comma-separated-values (CSV) file is quite limiting in presentation control. Yes, the data is all there, but the end-user is still going to spend time “prettying up” the contents. Printing a report to PDF also gets the job done, but it’s still just a report. Wouldn’t it be useful to query the data and easily put it into a spreadsheet that encourages user interaction? This approach takes the data publishing paradigm one step further, enabling the end-user to interact with the data and empowering them to draw new insights that are beneficial to the business.
Spreadsheets have become a du jour “standard” for some forms of Business-to-Business integration, offering a data representation that is easy to produce and consume, and is widely supported across industries and geographic boundaries. Spreadsheets are also very portable; they can be emailed, viewed across platforms (Microsoft Windows, Apple OS X, Linux) and are accessible by many software packages (Microsoft Excel, OpenOffice, Google Docs).
Using spreadsheets as an integration medium can be challenging, however, because the layout of data within a spreadsheet can vary. Spreadsheets aren’t always simple grids of rows and columns. Data can be represented in a tabular format, e.g., to transmit raw data from a back-end application, or in a forms-based layout, similar to what we might find in business documents like purchase orders and invoices. That flexibility makes the spreadsheet versatile and attractive as a data-publishing tool, but makes integration of some spreadsheet cases less trivial.
When it comes to solving data integration problems, we often overlook the system-level impacts of proliferating integration objects, increasing data volume, and increased logging activity. The tendency is to focus on delivering applications and to ignore broader consequences that could come back to bite us.
As an EXTOL developer who interacts with our front line support representatives several times a day, I have seen, first hand, the perils of poor system maintenance and not having a disaster recovery plan. There are three important points that need to be considered, to keep the ship sailing smoothly and to mitigate extended periods of downtime, should a disaster occur.