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

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.

(1) Costs

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 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 overhead costs and benefits are equal to 100 percent of pre-tax wages, so the hourly wage including overhead costs is $139.00.

\536\ BLS. Occupational Employment and Wage Statistics: https://data.bls.gov/oes/#/industry/000000.

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 data\537\ 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 are also assumed to support electronic prescribing for Medicare Part D, which has required the use of the NCPDP SCRIPT standard version 2017071

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” final rule (Part D and Health IT Standards Final Rule) which appeared in the Federal Register on June 17, 2024 (89 FR 51238).\538\

\537\ https://data.cms.gov/quality-of-care/quality-payment-program-experience/data.

\538\ https://www.federalregister.gov/documents/2024/06/17/2024-12842/medicare-program-medicare-prescription-drug-benefit-program-health-information-technology-standards.

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

Lower Upper

Task Details bound bound Remarks

hours hours

Task 1: NCPDP SCRIPT Standard Version Update required 200 600 There are no changes related

2023011 for all required electronic prescribing to these transactions

transactions. transactions from NCPDP between the 2017071 and

SCRIPT Standard Version 2023011 versions of the

2017071 to NCPDP SCRIPT NCPDP SCRIPT Standard. We

Standard Version expect low implementation

2023011. effort, similar to prior

transitions, 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

eight required transactions:

New prescription (NewRx);

Request and respond to

change prescriptions

(RxChangeRequest,

RxChangeResponse); Request

and respond to cancel

prescriptions (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 previously 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 comply with the new

requirements. Task 2a: (i) Electronic Prior Electronic Prior 250 500 Products for electronic

Authorization transactions and (ii) Authorization prescribing being actively

new PANotification transaction. transactions are now used to report for Medicare Actively used products already required. These were PI performance are required

supporting Part D Requirements optional under Cures to conduct electronic

through PI reporting. Update regulations. prescribing through Part D,

Also, it is now which as of 2022, requires

required to implement the use of the SCRIPT

the transaction, standard and its associated

PANotification. 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 Electronic Prior 250 3600 In the 2015 Certification

Authorization transactions and (ii) Authorization Edition, new transactions

new PANotification transaction. transactions are now were required for this Products not represented in PI required. These were criterion. It was estimated

Reporting and may not yet support optional under Cures that it would require 250-

these transactions. Update regulations. 400 labor hours to implement

Also, it is now each new transaction. We

required to adopt and take a similar approach here

require transaction, with remaining products not

PANotification. represented in PI reporting.

Additionally, those who

voluntarily adopted the

transactions as part of a

certified Health IT Module

under prior rulemaking will

face less development costs

to adopt under new

requirements. Task 3: FDA National Drug Code (NDC) NDC is required in NCPDP 40 80 NDC is already widely adopted

terminology for coded drugs. SCRIPT Standard Version and seen as critical for

2023011 for coded drugs. coding 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. Task 4: Update to RxNorm December 4, Aligns with more current 40 80 Vocabulary standard is likely

2023, Full Update Release version of vocabulary to already be incorporated

terminology. standard. into fielded technology.

Some effort expected to

align with updated

certification requirements. Task 5. Race and Ethnicity data for NCPDP standard supports 40 80 Developers must map to

four transactions. the capability to patient's race and ethnicity

capture these data for data and support exchange of

transactions. these data for four

transactions. This

requirement 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).............. $5,532,200.00 $16,596,600.00 Task 2a (161 products)............. 5,594,750.00 11,189,500.00 Task 2b (38 products).............. 1,320,500.00 19,015,200.00

Task 3 (199 products).............. 1,106,440.00 2,212,880.00 Task 4 (199 products).............. 1,106,440.00 2,212,880.00 Task 5 (199 products).............. 1,106,440.00 2,212,880.00 Total (199 products and 150 15,766,770.00 53,439,940.00

developers).......................

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 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[thinsp]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 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 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 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 [verbar] Overdose Prevention [verbar] 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 [verbar] Journal of the American Medical Informatics Association [verbar] 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, 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 greater interoperability with pharmacy data systems and facilitate correct identification of prescribed products.

