Preparing for 5010: Internal testing of HIPAA Transaction Upgrades recommended by December 31

By Jim Moynihan, MBA, FHFMA, CTP, CHBME

Vendors will bear the brunt of work tied to the industry’s migration to version 5010 of the X12 HIPAA transaction standards. However, providers are responsible for identifying their systems in need of upgrade, getting software installed and tested, and training staff in new functionalities. When’s the best time to start? Now.

In January 2009 the Department of Health and Human Services mandated that health plans and provider organizations migrate to upgraded standards for electronic claims processing by January 2012. The upgrade is necessary to support the industry’s migration to the ICD-10-CM/PCS coding classification by 2013.

The shorthand for this change is to migrate or upgrade from version 4010 X12 standards to version 5010 X12 standards. Failure to make the change in a timely basis exposes providers and payers to penalties. Perhaps worse, there is a risk that noncompliance might result in unpaid claims and a resulting reduction in provider cash flow.

The task of achieving compliance will vary greatly from one organization to another, but all organizations should begin with an evaluation of both the risks and opportunities created by this latest regulatory mandate.

The concept of “opportunities” may seem foreign to compliance-burdened providers. However, all of the HIPAA transactions were mandated based on a consensus that standardizing and automating the major exchanges between health plans and providers can eliminate enormous administrative waste. The vast majority of the changes in the HIPAA transaction standards were designed to give providers more robust information and achieve more uniform utilization across all payers.

So when an organization undertakes this transition, its thoughts should be not only on “compliance” technically defined. It also should focus on how to increase the number of transactions done by computer rather than exchange of paper documents or time-consuming phone calls and Web searches.

When to Start

Covered entities should be prepared to meet two deadlines, according to the regulation mandating the upgrade: an interim “level 1” milestone completed by December 31, 2010, and full “level 2” compliance by December 31, 2011. On January 1, 2012, providers, payers, and clearinghouses must be using the new standards exclusively.

The regulation defines level 1 compliance as the completion of internal testing to determine if the covered entity can receive or transmit the HIPAA-compliant transaction. Level 2 is end-to-end testing, which would mean, for example, sending a HIPAA-compliant file from a provider through a clearinghouse and having a successful receipt by an insurance company.

Based on these deadlines, providers that have not performed a gap analysis should do so immediately, and they should obtain a clear timeline from each of their affected vendors on the availability and price of upgrades for level 1 compliance.

On a parallel track the provider’s clearinghouse and related “connectivity” vendors should have a game plan for using the enhanced functionality of the upgraded software and managing the implementation of the new standard transactions with the myriad payers out there. This sounds simple at a high level, but how costly and complex will it prove to be?

In all likelihood most providers will not require anything like the intensity of the Y2K or original HIPAA implementation. The bulk of the changes are improvements to the standards where modifications clarify use and eliminate some ambiguity or confusion in the original implementation guidelines. There are some changes in field lengths that create more of a headache for older systems than for newer, table-driven systems.

For most providers who do not maintain their own systems the work of writing the software code to support these transactions is the responsibility of a vendor. However, this may not mean the upgrade will be easy, rapid, or inexpensive. There is reasonable risk that some unintended consequence of the change can magnify the impact of the project.

For example, a practice management system vendor may offer an upgrade but tie other changes to the software enhancement that will require major retraining efforts for all staff. That software upgrade, packaged with other changes, might require hardware or network upgrades as well because the new software requires more computer horsepower than the current organizational system has. These changes are only indirectly related to the actual X12 standards changes, but in such an occurrence the provider would face a significant resource requirement to meet all deadlines.

So while the good news may be that the transition is relatively minor there is enough risk of complications to treat this very seriously and more importantly to begin immediately. Providers are encouraged to use 2010 to manage the software upgrades that may impact their hardware, software, and people. They will require 2011 for level 2 testing, when the many and varied payers have to connect with thousands of providers in this transition.

Where to Start

The foundation step in the conversion is identifying where HIPAA transactions are used in the organization and what application programs or business processes they impact. This is a two-step process known as taking a systems inventory.

Some organizations may have maintained an inventory of HIPAA transaction use since HIPAA was initially implemented in 2003. Others may not have kept that inventory analysis up to date as organizational mergers and acquisitions or IT installs have changed the utilization of the transactions.

Clearly the revenue cycle is a key department, and the practice management or patient accounting systems are the prime focus. More complex health systems have retail pharmacies, medical groups, hospitals, and other subsidiaries that all generate claims. Some even own health plans or third-party administrators that administer claims-paying operations. The list of systems and business operations affected by HIPAA transactions varies widely.

