HIPAAnotes Volume Three, October 2003

No. 39 – Are You Ready for HIPAA Transactions and Code Sets (TCS)?

Are you getting nervous with the impending HIPAA TCS deadline of October 16? You have been feverishly testing your transactions. Are you not quite sure if all of your health plans are ready as you haven't seen all of their companion guides? Even though some health plans have recently relaxed the acceptance of non-compliant transactions after October 16, you still need to move forward with a continuing good faith effort and test, test, and test some more. For a quick sanity check, answer the questions below. The more questions to which you answer "yes," the more ready you should be for TCS compliance.

Has your clearinghouse received certification using your data?
Have you prioritized your health plans by dollar volume?
Have you established dialogue with prioritized health plans to determine and confirm their billing contingencies?
Do you have a companion guide for your top priority health plans?
Are you in continuous dialogue with your clearinghouse(s)/health plans?
Are you tracking status of your health plan and clearinghouse readiness?
Do you have a centralized file documenting your TCS "good faith" compliance efforts?
Have you confirmed how you will process 835 payment remittance transactions from your health plans and clearinghouse(s)?
Is your clearinghouse/health plan ready to acknowledge that you have sent them a clean claim that can be paid?
Do your trading partners have compliance deadline contingency plans?
Are you accumulating cash reserves and establishing credit facilities?
Have you set any changed or new business processes in place to handle the HIPAA transactions?
Have you trained staff to handle these new business processes?
Once your HIPAA transaction rollout begins, will you be prepared to validate on a daily basis, adjudicated claims and fix 837 edit rejects?
Do you have contingency plans in case you don't meet the October 16 compliance deadline?

If you were able to answer "yes" to most of these questions, congratulations! If, however, you feel that you are lagging behind in the compliance race, be sure your answer to the last question is "yes." If your organization is not compliant by October 16, then you MUST be sure your contingency plan is well-established and documented. The guidance issued by CMS on July 24, 2003 (PDF) provides expectations for how to proceed in the event TCS compliance is not achieved.

Ken Schulkin, Director
Phoenix Health Systems

No. 40 – What Does the Recent “Relaxation” of the TCS Compliance Deadline Mean to My Organization?

Major health plans have recently announced that, as a contingency plan, non-compliant transactions will be accepted from providers after the October 16th transactions and code sets (TCS) compliance deadline. This is due to the Centers for Medicare & Medicaid Services (CMS) offering flexibility on compliance after October 16th – as outlined in its July 24, 2003 guidance (PDF).

CMS has explained they will not impose penalties on your organization if it has made a "good-faith effort" to comply with the TCS Regulation. This includes health plans that process compliant and non-compliant transactions while helping providers work toward compliance. However, healthcare providers should be able to demonstrate that they performed sustained and continuous actions to become compliant.

So if your health plans have “relaxed” the acceptance of non-compliant transactions after October 16th, the key to moving forward is to continue your momentum and sustain the level of your testing effort. This is not a signal to slow down your testing efforts. Your organization, as a provider, still needs to document its continuing “good-faith efforts” to comply with the TCS standards and make every effort to meet the October 16th compliance date. Indications of good faith include increased external testing with trading partners based on outreach and testing efforts with emphasis on “sustained actions and demonstrable progress.” Be sure to keep a centralized file of meeting minutes, test results, status reports, and all correspondence with trading partners, etc.

Don’t assume your health plan or clearinghouse will be compliant by October 16th. Develop your own contingency plan to maintain cash flow in the event your transactions fail to process. Keep in mind that, after October 16th, in order to avoid penalties and maintain the stream of payments from health plans, your organization must continue to demonstrate and document “reasonable and diligent efforts to become compliant.”

Remember – until your health plans accept, adjudicate, and make payments on your compliant transactions, the vigilant words are TEST, TEST, TEST and DOCUMENT, DOCUMENT, DOCUMENT!

Ken Schulkin, Director
Phoenix Health Systems

No. 41 – Do You Have Your TCS Contingency Strategies & Plans in Place?

The Centers for Medicare and Medicaid Services (CMS) recognizes that transactions often require the participation of a provider and health plan and that non-compliance by one may put the other in jeopardy. Therefore, during the period following the transactions and code sets (TCS) compliance date of October 16th, CMS intends to look at "good faith" efforts by both covered entities in meeting TCS compliance.

Recently, major health plans have announced that, as a contingency, non-compliant transactions will be accepted from providers after the October 16th TCS compliance deadline. This is due to CMS offering flexibility on compliance after October 16th - as outlined in its July 24, 2003 guidance (PDF).

In addition to developing your own contingency plan, you need also to understand your health plans' contingency plans. Keep in mind that, after October 16th, in order to avoid penalties and maintain the stream of payments from health plans, your organization must continue to demonstrate and document reasonable and diligent efforts to become compliant.

TCS Contingency planning strategies for your organization as a provider should include:

Prioritizing your health plans by focusing on your high-volume plans
Establishing dialogue with your prioritized health plans to determine and confirm billing contingencies
Paralleling your HIPAA transaction processing with your current processing
Accumulating cash reserves and establishing credit facilities
Negotiating payment advances with your priority health plans

