# Health Insurance Reform; Modifications to the Health Insurance Portability and Accountability Act (HIPAA) Electronic Transaction Standards

> Briefs, arguments, decisions, and more.

URL: https://www.frixlaw.com/law-library/documents/fr%3AE9-740

## Record

- **Collection:** Federal Register
- **Document type:** Rule
- **Published:** January 16, 2009
- **Citation:** 74 FR 3296

## Text

DEPARTMENT OF HEALTH AND HUMAN SERVICES
Office of the Secretary
45 CFR Part 162
[CMS-0009-F]
RIN 0938-AM50
Health Insurance Reform; Modifications to the Health Insurance Portability and Accountability Act (HIPAA) Electronic Transaction Standards

AGENCY:

Office of the Secretary, HHS.

ACTION:

Final rule.

SUMMARY:

This final rule adopts updated versions of the standards for electronic transactions originally adopted under the Administrative Simplification subtitle of the Health Insurance Portability and Accountability Act of 1996 (HIPAA). This final rule also adopts a transaction standard for Medicaid pharmacy subrogation. In addition, this final rule adopts two standards for billing retail pharmacy supplies and professional services, and clarifies who the “senders” and “receivers” are in the descriptions of certain transactions.

DATES:

Effective Dates:
These regulations are effective March 17, 2009 except for the provisions of 45 CFR part 162 Subpart S, which are effective January 1, 2010. The incorporation by reference of certain publications listed in the regulations is approved by the Director of the Federal Register as of March 17, 2009.

Compliance Dates:
Compliance with the provisions of §§ 162.1102(c), 162.1202(c), 162.1302(c), 162.1402(c), 162.1502(c), 162.1602(c), 162.1702(c), and 162.1802(c) is required on January 1, 2012. Compliance with the provisions of § 162.1902 is required on January 1, 2013.

FOR FURTHER INFORMATION CONTACT:

Lorraine Tunis Doo, (410) 786-6597.

I. Background

HIPAA mandated the adoption of standards for electronically conducting certain health care administrative transactions between certain entities. Through subtitle F of title II of HIPAA, the Congress added to title XI of the Social Security Act (the Act) a new Part C, entitled “Administrative Simplification.” Part C of title XI of the Act now consists of sections 1171 through 1180. These sections define various terms and impose several requirements on HHS, health plans, health care clearinghouses, and certain health care providers concerning the electronic transmission of health information. On August 17, 2000, we published a final rule entitled, “Health Insurance Reform: Standards for Electronic Transactions” in the
Federal Register
(65 FR 50312) (hereinafter referred to as the Transactions and Code Sets rule). That rule implemented some of the HIPAA Administrative Simplification requirements by adopting standards for eight electronic transactions and for code sets to be used in those transactions. Those transactions were: Health care claims or equivalent encounter information; health care payment and remittance advice; coordination of benefits; eligibility for a health plan; health care claim status; enrollment and disenrollment in a health plan; referral certification and authorization; and health plan premium payments. We defined these transactions and specified the adopted standards at 45 CFR part 162, subparts I and K through R.

Since the time of compliance with the first set of HIPAA standards, a number of technical issues with the standards, including issues resulting from new business needs, have been identified. Industry stakeholders submitted hundreds of change requests to the standards maintenance organizations, with recommendations for improvements to the standards. These requests were considered, and many were accepted, resulting in the development and approval of newer versions of the standards for electronic transactions. However, covered entities are not permitted to use those newer versions until the Secretary of Health and Human Services (HHS) adopts them by regulation for HIPAA transactions.

In addition to technical issues and business developments necessitating consideration of the new versions of the standards, there remain a number of unresolved policy issues that were identified by the industry early in the implementation period for the first set of standards, and those issues were never addressed through regulation. This final rule addresses those outstanding issues.

We refer readers to review the following regulations for a more detailed discussion of the changes to the standards for electronic transactions; the Transactions and Code Sets rule; the Modifications to Electronic Data Transaction Standards and Code Sets rule (68 FR 8381), published in the
Federal Register
on February 20, 2003 (hereinafter the Modifications rule); Standards for Privacy of Individually Identifiable Health Information (65 FR 82462), published in the
Federal Register
on December 28, 2000; Standards for Privacy of Individually Identifiable Health Information; Final Rule (67 FR 53182) published in the
Federal Register
on August 14, 2002; and the Modifications to the Health Insurance Portability and Accountability Act (HIPAA) Electronic Transaction Standards proposed rule (73 FR 49796), published in the
Federal Register
on August 22, 2008 (hereinafter the August 22, 2008 proposed rule) for further information about electronic data interchange, the statutory background and the regulatory history.

In the August 22, 2008 proposed rule, we included a table that shows the full set of HIPAA transaction standards adopted in the Transactions and Code Sets rule, as we proposed to modify them in the August 22, 2008 proposed rule (73 FR 49744), and adopt in this final rule. The list is reproduced here in Table 1:

Table 1—HIPAA Standard and Transactions

Standard
Transaction

ASC X12 837 D
Health care claims—Dental.

ASC X12 837 P
Health care claims—Professional.

ASC X12 837 I
Health care claims—Institutional.

NCPDP D.0
Health care claims—Retail pharmacy drug.

ASC X12 837 P and NCPDP D.0
Health care claims—Retail pharmacy supplies and professional services.

NCPDP D.0
Coordination of Benefits—Retail pharmacy drug.

ASC X12 837 D
Coordination of Benefits—Dental.

ASC X12 837 P
Coordination of Benefits—Professional.

ASC X12 837 I
Coordination of Benefits—Institutional.

ASC X12 270/271
Eligibility for a health plan (request and response)—dental, professional and institutional.

NCPDP D.0
Eligibility for a health plan (request and response)—Retail pharmacy drugs.

ASC X12 276/277
Health care claim status (request and response).

ASC X12 834
Enrollment and disenrollment in a health plan.

ASC X12 835
Health care payment and remittance advice.

ASC X12 820
Health plan premium payment.

ASC X12 278
Referral certification and authorization (request and response).

NCPDP D.0
Referral certification and authorization (request and response)—Retail pharmacy drugs.

NCPDP 5.1 and NCPDP D.0
Retail pharmacy drug claims (telecommunication and batch standards).

NCPDP 3.0
Medicaid pharmacy subrogation (batch standard).

II. Provisions of the Proposed Regulations and Responses to Comments

On August 22, 2008 we proposed to adopt updated standards for the eight adopted electronic transactions standards. We proposed to revise § 162.1102, § 162.1202, § 162.1302, § 162.1402, § 162.1502, § 162.1602, § 162.1702, and § 162.1802 to adopt the ASC X12 Technical Reports Type 3 (TR3), Version 005010 (hereinafter referred to as Version 5010) as a modification of the current X12 Version 4010 standards (hereinafter referred to as Version 4010/4010A) for the HIPAA transactions. In some cases, the Technical Reports Type 3 have been modified by Type 1 Errata, and these Errata were also included in our proposal. The full discussion of our proposal to revise each of the above-referenced provisions can be found in the August 22, 2008 proposed rule (73 FR 49745-49750).

We proposed to revise § 162.1102, § 162.1202, § 162.1302, and § 162.1802 by adding new paragraphs (c)(1) to each of those sections to adopt the NCPDP Telecommunication Standard Implementation Guide, Version D, Release 0 (Version D.0) and equivalent NCPDP Batch Standard Implementation Guide, Version 1, Release 2 (Version 1.2) (hereinafter collectively referred to as Version D.0) in place of the NCPDP Telecommunication Standard Implementation Guide, Version 5, Release 1 and equivalent NCPDP Batch Standard Implementation Guide, Version 1, Release 1 (hereinafter collectively referred to as Version 5.1), for the following retail pharmacy drug transactions: Health care claims or equivalent encounter information; eligibility for a health plan; referral certification and authorization; and coordination of benefits. The full discussion of our proposal to revise each of the above-referenced provisions can be found in the August 22, 2008 proposed rule (73 FR 49751).

We proposed to add a new subpart S to 45 CFR part 162 to adopt a standard for the subrogation of pharmacy claims paid by Medicaid. The transaction is the Medicaid pharmacy subrogation transaction, defined at proposed § 162.1901, and the new standard is the NCPDP Batch Standard Medicaid Subrogation Implementation Guide, Version 3, Release 0 (Version 3.0), July 2007 (hereinafter referred to as Version 3.0) at proposed § 162.1902. The standard would be applicable to Medicaid agencies in their role as health plans, as well as to other health plans that are covered entities under HIPAA, but not to providers because this transaction is not utilized by them. For a complete discussion of the Medicaid pharmacy subrogation transaction and the proposed adoption of Version 3.0, see the August 22, 2008 proposed rule (73 FR 49751-49752).

We proposed to revise § 162.1102 to adopt both Version D.0 and the 837 Health Care Claim: Professional ASC X12 Technical Report Type 3 for billing retail pharmacy supplies and professional services. We proposed that the use of either standard would be determined by trading partner agreements. The full discussion of the proposed change can be found in the August 22, 2008 proposed rule (73 FR 49752-49754).

We proposed to revise the descriptions of the transactions at § 162.1301, § 162.1401, and § 162.1501 to more clearly specify the senders and receivers of those transactions. See the August 22, 2008 proposed rule for a full discussion of this proposal (73 FR 49754). For Versions 5010 and D.0, we proposed a compliance date of April 1, 2010 for all covered entities. For Version 3.0, we proposed a compliance date 24 months after the effective date of the final rule, except for small health plans, which would have to be in compliance 36 months after the effective date of the final rule. Finally, we proposed to revise § 162.923 to resolve the problem of different compliance dates for different entities, such that the requirement for covered entities to use the standards applies only when the covered entity conducts transactions with another entity that is also required to comply with the transaction standards.

In response to the August 22, 2008 proposed rule, we received 192 timely public comments from all segments of the health care industry, including providers, physician practices, hospitals, pharmacies, other health care professionals, health plans, clearinghouses, vendors, standards development organizations, professional associations, consultants, and State and Federal government agencies. We reviewed each submission, and grouped similar or related comments together to address in this final rule, which also enabled us to identify the areas of the proposed rule that required review in terms of policy, consistency or clarity.

In the following sections, we present comments and responses generally in the order in which the topics were presented in the August 22, 2008 proposed rule. There were a number of comments on topics that were not addressed in the proposed rule, and our responses to those comments are provided at the end of this section. Some comments we considered out of scope of the August 22, 2008 proposed rule, and we list several of them at the end of this section as well.

A. Adoption of X12 Version 5010 Technical Reports Type 3 for HIPAA Transactions

In the August 22, 2008 proposed rule, we proposed to revise § 162.1102, § 162.1202, § 162.1302, § 162.1402, § 162.1502, § 162.1602, § 162.1702, and § 162.1802 to adopt Version 5010. In some cases, the version was modified by Type 1 Errata, and these Errata were also proposed for adoption. In general, deficiencies inherent in the current standards continue to cause industry-wide difficulties to such a degree that much of the industry rely on “companion guides” and proprietary “work-arounds.” The four types of changes in Version 5010 are structural, front matter, technical improvements

and data content changes. The complete discussion of this proposal can be found in the August 22, 2008 proposed rule (73 FR 49745-49749).