\542\ HIPAA Transaction and Code Set https://www.ecfr.gov/current/title-45/section-162.1002#p-162.1002(a)(3)

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

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 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[thinsp]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.

(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[thinsp]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[thinsp]170.207(d)(1)) and National Drug Codes (45 CFR[thinsp]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:

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 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[thinsp]170.207(d)(1)) and National Drug Codes (45 CFR[thinsp]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 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 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 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 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

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.

\543\ https://www.healthit.gov/data/quickstats/hospital-adoption-real-time-benefit-tools.

\544\ https://surescripts.widen.net/s/mvtqvvf5sd/2022-national-progress-report#page=1.

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

\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%20Check%20(RTBC,your%20electronic% 20medical%20record%20representative.

\549\ https://www.express-scripts.com/corporate/articles/scriptvision-gives-physicians-real-time-access-patient-specific-information.

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

\550\ https://data.bls.gov/oes/#/industry/000000.

Table I.G.12.-05--Estimated Labor Hours to Develop Real-Time Prescription Benefit Certification Criterion in 45

CFR 170.315(b)(4)

Lower Upper

Task Details bound bound Remarks

hours hours

Task 1: NCPDP Real-Time Prescription Transactions include 500 1,000 For the 2015 Edition of

Benefit (RTPB) standard version 13 RTPBRequests, health IT certification

and all associated transactions. RTPBResponse. Requests criteria, new transactions

include 6 transaction were added to the

segments and Response “electronic prescribing”

includes 5 segments.. criterion. It was estimated

that it would require 250-

400 labor hours to implement

each new transaction. We

take a similar approach

here. Task 2: RxNorm vocabulary standard ........................ 40 80 RxNorm is widely implemented

for relevant transaction segments and is a required vocabulary

and associated data elements. standard for “electronic

rescribing”. Mapping using

these codes should create

little extra effort to

implement in certified

Health IT Modules. Task 3: National Drug Codes ........................ 40 80 NDC is widely implemented and

vocabulary standard for transaction seen as critical for coding

segments and associated data drugs. NDC is now a required

elements. 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]

Estimated cost

Activity -------------------------------

Lower bound Upper bound

Task 1 (100 products)................... $6,950,000 $13,900,000 Task 2 (100 products)................... 556,000 1,112,000 Task 3 (100 products)................... 556,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 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.

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

\551\ https://jamanetwork.com/journals/jama-health-forum/fullarticle/2824904.

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 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 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\

\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/NCPDPFoundationRTPBGrant_FinalReport.pdf.

\554\ https://www.optum.com/content/dam/optum4/resources/pdf/wf2167397_pcs_improving_prescribing_process.pdf.

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 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 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 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 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\

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

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 supplies alone, including glucometers,

lancets, test strips, and insulin syringes or pen needles.\561\

\560\ https://jamanetwork.com/journals/jamainternalmedicine/fullarticle/2796059.

\561\ https://www.goodrx.com/conditions/diabetes/true-cost-of-diabetes?srsltid=AfmBOopd8-vmB-6TlpDZ1f34I1HxaavmKy-yyhauZ6PxHbFD1qyxmfdY.

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 RTBT cost estimate, they consider cost in their medical decision-making.

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

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 facilitate cost conversations and lead to savings, that information is not real-time and 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.

\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[hyphen]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.

\568\ https://councilreports.ama-assn.org/councilreports/downloadreport?uri=/councilreports/n21_cms_report_2.pdf.

\569\ https://jamanetwork.com/journals/jamanetworkopen/fullarticle/2805012.

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

\570\ https://surescripts.widen.net/s/mvtqvvf5sd/2022-national-progress-report#page=1.

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 updated to reflect wages of software developers as of 2024.

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 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[supreg] FHIR[supreg] 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 criteria are as follows:

45 CFR[thinsp]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[thinsp]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 CMS API requirements) and provider systems who receive information from payer systems to inform patient care and facilitate prior

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

Lower bound Upper bound

Task Details hours hours

Task 1: HL7 FHIR Da Vinci--Coverage Support the request and exchange 500 1,000

Requirements Discovery (CRD) Implementation of information that supports

Guide: Version STU 2.0.1--STU 2. the identification of coverage

