Change Request Detail
No.
1105
Date
8/31/2010
Submitter
Type of Request
Pertaining to more than one, or not sure
Status
DSMO Process Completed
Business Reason
To transition from paper to electronic health care transactions and eliminate the numerous phone calls, faxes and e-mails that plague the current system, patients, physicians and other health care providers  need to receive all the information necessary to determine patient and payer contractual responsibilities and to automatically reconcile and post claims payments.  The current cost for just physicians and other health care providers is 10 to 14% of their revenue. The lack of a clear identification of both 1) the patient specific benefit plan/product type and 2) each of the entities involved in the processing and payment of a claim prevents easy determination of the information necessary to navigate the typical health plan: covered versus non-covered benefits, benefit management requirements (prior authorization and carved out benefit managers), in- versus out-of network services, and which fee schedule will apply to the services which are ultimately provided.

To automate the health care system, patients, physicians and other healthcare providers as well as patients need timely electronic access to all of the following:

•    The identity of the patient’s insurance benefit plan/product type in force for the specific patient.
•    The identity of the entity that will initially receive each health care transaction. 
•    The identity of the entity responsible for administering each health care transaction.
•    The identity of the entity that will fund the claim payment (not payment of the premium). 
•    The identity of the entity that contracts directly with the health care provider if any, and for each of these contracts:
•    the identification of the contracted fee schedule that applies to each specific claim.

Although this information is necessary for patients and their healthcare providers to automate the administrative functions associated with the provision of medical care and getting paid, these pieces of information are often not included in the X12 271 or 835 electronic standard transactions today.
   
The solution to this problem will depend on how the Secretary chooses to enumerate health plans through the Health Plan ID.   However the Secretary chooses to enumerate health plans through the Health Plan ID, this DSMO change request is being submitted to ensure that the impacted HIPAA transaction implementation guides allow for the reporting of the patient-specific benefit package/product type and identify each entity that has undertaken a health plan role for the specific transaction.

To the extent that the Secretary adopts a Health Plan identification scheme that covers the patient-specific benefit package/product type and each of these entities. the challenge will be the development of implementation guidelines or operating rules as appropriate to ensure that these HPIDs are included in the appropriate fields in the Transactions. To the extent the Secretary adopts a less robust identification scheme, this task will be further complicated by the need to adopt another identification system to cover the relevant health plan products or entities that are not covered by the HPID.
Suggestion
Assuming that the Secretary adopts a robust HPID system, the new versions of the HIPAA ASC X12 (5010) and the National Council for Prescription Drug Programs (NCPDP) (D.0) transaction standards effective January 1, 2012 contain fields that would need instruction so the HPIDs are used in the relevant fields of each transaction to clearly communicate the information identified above. The following indicates a potential method of using the HPID in the 271 and 835 transactions to communicate this information.

X12 271 eligibility response
Possible locations on the 005010x279 271 for Identifier:
•    Claim Routing Entity: Loop 2120C NM101 = PRP, NM108 = XV Identifier
•    Claim Administrator: Loop 2120C NM101 =PR, NM108 = XV (placement of identifier for entity that serves as the administrator for the transaction)
•    Product/Plan: Loop 2110C EB05 = (placement of identifier for benefit plan/product type)
•    Contract Responsibility: Loop 2100C REF01 =CT, REF02 = (placement of identifier for entity that holds direct contract with physician)
o    Key to Fee Schedule: Loop 2100C REF01=CT, REF02 (placement of identifier for the fee schedule that applies to the transaction)
•    Funding Responsibility: Loop 2120C NM101=P5, NM108 = XV (Identifier ) or 24 (NEIN) (placement of identifier for entity that funds the claim, not only payment of premiums)

X12 835 electronic remittance advice - possible locations on the 005010x221 835 for identifiers:
•    Claim Administrator: Loop 1000A N103 = XV, N104 = (placement of identifier for entity that services as the administrator for the transaction)
•    Contract Responsibility: Loop 2100 REF01 = CE, REF 02 = (placement of identifier for entity that holds direct contract with physician)
o    Key to Fee Schedule: Loop 2100 REF02 = (placement of identifier for the fee schedule that applies to the transaction)
•    Product/Plan: Loop 2100 REF02 = (placement of identifier for benefit plan/product type)

Regardless of the HPID system, the class of contract field has two issues that need to be addressed:
•    The 4010 version of the class of contract field in the transactions is not a mandated field and there is enormous variation if whether health plans complete the field or the level of specificity in the information provided.  One study indicated that 28% of disputes between doctors and a health plan for payment amounts was based on the uncertainty of which contract applied to the services provided. 
•    Although the field is mandatory in the 5010 version of the transactions the implementation guide directs that it must not be used when the HPID is adopted.

Note: These loops are not currently all designed for the information specified. This is an illustration of the type of usage that X12 and any Operating Rules entity would need to create rules to effectively allow placement of these identifiers or determine appropriate revisions for future standard transactions.
DSMO Category
D
Recommendation
Disapprove.  The DSMO supports the concept of the request and WGs are actively collaborating with AMA ongoing, however, until the HPID regulation is finalized, no final definitive decisions can be made on the request as submitted. While there may be pieces within the request that appear to be resolvable prior to the HPID IFR, the request in total cannot be definitively evaluated without the HPID IFR.
Appeal Recommendation