Comment:
Commenters overwhelmingly supported our proposal to adopt Version 5010 because of the technical and business improvements made to the standards. With respect to the specific changes made to Version 5010, commenters expressed their appreciation for the tightened, clear situational rules which will reduce analysis time for everyone, and minimize the need for companion guides. Commenters said that the improved eligibility responses and better search options will improve efficiency for providers and reduce phone calls for both providers and health plans. Commenters also said that the detailed clarifications of commonly misunderstood areas such as corrections and reversals, refund processing, and recoupments should result in a consistent implementation of the X12 835 (remittance advice), which is not the case today. They noted that incorrect implementations of the X12 835 have prevented providers from implementing electronic posting, or automating the data entry of reimbursement information, as widely as they might otherwise. Correct implementation of the X12 835 will reduce phone calls to health plans, reduce appeals due to incomplete information, eliminate unnecessary customer support, and reduce the cost of sending and processing paper remittance advices. Commenters also noted that the greatly improved X12 278 for referrals and authorizations could encourage wider implementation and save labor costs. Commenters noted that the new claims transaction standard contained in Version 5010 significantly improves the reporting of clinical data, enabling the reporting of ICD-10-CM diagnosis codes and ICD-10-PCS procedure codes, and distinguishes between principal diagnosis, admitting diagnosis, external cause of injury and patient reason for visit codes. Commenters noted that these distinctions will improve the understanding of clinical data and enable better monitoring of mortality rates for certain illnesses, outcomes for specific treatment options, and hospital length of stay for certain conditions, as well as the clinical reasons for why the patient sought hospital care. Commenters also noted that another improvement in the updated claims standard is the ability to handle identification of the “Present on Admission” (POA) indicator to the diagnoses.

Response:
We appreciate the overwhelming support of commenters for the adoption of Version 5010.

Comment:
We received a few comments urging X12 to publish an all-inclusive list of changes made to the standards. Commenters said that a change log is issued after each year's changes are approved. Since Version 5010 incorporates multiple years of changes, users would be required to consolidate multiple change logs. A cumulative change log that includes changes from each interim year should be provided so that all of the changes are contained in one document.

Response:
We agree that it would be helpful to have a comprehensive list of the changes made to a current version of the standards, and that it would make it easier for covered entities to identify all of the changes that have occurred since the last version of the standard was adopted. We have made this recommendation to the X12 work group as well as the Designated Standards Maintenance Organizations (DSMO).

Many commenters submitted technical comments relating to Version 5010. The comments included highly technical issues and suggested structural changes to the standards, definitional issues requiring clarification, and interpretational issues regarding routine usage of the standards. In total, there were over 470 technical comments. We provided all of the technical comments to X12, which had convened a committee of subject matter experts to review the technical comments and provide us with technical input. The workgroup reviewed each comment and categorized them into several groups as follows: (1) The committee agrees with the comment and the change will be made in the next version of the TR3s (212 comments); (2) the committee does not agree with the comment and believes that a change is not appropriate (156 comments); (3) the functionality already exists elsewhere in the TR3s; commenter requires explanation and references (5 comments); and (4) the comment is a request for interpretation and/or training, and not a request for a change in the TR3s (43 comments). There were 29 comments that were not requests for action, but rather statements of opinion about Version 5010. Of the 212 comments falling into the first category, most were clarifications that would improve usability of the TR3s, but would not adversely affect business processes. Therefore, we will not request that X12 accommodate these changes in Version 5010, but rather would address them in the course of developing later versions of the standards.

After publication of the final rule, all of the technical comments reviewed by the X12 workgroup, with the dispositions, will be posted on the CMS Web site at
http://www.cms.hhs.gov,
in the Regulations and Guidance section, as well as on the X12 portal at
http://www.x12.org.
Where education and/or additional communication are needed about the functionality of the transactions, X12 will provide that in future programs, in collaboration with appropriate industry groups. These Standards Development Organizations (SDO)-sponsored efforts will specifically address the third category of comments in which the committee stated that the functionality exists elsewhere in the TR3s, or the fourth category of comments where the commenter specifically requested additional interpretation guidance.

During the comment review process, X12 provided input to HHS, and we selected several comments to include in this final rule as examples of the types of technical issues that were submitted during the public comment period. In general, suggested corrections, clarifications, and definitional changes to Version 5010 transaction standards will be reserved for future versions of the standards. Any suggested changes to the structure of the standard will need to be evaluated through the standards development process and considered for future versions of the standard. All comments submitted during the comment period for the August 22, 2008 proposed rule will automatically be included in the X12 process for considering change requests. Submitters will not need to re-submit those comments.

Comment:
We received a few comments requesting clarification of a statement in the August 22, 2008 proposed rule regarding the field size issue in Version 4010/4010A to accommodate ICD-10. In the August 22, 2008 proposed rule, we said that Version 4010/4010A does not provide a means for identifying ICD-10 procedure or diagnosis codes on an institutional claim, and that Version 5010 anticipates the eventual use of ICD-10 procedure and diagnosis codes by adding a qualifier as well as the space needed to report the number of characters that would permit reporting of ICD-10 procedure and diagnosis codes on institutional health care claims. Commenters pointed out that the more accurate explanation for why Version 4010/4010A cannot accommodate ICD-10 is because of the lack of a qualifier

or indicator for the code set name rather than the size of the field for the codes.

Response:
We note the correction.

Comment:
One commenter recommended a correction to Version 5010, specific to the claims transactions, to enable it to support the creation of a proposed National Joint Replacement Registry.

Response:
Because of the technical nature of this comment, we consulted with the X12 work group to better understand the context of the comment and the stated concern. Based on our current understanding of the comment, we agreed with the X12 workgroup on this recommendation for the next version of its TR3s, once the registry is finalized. This means that Version 5010 will not have changes made to it for this purpose at this time, but that the next version of the standards will likely have addressed and resolved this issue.

Comment:
We received several comments regarding the external code sets used in the standards, such as claims adjustment reason codes. Several commenters wrote about the X12 835 remittance advice code mapping requirements, stating that providers continue to struggle with implementation of the X12 835 as many health plans struggle to provide quality mapping from proprietary to standard codes in the health care payment and remittance advice transaction. Commenters requested that guidelines for mapping be provided.

Response:
During our consideration of these comments, which we believe apply to the technical standards maintenance process, and which we feel are outside of the scope of this rule, we consulted with the WEDI 835 special work group (SWG) to confirm that the stated concerns were being addressed in its standards revision process. The WEDI 835 SWG indicated that it is developing a recommended set of mapping instructions and information for the industry. In addition, the WEDI 835 SWG has adopted recommendations that will assist in facilitating a more standard implementation of the X12 835.

Comment:
We received a comment from a large specialty association representing anesthesiology. This group responded to a discussion in the August 22, 2008 proposed rule in which we indicate that efficiencies are gained by allowing only the reporting of minutes for anesthesia time in Version 5010, whereas Version 4010/4010A allows for reporting of anesthesia time in either units or minutes. The commenter stated that this change to Version 5010 will not add efficiency and/or cost savings to the submission and processing of claims for anesthesia care, and requested that units continue to be permitted, or alternatively, that additional time be allowed to implement this change because of its impact on business processes and contracts.

Response:
Due to the nature of this comment, which addresses potential efficiencies resulting from a technical provision in the Version 5010 implementation guide, we consulted with the X12 workgroup. Based on our discussion with the X12 workgroup, we think that the appropriate course for the commenter to follow would be to submit a change request to the workgroup because the X12 development cycle is ongoing, and change requests will continue to be accepted and reviewed for consideration for the next version of the standards. Given the change in this final rule in the compliance date for Version 5010, we believe the commenter's request for more time to implement the data requirement is addressed.

Comment:
Several commenters suggested changes to the situational rule for the health care diagnosis codes segment on the X12 837D for dental claims. The situational rule requires inclusion of diagnosis codes only under circumstances involving oral surgery or anesthesia. Commenters suggested that today's dental health plans are offering benefit plans that provide additional coverage for dental services when certain medical conditions exist. The commenter suggested that the situational rule be expanded to allow for dental providers to include diagnosis codes in cases where specific dental procedures may minimize the risks associated with the connection between the patient's oral and systemic health conditions.

Response:
We do not feel that these comments are within the scope of the proposed rule, but instead pertain to certain technical aspects of the X12 Technical Reports. As such, we shared the comments with the X12 expert committee, which agreed with this recommendation and committed to incorporating this change into future versions of X12 Technical Reports Type 3. As stated earlier, X12 will provide guidance on how to accommodate the functionality in Version 5010.

Comment:
A few comments focused on the ability of dental providers to report tooth numbers on the X12 837P claim. According to commenters, there is a need for all dental providers to be able to report tooth numbers on medical claims. There were two specific issues raised in this regard. First, even though a field for the tooth number has been designated temporarily, to accommodate claims from oral surgeons and other practitioners, a permanent data element is needed. The second issue pertains to the use of either a national or international tooth numbering system. These commenters stated that both numbering systems should be accommodated in the X12 837 Dental and Professional Guides. Currently, only the Universal National Tooth Designation System is accommodated in Version 5010.

Response:
Once again, we believe these comments pertain more directly to the technical provisions of the relevant implementation guides. We therefore consulted with the X12 expert committee, which agreed with the first issue regarding the ability of dental providers to report tooth number beyond oral surgery, and committed to allowing this level of reporting in future versions of the X12 standards. Regarding the issue of which tooth numbering system should be accommodated in Version 5010, the X12 committee encourages the commenters to initiate the discussion through the DSMO process with additional business justification for future consideration. The X12 portal has several HIPAA Implementation Guide Requests (HIRs) available which explain how to use the claims transaction for dental services in the interim (
http://www.X12.org
).

Overall, the technical comments received on Version 5010 did not represent issues that would prevent this version of the standard from being adopted as currently proposed. However, enhancements will either be implemented in future versions or further vetted for inclusion in future versions.

B. Adoption of NCPDP Telecommunication Standard Implementation Guide Version D Release 0 (D.0) and Equivalent Batch Standard Implementation Guide, Version 1, Release 2 (1.2) for Retail Pharmacy Transactions

We proposed to revise § 162.1102, § 162.1202, § 162.1302, and § 162.1802 by adding new paragraphs (c)(1) to each of those sections to adopt the NCPDP Telecommunication Standard Implementation Guide, Version D, Release 0 (Version D.0) and equivalent NCPDP Batch Standard Implementation Guide, Version 1, Release 2 (Version 1.2) in place of the NCPDP Telecommunication Standard Implementation Guide, Version 5, Release 1 (Version 5.1) and equivalent NCPDP Batch Standard Implementation Guide, Version 1, Release 1 (Version 1.1), for the following retail pharmacy drug transactions: health care claims or

equivalent encounter information; eligibility for a health plan; referral certification and authorization; and coordination of benefits.

Since the time that Version 5.1 was adopted as a transaction standard in the Transactions and Code Sets rule, the industry has submitted requests for modifications to Version 5.1 to NCPDP. Some of these modification requests were necessary for reasons similar to those for the X12 standards—changing business needs—many of which were necessitated by the requirements of the Medicare Prescription Drug, Improvement and Modernization Act of 2003 (MMA). The complete discussion of our proposal and reasons for the proposal can be found in the August 22, 2008 proposed rule (73 FR 49751).

Comment:
Commenters unanimously supported the adoption of Version D.0, agreeing that Version D.0 is needed so that transactions for the Medicare Part D pharmacy benefit can be conducted. We did not receive any technical comments on Version D.0.

