PETER T BARRY COMPANY

Transcription

1 PETER T BARRY COMPANY Ozaukee Bank Building Suite North Main Street 744 Wedge Drive Thiensville Wisconsin Naples Florida (414) Natl Cell peterbarry@aol.com (414) Natl Cell peterbarry@aol.com HIPAA Implementation Series Batch versus Claim? - What is the right span of action against an error found in a single health care claim? Revised March 31, 2004 Hierarchal structure of a batch of claims Hierarchal Level Interchange Control Functional Group Transaction-set Billing / Pay-to Provider Payer and Subscriber Patient 1 Claim Service line Number of Permitted Iterations Entities often submit multiple interchanges per file Multiple Functional Groups within Interchange Control Multiple Transaction-sets within Functional Group Multiple Billing Providers within Transaction-set Multiple Payers and Subscribers within Billing Provider Multiple Patients within Subscriber Multiple Claims within Patient Multiple Service Lines within Claim 1 The Patient hierarchal level is situational. The level is not necessary when the patient is the subscriber. Copyright Peter T Barry Page 1 of 13

2 1.0 Summary 2.0 Disclaimer 3.0 Value Statement 4.0 Definition of Batch Table of Contents 5.0 Requirements Depend on HIPAA Definition of Health Care Claim 6.0 How Does HIPAA Define a Health Care Claim? 6.1 Hierarchal structure of a batch of claims 6.2 HIPAA definition of a claim is different from an 837 transaction-set 6.3 The 837 is not same as a HIPAA Health Care Claim 6.4 Understanding the HIPAA claim definition 6.5 Implementation Guides use Claim in its historical meaning 6.6 Concluding definition of a HIPAA health care claim 7.0 Span of Exception Handling Action 7.1 A health plan is obligated to accept valid claims 7.2 Example: Two providers, one plan, only one claim has an exception 7.3 Example: One provider, two plans, only one claim has an exception 7.4 Example: One provider, one plan, only one claim has an exception 7.5 When the exception affects other levels in the 837 hierarchy 7.6 When an exception affects levels at or above the 837 transaction-set Transaction-set level Functional group, interchange control, or file levels. 7.7 When would it be acceptable to act against an entire batch? When system or communication malfunction When too many claims from the same provider have exceptions. 7.8 Does software deficiency justify acting against valid claims? No. 8.0 Conclusion: Span of Exception Handling Is Limited To The Claim Or Claims With The Exception 9.0 The HHS FAQ Response on Batches of Claims Is Misleading 10.0 Further Reference Attachment A: Hierarchal Structure of an 837 Submission Copyright Peter T Barry Page 2 of 13

3 1.0 Summary BATCH VERSUS CLAIM? What is the Right Span of Action Against an Exception Found in a Single Health Care Claim? This paper asks the question: What is the correct span of action against 2 an exception 3 such as an error? Should the action apply only to the claim with the exception, or to more than one claim, or to the entire batch submission? Many health plans implemented EDI for health care claims using software whose transaction granularity was the X12 Transaction-set rather than a claim. This may have been a natural result of employing EDI software originally built for other industries, or it may have resulted from confusion between what is a transaction versus what is an X12 transaction-set? Software that acts at the level of the transaction-set will reject an entire batch of claims even if only one of the claims has an error. From the point of view of a claim submitter, rejection of an entire batch or file because of a single claim error is heavy handed indeed. Consequently, many health plans that originally rejected batches of claims have since been adjusting their software to act against individual claims instead. For example, Medicare intermediaries implemented systems last fall that rejected batches, but now they are changing to individual claims. This paper analyzes the batch-versus-claim question in relation to the Transactions and Code Sets rule. It concludes, apart from two circumstances, that exception handling must act only against the claim having an exception, or to such higher level in the transactionset hierarchy at which the exception occurs. It concludes that to discriminate against valid claims in a batch is inconsistent with the General Rule and Health Plan Mandate. It also concludes such action is inconsistent with state insurance and prompt pay laws. Yet, since so many health plans originally implemented batch rejection, it is reasonable that the basis for it must have been an understandable confusion. The reasonable course now is for plans to adjust their software to claim-level editing as they are able. 2.0 Disclaimer This paper is based on my understanding of the HIPAA Transactions and Code Sets rule. It examines applicability of the rule from the perspective of business and technical analysis. It is offered without warranty, and it is not a legal opinion. 2 By act against I mean the type of action appropriate to the exception, such as rejection, holding, correction, or continued processing despite the exception. Type of action is addressed in a second paper, Claims Remediation. 3 A transaction exception is a deviation from the format, data content, or code values in the Implementation Guide or certain business edits. It may be trivial, irrelevant to the business conducted between provider and plan, or severe. Copyright Peter T Barry Page 3 of 13

