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 ng interface (API) specifications (developed once and deployed enterprise wide) can be connected to another IT system (for example, an app or information database) that supports these same specifications. Each additional connection has a marginal cost, but each is built on the same foundational infrastructure, enabling more connections at lower marginal costs than if configured using non-standards- based APIs. In the 2015 Edition Final Rule (80 FR 62602), three API criteria were finalized: 45 CFR 170.315(g)(7), (g)(8), and (g)(9). These were the first API criteria adopted by the Certification Program, and we note that they were finalized as ‘‘functional’’ criteria that did not require conformance to a specific standard or method, beyond implementing a RESTful API, to respond to a query for a patient record. In that rulemaking, we estimated that building each of these APIs would require on average per product approximately 300 to 400 hours in development time. In the ONC Cures Act Final Rule (85 FR 25642), we finalized the ‘‘standardized API for patient and population services’’ criterion in 45 CFR 170.315(g)(10), which replaced the criterion in 45 CFR 170.315(g)(8) and required sup Rule (85 FR 25642), we finalized the ‘‘standardized API for patient and population services’’ criterion in 45 CFR 170.315(g)(10), which replaced the criterion in 45 CFR 170.315(g)(8) and required support for an API using industry standards in place of proprietary methods. We estimated in Table 16 of the ONC Cures Act Final Rule that the effort to replace the functional requirements of the API specified in 45 CFR 170.315(g)(8) and adopt the HL7 Fast Healthcare Interoperability Resources (FHIR) standard specified in the criterion in 45 CFR 170.315(g)(10) would require 1600 to 6000 hours, depending on whether the product already adopted the FHIR standard for its 45 CFR 170.315(g)(8) API (lower bound) or needed to do a complete re-build (upper bound).529 We also estimated in Table 16 that it would cost 800 to 1500 hours to adopt the Substitutable Medical Applications, Reusable Technologies (SMART) on FHIR App Launch Framework implementation guide, which standardizes the way in which a requesting application that connects to the standardized API securely accesses data from the FHIR 529 https://www.federalregister.gov/d/2020-07419/ p-3033. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 uesting application that connects to the standardized API securely accesses data from the FHIR 529 https://www.federalregister.gov/d/2020-07419/ p-3033. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00740 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 37275 server.530 Together these two standardized approaches to enable patient-level data queries and securely and uniformly respond to those requests amounted to 2400 to 7500 hours of effort or a median of approximately 5,000 hours to replace the functional API with a standards-based API. This is about 15 times the effort of building the functional, non-standardized API, specified in the criterion in 45 CFR 170.315(g)(8) that was finalized in the 2015 Edition Final Rule (80 FR 62602). This is a meaningful difference in development effort. Why require this larger additional effort to replace an API with no required standards with one that conforms to one or more standards? Standardization promotes more uniform and predictable access and exchange across many different possi fort to replace an API with no required standards with one that conforms to one or more standards? Standardization promotes more uniform and predictable access and exchange across many different possible exchange partners (or in computer terms, IT system nodes). If a developer is building an API for a specific, non-scalable purpose to achieve a specific proprietary or internal need, customizing it to align with an industry standard may not be feasible or reasonable. Standards, however, permit multiple uses of the API or many possible users of the API. In the case of the 45 CFR 170.315(g)(10) API, standards were adopted to enable broad implementation across hundreds of certified health IT products to enable use and access by hundreds, if not thousands of application (‘‘app’’) developers, health care organization innovators, and entrepreneurial health care providers, seeking to use their standardized data access to create novel applications to treat and care for their patients. Prior to the finalization of the ONC Cures Act Final Rule (85 FR 25642), the potential number of applications that could connect to a health IT product were numerous; standardizing the API would lead to more c the finalization of the ONC Cures Act Final Rule (85 FR 25642), the potential number of applications that could connect to a health IT product were numerous; standardizing the API would lead to more competition and innovation in the market.531 And, within the context of FHIR APIs, competition and innovation have resulted. Studies as early as 2020 show hundreds of distinct apps connecting to health IT products via standards-based and proprietary APIs, and other later studies show nearly all application developers or digital health companies building their applications and services using the FHIR standard by default given the broad availability of FHIR APIs in the market.532 533 Nearly all surveyed companies in the Barker, et al. study reported they were connecting with 2 or more companies and more so if they were FHIR adopters.534 These findings show that standardization can enable more connections and broaden the reach of technological innovation across the ecosystem of health care apps and technology. If an app developer can predictably build their app to connect to one health IT product via a FHIR API, the infrastructure they built once can be used to connect to 2, 3, or more hea s and technology. If an app developer can predictably build their app to connect to one health IT product via a FHIR API, the infrastructure they built once can be used to connect to 2, 3, or more health IT products. And for health IT product developers, enabling easier integrations with their EHR or other health IT system can provide more choice to their customers, and can broaden the product and service offerings available through their platform. Services and tools that the health IT product developer could not provide alone can be provisioned through any number of app developers who can connect and integrate with the health IT product, permitting use of the app directly in the health IT product instance. Furthermore, if a health IT product adopts a standardized API, an innovative company working with the health IT product’s competitor can connect to the competitor’s health IT products as well, without having to build a custom interface to a proprietary, non-standards-based API. We find that there are large potential savings for a developer of certified health IT if they adopt this standards-based approach. In our model, we assume certain tasks are necessary for an app to connect ind that there are large potential savings for a developer of certified health IT if they adopt this standards-based approach. In our model, we assume certain tasks are necessary for an app to connect to and integrate with a health IT product. We also estimate the effort required by a health IT product to support one or many integrations. In Table I.G.12.-01, we list some common tasks necessary to successfully connect an app to a health IT product via an API. We also provide the expected number of hours required to complete each task via a standards-based and non-standards-based API. For a standards-based API, we assume that the app and health IT product both adopt the same standards-based methods to connect via an API, in this case the FHIR and USCDI standards, as adopted in the 45 CFR 170.315(g)(10) certification criterion. We also assume that, even when utilizing a standards- based API, there is still some effort to integrate. However, when both the app and health IT product support the same standards, many of the tasks can be done at less or no additional effort. This is because the app connecting to the health IT product adopts similar API specifications and a similar data mod the same standards, many of the tasks can be done at less or no additional effort. This is because the app connecting to the health IT product adopts similar API specifications and a similar data model to fetch data elements from the health IT product. Comparing this effort to a scenario where an app must connect via a non-standards-based API, the effort to connect to the non-standards-based API is greater. This is because the health IT product developer must provide greater support (and the app must expend more effort) to review the novel API’s documentation; to map how the app records data elements; and to understand how the corresponding health IT product API makes those or similar data elements available. This effort could be considerable (nearly 60 percent of the entire effort) as mapping data elements is an essential task to programmatically query, fetch, and ingest data via an API. Standardizing APIs and standardizing any data exchange process are essential to reduce the effort to do this mapping. TABLE I.G.12.–01—TIME ON TASK FOR API INTEGRATIONS, NON-STANDARDS-BASED VS. STANDARDS-BASED API Task Task details Via non-standards- based API (hours) Via standards- based API (ho to do this mapping. TABLE I.G.12.–01—TIME ON TASK FOR API INTEGRATIONS, NON-STANDARDS-BASED VS. STANDARDS-BASED API Task Task details Via non-standards- based API (hours) Via standards- based API (hours) Review API Documentation ............. Get details on specific workflows to use the API and how to fetch data (data resources Mapping Data Elements .................. Map data received (to be ingested) via an API query to the same or similar data elements and endpoints needed to get specific data elements). Syntax for the API (to be used to incorporate into application code). Process to discover and connect to API endpoints. Authorization .................................... What credentials and how to present them when requesting data via a secure API end- in the developer’s application. Registration ...................................... Get authorized access to API host’s non-public facing tools and API information permitted Testing ............................................. Conduct testing via sandbox or synthetic data to verify successful API connection and data ingestion from host server to developer application. only after user is verified and trusted. point. Total ..... duct testing via sandbox or synthetic data to verify successful API connection and data ingestion from host server to developer application. only after user is verified and trusted. point. Total .......................................... ................................................................................................................................................. 40 150 20 2 40 252 8 0 0 2 40 50 Table I.G.12.–01 shows that it takes about 5 times the effort to connect via a non- standards-based API. However, we also calculated that the base cost to build the infrastructure for the standardized API is nearly 15 times the effort to build a non- 530 https://build.fhir.org/ig/HL7/smart-app- 532 Barker W, Johnson C. The ecosystem of apps launch/. 531 Dullabh P, Hovey L, Heaney-Huls K, Rajendran N, Wright A, Sittig DF. Application programming interfaces in health care: findings from a current-state sociotechnical assessment. Appl Clin Inform2020; 11 (1): 59–69. and software integrated with certified health information technology. J Am Med Inform Assoc. 2021 Oct 12;28(11):2379–2384. doi: 10.1093/jamia/ ocab171. PMID: 34486675; PMCID: PMC8510286. 533 Wesley Barker, Natalya integrated with certified health information technology. J Am Med Inform Assoc. 2021 Oct 12;28(11):2379–2384. doi: 10.1093/jamia/ ocab171. PMID: 34486675; PMCID: PMC8510286. 533 Wesley Barker, Natalya Maisel, Catherine E Strawley, Grace K Israelit, Julia Adler-Milstein, 534 Ibid. Benjamin Rosner, A national survey of digital health company experiences with electronic health record application programming interfaces, Journal of the American Medical Informatics Association, Volume 31, Issue 4, April 2024, Pages 866–874, https://doi.org/10.1093/jamia/ocae006. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00741 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 37276 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations standardized API. How can the standardized API, therefore, be preferred over a non- standardized API if it costs less to do the initial build? The savings are earned as more and more connections between a health IT product and apps are completed. In Table -I.G.12.–02, we compare the costs of building the base API infrastructure for a standards and non-standards-ba as more and more connections between a health IT product and apps are completed. In Table -I.G.12.–02, we compare the costs of building the base API infrastructure for a standards and non-standards-based API, as well as the marginal costs of connecting one or more apps to that health IT product. We find that on average the cost to build the standards- based API infrastructure and complete 24 app integrations would cost about the same as doing so via a non-standards-based API. However, the integration of more apps beyond 24 integrations yields savings, as the incremental costs to connect more apps become more costly via a non-standards- based API than a standards-based API. As the referenced studies and the updated analysis show, there are hundreds of apps (that we know of from public data sources) that currently connect to health IT products with consistent growth year after year.535 TABLE I.G.12.–02—COMPARISON OF COSTS TO INTEGRATE APPS WITH A HEALTH IT PRODUCT VIA STANDARDS AND NON-STANDARDS-BASED APIS Standards-based Not standards-based Differential costs Average hours 1 Cumulative hours Average hours Cumulative hours Cumulative hour difference Cumulative hours for all certified TANDARDS-BASED APIS Standards-based Not standards-based Differential costs Average hours 1 Cumulative hours Average hours Cumulative hours Cumulative hour difference Cumulative hours for all certified API products 2 Cost difference ($) 3 Base build ..................................................... 1 App ............................................................. 10 Apps ......................................................... 24 Apps 4 ....................................................... 25 Apps ......................................................... 50 Apps ......................................................... 100 Apps ....................................................... 5,000 50 500 1,200 1,250 2,500 5,000 5,000 5,050 5,500 6,200 6,250 7,500 10,000 350 250 2,500 6,000 6,250 12,500 25,000 350 600 2,850 6,350 6,600 12,850 25,350 4,650 4,450 2,650 ¥150 ¥350 ¥5,350 ¥15,350 $151,245,900 1,088,100 144,740,700 1,041,300 86,193,900 620,100 ¥35,100 ¥4,878,900 ¥81,900 ¥11,384,100 ¥1,251,900 ¥174,014,100 ¥3,591,900 ¥499,274,100 Notes: (1) Average hours are the median of the lower (2,400) and upper (7,500) bound hours calculated for the combined 45 CFR 170.315(g)(10) crite 4,100 ¥1,251,900 ¥174,014,100 ¥3,591,900 ¥499,274,100 Notes: (1) Average hours are the median of the lower (2,400) and upper (7,500) bound hours calculated for the combined 45 CFR 170.315(g)(10) criterion. (2) Total = (Cumulative Hour Difference) × (All Certified API Products, n=234). (3) Total $ = (Cumulative Hours for All Certified API Products) × (Wage Rate Used in this Impact Analysis, $139). (4) On average, the breakeven point for a certified API product to adopt a standards-based API (versus a non-standards-based API) is 24 apps. Formula: 50x + 5000 = 250x + 350; x = 4650/200; x = 23.25. The growth in new apps and digital health (1) Costs companies coming on the market and number of integrations between these apps and health IT products demonstrates the effectiveness of adopting industry standards to establish software interoperability and promote competition and innovation in the health care market. Standards-based APIs permit less costly and burdensome connections between certified health IT products and third-party apps and services and enable greater predictability in how a single app or digital service can connect to one or many certified health IT products. This model p fied health IT products and third-party apps and services and enable greater predictability in how a single app or digital service can connect to one or many certified health IT products. This model provides evidence for the likely savings that can accrue to certified health IT and third-party developers alike from the adoption and use of standards-based APIs. We replicate this model in our impact analysis, of adopting standards-based electronic prior authorization APIs to show the value of adopting industry standards versus proprietary, non-standards-based methods of exchange. b. Revised Electronic Prescribing Certification Criterion ASTP/ONC finalized updates to the ‘‘electronic prescribing’’ certification criterion in 45 CFR 170.315(b)(3) including the incorporation of NCPDP SCRIPT standard version 2023011. These updates include revising the list of required transactions, removing optional transactions, and adoption of several new transactions in light of changes to the NCPDP SCRIPT standard and other relevant considerations, including updated vocabulary standards. The required updates to the ‘‘electronic prescribing’’ certification criterion include five tasks: (1) incorporate standard and other relevant considerations, including updated vocabulary standards. The required updates to the ‘‘electronic prescribing’’ certification criterion include five tasks: (1) incorporate NCPDP SCRIPT Standard Version 2023011 for all required transactions; (2) require the eight Electronic Prior Authorization transactions and the PANotification transaction in alignment with NCPDP SCRIPT standard version 2023011; (3) adopt FDA National Drug Code (NDC) terminology for coded drugs; (4) adopt RxNorm, December 4, 2023, and (5) enable a user to capture race and ethnicity information for a patient when performing the following prescription-related electronic transactions: RxFill; RxChangeRequest, RxChangeResponse; CancelRx; and RxRenewalRequest, RxRenewalResponse. These tasks have their own levels of effort, and these estimates are detailed in Tables I.G.12.–03 and 04 are based on the following assumptions: • Health IT developers are assumed to use the same labor rates and data modeling approach. Table I.G.12.–03 presents the estimated labor costs per product to support updates. While actual costs may vary across developers, for these purposes, all certified health IT developer eling approach. Table I.G.12.–03 presents the estimated labor costs per product to support updates. While actual costs may vary across developers, for these purposes, all certified health IT developers are assumed to incur all costs outlined in Table I.G.12.–04. • 199 products certified by 150 developers will be required to adopt the revised criterion. We estimate that, in total, 395 health IT developers will certify 520 health IT products impacted by this rulemaking. However, not all these developers and products certify to the ‘‘electronic prescribing’’ certification criterion and need to meet the proposed requirements. As of the end of 2024, 38 percent of developers and 38 percent of products certified to the ‘‘electronic prescribing’’ certification criterion. We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by the proposed modifications to the certification criterion. • According to the May 2024 Bureau of Labor Statistics (BLS) occupational employment statistics, the mean hourly wage for a Software Developer (Standard Occupational Code: 15–1252) is $69.50.536 Assumptions include that ov 2024 Bureau of Labor Statistics (BLS) occupational employment statistics, the mean hourly wage for a Software Developer (Standard Occupational Code: 15–1252) is $69.50.536 Assumptions include that overhead costs and benefits are equal to 100 percent of pre-tax wages, so the hourly wage including overhead costs is $139.00. • Although electronic prior authorizations transactions were previously finalized as optional for the ‘‘electronic prescribing’’ criterion under the Certification Program, many products support them in practice to comply with Medicare Part D requirements. Certification to the revised criterion still requires effort; however, for products already supporting these transactions, the cost is expected to be lower than initially estimated, as the functionality is not net new and development work is likely already completed. Analysis of public Medicare Quality Payment Program data537 show that 81 percent of active products certified for electronic prescribing (161 of 199 products impacted by this final rule) are used to report for Promoting Interoperability (PI) performance, while 19 percent (38 of 199 products) are not. The 161 products actively used for PI reporting a oducts impacted by this final rule) are used to report for Promoting Interoperability (PI) performance, while 19 percent (38 of 199 products) are not. The 161 products actively used for PI reporting are also assumed to support electronic prescribing for Medicare Part D, which has required the use of the NCPDP SCRIPT standard version 2017071 535 https://www.healthit.gov/sites/default/files/ 536 BLS. Occupational Employment and Wage 537 https://data.cms.gov/quality-of-care/quality- 2023-05/Insights%20into%20Data% 20Sharing%20between%20EHRs %20and%20Apps%20508.pdf. Statistics: https://data.bls.gov/oes/#/industry/ 000000. payment-program-experience/data. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00742 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 37277 and associated PA transactions since 2022 and finalized requirements for the use of the NCPDP SCRIPT standard version 2023011 in the ‘‘Medicare Program; Medicare Prescription Drug Benefit Program; Health Information Technology Standards and Implementation Specifications or the use of the NCPDP SCRIPT standard version 2023011 in 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) which appeared in the Federal Register on June 17, 2024 (89 FR 51238).538 The estimated cost burden for the finalized 45 CFR 170.315(b)(3) ‘‘electronic prescribing’’ certification criterion has been reduced due to market readiness, policy alignment, and technical efficiencies. Health IT developers are already supporting many of these required functionalities, due to CMS requirements, industry standards, or existing implementations. Table I.G.12.–03 presents the estimated labor hours per product, by task, based on the assumptions noted previously. TABLE I.G.12.–03—ESTIMATED LABOR HOURS TO MODIFY 45 CFR 170.315(b)(3) ELECTRONIC PRESCRIBING CERTIFICATION CRITERION Task Details Lower bound hours Upper bound hours Remarks Task 1: NCPDP SCRIPT Stand- ard Version 2023011 for all re- quired transactions. Update required electronic prescribing transactions from NCPDP SCRIPT Standard Version 2017071 to NCPDP SCRIPT Standard Version 202301 CRIPT Stand- ard Version 2023011 for all re- quired transactions. Update required electronic prescribing transactions from NCPDP SCRIPT Standard Version 2017071 to NCPDP SCRIPT Standard Version 2023011. 200 Task 2a: (i) Electronic Prior Au- Electronic Prior Authorization trans- 250 thorization transactions and (ii) new PANotification transaction. Actively used products already supporting Part D Require- ments through PI reporting. actions are now required. These were optional under Cures Update regula- tions. Also, it is now required to im- plement the transaction, PANotification. 600 There are no changes related to these transactions between the 2017071 and 2023011 versions of the NCPDP SCRIPT Stand- ard. We expect low implementation effort, similar to prior transi- tions, where it was estimated in the final rule impact analysis that 50–150 labor hours were required for the 2014 Edition. There, ASTP/ONC finalized requirements to adopt NCPDP SCRIPT Standard Version 10.6 for NewRx (the only required transaction at the time). For this update, the same approach is applied by reducing the level of effort per transaction by half, given the lack of changes, and multiplying across the eig only required transaction at the time). For this update, the same approach is applied by reducing the level of effort per transaction by half, given the lack of changes, and multiplying across the eight re- quired transactions: New prescription (NewRx); Request and re- spond to change prescriptions (RxChangeRequest, RxChangeResponse); Request and respond to cancel prescrip- tions (CancelRx, CancelRxResponse); Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse); Receive fill status notifications (RxFill); Relay acceptance of a transaction back to the sender (Status); Respond that there was a problem with the transaction (Error); and Respond that a transaction requesting a return receipt has been received (Verify). Signatura (Sig) functionality, which was optional in prior rulemaking (including the Cures Update), is embedded within the required NCPDP SCRIPT standard. Developers who pre- viously implemented Sig as part of a certified Health IT Module under prior rulemaking are assumed to face lower development costs related to minor internal configurations and testing to com- ply with the new requirements. 500 Products for electronic prescribing being acti or rulemaking are assumed to face lower development costs related to minor internal configurations and testing to com- ply with the new requirements. 500 Products for electronic prescribing being actively used to report for Medicare PI performance are required to conduct electronic pre- scribing through Part D, which as of 2022, requires the use of the SCRIPT standard and its associated PA transactions. For those products which already support this functionality for Part D prescribers and are affected by this final rule, we estimate the cost for certification for this revised criterion and testing. Task 2b: (i) Electronic Prior Au- Electronic Prior Authorization trans- 250 3600 In the 2015 Certification Edition, new transactions were required thorization transactions and (ii) new PANotification transaction. Products not represented in PI Reporting and may not yet sup- port these transactions. actions are now required. These were optional under Cures Update regula- tions. Also, it is now required to adopt and require transaction, PANotification. for this criterion. It was estimated that it would require 250–400 labor hours to implement each new transaction. We take a simi- lar appro w required to adopt and require transaction, PANotification. for this criterion. It was estimated that it would require 250–400 labor hours to implement each new transaction. We take a simi- lar approach here with remaining products not represented in PI reporting. Additionally, those who voluntarily adopted the trans- actions as part of a certified Health IT Module under prior rule- making will face less development costs to adopt under new re- quirements. Task 3: FDA National Drug Code (NDC) terminology for coded drugs. Task 4: Update to RxNorm De- cember 4, 2023, Full Update Release terminology. NDC is required in NCPDP SCRIPT 40 80 NDC is already widely adopted and seen as critical for coding Standard Version 2023011 for coded drugs. Aligns with more current version of vo- 40 cabulary standard. drugs. NDC is now a required part of adopting 2023011 but high current adoption should reduce overall effort to implement in certified Health IT Modules. 80 Vocabulary standard is likely to already be incorporated into field- ed technology. Some effort expected to align with updated cer- tification requirements. Task 5. Race and Ethnicity data NCPDP standard supports the capa- 40 80 Deve already be incorporated into field- ed technology. Some effort expected to align with updated cer- tification requirements. Task 5. Race and Ethnicity data NCPDP standard supports the capa- 40 80 Developers must map to patient’s race and ethnicity data and sup- for four transactions. bility to capture these data for trans- actions. port exchange of these data for four transactions. This require- ment does not require capture or transmission by clinicians. TABLE I.G.12.–04—TOTAL COST TO MODIFY ELECTRONIC PRESCRIBING [2024 Dollars] Activity Estimated cost Lower bound Upper bound Task 1 (199 products) ................................................................................................................................... Task 2a (161 products) ................................................................................................................................. Task 2b (38 products) ................................................................................................................................... $5,532,200.00 5,594,750.00 1,320,500.00 $16,596,600.00 11,189,500.00 19,015,200.00 538 https://www.federalregister.gov/documents/ 2024/06/17/2024-12842/med ............................................ $5,532,200.00 5,594,750.00 1,320,500.00 $16,596,600.00 11,189,500.00 19,015,200.00 538 https://www.federalregister.gov/documents/ 2024/06/17/2024-12842/medicare-program- medicare-prescription-drug-benefit-program-health- information-technology-standards. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00743 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 37278 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations TABLE I.G.12.–04—TOTAL COST TO MODIFY ELECTRONIC PRESCRIBING—Continued [2024 Dollars] Activity Estimated cost Lower bound Upper bound Task 3 (199 products) ................................................................................................................................... Task 4 (199 products) ................................................................................................................................... Task 5 (199 products) ................................................................................................................................... Total (199 products and 150 devel ............ Task 5 (199 products) ................................................................................................................................... Total (199 products and 150 developers) ..................................................................................................... 1,106,440.00 1,106,440.00 1,106,440.00 15,766,770.00 2,212,880.00 2,212,880.00 2,212,880.00 53,439,940.00 The cost to a health IT developer to make the required modifications to the ‘‘electronic prescribing’’ certification criterion for its Health IT Module would range from $79,230 to $268,542.00 per product, on average. Therefore, assuming 199 products overall and a labor rate of $69.50 per hour, we estimate that the total cost to all health IT developers would, on average, range from $15.7 million to $53.4 million. (2) Cost Savings As stated previously, the final revised criterion’s incorporation of NCPDP SCRIPT standard version 2023011 aligns with Medicare Part D requirements for sponsors and prescribers. Standards alignment is crucial to ensure interoperability between IT systems. Alignment with regulatory requirements is also crucial to ensure that technology used to suppor sponsors and prescribers. Standards alignment is crucial to ensure interoperability between IT systems. Alignment with regulatory requirements is also crucial to ensure that technology used to support electronic prescribing for Part D prescribers adopts and uses standards in similar ways to avoid additional costs to developers and their end users to support multiple methods to electronically prescribe. Regulatory alignment ensures that the products used by Medicare clinicians to participate in Promoting Interoperability and to prescribe medications via Part D use the same standards and function in the same way. This eliminates redundancies and reduces inefficiencies in how certified technology is updated to meet multiple, overlapping federal regulations. (3) Benefits The updates to the ‘‘electronic prescribing’’ certification criterion at 45 CFR 170.315(b)(3) align the criterion with the NCPDP SCRIPT Standard Version 2023011, enhancing interoperability, clarity, and efficiency across electronic prescribing transactions. These changes support federal policy goals to empower patients with information, improve patient safety, improve transparency, and reduce regulatory burden through electronic prescribing transactions. These changes support federal policy goals to empower patients with information, improve patient safety, improve transparency, and reduce regulatory burden through automation and standardization. Adoption of updated code sets and structured data fields, including Sig, ePA transactions, RxNorm, and NDC terminology for coding drugs, and the capability of health IT developers to capture patient information will support consistent, high-value clinical workflows and more effective communication with pharmacy systems. For Task 1, this alignment is in step with a reciprocal Medicare Part D requirement for Part D sponsors, prescribers, and dispensers, when electronically transmitting prescriptions and prescription-related information for covered Part D drugs for Part D eligible individuals, to use a standard in 45 CFR 170.205(b), which includes the NCPDP SCRIPT standard version 2023011, for all required and optional electronic prescribing transactions. NCPDP SCRIPT standard version 2023011 includes important updates to terminology standards, transactions, and other data elements. Moreover, the adoption through rulemaking of a new NCPDP SCRIPT standard v P SCRIPT standard version 2023011 includes important updates to terminology standards, transactions, and other data elements. Moreover, the adoption through rulemaking of a new NCPDP SCRIPT standard version and corresponding updates to the certification criterion for ‘‘electronic prescribing’’ align with public feedback and consensus on how to ensure these transactions and the ‘‘electronic prescribing’’ certification criterion are advancing interoperability. In addition, communicating how a prescriber intends for a patient to take a medication is critical for safe and effective care. Standardizing prescription directions via the codified and structured Sig format has the potential to reduce medication errors and improve patient care. These instructions are essential for accurate prescription labeling, appropriate patient counseling and education from a pharmacist, and optimal medication use. The industry has been slow to adopt structured and codified Sig functionality, with unstructured free text Sig directions still the most commonly used format. The wide variation in unstructured Sig limits the clarity, utility, and reusability of the data, therefore diminishing the potential imp d free text Sig directions still the most commonly used format. The wide variation in unstructured Sig limits the clarity, utility, and reusability of the data, therefore diminishing the potential impact on patient safety and clinical outcomes. Sig is also an important factor in a provider’s capacity to follow the CDC Guideline for Prescribing Opioids for Chronic Pain, especially in cases where the provider lacks information about days’ supply, but still seeks to calculate quality improvement opioid measures as part of a larger strategy to support careful and selective use of long- term opioid therapy in the context of managing chronic pain.539 Implementation of the structured and codified Sig format in electronic prescribing has shown measurable benefits, including more complete details.540 The Sig requirement provides greater clarity, utility, and reusability of the data, moving from an unstructured free text Sig to a structured and codified functionality.541 539 Overdose Prevention. Overdose Prevention | Overdose Prevention | CDC. 540 Implementation outcomes of the Structured and Codified SIG format in electronic prescription directions. Implementation outcomes of the Structured Overdose Prevention | Overdose Prevention | CDC. 540 Implementation outcomes of the Structured and Codified SIG format in electronic prescription directions. Implementation outcomes of the Structured and Codified SIG format in electronic prescription directions | Journal of the American Medical Informatics Association | Oxford Academic. 541 A Prescription for Enhancing Prescribing Safety. A Prescription For Enhancing Electronic Prescribing Safety. For Task 2, comments submitted in response to ASTP/ONC’s ‘‘Request for Information: Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria,’’ published on January 24, 2022 (87 FR 3475), emphasized that requiring prior authorization transactions would advance interoperability and reduce administrative burden related to medication prior authorization processes. These transactions also help to streamline prescription workflows, improve patient safety, and support capabilities to address transparency and affordability gaps. Making these transactions mandatory will help ensure that pharmacy data systems can communicate consistently across all Health IT Modules certified to this criterion, eliminati and affordability gaps. Making these transactions mandatory will help ensure that pharmacy data systems can communicate consistently across all Health IT Modules certified to this criterion, eliminating the need to build different workflows for different systems. This requirement aligns with Medicare Part D, aligning certification requirements with broader federal healthcare policy (89 FR 51238). For Task 3, National Drug Codes (NDC) is critical for specific product identification in research, dispensing, and administrative workflows. NDC is the key, unique product identifier and is the standard of practice used throughout the pharmacy industry to identify the specific product. The pharmacy industry heavily relies on NDC in all aspects of its business, including, but not limited to, drug ordering, medication dispensing, reporting, billing, rebates, adverse event reporting, and patient safety. In NCPDP SCRIPT standard version 2023011, NDC is required for coded drugs in the standard. NDC is also adopted as a medical data code set for reporting drugs and biologics on retail pharmacy claims under the HIPAA Transaction and Code Set rule.542 The requirement of NDC is expected to ensure g is also adopted as a medical data code set for reporting drugs and biologics on retail pharmacy claims under the HIPAA Transaction and Code Set rule.542 The requirement of NDC is expected to ensure greater interoperability with pharmacy data systems and facilitate correct identification of prescribed products. For Task 4, updating Health IT Modules to use up-to-date versions of the RxNorm code set version is important for interoperability. Currently, modules certified to this certification criterion align with a prior RxNorm version; this new requirement transitions to a new baseline version, which will ensure Health IT Modules certified to this certification criterion are required to comply with a consistent baseline for these codes and can communicate with pharmacy data systems more effectively. This requirement promotes standardized 542 HIPAA Transaction and Code Set https:// www.ecfr.gov/current/title-45/section-162.1002#p- 162.1002(a)(3) VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00744 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 / 5001 PO 00000 Frm 00744 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 37279 terminology across systems, reduces ambiguity in medication-related data exchange, and supports more accurate prescribing and dispensing. For Task 5, Health IT Modules certified to the ‘‘electronic prescribing’’ criterion now must enable users to exchange a patient’s race and ethnicity data when conducting the following four transactions: RxFill; RxChangeRequest/Response; CancelRx; and RxRenewalRequest/Response. While the NCPDP SCRIPT standard version 2023011 currently supports exchange of these data as an optional feature, this requirement would ensure consistent support across certified health IT. This requirement for developers will help support improved interoperability and data consistency. The resulting improvements to interoperable exchange of health information will significantly benefit prescribers, pharmacists, payers, and patients and improve the quality of health care provided. These requirements align with a reciprocal Medicare Part D requireme ormation will significantly benefit prescribers, pharmacists, payers, and patients and improve the quality of health care provided. These requirements align with a reciprocal Medicare Part D requirement in the Part D and Health IT Standards Final Rule for Part D sponsors, prescribers, and dispensers, when electronically transmitting prescriptions and prescription-related information for covered Part D drugs for Part D eligible individuals, to use a standard in 45 CFR 170.205(b), which includes the NCPDP SCRIPT standard version 2023011. Prescribers, pharmacists, and payers will benefit from the updates to the standards and to the certification criterion through increased standardization and interoperability of electronic prescribing. c. New Real-Time Prescription Benefit Certification Criterion (1) Background We finalized a ‘‘real-time prescription benefit’’ certification criterion in 45 CFR 170.315(b)(4) based on the NCPDP Real-Time Prescription Benefit (RTPB) standard version 13. We also finalized inclusion of this certification criterion in the Base EHR definition in 45 CFR 170.102. We believe the ‘‘real-time prescription benefit’’ certification criterion will increase the use of lso finalized inclusion of this certification criterion in the Base EHR definition in 45 CFR 170.102. We believe the ‘‘real-time prescription benefit’’ certification criterion will increase the use of real-time prescription benefit tools; reduce the costs and complexity of using these tools; and increase competition between vendors, promoting widespread adoption of more effective real-time prescription benefit tools, and helping to lower drug costs for Medicare beneficiaries. Use of real-time prescription benefit tools enables Medicare providers and enrollees to make cost-informed decisions about prescriptions, and a standardized approach will ensure that critical drug and drug price data is available to providers when they need it. The final certification criterion includes the following standards and functional requirements: • Incorporate the NCPDP RTPB standard version 13 and vocabulary standards, RxNorm (45 CFR 170.207(d)(1)) and National Drug Codes (45 CFR 170.207(d)(2)), to enable a user to send and receive patient-specific benefit information, estimated cost information, and product alternatives within the workflow at the point of care, specifically standard transactions: • e a user to send and receive patient-specific benefit information, estimated cost information, and product alternatives within the workflow at the point of care, specifically standard transactions: • Transaction segments and associated data elements for RTPBRequests and RTPBResponse transactions; • Error transaction or RTPBResponse reject code; and • Exclusive use of XML format for all transactions. NCPDP RTPB standard version 13 permits the use of the EDI or XML format for payloads. We have finalized that a Health IT module certified to the certification criterion must enable a user to perform the specified NCPDP RTPB standard version 13 transactions using the XML format. ASTP/ ONC similarly requires that a Health IT Module certified to the ‘‘electronic prescribing’’ certification criterion, which uses the NCPDP SCRIPT standard, use the XML format for payloads. In public comments on ASTP/ONC’s RFI on Pharmacy Interoperability in the HTI–1 Proposed Rule (88 FR 23848) and on ASTP/ONC’s HTI–2 proposed rule (89 FR 63498), there was broad support for use of XML. We do not estimate additional costs to developers to exclusively use XML to implement this certification criterion, as it is HTI–2 proposed rule (89 FR 63498), there was broad support for use of XML. We do not estimate additional costs to developers to exclusively use XML to implement this certification criterion, as it is broadly supported and required as part of the functionally similar ‘‘electronic prescribing’’ certification criterion. The ‘‘real-time prescription benefit’’ certification criterion also requires use of NCPDP RTPB standard version 13 to send and receive patient-specific benefit, estimated cost information, and product alternatives. We do not estimate additional costs to developers to implement the standard and certification criterion in this manner. (2) Costs We estimate costs to certified health IT developers to incorporate the NCPDP RTPB standard version 13 and vocabulary standards, RxNorm (45 CFR 170.207(d)(1)) and National Drug Codes (45 CFR 170.207(d)(2)) to send and receive transaction segments and associated data elements for RTPBRequest and RTPBResponse transactions and the Error transaction. We have updated estimated effort for these tasks from the proposed rule. While the effort per developer and product remains constant, we have updated assumptions about the number of produc ransaction. We have updated estimated effort for these tasks from the proposed rule. While the effort per developer and product remains constant, we have updated assumptions about the number of products that will be impacted by this criterion. Levels of effort are detailed in Tables I.G.12.–05 and 06 and are based on the following assumptions: • Health IT developers will use the same labor costs and data models. Table I.G.12.–05 shows the estimated labor costs per product to develop the certification criterion. We recognize that health IT developer costs will vary; however, our estimates in this section assume all health IT developers will incur the costs noted in Table I.G.12.–06. • We estimate that 199 products certified by 150 developers will certify to the ‘‘real- time prescription benefit’’ criterion. This estimate represents a subset of the total number of estimated health IT developers and certified products we estimated previously. The estimate of 199 products certified by 150 developers is derived as follows. We estimate that, in total, 395 health IT developers will certify 520 health IT products impacted by this final rule. The final rule requires Health IT Modules certif developers is derived as follows. We estimate that, in total, 395 health IT developers will certify 520 health IT products impacted by this final rule. The final rule requires Health IT Modules certified to the ‘‘electronic prescribing’’ certification criterion to certify to the finalized ‘‘real-time prescription benefit’’ certification criterion. We therefore use the estimated number of developers and products that certify to the ‘‘electronic prescribing’’ certification criterion as a proxy for the expected number of developers and products that will certify the proposed ‘‘real- time prescription benefit’’ certification criterion. As of the end of 2024, 38 percent of developers and 38 percent of products were certified to the ‘‘electronic prescribing’’ certification criterion. We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by the proposed certification criterion. • In this final rule, we estimate that 50 percent of the products that will certify to the ‘‘real-time prescription benefit’’ criterion in 45 CFR 170.315(b)(4) have already implemented functionality supporting the NCPDP RTPB sta imate that 50 percent of the products that will certify to the ‘‘real-time prescription benefit’’ criterion in 45 CFR 170.315(b)(4) have already implemented functionality supporting the NCPDP RTPB standard version 13 or will incur de minimis costs that would meet the certification criteria. This assumption differs from the proposed rule and is based on several factors. First, industry has had substantial time and incentive to implement the NCPDP RTPB standard. The standard was published in 2021, allowing several years for industry uptake by January 1, 2028, when the certification criterion will be added to the Base EHR definition. Similarly, CMS requirements for Part D plan sponsors to support the standard were finalized at 42 CFR 423.160(b)(5) with requirements beginning January 1, 2027, so that developers of certified health IT will have additional incentive to begin supporting the standard regardless of the inclusion of the ‘‘real-time prescription benefit’’ criterion in the Certification Program. Given the timing of the finalization of those requirements for Part D plan sponsors and the publication of the HTI–2 Proposed Rule, we were not able to account for its impact on develo cation Program. Given the timing of the finalization of those requirements for Part D plan sponsors and the publication of the HTI–2 Proposed Rule, we were not able to account for its impact on developer behaviors. Second, published reports indicate wide adoption of real-time prescription benefit capabilities. ASTP/ONC analysis of the 2023 American Hospital Association Health Information Technology Supplement indicated that more than half (56.2 percent) of non-federal, acute care hospitals have implemented EHR functionality that integrates health insurer real-time prescription benefit information for all or nearly all payers; another 15.8 percent have implemented such a functionality for a limited set of payers; 17.7 percent have not implemented the functionality; and 10.3 percent of respondents did not know if they had implemented such a system.543 Additional data from 2020 indicated that approximately 20 percent of physicians had access to real-time prescription benefit information. Similarly, according to one source, as of the end of 2022, 98 percent of U.S. prescribers were served by EHRs with 543 https://www.healthit.gov/data/quickstats/ hospital-adoption-real-time-benefit-too Similarly, according to one source, as of the end of 2022, 98 percent of U.S. prescribers were served by EHRs with 543 https://www.healthit.gov/data/quickstats/ hospital-adoption-real-time-benefit-tools. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00745 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 37280 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations access to an available real-time prescription benefit tool, and over half of prescribers used real-time prescription benefit to access medication pricing.544 We believe a substantial portion of those EHRs supported the NCPDP RTPB standard. Third, our market research found multiple tools available in the marketplace from health IT software vendors; health plans; and pharmacy benefit managers (PBMs) indicating that there is choice in the market for these tools.545 546 547 548 549 Conversations with EHR market leaders, indicated that there is variation in adoption and implementation: some have deployed their own tools; some depend on third-party developers to provide these services; and others do not currently deploy a icated that there is variation in adoption and implementation: some have deployed their own tools; some depend on third-party developers to provide these services; and others do not currently deploy a tool to their customers. There is also mixed adoption and perspectives on standard approaches to develop and deploy these tools, with some developers currently supporting the NCPDP RTPB standard, some being supportive of tools using the NCPDP RTPB standard, and others agnostic. Finally, in requiring that Part D plan sponsors implement RTBTs compliant with the NCPDP RTPB standard version 13, CMS stated in the Part D and Health IT Standards Final Rule that ‘‘because Part D sponsors have invested in the hardware, software, and connectivity necessary to utilize RTBTs, we believe that adopting the NCPDP RTPB standard version 13 will impose de minimis cost on the industry and that costs will be largely offset by the advantages and efficiencies associated with interoperability that a standard brings. CMS does not require prescribers to utilize RTBTs, but for prescribers who do utilize RTBTs, we believe that the burden associated with using an RTBT that does not use a standard will be the sam ings. CMS does not require prescribers to utilize RTBTs, but for prescribers who do utilize RTBTs, we believe that the burden associated with using an RTBT that does not use a standard will be the same as using an RTBT that uses NCPDP RTPB standard version 13’’ (89 FR 51262). Similarly, it is likely that many certified health IT products offer RTBT capabilities to support physician and hospital access to real- time prescription benefit information and leverage the NCPDP RTPB standard. We believe this implies de minimis costs to these developers to complete the certification criterion for those products. In this final rule, we therefore assume that, of the 199 products using electronic prescribing, only 100 will incur costs. • According to the May 2024 BLS occupational employment statistics, the mean hourly wage for a ‘‘Software Developer’’ is $69.50.550 As noted previously, we have assumed that overhead costs (including benefits) are equal to 100 percent of pre-tax wages, so the hourly wage including overhead costs is $139.00. TABLE I.G.12.–05—ESTIMATED LABOR HOURS TO DEVELOP REAL-TIME PRESCRIPTION BENEFIT CERTIFICATION CRITERION IN 45 CFR 170.315(B)(4) Task Details Lower bound hou wage including overhead costs is $139.00. TABLE I.G.12.–05—ESTIMATED LABOR HOURS TO DEVELOP REAL-TIME PRESCRIPTION BENEFIT CERTIFICATION CRITERION IN 45 CFR 170.315(B)(4) Task Details Lower bound hours Upper bound hours Remarks Task 1: NCPDP Real-Time Pre- scription Benefit (RTPB) standard version 13 and all associated transactions. Task 2: RxNorm vocabulary stand- ard for relevant transaction seg- ments and associated data ele- ments. Transactions include RTPBRequests, RTPBResponse. Requests in- clude 6 transaction segments and Response includes 5 seg- ments.. 500 1,000 For the 2015 Edition of health IT certification criteria, new transactions were added to the ‘‘electronic prescribing’’ criterion. It was esti- mated that it would require 250–400 labor hours to implement each new transaction. We take a similar approach here. ........................................................ 40 80 RxNorm is widely implemented and is a required vocabulary standard for ‘‘electronic rescribing’’. Mapping using these codes should cre- ate little extra effort to implement in certified Health IT Modules. Task 3: National Drug Codes vo- ........................................................ 40 8 Mapping using these codes should cre- ate little extra effort to implement in certified Health IT Modules. Task 3: National Drug Codes vo- ........................................................ 40 80 NDC is widely implemented and seen as critical for coding drugs. cabulary standard for transaction segments and associated data elements. NDC is now a required part of implementing the NCPDP SCRIPT standard as well as the RTPB standard. Mapping using these codes should create little extra effort to implement in certified Health IT Modules. TABLE I.G.12.–06—TOTAL COST TO DEVELOP REAL-TIME PRESCRIPTION BENEFIT CERTIFICATION CRITERION [2024 Dollars] Activity Estimated cost Lower bound Upper bound Task 1 (100 products) ............................................................................................................................................. Task 2 (100 products) ............................................................................................................................................. Task 3 (100 products) ............................................................................................................................................. $6,950, ............................ Task 3 (100 products) ............................................................................................................................................. $6,950,000 556,000 556,000 $13,900,000 1,112,000 1,112,000 Total (100 products) ......................................................................................................................................... 8,062,000 16,124000 The cost to a health IT developer to develop a Health IT Module certified to the ‘‘real-time prescription benefit’’ criterion ranges from $80,620 to $161,240 per product, on average. Therefore, assuming 100 products, we estimate that the total cost to all health IT developers would, on average, range from $8.1 million to $16.1 million. This would be a one-time cost to developers per product that is certified to the specified certification criterion. We acknowledge that these costs may be passed from health IT developers to their customers (that is, health care providers) during the licensing of their health IT modules. We cannot calculate the per entity costs for health care providers, because we do not know the exact number of health care providers who will oviders) during the licensing of their health IT modules. We cannot calculate the per entity costs for health care providers, because we do not know the exact number of health care providers who will be affect or the extent to which costs will be passed on from developers to providers rather than borne by developers. We expect that health care providers who currently do not have access to an EHR with an RTBT that meets the NCPDP standard version 13 will be disproportionately affected, as these EHRs will bear the brunt of the development costs. 544 https://surescripts.widen.net/s/mvtqvvf5sd/ 2022-national-progress-report#page=1. 545 https://surescripts.com/who-we-serve/ehr- vendors. 546 https://arrivehealth.com/wp-content/uploads/ 2022/11/Arrive-Health-Physician-Insights-Whats- Needed-to-Improve-Prescribing-Workflows.pdf. 547 https://www.optum.com/content/dam/ optum4/resources/pdf/wf2167397_pcs_improving_ prescribing_process.pdf. 548 https://www.humana.com/provider/ pharmacy-resources/tools/real-time-benefit- tool#:∼:text=Real%2DTime%20Benefit%20 Check%20(RTBC,your%20electronic% 20medical%20record%20representative. 549 https://www.express-scripts.com/corporate/ articles/scriptvision ools/real-time-benefit- tool#:∼:text=Real%2DTime%20Benefit%20 Check%20(RTBC,your%20electronic% 20medical%20record%20representative. 549 https://www.express-scripts.com/corporate/ articles/scriptvision-gives-physicians-real-time- access-patient-specific-information. 550 https://data.bls.gov/oes/#/industry/000000. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00746 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 37281 (2) Cost Savings As stated previously, the final revised criterion incorporates the adopted NCPDP RTPB standard version 13 specified in Medicare Part D requirements. Standards alignment is crucial to ensure interoperability between IT systems. Alignment across regulatory requirements is also crucial to ensure that technology used to support electronic prescribing for Part D prescribers implements and uses standards for real-time prescription benefit in similar ways to avoid additional costs to developers and their end users. This eliminates redundancies and reduces inefficiencies in how certified technology rds for real-time prescription benefit in similar ways to avoid additional costs to developers and their end users. This eliminates redundancies and reduces inefficiencies in how certified technology is updated to meet multiple related federal regulations. In 2019, CMS finalized in the ‘‘Modernizing Part D and Medicare Advantage to Lower Drug Prices and Reduce Out-of-Pocket Expenses’’ final rule (84 FR 23832) that Part D plan sponsors must make a real-time benefit tool (RTBT) available to prescribers. Then in 2024, CMS and ASTP/ ONC released the Part D and Health IT Standards Final Rule (89 FR 51238) which adopted the NCPDP RTPB standard version 13 and finalized that RTBTs established by Part D plan sponsors must conform to that standard by January 1, 2027. The certification criterion finalized at 45 CFR 170.315(b)(4) will incorporate published, adopted standards and functional requirements by January 2028, thus promoting interoperability between certified health IT, plans, and PBMs, and helping to deliver on the promising benefits of the real-time ability of providers and their patients to make informed choices about medication costs. Benefits for providers, patients, PBMs, and te nd helping to deliver on the promising benefits of the real-time ability of providers and their patients to make informed choices about medication costs. Benefits for providers, patients, PBMs, and technology developers from this criterion are likely to manifest via multiple pathways. The finalized criterion is likely to result in greater implementation and uptake of RTBTs, and tool implementation can reduce time and effort and improve the accuracy of information, lead to reduced prescription costs for patients and payers, improve medication adherence, and generate other downstream benefits. However, data are not available to estimate the increase in use of RTBTs resulting from finalization of this policy or the resulting benefit to patients. Therefore, we have updated our qualitative description of the benefits from this criterion based on available evidence, some of which was published between the publication of the HTI–2 Proposed Rule and this final rule. We anticipate that provider organizations and healthcare professionals will benefit from the finalization of real-time prescription benefit provisions in the final rule in several ways: • Among the 34.1 percent of hospitals res organizations and healthcare professionals will benefit from the finalization of real-time prescription benefit provisions in the final rule in several ways: • Among the 34.1 percent of hospitals responding to the American Hospital Association Health Information Technology Supplement survey that had not implemented EHR functionality integrating real-time prescription benefit information, many were smaller hospitals located in rural areas.551 Additionally, many provider groups that are not affiliated with hospitals likely have not yet implemented any real-time 551 https://jamanetwork.com/journals/jama- health-forum/fullarticle/2824904. prescription benefit functionality in their EHRs. Finalization of this criterion and inclusion in the Base EHR definition will ensure that real-time prescription benefit information is available for more practices and hospitals that use certified health IT. • Interviews with providers as well as comments on the HTI–2 Proposed Rule from provider organizations reveal that while providers appreciate the current access to RTBTs, they experience inaccurate cost estimates and inappropriate product alternatives. Providers may avoid using RTBTs due to concer ions reveal that while providers appreciate the current access to RTBTs, they experience inaccurate cost estimates and inappropriate product alternatives. Providers may avoid using RTBTs due to concerns that inaccuracies will increase their administrative burden and time burden. We expect that regulations requiring that Part D sponsors, PBMs, and certified health IT developers meet RTPB standards will improve the accuracy of the information, thereby increasing trust in and utilization of RTBTs by providers. • Greater provider use of tools leveraging the NCPDP RTPB standard version 13 due to the final rule may result in prescribers providing more informed choices to their patients and increased efficiencies in prescribing and approving products. Several commenters to on the proposed rule noted that addressing cost and coverage in real-time during the clinical encounter may reduce the frequency of post-visit telephone calls and administrative burden related to utilization management. In a survey of providers commissioned by an RTBT, a majority of respondents stated they need to change or manage a prescription order more than 25 percent of the time after it has been sent to the pharma a survey of providers commissioned by an RTBT, a majority of respondents stated they need to change or manage a prescription order more than 25 percent of the time after it has been sent to the pharmacy.552 When one research hospital’s health system implemented their RTBT, researchers were able to guide prescribers to choose alternatives without prior authorization requirements, convert from drugs covered with restrictions, and/or to convert from drugs not covered to one covered with restrictions.553 Upfront coverage information may also steer providers toward medications that do not require prior authorization when clinically appropriate, thus further reducing paperwork, phone calls, and overall administrative burden. One industry-led study estimates that when clinicians switched to medications that did not require prior authorization, they saved up to 50 minutes on prior authorization requests and denials.554 • ASTP/ONC has heard reports that healthcare organizations currently need to contract with multiple PBMs or RTBT vendors that each uses its own proprietary data exchange/API to obtain cost, coverage, and product alternative information for their patient population. This crea o contract with multiple PBMs or RTBT vendors that each uses its own proprietary data exchange/API to obtain cost, coverage, and product alternative information for their patient population. This creates financial and administrative burden for healthcare organizations related to contracting with each party and maintaining each system. By requiring that certified health IT certified to 45 CFR 170.315(b)(4) support the same 552 https://arrivehealth.com/wp-content/uploads/ 2022/11/Arrive-Health-Physician-Insights-Whats- Needed-to-Improve-Prescribing-Workflows.pdf. 553 https://ncpdpfoundation.org/pdf/NCPDP FoundationRTPBGrant_FinalReport.pdf. 554 https://www.optum.com/content/dam/ optum4/resources/pdf/wf2167397_pcs_improving_ prescribing_process.pdf. standard as PBMs, this final rule will reduce barriers to universal access to price information, resulting in lower burden on healthcare organizations. With information more readily available, RTBT developers may pivot to competing on features and functionality rather than access to specific Part D plan sponsors. We anticipate that patients will benefit from the finalization of real-time prescription benefit provisions in several ways: We and functionality rather than access to specific Part D plan sponsors. We anticipate that patients will benefit from the finalization of real-time prescription benefit provisions in several ways: We expect that finalization of the new certification criterion and its inclusion in the Base EHR definition will increase the availability of RTBTs that support the NCPDP RTPB standard. As a result, more prescribers will have broader access to more accurate price information. Research shows that patients benefit from RTBTs in several ways, and broader access to real-time prescription benefit information will multiply these benefits. Benefits to patients include: • Increased treatment adherence: Studies have shown that patients who pay less for their medications overall have higher rates of medication adherence. A review of interventions to improve medication adherence found that reducing out-of-pocket costs to patients can be an effective mechanism.555 Consistent with this, ASTP/ ONC-affiliated researchers conducted a survey of respondents 65 and older, finding that 20.2 percent reported cost-related medication non-adherence—most often delaying prescription fills, not filling prescription ed researchers conducted a survey of respondents 65 and older, finding that 20.2 percent reported cost-related medication non-adherence—most often delaying prescription fills, not filling prescriptions, or skipping doses.556 Reducing prescription copays and formulary decision support have previously been shown to improve medication adherence,557 558 suggesting that RTBTs may also be a useful mechanism. One retrospective study appears to support this, finding that prescriptions placed using RTBTs were associated with a higher fill rate (79.8 percent vs. 71.7 percent) and lower cancellation rate (9.3 percent vs. 14.9 percent).559 • Lower out-of-pocket costs: In a cluster- randomized trial comparing clinics with versus without access to an RTBT, patients saved $28 per month on medications that had an available lower-cost alternative. Savings were even higher (up to $100 per month) for medications with the highest out-of-pocket costs.560 So far, no studies have evaluated the impact of RTBT use on cost of or access to medical supplies, but there is a strong potential for savings. One study estimated that patients with diabetes may spend up to $2,700 per year on glucose monitoring suppli use on cost of or access to medical supplies, but there is a strong potential for savings. One study estimated that patients with diabetes may spend up to $2,700 per year on glucose monitoring supplies alone, including glucometers, 555 https://www.acpjournals.org/doi/10.7326/ 0003-4819-157-11-201212040-00538. 556 https://jamanetwork.com/journals/ jamanetworkopen/fullarticle/2805012. 557 https://jamanetwork.com/journals/ jamainternalmedicine/fullarticle/409766. 558 https://jamanetwork.com/journals/ jamainternalmedicine/fullarticle/773454. 559 https://www.sciencedirect.com/science/ article/abs/pii/S0002934322005289?via%3Dihub via https://link.springer.com/article/10.1007/ s11606-022-07945-z. 560 https://jamanetwork.com/journals/ jamainternalmedicine/fullarticle/2796059. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00747 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 37282 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations lancets, test strips, and insulin syringes or pen needles.561 • Increased consideration of financial tradeoffs in medical decision-making: An ASTP/ON 7 / Monday, August 4, 2025 / Rules and Regulations lancets, test strips, and insulin syringes or pen needles.561 • Increased consideration of financial tradeoffs in medical decision-making: An ASTP/ONC-affiliated research review notes that 86 percent of providers believe that cost should influence treatment decisions, but barriers to cost conversations include physicians’ knowledge of patients’ cost burdens and lack of information about insurance coverage and prices. In one study of 889 primary care providers and 137,860 medication orders, prescribers changed their medication order 12 percent of the time after viewing an RTBT cost estimate and lower- cost alternative.562 Prescribers were more likely to change their medication order if the potential cost savings were higher. Another retrospective study found that prescribers adjusted the days’ supply of their prescriptions in 44 percent of cases and adjusted quantity (for example, of pills or tablets) in 69 percent of cases, in response to an RTBT’s suggestion.563 Another study, however, did not find changes in the frequency of 90-day supply prescriptions after RTBT use.564 These early findings suggest that once providers see an RTB to an RTBT’s suggestion.563 Another study, however, did not find changes in the frequency of 90-day supply prescriptions after RTBT use.564 These early findings suggest that once providers see an RTBT cost estimate, they consider cost in their medical decision-making. Similarly, work by ASTP/ONC-affiliated researchers has highlighted the desire of patients to have conversations about costs with their prescribers. In one survey, the majority of respondents (79.3 percent) expressed a desire to speak to their physician about the cost of all or some of their medications, with respondents who reported cost-related non-adherence more likely to want to speak with their physician.565 89.5 percent of respondents indicated a desire for physicians to use real-time benefit tools and 89.8 percent indicated a desire to discuss the estimated prices, with greater interest among those with any cost-related nonadherence.566 Similarly, in focus groups with patients, most indicated a desire for physicians to use real- time benefit tools and discuss the estimated prices, with greater interest among those with cost-related nonadherence.567 While other tools such as formulary guides exist that can help s to use real- time benefit tools and discuss the estimated prices, with greater interest among those with cost-related nonadherence.567 While other tools such as formulary guides exist that can help facilitate cost conversations and lead to savings, that information is not real-time and 561 https://www.goodrx.com/conditions/diabetes/ true-cost-of-diabetes?srsltid=AfmBOopd8-vmB- 6TlpDZ1f34I1HxaavmKy-yyhauZ6PxHb FD1qyxmfdY. 562 https://jamanetwork.com/journals/ jamainternalmedicine/fullarticle/2809102. 563 https://www.ajmc.com/view/implementation- and-cost-validation-of-a-real-time-benefit-tool. 564 https://jamanetwork.com/journals/ jamainternalmedicine/fullarticle/2796059. 565 Dusetzina, Stacie B., et al. ‘‘Cost-related medication nonadherence and desire for medication cost information among adults aged 65 years and older in the US in 2022.’’ JAMA Network Open 6.5 (2023): e2314211–e2314211. https://jamanetwork. com/journals/jamanetworkopen/fullarticle/ 2805012. 566 Ibid. 567 Mattingly, T. Joseph, et al. ‘‘ ‘‘Worth it if you could afford it’’: Patient perspectives on integrating real-time benefit tools into drug cost conversations.’’ Journal of the American Geriatrics Society 71.5 ( T. Joseph, et al. ‘‘ ‘‘Worth it if you could afford it’’: Patient perspectives on integrating real-time benefit tools into drug cost conversations.’’ Journal of the American Geriatrics Society 71.5 (2023): 1627–1637. https://agsjournals. onlinelibrary.wiley.com/doi/abs/10.1111/jgs.18226. may not be up to date,568 and patients may lose confidence in estimates or their providers if the provided information proves to be wrong.569 Interviews with providers reveal that access to RTBTs has made them more aware of the cost-related barriers to care that patients face and has made them more willing to discuss costs and consider costs in medical decisions. We anticipate that Medicare Part D plan sponsors and PBMs will benefit from the finalization of the ‘‘real-time prescription benefit’’ criterion and related standards. Medicare Part D plan sponsors are required to implement the NCPDP RTPB standard version 13 by January 1, 2027. By including the ‘‘real-time prescription benefit’’ certification criterion in the Base EHR definition, certified health IT used by almost all hospitals and most office-based physicians will support the standard. As a result, PBMs will be able to provide cost and c criterion in the Base EHR definition, certified health IT used by almost all hospitals and most office-based physicians will support the standard. As a result, PBMs will be able to provide cost and coverage information in a format that EHRs certified to the criterion will be able to consume reducing the need for proprietary or specific APIs. We expect that this will reduce the overall development work required to support sharing of real-time prescription benefit information. We anticipate that developers of certified health IT will benefit from the finalization of the ‘‘real-time prescription benefit’’ criterion and related standards in several ways. Rather than develop proprietary interfaces to integrate with multiple RTPB vendors or PBMs, developers of certified health IT will be able to focus on implementing the standardized approach. Given requirements for Medicare Part D plans to support the NCPDP RTPB standard, health IT products certified to 45 CFR 170.315(b)(4) will be able to access prescription benefit information from all Part D plans. We expect that this will reduce the overall development work required to support broad exchange of prescription benefit information acro access prescription benefit information from all Part D plans. We expect that this will reduce the overall development work required to support broad exchange of prescription benefit information across plans. The cost savings of these modifications are not quantifiable at this time, but we expect the resulting improvements to interoperable exchange of health information to provide significant benefits. Data show that RTBTs are available to nearly all US prescribers through prescribers’ EHRs, though only half use the tool itself.570 The proposed ‘‘real-time prescription benefit’’ certification criterion would standardize tools across all EHRs certified to the criterion and establish a baseline of functionality. This may increase use, but the data show the certification criterion may have a negligible effect on the availability of the tools. Comment: We received no comments regarding the impact analysis of the real-time prescription benefit provisions. Response: The final impact analysis is consistent with the proposed rule and updates costs based on information on the number of products that are likely to require new functionality. Cost estimates were 568 https://councilreports.ama s is consistent with the proposed rule and updates costs based on information on the number of products that are likely to require new functionality. Cost estimates were 568 https://councilreports.ama-assn.org/ councilreports/downloadreport?uri=/ councilreports/n21_cms_report_2.pdf. 569 https://jamanetwork.com/journals/jamanet workopen/fullarticle/2805012. 570 https://surescripts.widen.net/s/mvtqvvf5sd/ 2022-national-progress-report#page=1. updated to reflect wages of software developers as of 2024. d. New Electronic Prior Authorization Certification Criteria We have finalized a set of certification criteria to enable API-based electronic prior authorization for providers in 45 CFR 170.315(g)(31) through (33) that aim to complement and advance the policies that CMS has developed to increase patient, provider, and payer access to information. If health IT developers (including those that support payers or are part of a payer) were to seek testing and certification to these finalized certification criteria, we believe that they would be better positioned to support more effective exchange of prior authorization information. Further, this would help ensure that technology used to sati tification criteria, we believe that they would be better positioned to support more effective exchange of prior authorization information. Further, this would help ensure that technology used to satisfy the reciprocal CMS requirements has been tested for conformance with widely available industry standards designed to support interoperability for each use case. These finalized certification criteria reference a set of API implementation specifications based upon the HL7® FHIR® standard. The new certification criteria also incorporate FHIR capabilities finalized in 45 CFR 170.315(j). The finalized certification criteria would enable users of certified health IT to utilize APIs established under CMS API requirements for the Prior Authorization API (87 FR 76285). These criteria could further enable providers to successfully complete the Electronic Prior Authorization measures finalized by CMS for the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category. We finalize to adopt and reference CMS-recommended implementation specifications for electronic prior authorization within the certification criteria. (1) Costs The new certification ormance category. We finalize to adopt and reference CMS-recommended implementation specifications for electronic prior authorization within the certification criteria. (1) Costs The new certification criteria are as follows: • 45 CFR 170.315(g)(31) Provider prior authorization API—coverage requirements discovery. • 45 CFR 170.315(g)(32) Provider prior authorization API—documentation templates and rules. • 45 CFR 170.315(g)(33) Provider prior authorization API—prior authorization support. Certification criteria (g)(31), (g)(32), and (g)(33) adopt and reference the same recommended implementation specifications that CMS identified in the Interoperability and Prior Authorization Final Rule (FR 8945). The certification criteria provide a predictable and transparent method for health IT developers to test and certify health IT modules that meet the implementation specifications identified by CMS, providing developers seeking to support customers that seek to utilize API meeting CMS requirements a way to demonstrate conformance to their users. Certification criteria (g)(31), (g)(32), and (g)(33) enable bi- directional exchange and transfer of data between payer systems (who must meet CM ments a way to demonstrate conformance to their users. Certification criteria (g)(31), (g)(32), and (g)(33) enable bi- directional exchange and transfer of data between payer systems (who must meet CMS API requirements) and provider systems who receive information from payer systems to inform patient care and facilitate prior VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00748 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 37283 authorization. These certification criteria do not implement CMS finalized API requirements (which only affect payer systems), but the criteria can further enable interoperability between payer and provider systems if adopted by health IT developers. The finalized certification criteria: ‘‘provider prior authorization API—coverage requirements discovery,’’ ‘‘provider prior authorization API—documentation templates and rules’’, and ‘‘provider prior authorization API—prior authorization support’’ have their own level of effort and these estimates are detailed in Tables I.G.12.- 07A, 08A, and 09A tation templates and rules’’, and ‘‘provider prior authorization API—prior authorization support’’ have their own level of effort and these estimates are detailed in Tables I.G.12.- 07A, 08A, and 09A and are based on the following assumptions: • Health IT developers will use the same labor costs and data models. Tables I.G.12.- 05A, 05B, and 05C show the estimated labor costs per product to develop ‘‘provider prior authorization API—coverage requirements discovery,’’ ‘‘provider prior authorization API—documentation templates and rules’’, and ‘‘provider prior authorization API—prior authorization support’’ criteria. We recognize that health IT developer costs will vary; however, our estimates in this section assume all health IT developers will incur the costs noted in Tables I.G.12.- 07B, I.G.12.- 08B, and I.G.12.- 09B. • We estimate that 234 products certified by 189 developers will be affected by our proposal. These estimates are a subset of the total estimated health IT developers and certified products we estimated previously. The estimate of 234 products certified by 189 developers is derived as follows. We estimate that, in total, 395 health IT developers will certify 520 hea nd certified products we estimated previously. The estimate of 234 products certified by 189 developers is derived as follows. We estimate that, in total, 395 health IT developers will certify 520 health IT products impacted by this final rule. However, not all of these developers and products will certify these new criteria. As of the end of 2024, 48 percent of developers and 45 percent of products certified to the ‘‘standardized API criterion for patient and population services’’ certification criterion. We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by these finalized certification criteria. • According to the May 2024 BLS occupational employment statistics, the mean hourly wage for a ‘‘Software Developer’’ is $69.50. As noted previously, we have assumed that overhead costs (including benefits) are equal to 100 percent of pre-tax wages, so the hourly wage including overhead costs is $139. TABLE I.G.12.–07A—ESTIMATED LABOR HOURS TO DEVELOP 45 CFR 170.315(G)(31) PRIOR AUTHORIZATION API— COVERAGE REQUIREMENTS DISCOVERY Task Details Task 1: HL7 FHIR Da Vinci—Coverage Requirements Discovery TABLE I.G.12.–07A—ESTIMATED LABOR HOURS TO DEVELOP 45 CFR 170.315(G)(31) PRIOR AUTHORIZATION API— COVERAGE REQUIREMENTS DISCOVERY Task Details Task 1: HL7 FHIR Da Vinci—Coverage Requirements Discovery Support the request and exchange of information that supports (CRD) Implementation Guide: Version STU 2.0.1—STU 2. Task 2: HL7 CDS Hooks FHIR Implementation Guide version the identification of coverage requirements. ........................................................................................................ 2.0. Task 3: Support for ‘‘order-sign’’ hook .......................................... ........................................................................................................ Notes: The lower and upper bound hours estimated to complete each task are estimates of labor hours required for each product. Lower bound hours Upper bound hours 500 0 75 1,000 1,000 150 TABLE I.G.12.—07B—TOTAL COST TO DEVELOP 45 CFR 170.315(G)(31) [2024 Dollars] Activity Estimated cost Lower bound Upper bound Task 1 (234 products) ............................................................................................................................................. Task 2 ( ost Lower bound Upper bound Task 1 (234 products) ............................................................................................................................................. Task 2 (234 products) ............................................................................................................................................. Task 3 (234 products) ............................................................................................................................................. $16,263,000 0 2,439,450 32,526,000 32,526,000 4,878,900 Total (234 products and 189 developers) ........................................................................................................ Total (1 product and 1 developer) .................................................................................................................... 18,702,450 79,925 69,930,900 298,850 TABLE I.G.12.–08A—ESTIMATED LABOR HOURS TO DEVELOP 45 CFR 170.315(G)(32) PRIOR AUTHORIZATION API— DOCUMENTATION TEMPLATES AND RULES Task Details Lower bound hours Upper bound hours Task 1: HL7 FHIR Da Vinci—Documentation Templates and Rules (DTR) Imple- mentation Guide: Version STU 2.0.1—ST N API— DOCUMENTATION TEMPLATES AND RULES Task Details Lower bound hours Upper bound hours Task 1: HL7 FHIR Da Vinci—Documentation Templates and Rules (DTR) Imple- mentation Guide: Version STU 2.0.1—STU 2 ...................................................... Task 2: Support for the SMART App Launch Framework ‘‘confidential app’’ profile Support ‘‘Full DTR EHR’’ ability to exchange and execute rules to ensure that prior authorization documentation requirements are met .................................................................................................... 500 1,000 0 80 Notes: The lower and upper bound hours estimated to complete each task are estimates of labor hours required for each product. TABLE I.G.12.–08B—TOTAL COST TO DEVELOP 45 CFR 170.315(G)(32) [2024 Dollars] Activity Estimated cost Lower bound Upper bound Task 1 (234 products) ............................................................................................................................................. Task 2 (234 products) ............................................................................................................................................. $16,263,000 0 $32,526,000 2,602, ... Task 2 (234 products) ............................................................................................................................................. $16,263,000 0 $32,526,000 2,602,080 Total (234 products and 189 developers) ........................................................................................................ Total (1 product and 1 developer) .................................................................................................................... 16,263,000 69,500 35,128,080 150,120 VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00749 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 37284 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations TABLE I.G.12.–09A—ESTIMATED LABOR HOURS TO DEVELOP 45 CFR 170.315(G)(33) PRIOR AUTHORIZATION API— PRIOR AUTHORIZATION SUPPORT Task Details Lower bound hours Upper bound hours Task 1: HL7 FHIR Da Vinci—Prior Authorization Support (PAS) Imple- Ability of the API to create and send prior authorization requests and to 500 1,000 mentation Guide: Version STU 2.0.1—STU 2. receive prior authorizat Da Vinci—Prior Authorization Support (PAS) Imple- Ability of the API to create and send prior authorization requests and to 500 1,000 mentation Guide: Version STU 2.0.1—STU 2. receive prior authorization responses. Task 2: Subscriptions R5 Backport Implementation Guide version 1.1.0 Requirements to include: (1) topic-based Subscription support for FHIR 500 1500 (Backport IG). R4 and (2) support of the REST-hook Subscription channel. Task 3: Support R4/B Topic-Based Subscription Profile .......................... Conformance to profile, support for ‘‘must support’’ elements, and use 250 500 Task 4: Support for R4 Topic-Based Subscription Server Capability Support the creation, update, and deletion of Subscription resources in 50 100 Statement. the Capability Statement. of canonical URL of Subscription Topic. Notes: The lower and upper bound hours estimated to complete each task are estimates of labor hours required for each product. TABLE I.G.12.–09B—TOTAL COST TO DEVELOP 45 CFR 170.315(G)(33) [2024 Dollars] Activity Estimated cost Lower bound Upper bound Task 1 (234 products) ........................................................................................................... (G)(33) [2024 Dollars] Activity Estimated cost Lower bound Upper bound Task 1 (234 products) ............................................................................................................................................. Task 2 (234 products) ............................................................................................................................................. Task 3 (234 products) ............................................................................................................................................. Task 4 (234 products) ............................................................................................................................................. $16,263,000 16,263,000 8,131,500 1,626,300 $32,526,000 48,789,000 16,263,000 3,252,600 Total (234 products and 189 developer) .......................................................................................................... Total (1 product and 1 developer) .................................................................................................................... 42,283,800 180,700 100,830,600 430,900 The cost to a health IT developer to develop all t .............................................................................................................. 42,283,800 180,700 100,830,600 430,900 The cost to a health IT developer to develop all three criteria ‘‘provider prior authorization API—coverage requirements discovery’’, ‘‘provider prior authorization API—documentation templates and rules’’, and ‘‘provider prior authorization API—prior authorization support’’ for their Health IT Modules would range from $330,000 to $880,000 per product, on average. Individually, the cost to develop ‘‘Provider prior authorization API—coverage requirements discovery’’ would be $80,000 to $310,000 per product; ‘‘provider prior authorization API—documentation templates and rules’’ $69,000 to $139,000 per product; and ‘‘provider prior authorization API—prior authorization support’’ $181,000 to $431,000 per product. In total, we estimate that for all applicable products (n = 234), the total cost to adopt these criteria for developers of certified health IT would be $77m to $206m. Studies show that prior authorization accounts for $35 billion in annual administrative health care costs.571 This cost is estimated to be proportional among payers, health IT would be $77m to $206m. Studies show that prior authorization accounts for $35 billion in annual administrative health care costs.571 This cost is estimated to be proportional among payers, physician groups, and hospitals. These studies also show that prior authorization is one of the least ‘‘electronic’’ administrative workflows in health care, wherein about 20 percent of transactions are fully electronic compared to claim submission (96 percent) and eligibility and benefit verification (84 percent), respectively.572 Payers and providers have both adopted electronic prior authorization and it has increased from 12 percent to 31 percent from 2018 to 2023, according to other studies.573 574 However, phone and fax are largely used by payers to manage prior authorizations and the peer-to- peer review process for denial appeals.575 Prior authorization poses a large financial and administrative burden on clinicians with large potential savings from improvements to the prior authorization, including movement to a more streamlined, electronic process.576 A 2023 survey found that physicians spent 1 hour per week on average, nursing and other clinical support staff spent about 2. rization, including movement to a more streamlined, electronic process.576 A 2023 survey found that physicians spent 1 hour per week on average, nursing and other clinical support staff spent about 2.5 hours per week on average, and clerical staff spent about 9 hours per week on average completing prior authorization activities.577 This aligns with the findings of Casalino, et al. whose 2009 study first measured prior authorization costs on physician practices.578 However, although the total hours (∼13) per week spent on prior authorization remained the same across these personnel categories, the burden of effort has shifted from frontline clinical staff to support and administrative personnel. The Sahni, et al. (2023) study also shows the range of different personnel who may complete prior authorization in any given practice setting, showing the complexity and range and type of staff 573 https://www.caqh.org/sites/default/files/2022- caqh-index-report%20FINAL%20SPREAD %20VERSION.pdf. 574 https://www.caqh.org/hubfs/43908627/drupal/ 2024-01/2023_CAQH_Index_Report.pdf. 575 https://ascopubs.org/doi/full/10.1200/EDBK_ 100036. 576 https://www.caqh.org/hubfs/43908627/drupal/ 2024-01/2023 574 https://www.caqh.org/hubfs/43908627/drupal/ 2024-01/2023_CAQH_Index_Report.pdf. 575 https://ascopubs.org/doi/full/10.1200/EDBK_ 100036. 576 https://www.caqh.org/hubfs/43908627/drupal/ 2024-01/2023_CAQH_Index_Report.pdf. 577 https://academic.oup.com/healthaffairs 571 https://jamanetwork.com/journals/jama/ scholar/article/2/9/qxae096/7727862. fullarticle/2785480. 572 Ibid. 578 https://www.healthaffairs.org/doi/10.1377/ hlthaff.28.4.w533. needed to process these authorizations.579 This complexity is but one facet of the burden and effort involved in prior authorization that could be ameliorated by standardized, electronic solutions. The American Medical Association (AMA) regularly surveys physicians to understand their prior authorization experience. In 2021, their survey of 1,000 physicians found that the average practice completed 41 prior authorizations per week.580 This effort involved over 13 hours of the average physician and their support staff’s time each week. Furthermore, 2 in 5 physicians report needing to dedicate staff resources, for example registered nurses or other support staff, exclusively toward prior authorizations—findings supported by studies referenced previ in 5 physicians report needing to dedicate staff resources, for example registered nurses or other support staff, exclusively toward prior authorizations—findings supported by studies referenced previously. The AMA published results of their analysis of the latest survey 2024) in early 2025, showing very little has changed in the past 4 years, despite progress in the digitization and automation of other healthcare services and tasks.581 Even as an increasing volume of prior authorization (69 percent in 2023) transactions are fully electronic (via the HIPAA Transaction Standard: ASC X12N 278) or partially electronic (web portals), effort and burden remain high.582 Unpublished results from an ASTP/ONC analysis of American Board for Family 579 https://academic.oup.com/healthaffairs scholar/article/2/9/qxae096/7727862. 580 https://apps.legislature.ky.gov/Committee Documents/7/20788/10%2026%202022 %20Tailor%20-%202021%20AMA %20Physician%20Prior%20Auth%20Survey.pdf. 581 https://www.ama-assn.org/practice- management/prior-authorization/prior- authorization-research-reports. 582 https://www.caqh.org/hubfs/43908627/ drupal/2024-01/2023_CAQH_Index_Report.pdf. VerDate Sep 2014 00:36 Aug 02, 2 org/practice- management/prior-authorization/prior- authorization-research-reports. 582 https://www.caqh.org/hubfs/43908627/ drupal/2024-01/2023_CAQH_Index_Report.pdf. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00750 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 37285 Medicine (ABFM) survey data shows that although most family medicine physicians report using their EHR to conduct prior authorization (that is via a transaction standard or portal), the effort and burden are no different than for those physicians who perform these tasks manually, which supports prior findings reported by Salzbrenner, et al. published only a few years ago.583 584 The current methods, either electronic or manual, to complete a prior authorization are not reducing burden and take precious time away from vital provider- patient interactions. In 2023, the CAQH estimated that the cost to providers of a manual prior authorization approval was $10.97 per claim, while the cost to payers was $3.52 per claim.585 In addition, a policy paper for T In 2023, the CAQH estimated that the cost to providers of a manual prior authorization approval was $10.97 per claim, while the cost to payers was $3.52 per claim.585 In addition, a policy paper for The Hamilton Project calculated that staff time is approximately 25 hours per week in resolving 37 prior authorization adjudications at $20 per hour, which equals $14 per claim as a cost to medical staff.586 Administrative costs per claim vary slightly, and studies show that current electronic methods can reduce the per claim cost of prior authorization, showing that on average a fully electronic prior authorization transaction costs $5.79 for the average provider—nearly half what it costs to do this work manually.587 Based on a survey of 1,147 responses from 100,000 providers, University of Nebraska Medical Center physicians and researchers found it took health plans less time to submit decisions electronically, though providers had similar challenges with electronic prior authorizations as they did with manual prior authorizations.588 Although electronic prior authorization processes exist, they’re not uniformly implemented across plans, creating a hodge podge of options for the avera s they did with manual prior authorizations.588 Although electronic prior authorization processes exist, they’re not uniformly implemented across plans, creating a hodge podge of options for the average practice, who treat patients across numerous plans. Plans may benefit from implementing an electronic prior authorization process that enables providers to transmit authorizations through a portal or other electronic method, but without more uniformity in electronic prior authorization across health plans, providers are left holding the bag on managing a complex web of prior authorization management. The prior authorization API criteria finalized in this final rule will standardize electronic prior authorizations, providing complementary APIs to the APIs plans will be required to establish as part of the CMS final rule (89 FR 8758), enabling interoperable exchange of prior authorization requests (from providers) and decisions (from plans). Several pilots are underway or have 583 [Unpublished manuscript] MH Gabriel, et al. Navigating the Primary Care Physician’s Triple Burden—Health Info Hunting, Prior Authorization, and ’Pajama Time’. 584 https://www.jmcp.org/doi/10.18553/ jmcp.2022 ished manuscript] MH Gabriel, et al. Navigating the Primary Care Physician’s Triple Burden—Health Info Hunting, Prior Authorization, and ’Pajama Time’. 584 https://www.jmcp.org/doi/10.18553/ jmcp.2022.28.10.1121. 585 https://www.caqh.org/hubfs/43908627/drupal/ 2024-01/2023_CAQH_Index_Report.pdf. 586 https://www.hamiltonproject.org/wp-content/ uploads/2023/01/Cutler_PP_LO.pdf. 587 https://www.caqh.org/hubfs/43908627/drupal/ 2024-01/2023_CAQH_Index_Report.pdf. been completed to test the prior authorization API. One pilot, led by Regence, used the HL7 FHIR standard to automate prior authorization.589 Using the SmartAuth app integrated with the Epic EHR, they were able to automatically populate policy criteria and automatically extract clinicals from the EHR. They were able to make immediate determinations on over 90 percent of the requests with nearly all determined that prior authorization was not required. Furthermore, staff realized nearly 68 percent in time savings using this standardized API-based process—time savings that can be directed toward other activities. Whereas, without the use of the app and automated process, providers might wait hours or days just to find out prior a ized API-based process—time savings that can be directed toward other activities. Whereas, without the use of the app and automated process, providers might wait hours or days just to find out prior authorization is not required. In some cases, prior authorization was automatically processed, enabling an immediate decision to prescribe or suggest a treatment. This was all enabled using an API built using the FHIR standard—the exact method and standard finalized in these prior authorization criteria. Setting a standard, electronic method to facilitate payer and provider exchange and the prior authorization of certain treatments and medications can reduce overall time and effort for payers and providers alike. A standard, uniform process can also be replicated across many IT systems, ensuring reliable interoperability between systems and more certainty to providers that they can electronically submit a prior authorization to a payer and receive a response congruent with their technology and workflow. When two partners in exchange have technology that adopt the same methods of communication (in this case automated, machine-based), they can connect and share information with lower effo and workflow. When two partners in exchange have technology that adopt the same methods of communication (in this case automated, machine-based), they can connect and share information with lower effort and more consistency. In the same manner that a recipient must have an email server in order to receive email, a sender cannot transmit a FHIR-based payload via a DaVinci API to a recipient who does not have a similarly compliant FHIR server. A fragmented system where providers may need to follow different procedures and processes for different payers increases burden on providers and administrators and reduces their time to treat and manage patients. These finalized prior authorization APIs for providers, therefore, shall enable cost savings to developers of certified health IT and their provider users and benefits in the form of time savings to provider users of this technology. (2) Comparative Analysis Between Standardized and Non-standardized Application Programming Interfaces for Electronic Prior Authorization There are important trends towards the wide uptake of electronic prior authorization in the absence of this rule, including requirements on certain CMS-regulated health p lectronic Prior Authorization There are important trends towards the wide uptake of electronic prior authorization in the absence of this rule, including requirements on certain CMS-regulated health plans to support standards-based prior authorization APIs and for providers to report on Electronic Prior Authorization measures that require them attest to using prior authorization APIs within the Promoting Interoperability program and MIPS Promoting Interoperability performance category. In addition, a recent pledge by insurers to support electronic prior authorization indicates clear momentum towards building electronic prior authorization that developers of certified health IT will likely be pushed to meet by their customers.590 Due to this market momentum, we believe that in a baseline state absent this rule, these trends would lead developers of certified health IT to develop further support for prior authorization APIs to ensure their customers can attest to the Promoting Interoperability measures. However, absent this rule, health plans may not have incentive to closely follow open implementation guides to implement prior authorization APIs. As a result, developers of certified bility measures. However, absent this rule, health plans may not have incentive to closely follow open implementation guides to implement prior authorization APIs. As a result, developers of certified health IT working to support their customers connections to these APIs may be required to largely overhaul connectivity they build to connect customers to each plan, leading to high marginal costs, some of which will be passed through to their customers. We believe this would result in development of a limited amount of connectivity between providers and payers at high marginal costs so that: (1) developers of certified health IT would implement connectivity with only a small fraction of health plans; and (2) low overall reduction in provider time and effort because of limited connectivity between providers through their certified health IT and health plans. In this context, we believe the gains from economies of scale of standardizing point-to- point connections between plan and provider IT systems and the demand for a standardized prior authorization method that can reduce, if not wholly automate this process, will create savings to developers of certified health IT and health IT pu IT systems and the demand for a standardized prior authorization method that can reduce, if not wholly automate this process, will create savings to developers of certified health IT and health IT purchases. First, developers of certified health IT who must build and deploy this technology will realize savings as they will only need to support one method to electronically connect their systems to plan systems to process a prior authorization transaction. Health plans would in turn have incentives to ensure they are able to engage in prior authorization transactions according to this standard and related implementation guides. This method can also support automation of prior authorization and enable innovation from the broader digital health ecosystem to partner with developers of certified health IT and deliver solutions powered by artificial intelligence and other modern technologies that can further reduce effort to develop and deploy this technology.591 Finally, health IT purchasers who must learn multiple prior authorization methods and the contact information for a multitude of health plans will realize savings as their EHR can be configured to process prior authorizations mo s who must learn multiple prior authorization methods and the contact information for a multitude of health plans will realize savings as their EHR can be configured to process prior authorizations more seamlessly and with reduced manual intervention.592 These APIs can reduce the time and expense to train staff on prior authorization and focus their efforts on a single, standardized method adopted by 590 https://www.hhs.gov/press-room/kennedy-oz- cms-secure-healthcare-industry-pledge-to-fix-prior- authorization-system.html. 591 https://showroom.epic.com/stage? id=35&t=23&c=259. 588 https://www.ncbi.nlm.nih.gov/pmc/articles/ 589 https://www.cms.gov/files/document/hiig- 592 https://www.cms.gov/files/document/hiig- PMC10332446/. august-2023-isc-speaker-slides.pdf. august-2023-isc-speaker-slides.pdf. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00751 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 37286 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations most, if not all health plans that cover their patients. As described previously, prior authorization today is completed l Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations most, if not all health plans that cover their patients. As described previously, prior authorization today is completed through a mix of fully and partially electronic, as well as manual methods (for example, fax, phone calls). This is due in part to the range of ways health plans process prior authorizations, as well as the technological capabilities of medical practices and hospitals. Some plans may provide portals to process prior authorizations, others do not. Some providers may have a health IT product that enables electronic messaging of prior authorization requests, but plans’ ability to process these electronic prior authorizations varies. Some medical practices may default to manual methods, because they perceive no real difference in electronic or manual methods, as some data also show. Health IT products enable electronic processing to deliver a helpful service to their customers, but they face much effort enabling prior authorization between their myriad customers and the hundreds of health plans that provide health care coverage nationwide. Without a standardized, and potentially automatabl uch effort enabling prior authorization between their myriad customers and the hundreds of health plans that provide health care coverage nationwide. Without a standardized, and potentially automatable prior authorization process, health IT product developers are left configuring 1-to- 1 connections (if available) between their customers and the health plans that cover their patient population, and providers are left deciding between two sub-optimal methods for prior authorization. So, if the 300+ CMS-covered plans all configure their IT systems to share prior authorization decisions via a standards-based API, as finalized by the CMS Interoperability and Prior Authorization Final Rule (89 FR 8758) and the providers that serve patients covered by these plans (nearly all providers and patients nationwide) have certified health IT configured to these same standards-based APIs, the IT developers can all build infrastructure in the same fashion, ensuring electronic prior authorization interoperability. At present, one health IT product would need to support multiple methods of prior authorization and, if using electronic methods, would have to support diverging methods of transactional operability. At present, one health IT product would need to support multiple methods of prior authorization and, if using electronic methods, would have to support diverging methods of transactional prior authorization or via an online portal, all of which require some manual provider intervention to complete. In the section ‘‘Comparative Analysis Between Standardized and Non-standardized Application Programming Interfaces’’ of this impact analysis, we analyzed the alternatives with using a standards-based API and a non- standards-based API to enable interoperable connections between an average health IT product and one or many third-party apps that can connect to that health IT product to provide additional digital services beyond the capabilities of the health IT product to the health IT product users. This model has been applied to the standards-based electronic prior authorization APIs we adopt in this final rulemaking. The CMS Interoperability and Prior Authorization Final Rule (89 FR 8758) affects 300+ plans nationwide. All those plans will need to connect to the dozens of health IT products that serve the hundreds of hospitals and thousands of practice groups that serve Med 89 FR 8758) affects 300+ plans nationwide. All those plans will need to connect to the dozens of health IT products that serve the hundreds of hospitals and thousands of practice groups that serve Medicare and Medicaid patients nationwide. When a health IT product that serves many types of clients across multiple states needs to get prior authorization from the dozens (if not hundreds) of plans that serve their patients, implementing a standards-based process to exchange that information generates savings—both for health IT products who have to establish those connections for their clients and plans who need to send and relay prior authorization decisions to their enrollees’ providers. In Table I.G.12.–10 we replicate the API comparison model and replace the ‘‘app’’ connections with ‘‘plan’’ connections, as the prior authorization APIs connect health IT product and plan IT systems, rather than health IT product and app IT systems. Table I.G.12.–10 compares the costs to perform prior authorization using standards-based and non-standards-based APIs. As shown in the API comparison model, the base build for the standards-based prior authorization APIs is more expensive than a non-stand thorization using standards-based and non-standards-based APIs. As shown in the API comparison model, the base build for the standards-based prior authorization APIs is more expensive than a non-standards- based or functional API. However, as more and more connections are done between the health IT product and one or more health plans, the smaller marginal costs of connecting via a standards-based API outweigh the costs of connecting to the same number of health plan IT systems via a non- standards-based API. If the average health IT product were to connect to 20 health plan IT systems (fewer than 10 percent of CMS- sponsored plans nationwide), the combined costs of the base infrastructure of the standards-based APIs and the effort to connect to all 20 IT systems would incur lower costs, compared to the cost of the same effort and base infrastructure for non- standards-based APIs. When we extrapolate connections to 300 or more plans, the savings could be immense across all certified API developers. If all certified API products were to connect to 300 CMS-sponsored health plans, the savings in 2024 dollars would exceed $1.8 billion. For all products to connect to 50 plans, the total I developers. If all certified API products were to connect to 300 CMS-sponsored health plans, the savings in 2024 dollars would exceed $1.8 billion. For all products to connect to 50 plans, the total cost savings would be nearly $200 million. TABLE I.G.12.–10—COMPARISON OF COSTS TO INTEGRATE HEALTH PLAN PRIOR AUTHORIZATION APIS VIA AN HEALTH IT PRODUCT Standards-based Not standards-based Differential costs Average hours 1 Cumulative hours Average hours Cumulative hours Cumulative hour difference Cumulative hours for all certified API Products 2 Cost difference ($) 3 Base build .................................. 1 Plan ......................................... 10 Plans ..................................... 20 Plans 4 ................................... 25 Plans ..................................... 50 Plans ..................................... 300 Plans ................................... 4,300 50 500 1,000 1,250 2,500 15,000 4,300 4,350 4,800 5,300 5,550 6,800 19,300 350 250 2,500 5,000 6,250 12,500 75,000 350 600 2,850 5,350 6,600 12,850 75,350 $128,477,700 3,950 121,972,500 3,750 63,425,700 1,950 ¥1,626,300 ¥50 ¥34,152,300 ¥1,050 ¥196,782,300 ¥6,050 ¥56,050 ¥13,115,700 ¥1,823,0 000 6,250 12,500 75,000 350 600 2,850 5,350 6,600 12,850 75,350 $128,477,700 3,950 121,972,500 3,750 63,425,700 1,950 ¥1,626,300 ¥50 ¥34,152,300 ¥1,050 ¥196,782,300 ¥6,050 ¥56,050 ¥13,115,700 ¥1,823,082,300 924,300 877,500 456,300 ¥11,700 ¥245,700 ¥1,415,700 Notes: (1) Average hours are the midpoint of the lower (2,375) and upper (6,330) bound hours calculated for the combined 45 CFR 170.315(g)(31), (g)(32), and (g)(33) criteria. (2) Total = (Cumulative Hour Difference) X (All Certified API Products, n=234). (3) Total $ = (Cumulative Hours for All Certified API Products) X (Wage Rate Used in this Impact Analysis, $139). (4) On average, the breakeven point for a certified API product to adopt a standards-based API (versus a non-standards-based API) is 20 plans. Formula: 50 × +4,300 = 250 × +350; × = 3,950/200; × = 19.75. Standardization enables certified health IT to support an API to connect many if not all plans, increasing the number of prior authorization transactions that can be done via the API and reducing manual effort to issue a prior authorization and receive a determination. We estimated that that for all applicable products (n = 234), the total cost to adopt these criter ne via the API and reducing manual effort to issue a prior authorization and receive a determination. We estimated that that for all applicable products (n = 234), the total cost to adopt these criteria for developers of certified health IT would be $77 million to $206 million or a median cost of $142 million. As the APIs are designed to connect to health plan systems to conduct prior authorization, the effort to complete these individual health plan connections is important to consider when weighing the option of a standards-based or non-standards- based API. Considering the potential cost differences estimated in Table I.G.12.- 10 of all applicable products connecting to 20 or more health plans to conduct prior authorization using the adopted standards- based APIs, we estimate that the initial effort to adopt the standards-based APIs outweigh VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00752 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 37287 the cost of adopting non-standards APIs, given the larger marginal cost 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 37287 the cost of adopting non-standards APIs, given the larger marginal cost of connecting to one or more plans via a non-standards- based API. This initial investment in standards-based APIs is an overall cost saver to developers of certified APIs. The requirements will also have a measurable quantifiable benefit on the time it takes to process a prior authorization and the use of these time savings toward more productive and health-focused activities for patients and providers alike. (3) Benefits The finalized prior authorization API criteria for providers, which adopt and reference the same standards recommended in CMS’s Interoperability and Prior Authorization Final Rule (89 FR 8758) and incorporate these standards to enable interoperability with the CMS-finalized APIs health plans are required to adopt, will ensure bi-directional exchange between plans and providers and, importantly, enable automation of these tasks—capabilities not enabled by current electronic prior authorization tools.593 In the final rule (89 FR 8758), CMS assessed the overall benefit viders and, importantly, enable automation of these tasks—capabilities not enabled by current electronic prior authorization tools.593 In the final rule (89 FR 8758), CMS assessed the overall benefit and level of effort to standardize prior authorization and payer exchange.594 CMS estimates, over a ten-year period, that physician groups and hospitals could face reduced costs of $15.3 billion if they adopted this technology to standardize prior authorization. As stated, these finalized certification criteria adopt standards and functionality identified by CMS and we believe that these certification criteria, if adopted by developers of certified health IT, would help ensure that the technology are developed and deployed in a standard, uniform way, culminating in the expected benefits to physician groups and hospitals estimated by CMS in their final rule. CMS assessed the impact of the Interoperability and Prior Authorization Final Rule on the Medicare-covered clinician population, inclusive of physician groups and hospitals. CMS estimated 199,543 physician groups (based on data in the CY 2023 Physician Fee Schedule proposed rule (87 FR 46410)) and 7,911 hospitals, which includes gen sive of physician groups and hospitals. CMS estimated 199,543 physician groups (based on data in the CY 2023 Physician Fee Schedule proposed rule (87 FR 46410)) and 7,911 hospitals, which includes general acute care hospitals (3,150), critical access hospitals (1,350), and outpatient hospitals (3,411), which are generally ambulatory surgical centers and urgent care/emergency care facilities. The number of physician groups (199,543) was based off a rough estimation using the total count of clinicians CMS estimated to be affected by the CY23 PFS (87 FR 46410) (1,596,340) divided by the median number of clinicians per practice (8) as estimated in Muhlestein and Smith.595 This is a novel method of calculating physician groups, as other sources, including CMS’s own National Downloadable File of doctors and clinicians and the AHRQ Compendium of Health Systems both put physician groups more at an average of 225,000.596 597 Despite the differences, we agree that a truly accurate estimate of the total physician groups affected by the CMS and ASTP/ONC final rules is difficult to calculate. Nevertheless, we believe the CMS estimate of 199,543 is reasonable and based on reliable data. CMS’ cal e total physician groups affected by the CMS and ASTP/ONC final rules is difficult to calculate. Nevertheless, we believe the CMS estimate of 199,543 is reasonable and based on reliable data. CMS’ calculation of hospitals is accurate and is much easier to calculate, as it is based on reliable data from multiple sources that mutually validate these counts. However, for our analysis, we focus on the count of general acute care (3,150) and critical access (1,350) hospitals (4,500 in total), and exclude the count of outpatient hospitals (3,411) used in the CMS analysis. The CMS model assumed an immediate impact on MIPS-eligible clinicians and groups in 2027, based on the implementation date established in the prior authorization final rule. It also assumed an incremental impact on other covered clinicians, up to 50 percent of these groups by 2036. CMS described the reasoning to limit the total benefit estimate to 50 percent of groups, but also noted that according to the National Center for Health Statistics’ National EHR Survey (NEHRS) (which is fielded in partnership with ASTP/ONC), 78 percent of physicians report using a certified EHR. As CMS notes, this statistic could indicate an r Health Statistics’ National EHR Survey (NEHRS) (which is fielded in partnership with ASTP/ONC), 78 percent of physicians report using a certified EHR. As CMS notes, this statistic could indicate an underestimation of the benefits, that is estimating the impact to only 50 percent of practice groups may underestimate the full benefits of the adoption of electronic prior authorization under the final rule. We agree with CMS’ assessment and believe that the combined impact of both the CMS final rule and this final rule would be greater. We believe additional benefits would be gained as prior authorization APIs are widely adopted by developers of certified health IT supporting a wide range of sites of service. We believe the combined impact would realize time savings for a broader scope of providers from a standardized and automatable prior authorization process. We further describe these likely additional benefits in this regulatory impact analysis. In addition, CMS treated the hospital prior authorization experience the same as the average physician group experience in the CMS final rule for the purposes of calculating cost and benefits. At the time, this approach was supported by a prior authorization experience the same as the average physician group experience in the CMS final rule for the purposes of calculating cost and benefits. At the time, this approach was supported by a need to develop a more general single estimate for average savings. However, we believe that the actual average hospital and physician group experience are not equal in part due to the nature of care provided in different facility types and also due to economies of scale. Hospitals deliver more services covered by prior authorization (for example, surgeries, diagnostics, medications—particularly pain medication, and durable medical equipment), and the average hospital treats and discharges more patients per annum than the average practice. The volume of patients encounters, treatments, and diagnostics among hospitals should merit greater weighting in the impact of these technology policies on the operations of U.S. hospitals. Given that nearly all hospitals use a certified EHR and report for PI annually, we estimate that from 2027 to 2031 all 95 percent hospitals will have this API technology, with all hospitals adopting the technology by 2036.598 599 Table I.G.12.–11 shows the counts for PI annually, we estimate that from 2027 to 2031 all 95 percent hospitals will have this API technology, with all hospitals adopting the technology by 2036.598 599 Table I.G.12.–11 shows the counts of patient visits across US hospitals. As of 2020, a portion of all hospitals, general and acute care hospitals comprise the vast majority of all hospital-based care (86 percent), with over 700 million outpatient visits occurring each year. These outpatient visits occurred at 4,500 hospitals nationwide. That is just under 160,000 visits per hospital per year. As hospitals are often open continuously throughout the year, that is about 436 patients per day or 18 per hour on average. Very large hospitals are likely to see many more patients on average, compared to smaller hospitals. In contrast, as shown in Table I.G.12.–12, as of 2019, nationally all physician offices had over 1 billion patient office visits. Although we cannot be truly precise, we consider the total outpatient visits from the NCHS/NAMCS data to be representative of the number of practice groups included in the CMS analysis and used here in this analysis as well (199,543). Using these counts, we estimate that each pract the NCHS/NAMCS data to be representative of the number of practice groups included in the CMS analysis and used here in this analysis as well (199,543). Using these counts, we estimate that each practice has over 5,000 patient visits per year (considering 250 working days a year, that is about 20 patient visits per group per year.) It should be recognized that the NAMCS does exclude some physician types from its scope, so its accounting may underestimate the true count of all outpatient visits inclusive of the physician groups within scope of this analysis. If we were to adjust this count by 25 percent, total outpatient visits would increase to 6,500 per annum per practice. TABLE I.G.12.–11—HOSPITAL ENCOUNTER TYPES BY ALL AND GENERAL AND CRITICAL ACCESS HOSPITALS Encounter type All hospitals General and crit- ical access hospitals % of All Per general hospital (n=4,500) Outpatient visits ................................................................................... 834,034,000 717,159,000 86 159,368 593 https://www.federalregister.gov/documents/ 2024/02/08/2024-00895/medicare-and-medicaid- programs-patient-protection-and-affordable-care- act-advancing-interoperability. 594 htt ,159,000 86 159,368 593 https://www.federalregister.gov/documents/ 2024/02/08/2024-00895/medicare-and-medicaid- programs-patient-protection-and-affordable-care- act-advancing-interoperability. 594 https://www.federalregister.gov/documents/ 2024/02/08/2024-00895/medicare-and-medicaid- programs-patient-protection-and-affordable-care- act-advancing-interoperability. 595 https://www.healthaffairs.org/doi/10.1377/ hlthaff.2016.0130. 596 https://data.cms.gov/provider-data/dataset/ mj5m-pzi6. 597 https://www.ahrq.gov/chsp/data-resources/ compendium-2023.html. 598 https://www.healthit.gov/data/quickstats/ national-trends-hospital-and-physician-adoption- electronic-health-records. 599 https://data.cms.gov/provider-data/dataset/ f4ga-b9gx. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00753 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 37288 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations TABLE I.G.12.–11—HOSPITAL ENCOUNTER TYPES BY ALL AND GENERAL AND CRITICAL ACCESS HOSPITALS—Continued Encounter type All hospitals General and crit- ical access hospitals % of All Per genera egulations TABLE I.G.12.–11—HOSPITAL ENCOUNTER TYPES BY ALL AND GENERAL AND CRITICAL ACCESS HOSPITALS—Continued Encounter type All hospitals General and crit- ical access hospitals % of All Per general hospital (n=4,500) Hospital admissions ............................................................................. Length of stay ...................................................................................... 33,357,000 6.3 31,393,000 5.6 94 ........................ 6,976 ........................ Total days ..................................................................................... 210,149,100 175,800,800 84 39,066 Source: NCHS/Division of Analysis and Epidemiology, Hospital admission, average length of stay, outpatient visits, and outpatient surgery by type of ownership and size of hospital, 2020, https://data.cdc.gov/National-Center-for-Health-Statistics/DQS-Hospital-admission-average-length-of- stay-outp/rear-2epk/about_data. Note: General and critical access hospitals are tabulated using the nonfederal, community hospital category. 4,500 total hospitals of this type. TABLE I.G.12.–12—PHYSICIAN GROUP OUTPATIENT VISITS, 2019 Encounter type All physicians Primary tals are tabulated using the nonfederal, community hospital category. 4,500 total hospitals of this type. TABLE I.G.12.–12—PHYSICIAN GROUP OUTPATIENT VISITS, 2019 Encounter type All physicians Primary care Percentage of all Per practice (n=199,543) Outpatient visits ................................................................................... 1,036,484,000 521,466,000 50 5,194 Source: NCHS, National Ambulatory Medical Care Survey, 2019 National Summary Tables, https://www.cdc.gov/nchs/data/ahcd/namcs_sum- mary/2019-namcs-web-tables-508.pdf. Note: 199,543 practices. Taken together, these results show that hospitals and physician groups are not equal in the volume of patients seen: 160,000 per hospital vs 5,000 (to 6,500) per practice group, which is a difference of over 20 times more per year. We know less about what portion of patient visits involve prior authorization. However, based on what we know about the range of services a hospital provides versus the average practice group, it is likely the same burden per 100 patients if not more. Comparing this to studies that show that the overall costs for prior authorization are equal for all hospital and physician groups, we bel p, it is likely the same burden per 100 patients if not more. Comparing this to studies that show that the overall costs for prior authorization are equal for all hospital and physician groups, we believe this final rule in combination with the requirements in the CMS Interoperability and Prior Authorization Final Rule should create broad estimated time savings to both physician groups and hospitals at fairly similar levels.600 If EHR technology that supports these prior authorization APIs are adopted at similar rates across physician groups and hospitals, the time savings in total to practices and hospitals should be fairly equal, rather than the average cost savings to practices and hospitals being fairly equal, as has been previously finalized.estimated. This final rule shows the broader impact that adoption across both physician groups and general hospitals of these provider prior authorization APIs might have. As an estimated 78 percent of physicians use a certified EHR (and about an equal number of physician office visits occur at a practice that uses a certified EHR) and over 96 percent of general hospitals use a certified EHR, we believe the adoption of these certified APIs an equal number of physician office visits occur at a practice that uses a certified EHR) and over 96 percent of general hospitals use a certified EHR, we believe the adoption of these certified APIs that can connect in an interoperable manner with over 300 health plans nationwide will generate significant cost savings to the health care providers who deliver the vast majority of daily, outpatient care nationwide.601 602 TABLE I.G.12.–13—TOTAL HOURS (IN MILLIONS) AND DOLLARS (IN MILLIONS) SAVED OVER 10 YEARS AS A RESULT OF HOSPITALS ADOPTING CERTIFIED PRIOR AUTHORIZATION APIS Year Savings per hospital (hour), average Savings per hospital ($), average Percentage of hospitals adopting the APIs Total number of hospitals Reduced hours per years (millions), average Reduced cost per years ($ millions), average 2027 ......................................................................................... 2028 ......................................................................................... 2029 ......................................................................................... 2030 ......................................................................................... 203 ...... 2029 ......................................................................................... 2030 ......................................................................................... 2031 ......................................................................................... 2032 ......................................................................................... 2033 ......................................................................................... 2034 ......................................................................................... 2035 ......................................................................................... 2036 ......................................................................................... 4,410 4,410 4,410 4,410 4,410 4,410 4,410 4,410 4,410 4,410 315,390 315,390 315,390 315,390 315,390 315,390 315,390 315,390 315,390 315,390 75 80 85 90 96 97 98 99 99 100 4,500 4,500 4,500 4,500 4,500 4,500 4,500 4,500 4,500 4,500 Total .................................................................................. ................ .................... .................... .................... 14.9 15.9 16.9 17.9 19.1 19.2 19. tal .................................................................................. ................ .................... .................... .................... 14.9 15.9 16.9 17.9 19.1 19.2 19.4 19.6 19.6 19.8 182 1,064 1,135 1,206 1,277 1,362 1,377 1,391 1,405 1,405 1,419 13,043 Notes: The savings per hospital and overall reflect an average of the lower bound and upper bound estimates of the amount of prior author- ization per hospital as compared to per physician group. The lower bound assumes the average hospital experiences 10x the prior authorization burden of the average physician group. The upper bound assume the average hospital experiences 20x the prior authorization burden of the av- erage physician group. The average is 15x the amount of burden. 600 https://jamanetwork.com/journals/jama/ fullarticle/2785480. 601 https://www.healthit.gov/data/quickstats/ national-trends-hospital-and-physician-adoption- electronic-health-records. 602 https://www.cdc.gov/nchs/data/ahcd/namcs_ summary/2019-namcs-web-tables-508.pdf. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00754 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 amcs_ summary/2019-namcs-web-tables-508.pdf. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00754 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 37289 TABLE I.G.12.–14—DIFFERENCE IN TOTAL HOURS (IN MILLIONS) AND DOLLARS (IN MILLIONS) SAVED OVER 10 YEARS AS A RESULT OF HOSPITALS ADOPTING CERTIFIED PRIOR AUTHORIZATION APIS Year Provider API, API effect, hours per year (in millions) Provider API, API effect, dollars per year (in millions) 2027–2036 ............................................................................................................................................................... 177.7 12,686 Notes: The difference subtracts the number of hours and dollars saved accounted for in CMS Rule (89 FR 8758) from the total hours and dol- lars saved as totaled in Table C6. TABLE I.G.12.–15—TOTAL HOURS (MILLIONS) AND DOLLAR (MILLIONS) SAVED OVER 10 YEARS AS A RESULT OF PHYSICIAN GROUPS ADOPTING CERTIFIED PRIOR AUTHORIZATION APIS Year Savings per practice (hour) Savings per practice ($) Percentage of practice ) AND DOLLAR (MILLIONS) SAVED OVER 10 YEARS AS A RESULT OF PHYSICIAN GROUPS ADOPTING CERTIFIED PRIOR AUTHORIZATION APIS Year Savings per practice (hour) Savings per practice ($) Percentage of practices adopting the APIs Total number of practices Reduced hours per year (in mil- lions) Reduced cost per year ($ in mil- lions) 2027 ......................................................................................... 2028 ......................................................................................... 2029 ......................................................................................... 2030 ......................................................................................... 2031 ......................................................................................... 2032 ......................................................................................... 2033 ......................................................................................... 2034 ......................................................................................... 2035 ......................................................................................... 2036 ............... .................................................................................... 2035 ......................................................................................... 2036 ......................................................................................... 294 294 294 294 294 294 294 294 294 294 21,026 21,026 21,026 21,026 21,026 21,026 21,026 21,026 21,026 21,026 27.5 33.2 39.0 44.7 50.5 56.2 62.0 67.7 73.5 79.2 199,543 199,543 199,543 199,543 199,543 199,543 199,543 199,543 199,543 199,543 Total .................................................................................. ................ .................... .................... .................... 16.1 19.5 22.9 26.2 29.6 33.0 36.3 39.7 43.1 46.5 313 1,151.7 1,392.9 1,634.2 1,875.4 2,116.7 2,357.9 2,599.2 2,840.4 3,081.7 3,322.9 22,373 Notes: The savings reflect adjustment in the percentage of practices adopting the finalized prior authorization APIs, as adjusted from the per- centage accounted for in CMS Rule (89 FR 8758). The average savings per practice remain the same. TABLE I.G.12.–16—DIFFERENCE IN TOTAL HOURS (MILLIONS) AND DOLLARS (MILLIONS) SAVED OVER 10 YEARS AS A RESULT OF PHYSICIAN GROUPS ADOP le (89 FR 8758). The average savings per practice remain the same. TABLE I.G.12.–16—DIFFERENCE IN TOTAL HOURS (MILLIONS) AND DOLLARS (MILLIONS) SAVED OVER 10 YEARS AS A RESULT OF PHYSICIAN GROUPS ADOPTING CERTIFIED PRIOR AUTHORIZATION APIS Year Provider API API effect, hours per year (millions) Provider API API effect, $ per year (millions) 2027 ......................................................................................................................................................................... 2028 ......................................................................................................................................................................... 2029 ......................................................................................................................................................................... 2030 ......................................................................................................................................................................... 2031 ........................................................................................................................................................ .......................................... 2031 ......................................................................................................................................................................... 2032 ......................................................................................................................................................................... 2033 ......................................................................................................................................................................... 2034 ......................................................................................................................................................................... 2035 ......................................................................................................................................................................... 2036 ......................................................................................................................................................................... Total ..................................................................................................... ............................................................................................ Total .................................................................................................................................................................. 0.0 2.3 4.5 6.6 8.6 10.6 12.3 14.1 15.7 17.2 91.8 0.0 161.9 318.4 468.9 613.3 750.9 881.5 1,004.3 1,119.1 1,225.1 6,543.4 Notes: The difference subtracts the number of hours and dollars saved accounted for in CMS Rule (89 FR 8758) from the total hours and dol- lars saved as totaled in Table C8. As shown in tables I.G.12.–13–16, we find that there are significant time savings that can be realized from the adoption of both the CMS-finalized prior authorization APIs (for plans) and the ASTP/ONC-finalized prior authorization API health IT criteria (for providers). Importantly we find the difference in savings estimated in CMS final rule (89 FR 8758) from the updated calculations we estimate previously. In total we find $12.7 billion in cumulative cost savings from 2027 to 2036 for hospitals (Table I.G.12.–14) and $6.5 billion in additional cumulative savings from 2027 to 2036 for practice groups (Table I.G.12.–16), totaling $19. in cumulative cost savings from 2027 to 2036 for hospitals (Table I.G.12.–14) and $6.5 billion in additional cumulative savings from 2027 to 2036 for practice groups (Table I.G.12.–16), totaling $19.2 billion in total savings from the additional impact of finalizing these standardized prior authorization APIs for providers. (4) Benefits Implementing these capabilities will deliver a more automated and seamless experience for clinicians and medical professionals across physician practice groups and general hospitals, who provide critical frontline, primary, and emergency care to tens of millions of Americans every year. As studies show that existing prior authorization processes (including current electronic methods) create undue burden and take precious time away from patient care and personal conversations between patients, their caregivers, and providers, these standardized APIs will reduce these burdens and free time to providers and patients to focus on health and well-being, not paperwork and overhead. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00755 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 paperwork and overhead. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00755 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 37290 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations Comment: We received no comments regarding the impact analysis of the API requirements. Response: The final impact analysis updates costs based on new information on the number of products that are likely to require new functionality and the impact of these finalized policies. Cost estimates were updated to reflect wages of software developers as of 2024. Quantified savingsbenefits were updated in this final impact analysis, given new information and availability of data. e. New Certification Criteria for Modular API Capabilities We finalized two new criteria: 45 CFR 170.315(j)(20): ‘‘Workflow triggers for decision support interventions—clients’’ and 45 CFR 170.315(j)(21): ‘‘Subscriptions— client’’, which would be available for certification based on certain contexts or other programs requiring the use of the specified certified capabilities. The new certification criteria create flexibility ’’, which would be available for certification based on certain contexts or other programs requiring the use of the specified certified capabilities. The new certification criteria create flexibility to test and certify Health IT Modules and introduce new technical functionalities with synergy with other certification criteria finalized in this final rule. Finalized certification criteria in 45 CFR 170.315(j)(20) and 45 CFR 170.315(j)(21) reflect new technical functionalities. However, this final rule does not require adoption of these new certification criteria by health IT developers. These two certification criteria are referenced as conditional or as required functionality for other finalized certification criteria. The impact analyses for these two finalized certification criteria assess the expected level of effort and development tasks required to adopt the new certification criteria, but do not assume required adoption for these certification criteria for any current developers of certified health IT. We separately estimate the cost and benefits for the specific certification criteria that reference these modular functionalities in order to create a clear correlation of cos of certified health IT. We separately estimate the cost and benefits for the specific certification criteria that reference these modular functionalities in order to create a clear correlation of cost and benefits to requirements, as well as to avoid duplication within our estimates. (1) Workflow Triggers for Decision Support Interventions We finalized adoption of the HL7 Clinical Decision Support (CDS) Hooks Release 2.0.1 in 45 CFR 170.215(f) as a mandatory compliance prerequisite to facilitate API- driven workflow triggers for decision support interventions in 45 CFR 170.315(j)(20). This requirement would establish adoption of a ‘‘hook’’-based pattern for initiating clinical decision support, either allowing decision support results to be integrated seamlessly into a provider’s EHR workflow or launching an interactive CDS application from within the workflow. (a) Costs TABLE I.G.12.—17. ESTIMATED LABOR HOURS TO DEVELOP WORKFLOW TRIGGERS FOR DECISION SUPPORT INTERVENTIONS 45 CFR 170.315(J)(20) Task Details Lower round hours Upper round hours Remarks Task 1: HL7 CDS Hooks Release 2.0.1 ............ CDS Hooks FHIR Release 2.0.1 in 45 CFR 0 1.000 First balloted over 5 years ago, CDS 315(J)(20) Task Details Lower round hours Upper round hours Remarks Task 1: HL7 CDS Hooks Release 2.0.1 ............ CDS Hooks FHIR Release 2.0.1 in 45 CFR 0 1.000 First balloted over 5 years ago, CDS Hooks in 170.215(f) as a prerequisite to facilitate API- driven CDS workflow triggers in 45 CFR 170.3315(j)(20). mature but still in trial use. We finalize a minimal implementation of the standard and believe this implementation is likely sup- ported and deployed by some developers, but not all in some fashion. Notes: The lower and upper bound hours estimated to complete each task are estimates of labor hours required for each product. This proposal may also impose some costs and challenges that are not easily quantifiable. While some scholars posit that CDS Hooks are in a state of relative immaturity compared to other HL7 standards, their growing popularity suggests further standards development for CDS Hooks is likely on the horizon. Part of the developing maturity level comes from exploration of new hook definitions for workflow trigger points, security best practices, response analytics, and suggestions for improved interoperability for items like recommended prescriptions.603 Bas oration of new hook definitions for workflow trigger points, security best practices, response analytics, and suggestions for improved interoperability for items like recommended prescriptions.603 Based on public feedback on ASTP/ONC’s request for information in the HTI–1 Proposed Rule, some commenters expressed concerns for slow real-world adoption of CDS Hooks. Although CDS Hooks is reasonably mature, many developers and other organizations are not using this technology. One review of ‘‘original studies describing development of specific CDS tools or infrastructures’’ using FHIR, SMART, CQL, and CDS Hooks published in 2021 found that only 18 percent used CDS Hooks. These authors note that it is too early to determine a mature-state uptake rate of CDS Hooks based on the current early stage and the limited number of studies.604 Many commenters were partial to certification requirements for specific use 603 https://www.ncbi.nlm.nih.gov/pmc/articles/ PMC8324242/. 604 https://www.ncbi.nlm.nih.gov/pmc/articles/ cases, such as prior authorization, immunization decision support, evidenced- based treatment decisions and alternatives, etc. Notably, prior authorization was indicated to be a .nih.gov/pmc/articles/ cases, such as prior authorization, immunization decision support, evidenced- based treatment decisions and alternatives, etc. Notably, prior authorization was indicated to be a high priority use case. Furthermore, one market leading EHR developer indicated in RFI comments that it does not believe certification of CDS Hooks is necessary to materially advance interoperability and supports allowing market forces to drive adoption. The developer noted they make CDS Hooks available but is utilized by only about 10 percent of end users, potentially due to its effect of slowing clinician workflows. There are examples of successful implementations of CDS Hooks, but these implementations are not without challenges. In one study by Dolin et al., the researchers developed a pharmacogenomics CDS service prototype based on the FHIR and CDS Hooks standards.605 The researchers noted that they were able to meet the goals of deploying a functional prototype but identified some challenges with CDS Hooks. They found that the process for executing an authenticated query request in a system outside of the EHR from a trigger within the EHR was very complex and noted constraints o hallenges with CDS Hooks. They found that the process for executing an authenticated query request in a system outside of the EHR from a trigger within the EHR was very complex and noted constraints on the variety of actionable CDS recommendation types that could be returned from the decision support tool. One randomized control trial assessed the cost of using CDS Hooks to clinician end- users. CDS Hooks was shown to be more burdensome to end-users, requiring many clicks and a greater level of effort than other EHR prompts. Based on a cluster RCT in an emergency department using Epic, single- click prompts, such as ordering HIV screening laboratory tests, take less effort and clicks than CDS Hooks. Single-click app launching occurs with some CDS Hooks; for example, the Epic EHR uses CDS Hooks for pop-up alerts. However, single-click launching does not happen for all Epic prompts, including Storyboard prompts (patient summaries that are always displayed in the EHR for an individual patient). Instead of a single click, the user must click on the Storyboard prompt and then eventually access the hyperlink to the hook. Accessing the hyperlink is nonintuitive to most users, which is why ient). Instead of a single click, the user must click on the Storyboard prompt and then eventually access the hyperlink to the hook. Accessing the hyperlink is nonintuitive to most users, which is why the researchers in this study requested Epic to have a single-click for CDS Hooks in the Storyboard prompt.606 These challenges faced by end-users suggest that there may be room for growth in CDS Hooks implementations. (b) Benefits The benefits of these modifications are not quantifiable at this time, but we expect the resulting improvements to interoperable exchange of health information to significantly benefit clinician end users and improve the quality of health care provided. Clinicians will benefit from the updates to the standard and to the certified criterion through increased standardization and PMC8416232/. 605 https://pubmed.ncbi.nlm.nih.gov/30605914/. 606 Ibid. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00756 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 37291 interoperability of CDS Hooks technology. Cert 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 37291 interoperability of CDS Hooks technology. Certified use of CDS Hooks is expected to facilitate more patient-specific results from clinical decision support tools, assisting providers in a more patient-centric approach to care. Based on public feedback on ASTP/ONC’s request for information in the HTI–1 Proposed Rule, commenters were generally more supportive of certification criteria for adoption of the v2.0 specification of FHIR CDS Hooks, as opposed to v1.0. Many also preferred ASTP/ONC supporting narrow certification criteria related to a particular user guide, as we have specified in this proposal. Although many argue that adoption is growing slowly for CDS Hooks, based on comments received as part of the HTI–1 Proposed Rule RFI, a commenter expressed support for modular certification of this technology, noting the belief that it is significantly developed and mature, as well as citing the fact that the CMS Interoperability and Prior Authorization Proposed Rule is dependent on this technology (a large-scale implementation examp s significantly developed and mature, as well as citing the fact that the CMS Interoperability and Prior Authorization Proposed Rule is dependent on this technology (a large-scale implementation example). Based on public feedback on ASTP/ONC’s request for information in the HTI–1 Proposed Rule, commenters were generally supportive of the utility of CDS Hooks and believed the specification to be mature. Based on the literature, use of CDS Hooks appears to offer utility to patients and providers. In a randomized control trial of CDS Hooks’ feasibility to increase use of SMART on FHIR apps, researchers found that CDS Hooks may lead to reduction in usability issues with SMART on FHIR apps.607 This would likely create better access to clinical care recommendations on its own, in addition to more complex decision logic due to the use of an external CDS engine through CDS Hooks services that could then be implemented using native EHR CDS approaches. These improvements in CDS could subsequently improve care decisions and patient outcomes. Another likely benefit of CDS Hooks is time savings from interoperability because (similar to SMART on FHIR apps), CDS Hooks can be shared across EHR pla y improve care decisions and patient outcomes. Another likely benefit of CDS Hooks is time savings from interoperability because (similar to SMART on FHIR apps), CDS Hooks can be shared across EHR platforms and health systems. Beyond the opportunity for clinical decision support tools to facilitate reduced cognitive load and timesaving for providers, another anticipated benefit of CDS Hooks is that it gives clinicians using CDS tools the option to utilize these tools only when needed.608 Relatedly, use of CDS Hooks allows decision support results to be accessed at any time during a patient’s care, and not only when the results of an ordered lab are received. This is expected to benefit patients by reducing the risk of adverse health events and preventing duplication of lab tests. Due to resulting increases in care efficiency, this is also expected to lead to notable cost-savings for health systems utilizing the CDS Hooks tool. In one RCT trial, researchers aimed to assess the feasibility of using CDS Hooks to increase SMART on FHIR app utilization. The researchers found that developer burden can be reduced because CDS Hooks use FHIR as both the data model and exchange standard and ty of using CDS Hooks to increase SMART on FHIR app utilization. The researchers found that developer burden can be reduced because CDS Hooks use FHIR as both the data model and exchange standard and the same logic is used for SMART on FHIR apps. Morgan et al, advise that to justify the significant time and resources EHR developers must invest in building the hook, development should focus on single-click prompts where the end-user burden is most likely to benefit (however, developer effort is not quantified in this RCT).609 CDS Hooks largely addresses this concern, as it uses a hyperlink to SMART on FHIR app that allows users to launch the app in a single click.610 (2) Subscriptions We finalized that Health IT Modules certified to 45 CFR 170.315(j)(21) demonstrate support for FHIR-based API subscriptions according to the HL7 FHIR Subscriptions Framework. FHIR Subscriptions allow a server to notify a user when information has been added or altered within a record, as well as offers the ability to submit a payload with a notification. We finalized the adoption of the Subscriptions R5 Backport Implementation Guide version 1.1.0 (Backport IG) in 45 CFR 170.215(h)(1) as a baseline stan ability to submit a payload with a notification. We finalized the adoption of the Subscriptions R5 Backport Implementation Guide version 1.1.0 (Backport IG) in 45 CFR 170.215(h)(1) as a baseline standard conformance requirement in 45 CFR 170.315(j)(21), and, specifically, that Health IT Modules support the requirements specified in section ‘‘1.6 Topic-Based Subscriptions—FHIR R4’’ of the implementation specification in 45 CFR 170.215(h)(1). We further finalized the following requirements for certification of a Health IT Module in 45 CFR 170.315(j)(21): • Conformance to the ‘‘R4/B Topic-Based Subscription’’ profile detailed in the as specified in the Backport IG. • Conformance to the ‘‘R4 Topic-Based Subscription Server Capability Statement’’ of the implementation specification in 45 CFR 170.215(h)(1), including. Server support of create, update and delete interactions for Subscription resources (create and delete are currently optional). • At a minimum, support of the REST- hook Subscription channel as a means of notifying subscribers of the availability of new results. (a) Costs Each of the defined tasks has a corresponding level of effort, and these estimates are detailed in Tab ription channel as a means of notifying subscribers of the availability of new results. (a) Costs Each of the defined tasks has a corresponding level of effort, and these estimates are detailed in Table I.G.12.–18: TABLE I.G.12.—18. ESTIMATED LABOR HOURS TO DEVELOP SUBSCRIPTIONS 45 CFR 170.315(J)(21) Task Details Task 1: Implementation of Subscriptions R5 Backport Implemen- tation Guide version 1.1.0 (Backport IG). Requirements to include: (1) topic-based Subscription support for FHIR R4 and (2) support of the REST-hook Subscription channel. Task 2: Support R4/B Topic-Based Subscription Profile .............. Conformance to profile, support for ‘‘must support’’ elements, Task 3: Support for R4 Topic-Based Subscription Server Capa- Support the creation, update, and deletion of Subscription re- bility Statement. sources in the Capability Statement. and use of canonical URL of Subscription Topic. Notes: The lower and upper bound hours estimated to complete each task are estimates of labor hours required for each product. Lower bound hours Upper bound hours 500 250 50 1,500 500 100 We acknowledge that these costs may be difficult to estimate given the current state of FHIR Subscription hours required for each product. Lower bound hours Upper bound hours 500 250 50 1,500 500 100 We acknowledge that these costs may be difficult to estimate given the current state of FHIR Subscription implementations. ASTP/ ONC requested public comment in a ‘‘FHIR Subscriptions Request for Information’’ in the HTI–1 Rule proposal, and some commenters expressed concern for cost. A commenter specifically indicated a concern for costs to implement and a need for more information on relevant use cases, given a current lack of real-world implementations of FHIR Subscriptions according to the specifications in the R5 Backport IG. Further, we do not know the extent to which costs and benefits may balance one another. Subscriptions are intended to provide active event notifications to users immediately when data in a record is updated or changed.611 However, academic literature on this topic does not currently reflect concrete benefits of this notification service. We request comment on these cost estimates, in particular the burden hours and necessary tasks to develop this functionality. (b) Benefits The benefits of these modifications are not quantifiable at this time, but we expect the cost estimates, in particular the burden hours and necessary tasks to develop this functionality. (b) Benefits The benefits of these modifications are not quantifiable at this time, but we expect the resulting improvements to interoperable exchange of health information to significantly benefit patients, providers, and health care workers and improve the quality of health care provided. Currently, patient access and decision support applications need to periodically poll 45 CFR 170.315(g)(10)-certified APIs to check for 607 https://www.ncbi.nlm.nih.gov/pmc/articles/ 609 https://www.ncbi.nlm.nih.gov/pmc/articles/ 611 https://build.fhir.org/ig/HL7/fhir-subscription- PMC9382378/. 608 https://www.ncbi.nlm.nih.gov/pmc/articles/ PMC7233102/. PMC9382378/. 610 Ibid. backport-ig/. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00757 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 37292 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations updates to patient records. Using the HL7 FHIR Subscriptions Framework, these apps can receive notifications when relevant updates are available. 147 / Monday, August 4, 2025 / Rules and Regulations updates to patient records. Using the HL7 FHIR Subscriptions Framework, these apps can receive notifications when relevant updates are available. This means that patient apps and decision support apps can have more timely, real-time access to the latest records, ensuring that they always have the most up-to-date information. The current API polling model requires applications to make requests to the server, even when there are no updates available. This can result in unnecessary network traffic and resource utilization. Using HL7 FHIR Subscriptions, applications receive notifications when updates are available, and can use these notifications to make server queries to receive patient record updates, reducing the overall network traffic and resource usage. Provider applications can similarly benefit by receiving real-time notifications to update decision support modules and other supporting services. The FHIR Subscriptions IG has a maturity level of 3 (on a 5-point Likert scale) and is currently in Trial Use. Although it has been deemed ready for use in production systems, it has not seen widespread use in production.612 Accordin aturity level of 3 (on a 5-point Likert scale) and is currently in Trial Use. Although it has been deemed ready for use in production systems, it has not seen widespread use in production.612 According to the HL7 website, this would mean that the ‘‘FMM2 + the artifact has been verified by the work group as meeting the Conformance Resource Quality Guidelines; has been subject to a round of formal balloting; and has at least 10 distinct implementer comments recorded in the tracker drawn from at least 3 organizations resulting in at least one substantive change.’’ 613 The HL7 website further states that subscribers (in this case, developers) typically would not need to implement many channel types, so it is unlikely that these developers would spend a significant portion of time with trial and error.614 We specifically require support only for the REST-hook channel for modular certification in 45 CFR 170.315(j)(21). We note in the proposal that this channel uses the RESTful model, is used extensively in the FHIR standard, and is considered the lowest bar for implementation. Given these points, we believe the burden to developers who wish to achieve modular certification in 45 CFR 170. extensively in the FHIR standard, and is considered the lowest bar for implementation. Given these points, we believe the burden to developers who wish to achieve modular certification in 45 CFR 170.315(j)(21) to be minimized. As a note, no academic literature has been found that assesses end-user burden of event notifications/Subscriptions R5 Backport IG. Although the literature does not highlight clear, quantifiable benefits of FHIR Subscription services, we anticipate FHIR Subscriptions to ease interorganizational transactions through the functionality to transmit a payload along with a notification, as well as to reduce the burden of reporting across several public health use cases. Subscriptions are expected to be relevant in clinical, public health, administrative, and research use cases. The public was asked to provide comments on ASTP/ONC’s FHIR subscriptions request for information in the HTI–1 rule proposal, and responses were considered in the development of proposals pertaining to FHIR subscriptions in HTI–2. Commenters generally noted that the FHIR version R5 Backport IG as a better option for implementation guidance than the R4B IG. Feedback received also included re ining to FHIR subscriptions in HTI–2. Commenters generally noted that the FHIR version R5 Backport IG as a better option for implementation guidance than the R4B IG. Feedback received also included recommendations to start with small defined use cases and a subset of topics thought to be most beneficial. Comment: We received no comments regarding the impact analysis of the modular API requirements. Response: The final impact analysis is consistent with the proposed rule and updates costs based on information on the number of products that are likely to require new functionality. Cost estimates were updated to reflect wages of software developers as of 2024. f. Revisions to Real World Testing Requirements We finalized updates to the Real World Testing Condition of Certification at 45 CFR 170.405(a) to include the criteria in 45 CFR 170.315(g)(31), (g)(32), and (g)(33), and criteria in 45 CFR 170.315(j)(20), and (j)(21). This rule also finalizes a new certification criterion, 45 CFR 170.315(b)(4), which as a 45 CFR 170.315(b) criterion is considered part of real world testing. We estimate costs for developers of certified health IT to plan, conduct, and report on this new testing. (1 315(b)(4), which as a 45 CFR 170.315(b) criterion is considered part of real world testing. We estimate costs for developers of certified health IT to plan, conduct, and report on this new testing. (1) Costs We assume, as 45 CFR 170.315(j)(20) is required to be certified as part of 45 CFR 170.315(g)(31) and 45 CFR 170.315(j)(21) is required to be certified as part of 45 CFR 170.315(g)(33), that the full cost of conducting real world testing for 45 CFR 170.315(g)(31) and 45 CFR 170.315(g)(33) would include testing for 45 CFR 170.315(j)(20) and 45 CFR 170.315(j)(21), as these are dependent criteria. Therefore, we do not estimate separate costs to conduct real world testing for 45 CFR 170.315(j)(20) and 45 CFR 170.315(j)(21). In the Cures Final Rule (85 FR 25642), we finalized the Real World Testing Condition of Certification at 45 CFR 170.405(a). The condition applied to 23 certification criteria at the time of finalization. In the Cures Rule, we estimated that it would cost per developer on average $109,557 annually to comply with the condition and conduct real world testing for the applicable criteria.615 The original impact estimates for real world testing included costs per devel r on average $109,557 annually to comply with the condition and conduct real world testing for the applicable criteria.615 The original impact estimates for real world testing included costs per developers to (i) design a testing approach and submit plan; (ii) prepare staff and environments to collect data; (iii) perform testing; and (iv) collect results and prepare/submit report. We estimated these costs would be annual to align with annual reporting requirements. Averaging this overall, we estimate the cost per criterion per developer to plan, conduct, and report for real world testing to be $4,763.616 For the new criteria added to real world testing finalized in this rule, we estimate a lower incremental cost to complete real world testing for these new criteria, considering that some real world testing costs ((i) through (iv) noted previously) would be less or de minimis given existing investments into the infrastructure and capacity to conduct real world testing for other criteria. Specifically, we assume that the additional effort to design a testing approach and submit a plan will be limited to the effort to design a testing approach for new criteria (90 percent of task cost . Specifically, we assume that the additional effort to design a testing approach and submit a plan will be limited to the effort to design a testing approach for new criteria (90 percent of task cost) and assume the effort to submit the plan (10 percent of task cost or 3 percent of the total real world testing cost) will be de minimis, as this is work already conducted by the average developer for existing reporting requirements. We also assume that the additional effort to collect results and prepare and submit the report will be de minimis (20 percent of overall RWT cost per developer). We estimate that work to prepare staff and environments and perform testing will be net new for these criteria, as we assume they require net new infrastructure and capacity-building to conduct real world testing. Therefore, we consider that 23 percent of the original cost to conduct real world testing per developer to not apply toward the addition of new criteria to real world testing, and that the incremental cost of new real world testing requirement would be roughly 75 percent of the original estimated cost. Per criterion and per developer that equals $3,667.617 We must also consider wage inf incremental cost of new real world testing requirement would be roughly 75 percent of the original estimated cost. Per criterion and per developer that equals $3,667.617 We must also consider wage inflation associated with the increase in labor rates for staff in 2025 and beyond, compared to labor rates used to estimate real world testing in the Cures Rule. We estimate an average 21 percent wage inflation across all labor categories included in the Cures Rule (Table I.G.12.–19). TABLE I.G.12.–19—WAGE INFLATION FOR ALL REAL WORLD TESTING LABOR CATEGORIES, 2017–2024 Labor category 2017 wage 2024 wage Wage inflation Computer Systems Analysts ....................................................................................................... Information Security Analysts ...................................................................................................... Software Developers ................................................................................................................... Database Administrators ............................................................................................................. Network and Computer Systems Administrators .. ................... Database Administrators ............................................................................................................. Network and Computer Systems Administrators ........................................................................ Computer Network Architects ...................................................................................................... 89 96 107 86 83 104 108 103 139 103 97 131 21.0% 7.1 29.9 20.1 17.2 25.6 612 https://build.fhir.org/subscriptions.html. 613 https://build.fhir.org/versions.html#maturity. 614 https://build.fhir.org/subscriptions.html. 615 https://www.federalregister.gov/d/2020-07419/ 616 Formula: $109,557/23 = $4,763. 617 Formula: $4,763 × (1–0.23) = $3,667 p-3125. VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00758 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 37293 TABLE I.G.12.–19—WAGE INFLATION FOR ALL REAL WORLD TESTING LABOR CATEGORIES, 2017–2024—Continued Labor category 2017 wage 2024 wage Wage inflation Computer Occupations, All Oth s and Regulations 37293 TABLE I.G.12.–19—WAGE INFLATION FOR ALL REAL WORLD TESTING LABOR CATEGORIES, 2017–2024—Continued Labor category 2017 wage 2024 wage Wage inflation Computer Occupations, All Other ................................................................................................ Computer Network Support Specialists ....................................................................................... All .......................................................................................................................................... 88 65 90 112 77 109 27.5 17.8 21.1 Note: Rates from Bureau of Labor Statistics occupational employment statistics. 2017 rates copied from 85 FR 25642. 2024 from: https:// data.bls.gov/oes/#/industry/000000. Using this cost inflation, we estimate, using all the figures described previously and presented in Table I.G.12.–20 that new annual costs for real world testing will total $3.3 million. However, these costs, would not be incurred at the same time. Developers of certified health IT would be required to meet new 45 CFR 170.315(b)(4) requirements by January 1, 2028. Therefore, related reports and results would not be requir urred at the same time. Developers of certified health IT would be required to meet new 45 CFR 170.315(b)(4) requirements by January 1, 2028. Therefore, related reports and results would not be required until the following year after certification. We assume, beginning in 2027, developers would incur costs to plan, prepare, and report real world testing for this criterion. 45 CFR 170.315(g)(31), (g)(32), and (g)(33), however, do not have a specific certification timeline, but we assume that most developers will certify by January 1, 2027 to comply with current CMS timelines for eligible clinicians, eligible hospitals, and critical access hospitals to report on Electronic Prior Authorization measures during 2027 Promoting Interoperability program year reporting periods. We assume, beginning in 2027, developers would incur costs to plan, prepare, and report real world testing for these criteria. TABLE I.G.12.–20—ANNUAL REAL WORLD TESTING COST FOR 45 CFR 170.315(g)(31), (g)(32), AND (g)(33) AND 45 CFR 170.315(b)(4) Criterion Per criterion cost New criterion cost (%) Number of de- velopers Cost inflation (labor rate) Total cost (per annum) 45 CFR 170.315(b)(4) ......................... 3) AND 45 CFR 170.315(b)(4) Criterion Per criterion cost New criterion cost (%) Number of de- velopers Cost inflation (labor rate) Total cost (per annum) 45 CFR 170.315(b)(4) .......................................................... 45 CFR 170.315(g)(31) ........................................................ 45 CFR 170.315(g)(32) ........................................................ 45 CFR 170.315(g)(33) ........................................................ 4,763 4,763 4,763 4,763 77% 77 77 77 150 189 189 189 21% 21 21 21 $696,414 877,481 877,481 877,481 All .................................................................................. ........................ ........................ ........................ ........................ 3,328,857 Notes: Number of developers based on estimates included in respective impact analyses for 45 CFR 170.315(b)(4), (g)(31), (g)(32), and (g)(33). Formula: [($4,763 × (1¥0.23)) × Ndeveloper]/(1–0.21) = Total cost per annum per criterion. (2) Benefits We estimated benefits for the original finalization of real world testing as part of the Cures Rule (85 FR 25642) and believe the addition of these new criteria to real world testing wil (2) Benefits We estimated benefits for the original finalization of real world testing as part of the Cures Rule (85 FR 25642) and believe the addition of these new criteria to real world testing will provide additional transparency and awareness of the benefit of these criteria toward improvements in interoperability and how they are deployed in real world settings. g. Corrections for HTI–2 Final Rule Corrections for the HTI–2 Final Rule correct erroneous updates and omissions to the CFR and do not create additional burden and effort. 13. Finalization of the Provisions of the FY 2025 IFC In section XI.C. of the preamble of this final rule, we are finalizing the provisions of the FY 2025 IFC that implemented revised Medicare wage index values for FY 2025, established a transitional payment exception for low wage hospitals significantly impacted by those revisions, and made conforming changes to the hospital IPPS and LTCH PPS payment rates for FY 2025 to reflect the removal of the low wage index hospital policy following the appellate court decision in Bridgeport Hosp. v. Becerra. As discussed in greater detail in that section, after consideration of public comments we are finalizi wage index hospital policy following the appellate court decision in Bridgeport Hosp. v. Becerra. As discussed in greater detail in that section, after consideration of public comments we are finalizing the provisions of that IFC without modification. In the FY 2025 IFC (89 FR 80414 through 804020), we presented an impact analysis to illustrate the effects of the provisions of that IFC on hospitals’ FY 2025 payments by comparing the total estimated change in payments under the FY 2025 IFC and the total estimated change in payments from the FY 2025 IPPS/LTCH PPS final rule, as corrected. This analysis shows the effects of the removal of the low wage index hospital policy and the application of the transition policy, along with the also include the conforming changes to the rates and factors established in that IFC (for example, the outlier threshold). We estimate that acute care hospitals will experience an increase of approximately $41 million in FY 2025 due to the provisions of the FY 2025 IFC. This change is primarily due to the application of the non-budget neutral transitional payment exception policy. The estimated change in operating payments is approximately $37 million (dis 2025 IFC. This change is primarily due to the application of the non-budget neutral transitional payment exception policy. The estimated change in operating payments is approximately $37 million (discussed in section VI.A. of the FY 2025 IFC). The estimated change in capital payments is approximately $3 million (discussed in section VI.B. of the FY 2025 IFC). The total differs from the sum of the components due to rounding. Table I of section VI.A. of the FY 2025 IFC and Table II of section VI.B. of the FY 2025 IFC demonstrate the estimated redistributional impacts of the provisions of the FY 2025 IFC. As noted previously and as discussed in greater detail in that section, after consideration of public comments as discussed in greater detail in section XI.C. of the preamble of this final rule, we are finalizing the provisions of that IFC without modification. For additional details, refer to the Regulatory Impact Analysis in section VI. of the FY 2025 IFC (89 FR 80414 through 804020). 13. Finalization of the Provisions of the FY 2025 IFC In section XI.C. of the preamble of this final rule, we are finalizing the provisions of the FY 2025 IFC that implemented revised Medicare wage i 13. Finalization of the Provisions of the FY 2025 IFC In section XI.C. of the preamble of this final rule, we are finalizing the provisions of the FY 2025 IFC that implemented revised Medicare wage index values for FY 2025, established a transitional payment exception for low wage hospitals significantly impacted by those revisions, and made conforming changes to the hospital IPPS and LTCH PPS payment rates for FY 2025 to reflect the removal of the low wage index hospital policy following the appellate court decision in Bridgeport Hosp. v. Becerra. As discussed in greater detail in that section, after consideration of public comments we are finalizing the provisions of that IFC without modification. In the FY 2025 IFC (89 FR 80414 through 804020), we presented an impact analysis to illustrate the effects of the provisions of that IFC on hospitals’ FY 2025 payments by comparing the total estimated change in payments under the FY 2025 IFC and the total estimated change in payments from the FY 2025 IPPS/LTCH PPS final rule, as corrected. This analysis shows the effects of the removal of the low wage index hospital policy and the application of the transition policy, along with the al the FY 2025 IPPS/LTCH PPS final rule, as corrected. This analysis shows the effects of the removal of the low wage index hospital policy and the application of the transition policy, along with the also include the VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00759 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 37294 Federal Register / Vol. 90, No. 147 / Monday, August 4, 2025 / Rules and Regulations conforming changes to the rates and factors established in that IFC (for example, the outlier threshold). We estimate that acute care hospitals will experience an increase of approximately $41 million in FY 2025 due to the provisions of the FY 2025 IFC. This change is primarily due to the application of the non-budget neutral transitional payment exception policy. The estimated change in operating payments is approximately $37 million (discussed in section VI.A. of the FY 2025 IFC). The estimated change in capital payments is approximately $3 million (discussed in section VI.B. of the FY 2025 IFC). The total differs from the sum of the components due to rounding. Table I of section VI.A. of the FY 2025 IF pital payments is approximately $3 million (discussed in section VI.B. of the FY 2025 IFC). The total differs from the sum of the components due to rounding. Table I of section VI.A. of the FY 2025 IFC and Table II of section VI.B. of the FY 2025 IFC demonstrate the estimated redistributional impacts of the provisions of the FY 2025 IFC. As noted previously and as discussed in greater detail in that section, after consideration of public comments as discussed in greater detail in section XI.C. of the preamble of this final rule, we are finalizing the provisions of that IFC without modification. For additional details, refer to the Regulatory Impact Analysis in section VI. of the FY 2025 IFC (89 FR 80414 through 804020). H. Effects on Hospitals and Hospital Units Excluded From the IPPS As of July 2025, there were 94 children’s hospitals, 11 cancer hospitals, 6 short term acute care hospitals located in the Virgin Islands, Guam, the Northern Mariana Islands, and American Samoa, 1 extended neoplastic disease care hospital, and 11 RNHCIs being paid on a reasonable cost basis subject to the rate-of-increase ceiling under § 413.40. (In accordance with § 403.752(a) of the regulation, RNHC d neoplastic disease care hospital, and 11 RNHCIs being paid on a reasonable cost basis subject to the rate-of-increase ceiling under § 413.40. (In accordance with § 403.752(a) of the regulation, RNHCIs are paid under § 413.40.) Among the remaining providers, the rehabilitation hospitals and units, and the LTCHs, are paid the Federal prospective per discharge rate under the IRF PPS and the LTCH PPS, respectively, and the psychiatric hospitals and units are paid the Federal per diem amount under the IPF PPS. As stated previously, IRFs and IPFs are not affected by the rate updates discussed in this final rule. The impacts of the changes on LTCHs are discussed in section I.J. of the appendix of this final rule. For the children’s hospitals, cancer hospitals, short-term acute care hospitals located in the Virgin Islands, Guam, the Northern Mariana Islands, and American Samoa, the extended neoplastic disease care hospital, and RNHCIs, the update of the rate- of-increase limit (or target amount) is the estimated FY 2026 percentage increase in the 2023-based IPPS operating market basket, consistent with section 1886(b)(3)(B)(ii) of the Act, and §§ 403.752(a) and 413.40 of the regulations. unt) is the estimated FY 2026 percentage increase in the 2023-based IPPS operating market basket, consistent with section 1886(b)(3)(B)(ii) of the Act, and §§ 403.752(a) and 413.40 of the regulations. Consistent with current law, based on IGI’s second quarter 2025 forecast of the 2023-based IPPS market basket increase, we are estimating the FY 2026 update to be 3.3 percent (that is, the estimate of the market basket rate-of-increase), as discussed in section VI.B. of the preamble of this final rule. Section 1886(b)(3)(B)(xi)(I) of the Act requires a productivity adjustment (0.7 percentage point reduction for FY 2026), resulting in a 2.6 percent applicable percentage increase for IPPS hospitals that submit quality data and are meaningful EHR users, as discussed in section VI.B. of the preamble of this final rule. Children’s hospitals, cancer hospitals, short term acute care hospitals located in the Virgin Islands, Guam, the Northern Mariana Islands, and American Samoa, the extended neoplastic disease care hospital, and RNHCIs that continue to be paid based on reasonable costs subject to rate-of-increase limits under § 413.40 of the regulations are not subject to the reductions in th lastic disease care hospital, and RNHCIs that continue to be paid based on reasonable costs subject to rate-of-increase limits under § 413.40 of the regulations are not subject to the reductions in the applicable percentage increase required under section 1886(b)(3)(B)(xi)(I) of the Act. Therefore, for those hospitals paid under § 413.40 of the regulations, the update is the percentage increase in the 2023-based IPPS operating market basket for FY 2026, currently estimated at 3.3 percent. The impact of the update in the rate-of- increase limit on those excluded hospitals depends on the cumulative cost increases experienced by each excluded hospital since its applicable base period. For excluded hospitals that have maintained their cost increases at a level below the rate-of-increase limits since their base period, the major effect is on the level of incentive payments these excluded hospitals receive. Conversely, for excluded hospitals with cost increases above the cumulative update in their rate-of- increase limits, the major effect is the amount of excess costs that would not be paid. We note that, under § 413.40(d)(3), an excluded hospital that continues to be paid under the TEF their rate-of- increase limits, the major effect is the amount of excess costs that would not be paid. We note that, under § 413.40(d)(3), an excluded hospital that continues to be paid under the TEFRA system and whose costs exceed 110 percent of its rate-of-increase limit receives its rate-of-increase limit plus the lesser of: (1) 50 percent of its reasonable costs in excess of 110 percent of the limit; or (2) 10 percent of its limit. In addition, under the various provisions set forth in § 413.40, hospitals can obtain payment adjustments for justifiable increases in operating costs that exceed the limit. I. Effects of Changes in the Capital IPPS 1. General Considerations For the impact analysis presented in this section of this final rule, we used data from the March 2025 update of the FY 2024 MedPAR file and the March 2025 update of the Provider-Specific File (PSF) that was used for payment purposes. Although the analyses of the changes to the capital prospective payment system do not incorporate cost data, we used the March 2025 update of the most recently available hospital cost report data to categorize hospitals. Our analysis has several qualifications and uses the best dat not incorporate cost data, we used the March 2025 update of the most recently available hospital cost report data to categorize hospitals. Our analysis has several qualifications and uses the best data available, as described later in this section of this final rule. Due to the interdependent nature of the IPPS, it is very difficult to precisely quantify the impact associated with each change. In addition, we draw upon various sources for the data used to categorize hospitals in the tables. In some cases (for instance, the number of beds), there is a fair degree of variation in the data from different sources. We have attempted to construct these variables with the best available sources overall. However, it is possible that some individual hospitals are placed in the wrong category. Using cases from the March 2025 update of the FY 2024 MedPAR file, we simulated payments under the capital IPPS for FY 2025 and the payments for FY 2026 for a comparison of total payments per case. Short- term, acute care hospitals not paid under the general IPPS (for example, hospitals in Maryland) are excluded from the simulations. The methodology for determining a capital IPPS payment is set forth a term, acute care hospitals not paid under the general IPPS (for example, hospitals in Maryland) are excluded from the simulations. The methodology for determining a capital IPPS payment is set forth at § 412.312. The basic methodology for calculating the capital IPPS payments in FY 2026 is as follows: (Standard Federal rate) × (DRG weight) × (GAF) × (COLA for hospitals located in Alaska and Hawaii) × (1 + DSH adjustment factor + IME adjustment factor, if applicable). In addition to the other adjustments, hospitals may receive outlier payments for those cases that qualify under the threshold established for each fiscal year. We modeled payments for each hospital by multiplying the capital Federal rate by the geographic adjustment factor (GAF) and the hospital’s case-mix. Then we added estimated payments for indirect medical education, disproportionate share, and outliers, if applicable. For purposes of this impact analysis, the model includes the following assumptions: • The capital Federal rate was updated, beginning in FY 1996, by an analytical framework that considers changes in the prices associated with capital-related costs and adjustments to account for forecast error, change eral rate was updated, beginning in FY 1996, by an analytical framework that considers changes in the prices associated with capital-related costs and adjustments to account for forecast error, changes in the case-mix index, allowable changes in intensity, and other factors. As discussed in section III.A.1. of the Addendum to this final rule, the update to the capital Federal rate is 2.8 percent for FY 2026. • In addition to the FY 2026 update factor, the FY 2026 capital Federal rate was calculated based on a GAF/DRG budget neutrality adjustment factor of 0.9918, a budget neutrality factor for the 5-percent cap on wage index decreases policy and the transition for the discontinuation of the low wage index hospital policy of 0.9989, and a outlier adjustment factor of 0.9616. 2. Results We used the payment simulation model previously described in section I.I. of the Appendix of this final rule to estimate the potential impact of the changes for FY 2026 on total capital payments per case, using a universe of 3,033 hospitals. As previously described, the individual hospital payment parameters are taken from the best available data, including the March 2025 update of the FY 2024 MedPAR using a universe of 3,033 hospitals. As previously described, the individual hospital payment parameters are taken from the best available data, including the March 2025 update of the FY 2024 MedPAR file, the March 2025 update to the PSF, and the most recent available cost report data from the March 2025 update of HCRIS. In Table III, we present a comparison of estimated total payments per case for FY 2025 and estimated total payments per case for FY 2026 based on the FY 2026 payment policies. Column 2 shows estimates of payments per case under our model for FY 2025. Column 3 shows estimates of payments per case under our model for FY 2026. Column 4 shows the total percentage change in payments from FY 2025 VerDate Sep 2014 00:36 Aug 02, 2025 Jkt 265001 PO 00000 Frm 00760 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 37295 to FY 2026. The change represented in Column 4 includes the 2.8 percent update to the capital Federal rate and other changes in the adjustments to the capital Federal rate. The comparisons are provided by: (1) g The change represented in Column 4 includes the 2.8 percent update to the capital Federal rate and other changes in the adjustments to the capital Federal rate. The comparisons are provided by: (1) geographic location; (2) region; and (3) payment classification. The simulation results show that, on average, capital payments per case in FY 2026 are expected to increase 3.2 percent compared to capital payments per case in FY 2025. This expected increase is primarily due to the 2.8 percent update to the capital Federal rate. In general, regional variations in estimated capital payments per case in FY 2026 as compared to capital payments per case in FY 2025 are primarily due to the changes in GAFs, and are generally consistent with the projected changes in payments due to the changes in the wage index (and policies affecting the wage index), as shown in Table I in section I.F. of the appendix of this final rule. The net impact of these changes is an estimated 3.2 percent increase in capital payments per case from FY 2025 to FY 2026 for all hospitals (as shown in Table III). The geographic comparison shows that, on average, hospitals in both urban and rural classifications would experi