Response:
We agree that Version D.0 is needed to enhance retail pharmacy transactions, as well as to better support Medicare Part D requirements. We are adopting Version D.0 as proposed.

C. Adoption of a Standard for Medicaid Pharmacy Subrogation: NCPDP Medicaid Subrogation Implementation Guide, Version 3.0 for Pharmacy Claims

We proposed adding a new subpart S to 45 CFR part 162 to adopt a standard for the subrogation of pharmacy claims paid by Medicaid. We proposed that the transaction would be the Medicaid pharmacy subrogation transaction, defined at proposed § 162.1901, and that the standard for that transaction would be the NCPDP Batch Standard Medicaid Subrogation Implementation Guide, Version 3, Release 0 (Version 3.0), July 2007 (hereinafter referred to as Version 3.0) at proposed § 162.1902. The complete discussion of our proposal and reasons for the proposal can be found in the August 22, 2008 proposed rule (73 FR 49751-49752).

Comment:
Commenters unanimously supported the adoption of Version 3.0 for Medicaid pharmacy subrogation, and we did not receive any comments in opposition. We also did not receive any technical comments on Version 3.0.

Response:
We are adopting Version 3.0 as the HIPAA standard at § 162.1902, for the Medicaid pharmacy subrogation transaction, as described at § 162.1901.

Comment:
Several commenters requested that standards for Medicaid subrogation also be adopted for other claims types in addition to pharmacy claims. The commenters pointed out that the ASC X12 837 claim standards used for processing institutional, professional and dental claims already include the ability to perform Medicaid subrogation and that these standards have also gone through the DSMO approval process.

Response:
We appreciate the suggestion that we adopt standards for conducting Medicaid subrogation for both pharmacy and medical claims. However, since we did not propose the adoption of Version 5010 for Medicaid subrogation of non-pharmacy claims, we cannot adopt it in this final rule. HHS will consider whether to adopt the X12 standard for non-pharmacy Medicaid subrogation transactions. If we pursue that option, we would propose it in an NPRM and take industry comments into consideration before we would adopt a standard.

We note that, although we are not adopting a standard for Medicaid subrogation for non-pharmacy related claims in this rule, those standards are available for use. Covered entities are not prohibited from using Version 5010 for non-pharmacy Medicaid subrogation transactions between willing trading partners. Some Medicaid agencies have already been successfully using this approach with commercial health plans.

Comment:
We received comments recommending that HHS clarify that State Medicaid agencies would not be prohibited from continuing to bill using paper claims when necessary.

Response:
We recognize that there may be situations where it is not cost-effective for State Medicaid agencies and certain plans to use an electronic format for pharmacy claims. For example, while a particular plan may process a large volume of claims, the same plan may have only a small number of Medicaid pharmacy subrogation claims. In addition, States continue to make advancements in identifying other liable payers. This enables States to avoid payment by returning claims to providers and instructing them to bill the other payers. This will result in a decrease in the volume of subrogation claims for Medicaid. Health plans do not always have to conduct electronic transactions for which a standard has been adopted, but if they do, the standard must be used. Section 162.923, however, places additional requirements on health plans so that if a covered entity wanted to conduct the transaction electronically with the Medicaid agency, the agency could not refuse to do so. Medicaid agencies could continue to bill on paper as long as both parties to the transaction agree to conduct the paper transaction. However, Medicaid agencies will still be required to have the capacity to transmit and receive the Medicaid pharmacy subrogation transaction electronically, in standard format, which the Medicaid agency could choose to do through its own system or through a health care clearinghouse.

Comment:
We received a comment from a pharmacy that supports the adoption of Version 3.0. The pharmacy requested that HHS enforce the use of the standard and eliminate the practice used by some States of recouping money from the pharmacy instead of the third party, which puts additional burden on the pharmacy to bill the third party and in some instances re-bill Medicaid.

Response:
It is not in the purview of this regulation to eliminate the practice of recoupment from providers. The adoption of the Medicaid pharmacy subrogation standard will not restrict States that choose to recoup from providers in lieu of seeking reimbursement from the third party directly. Once a claim is paid to a pharmacy, the State has the option to seek recovery directly from liable third party payers, or to seek recovery as an overpayment from the provider. We believe that the adoption of the Medicaid pharmacy subrogation standard will greatly improve the efficiency and effectiveness of the health care system which should result in more direct billing of third parties in States that routinely recoup from providers.

D. Adoption of the NCPDP Telecommunication Standard Implementation Guide Version D Release 0 (D.0) and the Health Care Claim: Professional ASC X12 Technical Report Type 3 for Billing Retail Pharmacy Supplies and Services

We proposed to revise § 162.1102 to adopt both Version D.0 and the 837 Health Care Claim: Professional ASC X12 Technical Report Type 3 for billing retail pharmacy supplies and professional services. The use of either standard would be determined by trading partner agreements. The complete discussion of our proposal and the reasons for the proposal can be found in the August 22, 2008 proposed rule (73 FR 49752-49754).

Comment:
We received several comments in support of the proposal to allow the use of either standard for this purpose. Commenters agreed that the NCPDP Telecommunication and Batch Standard supports the billing of the various code sets needed to bill retail pharmacy supplies and professional services (for example, Medication Therapy Management (MTM), vaccine

administration), and that they can use this NCPDP standard for most of their transactions. The commenters said that workflow will be less disrupted when pharmacies can bill for services and supplies using the same NCPDP standard as that used for pharmacy drug claims. Commenters said that the ability to use the NCPDP standard will improve customer service and lower administrative costs. These commenters said that in some cases the X12 standard was appropriate, and that they preferred to have the option of using it on a case-by-case basis.

Response:
We are adopting our proposal to allow the use of either Version D.0 or Version 5010 for billing retail pharmacy supplies and professional services.

Comment:
A few commenters noted their support of the proposal, particularly as it relates to improving interoperability of claims processing and adjudication, and suggested that we clarify how our proposal would be implemented with respect to trading partner agreements. Another commenter was cautiously supportive, and said that it agreed with the use of either standard, but that we should emphasize the requirement that trading partner agreements be voluntary, and that a health plan could not create a mandate to use one standard over the other.

Response:
We reiterate that, by adopting both standards for the one transaction, we are supporting current industry practices with respect to the use of these standards for billing supplies and services that are commonly dispensed or conducted via the retail pharmacy channel. With the exception of the requirements set forth in § 162.915, regarding certain particulars that may not be included in trading partner agreements, we do not dictate the terms of trading partner agreements but expect that health plans and providers will continue to collaborate on the processes for these claim types.

In addition to revising the regulation text at § 162.1102 to allow for the use of either the X12 or the NCPDP standard for billing retail pharmacy supplies and professional services, we are also making a conforming change to the definition of “standard transaction” at § 162.103. We indicate that a standard transaction means a transaction that complies with “an” applicable standard adopted under this part, rather than “the” applicable standard adopted under this part.

Comment:
One commenter said that if we are adopting standards for retail pharmacy supplies and services, that we should clearly state that both adopted standards apply to Medication Therapy Management (MTM) services. The commenter stated that MTM is a service designed to ensure that Part D drugs prescribed to targeted beneficiaries are appropriately used to optimize therapeutic outcomes through improved medication.

Response:
In the August 22, 2008 proposed rule, we address MTM services, noting that the MMA provides coverage for MTM, which is a distinct set of services that encompasses a broad range of professional activities and responsibilities. We noted that some pharmacies believe it is appropriate to use the NCPDP standard for MTM services because the services are part of the prescription. Other industry segments, however, believe it is appropriate to use the X12 standard for billing MTM services because they interpret “professional services” to require the use of a professional claim (837P) (73 FR 49753). We agree with the commenter and affirm that MTM is included as a service to which both standards apply.

E. Modifications to the Descriptions of Transactions

We proposed to revise the descriptions of the transactions at § 162.1301, § 162.1401, and § 162.1501 to clearly specify the senders and receivers of those transactions. We proposed to revise the descriptions for the following transactions: (1) Enrollment and Disenrollment in a Health Plan; (2) Referral Certification and Authorization; and (3) Health Care Claim Status.

Comment:
The majority of commenters expressed their support for the revised transaction descriptions.

Response:
We are adopting the revisions to the regulation text as proposed.

Comment:
Several pharmacies and a national pharmacy chain noted that real-time pharmacy claim transaction statuses are given using the NCPDP standard in real time, whereas Version 4010/4010A is a batch standard. A commenter requested that our definition of the health care claim status transaction specify that Version 5010 (ASC X12 276/277) is used to provide status on X12 transactions for medical claims only, because the commenter wanted clear differentiation between pharmacy and non-pharmacy claims.

Response:
We are not making a change in our regulation text because we do not think it is appropriate. In § 162.1401, the description of the health care claim status transaction only describes the actions and specifies the senders and receivers of the transaction, whereas § 162.1402 clearly identifies the standard that is adopted for the function described in § 162.1401.

Comment:
We received a comment requesting a technical clarification to the enrollment and disenrollment in a health plan transaction (§ 162.1501). The commenter stated that there has always been a concern as to when the enrollment/disenrollment (834) transaction was required. This commenter believed that the definition of a group health plan could be applied to the plan sponsor role of a self-funded employer group, which would require the plan sponsor to use the enrollment transaction. The commenter recommended that the final rule include wording to further clarify this requirement, by adding to § 162.1501 the following: For the purpose of enrollment and disenrollment in their health plan, the term sponsor shall include self-funded employer groups that transmit electronic information to their Third Party Administrator (TPA) to establish or terminate insurance coverage for their member.

Response:
We proposed to describe this transaction as being “the transmission of subscriber enrollment information from the sponsor of the insurance coverage, benefits, or policy, to a health plan to establish or terminate insurance coverage.” We provided in the August 22, 2008 proposed rule that a sponsor is an employer that provides benefits to its employees, members, or beneficiaries through contracted services. We further noted that numerous entity types act as sponsors in providing benefits, including, for example, unions, government agencies, and associations (73 FR 49754). We do not think it is appropriate to further revise the definition of the enrollment and disenrollment in a health plan transaction to specify that a sponsor includes any one particular type of entity, as the commenter suggests. We reiterate here that it is not mandatory for a sponsor that is not otherwise a covered entity to use the transaction standard because, as a non-covered entity, HIPAA does not apply to it.

F. Compliance and Effective Dates

Versions 5010 and D.0: We proposed to adopt a date of April 1, 2010 for all covered entities to be in compliance with Versions 5010 and D.0. In the August 22, 2008 proposed rule, we discussed our reasons for proposing the compliance timeframe we did. We justified the proposed date based on assumptions that the industry had sufficient expertise in using the X12 and NCPDP standards, and that the system and business changes could therefore be

efficiently coordinated, requiring less time than the original standards for implementation. We also discussed at length an alternative we considered, but did not propose—a staggered compliance timeframe for Versions 5010 and D.0 (72 FR 49754-49757). We received more than 100 comments on compliance dates, with virtually all indicating that the proposed compliance date was not feasible given the extensive changes in Versions 5010 and D.0 from the current standards, and the need for a coordinated implementation and testing schedule. As stated at the beginning of the preamble, this rule is effective March 17, 2009. We note that the effective date is the date that the policies set forth in this final rule take effect, and new policies are considered to be officially adopted. The compliance dates, which are different than the effective dates, are the dates on which entities are required to have implemented the policies adopted in this rule. The compliance dates we now adopt for this regulation are as follows:

• Versions 5010 and D.0—January 1, 2012.

• Version 3.0 for all covered entities except small health plans—January 1, 2012.

• Version 3.0 for small health plans—January 1, 2013.

Comment:
The majority of commenters opposed the proposed compliance date for Versions 5010 and D.0 and requested additional time for implementation. Most commenters stated that the proposed date did not provide sufficient time to adequately execute a gap analysis for all of the transactions, build programs, train staff, and conduct outreach and testing with trading partners. These commenters stressed the need to avoid compliance extensions or contingency periods because they complicate implementations and increase costs. Health plans and providers expressed concern that the proposed compliance date was unrealistic because large segments of the industry have not been able to meet any of the deadlines for the HIPAA standards to date, including Medicare and many State Medicaid agencies.

The majority of commenters who opposed the April 2010 compliance date suggested a thirty-six month compliance period instead. These commenters said that this amount of time is needed for full implementation because the same programmers, developers and operations staff who must re-design technical and business infrastructure activities to accommodate Versions 5010 and D.0 will also be needed to do similar work to implement ICD-10. In fact, some commenters suggested that the impact of ICD-10 is so significant, that there might not be sufficient industry resources to address Versions 5010 and D.0 because of competing resource needs. A number of health plans stated that, based on their own impact assessments, not only would record layouts and mapping changes be required, but also changes to edits, business procedures and system capabilities. They stated that there are nearly 850 changes between Version 4010/4010A and Version 5010 to be analyzed and potentially implemented. One example is the X12 270/271 eligibility transaction, which will require a more detailed response with less information supplied. Plans will have to determine where the data can be accessed and whether it exists within the current software; in many cases, it will not be a case of moving a few extra fields, and databases may have to be modified or created. These commenters said the complexity of the Technical Reports Type 3 requires in-depth analysis, which will have to be conducted through formal procedures (impact analysis, requirements definition) before design, build, and testing can take place. Similar comments were received regarding the compliance date for Version D.0.

All entities that submitted comments agreed with the proposed adoption of that standard, but did not think enough time was given for implementation. Commenters stated that the transition from Version 5.1 to Version D.0 has functional complexity that will require standardization of practices, new fields, new situational rules for each data element, as well as education, testing and training. These commenters pointed out that, although there have been 22 version releases of the NCPDP standard since Version 5.1, the majority of the industry was reluctant to develop software for any version that was not adopted under HIPAA. These commenters suggested a 36-month implementation schedule for Version D.0.

Response:
Based on the comments and our analysis of those comments, we are adopting a compliance date later than the date we proposed for all covered entities for Version 5010 and Version D.0. We are requiring that all covered entities be in compliance with Versions 5010 and D.0 on January 1, 2012.

We believe that it is crucial for covered entities to meet certain milestones during the compliance period in order to ensure full, successful, and timely compliance. The NCVHS recommended a framework for compliance that we believe will be very effective for these purposes. Therefore, we describe below the NCVHS recommendation and the schedule to which we expect covered entities to adhere during the compliance period.

A letter from the NCVHS to Secretary of HHS Michael Leavitt dated September 26, 2007 (
http://www.ncvhs.hhs.gov
) summarized the Committee's Standards and Security Subcommittee's HIPAA transaction hearings of July 2007, noting that “the timing of standards implementation is critical to success.” The NCVHS weighed the industry testimony presented at that hearing and noted that HHS should consider establishing two different levels of compliance for the implementation of Version 5010. Level 1 compliance, as interpreted by the NCVHS, means that the HIPAA covered entity could demonstrate that it could create and receive Version 5010 compliant transactions. Level 2 compliance was interpreted by the NCVHS to mean that HIPAA covered entities had completed end-to-end testing with all of their partners and were ready to move into full production with the new version. The NCVHS letter stated that: “it is critical that the industry is afforded the opportunity to test and verify Version 5010 up to two years prior to the adoption of Version 5010.” The letter's Recommendation 2.2 states that “HHS should take under consideration testifier feedback indicating that for Version 5010, two years will be needed to achieve Level 1 compliance.”

Accordingly, our expectations are as follows. The Level 1 testing period is the period during which covered entities perform all of their internal readiness activities in preparation for testing the new versions of the standards with their trading partners. When we refer to compliance with Level 1, we mean that a covered entity can demonstrably create and receive compliant transactions, resulting from the completion of all design/build activities and internal testing. When a covered entity has attained Level 1 compliance, it has completed all internal readiness activities and is fully prepared to initiate testing of the new versions in a test or production environment, pursuant to its standard protocols for testing and implementing new software or data exchanges. The Level 2 testing period is the period during which covered entities are preparing to reach full production readiness with all trading partners. When a covered entity is in compliance with Level 2, it has completed end-to-end testing with each of its trading

partners, and is able to operate in production mode with the new versions of the standards by the end of that period. By “production mode,” we mean that covered entities can successfully exchange (accept and/or send) standard transactions and as appropriate, be able to process them successfully.

During the Level 1 and Level 2 testing periods, either version of the standards may be used in production mode—Version 4010/4010A and/or Version 5010, as well as Version 5.1 and/or Version D.0—as agreed to by trading partners. Covered entities should be prepared to meet Level 1 compliance by December 31, 2010, and Level 2 compliance by December 31, 2011. After December 31, 2011, covered entities may not use Versions 4010/4010A and 5.1. On January 1, 2012, all covered entities will have reached Level 2 compliance, and must be fully compliant in using Versions 5010 and D.0 exclusively.

The final compliance date provides an implementation period of 36 months, or three years, as requested by the majority of the commenters. Given this revised implementation period that accommodates NCVHS and industry concerns, we expect that covered entities will be able to meet the compliance date. We anticipate that, since there was support for a phased-in schedule, health plans and clearinghouses will make every effort to be fully compliant on January 1, 2012. Covered entities are urged to begin preparations now, to incorporate effective planning, collaboration and testing in their implementation strategies, and to identify and mitigate any barriers long before the deadline. While we have authorized contingency plans in the past, we do not intend to do so in this case, as such an action would likely adversely impact ICD-10 implementation activities. HIPAA gives us authority to invoke civil money penalties against covered entities who do not comply with the standards, and we have been encouraged by industry to use our authority on a wider scale. We refer readers to the HIPAA Enforcement Final Rule (71 FR 8390), published in the
Federal Register
on February 16, 2006, for our regulations implementing that HIPAA authority.

Compliance Date for Version 3.0

For implementation of Version 3.0 for the Medicaid pharmacy subrogation transaction, we proposed to revise § 162.900 to adopt a compliance date of 24 months after the effective date of the final rule for all covered entities, except for small health plans, which would have 36 months. We also proposed to revise § 162.923, entitled “Requirements for covered entities” to make paragraph (a) applicable only to covered entities that conduct transactions with other entities that are required to comply with a transaction standard. We proposed this change in order to address the situation where transactions require the participation of two covered entities, where one entity is under a different set of compliance requirements. We expect that the change we proposed to § 162.923 would resolve the problem of a State Medicaid agency attempting to transmit a transaction using Version 3.0 to a small health plan before the small health plan is required to be compliant and could, therefore, reject the transaction on the basis that it is in the standard format (73 FR 49754-49755).

Comment:
We received one comment explaining that Version 3.0 had to be implemented either at the same time as Version D.0, or after, because certain data elements present in D.0, but not in Version 5.1, were needed in order to use Version 3.0. The commenter also believed that willing trading partners would be able to agree to use the Medicaid pharmacy subrogation standard voluntarily at any time after the effective date and before the compliance date.

Response:
We agree that Versions D.0 and 3.0 are tied together by certain data elements necessitating their concomitant or sequential implementation respectively. To accommodate these technical needs, we are making the effective date of Version 3.0 later than the effective date for the other parts of this rule. We are making the effective date for the portion of the rule concerning the adoption of Version 3.0 January 1, 2010, which means that covered entities, except small health plans, must be in compliance with Version 3.0 no later than January 1, 2012. Small health plans must be in compliance no later than January 1, 2013. This gives States and health plans a two-year planning, implementation and testing window, in contrast to the three years being provided for Versions 5010 and D.0. States and plans are encouraged to do as much planning in the year before the effective date (calendar year 2009) as possible, to take advantage of that window and the work already under way for Version D.0, since Versions D.0 and 3.0 are tied together. In other words, States may use calendar year 2009 to conduct a preliminary analysis of Version 3.0 changes, in concert with their analysis of Version D.0 changes. States should also prepare and submit their budget requests to secure funding for design, development and implementation in 2010 and 2011, which would leave time to conduct testing with trading partners between January 2011 and January 2012.

Comment:
We received a number of comments from providers and health plans supporting the proposed revision to § 162.923(a).

Response:
We are adopting the revision to § 162.923(a), as proposed in the August 22, 2008 proposed rule.

Timeline

In the proposed rule, we provided a timeline for implementation and compliance of ICD-10 and Versions 5010 and D.0. We included the timeline to enable the industry to conduct preliminary planning (73 FR 49757), and indicated that the proposed timeline represented our best estimate for industry implementation at the time. We also indicated that the timeline was subject to revision as updated information became available. We provide the revised timeline here.

Timeline for Implementing Versions 5010/D.0, Version 3.0 and ICD-10

Version 5010/D.0 and Version 3.0
ICD-10

01/09: Publish final rule
01/09: Publish Final Rule.

01/09: Begin Level 1 testing period activities (gap analysis, design, development, internal testing) for Versions 5010 and D.0

01/10: Begin internal testing for Versions 5010 and D.0

12/10: Achieve Level 1 compliance (Covered entities have completed internal testing and can send and receive compliant transactions) for Versions 5010 and D.0

01/11: Begin Level 2 testing period activities (external testing with trading partners and move into production; dual processing mode) for Versions 5010 and D.0
01/11: Begin initial compliance activities (gap analysis, design, development, internal testing).

01/12: Achieve Level 2 compliance; Compliance date for all covered entities. This is also the compliance date for Version 3.0 for all covered entities except small health plans *

01/13: Compliance date for Version 3.0 for small health plans

10/13: Compliance date for all covered entities (subject to the final compliance date in any rule published for the adoption of ICD-10).

* Note: Level 1 and Level 2 compliance requirements only apply to Versions 5010 and D.0

Other Comments Pertaining to the Compliance Date Specific to Versions 5010 and D.0

Comment:
We received a few comments from Medicaid agencies explaining why the compliance dates were problematic from a funding perspective. Commenters explained that the State budget environment requires more lead time to obtain project authority and resources on the scale necessary to implement Versions 5010, D.0, and 3.0. One State said that it could not begin any substantial required documentation activities until there is a final rule. Finally, a number of States said that they are facing fairly significant budget shortages. Commenters said that, even with 90 percent federal matching rates, resource requests based on a proposed rule would be unlikely to receive approval from legislatures.

Response:
The comments from the States were compelling with respect to funding and planning issues, and were helpful in our reconsideration of the proposed compliance dates. We acknowledge the need to work with States to coordinate their budget requests and implementation activities with legacy system replacement.

Comment:
Another State agency recommended that the final rule contain a waiver provision to permit covered entities to seek a waiver for implementation of Version 5010 in any existing legacy system that is scheduled for replacement.

Response:
Waivers cannot be accommodated. Neither the statute nor the regulations provide for waivers for meeting the standards set forth under HIPAA.

