The great efficiency that we enjoy (or bemoan for some!) in our 21st century life is that information can flow at the speed of light as bit and bytes of data. It seems that what we enter and click on here shortly thereafter ends up in a delivery package there. All of this information fluidity has to move along in way that appears seamless, but if you lift up the hood, it’s a different kind of picture.
As data is entered in one system, it often changes--information gets added, information gets subtracted, information gets analyzed, or maybe information sets off waves of other information on other systems. Needless to say, a lot happens as data gets utilized!
Data needs sophisticated integration to move seamlessly from one system to another: flight scheduling systems need integration with ticketing and air traffic control systems; point of sale systems have to integrate with financial systems; manufacturing systems to inventory systems; and energy grid systems to metering systems.
Integrating different data systems allows you to collaborate with the same source of information to generate reports and perform analytics across different locations and saves you tremendous time with your team; data is transmitted and converted increasing accuracy and reducing data errors; increasing the value of data across systems to perform robust Business Intelligence.
Having systems talk to each other is no simple matter, of course, and doesn’t simply zap along magically!
Electronic Data Interchange, or EDI for short, is essentially a way of formatting data in an electronic document. Communication between two people from different countries can either go through an translator, which increases the back and forth, or by both parties speaking the same language for shared understanding. EDI is a way of formatting a business process transaction between different companies or different systems. In the context of healthcare, one claims management system for a provider entity will be able to communicate and submit information to a payor entity to transmit structured data across systems in ways that are usable and without human intervention.
It was not too long ago that transactional processes were disparate and governed by paper and forms. The manual overhead for submitting claims for providers to insurers, as an example, would require significant human interaction and oversight -- there were about 400 forms that could be in use. In response to this manual process climate, and in an effort to make healthcare transactions more efficient, the Workgroup for Electronic Data Interchange (WEDI) was formed. It had significant influence to the transactional data standards established by the passage of the Health Insurance Portability and Accountability Act in 1996.
From the establishment of HIPAA’s mandate for standardization, transactional data would be transmitted by the EDI protocol X12 which was established by the Accredited Standards Committee X12. It’s important to note that EDI is not healthcare specific, its association is often mentioned with healthcare because it is the major industry whereby EDI transactions are government mandated. There are a number of EDI sets, for example, that are enumerated--for healthcare, real time eligibility is in the 270-271 range set, claims status inquiry is 276-277. In fact, there are 15 transactional sets specified by HIPAA for data exchange in healthcare. Although related, each one is distinct in format and must be accounted for.
EDI allows for the exchange of data between computer systems in a standardized format and in a secured transmission (as HIPAA mandates) among providers, patients, and insurers. It allows the exchange of information of claims statuses and requests using standard transactional sets for systematic processing on both the sending and receiving parties with established compliance. Removing much of the manual overhead that existed previously in such transactions has lead to dramatically lower handling costs with mandatory security transmission.
The format is specific and unlike what may appear to be a flat file database (single line, single record, delimited). EDI messages have headers that identify the transactional set, and is further structured with a number of sections, or segments. These are further divided into fields (which can be further divided into components and subcomponents themselves), which use a value specified by the dataset type. These messages, segments, and fields are delimited by special characters specified by the standard in the header. Segments can also repeated in a message (loops), which adds another layer of significant complexity.
Given that these file formats are highly standardized, and could have escalating complexity, ingestion and processing of such files to the correct standard is critical. This type of data processing requires industry knowledge and the mandated infrastructure to ensure security of handling throughout the entire process.
Healthcare entities, such as insurers and providers, need to ensure that the information technology partners they work with have the highest level of security and a deep knowledge of X12 schemas and standards so that their data is processed with the utmost in efficiency and accuracy with minimal errors.
The problem with data processing/transaction vendors is that they typically either do not have enough EDI experience to successfully break down the X12 file formats -- often treating them like other data, flat files. This could prove to be very costly for the insurer and provider as EDI transactions are not processed accurately. On the other end of spectrum, are large vendors who have the industry specific knowledge, but have high cost barriers for that partnership.
At MXOtech, you can be assured that we maintain deep industry knowledge of EDI integration for the healthcare industry, while maintaining the boutique and personal interaction value in a partner. MXOtech maintains HIPAA compliance and is also HITRUST CSF certified, to ensure your custom web applications exceed the healthcare industry’s complex data privacy and security regulations.