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 athttp://www.cms.hhs.gov,in the Regulations and Guidance section, as well as on the X12 portal athttp://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 qualifieror 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 SS 162.1102, SS 162.1202, SS 162.1302, and SS 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 orequivalent 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 SS 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 SS 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 SS 162.1902, for the Medicaid pharmacy subrogation transaction, as described at SS 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 SS 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), vaccineadministration), 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 SS 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 SS 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 SS 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 SS 162.1301, SS 162.1401, and SS 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 SS 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 SS 162.1402 clearly identifies the standard that is adopted for the function described in SS 162.1401.
Comment:We received a comment requesting a technical clarification to the enrollment and disenrollment in a health plan transaction (SS 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 SS 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 beefficiently 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 tradingpartners, 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 theFederal Registeron 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 SS 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 SS 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 SS 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 SS 162.923(a).
Response:We are adopting the revision to SS 162.923(a), as proposed in the August 22, 2008 proposed rule.
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
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