Comment:
A few commenters favored the proposed compliance dates for Versions 5010 and D.0, citing their eagerness to begin benefiting from the updated standards as soon as possible, particularly because it has been so long between adoption of Versions 4010/4010A1 and 5.1, and the updated versions of those standards.

Response:
We believed the proposed compliance dates were reasonable for the reasons provided in the proposed rule (73 FR 49754-49757). Based on the comments however, we acknowledge that many significant actions would have to take place very quickly (for example, budget requests, hiring and recruitment of subject matter experts, design work, schedule of programming installations, etc.) in order to meet an April 2010 compliance date, and as stated above, have adopted a later date for both standards.

Comment:
The majority of commenters agreed that small health plans should not have additional time (for example, an additional year as in past regulations) to become compliant with Versions 5010 and D.0 because these entities are, or should be, already using Version 4010/4010A and Version 5.1 through clearinghouses or their own systems. Small health plans should be at the same stage of implementation as any other covered entity, meaning that their organizations, business associates and trading partners are now well-versed in the technology and requirements for using Version 4010/4010A and Version 5.1, and should not require additional time to accommodate the new versions. All covered entities are essentially at the same point with respect to having implemented the standards, identified and resolved business process issues, trained staff, and incorporated the use of standards process into their existing infrastructure.

Response:
We agree with commenters regarding the compliance dates for small health plans, and are requiring all covered entities, including small health plans, to be in compliance on the same date.

Comment:
We received several comments supporting a different schedule which involved staggering compliance based on either covered entity type or transaction type over the course of 3 years. In the first scenario, all health plans and clearinghouses would be required to be compliant one year before covered health care providers in order to ensure that providers could begin testing with all trading partners the following year. For example, under a 36-month compliance scenario, health plans and clearinghouses would have to be in compliance 24 months after the effective date, and prepared to conduct testing with trading partners over the next 12 months. We also received a few comments that suggested a staggered implementation schedule by transaction type. For example, the updated standards for health care claims and related transactions could be implemented first, followed by updated standards for eligibility transactions, claims status transactions, etc. However, the majority of commenters who had opinions about a staggered implementation schedule based on transaction type believe that assigning different compliance dates to different transactions would not have the intended effect of ensuring compliance by the deadline, nor would it facilitate the testing process. These commenters explained that the use of certain transactions, particularly auxiliary transactions (for example, authorizations and referrals), is so inconsistent across the industry, there would be no effective means by which to stagger their implementation. The use of the auxiliary transactions is uneven—many entities do not use the claims status transactions because they have on-line access to their billing files; many do not use the eligibility transaction because, historically, it has not provided useful information. Thus, entities actually have very little experience with these transactions, and may continue to use them minimally. They do not wish to expend limited resources on a transaction that will not have a return on investment in the early years.

Response:
We believe that different compliance dates for different types of covered entities could significantly complicate trading partner testing, particularly for those entities that function as both health plans and health care providers, as well as for other entity types that perform in multiple roles. It is likely that different compliance dates for different entity types could be confusing to the industry, and could actually delay some implementations while entities waited for trading partner compliance. For

example, this approach presumes that providers and their software vendors will be making system and operational changes at the same time as the health plans and clearinghouses in order to be ready for testing.

Comment:
We received a number of comments about our assumption in the August 22, 2008 proposed rule that staggered implementation dates for health plans and clearinghouses would not be feasible because of robust trading partner tracking systems that might be needed so that entities could know which providers were testing Versions 5010 and/or D.0, which were using Versions 4010/4010A and/or 5.1, and which had fully converted to Versions 5010 and/or D.0. This would be very complicated to build and manage between the thousands of providers, health plans, vendors and clearinghouses. Commenters also expressed concern about the impact on coordination of benefits with secondary health plans, since each health plan would be implementing Version 5010 at different times. One commenter said that the reality is that all covered entities would need robust trading partner tracking systems for any implementation plan, and that coordination of benefits would be disrupted with any implementation plan because not all covered entities would be ready on the same date to send and receive the updated HIPAA standards. Commenters said that covered entities would have to support the dual use of Version 4010/4010A and Version 5010 until the compliance date in any scenario. They explained that all covered entities would need to test at different times during the implementation process, and that a complex scheduling process would need to exist between health plans, clearinghouses and providers testing and migrating to the updated transactions at different times.

Response:
We agree with the commenters' points regarding the complexity of programming, testing and coordinating all implementation efforts, regardless of the timeline, if we were to adopt a staggered implementation schedule by entity type or transaction type.

Comment:
Some commenters said that all health plans, including State Medicaid agencies, must be held to the same compliance dates, and that compliance with prior HIPAA implementations varies between non-government health plans and State Medicaid agencies. Since Medicaid agencies have lagged behind and not met implementation deadlines, hospitals and providers have had to maintain a dual submission strategy which incurs significant additional costs to the providers. We received a number of comments expressing particular concern about Medicare mandating full compliance prior to the compliance date adopted by the final rule. The commenters specifically referenced written communication they had received from Medicare stating that it (Medicare) would have an early compliance date for Version 5010 for the coordination of benefits transaction. The commenters stated that, if Medicare requires covered entities to be ready to shift to dual processing several months before the adopted compliance date, there will be significant implementation problems for many providers and other health plans. The commenters also stated that, if Medicare mandates use of Version 5010 for coordination of benefits, before any of the other transactions were mandated for use, other health plans would have to run separate processing systems for just the one transaction. Other commenters stated that health plans do not maintain separate processing systems for each additional health plan with which they conduct COB transactions. Commenters stated that, if Medicare is allowed to mandate early compliance, it would exacerbate an already difficult situation, and reiterated that no entity should be allowed to require their trading partners to implement the standards in a production environment, prior to the HHS compliance date, if the trading partner did not agree. These commenters feel that such a prohibition would help ease the implementation as solutions are deployed across all entities, over a defined period of time.

Response:
We agree that no covered entity, including State Medicaid agencies or Medicare, should be allowed to require compliance earlier than the compliance date we are adopting in this final rule. If entities were allowed to require earlier compliance, this would cause undue financial and operational burdens on other segments of the industry. For example, one State chose to implement the NPI before the compliance deadline, which caused significant difficulties and expenses for providers because, in some cases, they were not ready to comply, and therefore had to revert to paper. In many cases, the State's other trading partners, namely other commercial health plans and the Federal Medicare program, were not prepared to accept the NPI, which meant that providers (and their vendors and clearinghouses) in that State had to support a complex infrastructure in which the NPI was included on some claims, but not on others. HHS will ensure that appropriate agencies and departments work together to monitor Medicaid implementation work plans, testing and readiness on a regular basis throughout the implementation period.

We are adopting a revision to § 162.925, by adding a new paragraph (a)(6), to specify that a health plan is not permitted to delay, reject, or attempt to adversely affect the other entity or the transaction on the basis that the transaction does not comply with another adopted standard during the period from the effective date of the final rule until the compliance date. With respect to coordination of benefits, this means, for example, that Medicare will not be able to require of trading partners that they be in full compliance with Version 5010 prior to January 1, 2012, unless willing trading partners agree to do so. Health plans that participate in Medicare's Coordination of Benefits program will be able to work with Medicare to arrange a mutually agreeable testing schedule in order to expedite this transaction, but they are not required to do so, and may revert to receiving claims directly from providers if they choose to do so.

Comment:
Commenters said that a key component of any implementation schedule is testing, and a large number of commenters stressed the importance of both internal testing as well as external testing with trading partners. Many commenters stated that testing often occurs at or near the end of the compliance period, and that such last-minute testing causes scheduling problems and creates uncertainty about whether changes were applied correctly. Commenters said that, in many cases, hospitals and other providers must wait for vendors and health plans to schedule testing. Many commenters said that health plans do not provide sufficient advance communication about their testing efforts or their readiness to implement the standards, and providers have indicated that it is difficult to obtain the name of the individual or department within the health plan with whom they should coordinate. One commenter explained that testing is done in three parts: Testing of the standards themselves for workability; conformance testing of products and applications that send and/or receive the transactions; and end-to-end testing to ensure interoperability among trading partners. All three levels of testing are critical to the successful implementation of Versions 5010, D.0 and 3.0, and efforts to execute all three levels of testing will minimize delays and avoid many of the

complications afflicting previous implementations.

Response:
We agree that testing is absolutely crucial to resolving problems before the implementation date to ensure that there are no payment delays or service disruptions. In the August 22, 2008 proposed rule, we discussed and emphasized the importance of testing to a successful and timely implementation (73 FR 49755-49756). Based on the industry's experience in previous implementations, it is clear to us that testing is core to resolving issues early and effectively. We have revised the regulation text that identifies the adopted standard for each transaction, in every instance, to enable testing to occur during the period from the effective date of the final rule until the compliance date for Versions 5010 and D.0. Our revised regulations permit the dual use of standards during that timeframe, so that either Version 4010/41010A1 or Version 5010, and either Version 5.1 or Version D.0, may be used for the period prior to the compliance date. We note that the adoption of two standards for one transaction during the period prior to compliance does not mean that covered entities must use both standards, but, rather, that the use of either standard is permitted.

Comment:
Another commenter said that the importance of vendor compliance cannot be underestimated, as practice management system vendors are critical to provider compliance. Any delays in vendor implementation of compliant products will delay end-to-end testing, so providing sufficient time for the vendors to design, build and test, will only facilitate the process. A large software vendor explained that, to enable compliance with Versions 5010 and D.0, users must continue to use their current software while testing new software updates to accommodate the changes. The commenter explained that there are often several stages of software revisions, and this necessity may add additional time to the development and implementation process. Finally, testing and certification activities on each version must take place to ensure compatibility and stability of software. This process almost always takes longer than expected.

Response:
While we do not have the authority to regulate vendors, as they are not covered entities, we agree about the critical importance of vendor testing, and that, in particular, accurate, quality software development and testing are critical to the successful implementation of the updated versions. We also agree that appropriate time is necessary for installation, user training and coordination of testing with trading partners. By adopting a later compliance date, we hope to ensure that software development vendors have sufficient time to conduct the appropriate internal and external testing such that the software they provide to their covered entity clients is compliant with the standards, capable of facilitating the transmission and receipt of the new versions of the standards.

G. Miscellaneous/General Other Comments

This section includes comments and responses to other issues raised during the public comment period.

Claims Attachments

Comment:
We received several comments requesting that HHS not adopt standards for electronic health care claims attachments at this time because implementation of Versions 5010, D.0, and 3.0, and ICD-10 would make it impossible to also implement standards for claims attachments. One commenter stressed that, since claims attachments included another new standard—the HL7 Attachment Specifications—the industry would not be able to accommodate the additional work needed to implement the claims attachment standard if Versions 5010, D.0, and 3.0, and ICD-10 also had to be implemented in that same time period.

Response:
We appreciate and will consider the commenters' concerns for not wanting to have to implement the electronic health care claims attachment standards at the same time as Versions 5010, D.0 and 3.0, and ICD-10.

Standards Adoption and Modifications

In the August 22, 2008 proposed rule, we provided an explanation of the procedures for maintaining existing standards and for adopting new standards and modifications to existing standards (73 FR 49744-49755). That section of the proposed rule describes how § 162.910 sets out the standards maintenance process and defines the role of SDOs and the DSMOs. For additional information about the DSMO process and procedures, refer to the Web site at
http://www.hipaa-dsmo.org/Main.asp
. We also described the process for adopting modifications to standards under § 162.910, which is discussed in detail in the Transactions and Code Sets rule (65 FR 50312), and implemented at § 162.910.