The second step is to determine the players who will get the organization to both level 1 and then level 2 compliance. The primary partners in this effort are the application program vendors that support file processing for either outbound or inbound transactions. Some providers support electronic data interchange (EDI) or e-commerce departments that also map flat files from application programs into the transaction standards. For those organizations, the EDI department bears a key responsibility for compliant transactions. Most providers outsource that work to organizations such as clearinghouses.

Organizations with an up-to-date inventory of applications that use the HIPAA transactions standards will be able to quickly identify all their vendors. Again, the inventory a provider organization did for the initial HIPAA implementation may have changed. The revenue cycle team may have added a denial management package that works in uploaded remittance data using a HIPAA transaction. The organization’s bank may be providing a service that ties those electronic remittance data to associated electronic funds transfers.

Ultimately the compliance team has to play both detective and management consultant. As a detective they need to identify every use of a HIPAA transaction standard. As a management consultant they should be thinking about how increased or improved use of these transactions can save the organization time and money.

Following are some guidelines for that analysis by transaction standard and the implications for applications vendors and network service vendors such as clearinghouses and banks.

Claims: 837 and NCPDP Standards

It is highly likely that an organization’s patient accounting, practice management, or pharmacy systems vendors will be responsible for providing the health system with an upgrade to support data elements needed in version 5010. Information about the upgrade and its related price should be in the organization’s hands today.

These upgrades likely will not be solely related to version 5010. Many other fixes, patches, and enhancements will be scheduled for releases marketed under the “5010 compliant” banner. Organizations should watch for requirements at the state level that may also require updates (Minnesota being the prime example).

While most attention is placed on medical and hospital claims, many health systems have retail pharmacies, and they must migrate to the new NCPDP standard within this mandate as well.

As mentioned, the biggest conversion risk is vendor software upgrades that include so many changes that staff need to be retrained and bugs need to be worked out. The timeline to achieve level 1 compliance by the end of this year may be tight, because many providers are going through these upgrades and vendors have limited resources to manage all the conversions. Starting early may be very important given the crunch that may occur. This is the transaction that has the greatest risk of impacting cash flow if not done correctly or on time.

On a parallel track, every provider should be in dialogue with its clearinghouses (or with its payers, if the provider is a direct submitter) about level 2 compliance, the testing of transactions all the way through to the payer. Most clearinghouses have table-driven software, and they should have limited issues in the conversion process. The challenge will be the large number of payers and how quickly they complete their own system upgrades. The payer community undoubtedly has a major challenge, but the upgrade has no contingency period, and the compliance deadlines are firm.

Eligibility Inquiry and Response: 270-271 Standards

Providers obtain eligibility information from patients, via EDI inquiries, Web sites, and phone calls. The potential benefit of getting up-to–date, accurate, and complete eligibility information without human intervention is astronomical.

The first implementation of the HIPAA 270-271 standard failed to achieve that potential because payers did not populate an eligibility response as robustly as they populated a Web site performing the same function. The 5010 version of the eligibility standard solves some issues that bedeviled exchanges (such as properly identifying the patient versus the subscriber) and requires greater detail from payers in eligibility responses.

What should providers examine? Usually providers use an eligibility vendor or clearinghouse that processes a data feed from the underlying health information system. That feed should be examined for completeness in consultation with the eligibility vendor to ensure that the provider is passing as much detail as is needed for an accurate and complete outbound inquiry.

At the same time providers should determine if they have the optimum capability to display and retain more robust response information. It would be a waste to get back a complete 271 response from a payer and find that the data dropped through a crack and were never captured in the system or used by staff.

While “compliance” will probably not be a challenge for provider eligibility processing, the savings opportunity could be significant. There is no reason why staff should be on the phone or the Web getting eligibility information if the system can obtain it without human intervention. The standard is not the issue; the work process improvement to use the standard is the issue. Preparing for enhanced eligibility processing is once again about talking to application system vendors related to “background” or batch processing of eligibility transactions.

Claims Payment: 835

The claims payment transaction is sometimes called an electronic remittance advice. Many hospitals elected to adopt the 3010 version of the 835 in 1993 for Medicare Part A payments and upgraded to the 4010 version by 2003 because of the HIPAA mandate.

The magnitude of upgrading to 5010 may vary widely. A provider that has three payers sending 835s and a staff of people key-entering the remainder of its claim payment data has less work for the transition than a more automated shop that has 50 payers from whom it receives electronic remittance data.

