Comment: The majority of commenters supported the concept of a maximum defined data set; however, there was some confusion on what we were proposing.
Several commenters believed we were requiring health care providers to always send the transaction with the maximum data possible. They stated that health care providers and health plans will pay excessively for unused data that is transmitted. Concern was also expressed that health plans would have to store coordination of benefits (COB) information if it is submitted, even though they do not perform COB. Several commenters suggested that health plans be allowed to reject a transaction because it contains information they do not want.
One commenter recommended that the maximum defined data set be the full set of data available in the implementation specifications, not the addendum in the proposed rule.
A few commenters wanted to expand the concept of a maximum defined data set to include code sets, modifiers, narrative descriptions, guidelines and instructions applicable to codes sets, as well as an additional category for “usage” in the implementation specifications, “not required unless specified by a contractual agreement.” Several commenters wanted trading partners to be able to agree on which non-required data will be used between them.
One commenter suggested a “minimum” data set principle be applied. If a submitter sends a minimum data set, the receiver cannot reject it as incomplete. Again, the commenter believed we were implying that a submitter must send the maximum every time, in order to assure acceptance of the transaction.
Response: We wish to clarify the maximum defined data set concept. A maximum defined data set contains all of the required and situational data elements possible in a standard transaction. For each standard transaction there are situational data elements that are both relevant to the particular transaction and necessary to process it; there are also situational data elements that an entity may include in a transaction, but does not need to include, in order for the transaction to be processed. A required data element is always required in a transaction. A situational data element is dependent on the written condition in the implementation specification that describes under which circumstances it is to be provided. The maximum defined data set is based on the implementation guides and not the addendum in the proposed rule. The maximum defined data set also includes the applicable medical and nonmedical code sets for that transaction. Some code sets, e.g., HCPCS and CPT-4, include special codes referred to as “modifiers.” Modifiers are included in the concept of maximum defined data set. The maximum defined data set does not include operational guidelines or instructions for every code set.
We note that if an entity follows the implementation specification and the conditions in the implementation specification for each transaction, the entity will only be supplying the minimum amount of data elements necessary to process a transaction (required data elements and relevant situational data elements); the entity will not be supplying possible but unnecessary situational data elements.
In addition, we note that the intent behind the maximum defined data set was to set a ceiling on the nature and number of data elements inherent to each standard transaction and to ensure that health plans did not reject a transaction because it contained information they did not want. For example, if an implementation specification defines a health care claim or equivalent encounter information transaction as having at most 50 specific data elements, a health plan could not require a health care provider to submit a health care claim or encounter transaction containing more than the 50 specific data elements as stipulated in the implementation guide. (A health plan may, however, request additional information through attachments.)
While operational guidelines or instructions are not included in the concept of a maximum defined data set, we agree that standardization of these code set guidelines is highly desirable and beneficial. We reviewed the available guidelines to determine which should be adopted as implementation specifications and have found that there are also many current practical barriers to achieving such standardization. For example, we recognize that the operational guidelines for some code sets required for use in the designated transactions are more complete than others. Also, objective, operational definitions for most codes are not available and the level of detail varies widely from code to code. In addition, the processes for developing guidelines and instructions are typically not open and include limited participation compared to the code development processes. However, where such guidelines exist and are universally accepted, we name them as part of the standard. Therefore, we adopt the Official ICD-9-CM Guidelines for Coding and Reporting as maintained and distributed by the Department of Health and Human Services (§162.1002). Additionally, we received many public comments in support of this action. We do not name guidelines for other code sets.
With respect to COB, if a health plan electronically performs COB exchange with another health plan or other payer, then it must store the COB data necessary to forward the transaction to that health plan or other payer.
In addition, we disagree with commenters that we should add a new “usage” statement, “not required unless specified by a contractual agreement,” in the implementation guide. We believe that the usage statement would have the same effect as allowing trading partners to negotiate which conditional data elements will be used in a standard transaction. Each health plan could then include different data requirements in their contracts with their health care providers. Health care providers would then be required to use a variety of guidelines to submit transactions to different health plans. This would defeat the purpose of standardization.