4 3.0 Value Statement The best and most reasonable design maximizes acceptance and adjudication of claims within the framework of the Transactions and Code Sets rule. The following quotation states the point of view of a typical claim submitter with clarity: "We at AIM provide electronic billing software and support to a broad range of medical service providers. In converting our clients for HIPAA compliance, we completely tested our upgraded software with each trading partner, including some beta and Claredi testing. After early success, our first live client one day sent 429 claims to Medicare, and Medicare deleted all 429 claims because of a quotation mark in the prior authorization number field. So for the next two months we again upgraded all the AIM software to include edits to catch any errant characters that could lead to complete file deletion. Recently we again invested a great deal of time in additional software edits after we discovered the name O'Connor 4, rather than OConnor, caused a huge entire batch to be deleted by the carrier. It is ridiculous and time consuming for the HIPAA requirements to delete a providers' entire batches because of an individual claim." [Annie MacDonald, President, AIM Systems, Inc, October 30, 2003] 4.0 Definition of Batch For purposes of this paper, I define a batch of claims as more than one claim or a transmission structure capable of more than one claim. An X12 transaction-set is a batch because it carries or can carry multiple claims. Also, multiple transaction-sets, multiple functional groups, and multiple interchanges within one transmission can form a batch. The Transactions and Code Sets rule does not define batch. Implementation Guides purport to have a definition, but they intermix concepts of batch, batch mode, multiple transactions, synchronous and asynchronous telecommunication sessions, and time to process, all into one definition of a typical scenario. The IG definition is not useful here. 5.0 Requirements Depend on HIPAA Definition of Health Care Claim General Rule (a). General rule. Except as otherwise provided in this part 5, if a covered entity conducts with another covered entity (or within the same covered entity), using electronic media, a transaction for which the Secretary has adopted a standard under this part, the covered entity must conduct the transaction as a standard transaction. Health plan mandate (a)(1) If an entity requests a health plan to conduct a transaction as a standard transaction, the health plan must do so. These rules say that if a claim transaction is standard meaning that it fully conforms to the standard, which is defined in an Implementation Guide then the health plan must conduct it. So the span of action hinges on the HIPAA definition of a claim transaction. 4 Note that an apostrophe is a valid character in the Basic Character Set; so, assuming we have the facts straight, it would appear the first O Connor error was made by the plan when it rejected the claim, not by the provider who submitted it. Based on the conclusions of this paper, the second error was when the plan rejected all the claims. 5 The rule exceptions are direct data entry (DDE) or by meeting the same requirement through a business associate. Copyright Peter T Barry Page 4 of 13

5 6.0 How Does HIPAA Define a Health Care Claim? 6.1 Hierarchal structure of a batch of claims Hierarchal Level Interchange Control Functional Group Transaction-set Billing / Pay-to Provider Payer and Subscriber Patient 6 Claim Service line Number of Permitted Iterations Entities often submit multiple interchanges per file Multiple Functional Groups within Interchange Control Multiple Transaction-sets within Functional Group Multiple Billing Providers within Transaction-set Multiple Payers and Subscribers within Billing Provider Multiple Patients within Subscriber Multiple Claims within Patient Multiple Service Lines within Claim The X12 structure and the 837 transaction-set structure together form a hierarchy that enables many claims to be included in a single transmission and that avoids redundant transmission common to multiple claims. For example, if two claims are from the same provider, the hierarchy enables provider data to be transmitted only once. The structure means that claims share data and the data for a single claim is not necessarily contiguous. 6.2 HIPAA definition of a claim is different from an 837 transaction-set The Transactions and Code Sets rule defines a health care claim in business terms. It does not define a claim with the technical specifications of an X12 transaction-set: HIPAA Definition of a Claim Health care claims 7 or equivalent encounter information transaction. The health care claims or equivalent encounter information transaction is the transmission of either of the following: (a) A request to obtain payment, and the necessary accompanying information from a health care provider to a health plan, for health care. The controlling HIPAA definition quoted above is singular. It defines a claim transaction with three singular components: A request to obtain payment for health care. (singular request) from a health care provider (singular provider) to a health plan (singular plan) 6 The Patient hierarchal level is situational. The level is not necessary when the patient is the subscriber. 7 I have heard an inference taken from the existence of a plural in the claim transaction name that the defined HIPAA transaction is not a claim as historically understood or as defined in other law such as state insurance and prompt pay laws, but instead it would be a new thing; it would be whatever an X transaction-set could carry. Hence, the rationale goes, if there would be a single data exception within an 837 transaction-set, the entire 837 transaction-set could be rejected. That s reading a whole bunch into the name s s. A name only labels; it does not define. The controlling definition is singular as described below. Copyright Peter T Barry Page 5 of 13

