TCS ICE: PROVIDER'S PERSPECTIVE

Issues, Concerns, and Enforcement of TCS Compliance From a Provider's Perspective

By Barbara McGowin, Resource Consultant, Connecting Healthcare Organizations with People, Products and Services to Achieve HIPAA Compliance

Introduction

On August 21, 1996, President Clinton signed into law the Health Insurance Portability and Accountability Act of 1996, Public Law 104-191 (HIPAA). In so doing, the health care industry was given a far-reaching and complex mandate that would impact every aspect of health care in the United States of America. After surviving multiple drafts, Y2K, addenda, and the Administrative Simplification Compliance Act (ASCA) enforcement extension, the HIPAA Transactions and Codes Sets (TCS) standards enter nation-wide production on October 16, 2003. This white paper addresses the issues, concerns, and enforcement of TCS compliance from a provider's perspective.

Issues

One of the more basic issues of claims adjudication with HIPAA Electronic Data Interchange (EDI) transactions is the concept of "paperless" or electronic claims. The use of technology to use electronic data interchange to cause an event, instead of using technology to produce a document which causes an event, is a concept that is difficult for some to grasp.

The Implementation guides for standard transactions are technically difficult. Most providers are relying on their business associate (BA) billing services and clearinghouses to compile the necessary data elements, and to send and receive compliant transactions on their behalf. Many providers must rely on their application vendor to provide a means of collecting and maintaining the data that is needed to provide their BA billing service/clearinghouse. In some instances, especially in large provider organizations, multiple applications and departments are involved in the collection of this data and are unaware of how this data affects transactions. The provider's reliance on business associates to achieve the technical requirements of EDI compliant transactions has caused many to forgo educating themselves on the general administrative requirements of the transactions and code set standards for electronic transactions. The provider's lack of understanding of the general administrative requirements makes TCS compliance hard, if not impossible, to manage.

HIPAA TCS transaction solutions are few and far between. Only in the largest provider and payer organizations are compliant transactions in production. Reports of affordable TCS solutions are often met with skepticism. This skepticism, coupled with the scarcity of resources to meet the number one priority, the availability and quality of patient care, makes it hard for providers to identify the resources necessary to develop a TCS compliance plan. Those who have developed a plan tend to focus more on the management of the technical aspects of EDI, rather than on managing the coordination of their application vendors, BA billing services/clearinghouses, and health plans.

It is difficult to budget unrealized return on investment.

Concerns

Most providers are concerned that there may be a disruption in claims processing causing significant cash flow problems, adversely affecting the availability and quality of patient care. They are not sure what needs to be done to avoid this disruption. As a covered entity, the responsibility is on the provider to ensure compliant transactions. Their BA billing service/clearing house may not communicate what needs to be done or may not be forthright as far as what is going on with the provider's trading partners and all their payers, causing non-compliance come October.

Many providers are concerned that their current software version does not have the necessary "HIPAA data fields" that their billing services or clearinghouses will need to produce compliant transactions. Those whose vendors have updates or patches may not have the time or resources required to make the appropriate changes to their health information system.

Providers may find that those who enter data may skip necessary "HIPAA data elements" for those health plans that are not currently part of EDI transactions. Gaps for a new payer that did not exist when gaps were originally considered will arise. Payer specific changes will be on going. Changes to the standard transactions will occur. Staying on top of department, application, BA billing services/clearinghouse, and health plan for each transaction type may be a very large matrix to keep straight.

There is overall concern that health plans cannot accept noncompliant claims without jeopardizing their own compliance status and risking enforcement action.

Enforcement

Through statements in the Federal Register, through extensive outreach, and through the July 24, 2003 Guidance on Compliance with HIPAA Transactions and Code Sets, CMS has stated that it will focus on obtaining voluntary compliance and use complaint-driven approach for enforcement. Entities will have the opportunity to:

o Demonstrate compliance

o Document their good faith efforts to comply with the standards

o Submit a corrective action plan

CMS's approach will utilize the flexibility granted in section 11176(b) of the Social Security Act and may not impose a civil money penalty (CMP) where:

o Failure to comply is based on reasonable cause and is not due to willful neglect

o The failure to comply is cured within a period determined by HHS based on the nature and extent of the failure to comply

CMS recognizes that transactions require the participation of two covered entities and that noncompliance by one covered entity may put the second covered entity in a difficult position. Therefore, during the transition to TCS compliance following October 16, 2003, CMS will consider:

o Whether a reasonable cause for the noncompliance exists

o The good faith efforts (sustained actions and demonstrable progress) to come into compliance with the standards by both of the covered entities

The July 24th guidance on TCS compliance states "CMS will not impose penalties on covered entities that deploy contingencies in order to ensure the smooth flow of payments."

This allows providers to stay on their legacy systems while making the transition to TCS compliance and it will allow the payers to do the same. To avoid that period of lost revenue providers must make payers aware of this flexibility and inform their payers of the existence of their own contingency plan.

How to Jump-Start Compliance Plan and Establish Contingency Plan

In order to develop an effective and sustainable compliance plan, and to establish a contingency quickly, providers should consider doing the following:

1) Contact your local, regional, and national associations and organizations and ask what is available to assist in achieving TCS compliance.

2) Read the General Administrative Requirements and Modifications to Transactions and Code Set Standards for Electronic Transactions (http://aspe.hhs.gov/admnsimp/final/txfinal.pdf). Seek assistance if necessary to understand the spirit and details of the regulations.

3) Determine which transaction types that are or will be used. If you will be providing in-house technical support you will also need to obtain the standard implementation guides for those transactions.

