The RFA also specified that pilot sites would use NCPDP SCRIPT 5.0. With the Secretary's recognition of the updated NCPDP SCRIPT 8.1, AHRQ, in its capacity as the administrator of the pilot project, gave pilot sites the option to voluntarily use NCPDP SCRIPT 8.1. Accordingly, all grantees/contractor in the pilot sites voluntarily employed the updated NCPDP SCRIPT 8.1 in their various testing modalities.
2. Grantees/Contractor and Testing Criteria
[If you choose to comment on issues in this section, please include the caption ``Grantees/Contractor and Testing Criteria'' at the beginning of your comments.]

The initial standards were tested in five healthcare/geographic settings to determine whether they were ready for broad adoption. Grantees/contractor tested whether the initial standards allowed participants to effectively communicate the necessary information between all participants in the transactions, such as the pharmacy, pharmacy benefits manager (PBM), router, plan and prescriber. They also tested how the initial standards worked with the foundation standards. Pilot sites also tracked generally anticipated eprescribing outcomes, such as a reduction in medical errors. For more information on testing parameters and criteria, go to http://www.grants.nih.gov/grants/guide/rfafiles/RFAHS06001.html.

One of the strengths of the pilot project was the diversity and uniqueness of the five grantees/contractor. Grantees/contractor represented the spectrum of communities involved with eprescribing, including most practice settings, and focused on utilization by pharmacists, physicians, nurses, and technology vendors. Applications were considered based on specific
[[Page 64904]]
characteristics/criteria. Each pilot site focused on different perspectives of the functionality and impact of initial standards by evaluating them in different sectors of the healthcare system, different geographies, and different practice settings using different technology application vendors, pharmacies and other stakeholders in the eprescribing industry. The grantees selected were Achieve Healthcare Information Technologies, L.L.P., Eden Prairie, Minnesota; Brigham and Women's Hospital, Boston, Massachusetts; RAND Corporation, Santa Monica, California; SureScripts, L.L.C., Alexandria, Virginia. The contractor that was selected was the University Hospitals Health System, Cleveland, Ohio. For more information on the pilot project criteria, refer to the Request for Application at http://www.grants.nih.gov/guide/RFAHS06001.html .
3. Pilot Test Findings
[If you choose to comment on issues in this section, please include the caption ``Pilot test findings'' at the beginning of your comments.] a. Standard for Formulary and Benefits

In the February 4, 2005 proposed rule, we discussed how the adoption of the formulary and benefit standard would enhance e prescribing capabilities under Medicare Part D by making it possible for the prescriber to obtain information on the patient's benefits, including the formulary status of drugs that the physician is considering prescribing. At that time, we proposed characteristics for a formulary and benefit standard (for a more detailed discussion refer to 70 FR 6262 through 6263). We proposed that if those characteristics for formulary were met by a standard and there was adequate industry experience with it, we would consider adopting it as a foundation standard. The NCVHS, in a September 2, 2004 letter to the Secretary (http://www.ncvhs.hhs.gov), had recommended the development of an NCPDP formulary and benefit standard, based on an RxHub protocol, to address the need for these desirable characteristics. RxHub submitted this protocol to NCPDP for approval and it was included in the October 2005 release of NCPDP Formulary and Benefit standard 1.0. However, the timing of its release in October 2005 was too late for the Formulary and Benefit standard 1.0 to be considered for approval as a foundation standard in the November 7, 2005 final rule. Also, there was little to no industry experience with the standard. Because of this and other concerns about its interoperability with other standards, at that time we did not adopt NCPDP Formulary and Benefit standard 1.0 as a foundation standard, but agreed to include it in pilot testing. For more details, refer to 70 FR 67573.

Formulary and benefits data standards must provide a uniform means for pharmacy benefit payers (including health plans and PBMs) to communicate a range of formulary and benefit information to prescribers via pointofcare (POC) systems. These include:

The NCPDP Formulary and Benefits Standard 1.0 enables the prescriber to consider this information during the prescribing process, and make the most appropriate drug choice without extensive backand forth administrative activities with the pharmacy or the health plan.

The NCPDP Formulary and Benefits Standard 1.0 was implemented live in all pilot sites, and technology vendors were certified prior to production. This standard works in tandem with the eligibility request and response (ASC X12N 270/271). Once the individual is identified, the appropriate drug benefit coverage is located and transmitted to the requestor.

The pilot sites demonstrated that the NCPDP Formulary and Benefits Standard 1.0 can be successfully implemented between prescriber and plan. The NCPDP Formulary and Benefits Standard 1.0 is quite broad, and there are a number of complex data relationships supported by the standard. This complexity creates a certain level of confusion as to how to properly use the data and leads to implementation issues. While complex, the standard can support the transaction, and is ready for implementation as part of the eprescribing program under Medicare Part D.

Formularies by their very nature are complex. They consist of hundreds of pages of drug names, dosages, etc., that frequently change due to updates in formulations, coverage decisions, etc. In addition, each drug plan has their own formulary that they use for coverage purposes. Coverage of benefits is sometimes a fluid issue; coverage can change from day to day, depending, for example, as to whether a Medicare Part D beneficiary has met outofpocket spending thresholds, or has experienced a lifechanging situation that might affect their benefit delivery for example, entering a longterm care facility). Adoption of this standard for formulary and benefits transactions between plans and providers may deliver added value in approximating patients' drug coverage and lead to patientspecific, realtime benefit information.

b. Standard for Medication History

A medication history standard provides a way for prescribers, dispensers, and payers to communicate about a listing of drugs that have been prescribed or claimed for a patient within a certain timeframe. It may provide information that would be of use in helping to identify drug interactions, including the dispensing pharmacy and the prescribing physician. This standard is relatively mature and widely adopted by the prescribing industry. It has been useful in preventing medication errors, as well as understanding medication management compliance. Results demonstrate there is a difference in how the standard is implemented based on the source of the medication history.