The proposed modifications and the new transaction standards were developed through the process that conforms with § 162.910. We received many technical comments specific to the Version 5010 standards, indicating that there are still opportunities for improvement in that version. We did not receive any technical comments specific to Version D.0.

Comment:
A few commenters stated that greater industry involvement in the X12 standards development and balloting process would be helpful to their industry segment, e.g., health care providers, hospitals, health plans, health care clearinghouses and vendors.

Response:
We have suggested to the X12 SDO that it consider the following: (1) Expanding the current outreach efforts to industry to obtain more diverse representation from all covered entity types. This would take place during the development of new versions as well as during the balloting process; and (2) securing industry volunteers to test the balloted standards before they are proposed to NCVHS. That way, when the suggested modifications are submitted to NCVHS for consideration, even greater industry support can be expected.

Comment:
We received a few comments suggesting that HHS streamline the standards adoption process. Commenters said that the marketplace is evolving at a rapid pace, creating new products, new technologies and new methods of conducting business. They stressed that, even though X12 continues to improve the standards each year, the industry has not had the opportunity to benefit from necessary and helpful changes because too much time elapses between the adoption of versions. Others reiterated that there is a need for the updated standards to be available for use by the industry as they are tested and balloted. For example, one entity found that the industry needs information about tax advantaged payment mechanisms (for example, Medical Savings Accounts, Health Savings Accounts, Health Reimbursement Accounts, etc.) that are now commonly in place to support the movement to consumer-directed health care. Version 5010 does not contain the information needed by patients or providers to determine the financial impacts and flows. Commenters said that the industry cannot wait another eight years to be able to exchange this type of crucial information for critical market needs. They suggest that a more streamlined way to develop, implement and adopt updated standards must be found. Commenters suggested that HHS work with industry stakeholders to identify and implement a way to increase the predictability and timeliness of adopting updated standards, including a means by which the rulemaking process might not be

necessary to allow the industry to use updated versions of the standards.

Response:
HHS has considered similar concerns in the past, and continues to assess potential alternatives within the context of HIPAA and the Administrative Procedures Act (APA). HHS will continue to work with industry to identify a means by which updated standards can be used on a timelier basis, consistent with the law.

Comment:
One commenter recommended that HHS adopt the X12 standard transaction formats in the final rule, but not the specific versions of the X12 standards or Technical Reports Type 3 (TR3s). The commenter stated that it has been eight years since publication of the Transactions and Code Sets rule adopting the Version 4010/4010A implementation guides. The long passage of time since the initial adoption has resulted in widespread workarounds in the industry to address Version 4010/4010A's deficiencies. The commenter suggests that HHS could designate the DSMO coordinating committee to biannually determine whether a change makes sense for the industry, and which updated TR3s would be implemented. The DSMO committee would still provide open public access to the standards development process, but this approach would eliminate the time-consuming NPRM steps and enable smaller iterative version updates to take place. The commenter noted that the ongoing maintenance of the adopted code sets is already handled outside of the NPRM process. Under this recommendation, new standards, as opposed to updates or modifications to the standards, would continue to be adopted by HHS utilizing the regulatory process.

Response:
HHS has evaluated options for streamlining the process of adopting new versions of the standards, and agrees with commenters that alternate, more expedient methods are necessary, consistent with HIPAA and the APA. We are committed to working with industry and the standards organizations to develop a process that can be proposed in the near future, consistent with the law. With respect to the commenter's reference to the ongoing maintenance of the adopted code sets, HHS notes that there is specific statutory authority in HIPAA which permits the routine maintenance, testing, enhancement and expansion of code sets outside of the rulemaking process; modifications to adopted code sets, however, are adopted by means of the rulemaking process.

Outreach, Education and Training

In the proposed rule, at 73 FR 49756, we stated that HHS would begin preparations for, and execution of, outreach and education activities, and the engagement of industry leaders and stakeholder organizations to provide a variety of educational and communication programs for various constituencies.

Comment:
Many commenters advised HHS to establish a network of training and outreach partners to work collaboratively to educate the industry, and outlined the education and outreach strategies that will be needed. Commenters stated there were needs for: National associations to collaborate on education efforts; a consistent set of messages and/or materials from authoritative sources; recognition that different audiences may need different levels of training; and in-person training to supplement Internet training and printed documents. Several commenters recommended that HHS develop a consistent standard set of training materials for distribution to industry groups as soon as possible. The commenter suggested that key professional associations should be the source for common educational materials. One commenter suggested that HHS collaborate with other organizations to publish a “lessons learned” guidance document. A number of commenters recommended that HHS begin outreach activities as quickly as possible, and to clearly differentiate between HHS Policy guidance (for the industry at large) and Medicare guidance (specifically for Medicare providers). Other commenters agreed, indicating that this was important because Medicare policies do not often apply to other covered entities' policies, and information is confusing to providers when it is not clearly differentiated. Another commenter provided a summarized list of requested technical assistance which included migration tools that automatically translate Version 4010/4010A to Version 5010, and Version 5010 to Version 4010/4010A.

Response:
We agree that it is important that consistent and accurate messages and/or materials be developed by authoritative sources, and will work closely with industry to put together a comprehensive, diverse plan that addresses Medicare-specific policies, as well as industry-wide policies and implementation issues.

We agree that different audiences may need different levels of training. Our current plan is to develop and disseminate high-level materials, and we anticipate that the industry will continue to offer the more in-depth materials that specific stakeholder groups may need. HHS already dedicates a section of its Web site to the HIPAA regulations, including guidance papers, FAQs, and links to external Web sites and to other useful resources. The Web site is
http://www.cms.hhs.gov
.

Comment:
We received a number of comments suggesting that HHS ensure better coordination of the communication of, by, and between, Medicare and Medicaid.

Response:
We agree that all segments of the industry should collaborate and communicate on implementation to avoid misunderstanding and to coordinate testing schedules. We will work with State Medicaid agencies to support their development of communication and outreach initiatives as we develop the overarching implementation strategy for education. We will also help to ensure that there are regular opportunities for Medicare and Medicaid to collaborate on implementation strategies.

Companion Guides

In the August 22, 2008 proposed rule, we discussed the deficiencies in Version 4010/4010A and Version 5.1, and the fact that the industry has come to rely upon health plan-specific companion guides to address the ambiguities in the implementation guides for each of the standards (73 FR 49746). It is possible that the reliance on companion guides has minimized some of the potential benefits offered by the standards. Based on testimony from the standards organizations and other industry representatives to NCVHS, the improvements to Version 5010 should minimize dependence on companion guides. Some of those improvements include clarifications of the standard requirements, and consistency in requirements across all of the transactions. In the August 22, 2008 proposed rule, we said that companion guides could potentially be eliminated if the updated versions of the standards were adopted.

Comment:
We received a number of comments from the industry on this subject, offering support for the elimination of companion guides because of the complexities they create in implementing the standards. Health plans were less supportive of a complete elimination of companion guides, but did, in general, comment that the use of companion guides could be reduced, and that their content could be less complex. A few commenters requested that HHS prohibit the use of companion guides. They justified this

recommendation based on the use of these guides continuing to undermine the potential of standards. A few of the clearinghouse commenters suggested that companion guides be limited to providing supplemental information and instruction, but that they could not be used to mandate the use of certain situational fields. Other commenters felt that the next version of the standard should do away with nearly all situational data elements, and only leave a bare minimum of fields eligible to be situational, thus further reducing the need for companion guides. A few of the commenters who supported the use of companion guides said that these would always be necessary because health plans would always have unique business rules, and that sometimes these rules or practices were to the advantage of the provider.

Response:
We acknowledge the issues presented by companion guides, but note that we do not have the authority to expressly prohibit the use of these guides. However, based on our review of many such documents, and the ongoing efforts of the industry to collaborate, we strongly discourage health plans from having companion guides unless they are focused significantly on the basics for connectivity, trading partner arrangements, and use of situational data elements. We encourage X12 to evaluate, and address as appropriate, industry comments specific to situational data elements, so that the minimum number of fields remain situational. This will enhance standardization and further reduce the need for companion guides. We also note that we have already published FAQs clarifying that, if companion guides contradict the implementation guides, the transaction will not be compliant. Covered entities may use the existing enforcement process to submit official complaints to HHS. Once an investigation is opened, HHS will review the companion guide at issue and a determination will be made as to its compliance with the standard(s).

Standardization of Data Content

Comment:
We received a few comments requesting that HHS support the work of some industry groups, such as the Coalition for Affordable and Quality Healthcare (CAQH), that are attempting to standardize the use of data content to maximize the benefits of transaction standards—in other words, some industry representatives are trying to build consensus on the data elements that everyone will request and provide, to make implementation more consistent throughout the industry. A few commenters said that one group has been working on standard content for the eligibility standard, so that the transaction provides more robust and useful information above and beyond what is currently a “yes/no” requirement in response to a request for information about an individual's eligibility for health plan benefits. One commenter requested that HHS support the CAQH certification process for the use of the eligibility transaction, in which organizations voluntarily agree to have their programming reviewed and approved by CAQH, and those organizations agree to use all of the same data elements as others who are participating in the certification program.

Response:
We do support the work of individuals and organizations in efforts to make the standard transactions more useful to the industry as a whole. While HHS cannot mandate participation in any certification programs, we do support any efforts towards improved compliance with the standards, as well as efforts towards maximizing the usefulness and usability of the standards. We also reiterate that we have published FAQs clarifying how a covered entity may file a complaint against another entity who it believes may not be in compliance with the implementation guides.

Definition of Compliance

Comment:
We received a few comments suggesting that we adopt a definition of the term “compliance,” using the text from the TR3 guides, which provides that compliance indicates the receiver of a standard transaction does not have to reject a transaction that is not in compliance with all of the rules within the standard. According to commenters, the TR3 guides have a definition of compliance that states a covered entity is out of compliance if it receives and accepts a transaction that is a non-standard transaction. These commenters believe this statement conflicts with an HHS FAQ which states that a receiver may not accept a non-compliant transaction. The commenter suggests that the sender of the transactions is responsible for the compliance of the transaction, and HHS should not consider the receiver to be out of compliance if it accepts a non-compliant transaction. Another commenter said that HHS should encourage an “ignore, don't reject” approach to implementation, which would mean that, if a transaction is submitted conforming to the standard, but it contains more information than is necessary for an entity to process that transaction, the additional information should be ignored by the receiver, and the transaction not rejected.

Response:
The definitions in the TR3 reports are not specific to the compliance of the transaction with the HIPAA rules, so the way “compliance” is defined by the TR3 reports does not apply to compliance under HIPAA. We believe our regulations sufficiently address the requirements for compliance. Our regulations at § 162.923 address the requirements for a covered entity to conduct a standard transaction when it conducts a HIPAA transaction using electronic media, and we define “standard transaction,” as revised in this rule, as “a transaction that complies with an applicable standard adopted under this part.” Regarding the commenter's suggestion of an “ignore, don't reject” policy, we point out that § 162.925(a)(3) provides that a health plan may not reject a standard transaction on the basis that it contains data elements not needed or used by the health plan. Finally, we do have an enforcement program through which covered entities may file complaints, and we continue to encourage the industry to utilize this program when faced with conflicts about the compliance of a transaction.