As part of your reasonable and diligent efforts to become compliant, it is prudent for your organization to deploy contingencies that will ensure the smooth flow of payments after October 16th. If you haven't already done so, it is imperative to establish and communicate contingency planning within your own organization as well as with your trading partners.

So, do you have your HIPAA TCS contingency strategies and plans in place?

Read CMS' Basic Contingency Planning Guidelines.

Ken Schulkin, Director
Phoenix Health Systems

No. 42 – How Does the Security Rule Impact Your BA Contracts?

As a requirement of the HIPAA Privacy Regulation, your organization should have made substantial strides in executing business associate (BA) contracts. (Note: For further information on the Privacy Rule's BA requirements, please refer to the HIPAA Notes Archives). Because the Security Rule reinforces the Privacy Rule protections, the groupings relative to "safeguards" in the Security Rule were aligned to the safeguards provisions of the Privacy Rule – including the business associate requirements.

To avert any confusion over control of electronic protected health information (ePHI) as it moves down the "chain" of trading partners, the BA contract standard is also applied to the Security Rule. This is where covered entities (CEs) should require their BAs to maintain a level of security that adapts "reasonable and appropriate safeguards" for ePHI based on the Security Rule. As with the Privacy Rule, a CE is free to negotiate security arrangements with its non-BA trading partners as well, but does not have to do so.

As compared to the Privacy Rule, the HIPAA Security Rule does apply some additional implications for ePHI versus PHI (without the 'e'). Where a BA is used to create, receive, maintain, or transmit ePHI on your organization's behalf (as covered entity), the Security Rule requires the BA to:

Implement administrative, physical, and technical safeguards that reasonably and appropriately protect the confidentiality, integrity, and availability of your organization's ePHI;
Ensure that agents/subcontractors who receive ePHI from the BA meet the same standard as the BA;
Report to your organization any security incidents of which it becomes aware;
Ensure that the BA contract authorizes termination of the contract if the BA has violated a material term.

So, how does the final Security Rule impact your BA contract process?

Right now, you should pay attention first to those existing business associates that are acting as your trading partners in the exchange of ePHI – such as clearinghouses and billing agencies. For these cases, you will likely need to work with your legal counsel to add additional verbiage in your existing BA contract to address the bullet points above. By April 21, 2005 – the compliance deadline for the Security Rule – this additional verbiage (addressing ePHI's impact on BAs) should be incorporated into all existing BA contracts impacted by the Security regulations, as well as BA contracts that come up for renewal. Obviously, all contracts for new business associates being negotiated must include the appropriate language to address the HIPAA standards.

Ken Schulkin, Director
Phoenix Health Systems

No. 43 – Risk Analysis Kicks Off the Risk Management Process

Risk analysis and risk management together may be thought of as the cornerstone of the Security Rule and are required as part of the Security Management Process (164.308(a)(1)). A risk analysis is an "accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, availability, and integrity" of your organization's ePHI (electronic protected health information).

To begin the risk analysis, your organization should determine security scope -- does it focus on HIPAA compliance only or does it include business goals? Also, you should conduct a gap analysis to identify the best practices currently being done in your organization. The analysis must also determine what needs to be done to meet the Security Rule requirements and addressable standards.

Risk analysis is a pre-requisite in an on-going risk management process. From a HIPAA perspective, risk analysis is the process through which the costs associated with safeguards are balanced against the potential losses if such safeguards were not in place. Per the Security Rule, risk management is the "implementation of security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level." Risk management includes not only risk analysis and risk mitigation, but also on-going risk maintenance and evaluation.

Your organization should begin risk analysis by reviewing existing "system asset inventories" in order to find each asset's vulnerability. Your organization can then determine the level of risk it is willing to assume to protect the asset. Assets can be broken into classes, such as: communications, software, hardware, and physical facility. A variety of areas in addition to Information Systems -- such as Clinical Engineering, Nursing, Lab, Radiology, and Pharmacy -- would need to provide input to the risk assessment, as appropriate.

Risk analysis steps include:

Review systems/assets that safeguard ePHI
Identify threats/vulnerabilities
Assess severity impacts
Assess likelihood of occurrence of threats
Determine associated risks
Identify safeguard options to mitigate risks
Determine cost of safeguard option(s)
Make mitigation decision, i.e., select safeguard(s) to mitigate risks

The risk analysis process should be documented using a risk assessment decision support tool. Risk management includes the risk analysis process along with the on-going process of maintaining and evaluating the level of risk you are willing to accept for safeguarding ePHI. Your organization may need a consultant and staff training to initially operationalize this effort. Risk awareness and risk management should be part of the enterprise-wide security training program as required by the Security Rule.

Once the risk analysis is completed, your organization should assign the systems risk management responsibility to an appropriate individual who will lead the on-going ePHI risk maintenance and evaluation effort. In many organizations, this would be the Security Officer or someone delegated by the Security Officer.

A well-structured risk management program (supported by documented policies, procedures, and tools) should help identify and provide reasonable, cost-effective safeguards to your ePHI that are appropriate and scalable to your organization.