Federal Register: January 16, 2009 (Volume 74, Number 11)

DOCID: fr16ja09-33 FR Doc E9-740

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Western Area Power Administration

CFR Citation: 45 CFR Part 162

RIN ID: RIN 0938-AM50

CMS ID: [CMS-0009-F]

NOTICE: Part VI

DOCID: fr16ja09-33

DOCUMENT ACTION: Final rule.

SUBJECT CATEGORY:

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

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 Sec. Sec. 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 Sec. 162.1902 is required on January 1, 2013.

DOCUMENT 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.

SUMMARY:

Health and Human Services Department,

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 1HIPAA 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 BenefitsRetail pharmacy drug. ASC X12 837 D.................................. Coordination of BenefitsDental. ASC X12 837 P.................................. Coordination of BenefitsProfessional .
ASC X12 837 I.................................. Coordination of BenefitsInstitutiona l.
ASC X12 270/271................................ Eligibility for a health plan (request and response)dental, professional and institutional. [[Page 3297]]
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 Sec. 162.1102, Sec. 162.1202, Sec. 162.1302, Sec. 162.1402, Sec. 162.1502, Sec. 162.1602, Sec. 162.1702, and Sec. 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 abovereferenced provisions can be found in the August 22, 2008 proposed rule (73 FR 4974549750).

We proposed to revise Sec. 162.1102, Sec. 162.1202, Sec. 162.1302, and Sec. 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 abovereferenced 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 Sec. 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 Sec. 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 4975149752).

We proposed to revise Sec. 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 4975249754).

We proposed to revise the descriptions of the transactions at Sec. 162.1301, Sec. 162.1401, and Sec. 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 Sec. 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 Sec. 162.1102, Sec. 162.1202, Sec. 162.1302, Sec. 162.1402, Sec. 162.1502, Sec. 162.1602, Sec. 162.1702, and Sec. 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 industrywide difficulties to such a degree that much of the industry rely on ``companion guides'' and proprietary ``workarounds.'' The four types of changes in Version 5010 are structural, front matter, technical improvements
[[Page 3298]]
and data content changes. The complete discussion of this proposal can be found in the August 22, 2008 proposed rule (73 FR 4974549749).

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 ICD10CM diagnosis codes and ICD10PCS 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 resubmit 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 ICD10. In the August 22, 2008 proposed rule, we said that Version 4010/4010A does not provide a means for identifying ICD10 procedure or diagnosis codes on an institutional claim, and that Version 5010 anticipates the eventual use of ICD10 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 ICD10 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
[[Page 3299]]
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 Sec. 162.1102, Sec. 162.1202, Sec. 162.1302, and Sec. 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
[[Page 3300]]
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 standardschanging business needsmany 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 Sec. 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 Sec. 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 4975149752).

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 Sec. 162.1902, for the Medicaid pharmacy subrogation transaction, as described at Sec. 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 nonpharmacy claims, we cannot adopt it in this final rule. HHS will consider whether to adopt the X12 standard for nonpharmacy 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 nonpharmacy related claims in this rule, those standards are available for use. Covered entities are not prohibited from using Version 5010 for nonpharmacy 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 costeffective 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 rebill 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 Sec. 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 4975249754).

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
[[Page 3301]]
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 casebycase 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 Sec. 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 Sec. 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 Sec. 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 Sec. 162.1301, Sec. 162.1401, and Sec. 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 realtime 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 nonpharmacy claims.

Response: We are not making a change in our regulation text because we do not think it is appropriate. In Sec. 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 Sec. 162.1402 clearly identifies the standard that is adopted for the function described in Sec. 162.1401.

Comment: We received a comment requesting a technical clarification to the enrollment and disenrollment in a health plan transaction (Sec. 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 selffunded 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 Sec. 162.1501 the following: For the purpose of enrollment and disenrollment in their health plan, the term sponsor shall include selffunded 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 noncovered 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
[[Page 3302]]
efficiently coordinated, requiring less time than the original standards for implementation. We also discussed at length an alternative we considered, but did not proposea staggered compliance timeframe for Versions 5010 and D.0 (72 FR 4975449757). 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.0January 1, 2012.
  • Version 3.0 for all covered entities except small health plansJanuary 1, 2012.
  • Version 3.0 for small health plansJanuary 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 thirtysix 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 redesign technical and business infrastructure activities to accommodate Versions 5010 and D.0 will also be needed to do similar work to implement ICD10. In fact, some commenters suggested that the impact of ICD10 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 indepth 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 36month

    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 endtoend 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 endtoend testing with each of its trading [[Page 3303]]
    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 modeVersion 4010/4010A and/or Version 5010, as well as Version 5.1 and/or Version D.0as 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 phasedin 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 ICD10 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 Sec. 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 Sec. 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 Sec. 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 4975449755).

    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 twoyear 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 Sec. 162.923(a).

    Response: We are adopting the revision to Sec. 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 ICD10 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 ICD10

    Version 5010/D.0 and Version 3.0 ICD10 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 01/11: Begin initial compliance activities (external testing with activities (gap analysis, trading partners and move into design, development, internal production; dual processing mode) for testing).
    Versions 5010 and D.0.
    [[Page 3304]]
    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 ICD10). * 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 4975449757). 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 wellversed 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 36month 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 unevenmany entities do not use the claims status transactions because they have online 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