In the February 4, 2005 proposed rule, we discussed how the adoption of the medication history standard would enhance eprescribing capabilities under Medicare Part D by making it possible for the prescriber to obtain information on the medications the patient is already taking, including those prescribed by other providers. At that time, we proposed characteristics for a medication history standard (for a more detailed discussion refer to 70 FR 6262 through 6263). We proposed that if those characteristics for medication history were met, and there was adequate industry experience with them, we would consider adopting foundation standards. The NCVHS, in a September 2, 2004 letter to the Secretary (http://www.ncvhs.hhs.gov), had recommended the rapid development of an NCPDP medication history standard based on an RxHub protocol. The NCPDP SCRIPT standard 8.1, based on the RxHub protocol, was released in October 2005, featuring those desirable
characteristics. However, the timing of its release in October 2005 was too late for the standard to be considered for approval as a foundation standard in the November 7, 2005 final rule, and there was little to no industry experience with the standard. Because of this and other concerns about its interoperability with other standards, at that time we did not adopt the NCPDP SCRIPT standard as a foundation standard for medication history, but agreed to include it in pilot
[[Page 64905]]

testing. For more details, refer to 70 FR 67573.

The pilot sites found that the proposed medication history standard included as a transaction in the NCPDP SCRIPT 8.1 is well structured, supports the exchange of information, would not impose an undue administrative burden on prescribers and dispensers, is compatible with other health IT standards, and is ready to be used as part of the e prescribing program under Medicare Part D.

c. Standard for Structured and Codified SIG

Patient instructions for taking medications are placed at the end of a prescription. These are called the signatura, commonly abbreviated SIG. Currently, the Food and Drug Administration (FDA) provides some terminology for SIGS, for example, route of administration and unit of presentation. However, there is no standardized format or vocabulary for SIGs, leaving room for misinterpretation and error. A standard structure and code set for expressing SIGs has the potential to enhance patient safety, although free text capability must be preserved for special circumstances. Pilot sites used a variety of approaches including review of the proposed NCPDP Structured and Codified SIG standard 1.0, identification of test cases, using live transactions and selecting samples of prescriptions with a wide variety of SIGs, recreating each test case in a laboratory environment, and then developing a test harness that would include functions of an electronic information exchange application. Another approach was to analyze an initial sample that would be statistically valid with an attempt to represent each distinct SIG using the proposed standard's 128 data fields.

The pilot sites found that the proposed Structured and Codified SIG format needs additional work with reference to field definitions and examples, field naming conventions and clarifications of field use. It is imperative that the prescriber's instructions be translated exactly into eprescribing and pharmacy practice management systems to reduce medication errors, decrease healthcare costs and improve patient safety. Contradictions with other structured fields exist, and there are limitations on directions for topical drugs (such as the area of application). The pro re nata (PRN) or ``as needed'' designation could be interpreted as either ``as needed'' or ``as required'', and the standard does not allow for quick revisions for new drug
administration. Mistranslations and contradictions in dosage/timing directions leave room for misinterpretation and error. Analysis shows that the NCPDP's proposed Structured and Codified SIG Standard 1.0 is not sufficiently developed for use for Medicare Part D eprescribing in its current state.

d. Standard for Fill Status Notification

The Fill Status Notification standard is a function within the NCPDP SCRIPT 8.1, but it was not named a foundation standard due to lack of adequate industry experience. The standard enables a pharmacy to notify a prescriber when the prescription has been dispensed (medication picked up by patient), partially dispensed (partial amount of medication picked up by the patient), or not dispensed (medication not picked up by patient, resulting in the medication being returned to stock).

Pilot sites found that the NCPDP SCRIPT 8.1 standard supports the activities of a pharmacy sending messages to the prescriber as to the status of a prescription. The challenges encountered were not related to the structure and format of the standard, but in its implementation. RxFill is intended to encourage adherence and compliance with medication therapy. Although the transaction is technically capable of performing that function, the pilot sites' experiences and observations indicate there is no marketplace demand for this information, and may cause an unnecessary administrative burden on prescribers and dispensers. Prescribers expressed concerns about being inundated with data if they were informed every time a prescription was filled or not filled, and were unsure of the usefulness of the information. Moreover, implementing the Fill Status transaction would require significant business process changes at pharmacies as well as development of common rules for determining when a prescription becomes a ``nofill.'' We question the marketplace demand for Fill Status Notification and solicit comments regarding both stakeholders' and industry's potential utilization of RxFill.

e. Standard for Clinical Drug Terminology: RxNorm

RxNorm is a vocabulary resulting from a collaboration between the Food and Drug Administration (FDA) and the National Library of Medicine (NLM) that provides standard names for clinical drugs (active ingredient + strength + dose form), and for dose forms as administered to a patient. These concepts are relevant to how a physician would order a drug. It provides links from clinical drugs, both branded and generic, to their active ingredients, drug components (active ingredient + strength), and related brand names. NDCs (National Drug Codes) for specific drug products (where there are often many NDC codes for a single product) are linked to that product in RxNorm. NDCs for specific drug products identify not only the drug but also the manufacturer and the size of the package from which it is dispensed. NDCs are relevant to how a pharmacy would dispense the drug. RxNorm links its names to many of the drug vocabularies commonly used in pharmacy management and drug interaction software. By providing links between these vocabularies, RxNorm can mediate messages between systems not using the same software and vocabulary.

RxNorm terminology was evaluated in the context of the NCPDP SCRIPT 8.1 for new prescriptions, renewals, and changes. RxNorm was included in the pilot to determine how well the RxNorm information can be translated from the prescriber's system to the dispenser's system while maintaining the prescriber's intent. The grantees/contractor tested this standard in a laboratory setting, specifically to gain understanding of the completeness and accuracy of RxNorm.

The pilot sites demonstrated that RxNorm has significant potential to simplify eprescribing, create efficiencies, and reduce dependence on NDCs among dispensers. It was able to represent both new prescriptions and renewal requests. In some testing, RxNorm erroneously linked some NDCs to lists of ingredients rather than to the drugs themselves. Testing also revealed cases in which the NDC codes linked by RxNorm did not match to a semantic clinical drug (SCD), which always contains the ingredient(s), strength and dose form, in that order. This indicates there was either an error in matching to the correct RxNorm concept, or an error with RxNorm itself, with more than one term being available for the same clinical drug concept (that is, unresolved synonymy). There is currently no central repository containing a list of all NDC codes, nor a reference guide that indicates all of the NDCs associated with a particular drug. (On August 29, 2006, FDA published a proposed rule [71 FR 51276] which would result in the creation of an electronic drug registration and listing system for which FDA would issue all NDCs, registrants would be required to keep information up to date, and there would be a centralized electronic repository for these NDCs. Through the Structured Product Labeling (SPL) for
[[Page 64906]]
each marketed drug product, the NDCs would be linked to the drug product code, proprietary name, established name of the active ingredients, Unique Ingredient Identifiers [UNII], active ingredient strengths and pharmaceutical dosage form.) As with other vocabulary standards, RxNorm will never cover 100 percent of what is needed in every circumstance, so some provisions for exceptions will be needed. One example encountered in the pilots was the lack of standard names and identifiers for pharmacycompounded drugs. Analysis shows that, as of December 2006, RxNorm was not sufficiently developed for effective and accurate use for Medicare Part D eprescribing.

f. Standard for Prior Authorization

The prior authorization standard incorporates realtime prior authorization functionality in the ASC X12N 278 Version 4010A1 Health Care Services Review transaction. Originally there were two models that were to be considered, solicited (prescriber proactively solicits prior authorization criteria/forms from plan) and unsolicited (questions appear via prompts on a pointofcare software system). The solicited model is rarely used and usually results in a paperbased response, versus the unsolicited model which employs eprescribing technology. Upon consultation between the pilot sites and AHRQ as the administrator of the pilot project, AHRQ advised that the pilot sites use the unsolicited model using the NCPDP Formulary and Benefits Standard 1.0 specification as it would provide a better test of prior authorization in an eprescribing environment.

Prior authorization is a very complex standard to implement, necessitating an understanding of four different standards and multiple payer requirements. The combination of ASC X12N 278, ASC X12N 275 and the HL7 prior authorization (PA) attachment is cumbersome, confusing and requires expertise that may limit adoption. Because health plans typically require prior authorization only for a small subset of drugs, the pilot sites had limited live experience with this standard. Nevertheless, they pilot tested the ASC X12N 278 version 4010A1 and ASC X12N 275 version 4010 with the HL7 PA attachment and identified several issues that need to be addressed before this standard should be adopted as an eprescribing final standard, including some inconsistencies between ASC X12N 278 Version 4010A1 and ASC X12N 275 Version 4010 that need to be addressed. Investigators agreed that the HIPAAnamed prior authorization standardthe ASC X12N 278 version 4010A1was not adequate to support prior authorization because it was designed for service or procedure prior authorizations, not for medication prior authorization. One of the challenges of the ASC X12N 275 version 4010 with the HL7 PA attachment is that it did not allow vendors to make questions mandatory, which would ensure that the information required is complete and reduce the need for backandforth communication that takes place between plan prior authorization representatives and prescribers. Standards modifications would need to be made prior to adoption as a final standard for the Medicare Part D eprescribing program.

g. Use of Standards in the LongTerm Care (LTC) Setting

Healthcare Delivery in longterm care (LTC) settings is unique for several reasons. Nurses are frequently the primary caregivers, with offsite physicians who monitor care; specialized longterm care pharmacies are located offsite with drugs being delivered to the facility. While the participants in the Achieve study were drawn from a convenience sample, the setting provided a special opportunity for understanding eprescribing's impact on an entirely different patient population, provider type, and prescription delivery system.

In longterm care, a prescription order typically remains an open order with no end date or a date far in the future. A prescriber may need to modify this order and notify the pharmacy. Changes might include dose, form, strength, route, modifications of frequency, or a minor change related to the order. Also, in the longterm care environment, there is a need to send a refill request from a facility to a pharmacy. An example is when a medication supply for a resident is running low (23 doses remaining), and a new supply is needed from the pharmacy. The facility needs a way to notify the pharmacy that a refill for the medication is needed. Eprescribing was evaluated within the unique context of longterm care workflow from facility to pharmacy.

The primary purpose of the longterm care pilot site was to test the NCPDP SCRIPT 8.1 in the longterm care setting and found that modifications were required in order to ensure accurate transmission of the data. Through partner agreement, ``workarounds'' were identified and implemented. These workaround requests were formally submitted by the pilot site grantee to NCPDP in the form of a DERF (Data Element Request Form) to modify the standard as needed. When an updated version of the NCPDP SCRIPT Standard becomes available that can accommodate the unique prescription workflow of the LTC setting, we will consider removing the current exemption. We solicit industry and other interested stakeholder comments on the impact and timing of lifting this exemption.
II. Provisions of the Proposed Rule
A. Proposed Retirement of NCPDP SCRIPT 5.0 and Adoption of NCPDP SCRIPT 8.1 as a Final Standard
[If you choose to comment on issues in this section, please include the caption ``Adoption of NCPDP SCRIPT 8.1'' at the beginning of your comments.]

We propose to revise Sec. 423.160(b)(1) to replace the NCPDP SCRIPT 5.0 standard with the NCPDP SCRIPT 8.1. Those providers and dispensers using eprescribing to provide for the electronic communication of a prescription or prescriptionrelated information would be required to use the NCPDP SCRIPT 8.1 for the following transactions:

On June 23, 2006, we published an interim final rule with comment (71 FR 30620) to solicit comments as to whether the NCPDP SCRIPT 8.1 was a backward compatible update to NCPDP SCRIPT 5.0. We received 5 timely public comments on this interim rule with comment. The comments came from a standards setting organization, two national industry associations, and two private corporations actively involved in e prescribing. All commenters supported the voluntary use of the backward compatible Version 8.1 of the NCPDP SCRIPT Standard. Four recommended that it be adopted as soon as reasonably possible, and that Version 5.0 be retired as soon as reasonably practical. They also indicated that Version 8.1 was already in widespread use throughout their
[[Page 64907]]
respective industries. One commenter indicated a concern with making backward compatibility ``the criteria'' for determining if a notice and comment rulemaking is required. That commenter felt that backward compatibility must be viewed as just one factor in making a determination to update, as opposed to modify, a standard.

We continue to find that the NCPDP SCRIPT 8.1 is backward compatible to the adopted NCPDP SCRIPT 5.0. Both versions are the same, except that Version 8.1 contains the additional feature of medication history. One commenter expressed that it has been their experience that, while capable of processing Version 5.0, the industry is already implementing Version 8.1, and that few, if any, of their trading partners are using Version 5.0. This is supported by industry reports that numerous software systems now using Version 8.1 have been certified for use by electronic prescribing networks.

Regarding the comment that backward compatibility should not be the sole criterion for determining whether use of a subsequent version requires an update or a modification of an eprescribing standard, we note that it is not the sole criterion. The ``backward compatibility'' of a subsequent version of an adopted standard simply indicates that entities may voluntarily upgrade their systems with the subsequent version that is ``backward compatible,'' and still be compliant with the adopted standard. With the backward compatible version, entities may conduct transactions with other entities that continue to use the adopted version of the standard with no deleterious effect on the transmission of information or the transaction itself. We also note that we are required by law to employ notice and comment rulemaking to modify an adopted standard or when entities would be required to transition to a subsequent version. Through the rulemaking process, we must notify the public as to the proposed modifications, receive public comment on our proposals, and take into consideration an analysis of factors such as the modification's impact on affected entities relative to cost, benefit projections, productivity, etc., as well as industry and stakeholder feedback provided by means of the written comment process. We are soliciting comments regarding the retirement of Version 5.0 and the adoption of Version 8.1 as the adopted standard for the e prescribing functions outlined in 42 CFR 423.160(b)(1), and based on the proposed compliance date described in section II.E. of this proposed rule.
B. Proposed Adoption of an EPrescribing Standard for Medication History Transaction
[If you choose to comment on issues in this section, please include the caption ``Medication History'' at the beginning of your comments.]

In the Foundation Standards final rule, 70 FR 67568, we discussed the need for medication history standards, and that we were unaware of any standard for these transactions that clearly met the criteria for adequate industry experience. As a result, a standard for medication history was tested in the 2006 pilot project.

The NCVHS noted in its September 2, 2004 letter to the Secretary that medication history information was communicated between payers and prescribers using proprietary messaging standards, frequently the Information File Transfer protocols established by RxHub, a national formulary and benefits information exchange. The NCVHS recommended that HHS actively participate in and support the rapid development of an NCPDP standard for formulary and medication history using the RxHub protocol as a basis. In September 2005, RxHub announced that its propriety data transaction format for Medication History which they had submitted to NCPDP, had been approved and incorporated into the NCPDP Script Standard, and approved by the American National Standard Institute (ANSI). NCVHS considered ANSI accreditation to be one criterion in their recommendation process for adoption of eprescribing standards, and HHS adopted this as a criterion for determining adequate industry experience. (See 70 FR 67568, 67577 for a discussion of all the criterion considered by NCVHS.) The resulting NCPDP SCRIPT standard was recognized by the Secretary as an initial standard, then pilot tested in accordance with the MMA.

The pilot sites demonstrated that the standard can be successfully implemented among a variety of eprescribing partners and, while complex, the standard can support the Medication History transaction, and is ready for implementation under Medicare Part D.

If NCPDP SCRIPT 8.1 is adopted in place of NCPDP SCRIPT 5.0 at Sec. 423.160(b)(1) as proposed above, we also propose to add Sec. 423.160(b)(3) to adopt the NCPDP SCRIPT 8.1 for electronic medication history transactions among the plan sponsor, prescriber, and the dispenser when eprescribing for covered Medicare Part D drugs for Medicare Part D eligible individuals. The medication history transaction in the NCPDP SCRIPT 8.1 standard is based on the proprietary file transfer protocol developed by RxHub, which is currently being used to communicate this information in many e prescribing products.

Adoption of the NCPDP SCRIPT 8.1 standard for the medication history transaction will provide a uniform communications mechanism for prescribers, dispensers and payers, support reconciliation of useful data from a large number of sources, and raise awareness of its availability and use among providers. Cost savings to the public will be generated based on reductions in the number of preventable adverse drug events (ADEs). Significantly, systems that utilize this proposed transaction in the NCPDP SCRIPT 8.1 standard will be substantially more effective at ADE reduction than those merely utilizing the original foundation standards by allowing prescribers to see what medications have been prescribed by other providers in the past.
C. Proposed Adoption of an Eprescribing Standard for Formulary and Benefit Transactions
[If you choose to comment on issues in this section, please include the caption ``formulary and benefit transactions'' at the beginning of your comments.]

As a result of pilot testing, we are proposing to add Sec. 423.160(b)(4) to adopt the NCPDP Formulary and Benefit Standard 1.0, for the transaction of communicating formulary and benefit information between the prescriber and the plan sponsor when eprescribing for covered Medicare Part D drugs for Medicare Part D eligible individuals. This standard is based on a proprietary file transfer protocol developed by RxHub, which is currently being used to communicate this information in many eprescribing products. The RxHub protocols were submitted to NCPDP for accreditation, and the resulting standard was recognized by the Secretary as an initial standard and pilottested in accordance with the MMA.

The NCPDP Formulary and Benefits Standard 1.0 was implemented live in all pilot sites. This standard works in tandem with the eligibility request and response (ASC X12N 270/271). Once the individual is identified, the appropriate drug benefit coverage is located and transmitted to the requestor.

The pilot sites demonstrated that the NCPDP Formulary and Benefits Standard 1.0 can be successfully
[[Page 64908]]
implemented among a variety of eprescribing partners, and while complex, the standard can support the transaction, and is ready for implementation under Medicare Part D.

Adoption of this standard for formulary and benefits transactions between plan sponsors and prescribers may deliver added value in approximating patients' drug coverage and lead to patientspecific, realtime benefit information. The NCPDP Formulary and Benefits Standard 1.0 enables the prescriber to consider this information during the prescribing process, and make the most appropriate drug choice without extensive backandforth administrative activities with the pharmacy or the plan sponsors. As prescribers prescribe based on the coverage offered by a patient's plan formulary, plans will experience reduced costs through paying for drugs that are specific to their formularies for which they have negotiated favorable rates. Patients will see reduced costs in not having to pay increased outofpocket expenses for prescribed drugs that are not on their plan's formularies. D. Adoption of the National Provider Identifier (NPI) as a Standard for Use in EPrescribing Transactions
[If you choose to comment on issues in this section, please include the caption ``Adoption of the National Provider Identifier'' at the beginning of your comments.]

We are proposing to add Sec. 423.160(b)(5) to adopt the National Provider Identifier as a standard for use in eprescribing transactions among the plan sponsor, prescriber, and the dispenser. The NCPDP SCRIPT standard 8.1, which we are proposing for adopting in this proposed rule, supports the use of NPI.

While the NPI was not tested in the pilot project, we have reason to believe that there is adequate industry experience with the NPI which would support its use in eprescribing transactions under section 1860D4(e)(4)(C)(ii). Use of the NPI is already required in order to conduct HIPAAcompliant transactions which require the identity of HIPAA covered health care providers; and the compliance date for the NPI, May 27, 2007, has already passed. The NPI is in widespread use by HIPAA covered entities in HIPAA transactions. Although the NCPDP SCRIPT transaction is not a HIPAA transaction, the prescribers and dispensers that conduct it would be HIPAA covered entities, and as such, they would already be using NPI as they conduct their HIPAA transactions. They would, therefore, already be familiar with the NPI, even though they may not currently use it in the NCPDP SCRIPT transaction. Furthermore, NPI meets the objectives and design criteria laid out at section 1860D4(e)(3) of the Act, so adoption of the NPI for use in e prescribing standards is supported by section 1860D4(e)(3)(A) of the Act as well. Finally, as uniform identifiers are necessary to conduct electronic transactions such as those in the eprescribing program, adoption of NPI is also supported by section 1102 of the Act.

We generally solicit comments from the industry and other stakeholders on the adoption of NPI as an eprescribing standard, and we specifically request comments as to whether use of the NPI in HIPAA compliant transactions constitutes adequate industry experience for purposes of using NPI as a covered health care provider identifier in Medicare Part D eprescribing transactions.

E. Proposed Compliance Date

In accordance with section 1860D4(e) of the Act, the Secretary must issue certain final uniform standards for eprescribing no later than April 1, 2008, to become effective not later than 1 year after the date of their promulgation. Therefore, in accordance with this requirement, the Secretary proposes a compliance date of 1 year after the publication of the final uniform standards. The Secretary also proposes adopting NCPDP SCRIPT 8.1 as the eprescribing standard for the transactions listed in section III. C. of this proposed rule, effective 1 year after the publication of the final uniform standards. We solicit comments regarding the impact of these proposed dates on industry and other interested stakeholders and whether an earlier compliance date should be adopted.

III. Collection of Information Requirements

Under the Paperwork Reduction Act of 1995 (PRA), agencies are required to provide a 30day notice in the Federal Register and solicit public comment before a collection of information requirement is submitted to the Office of Management and Budget (OMB) for review and approval. In order to fairly evaluate whether an information collection should be approved by OMB, section 3506(c)(2)(A) of the PRA requires that we solicit comment on the following issues:

We are soliciting public comment on each of these issues for the following sections of this document that contain information collection requirements.
Standards for an Electronic Prescribing Program (Sec. 423.160)

The emerging and increasing use of health care electronic data interchange (EDI) standards and transactions have raised the issue of the applicability of the PRA. It has been determined that a regulatory requirement mandating the use of a particular EDI standard constitutes an agencysponsored thirdparty disclosure as defined under the PRA.

As a thirdparty disclosure requirement subject to the PRA, Medicare Part D sponsors offering qualified prescription drug coverage must support and comply with electronic prescription standards relating to covered Medicare Part D drugs, for Medicare Part D enrolled individuals as would be required under Sec. 423.160.

However, the requirement that Medicare Part D sponsors support electronic prescription drug programs in accordance with standards set forth in this section, as established by the Secretary, does not require that prescriptions be written or transmitted electronically by prescribers or dispensers. After the promulgation of this set of final standards, these entities will be required to comply with the proposed standards only if they transmit prescription information electronically as discussed in section 1860D4(e)(1) and (2) of the Act.

Testimony presented to the NCVHS indicates that most health plans/ PBMs currently have eprescribing capability either directly or by contracting with another entity. Therefore, we do not believe that conducting an electronic prescription drug program would be an additional burden for those plans. We solicit industry and other interested stakeholder comments and input on this issue.

Since these standards are already familiar to industry, we believe the requirement to adopt them constitutes a usual and customary business practice and the burden associated with the requirements is exempt from the PRA as stipulated under 5 CFR 1320.3(b)(2). [[Page 64909]]

As required by section 3504(h) of the Paperwork Reduction Act of 1995, we have submitted a copy of this document to OMB for its review of these information collection requirements.

If you comment on any of these information collection requirements, please mail copies directly to the following: Centers for Medicare & Medicaid Services, Office of Strategic Operations and Regulatory Affairs, Regulations Development and Issuances Group, Attn: William Parham, III, CMS0016P, Room C51403, 7500 Security Boulevard, Baltimore, MD 212441850; and Office of Information and Regulatory Affairs, Office of Management and Budget, Room 10235, New Executive Office Building, Washington, DC 20503. Attn: Carolyn Lovett, CMS Desk Officer, CMS0016P, Carolyn_lovett@omb.eop.gov. Fax: (202) 3956974. IV. Response to Comments

Because of the large number of public comments we normally receive on Federal Register documents, we are not able to acknowledge or respond to them individually. We will consider all comments we receive by the date and time specified in the DATES section of this preamble, and, when we proceed with a final rule, we will respond to the comments in the preamble to that document.
V. Regulatory Impact Analysis
[If you choose to comment on issues in this section, please include the caption ``Regulatory Impact Analysis'' at the beginning of your comments.]

We have examined the impacts of this rule as required by Executive Order 12866 of September 30, 1993, as further amended; the Regulatory Flexibility Act (RFA) (September 16, 1980, Pub. L. 96354); section 1102(b) of the Social Security Act; section 202 of the Unfunded Mandates Reform Act of 1995 (March 22, 1995, Pub. L. 1044); and Executive Order 13132 of August 4, 1999.

Executive Order 12866 (as amended by Executive Order 13258, which merely reassigns responsibility of duties, and further amended by Executive Order 13422) directs agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). According to Executive Order 12866, a regulatory action may reasonably be ``significant'' if it meets any one of a number of specified conditions, including if the action may reasonably be anticipated to lead to:

FOR FURTHER INFORMATION CONTACT Denise M. Buenning, (410) 786-6711.