Getting Ready for HIPAA: An Impact Analysis

Part 1: Executive Summary

This report examines the impact that the Healthcare Insurance Portability and Accountability Act (HIPAA) will have on the electronic commerce initiatives of healthcare providers and payers (insurance companies and healthcare maintenance organizations) striving to comply with new IT requirements taking effect on October 16, 2002.

There is much more than meets the eye in meeting the requirements of HIPAA. While many organizations in healthcare are anticipating a simple software adjustment to their communications applications, it is now becoming increasingly clear that, in addition to adopting national e-business standards like ANSI ASC X12 transaction sets, HIPAA compliance will also require a significant amount of work on internal enterprise applications.

This report concludes that both the healthcare community and the information technology vendors that support it will need to undertake a significant amount of preparation and education in order to ensure compliance by the HIPAA deadline.

The IT departments of healthcare companies in the United States face an acronym-imposed deadline for the second time in nearly two years, and the consequences of HIPAA may be more far-reaching than Y2K. The reason: where Y2K required organizations to identify and remedy programming code--a labor-intensive but operationally straightforward challenge--HIPAA mandates that by October 16, 2002, healthcare organizations adopt national standards for electronically processing administrative and financial transactions.

The new standards requirements will redefine the exchange of data behind a wide range of healthcare transactions, including:

  • Eligibility
  • Coverage
  • Benefit inquiries
  • Benefit information
  • Healthcare claim status requests and notifications
  • Healthcare services review information
  • Payment/order remittance advice
  • Benefit enrollment
  • Healthcare claim payment/advice

Beyond changing the business applications that healthcare providers and payers currently use to comply with voluntary national standards, it is increasingly clear that many organizations will have to adjust their business conventions--the way they actually operate--to comply with the HIPAA mandate.

For instance, HIPAA will require use of American National Standards Institute's (ANSI's) Accredited Standards Committee (ASC) X12 electronic data interchange (EDI) syntax. The X12 997 Functional Acknowledgment transaction set will be required to identify receipt and accept or reject a transaction based on whether or not transmission conforms to the syntax. But it will also require the X12 824 Application Advice transaction set to report application-level errors to the sending party. In other words, the HIPAA requirement dictates how the transaction set should be processed by the application after it has been translated.

Converting to these transmission protocols and application standards will require a great deal of effort by these organizations, since many currently use their own legacy methods and procedures for treating the information involved.

The Health Care Financing Administration (HCFA) Private Sector Technology Group has pointed out that under HIPAA, the legacy Medicaid Management Information Systems of most states will not be able to accept and store the new formats and certain information segments required by HIPAA.

"They will have to find other ways to generate data that is missing from the HIPAA format but is required by the state for processing."--HCFA Private Sector Technology Group, Use of Translators or Clearinghouses for HIPAA Compliance (November 2000).

To further add complexity to the mandate, HIPAA also places certain restrictions on the ways in which the X12 standard will be implemented. The mandate comes part and parcel with its own implementation guide detailing precisely how organizations in the healthcare industry must manage their X12 implementations. In short, the ramifications of HIPAA don't stop at the EDI translator and mapping applications. Organizations will have to dedicate time and significant effort to evaluating how current business processes and internal applications will be affected by the mandate.

Part 2: Ready or Not for HIPAA

The question of whether the healthcare industry is ready for HIPAA is academic, since the legislatively mandated deadline does not offer healthcare organizations a choice in the matter of compliance (unless one considers remaining on--or reverting back to--manual, paper-based operations). As a result, many organizations are scrambling to test existing applications and processes to determine whether or not they will be capable of meeting HIPAA requirements. Many are discovering they are not in compliance, and the scope of the problem makes it unlikely the HIPAA requirements will be easily met.

A great percentage of players in healthcare have not even begun to define--much less implement--a HIPAA migration strategy. But this has not been due to negligence or denial. Although HIPAA was passed in 1996, there have been significant delays by HIPAA officials in defining which transactions will be affected and how implementation will be carried out.

A recent Gartner Group study reveals that 85 percent of healthcare providers have yet to complete assessments or gap analyses, which form the critical foundation for achieving HIPAA transaction compliance. According to the survey, 68 percent of respondents are uncertain about the ultimate deadlines for compliance, and many have doubts on whether HIPAA itself is here to stay.

"These doubts, driven by continuing lobbying efforts and bills in Congress to effectively kill the regulation with a two- to four-year deadline extension, are severely damaging the HIPAA transaction regulation compliance effort," says Matt Duncan, Gartner research director and author of the study.

Still, the October 2002 deadline--and the threat of large fines for organizations that don't process transactions in the approved formats--has created a sense of urgency in the healthcare industry that is analogous to the Y2K problem.

The information technology vendor community, on the other hand, is ready in many ways for HIPAA. The X12 list of approved healthcare electronic transactions was issued in August 2000, and some technology vendors (translation software providers and value-added networks) have implemented them, putting them in a position to provide valuable assistance to healthcare organizations.