requirements. Task 2: HL7 CDS Hooks FHIR Implementation ................................ 0 1,000

Guide version 2.0. Task 3: Support for “order-sign” hook....... ................................ 75 150

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.--07B--Total Cost to Develop 45 CFR 170.315(g)(31)

[2024 Dollars]

Activity Estimated cost

Lower bound Upper bound

Task 1 (234 products)................... $16,263,000 32,526,000 Task 2 (234 products)................... 0 32,526,000 Task 3 (234 products)................... 2,439,450 4,878,900

Total (234 products and 189 18,702,450 69,930,900

developers)........................

Total (1 product and 1 developer)... 79,925 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

Lower Upper

Task Details bound bound

hours hours

Task 1: HL7 FHIR Da Vinci-- Support “Full DTR EHR” ability to exchange and execute 500 1,000

Documentation Templates and Rules rules to ensure that prior authorization documentation

(DTR) Implementation Guide: Version requirements are met

STU 2.0.1--STU 2................... Task 2: Support for the SMART App ........................................................ 0 80

Launch Framework “confidential

app” profile......................

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)................... $16,263,000 $32,526,000 Task 2 (234 products)................... 0 2,602,080

Total (234 products and 189 16,263,000 35,128,080

developers)........................

Total (1 product and 1 developer)... 69,500 150,120

Table I.G.12.-09A--Estimated Labor Hours to Develop 45 CFR

170.315(g)(33) Prior Authorization API--Prior Authorization Support

Lower Upper

Task Details bound bound

hours hours

Task 1: HL7 FHIR Da Vinci--Prior Ability of the API 500 1,000

Authorization Support (PAS) to create and send

Implementation Guide: Version prior

STU 2.0.1--STU 2. authorization

requests and to

receive prior

authorization

responses. Task 2: Subscriptions R5 Backport Requirements to 500 1500

Implementation Guide version include: (1) topic-

1.1.0 (Backport IG). based Subscription

support for FHIR

R4 and (2) support

of the REST-hook

Subscription

channel. Task 3: Support R4/B Topic-Based Conformance to 250 500

Subscription Profile. profile, support

for “must

support”

elements, and use

of canonical URL

of Subscription

Topic. Task 4: Support for R4 Topic- Support the 50 100

Based Subscription Server creation, update,

Capability Statement. and deletion of

Subscription

resources in the

Capability

Statement.

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)................... $16,263,000 $32,526,000 Task 2 (234 products)................... 16,263,000 48,789,000 Task 3 (234 products)................... 8,131,500 16,263,000 Task 4 (234 products)................... 1,626,300 3,252,600

Total (234 products and 189 42,283,800 100,830,600

developer).........................

Total (1 product and 1 developer)... 180,700 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, 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.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 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.

\571\ https://jamanetwork.com/journals/jama/fullarticle/2785480.

\572\ Ibid.

\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_CAQH_Index_Report.pdf.

\577\ https://academic.oup.com/healthaffairsscholar/article/2/9/qxae096/7727862.

\578\ https://www.healthaffairs.org/doi/10.1377/hlthaff.28.4.w533.

\579\ https://academic.oup.com/healthaffairsscholar/article/2/9/qxae096/7727862.

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

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.

\580\ https://apps.legislature.ky.gov/CommitteeDocuments/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.

\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.28.10.1121.

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\

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

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

\588\ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10332446/.

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

\589\ https://www.cms.gov/files/document/hiig-august-2023-isc-speaker-slides.pdf.

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

\590\ https://www.hhs.gov/press-room/kennedy-oz-cms-secure-healthcare-industry-pledge-to-fix-prior-authorization-system.html.

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

most, if not all health plans that cover their patients.

\591\ https://showroom.epic.com/stage?id=35&t=23&c=259.

\592\ https://www.cms.gov/files/document/hiig-august-2023-isc-speaker-slides.pdf.

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

Cumulative

Average Cumulative Average Cumulative Cumulative hours for all Cost difference

hours \1\ hours hours hours hour certified API ($) \3\

difference Products \2\