6 These singular components comport with general definition of an insurance claim: Claim. 3. A demand for money or property to which one asserts a right <insurance claim>. [Black s Law Dictionary, 7 th edition.] 6.3 The 837 is not same as a HIPAA Health Care Claim But the 837 transaction-set does not comport to these three components or to general definition of an insurance claim: It is impossible to be one request or one demand if addressed to more than one health plan, and it would not be to a health plan if it were to two plans. It is impossible to be one request or one demand if it comes from multiple providers, and it would not be from a health care provider if it were from two health care providers. It does not assert a single right if it contains more than one subscriber because the two subscribers may have different eligibility and may be covered by two policies whose coverage may differ so that the rights differ. Therefore the 837 transaction-set is not the same thing as the defined claim transaction. Since the 837 can carry claims from multiple providers, for multiple subscribers, to multiple plans, it is not an equivalent definition for a HIPAA claim transaction. Even the X12 term, transaction-set, as in set of transactions, says as much. Rather, the 837 transaction-set specifies the standard only after the transaction first meets the definition. The 837 transaction-set is technical; it specifies syntax, data, codes, and certain usage rules by which HIPAA claims are to be transmitted and accepted. It does not define a HIPAA claim transaction. 6.4 Understanding the HIPAA claim definition Reasonable understanding of the HIPAA definition of claim derives from historical usage and the everyday phrase, request to obtain payment. Its singular meaning resides in historically accepted claim submission and adjudication practices as illustrated, for example, by the HCFA 1500 and UB92 paper claim forms. It resides in the unit of information about which a provider notes, This is not a bill; we have filed a claim with your insurance company. It resides in the unit to which an insurance company affixes a claim number. It resides in the concept when an insurance company splits a claim. It is the specific object reported by a claims status response. Copyright Peter T Barry Page 6 of 13

7 It is found in the October 16, 2003, HHS FAQ response Health plans are allowed to accept and process any and all claims within a batch. 6.5 Implementation Guides use Claim in its historical meaning It is found in the HIPAA Claim Implementation Guides, which repeatedly describe an 837 transaction-set as carrying multiple claims, thereby defining a claim as a thing separate from the 837 transaction-set. For example: Comment Describing how one 837 can have multiple claims for multiple subscribers Describes multiple claims in an 837, how a plan may accept some and reject some, how it takes action on individual claims, not entire 837 transaction-set Describes how one 837 may carry thousands of claims Describes how a claim is in a subordinate hierarchal level Gives an example of two claims for one provider. Quotation from 837I Implementation Guide HL Segment If the billing provider is submitting claims for more than one subscriber, each of whom may or may not have dependents, the HL structure Unsolicited Claim Status (277) The 277 transmission may be used to indicate to the provider which claims in an 837 batch were received electronically but not yet accepted into the adjudication system, which were accepted into the adjudication system (i.e., which claims passed the front-end edits) and which claims were rejected before entering the adjudication system. 2.7 Limitations to the Size of a Claim/Encounter (837) Transaction. Receiving trading partners may have system limitations regarding the size of the transmission they can receive. Some submitters may have the capability and the desire to transmit enormous 837 transactions with thousands of claims contained in them. Loop: 2000A BILLING/PAY-TO PROVIDER HIERARCHICAL LEVEL Usage: SITUATIONAL Notes: 1. Required if the Service Facility Provider is the same entity as the BillingProvider and/or the Pay-to Provider. In these cases, the Service Facility Provider is being identified at this level for all subsequent claims in this HL batch and Loop ID-2310E is not used Business Scenario 3 Two Claims for the Same Provider This example combines two claims for the same provider. [837I Implementation Guide May 2000] Note especially above the use of the 277 to report claims separately from the same batch that are not yet accepted, accepted, and rejected. Copyright Peter T Barry Page 7 of 13