However, e-commerce generalists have not gone beyond the technical requirements for the transaction sets to develop strategies for implementing the EDI standards in the context of HIPAA's application management mandates. Too many EDI software vendors and their customers do not yet realize that an entire underlying set of requirements, rules and guidelines unique to the healthcare industry must be taken into account when implementing the EDI transaction sets. They will find that many of their translators and processes may not be able to handle the transactions under HIPAA because they deal with them strictly from a transactional standpoint and do not address the business process issues that must be addressed.

Concerns and Misunderstandings

Beyond the e-commerce technology provider community, there is also significant concern about whether internal enterprise software application vendors--such as claims processing, accounting and patient record-keeping functions--will be able to modify their applications to bring them into compliance with HIPAA before the October 2002 deadline. At the same time, numerous studies have analyzed the costs of bringing applications into compliance and have concluded that even minimal modification can cost millions of dollars because of the numbers of people and processes affected.

It may well be that compliance with HIPAA will require significant modification, or even replacement, of existing applications. It could mean healthcare organizations will be forced to bring in new technology that will introduce entirely new processes and new approaches to transaction exchanges. In the latter case, it may mean that an organization which had previously used only claims and claim payments electronically will have to expand its support of electronic transactions it may never have used in the past.

The HIPAA requirements will also impose new security standards that were not used in proprietary networks or information clearinghouses in the past. Thus, conforming to HIPAA-mandated standards will now require implementing new kinds of security and privacy regulations in addition to new data exchange processes.

Many healthcare companies accustomed to dealing with electronic transactions may not be familiar with the X12 standards committee or understand the EDI processes now required by HIPAA. They may have dealt with standardized transactions--for example, the commonly used HCFA 1500 claim. But it does not correlate very well in structure with the X12 837 Claim transaction set.

They may also believe that achieving compliance with HIPAA is "simply" a matter of making the HCFA 1500 format conform with the 837 format. Although the forms address the same claim issue, they are so radically different that organizations' HIPAA initiatives will require major changes in processes and application files to make HCFA 1500 compliant with X12 837.

Part 3: A Strategic Checklist

Because most healthcare organizations have been executing transactions electronically through proprietary applications and programs, they will have to purchase translation and transformation software that will convert data from their formats to the formats required by the X12 standards under HIPAA. Healthcare organizations will need to make sure that their software systems are not only capable of handling X12 transactions but are also capable of handling the business rules and communications security requirements being imposed by HIPAA.

Organizations must also make sure that, in addition to procuring the necessary software, their technology partners have the industry-specific knowledge needed to implement HIPAA requirements as well as software products. These are two separate though related issues. Many software providers may find that their existing staff cannot pull it off because they are not familiar with EDI or HIPAA or translator rules. The internal healthcare IT staffs as well as the technology partner organizations brought in to handle HIPAA implementation must be well educated about HIPAA requirements, the best practices that already exist and the current processes within the organization.

Healthcare providers and payers should also prepare to make HIPAA compliance an ongoing part of their business operations.

"The [HIPAA] regulations will continue to evolve, even after the first set of final rules is complete... [and] those rules will be updated and additional rules will be written." Sandra Fuller--from "HIPAA on the Job: Measuring HIPAA's Impact," Journal of the American Health Information Management Association (February 2001).

Putting off internal evaluations and decisions about HIPAA compliance will only compound the problems discussed in this report. Studies already show that each time a payer (i.e., insurance company) brings on a new healthcare provider, it takes an average of six months--from inception to production--to test and verify the transaction processing integrity between the two entities. This timeline will undoubtedly be elongated with the introduction of new HIPAA requirements.

To streamline an organization's HIPAA conversion, companies should reach out to technology partners with products and services that have been certified to support all required X12 transactions and HIPAA-mandated data handling requirements.

Translation products, in particular, should be flexible enough to use a variety of communications methodologies so that the system can easily accommodate emerging HIPAA transmission, encryption, authentication and digital signature requirements.

Finally, the strategies and products implemented by healthcare companies should be designed to easily integrate with existing applications that handle data conversions without having to recalculate, change or convert data.

Copyright © 2001 Extol International, Inc. All rights reserved.

To download the full white paper, "Getting Ready for HIPAA: An Impact Analysis," visit

About the Author

Extol International provides electronic commerce software for the midmarket enterprise, delivering solutions that are rapidly deployable and have a low cost of ongoing ownership. The company offers comprehensive B2B integration software applications for the AS400, NT and Unix platforms. Extol Integrator is a high-performance e-commerce system featuring partnership management, processing and integration requirements necessary for a wide array of business environments, including traditional X12 or EDIFACT-based EDI, the new frameworks of the XML initiatives and Web transaction management. Extol Portal utilizes IP technology to deliver partner connectivity and management. Extol Secure provides the Internet communications supporting most popular security standards, including AS1, AS2, SSL and digital certificates. For additional information about the company, visit

More by Extol International

About EXTOL International

EXTOL International, Inc. is a leading provider of B2B integration application software for the mid-sized enterprise.

EXTOL enables companies to exchange and integrate transactions and documents, regardless of form or format, between their applications and those of their partners. The EXTOL Business Integrator is an integration platform for electronic commerce applications including EDI, AS2, XML, UCCnet and the integration and management capabilities required to take full advantage of supply chain functionality. For more information go to