Base build.......................................... 4,300 4,300 350 350 3,950 924,300 $128,477,700 1 Plan.............................................. 50 4,350 250 600 3,750 877,500 121,972,500 10 Plans............................................ 500 4,800 2,500 2,850 1,950 456,300 63,425,700 20 Plans \4\........................................ 1,000 5,300 5,000 5,350 -50 -11,700 -1,626,300 25 Plans............................................ 1,250 5,550 6,250 6,600 -1,050 -245,700 -34,152,300 50 Plans............................................ 2,500 6,800 12,500 12,850 -6,050 -1,415,700 -196,782,300 300 Plans........................................... 15,000 19,300 75,000 75,350 -56,050 -13,115,700 -1,823,082,300

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 x +4,300 = 250 x +350; x = 3,950/200; x = 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 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

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\

\593\ https://www.federalregister.gov/documents/2024/02/08/2024-00895/medicare-and-medicaid-programs-patient-protection-and-affordable-care-act-advancing-interoperability.

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.

\594\ https://www.federalregister.gov/documents/2024/02/08/2024-00895/medicare-and-medicaid-programs-patient-protection-and-affordable-care-act-advancing-interoperability.

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

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

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

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

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

General and Per general

Encounter type All hospitals critical access % of All hospital

hospitals (n=4,500)

Outpatient visits......................... 834,034,000 717,159,000 86 159,368

Hospital admissions....................... 33,357,000 31,393,000 94 6,976 Length of stay............................ 6.3 5.6 .............. ..............

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

Percentage of Per practice