8 6.6 Concluding definition of a HIPAA health care claim Based on the above analysis, for purposes of the HIPAA Transactions and Code Sets rule, the scope of a single claim is a group of service line items from a single provider, to a single plan, for a single patient, and often for a single encounter or medical event, such that it is commonly adjudicated as a group and separately from other groups. Moreover, health care claim has meaning in state insurance and prompt pay laws and does not encompass multiple providers, multiple subscribers and patients, and, generally, multiple independent medical events. 7.0 Span of Exception Handling Action We established in the analysis above that the HIPAA definition of a claim is the same as the historically and legally accepted meaning of health care claim, and that it is not a new definition equating to the multi-claim capability of the 837 transaction-set. Therefore, the remaining span-of-action question is how many claims within a batch does the Transactions and Code Sets rule as well as other law such as state insurance and prompt pay laws permit the receiver to act against within the submission batch hierarchy? 7.1 A health plan is obligated to accept valid claims The Transactions and Code Sets rule mandates that a health plan must accept a standard claim: Health plan mandate (a)(1) If an entity requests a health plan to conduct a transaction as a standard transaction, the health plan must do so. Other law, including state insurance and prompt pay laws, obligate health plans to adjudicate and pay claims that are valid: The obligation to pay claims arises from underlying insurance contracts. Denying reimbursement of a clean claim invites a private lawsuit under state law for breach of the insurance contract. If reimbursement of clean claims is denied or improperly delayed on a systemic basis, payers invite class action lawsuits on state law theories including breach of contract and bad faith. [Surviving Standard Transactions, Richard D. Marks, Electronic Commerce & Law Report, BNA, June 4, 2003] 7.2 Example: Two providers, one plan, only one claim has an exception Say that two providers each send 10 claims in the same 837 transaction-set. This occurs in high volume such as when the providers clearinghouse send claims to the plan. Copyright Peter T Barry Page 8 of 13

9 Say there is an exception in one of Provider A s claims. Every claim submitted by Provider B is perfect. There is no basis to act against Provider B s claims. It is unreasonable and unfair to act against Provider B s claims because of an exception over which it had no control. To act against Provider B s claims is inconsistent with the mandate rule. Also, since Provider B has submitted valid claims, if their rejection would cause delay, it is contrary to state insurance and prompt pay laws. So the plan must accept and adjudicate all the claims from Provider B. 7.3 Example: One provider, two plans, only one claim has an exception Say that a provider sends 5 claims to one plan and 5 claims to another plan within the same 837 transaction-set. This occurs in high volume such as when a provider sends claims for many or all plans to a clearinghouse. It also occurs when a provider sends claims to an administrator for many plans. Say there is an exception in one claim sent to the first plan. All the claims to the second plan are perfect. There is no basis in the rules for not sending the claims to the second plan, and if the second plan does receive those claims, it would have no knowledge that there had been an exception in a claim intended for a different plan. Or, there is not basis for an administrator to reject perfect claims to one plan because of an exception detected in a claim for another plan. The exception detected in a claim to the first plan is completely independent from the claims to the second plan. Therefore, all claims to the second plan must be sent to it and the administrator must accept them. 7.4 Example: One provider, one plan, only one claim has an exception Say that a single provider sends 10 claims to a single plan in the same 837 transactionset. One claim has an exception; the other nine are perfect. Since a claim transaction is a different thing from the 837 transaction-set, there is no basis in the rule for the plan to act against the nine perfect claims because the tenth claim has an exception, provided that the exception is confined to the tenth claim alone. Moreover, the provider and plan are not the only parties. Say the exception was caused by one subscriber not supplying complete information. It is unreasonable and unfair potentially to delay claims for nine subscribers because of an exception to which they did not contribute. 7.5 When the exception affects other levels in the 837 hierarchy Some exceptions affect more than a single claim. For example, if the billing provider has not been properly identified, it might prevent all claims from that provider from being processed, and it could be appropriate to act against those claims. Another way of saying this is that the billing provider is part of every claim below the billing provider hierarchal level; consequently, if there is an exception in the billing provider information, there is an exception in every claim under that provider. Copyright Peter T Barry Page 9 of 13

10 But say there are valid claims for other providers in the same 837 transaction-set. There is no basis in the rule for acting against the claims of those providers. It would be unfair to act against their claims because of an exception wholly independent of them and over which they had no control. Also, it would be inconsistent with the health plan mandate, which obligates a plan to accept valid claims, and it would be contrary to state insurance and prompt pay laws. 7.6 When an exception affects levels at or above the 837 transaction-set Transaction-set level. If, say, the submitter in the transaction-set header is not identified, it would be appropriate to apply exception handling to the entire transaction-set, including all claims within it. Whether exception handling for this exception should be rejection, correction, or holding for correction is a second question, addressed in the Claims Remediation paper. But there would not be reason to act against other transaction-sets that are not affected by the exception unless the nature of the exception indicates system or communication malfunction Functional group, interchange control, or file levels. If the exception occurs at the functional group, interchange control, or file level, it would be appropriate to apply exception handling to all transaction-sets within that level. Whether exception handling should be rejection or holding for correction is addressed in the Claims Remediation paper. If the exception occurred at the functional group level, there would not be reason to act against other functional groups that are not affected by the exception unless the nature of it suggests serious malfunction. If the exception occurs at the interchange control level, there would not be reason to act against other interchange envelopes that may have been included in the same file unless the nature of the exception suggests serious malfunction. 7.7 When would it be acceptable to act against an entire batch? There are two circumstances when a plan would act against a batch: When system or communication malfunction. The nature of an exception may indicate serious malfunction of systems or telecommunication such as to call into question the integrity of an entire transmission. In such case, it would be prudent to reject the entire transmission and request retransmission. This occurs infrequently. In most cases, exceptions do not indicate malfunction that questions integrity of the transmission. In most cases, exceptions are of data within a correct X12 structure When too many claims from the same provider have exceptions. The examples above were based on the exception being an aberration, a low frequency occurrence. It is possible that a provider has one or more consistent exceptions Copyright Peter T Barry Page 10 of 13