As is the case with claims, the provider is usually dependent upon the application program vendor that provides autoposting functionality in the patient accounting or practice management system. The changes to the 835 are relatively minor, but the application vendor should use this opportunity to improve the functionality of the posting logic.

One commonly encountered problem with practice management systems is their inability to process a claims-level denial where the insurance company denies the entire claim. These vendors require a service line denial message for every service line. This requires insurance companies to create different 835 interpretations for hospitals that post at the claim level and medical groups that post at the line level. Some practice management system vendors will build new autoposting logic that supports a HIPAA-compliant claim level denial, thus expanding the payers a facility can deal with.

This transition, too, may illustrate a minor compliance challenge but a major opportunity. If the facility is only processing electronic remittance advice from three payers, why not use this upgrade as a catalyst to implement it from most, if not all, of its payers? This is particularly true in states like Minnesota, where recent legislation mandates that all payers, including workers compensation and property and casualty payers, support the 835.

Organizations will need to check with their vendors to see if state-specific mandates are supported for their states. As was the case with the claim transaction, organizations should be in dialogue with their remittance-processing vendor, which may be a clearinghouse or a bank. Given that drafts of both the Senate and House healthcare reform bills have an electronic funds transfer mandate, providers may expect to see fewer checks. There are two compliant HIPAA payment formats for electronic funds transfer, and providers should be working with their banks on the optimum solution for reassociating dollars and data sent separately.

The Opportunities

Many providers will find that their institutions currently do not support a number of the HIPAA transaction standards. Those who are compliance-minded may breathe a sigh of relief that they have only one less standard to consider. But what about the lost opportunity?

The following standards are not widely implemented, and for most providers they represent more of an opportunity than a compliance issue. Entities can at least consider what efficiencies and savings they offer as they plan their upgrades to 5010.

Referrals and Authorizations: 278

The improved 278 can eliminate many of the phone calls, faxes, and other communications between payer and provider and leverage the scarce resources of the utilization review and case management staff. It can also provide an audit trail superior to certifications received by phone and fax, which may come in handy to the denial management team.

Providers with a substantial book of managed care business should look at the merits of a 278 project to determine how they and their payers could utilize it.

Claims Status Inquiry and Response: 276-277

The 5010 standard modifies the claims status inquiry and response exchanges to correct some shortcomings in the original implementation guidelines. Instructions are now clearer, and greater detail can be reported. This is an underutilized transaction, and providers should consider how they and their payers are taking steps to eliminate the black hole into which some claims appear to drop.

The original mandated transaction standards were based on recommendations presented to Congress by WEDI in the early 1990s and specified in the HIPAA legislation in 1996. While laudable, acknowledgment transactions were not mandated and thus not on the “compliance checklist” in 2003.

There are several acknowledgment transaction standards. Key among them is the 997, or Functional Acknowledgment standard, which is essentially an electronic return receipt notification. In payer-provider exchanges providers want to know the status of the items that make up their working capital. The acknowledgment transaction gives providers confidence that their claims have been received.

Similarly the claims status exchanges (276-277) provide information about received claims that often require additional information to be paid. The industry will make fewer phone calls and have speedier access to claims status with the widespread use of both acknowledgments and claims status transactions.

Enrollment (834) and Premium Payment (820)

These standards are placed together here because in some way they are two sides of the same coin. Unlike all the other transactions that are exchanged between the revenue cycle professionals and health plans, these are housed in the human resources department.

Providers have a vested interest in widespread utilization of the 834 to automate the transmission of enrollment files. How many retroactive denials have institutions faced because an employer neglected to tell the health plan in a timely fashion that an employee had left the company?

The 834 is a best practice adopted by some institutions, including the University of California system, in an effort to provide payers with accurate, up-to-date information. In the university’s case, it also happened to discover a $750,000 billing error when it enjoyed better controls over an automated process.

The premium payment transaction (820) is a variation of the X12 standard used for all nonclaims payment. It should be what all health systems use to pay their primary distributors and key vendors. Many organizations are sending enrollment information on paper and dealing with payments by attaching a check to a large printout of employee names.

Adopting electronic enrollment can provide organizations with more timely, accurate, secure, and complete enrollment. The benefits include timely issuance of insurance cards and address changes. Adoption of financial EDI for premium payments may be the catalyst to more widespread EDI vendor payments and other ways to eliminate checks and use of paper.

Whether focused strictly on compliance or exploring opportunities, the time to begin the 5010 upgrade is now.

Jim Moynihan (james.moynihan@usbank.com) is a senior vice president at U.S. Bank Healthcare Payments.