Encounter type All physicians Primary care all (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_summary/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 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 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\

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

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

Savings Percentage Reduced Reduced

per Savings per of Total hours per cost per

Year hospital hospital hospitals number of years years ($

(hour), ($), adopting hospitals (millions), millions),

average average the APIs average average

2027................................ 4,410 315,390 75 4,500 14.9 1,064 2028................................ 4,410 315,390 80 4,500 15.9 1,135 2029................................ 4,410 315,390 85 4,500 16.9 1,206 2030................................ 4,410 315,390 90 4,500 17.9 1,277 2031................................ 4,410 315,390 96 4,500 19.1 1,362 2032................................ 4,410 315,390 97 4,500 19.2 1,377 2033................................ 4,410 315,390 98 4,500 19.4 1,391 2034................................ 4,410 315,390 99 4,500 19.6 1,405 2035................................ 4,410 315,390 99 4,500 19.6 1,405 2036................................ 4,410 315,390 100 4,500 19.8 1,419

Total........................... ......... ........... ........... ........... 182 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 authorization 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 average physician

group. The average is 15x the amount of burden.

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

Provider API,

Provider API, API effect,

Year API effect, dollars per

hours per year year (in

(in millions) 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

dollars 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

Percentage Reduced

Savings Savings of Total hours Reduced

Year per per practices number of per year cost per

practice practice adopting practices (in year ($ in

(hour) ($) the APIs millions) millions)

2027.................................. 294 21,026 27.5 199,543 16.1 1,151.7 2028.................................. 294 21,026 33.2 199,543 19.5 1,392.9 2029.................................. 294 21,026 39.0 199,543 22.9 1,634.2 2030.................................. 294 21,026 44.7 199,543 26.2 1,875.4 2031.................................. 294 21,026 50.5 199,543 29.6 2,116.7 2032.................................. 294 21,026 56.2 199,543 33.0 2,357.9 2033.................................. 294 21,026 62.0 199,543 36.3 2,599.2 2034.................................. 294 21,026 67.7 199,543 39.7 2,840.4 2035.................................. 294 21,026 73.5 199,543 43.1 3,081.7 2036.................................. 294 21,026 79.2 199,543 46.5 3,322.9

Total............................. ......... ........... ........... ........... 313 22,373

Notes: The savings reflect adjustment in the percentage of practices adopting the finalized prior authorization

APIs, as adjusted from the percentage 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 Adopting

Certified Prior Authorization APIS

Provider API Provider API

API effect, API effect, $

Year hours per year per year

(millions) (millions)

2027.................................... 0.0 0.0 2028.................................... 2.3 161.9 2029.................................... 4.5 318.4 2030.................................... 6.6 468.9 2031.................................... 8.6 613.3 2032.................................... 10.6 750.9 2033.................................... 12.3 881.5 2034.................................... 14.1 1,004.3 2035.................................... 15.7 1,119.1 2036.................................... 17.2 1,225.1

Total............................... 91.8 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

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

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.

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 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 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)

Lower Upper

Task Details round round Remarks

hours hours

Task 1: HL7 CDS Hooks Release 2.0.1.... CDS Hooks FHIR Release 0 1.000 First balloted over 5

2.0.1 in 45 CFR years ago, CDS Hooks in

170.215(f) as a mature but still in

prerequisite to trial use. We finalize a

facilitate API-driven CDS minimal implementation

workflow triggers in 45 of the standard and

CFR 170.3315(j)(20). believe this

implementation is likely

supported 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\ 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\

\603\ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8324242/.

\604\ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8416232/.

Many commenters were partial to certification requirements for specific use 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 on the variety of actionable CDS recommendation types that could be returned from the decision support tool.

\605\ https://pubmed.ncbi.nlm.nih.gov/30605914/.

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

\606\ Ibid.

(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

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 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 platforms and health systems.

\607\ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9382378/.

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.

\608\ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7233102/.

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 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\

\609\ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9382378/.

\610\ Ibid.

(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 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 Table I.G.12.-18:

TABLE I.G.12.--18. Estimated Labor Hours To Develop Subscriptions 45 CFR 170.315(j)(21)

Lower bound Upper bound

Task Details hours hours

Task 1: Implementation of Subscriptions R5 Requirements to include: (1) 500 1,500

Backport Implementation Guide version 1.1.0 topic-based Subscription

(Backport IG). support for FHIR R4 and (2)

support of the REST-hook

Subscription channel. Task 2: Support R4/B Topic-Based Subscription Conformance to profile, support 250 500

Profile. for “must support” elements,

and use of canonical URL of

Subscription Topic. Task 3: Support for R4 Topic-Based Support the creation, update, 50 100

Subscription Server Capability Statement. and deletion of Subscription

resources in the Capability

Statement.

Notes: The lower and upper bound hours estimated to complete each task are estimates of labor hours required for

each product.

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.

\611\ https://build.fhir.org/ig/HL7/fhir-subscription-backport-ig/.

(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

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

\612\ https://build.fhir.org/subscriptions.html.

\613\ https://build.fhir.org/versions.html#maturity.

\614\ https://build.fhir.org/subscriptions.html.

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

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) 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 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\

\615\ https://www.federalregister.gov/d/2020-07419/p-3125.

\616\ Formula: $109,557/23 = $4,763.

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

\617\ Formula: $4,763 x (1-0.23) = $3,667

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....................................... 89 108 21.0% Information Security Analysts................................... 96 103 7.1 Software Developers............................................. 107 139 29.9 Database Administrators......................................... 86 103 20.1 Network and Computer Systems Administrators..................... 83 97 17.2 Computer Network Architects..................................... 104 131 25.6

Computer Occupations, All Other................................. 88 112 27.5 Computer Network Support Specialists............................ 65 77 17.8

All......................................................... 90 109 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 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)

Per criterion New criterion Number of Cost inflation Total cost

Criterion cost cost (%) developers (labor rate) (per annum)

45 CFR 170.315(b)(4)............ 4,763 77% 150 21% $696,414 45 CFR 170.315(g)(31)........... 4,763 77 189 21 877,481 45 CFR 170.315(g)(32)........... 4,763 77 189 21 877,481 45 CFR 170.315(g)(33)........... 4,763 77 189 21 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 x (1-0.23)) x N\developer\]/(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 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.

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 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 (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).

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 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 (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).

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 Sec. 413.40. (In accordance with Sec. 403.752(a) of the regulation, RNHCIs are paid under Sec. 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 Sec. Sec. 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 Sec. 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 Sec. 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 Sec. 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 Sec. 413.40, hospitals can obtain payment adjustments for justifiable increases in operating costs that exceed the limit.

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 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 at Sec. 412.312. The basic methodology for calculating the capital IPPS payments in FY 2026 is as follows:

(Standard Federal rate) x (DRG weight) x (GAF) x (COLA for hospitals located in Alaska and Hawaii) x (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, 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.