Pilots

Comment:
We received a number of comments suggesting that standards should be pilot tested before adoption. These commenters said that pilot testing the standards is needed long before a standard is proposed for adoption because such testing identifies potential pit-falls and could identify and correct unanticipated issues with a particular standard before it is officially adopted. A few commenters noted the lack of a pilot testing process and suggested that HHS, with industry input, define a pilot testing process for future standards. Another commenter recommended that pilot testing proceed in a certain sequence, beginning with internal unit testing, and followed by system testing and integration testing, and ultimately ending with trading partner testing. One commenter stated that, without workability testing, the government, X12 and the industry would be repeating implementation mistakes that were made with Version 4010/4010A. That same commenter recommended that the provisions for permitting exceptions from the requirements to comply with the standards in order to test proposed modifications (§ 162.940) be suspended until the current version of a standard was no longer in use, in other words, that some date certain would be set to “retire” or sunset a particular version of a standard. The

commenter said that such a suspension would represent cost and administrative savings to all parties because it would simplify the process of accommodating new versions of the standards. We also received a comment suggesting that HHS fund pilot testing and allow an additional twelve months for the testing before the compliance date of a final rule, implying future final rules. No commenters suggested that Version 5010 be tested prior to adoption; rather, recommendations were for the future review and adoption of new versions of the standards.

Response:
We recognize the value of pilot testing and its importance in the standards implementation process, and intend to work with the industry to define parameters for pilot testing in the future. We also encourage industry stakeholders and the standards organizations to take the lead for initiating pilot tests and monitoring the success of such tests.

Acknowledgements

Version 5010 accommodates the acknowledgement transaction, for the data receiver to communicate any errors or transmission problems back to the sender. Many health plans and clearinghouses use acknowledgement transactions, and they are free to do so using the standards they choose for that transaction. We did not propose to adopt a standard for the acknowledgement transaction in the proposed rule, so we will not adopt one here.

Comment:
We received several comments on this subject, with most commenters indicating that acknowledgements improve the process of receiving and correcting an error and resubmitting the correction back to the receiver. These commenters suggested that HHS adopt Version 5010 for the acknowledgement transaction. Commenters said that migration to standard acknowledgement transactions would offer significant business benefits by ensuring that transactions are received and front-end errors reported on a timely and consistent basis. In spite of the support for adopting an acknowledgement transaction standard, commenters also mentioned that they did not wish in any way to delay overall implementation of Version 5010 by waiting until an acknowledgement transaction standard is proposed and adopted. In other words, if the choice was to wait to adopt Version 5010 until the NCVHS advises the Secretary to also adopt Version 5010 as the standard for the acknowledgement transaction, the commenters did not want to see their suggestion go forward.

Response:
Before we would adopt an acknowledgement transaction standard, such standard would have to have been vetted through the standards adoption process that includes approval of a DSMO change request, recommendation by the DSMOs to the NCVHS, and recommendation by the NCVHS to the Secretary. Even though the chair of the X12 standards workgroup testified to the NCVHS in July 2007, and recommended adoption of an acknowledgement transaction standard for inclusion with NCVHS' recommendation for the adoption of Version 5010, NCVHS did not include an acknowledgement transaction standard in its recommendations. Nonetheless, the fact that we have not adopted an acknowledgement standard does not preclude the industry from using Version 5010 to conduct the transaction between willing trading partners. We will consider the adoption of a standard for the acknowledgement transaction at the time we receive a recommendation from NCVHS.

Real-Time Eligibility

Comment:
A few commenters stated that there was a business need for a real-time eligibility transaction standard for all participants in healthcare delivery. They stated that, without a national standard, varying approaches to real-time eligibility will be detrimental to providers and plans that do business on a national basis. The commenters identified a number of organizations such as WEDI, CAQH and Blue Cross Blue Shield of North Carolina that support real-time eligibility transactions.

Response:
Similar to a standard for the acknowledgement transaction, adopting a standard for real-time eligibility transactions would have to be vetted through the standards adoption process described above. NCVHS did not include a real-time eligibility transaction standard in its recommendations, and we are unable to adopt one at this time.

HHS Funding the Purchase of TR3 Reports

When the Transactions and Code Sets rule was published, HHS negotiated a contract with the publisher of the Version 4010/4010A implementation guide to enable the industry to download the guides at no cost. This practice ended in 2006. At that time, very few downloads or copies were being ordered, and we had no complaints about individual providers, plans or clearinghouses paying the fee. HHS did not have a similar arrangement with NCPDP, so the industry has always paid for guides for those standards.

Comment:
A few commenters suggested that HHS should pay for the industry to access copies of Version 5010. These commenters stated that small providers could not afford to buy the set of guides, which currently cost approximately $800 for the set, or $175 for each guide. Several other commenters expressed concern about the cost of the X12 TR3s and a new requirement that covered entities purchase these guides. Commenters noted that HHS underwrote the Version 4010/4010A guides on behalf of covered entities through that implementation effort and believe that it is the most beneficial way for covered entities to access and implement new versions.

Response:
It is not uncommon for standards organizations to charge a fee for copies of their standards. NCPDP charges such a fee for their standards, which HHS has never covered for the industry. We do not agree that the price for the guides will negatively impact small providers because we think it is unlikely that small providers will find them useful in implementing Version 5010. We understand that small providers usually rely on software vendors to make their systems compliant, and that it is the vendors who will require the guides for programming. We expect that, as in the past, vendors and professional associations will provide necessary education and training for the provider staff on the system changes that will require operational changes. Software vendors typically have multiple clients, and we expect that they will only need to purchase one, or at most, just a few sets of the standards to program for all of their clients. Such multiple usages should defray the modest expense.

HIPAA Enforcement

At present, most formal compliance and enforcement activities for HIPAA are complaint-driven and complaint-based. Enforcement efforts are focused on investigating complaints to determine if a covered entity is in compliance.

Comment:
We received a few comments recommending that HHS increase its enforcement efforts related to HIPAA transactions to ensure that health plans are adhering to the requirements of the X12 transactions. We received another comment suggesting stronger enforcement of the adoption of all of the standard transactions by all covered entities. One commenter said that, to date, only a subset of HIPAA-mandated transaction standards that facilitate EDI have been

implemented as required, which significantly decreases the benefits of standardization to the industry.

Response:
Our complaint-driven enforcement process has been successful in obtaining compliance on a case-by-case basis, and we encourage covered entities to utilize the process. We understand that some of the standards have not been implemented because of their limited usefulness, or because of issues with implementation. We believe that, because the standards have been significantly improved, the standards we adopt here are more useful, and therefore will result in greater industry implementation. We have the authority to conduct compliance reviews at our discretion to evaluate compliance with any of the HIPAA requirements, and have done so already with respect to the security standards. We plan to expand our compliance review program in the future to include random reviews of compliance with the transaction standards as well.

Certification

Comment:
We received several comments suggesting that HHS consider petitioning the Certification Commission for Healthcare Information Technology (CCHIT) to include Versions 5010 or D.0 in all products that would be expected to carry the upgraded standards in order to facilitate compliance with the final rule. Commenters believe this will be especially important for small covered entities in the process of purchasing software until the compliance date. They believe that, if purchasers are aware of the need to buy products that are certified to meet the incoming HIPAA requirements, conversion might be smoother and less expensive.

Response:
Generally, CCHIT does not certify products for administrative transactions, and therefore we will not pursue this suggestion. Furthermore, HHS does not recognize certification of any systems or software for purposes of HIPAA compliance.

H. Comments Considered Out of Scope

We received a number of comments on subjects that were outside the scope of the proposed rule. We do not directly respond to those types of comments because we consider them to be outside the scope of this rule, but we wish to acknowledge them. We have summarized them in the following list:

• One commenter stated the final rule should clarify the relationship between HIPAA and the Family Educational Rights and Privacy Act (FERPA). The commenter stated that there are entities that are bound by both HIPAA and FERPA, and suggested that clarification is needed for situations where there are inconsistencies between the two laws.

• One commenter stated that HHS should agree to accept and utilize all diagnosis codes associated with an admission or an encounter, not just those accommodated within the limits first set by paper forms. The current practice of truncating numbers for diagnoses and procedures so that they are equal to what a paper claim supports causes problems for providers when they are trying to meet the “Present on Admission” (POA) requirement of providing adequate information about a patient's condition.

• One commenter recommended that HHS add a definition for real-time adjudication with regard to the 837 claim, 835 remittance advice and the 277 health care claim status transactions in this final rule. The commenter referenced the collaborative efforts between WEDI and X12 to provide a standard way to conduct real-time adjudication.

• One commenter requested that we address expectations related to § 162.925 regarding health plan incentives to health care providers for using direct data entry (DDE) transactions. The commenter said there are instances where health plans offer more information about eligibility and benefit information on Web sites than they do through the standard X12 270/271 transactions, which the commenter believes is an incentive for a provider to conduct a transaction using some means other than the standard transaction. The commenter requested clarification regarding the offer of more information through a non-standard transaction than in the standard transaction, even though the standard transaction contains the required amount of information. Since we did not address this issue in the proposed rule, we do not respond here, but may provide additional direction in a future Frequently Asked Question on the CMS Web site.

III. Provisions of the Final Rule

This final rule incorporates the provisions of the proposed rule, with the following exceptions and changes: We proposed to adopt a compliance date for Versions 5010 and D.0 of April 1, 2010 for all covered entities. In this final rule, we adopt a compliance date of January 1, 2012 for Versions 5010 and D.0 for all covered entities. We revise § 162.1102, § 162.1202, § 162.1302, § 162.1402, § 162.1502, § 162.1602, § 162.1702, and § 162.1802 accordingly.

We proposed a compliance date of 24 months after the effective date of the final rule for the Medicaid pharmacy subrogation standard (Version 3.0) with an additional 12 months for small health plans. In this final rule, we indicate an effective date of January 1, 2010 for the provisions of 45 CFR Subpart S. This means that covered entities other than small health plans must be in compliance on January 1, 2012, while small health plans, which have an additional 12 months, must be in compliance on January 1, 2013.

In § 162.925, we add paragraph (a)(6) that precludes health plans from requiring an earlier compliance date than those adopted. Use of Versions 5010 and D.0 in advance of the mandatory compliance date is permissible, based upon mutual agreement by trading partners.

We adopt revisions to § 162.1102, § 162.1202, § 162.1302, § 162.1402, § 162.1502, § 162.1602, § 162.1702, and § 162.1802 to enable covered entities to engage in Level 2 testing by allowing for the use of both the old standard and the updated standard.

We allow covered entities to use either Version 4010/4010A, 5010, 5.1 or D.0 for billing retail pharmacy supplies and services, and reflect that policy in revisions to § 162.1102. We also revise the definition of “standard transaction” in accordance with our policy to allow for the dual use of standards, by replacing “the applicable standard” with “an applicable standard” at § 162.103

We proposed to clarify the descriptions for three standards: Enrollment and disenrollment, referral certification and authorization, and health care claims status and request. In the final rule we do so, by specifying the senders and receivers of those transactions in § 162.1301, § 162.1401 and § 162.1501.

In the proposed rule, at § 162.900, we stated that ASC X12N implementation specifications and the ASCX12 Standard for Electronic Data interchange Technical Report Type 3 were available from the Washington Publishing Company. In the final rule, we provide the correct address and Web site for obtaining the Version 5010 guides, from X12. Version 4010/4010A specifications may still be obtained from the Washington Publishing Company.

