Medicare Program; Hospital Inpatient Prospective Payment Systems for Acute Care Hospitals (IPPS) and the Long-Term Care Hospital Prospective Payment System and Policy Changes and Fiscal Year (FY) 2026 Rates; Changes to the FY 2025 IPPS Rates Due to Court Decision; Requirements for Quality Programs; and Other Policy Changes; Health Data, Technology, and Interoperability: Electronic Prescribing, Real-Time Prescription Benefit and Electronic Prior Authorization exibility to determine how they can best meet the needs of their patient population. TEAM participants are permitted to collect additional information on their patients in the model, while remaining compliant with relevant laws and regulations, in order to improve quality of care and reduce Medicare spending. We anticipate that TEAM participants may work toward independently identifying and producing their own data, through electronic health records, health information exchanges, or other means Extremism and Restoring Biological Truth to the Federal Government: https://www.whitehouse.gov/ presidential-actions/2025/01/defending-women- from-gender-ideology-extremism-and-restoring- biological-truth-to-the-federal-government/./. that they believe are necessary to best evaluate the health needs of their patients, improve health outcomes, and produce efficiencies in the provision and use of services. Therefore, we support TEAM participants collecting additional information for their own use that could be beneficial to the health and wellbeing of their patients. We believe that removing health equity plans from the model does not prevent TEAM participants from collecting data that could g that could be beneficial to the health and wellbeing of their patients. We believe that removing health equity plans from the model does not prevent TEAM participants from collecting data that could give greater context to the care of patients. CMS is focused on reducing or not inflicting additional levels of administrative burden on TEAM participants. While we recognize health equity plans were voluntary, we believe removing health equity plans from TEAM will allow TEAM participants to direct their resources and attention to model requirements and achieving the goals of the model. We also believe removing health equity plans from TEAM will allow TEAM participants to make their own decisions on what data is the most useful to collect to provide the best care to patients. Comment: A commenter noted voluntary submission of health equity plans would help CMS and participants identify where potential care and health disparities exist, tailor care redesign efforts to patient needs, and develop interventions that reduce avoidable complications and readmissions. Response: We appreciate and sympathize with this commenter’s concerns over avoidable complications and readmissions, as this is lop interventions that reduce avoidable complications and readmissions. Response: We appreciate and sympathize with this commenter’s concerns over avoidable complications and readmissions, as this is a major part of what TEAM is trying to reduce. If TEAM participants believe that collecting health equity data will help in this endeavor, they are free to do so, but TEAM participants will not incur the burden of submitting this data to CMS (as they may under the current voluntary policy), nor will CMS accept receipt of this data. Comment: Some commenters supported CMS’s decision to keep reporting requirements around patient demographic data, but remove specific portions relating to Social Determinants of Health (SDOH) Response: We thank these commenters for their support. Comment: Other commenters questioned why CMS should remove SDOH data from reporting requirements. These commenters noted that voluntary submission of SDOH data would help CMS and TEAM participants identify where disparities exist, tailor care redesign efforts to patient needs, and develop interventions that reduce avoidable complications and readmissions. These commenters stressed that collecting this data is not a ties exist, tailor care redesign efforts to patient needs, and develop interventions that reduce avoidable complications and readmissions. These commenters stressed that collecting this data is not a burden to them but is considered an investment in using efficiently and effectively. They also believe this data collection aligns with the long-term goals of value-based care which leads to improving patient outcomes while reducing cost and raising quality of care. Response: We appreciate these commenters concerns and their commitment to CMS’s goals of improving quality while also reducing the cost of care for Medicare beneficiaries. We believe it is important to give TEAM participants more autonomy and flexibility to accomplish these goals. With this in mind, removing the SDOH reporting requirements from TEAM gives TEAM participants the flexibility to identify and focus on the non-medical needs for their specific patient population and cater their care redesign interventions to meet the needs of their patients. If TEAM participants believe collecting SDOH data will reduce costs and improve the quality of care, then TEAM participants are free to continue these data collection practice needs of their patients. If TEAM participants believe collecting SDOH data will reduce costs and improve the quality of care, then TEAM participants are free to continue these data collection practices, but they will not need to report this data to CMS. However, if it is not clear to TEAM participants if this specific data collection will reduce costs or improve quality of care, there will no longer be any mechanisms in place for them to report such data to CMS. After consideration of public comments, we are finalizing our proposal to remove Health Equity Plans from TEAM and remove the corresponding regulations at § 512.505 and § 512.563. We are also finalizing our proposal to remove voluntary reporting of the Screening for Social Drivers of Health measure and the Screen Positive Rate for Social Drivers of Health measure from TEAM and remove the corresponding regulations at § 512.563(b). Lastly, we are finalizing our proposal to rename the ‘‘gender’’ variable to ‘‘sex’’ at § 512.562(c)(3). e. Referral to Primary Care Services In the FY 2025 IPPS/LTCH PPS final rule (89 FR 69850) we finalized the referral to primary care services requirement. To comply with this requirement, TEAM pa (3). e. Referral to Primary Care Services In the FY 2025 IPPS/LTCH PPS final rule (89 FR 69850) we finalized the referral to primary care services requirement. To comply with this requirement, TEAM participants must (1) include in hospital discharge planning a referral to a supplier of primary care services for a TEAM beneficiary, on or prior to discharge from an anchor hospitalization or anchor procedure and (2) follow beneficiary freedom of choice requirements, as indicated in § 512.582(a). We stated in the proposed rule that since a TEAM episode only lasts 30 days after the TEAM beneficiary is discharged from the hospital, the goal VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00589 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37124 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations of this policy is to integrate care during the transition from an acute event—an episode—back to longitudinal care relationships, such as primary care. We noted in the proposed rule that we continue to believe there is value in maintaining this requirement in TEAM so that the TEAM bene de—back to longitudinal care relationships, such as primary care. We noted in the proposed rule that we continue to believe there is value in maintaining this requirement in TEAM so that the TEAM beneficiary has continuity of care after the episode ends. Therefore, we did not propose a change to the current policy. However, we were aware that the current policy does not take into consideration the TEAM beneficiary’s relationship with existing suppliers of primary care services. In other words, the TEAM participant may refer the TEAM beneficiary to a supplier of primary care services that is different from the supplier of primary care services that the TEAM beneficiary has an established relationship with, as documented through previous encounters via claims data, as long as it complies with beneficiary freedom of choice requirements. As such, we stated in the proposed rule that the TEAM participant may be incentivized to refer to their own suppliers of primary care services with whom they have a contractual relationship, even when complying with beneficiary freedom of choice requirements. While we anticipate most TEAM participants would refer TEAM beneficiaries back to suppliers wi hey have a contractual relationship, even when complying with beneficiary freedom of choice requirements. While we anticipate most TEAM participants would refer TEAM beneficiaries back to suppliers with whom they have an existing relationship with, we sought comment on whether not specifically requiring that beneficiaries be referred back to suppliers with whom they have an existing relationship could disrupt fair competition as well as limit access to high-value care. We considered, but did not propose, including in the referral to primary care services the requirement that TEAM participants refer the TEAM beneficiary back to the supplier of primary care services with whom they have an established relationship. We explained in the proposed rule that as part of the alternative, we considered identifying an established relationship by the TEAM beneficiary’s interaction with a supplier of primary care services within the 2 previous years before the initiation of the episode and TEAM participants would still need to comply with beneficiary freedom of choice requirements. However, we were concerned that this consideration, namely requiring the TEAM participant to refer the TEAM partici icipants would still need to comply with beneficiary freedom of choice requirements. However, we were concerned that this consideration, namely requiring the TEAM participant to refer the TEAM participant back to a supplier of primary care services with whom they have an existing relationship, would increase TEAM participant administrative burden by having them review claims data for an existing relationship and may be challenging to operationalize given the window of time when the beneficiary is admitted to the hospital or hospital outpatient department and when they are required to submit the referral— before the TEAM beneficiary is discharged from the hospital or hospital outpatient department. As such, we considered extending the timeframe of when the referral to primary care services would occur. For example, we considered requiring the referral to primary care services to occur any time before the episode ends, rather than by the time the TEAM beneficiary is discharged from the hospital or hospital outpatient department. Given the administrative burden, we considered only requiring the referral for TEAM beneficiaries who do not have any relationship with a supplier of primary ospital or hospital outpatient department. Given the administrative burden, we considered only requiring the referral for TEAM beneficiaries who do not have any relationship with a supplier of primary care services within the 2 previous years before the initiation of the episode as long as beneficiary freedom of choice requirements would be met, which would reduce burden since evidence from the BPCI Advanced model suggests most beneficiaries have some existing relationship. However, we recognized burden would not be diminished because it would still require the TEAM participant to identify through claims data whether the beneficiary had an established relationship or not. We also considered, but did not propose, that a TEAM participant could refer the beneficiary to a supplier of primary care services other than their existing supplier, including referral to a TEAM participant’s supplier of primary care services, as long as beneficiary freedom of choice requirements would be met, and the TEAM participant documented the TEAM beneficiary’s preference. In the proposed rule, we recognized such a policy would increase administrative burden on TEAM participants to document a TEAM benefic he TEAM participant documented the TEAM beneficiary’s preference. In the proposed rule, we recognized such a policy would increase administrative burden on TEAM participants to document a TEAM beneficiary’s preference to be referred to a supplier of primary care services other than the supplier with whom they have an established relationship. However, we believed this additional documentation would help to ensure referrals are not influenced by a TEAM participant’s financial or contractual relationships with certain suppliers of primary care services. In the proposed rule, we noted that an internal analysis for the BPCI Advanced model demonstrated that approximately 94 percent of beneficiaries that initiated an episode, medical or surgical, had some primary care visit, as demonstrated through at least one evaluation & management (E&M), care management services, care planning, or wellness visit in 2 years prior to their episode. Additionally, among the small group that did not have a primary care visit in those 2 years before the episode, the BPCI Advanced model increased the share of beneficiaries getting a primary care visit within the 90-day post- discharge period by 9 percent fo imary care visit in those 2 years before the episode, the BPCI Advanced model increased the share of beneficiaries getting a primary care visit within the 90-day post- discharge period by 9 percent for medical episodes. We stated in the proposed rule that this suggests that the majority of BPCI Advanced beneficiaries have interfaced with primary care prior to their episode of care and that they may have an existing relationship with a supplier of primary care services. However, we noted in the proposed rule that the benefit to requiring referral to primary care may be more practical for medical episodes rather than surgical episodes. This may be because the surgeon specialist has the expertise to manage the clinical follow-up, whereas a medical episode is generally an acute exacerbation of a chronic condition that primary care may typically manage. Given TEAM’s current set episodes are all surgical, we recognized the primary care service referral may not be as impactful to driving primary care connections. We therefore considered, but did not propose, removing the referral to primary care services requirement from TEAM. This means that a TEAM participant would not be required to su ary care connections. We therefore considered, but did not propose, removing the referral to primary care services requirement from TEAM. This means that a TEAM participant would not be required to submit a referral to primary care services for any TEAM beneficiary. In addition to the internal analysis findings, we stated in the proposed rule that we believe many TEAM participants already have the mechanisms in place to refer the TEAM beneficiary back to their preferred supplier of primary care services, thus making the requirement inconsequential. Further, we also stated in the proposed rule that TEAM’s testing of surgical episodes may also be contrary to a goal of the model. Meaning, referring back to a supplier of primary care services could result in unnecessary spending if the supplier of primary care services does not effectively manage the TEAM beneficiary’s care. For example, a supplier of primary care services has the TEAM beneficiary go to the emergency department for surgical wound assessment, whereas the surgeon specialist may have informed the TEAM beneficiary the wound was healing as expected. Despite the consideration to removing the referral to primary care services l wound assessment, whereas the surgeon specialist may have informed the TEAM beneficiary the wound was healing as expected. Despite the consideration to removing the referral to primary care services requirement, we stated in the proposed rule that we still believe it is an important policy because it provides additional assurances the TEAM participant will connect the TEAM beneficiary to primary care services for ongoing care and follow-up that may help to reduce avoidable readmissions VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00590 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37125 and promote better longer-term outcomes. We sought comment on our proposal to maintain the current policy as well as the alternative approaches for the referral to primary care services requirement as described previously. We also sought comment on alternatives that we may not have considered. The following is a summary of the public comments received on the proposed policy to maintain the primary care services referral requirement t comment on alternatives that we may not have considered. The following is a summary of the public comments received on the proposed policy to maintain the primary care services referral requirement and alternatives to this requirement, and our responses to these comments: Comment: Many commenters supported the referral to primary care services requirement. The majority of the commenters that supported the requirement supported a referral back to an established supplier of primary care services. Of those commenters that supported a referral back to an established supplier of primary care services, many had concerns with using historical claims to identify the established supplier of primary care services due to operational burden and lack of insight. Several commenters supported having the TEAM participant refer to the supplier of primary care services recorded at the initiation of the hospitalization or outpatient procedure. Other commenters that supported the requirement suggested that the referral go to the ordering or primary follow-up physician rather than a primary care provider. A commenter recommended using CPTII codes to ensure beneficiaries are connected back to a provid hat the referral go to the ordering or primary follow-up physician rather than a primary care provider. A commenter recommended using CPTII codes to ensure beneficiaries are connected back to a provider to which they are already aligned. Response: We thank the commenters for their support. As we noted in the FY 2025 IPPS/LTCH PPS final rule, TEAM provides an opportunity to further integrate care during the transition from an acute event- an episode- back to longitudinal care relationships, such as primary care (89 FR 69850). As such, the intent of the referral to primary care services requirement is to ensure the TEAM beneficiary can have continual clinical management from a longitudinal care provider after the episode ends. We do not intend for this requirement to disrupt existing patient- provider relationships nor replace any follow-up or management clinically necessary from a specialist or the clinician who performed the surgery. We agree that when including a referral to a supplier of primary care services in hospital discharge planning for a TEAM beneficiary, that the TEAM participant should take into account the TEAM beneficiary’s primary care provider recorded during the ho r of primary care services in hospital discharge planning for a TEAM beneficiary, that the TEAM participant should take into account the TEAM beneficiary’s primary care provider recorded during the hospital admission to the anchor hospitalization or recorded during the intake for the anchor procedure. We believe improved beneficiary quality of care can be achieved through consistent care management from suppliers who have an established relationship with the TEAM beneficiary. However, we recognize that there may be times that a TEAM beneficiary’s preferences may change over the course of the anchor hospitalization or anchor procedure. Therefore, it is imperative that TEAM participants comply with beneficiary freedom of choice requirements, as described in § 512.582(a), when including the referral for primary care services in the hospital discharge planning. We agree that relying on claims data to identify an established supplier of primary care services would be operationally burdensome on the TEAM participant and that this data may not capture recent patient preferences, especially if the TEAM beneficiary moved or if the TEAM beneficiary opted to change providers. We acknowledge t e on the TEAM participant and that this data may not capture recent patient preferences, especially if the TEAM beneficiary moved or if the TEAM beneficiary opted to change providers. We acknowledge the recommendation to use CPT II codes, as was used in BPCI Advanced for the Advanced Care Plan measure, to ensure a TEAM beneficiary is connected back to their established provider. However, we believe adding another step, such as including non- billable CPT II codes to a claim would increase TEAM participant burden unnecessarily. We also recognize the value in referring the TEAM beneficiary to a supplier that may be more clinically attuned to managing the TEAM beneficiary’s medical needs. As noted earlier, the referral to primary care services requirement should not replace any clinically appropriate follow-up care with a specialist or clinician that performed the surgical procedure. Outside of the referral to primary care services requirement, TEAM participants are not precluded from referring the TEAM beneficiaries to a specialist and we support the TEAM participant helping to coordinate a TEAM beneficiary’s care with a specialist as that acute surgical event is typically the primar erring the TEAM beneficiaries to a specialist and we support the TEAM participant helping to coordinate a TEAM beneficiary’s care with a specialist as that acute surgical event is typically the primary clinical focus after discharge from the hospital or hospital outpatient department. We believe the TEAM participant is well positioned to identify a supplier that they believe would be the most clinically appropriate to manage the TEAM beneficiary as long as the TEAM participant is complying with beneficiary freedom of choice requirements. Given the majority of commenters’ support for CMS to ensure TEAM beneficiaries are being referred to established suppliers, we believe that we need to modify the referral to primary care services requirement. Specifically, we will be adding clarifying language to § 512.564(a) to state that a TEAM participant must include in hospital discharge planning a referral to an established supplier of primary care services, as recorded on admission to the hospital or hospital outpatient department, for a TEAM beneficiary, on or prior to discharge from an anchor hospitalization or anchor procedure. However, we recognize that there may be instances when a supp al or hospital outpatient department, for a TEAM beneficiary, on or prior to discharge from an anchor hospitalization or anchor procedure. However, we recognize that there may be instances when a supplier of primary care services is not recorded on admission to the hospital or hospital outpatient department. We also want to prevent TEAM participants circumventing the documentation of an established supplier of primary care services to avoid the referral to primary care services requirement. In the event an established supplier of primary care services is not recorded on admission to the hospital or hospital outpatient department, such as because the TEAM beneficiary does not have an established supplier of primary care services, the TEAM participant must include in hospital discharge planning a referral to a supplier of primary care services for a TEAM beneficiary, on or prior to discharge from an anchor hospitalization or anchor procedure. In other words, if the supplier of primary care services was not recorded on admission to the hospital or hospital outpatient department, the existing referral to primary care services would apply. This ensures all TEAM beneficiaries are being c re services was not recorded on admission to the hospital or hospital outpatient department, the existing referral to primary care services would apply. This ensures all TEAM beneficiaries are being connected back to a supplier of primary care services, not just those with an established supplier. No modifications will be made to § 512.564(b); therefore, TEAM participants must continue to comply with beneficiary freedom of choice requirements. This means TEAM participants must continue to take into account TEAM beneficiary preferences when referring to a supplier of primary care services, which may include consideration of the supplier’s location in relation of the TEAM beneficiary’s place of residence. We believe this addition will ensure that TEAM beneficiaries are being referred to the established provider with whom they have an existing relationship. Further, we believe the referral to primary care services requirement will promote collaboration between the TEAM participant and primary care providers, so that the TEAM beneficiary is being managed by a care team that includes clinicians who VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00591 Fmt 4701 Sfmt 4700 E:\F mary care providers, so that the TEAM beneficiary is being managed by a care team that includes clinicians who VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00591 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37126 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations can manage the surgical procedure and clinicians who focus on preventative care and can manage underlying, chronic conditions. Comment: Several commenters supported a referral to primary care services but recommended CMS to not make it a requirement of the model. These commenters requested flexibilities for the TEAM participant to determine when a referral is appropriate and suggested the referral only be applicable to beneficiaries that do not have a supplier of primary care services. Some commenters also recommended that CMS include incentives for hospitals that successfully integrate primary care referrals into their care coordination strategies, rather than imposing strict compliance measures. Response: We appreciate the commenters’ recommendations. We recognize that a model requirement, as opposed to a nto their care coordination strategies, rather than imposing strict compliance measures. Response: We appreciate the commenters’ recommendations. We recognize that a model requirement, as opposed to an optional model feature, may have the potential to increase TEAM participant burden. However, we believe that a referral to primary care services is already a common component to hospital discharge planning procedures and, as such, we expect that many TEAM participants will already have this policy integrated into their standardized discharge planning procedures and therefore have a minimal impact on burden. We also understand why commenters suggested this model requirement just focus on TEAM beneficiaries that do not have a supplier of primary care services since these are the patients that may eventually lack proper care management after the episode ends. Nonetheless, we believe having the referral to primary care services requirement apply to all TEAM beneficiaries is the most appropriate because we view the referral to primary care services as an important component of care coordination. Given a goal of the model is to improve transitions between care settings and providers, we be ate because we view the referral to primary care services as an important component of care coordination. Given a goal of the model is to improve transitions between care settings and providers, we believe it would be best practice for TEAM participants to refer all TEAM beneficiaries not just those without an established supplier of primary care services. We acknowledge that the referral to primary care services is a requirement of the model but we do not believe that TEAM participants should be incentivized above and beyond the existing model incentive structure. Rather, we view the requirement as a mechanism to establish a standard care practice that we believe many hospitals already implement. We also believe the policy supports a step towards whole- person health where TEAM beneficiaries are being managed by the providers with the clinical expertise of their acute surgical event and then subsequently connected back to providers with longitudinal primary care expertise. Comment: Some commenters requested CMS extend the referral period to anytime during the episode of care rather than limiting it to the time period before the TEAM beneficiary is discharged from the anchor hospit me commenters requested CMS extend the referral period to anytime during the episode of care rather than limiting it to the time period before the TEAM beneficiary is discharged from the anchor hospitalization or anchor procedure. Response: We acknowledge the commenters’ recommendations to extend the referral period, which would provide the TEAM participant with more time to submit a referral to a supplier of primary care services. Still, we believe the best opportunity to have conversations with the TEAM beneficiary regarding longitudinal care management is when the TEAM participant can have in-person interaction with the TEAM beneficiary or the TEAM beneficiary’s family or caregivers. This means we believe the most appropriate time frame to have these face-to-face conversations would be during the anchor hospitalization or anchor procedure. Further, we also believe that having these face-to-face discussions during the anchor hospitalization or anchor procedure is conducive to ensuring beneficiary freedom of choice is taken into account when submitting the referral during discharge planning. Comment: A couple of commenters did not support CMS’s consideration of requiring hospitals g beneficiary freedom of choice is taken into account when submitting the referral during discharge planning. Comment: A couple of commenters did not support CMS’s consideration of requiring hospitals to refer patients specifically to a supplier of primary care services they have visited in the past 2 years, based on claims information, due to the TEAM participant’s burden since claims are not integrated into electronic health records (EHRs). They further indicated that patients may have moved or deliberately changed their usual source of care in the previous 2 years, which could prevent hospitals from connecting patients to a more appropriate source of care. Lastly, they indicated that patients that recently switched their supplier of primary care services would not necessarily have their current supplier of primary care services reflected in the claims available to the hospital at the time of discharge. Response: We recognize the challenge TEAM participants may have to identify a supplier of primary care services that has an established relationship with a TEAM beneficiary in the 2 years prior to the anchor hospitalization or anchor procedure when relying on claims data. While Me plier of primary care services that has an established relationship with a TEAM beneficiary in the 2 years prior to the anchor hospitalization or anchor procedure when relying on claims data. While Medicare providers and suppliers are generally good at submitting timely claims, we acknowledge that TEAM beneficiaries that have recently switched suppliers of primary care services may have their new suppliers and preferences inadvertently overlooked given the lag in claims data. Additionally, as the commenters noted, claims data is not necessarily integrated within a hospital’s EHR technology, and we realize the limitation to accessing historical claims data, especially claims data for items and services outside of the hospital’s claims. We also understand that TEAM beneficiaries can be transient or seek care from multiple clinicians over the span of the 2 years and thus relying on claims data in the 2-year period prior to the anchor hospitalization or anchor procedure to identify an established supplier of primary care services may not be the most reliable or clinically appropriate method to support continuity of care, especially in light of current medical needs after a surgical pro blished supplier of primary care services may not be the most reliable or clinically appropriate method to support continuity of care, especially in light of current medical needs after a surgical procedure. Therefore, we agree it may not be appropriate or operationally feasible to rely on claims data in the 2 years prior to the anchor hospitalization or anchor procedure to identify a supplier of primary care services for a TEAM beneficiary. Given these concerns, we are not requiring the TEAM participant to rely on claims data in the two years prior to the anchor hospitalization or anchor procedure to identify an established supplier of primary care services. Comment: Many commenters had concerns with the referral to primary care services requirement. Specifically, commenters wanted CMS to consider the impacts of the national physician shortage. These commenters indicated that hospitals, depending on their location, might experience challenges when referring patients after discharge and CMS should implement safeguards that would prevent clinicians from being penalized for situations beyond their control. A couple of commenters noted this referral to primary care services requiremen d CMS should implement safeguards that would prevent clinicians from being penalized for situations beyond their control. A couple of commenters noted this referral to primary care services requirement fails to account for situations where patients are offered but decline the option. Another commenter noted the challenges of identifying providers in remote cities/counties outside of their primary service area. A couple of commenters stated that the requirement could lead to increased costs for patients and contribute to patient dissatisfaction. Lastly, another commenter noted concerns with the requirement conflicting with ACO patient assignment and it potentially resulting in double payment for postoperative visits. The same commenter indicated that hospitals are already implementing this requirement due to hospital conditions of participation at § 482.24(d). VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00592 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37127 Response: We thank the commenters for sharing their conce i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37127 Response: We thank the commenters for sharing their concerns and we acknowledge the challenges that arise from provider shortages and the impact they have on the health care system and patient access to care. We agree that it would not be fair to have a policy that could result in remedial action when the conditions of the policy are beyond the provider’s control. That is why the referral to primary care services only requires the TEAM participant to include a referral in discharge planning and does not require the follow-up appointment to be scheduled or for the TEAM beneficiary to be seen within a certain amount of time. While the goal is for the TEAM beneficiary to be connected back to a supplier of primary care services for ongoing longitudinal care, we recognize imposing requirements beyond a referral may unnecessarily put certain TEAM participants at a disadvantage, such as rural hospitals or hospitals where clinician supply is low. Further, the definition of primary care services, as defined at § 512.505, is a broad definition that en icipants at a disadvantage, such as rural hospitals or hospitals where clinician supply is low. Further, the definition of primary care services, as defined at § 512.505, is a broad definition that encompasses many different types of potential primary care services that can make compliance with the requirement much easier for the TEAM participant, especially hospitals that face provider shortage challenges. We disagree that the referral to primary care services requirement fails to account for instances where the TEAM beneficiary may decline follow up care to a supplier of primary care services. The referral to primary care services requirement includes a provision that requires the TEAM participant to comply with beneficiary freedom of choice, as described in § 512.564(b). This means that a TEAM beneficiary may decline being referred to a supplier of primary care services and the TEAM participant may not be subject to remedial action because they respected the TEAM beneficiary’s choice. We note that just like any other discussion about the TEAM beneficiary’s care during the anchor hospitalization or anchor procedure, documentation of the refusal should be included in the beneficia e. We note that just like any other discussion about the TEAM beneficiary’s care during the anchor hospitalization or anchor procedure, documentation of the refusal should be included in the beneficiary’s EHR. We also disagree that the referral to primary care services would lead to increased patient costs and dissatisfaction. The conditions of participation the commenter referred to require hospitals to send notifications of admission and discharge/transfer to post-acute care providers or practitioners responsible for follow up care, not to identify specific primary care providers or refer beneficiaries to primary care services (42 CFR 482.24(d)). However, hospitals are required to have an effective discharge planning process which must be consistent with the patient’s goals for care and treatment preferences, ensure an effective transition of the patient from hospital to post-discharge care, and reduce the factors leading to preventable hospital readmissions (42 CFR 482.43). Hospitals must also transfer necessary medical information to appropriate post-acute care providers at the time of discharge. We believe the model’s referral to primary care services requirement is reinforcin s must also transfer necessary medical information to appropriate post-acute care providers at the time of discharge. We believe the model’s referral to primary care services requirement is reinforcing existing Medicare conditions of participation, not increasing patient encounters or out- of-pocket costs. Further, proper ongoing care management may reduce unnecessary provider encounters leading to less patient out-of-pocket costs. We also disagree that the referral to primary care services would lead to patient dissatisfaction. On the contrary, we believe the referral to primary care services requirement will result in TEAM beneficiaries having improved care experiences because the referral supports communication and coordination between specialty and primary care, which ensures continuity of care and supports whole person health. We disagree that the referral to primary care services requirement will disrupt beneficiary assignment in ACO models or result in duplicative post- operative visits. We believe that this requirement will promote better collaboration between TEAM participants and providers in ACOs models because TEAM participants should be referring TEAM beneficiaries to e visits. We believe that this requirement will promote better collaboration between TEAM participants and providers in ACOs models because TEAM participants should be referring TEAM beneficiaries to their established supplier of primary care services. Generally, beneficiaries aligned or assigned to an ACO have established suppliers of primary care services which would make compliance to the requirement easy and support handoff to longitudinal care management. We also disagree with the commenter that the referral to primary care services requirement would result in duplicative postoperative visits. The referral to primary care services requirement does not replace the specialty-specific care services, such as a postoperative visit with the surgeon specialist, a TEAM beneficiary may need after they are discharged from the anchor hospitalization or anchor procedure. Nor does the requirement require a follow-up visit with the supplier of primary care services during the episode of care or within a certain time period. Lastly, we agree with the commenter that many hospitals may already be referring their patients to primary care services due to existing Medicare conditions of participa within a certain time period. Lastly, we agree with the commenter that many hospitals may already be referring their patients to primary care services due to existing Medicare conditions of participation for hospitals. While the Medicare conditions of participation requirements do not explicitly require referral to a supplier of primary care services, the conditions do require hospitals to send notifications to post-acute care providers or practitioners responsible for follow up care, which may or may not be suppliers of primary care services. Further, the Medicare conditions of participation have similar goals as TEAM, such as ensuring effective care transitions and reducing preventable hospital readmissions. Therefore, we believe that TEAM’s referral to primary care services requirement is complementary to the existing conditions of participation and does not create additional burden beyond what may already be required of hospitals participating in the Medicare program. Comment: A commenter suggested that CMS should consider aligning the definition of primary care services with HEDIS measures for follow-up after ED visits for high-risk patients, or with primary care definitions ommenter suggested that CMS should consider aligning the definition of primary care services with HEDIS measures for follow-up after ED visits for high-risk patients, or with primary care definitions used in the Medicare Shared Savings Program. Response: We thank the commenter for their suggestion. We recognize there are multiple definitions of primary care services, and we understand the value of aligning across different CMS initiatives. However, we believe the broad definition of primary care services used in TEAM allows the TEAM participant flexibility to identify the most clinically appropriate supplier for the TEAM beneficiary’s needs. We also believe that a narrow definition may result in a TEAM participant having difficulties identifying a supplier of primary care services when there are provider shortages. Comment: A commenter suggested that CMS consider ways to ensure that primary care suppliers involved in care transitions take steps to prevent opioid misuse by requiring the TEAM participant to document a rationale for prescribing opioids and a plan for transitioning the beneficiary to a non- opioid alternative, as clinically appropriate. They also recommended for benefi TEAM participant to document a rationale for prescribing opioids and a plan for transitioning the beneficiary to a non- opioid alternative, as clinically appropriate. They also recommended for beneficiaries prescribed opioids at discharge, establishing a care plan that involves joint monitoring by the TEAM participant and primary care supplier to monitor for any signs of opioid misuse or opioid use disorder. Response: We recognize that it is common for opioids to be prescribed after a surgical procedure for pain management and we support providers and suppliers taking action to prevent opioid misuse. Proper care management for beneficiaries that are prescribed VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00593 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37128 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations opioids may lead to better health outcomes, mitigate pain, and reduce risks associated with opioid use disorder, overdose, and death. We anticipate TEAM will drive improved care coordination between providers and suppliers and we encourage TEAM participants t and reduce risks associated with opioid use disorder, overdose, and death. We anticipate TEAM will drive improved care coordination between providers and suppliers and we encourage TEAM participants to work closely with a TEAM beneficiary’s primary care provider to implement care plans attentive to the needs of the patient while promoting pathways to taper or discontinue opioid use, as clinically appropriate. We do not believe adding additional requirements, such as a documentation requirement, would result in reduced opioid misuse because we believe TEAM participants are already implementing safeguards to monitor patients for opioid misuse. TEAM participants are accountable for the quality of care and spending during an episode of care, which we believe will incentivize TEAM participants to closely manage beneficiaries and implement both patient-specific and patient-driven care plans. Further, the existing referral to primary care services requirement helps to connect TEAM beneficiaries back to primary care for continued care management beyond the episode which may help to minimize unnecessary long-term prescription opioid use. Comment: A few commenters wanted to know if the refer es back to primary care for continued care management beyond the episode which may help to minimize unnecessary long-term prescription opioid use. Comment: A few commenters wanted to know if the referral to primary care services requirement was just a referral or if it included an actual follow-up visit to the supplier of primary care services. One of the commenters noted that post-operative follow-up visits are performed by the surgical specialist and not the primary care provider. Another commenter wanted to know if the TEAM participant needed to confirm a scheduled follow-up visit. Response: We appreciate the commenters request to clarify the referral to primary care services requirement. TEAM participants are required to include in hospital discharge planning a referral to a supplier of primary care services for a TEAM beneficiary, on or prior to discharge from an anchor hospitalization or anchor procedure. TEAM participants are not required to ensure a visit is scheduled, nor are they required to confirm the beneficiary had the visit with the supplier of primary care services. We recognize there may be challenges outside the control of the TEAM participant, such as provider sh they required to confirm the beneficiary had the visit with the supplier of primary care services. We recognize there may be challenges outside the control of the TEAM participant, such as provider shortages, that could make scheduling a visit or requiring an actual visit to be burdensome or potentially difficult to be in compliance with. Further, we want to be mindful of beneficiary freedom of choice requirements and a beneficiary’s right to refuse follow-up care. To address the commenter’s statement about post-operative follow-up visits being with a surgical specialist and not a primary care provider, we want to highlight that the referral to primary care services requirement does not intend to replace or bypass any follow- up visit with a surgical specialist or the supplier who performed the procedure. The intent of the referral to primary care services requirement is to ensure that the TEAM beneficiary is connected back to primary care, and that they have a clinician who can help to manage their care after the episode end After consideration of the public comments, we are modifying the referral to primary care services requirement at § 512.564(a) to add that a TEAM participant o manage their care after the episode end After consideration of the public comments, we are modifying the referral to primary care services requirement at § 512.564(a) to add that a TEAM participant must include in hospital discharge planning a referral to an established supplier of primary care services, as recorded on admission to the hospital or hospital outpatient department, for a TEAM beneficiary, on or prior to discharge from an anchor hospitalization or anchor procedure. In the event an established supplier of primary care services is not recorded on admission to the hospital or hospital outpatient department, the TEAM participant must include in hospital discharge planning a referral to a supplier of primary care services for a TEAM beneficiary, on or prior to discharge from an anchor hospitalization or anchor procedure. f. Waivers of Medicare Program Requirements—3-Day SNF Rule In the FY 2025 IPPS/LTCH PPS final rule (89 FR 69833), we finalized the 3- Day SNF Rule Waiver that waives the requirement for a 3-day inpatient hospital stay prior to a Medicare- covered, post-hospital, extended-care service for eligible beneficiaries if certain conditions are met. As finalized, t waives the requirement for a 3-day inpatient hospital stay prior to a Medicare- covered, post-hospital, extended-care service for eligible beneficiaries if certain conditions are met. As finalized, the 3-Day SNF Rule Waiver allows TEAM participants to send eligible TEAM beneficiaries to qualified SNFs, as described in § 512.580(b), which does not include hospitals with swing bed arrangements. We sought comment in the FY 2025 IPPS/LTCH PPS proposed rule on the potential to allow TEAM participants to use the SNF 3-day rule waiver for hospitals and Critical Access Hospitals (CAHs), as designated in § 485.606, providing post-acute care (PAC) under swing bed arrangements (89 FR 36468). We considered including swing bed arrangements under the TEAM SNF 3-day rule waiver, but did not propose to do so at the time, citing concerns about the inability to ensure the quality of swing bed arrangements for post-acute care following an early hospital discharge. We received stakeholder feedback recommending that we allow TEAM participants to use the TEAM SNF 3-day rule waiver for PAC provided under swing bed arrangements on the grounds that the inclusion of swing beds would increase access to PAC mending that we allow TEAM participants to use the TEAM SNF 3-day rule waiver for PAC provided under swing bed arrangements on the grounds that the inclusion of swing beds would increase access to PAC services for beneficiaries in rural areas or areas with health care shortages (89 FR 69834). However, we did not alter our proposal and finalized the TEAM SNF 3-day rule waiver without including swing beds. In the final rule, we noted that greater risks may be present for patients following early inpatient hospital discharge, and that the SNF quality rating requirement for use of the SNF 3-day rule waiver, which requires SNFs to have a CMS Five-Star Quality Rating System rating of 3 stars or better for at least 7 of the past 12 months, offers an additional level of protection to beneficiaries following an early discharge by ensuring that all TEAM beneficiaries discharged to a SNF after a hospital stay of fewer than 3 days are admitted to a SNF that has demonstrated that it can provide quality care to patients with significant unresolved post-surgical symptoms and problems. Without a corresponding metric in place for swing bed arrangements, we declined to include swing beds under the T lity care to patients with significant unresolved post-surgical symptoms and problems. Without a corresponding metric in place for swing bed arrangements, we declined to include swing beds under the TEAM SNF 3-day rule waiver. To address stakeholder concerns surrounding PAC access in rural and underserved areas, we proposed to allow TEAM participants to use the TEAM SNF 3-day rule waiver for TEAM beneficiaries discharged to hospitals and CAHs providing PAC under swing bed arrangements. We stated in the proposed rule that in order to furnish SNF services under a swing bed agreement, hospitals must be substantially in compliance with the SNF participation requirements specified at § 482.58(b), whereas CAHs must be substantially in compliance with the SNF participation requirements specified at § 485.645(d). However, per current TEAM regulations, TEAM participants are not permitted to use the TEAM 3-day SNF waiver for SNF services furnished under a swing bed agreement because: (1) The SNF 3-day rule waiver under the TEAM regulations at § 512.580(b)(1) waives the requirement for a 3-day prior inpatient hospitalization only with respect to otherwise covered SNF services furnished by an 3-day rule waiver under the TEAM regulations at § 512.580(b)(1) waives the requirement for a 3-day prior inpatient hospitalization only with respect to otherwise covered SNF services furnished by an eligible SNF and does not extend to otherwise covered post- hospital extended care services furnished by a provider under a swing bed agreement; and (2) CAHs and other rural hospitals furnishing SNF services VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00594 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37129 under swing bed agreements are not included in the CMS Five-Star Quality Rating System and, therefore, cannot meet the requirement at § 512.580(b)(3) that, to be qualified for Medicare coverage of SNF services provided to a TEAM beneficiary discharged from the hospital with a stay of less than 3 days under the TEAM SNF 3-day rule waiver, the SNF must have an overall rating of 3 or higher under the CMS Five-Star Quality Rating System for 7 of the previous 12 months. For the reasons described in stakeholder comments o 3-day rule waiver, the SNF must have an overall rating of 3 or higher under the CMS Five-Star Quality Rating System for 7 of the previous 12 months. For the reasons described in stakeholder comments on the FY 2025 IPPS/LTCH PPS proposed rule as well as recent academic research on PAC access in rural areas,408 we believed it was necessary to offer hospitals participating under episode-based payment models and thereby assuming financial responsibility for their beneficiaries’ PAC—especially hospitals operating in areas where PAC access may be limited and SNF services specifically may only be available in non-traditional SNF settings— additional tools and flexibility to manage and coordinate care for their beneficiaries. We indicated in the proposed rule that we agreed with stakeholders that there are fewer SNFs in rural areas. We also agreed with stakeholders that risk-bearing hospitals in rural areas would be better able to coordinate and manage care, and thus to control unnecessary costs, if the SNF 3- day rule waiver extended to otherwise covered SNF services provided by a hospital or CAH under a swing bed agreement. We believed this proposal would primarily benefit hospitals loca ts, if the SNF 3- day rule waiver extended to otherwise covered SNF services provided by a hospital or CAH under a swing bed agreement. We believed this proposal would primarily benefit hospitals located in rural areas because most CAHs and hospitals that are approved to furnish post-acute SNF-level care via a swing bed agreement are located in rural areas. Consistent with what we proposed, and in line with the Medicare Shared Savings Program regulations at § 425.612(a)(1) introductory text and (a)(1)(iii)(A), we also proposed to revise the regulations governing the SNF 3-day rule waiver at § 512.580(b)(1) to indicate that, for purposes of determining SNF qualification for the SNF 3-day rule waiver, SNFs include providers furnishing SNF services under swing bed arrangements. We stated in the proposed rule that we believe it is important to align the SNF 3-day rule waiver with other CMS programs and 408 Sharma, H., Bin Abdul Baten, R., Ullrich, F., MacKinney, A.C., & Mueller, K.J. (2024). Nursing home closures and access to post-acute care and long-term care services in rural areas. The Journal of rural health: official journal of the American Rural Health Association and the Nation ). Nursing home closures and access to post-acute care and long-term care services in rural areas. The Journal of rural health: official journal of the American Rural Health Association and the National Rural Health Care Association, 40(3), 557–564. https:// doi.org/10.1111/jrh.12822. initiatives, where appropriate, to create more uniform policies and hopefully increase waiver utilization. In addition, we proposed to revise § 512.580(b)(3) to specify that the minimum 3-star rating requirement for at least 7 of the past 12 months applies only if the provider furnishing SNF services is eligible to be included in the CMS Five-Star Quality Rating System. We indicated in the proposed rule that we did not have a comparable data element to the CMS Five-Star Quality Rating System for hospitals and CAHs under swing bed agreements; however, under §§ 512.590 and 512.586(a), we reserved the right to monitor and audit the use of payment waivers. We will continue to monitor the use of the SNF 3-day rule waiver to ensure TEAM participants are not compromising beneficiary protections at § 512.582(a) and reserve the right to perform remedial action under § 512.592 if the waiver is used inappropriat rule waiver to ensure TEAM participants are not compromising beneficiary protections at § 512.582(a) and reserve the right to perform remedial action under § 512.592 if the waiver is used inappropriately or beneficiaries are not receiving appropriate care. Additionally, we noted in the proposed rule the possibility that a beneficiary could be admitted to a hospital, have an inpatient stay of less than 3 days, and then be admitted to the same hospital under its swing bed agreement. As previously discussed, we believed hospitals that bear a degree of financial risk have a stronger incentive not to overutilize services and have an incentive to recommend a beneficiary for admission to a SNF only when it is medically appropriate. We also noted in the proposed rule that this scenario could occur when a beneficiary meets the generally applicable 3-day stay requirement. Thus, we did not believe extending the SNF 3-day rule waiver to include services furnished by a hospital under a swing bed agreement would create a new gaming opportunity. We considered, but did not propose, including only swing bed arrangements at CAHs under the expanded TEAM SNF 3-day rule waiver. While stakeholder feedba reement would create a new gaming opportunity. We considered, but did not propose, including only swing bed arrangements at CAHs under the expanded TEAM SNF 3-day rule waiver. While stakeholder feedback received on the 2025 IPPS/LTCH PPS proposed rule focused on swing bed arrangements at CAHs, we believed that the inclusion of swing bed arrangements at other hospitals is better aligned with the swing bed eligibility requirements detailed in § 482.58. We sought comment on our proposal at § 512.580(b)(3) to allow TEAM participants to use the TEAM SNF 3-day rule waiver for TEAM beneficiaries discharged to hospitals and CAHs providing post-acute care (PAC) under swing bed arrangements. The following is a summary of the public comments received on the proposed policy to allow TEAM participants to use the TEAM SNF 3-day rule waiver for TEAM beneficiaries discharged to hospitals and CAHs providing post-acute care (PAC) under swing bed arrangements, and our responses to these comments: Comment: Many commenters supported the proposal to allow TEAM participants to use the TEAM SNF 3-day rule waiver for TEAM beneficiaries discharged to hospitals and CAHs providing PAC under swing bed arrangem : Many commenters supported the proposal to allow TEAM participants to use the TEAM SNF 3-day rule waiver for TEAM beneficiaries discharged to hospitals and CAHs providing PAC under swing bed arrangements, indicating that this proposed expansion of the SNF 3-day rule waiver would increase access to PAC for beneficiaries in rural and underserved areas and provide additional flexibility to TEAM participants in determining appropriate care pathways. Response: We thank the commenters for their support and agree with the stated benefits of broadening the TEAM 3-day SNF rule waiver to include swing bed arrangements. Comment: A commenter recommended that CMS permit the use of swing beds under the TEAM 3-day SNF rule waiver regardless of star rating. Response: We note that as part of the proposed broadening of the TEAM 3- day SNF rule waiver to include swing bed arrangements at hospitals and CAHs, we proposed to revise § 512.580(b)(3) to specify that the minimum 3-star rating requirement for 7 of the past 12 months applies only if the provider furnishing SNF services is eligible to be included in the CMS Five- Star Quality Rating System. Comment: A commenter recommended that CMS monitor th of the past 12 months applies only if the provider furnishing SNF services is eligible to be included in the CMS Five- Star Quality Rating System. Comment: A commenter recommended that CMS monitor the availability of eligible SNFs and swing beds in TEAM-participating regions to identify any gaps and adjust policy as needed. Response: We thank the commenter for their suggestion. We believe that broadening the TEAM 3-day SNF rule waiver to include swing bed arrangements at hospitals and CAHs will increase access to PAC in areas where PAC providers, especially eligible SNFs, are limited. As noted in the proposed rule and established in §§ 512.590 and 512.586(a), we reserve the right to monitor and audit the use of payment waivers. Such monitoring may include utilization of the 3-day SNF rule waiver across regions. Comment: A commenter recommended that we align the TEAM 3-day SNF rule waiver with the MSSP 3-day SNF rule waiver. Response: We note that the broadening of the TEAM 3-day SNF rule waiver to include swing bed arrangements at hospitals and CAHs VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00595 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D ule waiver to include swing bed arrangements at hospitals and CAHs VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00595 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37130 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations mirrors the MSSP 3-day SNF rule regulations at § 425.612(a)(1). After consideration of the public comments, we are finalizing without modification the proposal at § 512.580(b)(3) to allow TEAM participants to use the TEAM SNF 3-day rule waiver for TEAM beneficiaries discharged to hospitals and CAHs providing post-acute care (PAC) under swing bed arrangements. g. Decarbonization and Resilience Initiative In the FY 2025 IPPS/LTCH PPS final rule (89 FR 69859) we finalized the Decarbonization and Resilience Initiative (DRI). This initiative was designed to address threats posed by climate change to the Nation’s health and health care system by collecting, monitoring, and assessing hospital carbon emissions and their effects on health outcomes, costs, and quality. The initiative includes two primary elements— • Emissions reporting in four priority areas: nitoring, and assessing hospital carbon emissions and their effects on health outcomes, costs, and quality. The initiative includes two primary elements— • Emissions reporting in four priority areas: organizational, building energy, anesthetic gas, and transportation; and • Technical assistance on reducing emissions. We stated in the proposed rule that while the DRI is a voluntary initiative for TEAM participants and their hospital corporate affiliates, we recognize it does not align with the Administration’s priorities. We noted that it is not uncommon to reevaluate policies and programs, and that doing so is within an agency’s discretion, especially after a change in Administration, to implement changes through rulemaking. Additionally, since TEAM is a mandatory model, we wanted to reduce the reporting burden and reduce administrative costs on TEAM participants as much as possible, so eliminating this initiative will reduce the amount of data TEAM participants may report and reduce the costs to set up the reporting infrastructure. We stated in the proposed rule that the Episode Payment Models and the Cardiac Rehabilitation (CR) Incentive Payment Model were cancelled because, at t he costs to set up the reporting infrastructure. We stated in the proposed rule that the Episode Payment Models and the Cardiac Rehabilitation (CR) Incentive Payment Model were cancelled because, at that time, those models were not in the best interest of the Agency or the providers affected by them (82 FR 57066), and we similarly believed that retaining the DRI in TEAM is not in the best interest of the Agency or providers who already a part of a mandatory model. We believed removing this initiative from TEAM will allow TEAM participants to focus on the requirements of the model, rather than a voluntary initiative. We also believed that removing the DRI from TEAM will offer CMS flexibility to design and test other initiatives in the future that align with the Administration’s goals. We noted in the proposed rule that TEAM participants are not precluded from continuing their own efforts to reduce greenhouse gas emissions and are encouraged to engage in other areas that may help improve patient quality of care and reduce hospital spending and operating costs. Therefore, we proposed to remove the DRI from TEAM. We sought comment on our proposal to remove the DRI from TEAM and remove patient quality of care and reduce hospital spending and operating costs. Therefore, we proposed to remove the DRI from TEAM. We sought comment on our proposal to remove the DRI from TEAM and remove the corresponding regulations at § 512.598. The following is a summary of the public comments received on the proposed policy to remove DRI from TEAM, and our responses to these comments: Comment: Multiple commenters support CMS’s proposal to remove the voluntary decarbonization reporting requirements from TEAM. These commenters applauded CMS’s commitment to streamlining program requirements by reducing potential administrative burden. Commenters who supported the proposed removal of the voluntary decarbonization reporting requirement also noted this allows TEAM participants to focus on other areas of TEAM implementation. Response: We thank the commenters for their support. We agree that removal of the voluntary Decarbonization and Resilience Initiative from TEAM will allow TEAM participants to concentrate on other areas of the model, such as improving care transitions to drive quality improvements and finding efficiencies to reduce Medicare spending. Comment: Multiple commenters did n ts to concentrate on other areas of the model, such as improving care transitions to drive quality improvements and finding efficiencies to reduce Medicare spending. Comment: Multiple commenters did not support the removal of the voluntary decarbonization reporting requirements. Many of those opposed noted the United States healthcare system contributes more pollution than many other sectors of the U.S. economy and these reporting requirements could help healthcare providers better understand their impact on the environment. Response: We acknowledge the U.S. healthcare industry is large and emits large amounts of carbon. CMS’s proposal to remove the Decarbonization and Resilience initiative would simply remove the administrative burden to report this information to CMS. TEAM participants are not precluded from continuing their own efforts to reduce carbon emissions and CMS encourages TEAM participants to innovate in ways beyond model requirements to improve the healthcare system and population health. Comment: A commenter noted that a Decarbonization and Resilience Initiative could give TEAM participants data that would inform efforts to save money on energy expenses. Response: CMS pulation health. Comment: A commenter noted that a Decarbonization and Resilience Initiative could give TEAM participants data that would inform efforts to save money on energy expenses. Response: CMS is only proposing to remove the Decarbonization and Resilience Initiative, not dictating any internal process improvement efforts of TEAM participants. TEAM participants are still free, and encouraged, to find ways to lower energy costs that would save money to provide more quality patient care. Comment: Numerous commenters noted that air pollution, natural disasters, and changing climates cause millions of health problems every year. They noted that removing the Decarbonization and Resilience Initiative would allow TEAM participants to better track these climate events and respond to the health needs that follow. Response: We support any TEAM participants or healthcare providers who institute policies to reduce environmental impacts on their patients. This is a separate matter than TEAM participant reporting requirements, however, and we believe TEAM participants should be free to institute their own ecofriendly policies and procedures without CMS imposing a voluntary initiative that participant reporting requirements, however, and we believe TEAM participants should be free to institute their own ecofriendly policies and procedures without CMS imposing a voluntary initiative that may not meet the unique needs of each TEAM participant. Comment: Some commenters noted that they will continue their efforts to reduce their carbon footprints regardless of the Decarbonization and Resilience Initiative’s inclusion in TEAM. Response: We support any TEAM participants who would like to continue the Decarbonization and Resilience Initiative in their private capacity. CMS does not want to interfere with the internal decision-making process of healthcare providers. To this end, by removing the Decarbonization and Resilience Initiative, CMS is giving TEAM participants the freedom to continue, alter, or end their own decarbonization efforts without government oversight or imposing reporting requirements. After consideration of public comments, we are finalizing our proposal to remove the Decarbonization and Resilience Initiative from TEAM and remove the corresponding regulations at § 512.598. B. Health Data, Technology, and Interoperability: Electronic Prescribing, Real-Time move the Decarbonization and Resilience Initiative from TEAM and remove the corresponding regulations at § 512.598. B. Health Data, Technology, and Interoperability: Electronic Prescribing, Real-Time Prescription Benefit, and Electronic Prior Authorization (HTI–2) 1. General Comments ASTP/ONC received approximately 270 comment submissions on the broad VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00596 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37131 range of proposals included in the ‘‘Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability’’ proposed rule (HTI–2 Proposed Rule) (89 FR 63498). We thank all commenters for their thoughtful input. For the purposes of this final rule, we have reviewed and responded to comments on a narrowed set of proposals. Specifically, we summarize and respond to comments related to proposals to: • Update or adopt certification criteria for electronic prescribing, real- time prescription benefit capabilities, provide . Specifically, we summarize and respond to comments related to proposals to: • Update or adopt certification criteria for electronic prescribing, real- time prescription benefit capabilities, provider prior authorization APIs, and related proposals; • Adopt criteria for ‘‘modular API capabilities’’ related to decision support interventions and subscriptions capabilities; • Adopt implementation specifications supporting electronic prior authorization criteria; • Adopt additional implementation specifications that can support exchange of clinical data, administrative data, and provider directory information with payers; and • Update code sets related to medications referenced in certain criteria finalized in the rule. Comments received in response to other proposals from the HTI–2 Proposed Rule are beyond the scope of this final rule, are still being reviewed and considered, and may be the subject of subsequent final rules related to such proposals in the future. 2. Statutory Basis The Health Information Technology for Economic and Clinical Health Act (HITECH Act), Title XIII of Division A and Title IV of Division B of the American Recovery and Reinvestment Act of 2009 (Pub. L. 111– Health Information Technology for Economic and Clinical Health Act (HITECH Act), Title XIII of Division A and Title IV of Division B of the American Recovery and Reinvestment Act of 2009 (Pub. L. 111–5), was enacted on February 17, 2009. The HITECH Act amended the Public Health Service Act (PHSA) and created ‘‘Title XXX—Health Information Technology and Quality’’ (Title XXX) to improve healthcare quality, safety, and efficiency through the promotion of health IT and electronic health information (EHI) exchange. The 21st Century Cures Act (Pub. L. 114–255) (Cures Act) was enacted on December 13, 2016, to accelerate the discovery, development, and delivery of 21st century cures, and for other purposes. The Cures Act, through Title IV—Delivery, amended the HITECH Act by modifying or adding certain provisions to the PHSA relating to health IT. Section 1860D–4(o) of the Act, as added by section 119 of Title I, Division CC of the Consolidated Appropriations Act, 2021, Public Law 116–260 (CAA, 2021), requires sponsors of prescription drug plans to implement one or more real-time benefit tools (RTBTs) that meet the requirements described in section 1860D–4(o)(2) of the Act, after the Secre , 2021), requires sponsors of prescription drug plans to implement one or more real-time benefit tools (RTBTs) that meet the requirements described in section 1860D–4(o)(2) of the Act, after the Secretary has adopted a standard for RTBTs and at a time determined appropriate by the Secretary. For purposes of the requirement to implement a real-time benefit tool in section 1860D–4(o)(1) of the Act, section 1860D–4(o)(2)(A) of the Act provides that one of the requirements for an RTBT is that it can integrate with electronic prescribing and EHR systems of prescribing healthcare professionals for the transmission of formulary and benefit information in real time to such professionals. Section 1860D–4(o) of the Act requires incorporation of RTBTs within both the Medicare Part D prescription drug program and the ONC Health IT Certification Program (Certification Program). Specifically, section 119(b) of the CAA, 2021 amends the definition of a ‘‘qualified electronic health record’’ (qualified EHR) in section 3000(13) of the PHSA to add a new subparagraph (C) that requires that a qualified EHR must include (or be capable of including) an RTBT. a. Standards, Implementation Specifications, a EHR) in section 3000(13) of the PHSA to add a new subparagraph (C) that requires that a qualified EHR must include (or be capable of including) an RTBT. a. Standards, Implementation Specifications, and Certification Criteria The HITECH Act established two Federal advisory committees, the Health IT Policy Committee (HITPC) and the Health IT Standards Committee (HITSC). Each was responsible for advising the National Coordinator for Health Information Technology (National Coordinator) on different aspects of standards, implementation specifications, and certification criteria. Section 4003(e) of the Cures Act amended sections 3002 and 3003 of the PHSA by replacing, in an amended section 3002, the HITPC and HITSC with one committee named the Health Information Technology Advisory Committee (Health IT Advisory Committee or HITAC). Section 3002(a) of the PHSA, as added by the Cures Act, establishes that the HITAC recommends to the National Coordinator policies and standards, implementation specifications, and certification criteria, relating to the implementation of a health information technology infrastructure, nationally and locally, that advances the electronic access, exchange, and specifications, and certification criteria, relating to the implementation of a health information technology infrastructure, nationally and locally, that advances the electronic access, exchange, and use of health information. Further described in section 3002(b)(1) of the PHSA, this includes recommending to the National Coordinator a policy framework to advance interoperable health information technology infrastructure, updating recommendations to the policy framework, and making new recommendations, as appropriate. Section 3002(b)(2)(A) of the PHSA specifies that in general, the HITAC shall recommend to the National Coordinator for purposes of adoption under section 3004, standards, implementation specifications, and certification criteria and an order of priority for the development, harmonization, and recognition of such standards, specifications, and certification criteria. Like the process previously required of the former HITPC and HITSC, section 3002(b)(5) of the PHSA requires the HITAC to develop a schedule, updated annually, for the assessment of policy recommendations, which the Secretary publishes in the Federal Register. Section 3004 of the PHSA establishes a process the HITAC to develop a schedule, updated annually, for the assessment of policy recommendations, which the Secretary publishes in the Federal Register. Section 3004 of the PHSA establishes a process for the adoption of health IT standards, implementation specifications, and certification criteria and authorizes the Secretary to adopt such standards, implementation specifications, and certification criteria. As specified in section 3004(a)(1) of the PHSA, the Secretary is required, in consultation with representatives of other relevant federal agencies, to jointly review standards, implementation specifications, and certification criteria endorsed by the National Coordinator under section 3001(c) of the PHSA and subsequently determine whether to propose the adoption of such standards, implementation specifications, or certification criteria. Section 3004(a)(3) of the PHSA requires the Secretary to publish all such determinations in the Federal Register. Section 3004(b)(3) of the PHSA, titled, Subsequent Standards Activity, provides that the Secretary shall adopt additional standards, implementation specifications, and certification criteria as necessary and consistent with the sche titled, Subsequent Standards Activity, provides that the Secretary shall adopt additional standards, implementation specifications, and certification criteria as necessary and consistent with the schedule published by the HITAC. We consider this provision in the broader context of the HITECH Act and Cures Act to grant the Secretary the authority and discretion to adopt standards, implementation specifications, and certification criteria that have been recommended by the HITAC and endorsed by the National Coordinator, as well as other appropriate and necessary health IT standards, implementation specifications, and certification criteria. 3. ONC Health IT Certification Program Rules Section 3001(c)(5) of the PHSA provides the National Coordinator with VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00597 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37132 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations the authority to establish a certification program or programs for the voluntary certification of health IT. Section 3001(c)(5)(A) of the PHSA specifies that the Nation 4, 2025 / Rules and Regulations the authority to establish a certification program or programs for the voluntary certification of health IT. Section 3001(c)(5)(A) of the PHSA specifies that the National Coordinator, in consultation with the Director of the National Institute of Standards and Technology (NIST), shall keep or recognize a program or programs for the voluntary certification of health IT that is in compliance with applicable certification criteria adopted under section 3004 of the PHSA. The certification program(s) must also include, as appropriate, testing of the technology in accordance with section 13201(b) of the HITECH Act. Section 13201(b) of the HITECH Act requires that, with respect to the development of standards and implementation specifications, the Director of NIST shall support the establishment of a conformance testing infrastructure, including the development of technical test beds. Section 13201(b) of the HITECH Act also indicates that the development of this conformance testing infrastructure may include a program to accredit independent, non- federal laboratories to perform testing. Section 4002(a) of the Cures Act amended section 3001(c)(5) of the PHS s conformance testing infrastructure may include a program to accredit independent, non- federal laboratories to perform testing. Section 4002(a) of the Cures Act amended section 3001(c)(5) of the PHSA by adding section 3001(c)(5)(D) of the PHSA, which requires the Secretary, through notice and comment rulemaking, to require conditions of certification and maintenance of certification for the Certification Program. Specifically, the health IT developers or entities with technology certified under the Certification Program must, in order to maintain such certification status, adhere to certain conditions and maintenance of certification requirements concerning information blocking; assurances regarding appropriate exchange, access, and use of electronic health information; communications regarding health IT; application programming interfaces (APIs); real world testing; attestations regarding certain conditions and maintenance of certification requirements; and submission of reporting criteria under the EHR Reporting Program in accordance with section 3009A(b) of the PHSA. a. Regulatory History The Secretary issued an interim final rule with request for comments on January 13, 2010, riteria under the EHR Reporting Program in accordance with section 3009A(b) of the PHSA. a. Regulatory History The Secretary issued an interim final rule with request for comments on January 13, 2010, ‘‘Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology’’ (75 FR 2014), which adopted an initial set of standards, implementation specifications, and certification criteria. On March 10, 2010, the Secretary issued a proposed rule, ‘‘Proposed Establishment of Certification Programs for Health Information Technology’’ (75 FR 11328), that proposed both temporary and permanent certification programs for the purposes of testing and certifying health IT. A final rule establishing the temporary certification program was published on June 24, 2010, ‘‘Establishment of the Temporary Certification Program for Health Information Technology’’ (75 FR 36158), and a final rule establishing the permanent certification program was published on January 7, 2011, ‘‘Establishment of the Permanent Certification Program for Health Information Technology’’ (76 FR 1262). We have engaged in multiple rulemakings ertification program was published on January 7, 2011, ‘‘Establishment of the Permanent Certification Program for Health Information Technology’’ (76 FR 1262). We have engaged in multiple rulemakings to update standards, implementation specifications, certification criteria, and the Certification Program, a history of which can be found in the October 16, 2015, final rule ‘‘2015 Edition Health Information (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications’’ (80 FR 62602) (2015 Edition Final Rule). The history can be found at 80 FR 62606. A final rule making corrections and clarifications was published for the 2015 Edition Final Rule on December 11, 2015 (80 FR 76868), to correct preamble and regulatory text errors and clarify requirements of the Common Clinical Data Set (CCDS), the 2015 Edition privacy and security certification framework, and the mandatory disclosures for health IT developers. The 2015 Edition Final Rule established a new edition of certification criteria (‘‘2015 Edition health IT certification criteria’’ or ‘‘2015 Edition’’) and a new 2015 Edition Base EHR definiti lopers. The 2015 Edition Final Rule established a new edition of certification criteria (‘‘2015 Edition health IT certification criteria’’ or ‘‘2015 Edition’’) and a new 2015 Edition Base EHR definition. The 2015 Edition established the minimum capabilities and specified the related minimum standards and implementation specifications that certified EHR technology (CEHRT) would need to include to support the achievement of ‘‘meaningful use’’ by eligible clinicians, eligible hospitals, and critical access hospitals under the Medicare and Medicaid EHR Incentive Programs (EHR Incentive Programs). The Medicare and Medicaid EHR Incentive Programs are now referred to as the Medicare Promoting Interoperability Program and the Merit-based Incentive Payment System (MIPS) Promoting Interoperability performance category.409 The final rule also adopted a proposal to change the Program’s name to the ‘‘ONC Health IT Certification Program’’ from the ONC HIT Certification Program, modified the Certification Program to make it more accessible to other types of health IT beyond EHR technology and for health IT that supports care and practice settings beyond the ambulatory and inpatient settings, and ation Program to make it more accessible to other types of health IT beyond EHR technology and for health IT that supports care and practice settings beyond the ambulatory and inpatient settings, and adopted new and revised Principles of Proper Conduct for ONC–ACBs. After issuing a proposed rule on March 2, 2016, ‘‘ONC Health IT Certification Program: Enhanced Oversight and Accountability’’ (81 FR 11056), we published a final rule by the same title (81 FR 72404) (EOA Final Rule) on October 19, 2016. The EOA Final Rule finalized modifications and new requirements under the Certification Program, including provisions related to our role in the Certification Program. On March 4, 2019, the Secretary published a proposed rule titled, ‘‘21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program’’ (84 FR 7424) (ONC Cures Act Proposed Rule). The proposed rule proposed to implement certain provisions of the Cures Act that would advance interoperability and support the access, exchange, and use of electronic health information. On May 1, 2020, a final rule was published titled, ‘‘21st Century Cures Act: Interoperability, Information Blocking, bility and support the access, exchange, and use of electronic health information. On May 1, 2020, a final rule was published titled, ‘‘21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program’’ (85 FR 25642) (ONC Cures Act Final Rule). The final rule implemented certain provisions of the Cures Act, including Conditions and Maintenance of Certification requirements for health IT developers, the voluntary certification of health IT for use by pediatric health providers, and reasonable and necessary activities that do not constitute information blocking. The final rule also 409 Section 101(b) of the Medicare Access and CHIP Reauthorization Act of 2015 (MACRA) (Pub. L. 114–10, April 16, 2015) sunset the Medicare EHR Incentive Program for Eligible Professionals, set forth at section 1848(o) of the Act. Section 1848(o)(2) of the Act has been incorporated into the MIPS Promoting Interoperability performance category’s requirements via section 1848(q)(2)(B)(iv) of the Act. See the Medicare Program; Merit-Based Incentive Payment System (MIPS) and Alternative Payment Model (APM) Incentive Under the Physician Fee Schedule, and Criteria for P n 1848(q)(2)(B)(iv) of the Act. See the Medicare Program; Merit-Based Incentive Payment System (MIPS) and Alternative Payment Model (APM) Incentive Under the Physician Fee Schedule, and Criteria for Physician- Focused Payment Models (the CY 2017 Quality Payment Program) final rule with comment period (81 FR 77018 and 77019) for more information regarding the sunsetting of the Medicare EHR Incentive Program for Eligible Professionals. The Medicaid EHR Incentive Program sunset in 2021 (84 FR 42592). VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00598 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37133 implemented certain parts of the Cures Act to support patients’ access to their EHI, and the implementation of information blocking policies that support patient electronic access. Additionally, the final rule modified the 2015 Edition health IT certification criteria and Certification Program in other ways to advance interoperability, enhance health IT certification, and reduce burden and costs, as well as improving patie 5 Edition health IT certification criteria and Certification Program in other ways to advance interoperability, enhance health IT certification, and reduce burden and costs, as well as improving patient and health care provider access to EHI and promoting competition. On November 4, 2020, the Secretary published an interim final rule with comment period titled, ‘‘Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID– 19 Public Health Emergency’’ (85 FR 70064) (Cures Act Interim Final Rule). The interim final rule extended certain compliance dates and timeframes adopted in the ONC Cures Act Final Rule to offer the healthcare system additional flexibilities in furnishing services to combat the COVID–19 pandemic, including extending the applicability date for information blocking provisions to April 5, 2021. On April 18, 2023, the Secretary published a proposed rule titled, ‘‘Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing’’ (88 FR 23746) (HTI–1 Proposed Rule). The HTI–1 Proposed Rule proposed to implement the Electronic Health eroperability: Certification Program Updates, Algorithm Transparency, and Information Sharing’’ (88 FR 23746) (HTI–1 Proposed Rule). The HTI–1 Proposed Rule proposed to implement the Electronic Health Record (EHR) Reporting Program provision of the Cures Act by establishing new Conditions and Maintenance of Certification requirements for health IT developers under the Certification Program. The HTI–1 Proposed Rule also proposed to make several updates to certification criteria and implementation specifications recognized by the Certification Program, including revised certification criterion for: ‘‘clinical decision support’’ (CDS), ‘‘patient demographics and observations’’, and ‘‘electronic case reporting.’’ The HTI–1 Proposed Rule also proposed to establish a new baseline version of the United States Core Data for Interoperability (USCDI). Additionally, the HTI–1 Proposed Rule proposed enhancements to support information sharing under the information blocking regulations. On January 9, 2024, the Secretary issued the ‘‘Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing’’ final rule (HTI–1 Final Rule), which 9, 2024, the Secretary issued the ‘‘Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing’’ final rule (HTI–1 Final Rule), which implemented the EHR Reporting Program provision of the 21st Century Cures Act and established new Conditions and Maintenance of Certification requirements for health IT developers under the Certification Program (89 FR 1192). The HTI–1 Final Rule also made several updates to certification criteria and standards recognized by the Certification Program. The Certification Program updates included revised certification criteria for ‘‘decision support interventions,’’ ‘‘patient demographics and observations,’’ and ‘‘electronic case reporting,’’ as well as adopted a new baseline version of the USCDI standard, USCDI Version 3. Additionally, the HTI–1 Final Rule provided enhancements to support information sharing under the information blocking regulations. Through these provisions, we sought to advance interoperability, improve algorithm transparency, and support the access, exchange, and use of EHI. The HTI–1 Final Rule also updated numerous technical standards in the Certification Program advance interoperability, improve algorithm transparency, and support the access, exchange, and use of EHI. The HTI–1 Final Rule also updated numerous technical standards in the Certification Program in additional ways to advance interoperability, enhance health IT certification, and reduce burden and costs for health IT developers and users of health IT. On November 15, 2023, the Secretary issued a proposed rule titled, ‘‘Medicare Program; Contract Year 2025 Policy and Technical Changes to the Medicare Advantage Program, Medicare Prescription Drug Benefit Program, Medicare Cost Plan Program, and Programs of All-Inclusive Care for the Elderly; Health Information Technology Standards and Implementation Specifications’’ (88 FR 78476). This proposed rule proposed to adopt the National Council for Prescription Drug Programs (NCPDP) Real-Time Prescription Benefit standard version 13. On June 17, 2024, the Secretary issued the ‘‘Medicare Program; Medicare Prescription Drug Benefit Program; Health Information Technology Standards and Implementation Specifications’’ final rule (Part D and Health IT Standards Final Rule) (89 FR 51238 through 51265). This final rule adopted the NCPDP Real-Ti ealth Information Technology Standards and Implementation Specifications’’ final rule (Part D and Health IT Standards Final Rule) (89 FR 51238 through 51265). This final rule adopted the NCPDP Real-Time Prescription Benefit standard version 13 in 45 CFR 170.205(c)(1) and incorporated this standard by reference in 45 CFR 170.299(k). In this final rule, CMS also adopted requirements for Part D sponsors to use the standard in in 45 CFR 170.205(c)(1) when implementing an RTBT. On August 4, 2024, the Secretary published a proposed rule titled Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability (89 FR 63498) (HTI–2 Proposed Rule). 4. ONC Health IT Certification Program Updates a. Standards and Implementations Specifications (1) National Technology Transfer and Advancement Act The National Technology Transfer and Advancement Act (NTTAA) of 1995 (15 U.S.C. 3701 et seq.) and the Office of Management and Budget (OMB) Circular A–119 require the use of, wherever practical, technical standards that are developed or adopted by voluntary consensus standards bodies to carry out policy objectives or activities, with certain exce A–119 require the use of, wherever practical, technical standards that are developed or adopted by voluntary consensus standards bodies to carry out policy objectives or activities, with certain exceptions. The NTTAA and OMB Circular A–119 provide exceptions to electing only standards developed or adopted by voluntary consensus bodies, namely when doing so would be inconsistent with applicable law or otherwise impractical. Agencies have the discretion to decline the use of existing voluntary consensus standards if it is determined that such standards are inconsistent with applicable law or otherwise impractical, and instead use a government-unique standard or other standard. In addition to the consideration of voluntary consensus standards, the OMB Circular A–119 recognizes the contributions of standardization activities that take place outside of the voluntary consensus standards process. Therefore, in instances where use of voluntary consensus standards would be inconsistent with applicable law or otherwise impracticable, other standards should be considered that: meet the agency’s regulatory, procurement or program needs; deliver favorable technical and economic outcomes; and a plicable law or otherwise impracticable, other standards should be considered that: meet the agency’s regulatory, procurement or program needs; deliver favorable technical and economic outcomes; and are widely utilized in the marketplace. In this final rule, all of the standards adopted are voluntary consensus standards. (2) Compliance With Adopted Standards and Implementation Specifications In accordance with Office of the Federal Register regulations related to ‘‘incorporation by reference,’’ 1 CFR part 51, which we follow when we adopt proposed standards and implementation specifications in any subsequent final rule, the entire standard or implementation specification document is deemed published in the Federal Register when incorporated by reference therein with the approval of the Director of the Federal Register. Once published, compliance with the standard and VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00599 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37134 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations implementation specification includes the entire U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37134 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations implementation specification includes the entire document unless we specify otherwise. For example, for the HL7 (Fast Healthcare Interoperability Resources) FHIR® Da Vinci—Coverage Requirements Discovery Implementation Guide, Version 2.0.1— STU 2 (CRD IG) adopted in section IX.B.4.b.(6). of the preamble of this final rule, health IT certified to certification criteria referencing this IG would need to demonstrate compliance with all mandatory elements and requirements of the IG unless otherwise specified. If an element of the IG is optional or permissive in any way, it would remain that way for testing and certification unless we specified otherwise in regulation. In such cases, the regulatory text would supersede the permissiveness of the IG. (3) ‘‘Reasonably Available’’ to Interested Parties The Office of the Federal Register has established requirements for materials (for example, standards and implementation specifications) that agencies propose to incorporate by reference in the Code of Federal Regulations (79 FR 66267; 1 CFR 51 lished requirements for materials (for example, standards and implementation specifications) that agencies propose to incorporate by reference in the Code of Federal Regulations (79 FR 66267; 1 CFR 51.5(b)). To comply with these requirements, in section XI.B.4.b.(8). (‘‘Incorporation by Reference’’) of the preamble of this final rule, we provide summaries of, and uniform resource locators (URLs) to, the standards and implementation specifications we are adopting and subsequently incorporate by reference in the Code of Federal Regulations. To note, we also provide relevant information about these standards and implementation specifications throughout the relevant sections of the final rule. b. New and Revised Standards and Certification Criteria (1) Minimum Standards Code Sets Updates In the final rule titled ‘‘Health Information Technology: Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions to the Permanent Certification Program for Health Information Technology’’ (77 FR 54163) we discussed and revised our policy for adopting newer versions of minimum standards code sets, noting that this approach im ent Certification Program for Health Information Technology’’ (77 FR 54163) we discussed and revised our policy for adopting newer versions of minimum standards code sets, noting that this approach improves interoperability while creating little additional burden through the inclusion of new code sets (see 45 CFR 170.555 and 77 FR 54268). In the 2015 Edition Final Rule we made additional updates to code sets subject to this policy (80 FR 62612). As we stated in the HTI–1 Final Rule, when determining whether to propose newer versions of minimum standards code sets, we consider the impact on interoperability and whether a newer version would require substantive effort for developers of certified health IT to implement (89 FR 1224). If adopted, newer versions of minimum standards code sets serve as the baseline for certification and developers of certified health IT may use newer versions of these adopted standards on a voluntary basis. We reiterate that while minimum standard code sets update frequently, perhaps several times in a single year, these updates are confined to concepts within the code system, not substantive changes to the standards themselves. In this final rule, we are pdate frequently, perhaps several times in a single year, these updates are confined to concepts within the code system, not substantive changes to the standards themselves. In this final rule, we are only finalizing proposals in the HTI–2 Proposed Rule for minimum standard code sets relevant to medications in 45 CFR170.207(d), as these standards are referenced in two of the certification criteria in this final rule: the updated ‘‘electronic prescribing’’ criterion in 45 CFR 170.315(b)(3) and the new ‘‘real- time prescription benefit’’ criterion in 45 CFR 170.315(b)(4). (2) Medications In the HTI–2 Proposed Rule, we proposed to revise the citations in 45 CFR 170.207(d) to improve organization of this section (89 FR 63527). Specifically, we proposed to revise 45 CFR 170.207(d)(1) to list standards for clinical drugs and to reference multiple releases of RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine. We proposed in 45 CFR 170.207(d)(1)(ii) to reference RxNorm, December 4, 2023, Full Monthly Release and incorporate it by reference in 45 CFR 170.299(r). We proposed to move the standard adopted in 45 CFR 170.207(d)(1), R 170.207(d)(1)(ii) to reference RxNorm, December 4, 2023, Full Monthly Release and incorporate it by reference in 45 CFR 170.299(r). We proposed to move the standard adopted in 45 CFR 170.207(d)(1), RxNorm, July 5, 2022, Release, to 45 CFR 170.207(d)(1)(i), and that the adoption of this standard would expire on January 1, 2028. We proposed to move the standard adopted in 45 CFR 170.207(d)(3), RxNorm, September 8, 2015, Release, to 45 CFR 170.207(d)(1)(iii) and proposed that the adoption of this standard would expire on January 1, 2026. Finally, we proposed to move National Drug Codes, currently included via cross-reference in 45 CFR 170.207(d)(4), to 45 CFR 170.207(d)(2). We noted that 45 CFR 170.207(d)(2) was reserved at the time of the proposed rule. We also proposed to reserve 45 CFR 170.207(d)(3) and remove 45 CFR 170.207(d)(4). The following is a summary of the comments we received on the HTI–2 Proposed Rule and our responses: Comment: We did not receive any public comments specific to the proposed updates to the code sets in 45 CFR 170.207(d) and reorganization of this section. Commenters generally supported our proposals to update minimum code sets. Response: We thank comme fic to the proposed updates to the code sets in 45 CFR 170.207(d) and reorganization of this section. Commenters generally supported our proposals to update minimum code sets. Response: We thank commenters for their support. For a discussion of public comments on our proposals referencing the code sets in 45 CFR 170.207(d) as part of the ‘‘electronic prescribing’’ criterion in 45 CFR 170.315(b)(3) and the ‘‘real time prescription benefit’’ criterion in 45 CFR 170.315(b)(4), we refer readers to sections XI.B.4.b.(3) and XI.B.4.b.(4) of the preamble of this final rule, respectively. After consideration of the public comments, we are finalizing the adoption of the proposed version of RxNorm as RxNorm, December 4, 2023, Full Update Release, and incorporating it by reference in 45 CFR 170.299(r). We are also finalizing the proposed reorganization of 45 CFR 170.207(d), with modification. To improve the organization of the regulation text, we are finalizing the adoption of the most recent version of RxNorm in 45 CFR 170.207(d)(1)(i) (December 4, 2023 release), and renumbering the versions with prior release dates to be in 45 CFR 170.207(d)(1), at (ii) (July 5, 2022 release) and (iii) (Sep sion of RxNorm in 45 CFR 170.207(d)(1)(i) (December 4, 2023 release), and renumbering the versions with prior release dates to be in 45 CFR 170.207(d)(1), at (ii) (July 5, 2022 release) and (iii) (September 8, 2015 release). We are not finalizing the expiration dates that we proposed in the HTI–2 Proposed Rule, specifically, an expiration date of January 1, 2028, for the RxNorm July 5, 2022 release proposed in 45 CFR 170.207(d)(1)(i), and an expiration date of January 1, 2026, for the RxNorm September 8, 2015 release proposed in 45 CFR 170.207(d)(1)(iii). As RxNorm is identified as a minimum standard code set, any release of RxNorm that we adopt in regulation serves as the baseline for certification. Under our policy in 45 CFR 170.555, developers of certified health IT may use newer versions of these adopted standards on a voluntary basis. Given the flexibility available for use of the minimum standard code sets, we believe finalizing expiration dates for certain releases of RxNorm may lead to confusion as we have finalized the use of expiration dates in other instances where we are seeking to ensure health IT developers utilize a new standard beginning on a certain date. However, lead to confusion as we have finalized the use of expiration dates in other instances where we are seeking to ensure health IT developers utilize a new standard beginning on a certain date. However, as stated, under our policy for minimum standards code sets in 45 CFR 170.555, health IT VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00600 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37135 developers may voluntarily move to updated RxNorm releases. (3) Revised Electronic Prescribing Certification Criterion In the HTI–2 Proposed Rule, we proposed to update the ‘‘electronic prescribing’’ certification criterion in 45 CFR 170.315(b)(3) (89 FR 63524). The proposed updates included updating the core standard for electronic prescribing to NCPDP SCRIPT standard version 2023011,410 which was cross-referenced in 45 CFR 170.205(b)(2) in the proposed text in 45 CFR 170.315(b)(3)(ii)(A). We also proposed revisions to the transactions within the SCRIPT standard that would be required for the updated certification criterion and pro 2) in the proposed text in 45 CFR 170.315(b)(3)(ii)(A). We also proposed revisions to the transactions within the SCRIPT standard that would be required for the updated certification criterion and proposed to remove a number of transactions that are currently identified as optional for the criterion. Finally, we proposed to remove 45 CFR 170.315(b)(3)(i) from the CFR upon the effective date of this rule and reserve it as this version of the certification criterion is no longer valid for use in the Certification Program. (a) Electronic Prescribing Standard In the Part D and Health IT Standards Final Rule, which appeared in the Federal Register on June 17, 2024 (89 FR 51238 through 51265), we adopted NCPDP SCRIPT standard version 2023011 in 45 CFR 170.205(b)(2). We also finalized an expiration date for NCPDP SCRIPT standard version 2017071 of January 1, 2028, in 45 CFR 170.205(b)(1), which reflected a delay of one year from the expiration date we had proposed (88 FR 78501). We also finalized the removal of the NCPDP SCRIPT standard version 10.6, which was located in 45 CFR 170.205(b)(2) (89 FR 51258 and 51259). The finalization of these policies in the Part D and Health IT Standards ized the removal of the NCPDP SCRIPT standard version 10.6, which was located in 45 CFR 170.205(b)(2) (89 FR 51258 and 51259). The finalization of these policies in the Part D and Health IT Standards Final Rule, and CMS’ finalization of cross references to 45 CFR 170.205(b) in their requirements for the Part D Program, reflects a unified approach to aligning standards adoption across HHS programs that impact a common set of participants (88 FR 78486 through 78494). In the HTI–2 Proposed Rule (89 FR 63524), we noted that we previously proposed to adopt NCPDP SCRIPT standard version 2022011 and made other proposals in the ‘‘Medicare Program; Contract Year 2024 Policy and Technical Changes to the Medicare Advantage Program, Medicare Prescription Drug Benefit Program, Medicare Cost Plan Program, Medicare Parts A, B, C, and D Overpayment 410 See https://standards.ncpdp.org/Access-to- Standards.aspx. Provisions of the Affordable Care Act and Programs of All-Inclusive Care for the Elderly; Health Information Technology Standards and Implementation Specifications’’ proposed rule (2024 Part C/D Proposed Rule), which appeared in the Federal Register on December 27, 2022 (87 FR 79555). Howeve alth Information Technology Standards and Implementation Specifications’’ proposed rule (2024 Part C/D Proposed Rule), which appeared in the Federal Register on December 27, 2022 (87 FR 79555). However, we subsequently withdrew these proposals in the ‘‘Medicare Program; Contract Year 2025 Policy and Technical Changes to the Medicare Advantage Program, Medicare Prescription Drug Benefit Program, Medicare Cost Plan Program, and Programs of All-Inclusive Care for the Elderly; Health Information Technology Standards and Implementation Specifications’’ proposed rule (2025 Part C/D Proposed Rule), which appeared in the Federal Register on November 15, 2023 (88 FR 78476), and instead proposed to adopt the NCPDP SCRIPT standard version 2023011 in 45 CFR 170.205(b)(2) (88 FR 78501 through 78502). In the HTI–2 Proposed Rule, we proposed in 45 CFR 170.315(b)(3)(ii)(A) that for the time period up to and including December 31, 2027, a Health IT Module certified to the ‘‘electronic prescribing’’ certification criterion at 45 CFR 170.315(b)(3) must enable a user to perform certain prescription-related electronic transactions in accordance with the standard specified in 45 CFR 170.205(b)(1) (NCPDP tification criterion at 45 CFR 170.315(b)(3) must enable a user to perform certain prescription-related electronic transactions in accordance with the standard specified in 45 CFR 170.205(b)(1) (NCPDP SCRIPT standard version 2017071) or 45 CFR 170.205(b)(2) (NCPDP SCRIPT standard version 2023011) (89 FR 63524). We also proposed that on and after January 1, 2028, a Health IT Module certified to the ‘‘electronic prescribing’’ certification criterion must enable a user to perform the following prescription-related electronic transactions in accordance with only the standard specified in 45 CFR 170.205(b)(2) (where we adopted NCPDP SCRIPT standard version 2023011). We stated that this means that a health IT developer may continue to maintain health IT certification conformance to NCPDP SCRIPT standard version 2017071 (in 45 CFR 170.205(b)(1)) for the time period up to and including December 31, 2027. We noted that on and after January 1, 2028, consistent with our policy in 45 CFR 170.402(b), developers of certified health IT with Health IT Modules certified to the ‘‘electronic prescribing’’ certification criterion would need to update those Health IT Modules to the standard in 45 CFR 1 ), developers of certified health IT with Health IT Modules certified to the ‘‘electronic prescribing’’ certification criterion would need to update those Health IT Modules to the standard in 45 CFR 170.205(b)(2) and provide them to customers. This is consistent with the date of January 1, 2028, that we finalized for the expiration of NCPDP SCRIPT standard version 2017071 in 45 CFR 170.205(b)(1) in the Part D and Health IT Standards Final Rule (89 FR 51259). The following is a summary of the comments we received on the HTI–2 Proposed Rule and our responses: Comment: Commenters supported our proposal to require the use of NCPDP SCRIPT standard version 2023011 in an updated version of the ‘‘electronic prescribing’’ criterion. Commenters stated that this version of the standard includes several new elements that will enhance the usability of the standard and add important functionality. Other commenters stated this update will enhance interoperability, improve patient safety and streamline prescription processes. A commenter highlighted features of this version of the standard that will be beneficial for pediatric populations. Response: We thank the commenters for their support. We ag e prescription processes. A commenter highlighted features of this version of the standard that will be beneficial for pediatric populations. Response: We thank the commenters for their support. We agree that the proposed version of the NCPDP SCRIPT standard includes important enhancements that will improve the interoperability of electronic prescription information. Comment: Many commenters supported the proposal that health IT developers may maintain health IT certification conformance with the current version of NCPDP SCRIPT standard version 2017071 for the time period up to and including December 31, 2027, and must, by January 1, 2028, use NCPDP SCRIPT standard version 2023011. Commenters appreciated the alignment of this date with the requirement for Medicare Part D plan sponsors to implement the NCPDP SCRIPT standard version 2023011 by January 1, 2028, stating that this alignment will improve the functionality and overall interoperability of clinicians’ electronic prescribing systems. Commenters also supported the proposal to allow health IT developers time to update their systems while maintaining certification for the current version of the SCRIPT standard. Another commente tems. Commenters also supported the proposal to allow health IT developers time to update their systems while maintaining certification for the current version of the SCRIPT standard. Another commenter stated that the proposed timeline would ensure developers and clinicians can adequately plan and prepare for these updates. Response: We thank commenters for their support. We believe that the proposed timeline requiring health IT developers to update Health IT Modules certified to the ‘‘electronic prescribing criterion to NCPDP SCRIPT standard version 2023011 by January 1, 2028, will provide a reasonable amount of time for health IT developers to develop updated products and provide these products to customers. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00601 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37136 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations Comment: A commenter (b) Proposed Transactions recommended that ASTP/ONC extend the timeline by one year and require use of the NCPDP SCRIPT standard version 2023011 by January 1, 2029. The commenter suggested A commenter (b) Proposed Transactions recommended that ASTP/ONC extend the timeline by one year and require use of the NCPDP SCRIPT standard version 2023011 by January 1, 2029. The commenter suggested that while the standards are fully developed, the standards are not yet integrated into health IT vendor systems. The commenter stated the transition to the updated standard will take time, and health plan IT resources are invested in working toward the launch of CMS APIs in January 2027, which do not incorporate prescription drug requirements. Response: We disagree with the commenter that the deadline for updating Health IT Modules to the updated version of the ‘‘electronic prescribing’’ criterion should be extended for an additional year. In the Part D and Health IT Standards Final Rule, we adopted NCPDP SCRIPT standard version 2023011 in 45 CFR 170.205(b)(2). We also finalized an expiration date for NCPDP SCRIPT standard version 2017071 of January 1, 2028, in 45 CFR 170.205(b)(1), which reflected a delay of one year from the expiration date we had proposed (88 FR 78501). We believe this period will provide health IT developers with sufficient time for development and implementation h reflected a delay of one year from the expiration date we had proposed (88 FR 78501). We believe this period will provide health IT developers with sufficient time for development and implementation of an updated version of an existing criterion. We further clarify that the proposals in this final rule will affect health IT developers with Health IT Modules certified to the ‘‘electronic prescribing’’ criterion under the Certification Program. After consideration of the public comments, we are finalizing our proposals with modifications. Specifically, we are revising and reorganizing 45 CFR 170.315(b)(3)(ii)(A) to increase clarity around the timelines for use of standards in the ‘‘electronic prescribing’’ criterion. We are finalizing in 45 CFR 170.315(b)(3)(ii)(A)(1) that a Health IT Module certified to the ‘‘electronic prescribing’’ certification criterion at 45 CFR 170.315(b)(3) must enable a user to perform specified prescription-related electronic transactions in accordance with the standard specified in 45 CFR 170.205(b)(1) (NCPDP SCRIPT standard version 2017071) or 45 CFR 170.205(b)(2) (NCPDP SCRIPT standard version 2023011) for the time period up to and including December 3 he standard specified in 45 CFR 170.205(b)(1) (NCPDP SCRIPT standard version 2017071) or 45 CFR 170.205(b)(2) (NCPDP SCRIPT standard version 2023011) for the time period up to and including December 31, 2027. We are also finalizing in 45 CFR 170.315(b)(3)(ii)(A)(2) that a Health IT Module certified to the ‘‘electronic prescribing’’ criterion may only use the standard specified in 45 CFR 170.205(b)(2) on and after January 1, 2028. In the HTI–2 Proposed Rule (89 FR 63524 through 63526), we proposed the following updates and changes to the transactions identified for the ‘‘electronic prescribing’’ criterion in 45 CFR 170.315(b)(3)(ii). (i) New Prescriptions (NewRx) (45 CFR 170.315(b)(3)(ii)(A)(3)(i)) We proposed in 45 CFR 170.315(b)(3)(ii)(A)(1) to revise the name used for the NewRx transaction in our regulations from ‘‘Create New Prescriptions (NewRx)’’ to ‘‘New Prescriptions (NewRx).’’ We proposed this change to align with updated terminology used by NCPDP within the SCRIPT standard. The following is a summary of the comments we received and our responses: Comment: Commenters supported the revision of the name used for the NewRx transactions from ‘‘Create New Prescriptions (NewRx)’’ e following is a summary of the comments we received and our responses: Comment: Commenters supported the revision of the name used for the NewRx transactions from ‘‘Create New Prescriptions (NewRx)’’ to ‘‘New Prescriptions (NewRx)’’ to align with the updated terminology used in NCPDP SCRIPT standard version 2023011. Response: We thank commenters for their support. After consideration of the comments and due to the reorganization we are finalizing of 45 CFR 170.315(b)(3)(ii)(A), we are finalizing our proposal to update the name of the transaction to ‘‘New Prescriptions (NewRx)’’ in 45 CFR 170.315(b)(3)(ii)(A)(3)(i). (ii) Request and Receive Medication History (45 CFR 170.315(b)(3)(ii)(A)(3)(vi)) We proposed to remove the request and receive medication history transactions (RxHistoryRequest, RxHistoryResponse) as a requirement for the ‘‘electronic prescribing’’ certification criterion in 45 CFR 170.315(b)(3)(ii)(A)(6) and reserve this section. In the ONC Cures Act Final Rule, ONC finalized the request and receive medication history transactions (RxHistoryRequest, RxHistoryResponse) in the ‘‘electronic prescribing’’ certification criterion (85 FR 25682). Since the final rule was publ zed the request and receive medication history transactions (RxHistoryRequest, RxHistoryResponse) in the ‘‘electronic prescribing’’ certification criterion (85 FR 25682). Since the final rule was published, health IT developers and health care providers have described several challenges meeting this requirement, including development burden; lower than expected adoption and use; and duplicative, overlapping, and sometimes contradictory data from multiple sources. Due in part to these challenges and market forces that have prevented some developers from adopting this functionality natively, developers have had to rely on third- party applications to achieve certification, and in some cases, are unable to achieve certification for electronic prescribing altogether. As such, in the HTI–2 Proposed Rule (89 FR 63525), we proposed these transactions would no longer be required for certification to the ‘‘electronic prescribing’’ criterion in 45 CFR 170.315(b)(3)(ii)(A)(6). We also proposed to reserve 45 CFR 170.315(b)(3)(ii)(A)(6). In the HTI–2 Proposed Rule (89 FR 63525), we encouraged developers to continue to support these transactions where possible and to follow industry efforts to a reserve 45 CFR 170.315(b)(3)(ii)(A)(6). In the HTI–2 Proposed Rule (89 FR 63525), we encouraged developers to continue to support these transactions where possible and to follow industry efforts to advance the exchange of patient medication histories through various means such as health information exchanges, health information networks, and prescription drug monitoring programs. We further noted that (if our proposals were finalized) health IT developers would not be required to demonstrate compliance with these transactions in order for a Health IT Module to be certified to the updated version of the ‘‘electronic prescribing’’ criterion, but that CMS still requires use of these transactions when appropriate for electronic exchange of prescription- related information by Part D sponsors and prescribers and dispensers of Part D drugs for Part D eligible individuals (88 FR 78486). In other words, despite not needing to demonstrate technical conformance for certification, health IT developers would still need to support these transactions for customers who utilize these transactions in order to exchange electronic Part D medication history information among Part D sponsors and presc lopers would still need to support these transactions for customers who utilize these transactions in order to exchange electronic Part D medication history information among Part D sponsors and prescribers and dispensers of Part D drugs for Part D eligible individuals in compliance with requirements at 42 CFR 423.160(b)(1)(i)(U). The following is a summary of the comments we received and our responses: Comment: A commenter supported the proposal to remove the request and receive medication history transactions (RxHistoryRequest, RxHistoryResponse) as a requirement for the ‘‘electronic prescribing’’ certification criterion and reserve this section. Response: We thank commenters for their support. Comment: Several commenters opposed the removal of request and receive medication history transactions (RxHistoryRequest, RxHistoryResponse) from the electronic prescribing certification criterion. A commenter noted that medication history is a critical piece of information for episodic VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00602 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90 e Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00602 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37137 treatment as well as identifying lapses or gaps in care with medication changes over a period of time. Several commenters noted the proposal seems potentially harmful to patient safety as medication history queries are crucial for safe electronic prescribing and medication reconciliation. A commenter acknowledged the existing challenges with adoption and implementation of the request and receive medication history transactions, but believed the transaction should not be removed if it will support the ultimate goal of achieving seamless access to this data in the EHR for clinicians. A commenter disagreed that the rationale that some developers were unable to achieve certification for electronic prescribing was sufficient for removal of the transactions, stating that health IT certification criteria should be determined based on impact to patient care rather than burden for health IT developers. Other commenters suggested s emoval of the transactions, stating that health IT certification criteria should be determined based on impact to patient care rather than burden for health IT developers. Other commenters suggested separating this transaction into a distinct criterion to address developer concerns and providing additional support or guidance to vendors struggling with this implementation, rather than removing the requirement entirely. Response: We appreciate commenters’ feedback, and we agree that the ability for providers to easily obtain medication histories is crucial to patient care including for patient safety and medication reconciliation. We appreciate commenters’ concerns about the rationale we included as part of the proposal. While we believe it is important to consider the burden on health IT developers and challenges that developers may experience in meeting Certification Program requirements, we seek to balance these concerns with the potential for use of certified health IT to improve patient care and advance the exchange of information across participants in the health care system. We agree with commenters that there is significant value to patients and health care providers of cont tient care and advance the exchange of information across participants in the health care system. We agree with commenters that there is significant value to patients and health care providers of continuing to require support for medication history, which must be weighed against the issues identified in the proposed rule. Regarding the recommendation to adopt a separate criterion focused on this transaction, we note that we did not propose such a criterion, and believe that developing multiple certification criteria which require conformance with the NCPDP SCRIPT standard could increase administrative complexity for health IT developers and users of certified health IT. After consideration of the public comments received, we are not finalizing our proposal to remove the request and receive medication history transactions (RxHistoryRequest and RxHistoryResponse) as required for the ‘‘electronic prescribing’’ criterion. Due to the reorganization we are finalizing of 45 CFR 170.315(b)(3)(ii)(A), we are retaining the transactions for RxHistoryRequest and RxHistoryResponse in 45 CFR 170.315(b)(3)(ii)(A)(3)(vi). We recognize the need for Health IT Modules to support capabilities related ii)(A), we are retaining the transactions for RxHistoryRequest and RxHistoryResponse in 45 CFR 170.315(b)(3)(ii)(A)(3)(vi). We recognize the need for Health IT Modules to support capabilities related to medication history, and we are keeping these transactions in the Certification Program at this time, as supported by commenters. We will continue to monitor the request and receive medication history transactions for ongoing use, interest and value. (iii) Electronic Prior Authorization Transactions (45 CFR 170.315(b)(3)(ii)(A)(3)(x)) In the HTI–2 Proposed Rule (89 FR 63525), we proposed to require support for the following transactions for electronic prior authorization as part of the ‘‘electronic prescribing’’ criterion, at the time a health IT developer presents a Health IT Module for certification using the standard in 45 CFR 170.205(b)(2) (where we adopted NCPDP SCRIPT standard version 2023011): PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, PACancelResponse, and PANotification. In the ONC Cures Act Final Rule, ONC adopted these transactions in 45 CFR 170.315(b)(3)(ii)(B)(9) as optional for the ‘‘electronic p ealResponse, PACancelRequest, PACancelResponse, and PANotification. In the ONC Cures Act Final Rule, ONC adopted these transactions in 45 CFR 170.315(b)(3)(ii)(B)(9) as optional for the ‘‘electronic prescribing’’ criterion (85 FR 25678). We stated that we adopted these transactions to support alignment with the ‘‘Medicare Program; Secure Electronic Prior Authorization for Medicare Part D’’ proposed rule (84 FR 28450), in which CMS proposed to require Part D sponsors to support NCPDP SCRIPT standard version 2017071 for four electronic prior authorization transactions, and proposed that prescribers would be required to use that standard when performing electronic prior authorization transactions for Part D covered drugs they wish to prescribe to Part D eligible individuals (85 FR 25685). CMS subsequently finalized in the ‘‘Medicare Program; Secure Electronic Prior Authorization for Medicare Part D’’ final rule in 42 CFR 423.160(b)(8)(ii) that beginning January 1, 2022, Part D sponsors and prescribers must use the NCPDP SCRIPT standard version 201701 (85 FR 86832). The ONC Cures Act Final Rule allowed health IT developers seeking certification to support these transactions through opt d prescribers must use the NCPDP SCRIPT standard version 201701 (85 FR 86832). The ONC Cures Act Final Rule allowed health IT developers seeking certification to support these transactions through optional testing but did not require developers to certify health IT to these transactions. In the HTI–2 Proposed Rule (89 FR 63525), we stated we received feedback from the public in support of requiring these transactions, most recently in response to the ‘‘Request for Information: Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria’’ (Electronic Prior Authorization RFI), which appeared in the Federal Register on January 24, 2022 (87 FR 3475). Commenters stated that requiring these transactions in the certification criterion would help to advance interoperability and reduce administrative burden around prior authorization processes for medications. We agreed with this input, and in the HTI–2 Proposed Rule we proposed to remove PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, and PACancelResponse in 45 CFR 170.315(b)(3)(ii)(B)(9) as optional, and to require these transacti est, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, and PACancelResponse in 45 CFR 170.315(b)(3)(ii)(B)(9) as optional, and to require these transactions in 45 CFR 170.315(b)(3)(ii)(A)(10) for the ‘‘electronic prescribing’’ certification criterion at the time a health IT developer presents a Health IT Module for certification using NCPDP SCRIPT standard version 2023011. ONC also charged the HITAC to establish a Task Force in order to provide input and recommendations in response to the Electronic Prior Authorization RFI; the Task Force’s recommendations were approved and submitted to ONC on March 10, 2022.411 In the HTI–2 Proposed Rule (89 FR 63525), we stated that if finalized, the proposals would implement the Task Force’s recommendation to update these prior authorization transactions from ‘‘optional’’ in the current version of the ‘‘electronic prescribing’’ certification criterion to ‘‘mandatory,’’ to better support electronic prior authorization processes for drugs covered under a prescription benefit. We also proposed to adopt the PANotification transaction in 45 CFR 170.315(b)(3)(ii)(A)(10) as a required transaction for the ‘ authorization processes for drugs covered under a prescription benefit. We also proposed to adopt the PANotification transaction in 45 CFR 170.315(b)(3)(ii)(A)(10) as a required transaction for the ‘‘electronic prescribing’’ criterion to further support the exchange of electronic prior authorization information. We noted that PANotification is a new transaction introduced since NCPDP SCRIPT standard version 2017071. The PANotification transaction is used to alert the pharmacist or prescriber when 411 https://www.healthit.gov/sites/default/files/ page/2022-03/2022-03-10_ePA_RFI_ Recommendations_Report_Signed_508.pdf. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00603 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37138 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations a prior authorization has been requested or when a prior authorization determination has been received. The PANotification transaction is intended to improve electronic communication between prescribers and pharmacists, and to reduce duplicate submissions of prior authorization requests to payers. Notif The PANotification transaction is intended to improve electronic communication between prescribers and pharmacists, and to reduce duplicate submissions of prior authorization requests to payers. Notification may occur via a NewRx, RxChange or RxRenewal transaction, or as a standalone PANotification. We stated that we believe that requiring the PANotification transaction is an important complement to the other proposals related to electronic prior authorization described above. The following is a summary of the comments we received and our responses: Comment: Many commenters supported the proposal to require support for the electronic prior authorization transactions as part of the ‘‘electronic prescribing’’ criterion. A commenter stated that requiring prior authorization transactions as part of the criterion would help advance interoperability and reduce administrative burden associated with medication prior authorization processes and improve access to systems enabling electronic prior authorization. Other commenters stated that requiring these transactions would help ensure pharmacy data systems communicate consistently with certified health IT modules, thereby mitigating the nee r authorization. Other commenters stated that requiring these transactions would help ensure pharmacy data systems communicate consistently with certified health IT modules, thereby mitigating the need to build different prior authorization processes for different certified health IT systems. Another commenter believed that greater use of electronic prior authorization would address transparency and affordability gaps in the healthcare ecosystem. Response: We appreciate commenters’ support for our proposal to require electronic prior authorization transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, PACancelResponse, and PANotification) as part of the ‘‘electronic prescribing’’ criterion. We agree with commenters that electronic prior authorization is an important capability for reducing the administrative burden associated with prior authorization processes for medications. We also agree that adopting these transactions will support interoperability between prescriber and payer systems and can lead to more efficient investments in technical infrastructure to support electronic exchange of prior authoriz transactions will support interoperability between prescriber and payer systems and can lead to more efficient investments in technical infrastructure to support electronic exchange of prior authorization information. Comment: A commenter noted it was unclear if the electronic prior authorization transactions have been tested in the real world to verify that they will achieve the intended goal of automating prior authorizations without also causing serious consequences, such as increasing prescriber burden or driving further consolidation in the EHR market toward a few large developers. The commenter noted that real world testing is critical to ensuring that health IT is effective and interoperable for the physicians, clinical staff, and other end- users that rely on EHRs. Response: We appreciate commenters’ interest in testing of these electronic prior authorization transactions and agree that ongoing testing and evaluation is important to improving standards. We note that the Council for Affordable Quality Healthcare found that in a survey of medical providers that 38 percent of respondents used the NCPDP standard to conduct electronic prior authorization transactions in 2023, a l for Affordable Quality Healthcare found that in a survey of medical providers that 38 percent of respondents used the NCPDP standard to conduct electronic prior authorization transactions in 2023, an increase of eight percentage points from 2022,412 indicating that the electronic prior authorization transactions specified in the NCPDP SCRIPT standard are being used in practice. ASTP/ONC will continue to work with implementers and the standards development community to evaluate findings from the implementation of these transactions. We also note that CMS finalized a requirement that Part D plan sponsors support certain electronic prior authorization transactions in the NCPDP SCRIPT standard version 2017071 in the ‘‘Medicare Program; Secure Electronic Prior Authorization for Medicare Part D’’ which appeared in the Federal Register on December 31, 2020 (85 FR 86824). Finally, we acknowledge the commenters’ concerns about provider burden that may be associated with adopting workflows based on these transactions and consolidation in the EHR market that may result from adding regulatory requirements to the ‘‘electronic prescribing’’ criterion. At this time, we believe the potential val ed on these transactions and consolidation in the EHR market that may result from adding regulatory requirements to the ‘‘electronic prescribing’’ criterion. At this time, we believe the potential value of advancing electronic prior authorization and decreasing the administrative burden associated with prior authorization processes outweighs these concerns. However, we will continue to monitor public feedback and available data sources to track the impact of implementation of these transactions. Comment: A commenter stated that requiring electronic prior authorization transactions was premature without sufficient assurances that the payer 412 See https://www.caqh.org/hubfs/ Issue%20Briefs/CAQH_Insights_NCPDP_SCRIPT_ Issue_Brief.pdf. community will be ready to support the same standards and enable end-to-end electronic prior authorization for prescriptions. A commenter suggested payers should be the first to adopt electronic prior authorization standards in order to set the standard effectively. Another commenter recognized there are already many payers supporting these transactions, but did not believe that implementing electronic prior authorization would provide value until there ectively. Another commenter recognized there are already many payers supporting these transactions, but did not believe that implementing electronic prior authorization would provide value until there is a specific criterion under the Certification Program defining standards for payer adherence. A commenter stated that requirements for payers should mandate the use of codified question sets as part of electronic prior authorization, ensuring that these solutions are not simply digitizing a paper-based process but effectively streamlining it. A commenter suggested ASTP/ONC create a separate criterion for electronic prior authorization functionality. Response: We appreciate the importance of ensuring that all entities participating in exchange of electronic prior authorization information are using common standards. We note that CMS finalized a requirement that Part D plan sponsors support certain electronic prior authorization transactions in the NCPDP SCRIPT standard version 2017071 in the ‘‘Medicare Program; Secure Electronic Prior Authorization for Medicare Part D’’ which appeared in the Federal Register on December 31, 2020. CMS subsequently updated the version of the NCPDP SCRI the ‘‘Medicare Program; Secure Electronic Prior Authorization for Medicare Part D’’ which appeared in the Federal Register on December 31, 2020. CMS subsequently updated the version of the NCPDP SCRIPT standard required for electronic prescribing and electronic prior authorization to NCPDP SCRIPT standard version 2023011 by January 1, 2028. Thus, requirements for Part D plan sponsors to support electronic prior authorization transactions were finalized in advance of the requirements for developers of certified health IT that we are finalizing in this rule, and we believe Part D plan sponsors already have experience supporting these transactions. We agree the availability of a certification criterion for health IT used by Part D plan sponsors may have benefits, for instance, increasing conformance with the standard through required testing. However, we also believe that the combination of the current requirement for Part D plan sponsors to support the NCPDP SCRIPT standard in 42 CFR 423.160 and our requirements for health IT developers will effectively enable interoperability between provider and payer systems when conducting electronic prior authorization for medications. Regardin 3.160 and our requirements for health IT developers will effectively enable interoperability between provider and payer systems when conducting electronic prior authorization for medications. Regarding the use of codified question sets, we agree with the commenter that VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00604 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37139 consistent use of question sets by payers, which are supported as part of the electronic prior authorization transactions in the NCPDP SCRIPT standard, could help to further reduce burden for implementers. While requirements for how Part D plan sponsors support electronic prior authorization are out of scope for this rule, we are sharing these comments with the Part D program for consideration. We do not agree with the commenter that we should create a separate criterion to address electronic prior authorization transactions under the NCPDP SCRIPT standard, as we believe consolidating certification requirements for all transactions specified in the NC parate criterion to address electronic prior authorization transactions under the NCPDP SCRIPT standard, as we believe consolidating certification requirements for all transactions specified in the NCPDP SCRIPT standard under a single criterion will minimize burden for health IT developers seeking to support electronic prescribing capabilities within a single Health IT Module. After consideration of public comments, we are finalizing our proposal to require the transactions PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, and PACancelResponse and moving these transactions to 45 CFR 170.315(b)(3)(ii)(A)(3)(x), due to the revisions we are finalizing to reorganize 45 CFR 170.315(b)(3)(ii)(A). We are also finalizing our proposal to remove the above mentioned electronic prior authorization transactions from 45 CFR 170.315(b)(3)(ii)(B)(9), where they are identified as optional. We are also finalizing our proposal to include the PANotification transaction as part of the required electronic prior authorization transactions at 45 CFR 170.315(b)(3)(ii)(A)(3)(x). We are finalizing these transactions as required for the ‘‘ele the PANotification transaction as part of the required electronic prior authorization transactions at 45 CFR 170.315(b)(3)(ii)(A)(3)(x). We are finalizing these transactions as required for the ‘‘electronic prescribing’’ certification criterion at the time a health IT developer presents a Health IT Module for certification using the standard finalized at 45 CFR 170.205(b)(2), where we adopted NCPDP SCRIPT standard version 2023011. (iv) Optional Transactions (NewRxRequest, NewRxResponseDenied, RxFillIndicatorChange, GetMessage, Resupply, DrugAdministration, RxTransferRequest, RxTransferResponse, RxTransferConfirm, Recertification, REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse) (45 CFR 170.315(b)(3)(ii)(B)(1)–(8)) In the HTI–2 Proposed Rule (89 FR 63526), we proposed to remove the transactions in 45 CFR 170.315(b)(3)(ii)(B)(1)–(8) which are currently identified as ‘‘optional’’ for the ‘‘electronic prescribing’’ certification criterion. We proposed to revise 45 CFR 170.315(b)(3)(ii)(B) to include requirements related to the exchange of race and ethnicity information in 45 CFR 170.315(b)(3)(ii)(B)(1)–(4), which is discussed in greater detail later in thi e 45 CFR 170.315(b)(3)(ii)(B) to include requirements related to the exchange of race and ethnicity information in 45 CFR 170.315(b)(3)(ii)(B)(1)–(4), which is discussed in greater detail later in this section. Specifically, we proposed to remove the following transactions in 45 CFR 170.315(b)(3)(ii)(B) upon the effective date of the final rule: • NewRxRequest, NewRxResponseDenied (45 CFR 170.315(b)(3)(ii)(B)(1)) • RxFillIndicatorChange (45 CFR 170.315(b)(3)(ii)(B)(2)) • GetMessage (45 CFR 170.315(b)(3)(ii)(B)(3)) • Resupply (45 CFR 170.315(b)(3)(ii)(B)(4)) • DrugAdministration (45 CFR 170.315(b)(3)(ii)(B)(5)) • RxTransferRequest, RxTransferResponse, RxTransferConfirm (45 CFR 170.315(b)(3)(ii)(B)(6)) • Recertification (45 CFR 170.315(b)(3)(ii)(B)(7)) • REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse (45 CFR 170.315(b)(3)(ii)(B)(8)) For completeness, we noted that 45 CFR 170.315(b)(3)(ii)(B) currently has transactions listed in 45 CFR 170.315(b)(3)(ii)(B)(9) related to electronic prior authorization. However, we proposed in the section above to remove 45 CFR 170.315(b)(3)(ii)(B)(9) and add the electronic prior authorization transactions currently in 45 C related to electronic prior authorization. However, we proposed in the section above to remove 45 CFR 170.315(b)(3)(ii)(B)(9) and add the electronic prior authorization transactions currently in 45 CFR 170.315(b)(3)(ii)(B)(9) as required transactions in 45 CFR 170.315(b)(3)(ii)(A)(10). We noted that in reviewing data from the Certification Program, we found that very few developers have elected to certify to the optional transactions in 45 CFR 170.315(b)(3)(ii)(B)(1)–(9). We stated that we believe that the low rate of certification to these certification criteria indicates that health IT developers do not see a benefit in obtaining optional certification to these criteria. Accordingly, we stated that removing these optional transactions from the program would reduce the complexity and cost of the Certification Program with minimal impact on health IT developers. We further noted that CMS requires use of these transactions when appropriate for electronic exchange of prescriptions and prescription-related information by Part D sponsors and prescribers and dispensers of Part D drugs for Part D eligible individuals. In other words, despite not needing to demonstrate technical conforma rescription-related information by Part D sponsors and prescribers and dispensers of Part D drugs for Part D eligible individuals. In other words, despite not needing to demonstrate technical conformance for certification, developers would still need to support these transactions for customers who utilize these transactions in order to exchange information electronically between prescribers and dispensers of Part D drugs for Part D eligible individuals in compliance with requirements in 42 CFR 423.160(b)(1)(i). We requested comment on our proposal to remove the optional transactions in 45 CFR 170.315(b)(3)(ii)(B)(1)–(8) from the ‘‘electronic prescribing’’ certification criterion. We also stated that alternatively, we considered proposing to require the optional transactions in 45 CFR 170.315(b)(3)(ii)(B)(1)–(8) rather than removing them from the criterion. However, in the HTI–2 Proposed Rule, we did not identify additional reasons to propose to require any of these optional transactions (89 FR 63526). We requested comment on this alternative, including whether commenters believe requiring any of the optional transactions in 45 CFR 170.315(b)(3)(ii)(B)(1)–(8) proposed for removal fr s (89 FR 63526). We requested comment on this alternative, including whether commenters believe requiring any of the optional transactions in 45 CFR 170.315(b)(3)(ii)(B)(1)–(8) proposed for removal from the ‘‘electronic prescribing’’ certification criterion would be important to supporting interoperability between certified Health IT Modules and entities subject to Part D electronic prescribing requirements at 42 CFR 423.160. We referred readers to Table 1A in the HTI–2 Proposed Rule (89 FR 63529) for a comparison of transactions identified in the existing NCPDP SCRIPT standard version 2017071 and the proposed certification criterion based on NCPDP SCRIPT standard version 2023011. The following is a summary of the comments we received and our responses: Comment: Many commenters supported removing the transactions in (45 CFR 170.315(b)(3)(ii)(B)(1)–(8)) identified as optional. Some commenters noted removal would streamline the certification process and VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00605 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37140 Federal Register / Vol. 90, No. 147 / Monday, Au 5 Jkt 265001 PO 00000 Frm 00605 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37140 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations promote consistency across certified health IT modules. Commenters noted RxTransfer transactions are not used by physicians but are instead used to transfer prescriptions between pharmacies. Other commenters stated Resupply, DrugAdministration, and Recertification are communications between a long-term or post-acute care facility and a pharmacy, excluding the prescriber system. Response: We thank commenters for their support. We agree with many of the justifications offered by commenters to remove optional transactions identified as optional, including commenters who indicated that removal would streamline certification processes and promote consistent implementation of Health IT Modules certified to 45 CFR 170.315(b)(3). We further appreciate commenters’ feedback regarding specific transactions that are not useful for physicians. Due to the low rate of certification to these optional transactions among health IT developers, we believe that removing s’ feedback regarding specific transactions that are not useful for physicians. Due to the low rate of certification to these optional transactions among health IT developers, we believe that removing certification for these transactions will have minimal impact on prescribers. Comment: A commenter specifically recommended that the following transactions remain as optional: NewRxRequest, RxFillIndicatorChange, GetMessage and REMS. Response: We appreciate the continued interest in certain optional transactions in 170.315(b)(3)(ii)(B)(1)– (8). However, commenters did not provide, and we have not identified, reasons to retain these specific optional transactions as part of the certification criterion that outweigh the rationale we provided for proposing to remove these optional transactions related to streamlining the Certification Program and reducing regulatory burden. We will continue to evaluate how these capabilities evolve and may consider whether to propose to require these transactions as part of the ‘‘electronic prescribing’’ criterion in the future. After consideration of public comments, we are finalizing our proposal to remove the transactions identified as optional in 45 tions as part of the ‘‘electronic prescribing’’ criterion in the future. After consideration of public comments, we are finalizing our proposal to remove the transactions identified as optional in 45 CFR 170.315(b)(3)(ii)(B)(1)–(8) in order to reduce the complexity and cost of the Certification Program. (c) Additional Proposals (i) Signatura (Sig) (45 CFR 170.315(b)(3)(ii)(D)) accordance with the standard specified in 45 CFR 170.205(b)(2) (NCPDP SCRIPT standard version 2023011), at the time a health IT developer presents a Health IT Module for certification using the NCPDP SCRIPT standard version 2023011. We stated that the Signatura or Sig is the information provided with a prescription to communicate how a prescriber intends for a patient to take a medication. These directions for use are essential for accurate prescription labeling, appropriate patient counseling and education from a pharmacist, and optimal medication use. The NCPDP Structured and Codified Sig Format Implementation Guide,413 which is embedded in the NCPDP SCRIPT standard, is intended to standardize the portion of an electronic prescription containing the directions for use using existing, accepted electronic tra Guide,413 which is embedded in the NCPDP SCRIPT standard, is intended to standardize the portion of an electronic prescription containing the directions for use using existing, accepted electronic transmission standards, such as NCPDP SCRIPT. A ‘‘structured and codified’’ Sig conveys instructions in a consistent manner by mapping these directions to a defined set of elements representing the different components of these directions (for instance, dosing schedules and administration instructions). We stated that the Structured and Codified Sig Format includes 15 segments, each containing distinct fields to capture potential elements of patient instructions. This is intended to facilitate communication between prescribers and pharmacists, to improve the efficiency of prescribing and dispensing activities, and to help reduce the opportunity for errors. The NCPDP Structured and Codified Sig Format Implementation Guide contains the technical specifications and guidance for implementation of a structured and codified Sig. When conducting electronic prescribing, prescribers frequently transmit the Sig Text segment as unstructured free text, which introduces inconsistency and limits reusab a structured and codified Sig. When conducting electronic prescribing, prescribers frequently transmit the Sig Text segment as unstructured free text, which introduces inconsistency and limits reusability of the directions contained in the Sig, with potential impacts on patient safety and clinical outcomes.414 Moreover, when unstructured free text is used, prescribers and pharmacists may have to engage in back-and-forth communication to clarify what is intended in the Sig instructions, increasing burden. In the HTI–2 Proposed Rule (89 FR 63527), we noted that research has shown more than half In 45 CFR 170.315(b)(3)(ii)(D), we proposed that a Health IT Module certified to the ‘‘electronic prescribing’’ criterion must enable a user to enter, receive, and transmit structured and codified prescribing instructions in 413 See https://standards.ncpdp.org/Access-to- Standards.aspx. 414 Schiff, G., Mirica, M.M., Dhavle, A.A., Galanter, W.L., Lambert, B., & Wright, A. (2018). A prescription for enhancing electronic prescribing safety. Health Affairs (Project Hope), 37(11), 1877– 1883. doi:https://doi.org/10.1377/hlthaff.2018.0725. of all Sig directions sent in an ambulatory setting can be r enhancing electronic prescribing safety. Health Affairs (Project Hope), 37(11), 1877– 1883. doi:https://doi.org/10.1377/hlthaff.2018.0725. of all Sig directions sent in an ambulatory setting can be accurately represented by only 25 standardized concepts (for example, the directions ‘‘take 1 tablet by oral route every day’’ and ‘‘Take one (1) tablet by mouth once a day’’ can both be represented as the same Sig concept ‘‘Take 1 tablet by mouth once daily’’), indicating significant opportunities to reduce variation by expressing these directions through the structured and codified Sig format.415 Previously, in the 2015 Edition Final Rule, we did not finalize our proposal to require a Health IT Module certified to the ‘‘electronic prescribing’’ criterion to enable a user to enter, receive, and transmit codified Sig instructions in a structured format, based on commenters’ concerns regarding the readiness of the standard and other issues such as limitations on the length of a Sig within the version of the NCPDP SCRIPT Structured and Codified Sig Format v1.2 available at the time of the proposal (80 FR 62643). We stated that we would reconsider this stance for future rulemaking based o he version of the NCPDP SCRIPT Structured and Codified Sig Format v1.2 available at the time of the proposal (80 FR 62643). We stated that we would reconsider this stance for future rulemaking based on newer versions of the NCPDP SCRIPT Standard Implementation Guide that may provide implementation improvements and finalized an optional certification provision that technology must be able to receive and transmit the reason for the prescription using the indication elements in the SIG segment in 45 CFR 170.315(b)(3)(i) (80 FR 62643). In the ONC Cures Act Final Rule, we also finalized this optional provision in 45 CFR 170.315(b)(3)(ii)(D) (85 FR 25686). Since the 2015 Edition Final Rule, NCPDP has further advanced the structured and codified Sig format. The most recent version available is the NCPDP Structured and Codified Sig Implementation Guide version 2.2. The structured and codified Sig segment within the NCPDP SCRIPT standard has also been modified; changes to the Sig element from NCPDP SCRIPT standard version 2017017 are discussed in the NCPDP SCRIPT standard version 2023011 Implementation Guide.416 As a result of additional improvements made to the structured and codified Sig CPDP SCRIPT standard version 2017017 are discussed in the NCPDP SCRIPT standard version 2023011 Implementation Guide.416 As a result of additional improvements made to the structured and codified Sig format, as well as the additional time that industry has had to grow familiar with this functionality, we stated in the HTI–2 Proposed Rule (89 FR 63527) that 415 Yang, Y., Ward-Charlerie, S., Dhavle, A.A., Rupp, M.T., & Green, J. (2018). Quality and Variability of Patient Directions in Electronic Prescriptions in the Ambulatory Care Setting. Journal of managed care & specialty pharmacy, 24(7), 691–699. https://doi.org/10.18553/ jmcp.2018.17404. 416 See https://standards.ncpdp.org/Access-to- Standards.aspx. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00606 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37141 we believe that it is appropriate to propose in 45 CFR 170.315(b)(3)(ii)(D) to require that a Health IT Module certified to the ‘‘electronic prescribing’’ criterion must enable a user to enter, receive, and transmit it is appropriate to propose in 45 CFR 170.315(b)(3)(ii)(D) to require that a Health IT Module certified to the ‘‘electronic prescribing’’ criterion must enable a user to enter, receive, and transmit structured and codified prescribing instructions in accordance with the standard specified in 45 CFR 170.205(b)(2) (where we adopted NCPDP SCRIPT standard version 2023011), at the time a health IT developer presents a Health IT Module for certification using NCPDP SCRIPT standard version 2023011. We proposed to remove the optional provision that is currently in 45 CFR 170.315(b)(3)(ii)(D). The following is a summary of the comments we received on this proposal and our responses: Comment: Many commenters expressed support for our proposal that a health IT module certified to the ‘‘electronic prescribing’’ criterion must enable a user to enter, receive, and transmit structured and codified prescribing instructions in accordance with NCPDP SCRIPT standard version 2023011. Commenters agreed that communicating how a prescriber intends for a patient to take a medication is critical for delivering safe and effective care, and therefore standardizing prescription directions via a codified and at communicating how a prescriber intends for a patient to take a medication is critical for delivering safe and effective care, and therefore standardizing prescription directions via a codified and structured Sig field has the potential to reduce medication errors and improve patient care. Another commenter noted use of Structured Sig will minimize inefficiencies that result from ambiguous prescriber-pharmacist communications and manual prescription entry into pharmacy management systems, which are prone to errors. Other commenters supported the codified Sig format instructions, stating they are essential for accurate prescription labeling, appropriate patient counseling and education from a pharmacist, increasing interoperability, providing data for research, and optimal medication use. A commenter noted that use of free text Sigs can lead to errors and recommended structuring as much of this information as possible to support safer transitions of care. Response: We thank commenters for their support and agree with comments that use of structured Sigs support safer and more accurate prescriptions than free text Sigs when feasible. Comment: Several commenters supported the propos for their support and agree with comments that use of structured Sigs support safer and more accurate prescriptions than free text Sigs when feasible. Comment: Several commenters supported the proposal but requested clarification. A commenter noted that the statement in the HTI–2 Proposed Rule that the Structured and Codified Sig Format contains 15 segments did not reflect the complexity of the format, which contains approximately 180 distinct elements used to capture patient instructions. Another commenter stated that the Structured and Codified Sig format does not contain segments. Response: We appreciate commenters’ feedback. In the proposed rule we inadvertently referred to groupings of elements containing distinct fields to capture potential elements of patient instructions in the Structured and Codified Sig Format as ‘‘segments.’’ We agree with commenters’ characterization of the Structured and Codified Sig format as including approximately 180 distinct elements, excluding repetitions and extensions, used to capture patient instructions.417 Comment: Commenters stated that the Structured and Codified Sig format is embedded in the required NCPDP SCRIPT standard and recommended itions and extensions, used to capture patient instructions.417 Comment: Commenters stated that the Structured and Codified Sig format is embedded in the required NCPDP SCRIPT standard and recommended that we remove separate reference to the Structured and Codified Sig Format. Response: Regarding the proposal that a Health IT Module enable a user to enter, receive, and transmit structured and codified prescribing instructions in 45 CFR 170.315(b)(3)(ii)(D), we agree with commenters that, as noted in the proposed rule (89 FR 63526), that the Structured and Codified Sig Format is embedded within the NCPDP SCRIPT standard version 2023011. Therefore, we believe that if a Health IT Module implements NCPDP SCRIPT standard version 2023011 in a manner consistent with the requirements in the updated ‘‘electronic prescribing’’ criterion, it will implement the capability to transmit prescriptions according to the Structured and Codified Sig Format. Separately identifying a need to support these capabilities within the criterion would be redundant to requirements to support the NCPDP SCRIPT standard version 2023011. Comment: A commenter supported the proposal but noted that not every prescript apabilities within the criterion would be redundant to requirements to support the NCPDP SCRIPT standard version 2023011. Comment: A commenter supported the proposal but noted that not every prescription Sig can be accurately structured and codified due to the complexity and variability of medication instructions. To address this challenge, the commenter urged ASTP/ ONC to support the inclusion of free text alongside structured and codified prescriptions. Allowing for free text will enable healthcare providers to convey essential nuances and specific patient needs that may not be captured in standardized formats. The commenter stated this approach helps to preserve flexibility while avoiding situations where the use of the same code to represent multiple terms can create significant challenges for the backward translation of prescription Sigs. 417 https://www.ncpdp.org/. Response: We appreciate the commenter’s input. We note that the capacity to transmit free text Sigs continues to be supported in NCPDP SCRIPT standard version 2023011. Nothing in the final ‘‘electronic prescribing’’ criterion would prohibit a prescriber from utilizing Sig free text elements as needed in order to pr supported in NCPDP SCRIPT standard version 2023011. Nothing in the final ‘‘electronic prescribing’’ criterion would prohibit a prescriber from utilizing Sig free text elements as needed in order to provide information about a prescription. Comment: A commenter recommended that ASTP/ONC not finalize the Sig proposal. The commenter stated that the proposed requirement was vague and could be interpreted as requiring all Sigs to be sent in a codified manner, which would impose significant burdens on health IT developers while resulting in diminishing returns for therapies requiring less common, complex instructions that are more easily communicated through free text. The commenter stated that the value of mapping uncommon Sigs decreases significantly, given how infrequently prescribers may issue such patient directions. The commenter also expressed doubt about the value of exchanging structured Sigs when other organizations, such as pharmacy groups, are not subject to requirements to support this standard. The commenter recommended that ASTP/ONC indicate more clearly the expectations regarding the implementation of structured Sigs. Response: We thank the commenter for their input. The rt this standard. The commenter recommended that ASTP/ONC indicate more clearly the expectations regarding the implementation of structured Sigs. Response: We thank the commenter for their input. The intent of our proposed requirement in 45 CFR 170.315(b)(3)(ii)(D) was not to require all Sigs to be sent in a structured and codified format, but rather to enable a user to utilize this functionality in accordance with NCPDP SCRIPT standard version 2023011. As the commenter’s concern relates to the language of the proposed requirement in 45 CFR 170.315(b)(3)(ii)(D), we believe our decision to not finalize this provision addresses the commenter’s concerns regarding the ambiguity of the proposed language. After consideration of public comments, we are not finalizing the provision we proposed in 45 CFR 170.315(b)(3)(ii)(D) that a Health IT Module must enable a user to enter, receive, and transmit structured and codified prescribing instructions in accordance with the standard specified in § 170.205(b)(2) (NCPDP SCRIPT standard version 2023011), at the time a health IT developer presents a Health IT Module for certification using the NCPDP SCRIPT standard version 2023011. We believe that f 70.205(b)(2) (NCPDP SCRIPT standard version 2023011), at the time a health IT developer presents a Health IT Module for certification using the NCPDP SCRIPT standard version 2023011. We believe that finalizing this provision in the text of the regulation is unnecessary as this functionality will be implemented as part of requirements to VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00607 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37142 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations implement the NCPDP SCRIPT standard version 2023011. We did not receive any comments on our proposal to remove the existing optional provision in 45 CFR 170.315(b)(3)(ii)(D) related to the ability to receive and transmit the reason for prescription using the Indication for use element in the SIG segment and we are finalizing to remove this provision and reserve 45 CFR 170.315(b)(3)(ii)(D) for future notice-and-comment rulemaking. (ii) RxNorm and National Drug Codes (NDC) In 45 CFR 170.315(b)(3)(ii)(A) we require that a Health IT Module certified to the ‘‘electronic prescribing’’ crit ) for future notice-and-comment rulemaking. (ii) RxNorm and National Drug Codes (NDC) In 45 CFR 170.315(b)(3)(ii)(A) we require that a Health IT Module certified to the ‘‘electronic prescribing’’ criterion enable a user to perform specified prescription-related electronic transactions in accordance with a specified minimum version of the RxNorm code set for coding medications, among other standards. RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine (RxNorm), is a drug terminology providing a set of normalized medication names and codes based on a collection of commonly used public and commercial vocabularies of drug names and their ingredients. In section III.B.5. of the HTI–2 Proposed Rule (89 FR 63519 and 63520), we proposed to adopt an updated release of RxNorm, specifically, the December 4, 2023, Full Monthly Release, in 45 CFR 170.207(d)(1)(ii). We also proposed to reorganize 45 CFR 170.207(d) to include the versions of RxNorm adopted in 45 CFR 170.207(d)(1), (2), and (3), under 45 CFR 170.207(d)(1). In the HTI–2 Proposed Rule, for the ‘‘electronic prescribing’’ certification criterion, we proposed in 45 CFR 170.3 of RxNorm adopted in 45 CFR 170.207(d)(1), (2), and (3), under 45 CFR 170.207(d)(1). In the HTI–2 Proposed Rule, for the ‘‘electronic prescribing’’ certification criterion, we proposed in 45 CFR 170.315(b)(3)(ii)(A) to remove the existing reference to RxNorm, September 8, 2015, Release in 45 CFR 170.207(d)(3), and require use of at least one of the versions of the standard adopted in 45 CFR 170.207(d)(1) (89 FR 63527). We stated that if finalized, this reference to 45 CFR 170.207(d)(1), where we adopted multiple versions of RxNorm, would permit a health IT developer to use any version of RxNorm that is listed in 45 CFR 170.207(d)(1) and for which adoption has not expired. We noted that this proposal would result in a requirement to use progressively more recent releases of the RxNorm code set as the baseline version of RxNorm which Health IT Modules must use for the ‘‘electronic prescribing’’ certification criterion. Under NCPDP SCRIPT standard version 2020011 and greater, including NCPDP SCRIPT standard version 2023011, the National Drug Codes (NDC) element is required on all non- compounded medication electronic prescriptions (89 FR 63527).418 National Drug Codes (NDC) provide a PDP SCRIPT standard version 2023011, the National Drug Codes (NDC) element is required on all non- compounded medication electronic prescriptions (89 FR 63527).418 National Drug Codes (NDC) provide a unique identifier for products such as vaccines or medications. Each product is assigned a unique 10- or 11-digit, 3- segment number that identifies the labeler, product, and trade package size. We adopted NDC in 45 CFR 170.207(d)(4) in the HTI–1 Final Rule (89 FR 1226) via a cross-reference to 45 CFR 162.1002(b)(2) as referenced in 45 CFR 162.1002(c)(1). In the HTI–2 Proposed Rule, we proposed to relocate this cross-reference from 45 CFR 170.207(d)(4) to 45 CFR 170.207(d)(2) as part of our reorganization of this section (89 FR 63519 and 63520). Consistent with the requirement in the NCPDP SCRIPT standard version 2023011 to include NDC with prescriptions, we proposed in 45 CFR 170.315(b)(3)(ii)(A) that a Health IT Module certified to the criterion must enable a user to perform specified prescription-related electronic transactions in accordance with NDC in 45 CFR 170.207(d)(2). We proposed that use of NDC would be required at the time a health IT developer presents a Health IT Module f escription-related electronic transactions in accordance with NDC in 45 CFR 170.207(d)(2). We proposed that use of NDC would be required at the time a health IT developer presents a Health IT Module for certification using the NCPDP SCRIPT standard version 2023011 adopted in 45 CFR 170.205(b)(2). The following is a summary of the comments we received and our responses: Comment: Commenters expressed support for our proposal to revise the existing reference to RxNorm, September 8, 2015, Release, in 45 CFR 170.207(d)(3), and instead require use of at least one of the versions of the standard adopted in 45 CFR 170.207(d)(1), in which we proposed to include updated releases of RxNorm. A commenter agreed with ASTP/ONC’s approach to use progressively more recent releases of the RxNorm code set as baseline version of RxNorm for the ‘‘electronic prescribing’’ certification criterion. Another commenter supported use of the more current RxNorm release, stating that this would ensure Health IT Modules use the same code sets and enable more effective communications with pharmacy data systems, benefiting prescribers, pharmacists, payers, and patients. Response: We thank commenters for their supp ules use the same code sets and enable more effective communications with pharmacy data systems, benefiting prescribers, pharmacists, payers, and patients. Response: We thank commenters for their support. We note that in the HTI– 2 Proposed Rule, we inadvertently 418 For more information about the updates to NDC in the NCPDP SCRIPT standard see https:// ncpdp.org/NCPDP/media/images/ Resources%20Items/NDC-Use-eRx-Fact- Sheet.pdf?ext=.pdf. described the reference to RxNorm in 45 CFR 170.315(b)(3)(ii)(A) as referencing RxNorm, September 8, 2015, Release, in 45 CFR 170.207(d)(3) in preamble (89 FR 63527). This should have referred to RxNorm, July 5, 2022, in 45 CFR 170.207(d)(1) as stated in the text of the regulation. As discussed in section XI.B.4.b.(3) of this final rule, we are not finalizing the expiration dates for releases of RxNorm that we proposed in 45 CFR 170.207(d)(1). We further remind readers that, pursuant to the policy in 45 CFR 170.555 regarding ‘‘minimum standards’’ code set updates, developers of certified health IT are able to use newer versions of these minimum adopted standards on a voluntary basis. In order to maintain alignment with the ‘‘minimum standards’’ cod set updates, developers of certified health IT are able to use newer versions of these minimum adopted standards on a voluntary basis. In order to maintain alignment with the ‘‘minimum standards’’ code set policy in 45 CFR 170.555, we are finalizing the language proposed in 45 CFR 170.315(b)(3)(ii)(A) with a modification to retain the phrase ‘‘at a minimum.’’ Under this revision, we are conveying that any of the versions of the code set in 45 CFR 170.207(d)(1) (RxNorm) may serve as a baseline, but that, consistent with our ‘‘minimum standards’’ code sets policy, health IT developers may move to later versions of these code sets and maintain certification. Comment: Commenters supported the use of NDCs in the ‘‘electronic prescribing’’ certification criterion. A commenter agreed that the use of NDC for drugs is beneficial for specific product identification in research, dispensing, and administrative workflows. Response: We thank commenters for their support. Comment: A commenter stated that requiring the use of a code set that is not adopted as an official standard seems contrary to the concept of conforming to standards. A commenter opposed the proposal to require both RxNorm and N that requiring the use of a code set that is not adopted as an official standard seems contrary to the concept of conforming to standards. A commenter opposed the proposal to require both RxNorm and NDC. The commenter noted the value sets are duplicative, that the majority of the industry uses NDC to identify prescriptions, and that selecting one value set will improve interoperability. Response: We disagree that referencing NDC would be contrary to the concept of conforming to standards. NDC is a standard that is maintained by HHS. While ASTP/ONC has not adopted NDC directly, it has been adopted by the Secretary in 45 CFR 162.1002 and we believe it reduces confusion to cross- reference these existing codes rather than separately adopting the standard. We acknowledge the commenter’s feedback regarding preference for use of one code set, but we disagree that these code sets are duplicative. RxNorm is used to identify a brand or generic VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00608 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules an 0000 Frm 00608 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37143 medication, dose form and strength and is commonly used when ordering a medication. Additionally, an NDC code is used when the exact manufacturer and package size are known and identified to be dispensed and/or administered. We believe it is important to support both code sets as both are specified in the NCPDP SCRIPT standard version 2023011. After consideration of public comments, we are finalizing our proposal to revise our reference to RxNorm in the ‘‘electronic prescribing’’ criterion in 45 CFR 170.315(b)(3)(ii)(A), with modification. Pursuant to our reorganization of the paragraph at 45 CFR 170.315(b)(3)(ii)(A), we are finalizing cross-references to 45 CFR 170.207(d)(1), where we have adopted versions of RxNorm, in both 45 CFR 170.315(b)(3)(ii)(A)(1)(i) and 45 CFR 170.315(b)(3)(ii)(A)(2)(i). We are revising our previous requirement specifying use of the standard at 45 CFR 170.207(d)(1) with a requirement to use, at a minimum, at least one of the standards adop 170.315(b)(3)(ii)(A)(2)(i). We are revising our previous requirement specifying use of the standard at 45 CFR 170.207(d)(1) with a requirement to use, at a minimum, at least one of the standards adopted in 45 CFR 170.207(d)(1). We are finalizing this language for consistency with our policy in 45 CFR 170.555 regarding minimum standard code sets, discussed in section XI.B.4.b.(1) of this final rule. This revised reference clarifies that the ‘‘electronic prescribing’’ criterion requires the use of an RxNorm release that we include in 45 CFR 170.207(d)(1) as a baseline for certification. We are also finalizing our proposed requirement in the ‘‘electronic prescribing’’ criterion to use the standard in 45 CFR 170.207(d)(2), where we have cross referenced NDC, with modification. Pursuant to our reorganization of the paragraph at 45 CFR 170.315(b)(3)(ii)(A), we are finalizing in 45 CFR 170.315(b)(3)(ii)(A)(1)(ii) a requirement to use NDC if using the standard in 45 CFR 170.205(b)(2) (where we adopted NCPDP SCRIPT standard version 2023011) in the period before December 31, 2027. We are finalizing a requirement for use of NDC after January 1, 2028 in 45 CFR 170.315(b)(3)(ii)(A)(2)(ii). (ii e adopted NCPDP SCRIPT standard version 2023011) in the period before December 31, 2027. We are finalizing a requirement for use of NDC after January 1, 2028 in 45 CFR 170.315(b)(3)(ii)(A)(2)(ii). (iii) Diagnoses (45 CFR 170.315(b)(3)(ii)(C)) In 45 CFR 170.315(b)(3)(ii)(C) we require that a Health IT Module ‘‘must be able to receive and transmit the reason for prescription using the diagnosis elements: or ’’ for the set of prescription-related transactions identified in 45 CFR 170.315(b)(3)(ii)(C)(1)–(2). In the HTI–2 Proposed Rule (89 FR 63527 and 63528), we proposed to make changes to the list of required and optional transactions in 45 CFR 170.315(b)(3)(ii)(C) to reflect the proposed required transactions for the updated version of the certification criterion in 45 CFR 170.315(b)(3)(ii)(A), and our proposal to remove certain optional transactions from the updated version of the criterion in 45 CFR 170.315(b)(3)(ii)(B). Specifically, we proposed in 170.315(b)(3)(ii)(C)(1) to rename ‘‘Create New Prescriptions (NewRx)’’ to ‘‘New Prescriptions (NewRx).’’ We proposed in 45 CFR 170.315(b)(3)(ii)(C)(1)(vi) to remove the transaction ‘‘Receive medication history’’ (RxHistoryResponse) and ‘Create New Prescriptions (NewRx)’’ to ‘‘New Prescriptions (NewRx).’’ We proposed in 45 CFR 170.315(b)(3)(ii)(C)(1)(vi) to remove the transaction ‘‘Receive medication history’’ (RxHistoryResponse) and reserve this section. We proposed in 45 CFR 170.315(b)(3)(ii)(C)(1)(vii) to require the following electronic prior authorization transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse and PACancelRequest, PACancelResponse, PANotification) if using NCPDP SCRIPT standard version 2023011 (adopted in 45 CFR 170.205(b)(2)). Lastly, we proposed to remove the optional transactions in 45 CFR 170.315(b)(3)(ii)(C)(2)(i) through (iv) and reserve this section. We referred readers to Table 1A in the HTI–2 Proposed Rule (89 FR 63529) for a comparison of required and optional transactions identified in the current certification criterion based on NCPDP SCRIPT standard version 2017071 and the proposed updated criterion based on NCPDP SCRIPT standard version 2023011. The following is a summary of the comments we received and our responses: Comment: A commenter supported the inclusion of the Diagnosis field as proposed. Response: We thank the c ard version 2023011. The following is a summary of the comments we received and our responses: Comment: A commenter supported the inclusion of the Diagnosis field as proposed. Response: We thank the commenter for their support. Comment: A few commenters recommended updating the regulatory text to align with the new diagnosis structure in the NCPDP SCRIPT Standard Version 2023011, which allows for an unlimited number of diagnoses to be sent in prescription- related transactions. They proposed certifying only the diagnosis associated with the medication being dispensed, located in the MedicationPrescribed/ Diagnosis element, and not certifying the Patient diagnosis found in Patient/ HumanPatient/Diagnosis. They noted that this approach would ensure the focus remains on the medication- specific diagnosis rather than broader patient diagnoses. Response: We appreciate commenters’ feedback regarding the proposed regulation text at 45 CFR 170.315(b)(3)(ii)(C). We agree with commenters that the NCPDP SCRIPT Standard Version 2023011 accommodates an unlimited number of diagnoses to be sent in prescription- related transactions and that this updated version of the standard no longer utilizes e NCPDP SCRIPT Standard Version 2023011 accommodates an unlimited number of diagnoses to be sent in prescription- related transactions and that this updated version of the standard no longer utilizes the current or diagnosis elements previously identified in the 45 CFR 170.315(b)(3)(ii)(C). After consideration of the public comments, we are finalizing in 45 CFR 170.315(b)(3)(ii)(C) that a Health IT Module must be able to receive and transmit the diagnosis or diagnoses that are the reason for the prescription. We believe this language reflects the potential for multiple diagnoses as well as clarifying the requirement to support the diagnosis or diagnoses associated with the medication being prescribed. We further clarify that we are not finalizing any requirements under the ‘‘electronic prescribing’’ criterion that Health IT Modules must support diagnosis elements that are not related to the medication being prescribed. (iv) Race and Ethnicity In 2023, the Pharmacy Interoperability and Emerging Therapeutics Task Force provided a recommendation to the HITAC to support interoperability between pharmacy constituents by including race and ethnicity in the ‘‘electronic prescribing’’ cert Emerging Therapeutics Task Force provided a recommendation to the HITAC to support interoperability between pharmacy constituents by including race and ethnicity in the ‘‘electronic prescribing’’ certification criterion (PhIET–TF–2023_Recommendation 26).419 The Task Force stated that demographic data is not always made available through reporting such as case reporting to public health agencies. Yet, in order to support the ability to perform analytics, all data feeds should have relevant race and ethnicity data, and other key demographic data, when available. The Task Force recommended that various prescribing and laboratory results reporting capabilities need to be able to support sharing of the relevant data when an alternative source is not consistently available. Additionally, the Task Force acknowledged that a prescriber will likely already have patient race or ethnicity documented. Exchanging this information through available transactions, such as those included in electronic prescribing, is one way to improve consistency in 419 See https://www.healthit.gov/sites/default/ files/page/2023-11/2023-11-09_PhIET_TF_2023_ Recommendations_Transmittal_Letter_508.pdf. VerDate Sep 20 rescribing, is one way to improve consistency in 419 See https://www.healthit.gov/sites/default/ files/page/2023-11/2023-11-09_PhIET_TF_2023_ Recommendations_Transmittal_Letter_508.pdf. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00609 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k 37144 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations documentation of demographic data across provider types. Specifically, the Task Force recommended ONC include the ability to capture and exchange race and ethnicity as part of the ‘‘electronic prescribing’’ certification criterion and point to USCDI v4,420 which references the CDC Race & Ethnicity Code System—CDCREC 1.2 (July 2021).421 The CDC Race & Ethnicity Code System—CDCREC 1.2 code set facilitates use of federal standards for classifying data on race and ethnicity when these data are exchanged, stored, retrieved, or analyzed in electronic form. The NCPDP SCRIPT standard version 2023011, which we proposed to incorporate in the ‘‘electronic prescribing’’ certification criterion in the HTI–2 Proposed Rule (89 FR 63528), references ctronic form. The NCPDP SCRIPT standard version 2023011, which we proposed to incorporate in the ‘‘electronic prescribing’’ certification criterion in the HTI–2 Proposed Rule (89 FR 63528), references reporting of race and ethnicity using the CDCREC 1.2 associated value set ‘‘PHVS_Race_CDC’’ version 2 (December 2018 422) from the code system code ‘‘PH_ RaceAndEthnicity_CDC’’ as optional for certain transactions within the standard. This aligns with the code system code in CDCREC 1.2 which is ‘‘PH_ RaceAndEthnicity_CDC,’’ and is available on the Public Health Information Network (PHIN) Vocabulary Access and Distribution System (PHIN VADS).423 Given the importance of the issues described by the Task Force, and the alignment between the recommendation and NCPDP SCRIPT standard version 2023011, we stated that we believe that it is appropriate to implement the Task Force recommendation through updates to the ‘‘electronic prescribing’’ certification criterion. Therefore, we proposed in 45 CFR 170.315(b)(3)(ii)(B) that a Health IT Module certified to the ‘‘electronic prescribing’’ certification criterion must enable a user to exchange race and ethnicity information for a patient when perf R 170.315(b)(3)(ii)(B) that a Health IT Module certified to the ‘‘electronic prescribing’’ certification criterion must enable a user to exchange race and ethnicity information for a patient when performing the following prescription-related electronic transactions, if using NCPDP SCRIPT standard version 2023011: • Receive fill status notifications (RxFill). • Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse). 420 See https://www.healthit.gov/isa/united- states-core-data-interoperability-uscdi. 421 See https://www.cdc.gov/phin/resources/ vocabulary/. 422 See https://phinvads.cdc.gov/vads/ ViewValueSet.action?id=9152A536-AEEC-E711- ACD6-0017A477041A. 423 See https://phinvads.cdc.gov/vads/ ViewCodeSystemConcept.action?oid=2.16.840. 1.113883.6.238&code=1579-2. • Request to cancel prescriptions (CancelRx). • Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse). We stated we believe the transactions listed previously are an appropriate starting place to include race and ethnicity in the electronic prescribing certification criterion. We noted that we will continue to monitor changes to the NCPDP SCRIPT standard for additional upd te starting place to include race and ethnicity in the electronic prescribing certification criterion. We noted that we will continue to monitor changes to the NCPDP SCRIPT standard for additional updates to transactions to include race and ethnicity data fields. We invited comments on this proposal and requested information on whether there are other SCRIPT transactions that include data fields for race and ethnicity we should consider specifying to enable exchange of race and ethnicity data with providers in pharmacy settings. The following is a summary of the comments we received and our responses: Comment: Several commenters supported our proposal to require that Health IT Modules certified to the ‘‘electronic prescribing’’ criterion enable users to capture race and ethnicity in the specific transactions. Commenters stated that expanding data collection requirements across certified health IT, including options for disaggregated coding of race, ethnicity and preferred language, would help to extend contextual understanding for electronic prescribing information. Response: We thank the commenters for their support. We agree that enabling exchange of this information will increas ld help to extend contextual understanding for electronic prescribing information. Response: We thank the commenters for their support. We agree that enabling exchange of this information will increase its availability and can add useful information to electronic prescriptions. Comment: A commenter stated that ASTP/ONC should consider the potential misuse of race and ethnicity information captured using certified Health IT Modules, while another commenter recommended making race and ethnicity data collection and sharing optional, so pharmacy staff on the ground can make informed decisions on when it is appropriate to ask questions on demographics. Response: We appreciate commenters’ feedback on the use of race and ethnicity data and agree that there are many important considerations around the collection and use of these data. The potential misuse of data is not unique to data elements of race and ethnicity. Users of certified health IT should comply with existing laws and regulations governing the use of health information (for instance, see the HIPAA Security and Privacy Rules in 45 CFR part 160 and subparts A, C and E of part 164). Additionally, organizations may establish their governing the use of health information (for instance, see the HIPAA Security and Privacy Rules in 45 CFR part 160 and subparts A, C and E of part 164). Additionally, organizations may establish their own data policies to support the accuracy of data. We note that the proposed requirement that Health IT Modules certified to the updated ‘‘electronic prescribing’’ criterion must enable a user to exchange this information would not establish a requirement for end users of Health IT Modules certified to the ‘‘electronic prescribing’’ criterion to capture and share this information. This proposal does not require the collection or disclosure of demographic information nor does it address the voluntary nature of patient disclosures of race and ethnicity data. Comment: A commenter stated that ASTP/ONC should work with other agencies to ensure policies to support the collection and exchange of demographic data are patient-centric, respect patient privacy, and promote patient autonomy. Commenters recommended that all race and ethnicity information should be provided voluntarily by the patient and that ASTP/ONC and other agencies should work with stakeholders to implement feasible workflows, rs recommended that all race and ethnicity information should be provided voluntarily by the patient and that ASTP/ONC and other agencies should work with stakeholders to implement feasible workflows, identify appropriate ways to share data, and ensure that patients always have an option to decline to respond. Another commenter encouraged ASTP/ONC to more clearly identify specific uses for these data to reduce health inequities. A commenter recommended ASTP/ONC provide more rationale for requiring this information be captured as other areas of medicine are pushing to take race and ethnicity out of consideration when prescribing medications. Response: We agree with commenters that prescribers should think carefully about how to ensure patient-centered principles are followed when designing workflows around collection of this information, and that patients must have a voice in the data that they choose to share and how that data is shared with others. We will continue to collaborate with other agencies to ensure that such principles are considered in efforts around data collection as appropriate. Regarding additional rationale for our proposal, we refer readers to the findings of the other agencies to ensure that such principles are considered in efforts around data collection as appropriate. Regarding additional rationale for our proposal, we refer readers to the findings of the 2023 HITAC Pharmacy Interoperability and Emerging Therapeutics Task Force report 424 that race and ethnicity data are crucial for public health reporting and analytics. Gaps in the completeness of case reporting necessitate additional means to capture and share these data, so they 424 https://www.healthit.gov/sites/default/files/ page/2023-11/2023-11-09_PhIET_TF_2023_ Recommendations_Transmittal_Letter_508.pdf. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00610 Fmt 4701 Sfmt 4700 E:\FR\FM\04AUR2.SGM 04AUR2 2 S E L U R h t i w D O R P 4 4 1 S 7 W 9 K S D n o d n o m m a h k Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations 37145 may be included in public health reporting. Finally, we note that this requirement for certified Health IT Modules would not establish any requirements that end users must consider race and ethnicity data when making prescribing decisions. Comment: Several commenters noted the most common transaction in the NCPD s would not establish any requirements that end users must consider race and ethnicity data when making prescribing decisions. Comment: Several commenters noted the most common transaction in the NCPDP SCRIPT standard, NewRx, does not currently support race and ethnicity information, which limits the potential impact of exchanging race and ethnicity using the standard. Another commenter noted that ASTP/ONC should clarify the requirement is only to send race and ethnicity data to a pharmacy and not receive it back, as health systems are unlikely to want pharmacy data to overwrite information gathered during their check-in processes. Response: We acknowledge the comment regarding the lack of inclusion of race and ethnicity data in the NewRx transaction, and will continue to work with interested parties to further explore transactions where inclusion of this data may be useful. We confirm that our final rule requirement only specifies that the health IT module must enable a user to exchange this information. We did not propose any requirement for a Health IT Module to modify data or overwrite existing data based on information received from pharmacies. Comment: A commenter recommended ge this information. We did not propose any requirement for a Health IT Module to modify data or overwrite existing data based on information received from pharmacies. Comment: A commenter recommended the proposed timelines for certification should parallel those set forth in OMB’s recent Statistical Policy Directive No. 15: Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity (SPD 15) 425 regarding the collection of race and ethnicity data, which identified an implementation date of March 28, 2029. The commenter stated that federal agencies are required to plan for implementation of OMB’s race and ethnicity data policy over the next five years, so aligning with this delayed date would provide an opportunity to move towards standardization and alignment of race and ethnicity data across healthcare and government. Response: We appreciate commenters’ input, however it is not necessary to parallel the timelines in OMB’s SPD 15 directive with our policies in this final rule for the ‘‘electronic prescribing’’ criterion. OMB’s SPD 15 directive provides the standards for maintaining, collecting, and presenting race and ethnicity data for all Federal inf