Driven by consumer demands for more efficient Healthcare services at reduced costs, President Clinton signed into law the Health Insurance Portability and Accountability Act of 1996, better known as HIPAA. This law gave the Department of Health the job of mandating standards Healthcare EDI. While attempts to standardize the transfer of Healthcare information have been attempted since the advent of EDI, the first concerted effort to establish standards occurred with the establishment of the Workgroup for Electronic Data Interchange (WEDI) in 1993. While initially suggesting many changes, the U.S. government has now mandated that the proposed standards be applied throughout the industry.
As with any major shift in an industry, the establishment of standards has gone slowly. The first approaches to implementation were published in mid-August 2001 that stated that all doctors, hospitals, health plans, and clearinghouses will begin to start implementing the new federal Electronic Data Interchange (EDI) standards. All Healthcare data transmissions must adhere to these standards, but the required security standards have, by far, the most wide-ranging impact on the industry. These mandated HIPAA standards are having a significant impact on the entire Healthcare industry. The key thing to remember is that insurance companies will shoulder the majority of the burden of compliance to HIPAA as they must convert their systems to accept and implement these changes. The focus in the next few years will be on the implementation of EDI for basic Healthcare business processes which include claims transactions, remittance advices, enrolment and eligibility transactions.
The implementation of "standards" to electronically transfer information in the Healthcare industry has been a long time in coming. Industries such as the Financial Services, Retail and Logistics have had market pressures to force them to reduce processing costs. These industries have log been proponents of standardized electronic transfer of information (EDI) within their industry. By contrast, the Healthcare industry, focused on providing service as providers, has not, as a whole, taken advantage of technology to a similar extent.
The root cause of this lack of action is that the Healthcare industry frequently considered technology a "necessary evil" and has been implemented only as required. In addition, implementation of technology was frequently based on a single company's perspective without concern for all players in the Healthcare industry. Since each system was custom designed and built to a somewhat unique specification, the problem of implementing systems became more and more difficult. What was required was a unifying force to establish standard ways of communicating Healthcare information between players in the industry.
The driving force behind HIPAA is simplification. Traditionally, there were over 400 different medical form "standards". Each of these was supported by a complex, manpower and resource intensive system. People familiar with every "standard" format are required in various roles in every Healthcare company. The costs of training, turnover and the inherent introduction of errors in processing were staggering. The value in implementing HIPAA is cost savings through electronic transfer of information and simplification of the process.
HIPAA and EDI Today
At present, the Healthcare industry working through the process to define and implement standards for all flows of information in the industry for all participants. As you can imagine, the process is slow as there are so many interested parties and business processes in the industry to consider when defining the implementation of EDI. For a flavour of how the industry is doing, the following is a sample of the transaction sets that have been defined for implementation.
EDI Health Care Claim Transaction set (837)
The 837 transacation is used to submit health care claim billing information, encounter information, or both. It can be sent from providers of health care services to payers, either directly or via intermediary billers and claims clearinghouses. It can also be used to transmit health care claims and billing payment information between payers with different payment responsibilities where coordination of benefits is required or between payers and regulatory agencies to monitor the rendering, billing, and/or payment of health care services within a specific health care/ insurance industry segment.
For example, a state mental heath agency, may mandate all healthcare claims, Providers and health plans who trade professional (medical) health care claims electronically must use the 837 Health Care Claim: Professional standard to send in claims. As there are many different business applications for the Health Care claim, there can be slight derivations to cover off claims involving unique claims such as for Institutions, Professionals, Chiropractors, and Dentists etc.
EDI Health Care Claim Payment/Advice Transaction Set (835)
The 835 EDI transacation can be used to make a payment, send an Explanation of Benefits(EOB) remittance advice, or make a payment and send an EOB remittance advice only from a health insurer to a health care provider either directly or via a financial institution.
EDI Benefit Enrolment and Maintenance Set (834)
The 834 EDI Transacation can be used by employers, unions, government agencies, associations or insurance agencies to enrol members to a payer. The payer is a healthcare organization that pays claims, administers insurance or benefit or product. Examples of payers include an insurance company, health care professional (HMO), preferred provider organization (PPO), government agency (Medicaid, Medicare etc.) on any organization that may be contracted by one of these former groups.
EDI Application Advice (824)
This transaction set can be used to report the results of an application system's data content edits of transaction sets. The results of editing transaction sets can be reported at the functional group and transaction set level in either coded or free- form format. It is designed to accommodate the business need of reporting the acceptance/rejection or acceptance with change of any transaction set. The Application Advice should not be used in place of a transaction set designed as a specific response to another transaction set (e.g., purchase order acknowledgment sent in response to a purchase order.)
EDI Payroll Deducted and other group Premium Payment for Insurance Products (820)
This transaction set can be used to make a premium payment for insurance products. It can be used to order a financial institution to make a payment to a payee.
EDI Health Care Eligibility/Benefit Inquiry (270)
The 270 EDI transacation is used to inquire about the health care benefits and eligibility associated with a subscriber or dependant
EDI Health Care Eligibility/Benefit Response (271)
The 271 EDI transacation is used to respond to a request inquire about the health care benefits and eligibility associated with a subscriber or dependant
EDI Health Care Claim Status Request (276)
This transaction set can be used by a provider, recipient of health care products or services or their authorized agent to request the status of a health care claim.
EDI Health Care Claim Status Notification (277)
This transaction set can be used by a health care payer or authorized agent to notify a provider, recipient or authorized agent regarding the status of a health care claim or encounter, or to request additional information from the provider regarding a health care claim or encounter. This transaction set is not intended to replace the Health Care Claim Payment/Advice Transaction Set (835) and therefore, is not used for account payment posting. The notification is at a summary or service line detail level. The notification may be solicited or unsolicited.
EDI Health Care Service Review Information (278)
This transaction set can be used to transmit health care service information, such as subscriber, patient, demographic, diagnosis or treatment data for the purpose of request for review, certification, notification or reporting the outcome of a health care services review.
EDI Functional Acknowledgement Transaction Set (997)
This transaction set can be used to define the control structures for a set of acknowledgments to indicate the results of the syntactical analysis of the electronically encoded documents. The encoded documents are the transaction sets, which are grouped in functional groups, used in defining transactions for business data interchange. This standard does not cover the semantic meaning of the information encoded in the transaction sets.
HIPAA and EDI - The SoftCare Approach
SoftCare recognizes that for many organizations involved in the implementation of HIPAA, there are simply too many things to do to effectively integrate their back-end systems with the information needed to create EDI documents to comply to HIPAA's requirements With that in mind, SoftCare has created its HIPAA Quick Start Program, which is a comprehensive program for Healthcare organizations to link and utilize their information to create the necessary EDI documents. The final solution provides a centralized EDI management system to audit, manage and control the movement of information from an organizations back-end systems right through to its trading partners.
SoftCare's HIPAA Quick Start Program provides the software and services, required to implement HIPAA EDI for the Healthcare industry. The SoftCare Solution's Group provides necessary consulting services to determine:
• Where the required item information resides (internally and externally)
• What transformations are required to format the information to your EDI trading partners needs
• How the EDI documents should be passed to your trading partners
• What is the most cost effective method to communicate EDI documents
• What is the business process to move the information to your trading partner
Once the implementation "roadmap" is completed, the next step is to implement the solution to export data from a company's back-end systems, transform it and communicate it to your trading partners using the OpenEC? TradeLink EDI Management System. This step involves working with a company's staff to configure TradeLink to meet their business processes. Once completed, the Solutions Group will test with a company's trading partners and train internal staff on how to implement future partners within TradeLink. The key to SoftCare's Quick Start program is to provide the software and services required to implement HIPAA EDI quickly and efficiently.
Some of the key features of TradeLink are:
• Support of all ANSI X12, UNEDIFACT, HIPAA and xCBL standards
• Support for EDI over the Internet using our AS2 compliant EDI communications module. This allows for communications using secure email (S/MIME), secure HTTP ( HTTPS) or secure FTP (FTPS) for reduced communications costs
• Event Driven Alert Manager of EDI/XML business processes to allow the end user to receive email notification of problems in document processing in real-time
• Simple complete Business Process Management using Web services and BPEL to fully integrate the business processes to move business documents of any format to/from organizations back-end systems.
• Extended Mapping Functionality to quickly and efficiently define and manage XML transformations to move EDI, XML or Flat Files from/to TradeLink to/from business systems.
• Superior audit to track the movement of documents from an organizations back end applications to/from its trading partners.
• Graphical web based front end allows for distributed or centralized document management.
• Multiple consistent levels of audit (Operations Summary, Business Process, Task, File and Document) allow an end user to quickly identify and efficiently track document "problems".
• Concise and complete reporting of all processing in one report. The Audit function allows the user to generate reports on all EDI activity in whatever time frame necessary
• Payload independent secure routing of all data types, including any XML, EDI, TXT, ASCII and Binary formats to external or internal trading partners.
• Risk-free migration from VAN, direct-connect and paper communication methods
• Built-in transaction tracking, reporting and data retention with actionable audit trails and persistent queuing
• Operates on UNIX, Linux, NT, XP, Windows 2000.
Copyright 2011, Skillsight Inc. Terms of Use - Privacy Statement All Rights Reserved
Back to the top