IV. Collection of Information Requirements

Under the Paperwork Reduction Act of 1995, we are required to provide 30-day notice in the
Federal Register
and solicit public comment before a collection of information requirement is submitted to the Office of Management and Budget (OMB) for review and

approval. In order to fairly evaluate whether an information collection should be approved by OMB, section 350(c)(2)(A) of the Paperwork Reduction Act of 1995 requires that we solicit comment on the following issues:

• The need for the information collection and its usefulness in carrying out the proper functions of our agency.

• The accuracy of our estimate of the information collection burden.

• The quality, utility, and clarity of the information to be collected.

• Recommendations to minimize the information collection burden on the affected public, including automated collection techniques.

In this rule, we are finalizing the revisions to the information collection requirements that were announced in the proposed rule that was published on August 22, 2008 (73 FR 49742). Specifically, we are revising the currently approved information collection requirements contained in § 162.1102, § 162.1202, § 162.1301, § 162.1302, § 162.1401, § 162.1402, § 162.1501, § 162.1502, § 162.1602, § 162.1702, and § 162.1802 of this document. We believe that the revisions will have an impact on the burden (both hour burden and cost burden) associated with the aforementioned affected sections that are currently approved under OCN 0938-0866 with an expiration date of 7/31/2011. In addition to announcing the revisions in the proposed rule, we published a 60-day
Federal Register
notice on October 10, 2008 (73 FR 60296) that solicited public comments on the proposed revisions. No comments were received. Accordingly, we have submitted a revised information collection request to OMB for its review and approval of the revised information collection requirements. These requirements are not effective until approved by OMB.

If you wish to comment on these information collection and recordkeeping requirements, please fax your comments to 202-395-6974 or email your comments to
oira_submission@omb.eop.gov
. Please mark comments to the attention of the desk officer for CMS and indicate that they are in relation to OMB control number 0938-0866.

V. Regulatory Impact Analysis

A. Overall Impact

We have examined the impacts of this rule as required by Executive Order 12866 (September 1993, Regulatory Planning and Review), as amended by Executive Order 13258 (February 26, 2002) and further amended by Executive Order 13422 (January 18, 2007), the Regulatory Flexibility Act (RFA) (September 19, 1980, Pub. L. 96-354), section 1102(b) of the Social Security Act, the Unfunded Mandates Reform Act of 1995 (Pub. L. 104-4), Executive Order 13132 on Federalism, and the Congressional Review Act (5 U.S.C. 804(2)).

Executive Order 12866 (as further amended) directs agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). A regulatory impact analysis (RIA) must be prepared for major rules with economically significant effects ($100 million or more in any 1 year). Because we estimate that this rule will have economically significant effects, we prepared an RIA. We anticipate that the adoption of the new versions of the standards and the adoption of Version 3.0 would result in benefits that will outweigh the costs. Accordingly, we prepared a Regulatory Impact Analysis in the August 22, 2008 proposed rule that, to the best of our ability, presented the costs and benefits of the proposals. We did not receive any comments on the Regulatory Flexibility Analysis, and therefore provide a summary here. For details, we refer readers to the August 22, 2008 proposed rule at 73 FR 49757.

B. Regulatory Flexibility Analysis

The Regulatory Flexibility Act (RFA) of 1980, Public Law 96-354, requires agencies to describe and analyze the impact of the rule on small entities unless the Secretary can certify that the regulation will not have a significant impact on a substantial number of small entities. In the health care sector, a small entity is one with between $6.5 million and $31.5 million in annual revenues or is a nonprofit organization. For the purposes of this analysis (pursuant to the RFA), nonprofit organizations are considered small entities; however, individuals and States are not included in the definition of a small entity. We attempted to estimate the number of small entities and provided a general discussion of the effects of the proposed regulation, and where we had difficulty, or were unable to find information, we solicited industry comment. We stated our belief that the conversion to Versions 5010 and D.0 would have an impact on virtually every health care entity. We did not receive any comments in response to our solicitation for comments.

In our analysis, we combined Versions 5010 and D.0 because these two standards will be implemented at the same time, and in some cases are dependent on each other. We provided examples in the August 22, 2008 proposed rule (73 FR 49758).

The summary table in this final rule includes the final cost estimates for Versions 5010, D.0 and 3.0 on all entities we anticipated would be affected by the rule. The data in that table were used in this analysis to provide cost information.

Because most health care providers are either nonprofit or meet the Small Business Administration's (SBA) size standard for small business, we treated all health care providers as small entities. For providers, we predicted that the changes would be minimal involving software upgrades for practice management and billing systems. We included pharmacies in the analysis, and considered some of them to be small businesses. We considered some health plans small businesses, but were unable to identify data for these entities, nor was any information submitted in response to our solicitation. We addressed clearinghouses and Pharmacy Benefit Managers (PBMs) in our discussion, though we did not believe that there were a significant number of clearinghouses that would be considered small entities. This was confirmed by a number of associations, including the Maryland Commission for Health Care. PBMs were excluded from the analysis because we had no data to indicate that they would qualify as a small entity. State Medicaid agencies were excluded from the analysis because States are not considered small entities in any Regulatory Flexibility Analysis.

Final Regulatory Flexibility Analysis (FRFA)

1. Number of Small Entities

In total, we estimated that there are more than 300,000 health care organizations that may be considered small entities either because of their nonprofit status or because of their revenues. The Business Census data shows that there are 4,786 firms considered as health plans and/or payers (NAICS code 5415) responsible for conducting transactions with health care providers. In the proposed rule's impact analysis, we used a smaller figure based on a report from AHIP. But for purposes of the RFA, we did not identify a subset of small plans, and instead solicited industry comment as to the percentage of plans that would be considered small entities. We identified

the top 78 clearinghouses/vendors in the Faulkner and Gray health data directory from 2000—the last year this document was produced. Health care clearinghouses provide transaction processing and translation services to both providers and health plans.

We identified nearly 60,000 pharmacies, using the National Association of Chain Drug Stores Industry Profile (2007) (
http://www.nacds.org
), and for the purposes of the initial regulatory flexibility analysis we are treating all independent pharmacies reported in the Industry Profile as “small entities.” The number of independent pharmacies reported for 2006 is approximately 17,000 entities. We specifically invited comments on the number of small pharmacies, but received none.

Based on Figure 2 of the Industry Profile, independent pharmacy prescription drug sales accounted for 17.4 percent of total pharmacy drug sales of $249 billion sales for 2006. Allocating the Versions 5010 and D.0 costs based on the share of prescription drug revenues to independent pharmacies (the small businesses), implementation costs are expected to range between $6.4 million and $13 million or 0.02 and 0.03 percent of revenues. These figures indicate that there is minimal impact, and the effect falls well below the HHS threshold of 3 to 5 percent specified in the HHS guidance on treatment of small entities (
see
: “Guidance on Proper Consideration of Small Entities in Rulemakings of the U.S. Department of Health and Human Services”
http://www.hhs.gov/execsec/smallbus.pdf.pdf
).

2. Costs for Small Entities

To determine the impact on health care providers we used Business Census data on the number of establishments for hospitals and firms for the classes of providers and revenue data reported in the Survey of Annual Services for each NAICS code. For other providers, we assumed that the costs to implement Version 5010 would be accounted for at the level of firms rather than at the individual establishments. Since we treated all health care providers as small entities for the purpose of the initial regulatory flexibility analysis, we allocated 100 percent of the implementation costs reported in the impact analysis for provider type. Table 2 shows the impact of the Version 5010 implementation costs as a percent of the provider revenues. For example, dentists, with reported 2005 revenues of $87.4 billion and costs ranging from $299 million to $598 million have the largest impact on their revenues of between 0.11 percent and 0.21 percent. We solicited comments specifically on the number of providers affected by the proposed rule, but received none.

We did not include an analysis of the impact on small health plans, because we were not able to determine the number of plans that meet the SBA size standard of $6.5 million in annual receipts.

In evaluating whether there were any clearinghouses that could be considered small entities, we consulted with three national associations (EHNAC, HIMSS and the Cooperative Exchange), as well as the Maryland Commission for Health Care, and determined that the number of clearinghouses that would be considered small entities was negligible. We identified the top 78 clearinghouses, and determined that they are typically part of large electronic health networks, such as Siemens, RxHub, Availity, GE Healthcare etc., none of which fit into the category of small entity. As referenced earlier, in a report by Faulkner and Gray in 2000, the top 51 entities were listed, and the range of monthly transactions was 2,500 to 4 million, with transaction fees of $0.25 per transaction to $2.50 per transaction. We determined that even based on these data, few of the entities would fall into the small entity category, and we did not count them in the analysis.

With respect to Version 3.0, we point out that, while we do not know how many health plans/payers will exchange the pharmacy subrogation standard with Medicaid agencies, those entities would be counted in the health plan category and addressed under the analysis for Versions 5010 and D.0. We did not provide a separate analysis in this section.

In sum, we assumed that the financial burden would be equal to or less than three percent of revenues. Based on the results of this analysis, we remain reasonably confident that the rule will not have a significant impact on a substantial number of small entities. As stated throughout this section, in spite of our request for comments on this analysis, we received none.

Table 2 below summarizes the impact of the rule on the health care industry.

Table 2—Analysis of Implementation of the Burden of Versions 5010, D.0 and 3.0 on Small Covered Entities

NAICS
Entities
Total no. of entities
Small entities
Revenue or receipts ($ millions)
% Small entity receipts of total receipts
Version 5010/D.0 annual costs (in millions)
Small entity share of version 5010/D.0 costs (in millions $)
% Implementation cost revenue-receipts (costs/receipts)

6221
General Acute Care Hospitals (establishments)
5,386
5,386
612,245
100
292-583

.05-.10

6211
Physicians (firms)
189,562
189,562
330,889
100
136-272

.04-.08

6212
Dentists (firms)
118,163
118,163
87,405
100
94-187

.11-.21

44611
Pharmacies (includes 5010 and D.0)
56,946
17,482
249,000 (42,330 @ 17%)
17.4
37-75
6.4-13
.02-.03

In column 1 we display the NAICS code for class of entity. Column 3 shows the number of entities that are reported in the Business Census for 2006 or “Chain Pharmacy Industry Profile.”

Column 4 shows the number of small entities that were computed based on the Business Census and Survey of Annual Service when the data was available. All health care providers were assumed to be small. We assumed that all independent pharmacies reported in Table 2 of the Industry profile are small entities.

Column 5 shows revenues that were reported for 2005 in the Survey of Annual Services, or in the case of pharmacies, in Figure 2 of the Industry profile. In the case of health plans and third party administrators, we used the consumer payments reported for private health insurance in 2006 in the National Health Expenditure accounts.

Column 6 shows the percent of small entity revenues.

Column 7 shows the implementation costs for Versions 5010, D.0 and 3.0

taken from Table 14a of the impact analysis and annualized.

Column 8 shows the costs allocated to the small entities based on the percent of small entity revenues to total revenues.

Column 9 presents the percent of the small entity share of implementation costs as a percent of the small entity revenues. As stated in the guidance cited earlier in this section, HHS has established a baseline threshold of 3 percen

[Text truncated at 120,000 characters. The full text is on the page linked above.]

---

Source: Frix Law Library, https://www.frixlaw.com/law-library/documents/fr%3AE9-740. Public record. Not legal advice.