11 such as an omission, which the plan may or may not tolerate especially during the transition, while other exceptions are aberrant. But say that a provider has other exceptions in many or most of its claims. It is reasonable for a plan to require minimum quality from a provider. It is unreasonable for the provider to ask the plan to debug its systems 8. Consequently, a plan may decline to accept standard claims from a provider that cannot maintain sufficiently high quality. Quality of, say, 90-95% valid claims after the HIPAA transition period would seem reasonable, and over time a plan might raise this threshold. 7.8 Does software deficiency justify acting against valid claims? No. Some front-end and translation software, upon finding certain exceptions, will immediately reject an entire submission. Does that entitle a plan to act against valid claims? I would not think so. Computer software does not change the law. Software is supposed to follow the law, not the other way round. 8.0 Conclusion: Span of Exception Handling Is Limited To The Claim Or Claims With The Exception So exception handling must apply only to the affected claim, or to such higher level in the hierarchy at which the exception occurs. As determined in the analysis above, the span of exception handling must not disadvantage unrelated transactions involving other parties who have had no control over the exception. To act against valid claims is inconsistent with the health plan mandate, which obligates a plan to accept valid claims, and is contrary to state insurance and prompt pay laws. The Transactions and Code Sets rule does not admit a wider span. Since it defines the transaction as a claim as historically and legally understood, if a claim has an exception, it is correct to apply appropriate exception handling process to the claim with the exception, but other claims may be valid and unrelated to the claim with the exception, and the rule requires plans to accept those valid claims. A plan may apply exception handling procedure against a batch in two circumstances: when the exception indicates probable system or communication malfunction, or when the overall quality of the submitter s transactions is unacceptably below a reasonable minimum. 8 See also 3.3 HIPAA leaves compliance testing to business practice, ROI: Economics of Third Party Certification, Peter T Barry, April Copyright Peter T Barry Page 11 of 13

12 9.0 The HHS FAQ Response on Batches of Claims Is Misleading HHS posted an FAQ response as follows: Question. Must a health plan reject an entire batch of standard transactions if one of the transactions is not HIPAA-compliant? Answer. No. Neither the law nor our regulations require a health plan to reject an entire batch of standard transactions if one of the transactions is not HIPAA-compliant. Health plans are allowed to accept and process any and all claims within a batch that meet the HIPAA requirements. [HHS FAQ Response 2348 posted October 16, 2003] The answer is correct as far it goes. I like the part that affirms two concepts central to this analysis: (1) that there may be many claims within a batch; and (2) that a plan may treat the multiple claims differently. However, by saying a plan is not required to reject an entire batch, it implies that batch rejection of valid claims would be an acceptable option that it would be permissible to reject an entire batch when but a single claim has an exception. The implication, if intended, would be inconsistent with the Transactions and Code Sets rule. This report concludes it is not consistent with the rule for a plan to reject an entire batch of valid claims when one of the claims has an exception. This report concludes not only that rejecting valid claims is inconsistent with the General rule and Health Plan Mandate rule, but also that rejecting valid claims is contrary to state insurance and prompt pay laws and is likely to create problems for a plan under those laws Further Reference Papers related to the subject of this paper include the following: Remediation of Standard Claims: 2-Stage Bridge from Contingency to Compliance, Peter T Barry, Front-End Acknowledgment, Editing, and Reporting, SNIP Business Issues paper, revised. Copyright Peter T Barry Page 12 of 13

13 Attachment A Hierarchal Structure of an 837 Submission The hierarchal structure of an X12 EDI submission is illustrated by the following chart 9 : 9 Figure A1 Transmission Control Schematic in all HIPAA Implementation Guides. Copyright Peter T Barry Page 13 of 13