4) Use simple transaction models to illustrate the transaction cycle. (See Simple Transaction Model below)

5) Determine which departments collect, maintain, communicate, or aggregate information that supports the transaction types used. Determine the mode in which this information is handled (paper, phone, data entry, electronic, fax)

6) For those vendor applications that are used to collect, maintain, communicate or aggregate information needed to support the transaction types used, send a survey to the vendor and ask requirement specific questions to determine the gaps in existing systems and the availability of a "HIPAA compliant" version. It is advisable to send this survey letter certified mail, return receipt requested.

7) Send a survey to BA billing services/clearinghouses. Ask requirement specific questions to determine where they are and where you need to be in relation to them. Request they provide any necessary trading partner agreements or other contracts. In the survey letter inform them that to avoid a disruption in claims payment your contingency plan will be to continue processes currently in place until TCS compliance can be achieved. Also inform them that you will continue to make reasonable and diligent efforts to become compliant, and will keep them updated as to your schedule and progress. It is advisable to send this survey letter certified mail, return receipt requested.

8) Determine the health plans to which you will be sending electronic transactions. Send them a survey with requirement specific questions to determine where they are and where you need to be in relation to them. Request they provide any necessary trading partner agreements, or other agreements that they need as well as their companion guides. In the survey letter inform them that to avoid a disruption in claims payment your contingency plan will be to continue processes currently in place until TCS compliance can be achieved. Also inform them that you, as a covered entity provider, will continue to make reasonable and diligent efforts to become compliant, and will keep them updated as to your schedule and progress. It is advisable to send this survey letter certified mail, return receipt requested.

9) The department surveys will identify which department managers will need to be surveyed in more detail to determine the existing gaps that will need to be mitigated to achieve TCS compliance.

10) Response rate from survey letters may be low and will require follow up. Document responses and identify gaps. Steps taken to mitigate the gaps will be your TCS compliance plan.

Recognition of Content Influence

The members of the test group for the TCS module of HIPAA ComplyAssistant were instrumental in clarifying that TCS compliance can only be achieved through the management of the relationships between applications, billing services/clearinghouse and health plans for each of the transaction types. David A. Feinberg, the content developer for the TCS module of HIPAA ComplyAssistant, provided the insight that the most important part of managing TCS compliance from a provider's perspective is asking the right questions and documenting the responses from the application vendor, BA billing service/clearinghouse and health plans. He also showed how an ever-changing multi-dimensional matrix could be depicted in reports and graphs to provide an understanding of what a compliance plan requires. Gerry Blass, creator of HIPAA ComplyAssistant, showed that a logical, consistent approach is the key to achieving compliance and that effective reports and graphs that document progress and illustrate where an entity is, and where they need to be, are crucial to the decision making process, vital in documenting due diligence, and essential for successful project management.

Test Group Participants

Gerry Blass, President, Blass Consulting, LLC, Colts Neck, NJ

Bill Carlin, County of Cheshire, Finance Department, Resident Accounts, Keene, NH

Herman Doering, Sr. Consultant HIPAA SME, Venturi Technology Partners, Boise, ID

Gerry Dumatol, President, and Security Officer, Dumatek, Los Alamitos, CA

David A. Feinberg, C.D.P., President, Rensis Corp. Seattle, WA

Louise Gregg, MHA, IV-County Network Manager, Chenango, Delaware, Otsego, and Schohaire Counties Community Services, Norwich, NY

Ken Jenkins, Nebraska Health System, University of Nebraska Medical Center, Omaha, NE

Barbara McGowin, Resource Consultant, HIT Recruiting, Goose Creek, SC

Peggy Ott, President, and CEO, Hammer Logic, LLC, Grand Rapids, MI

Ray Posa, President, NJ HIPAA, Belmar, NJ

Fred Richards, VP Technology, HTP Inc., Columbus, OH

Carl Robinson, EDI Consultant, La Mesa, CA

Halbert Thomas, Hamilton County Community Mental Health Board, Cincinnati, OH

Paul Troyer, IT Consultant, Titusville, PA

Sherry Wilkerson, RHIT, CCS, CCS-P, Esse Health, St. Louis, MO

Simple Transaction Model

In order to manage compliant transactions it is helpful to picture the transaction in a simple transaction model that shows the "hops" between entities.

The following may be used to depict "hops" in these models:

DDE - **

DDE (one direction) <**, or **>

DDE (bi-directional) <**>

Standard - ---

Standard (one direction) - < --, or -- >

Standard (bi-directional) - < -- >

Non-Standard - ~~

Non-Standard (one direction) - <~~ or ~~>

Non-Standard (bi-directional) - <~~>

If a provider used DDE to submit 837P directly to a payer, the simple transaction model would look like this:

Provider **> payer

If a provider used DDE to submit 270 and receive 271 to/from their BA clearinghouse and the BA clearinghouse sent/received a standard 270/271 to/from the health plan, the simple transaction model would look like this:

Provider <**> provider clearinghouse < -- > payer

If a provider used a non-standard transaction to submit 837I to their BA clearinghouse and their BA clearinghouse sends a standard transaction to the payer, and the same hops are used for the 835 the simple transaction model would look like this:

Provider<~~> provider clearinghouse< -- > payer

Use of simple transaction models will assist in identifying the hops involved and where the transaction achieves compliance.